[MAGNOLIA-5699] When attempting to run Magnolia on J2EE server Guice conflicts with CDI Created: 27/Feb/14 Updated: 15/Nov/17 Resolved: 15/Nov/17 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 5.2.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Neutral |
| Reporter: | joshua portway | Assignee: | Unassigned |
| Resolution: | Outdated | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Wildfly8.0.final |
||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
Attempting to deploy a magnolia project (created from maven archetype) on Wildfly fails because wildfly scans the jar for classes using CDI annotations. Unfortunately, Magnolia uses Guice annotations which conflict with CDI causing Wildfly to bail on the deployment. Since both Glassfish and Wildfly use Weld as their CDI implementation I would imagine the same symptoms appear on Glassfish (and probably any other CDI spec compliant server), though I haven't tested yet. The workaround is to stop the CDI implementation from scanning the jars. There is a note on this here : http://weld.cdi-spec.org/documentation/#4 Basically it boils down to : <jboss xmlns="urn:jboss:1.0"> <weld xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/> </jboss> On Glassfish - I think it should be possible to turn off CDI by including a beans.xml file in WEB-INF with the following declaration (untested): <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" bean-discovery-mode="none"> </beans> This may work for JBoss too - I haven't tried it. |
| Comments |
| Comment by Daniel Lipp [ 28/Feb/14 ] |
|
see also http://forum.magnolia-cms.com/forum/thread.html?threadId=71e16516-6efc-4f48-92ab-f69b8e38c316&page=1 |
| Comment by Federico Grilli [ 28/Feb/14 ] |
|
Hi Joshua, are symptoms the same as in http://jira.magnolia-cms.com/browse/MGNLADMLEG-50? |
| Comment by joshua portway [ 28/Feb/14 ] |
|
Well, this one is deeper. The previous bug was just the first of these problems. That bug has gone away in 5.2.2 but magnolia still doesn't deploy because there are lots of similar problems. The workaround I describe above basically tells the server not to scan the war file for CDI annotations, and so it avoids the whole mess. At least for JBoss Wildfly this appears to work and magnolia will deploy and run (though it still throws a lot of warnings about sessions not being closed correctly, but that's a different problem and magnolia seems to have had that issue since version 4 and it seems to struggle on). |
| Comment by joshua portway [ 28/Feb/14 ] |
|
As an aside - you might want to consider moving from Guice to CDI at some point. I don't have much experience with Guice, but apart from integrating into JavaEE (well, it now seems to be the core of JavaEE) CDI does a lot of very useful validation and checking on startup which can catch strange and difficult bugs. The previous bug was an example - having a Singleton annotation on a generic class doesn't make sense so CDI warns you on startup. All this validation can catch a lot of issues before they happen (a bit like compiler warnings vs run time failures). I don't know whether the problems that CDI is finding in magnolia are relevant to Guice - perhaps they're not - but it's complaining about things like annotated methods throwing exceptions when the specification of the annotation (in CDI - perhaps not in Guice) forbid exceptions to be thrown. If it is actually a bug, that kind of error can lead to weird silent failures as the method throws an exception, but there's nothing to catch it. Even if you don't switch to CDI it might be worth at least looking at the problems CDI is throwing up. |
| Comment by Federico Grilli [ 28/Feb/14 ] |
|
Thanks for the clarification. The warnings about sessions not being closed correctly, though annoying, should be harmless, afaik. As to the implications of moving from Guice to CDI, I wouldn't know, I'll let someone more knowledgeable to chime in. |