Hello,
I'm still experimenting with CODI and WebSphere v8.5.0.1 without success
Our "standard" ear deployements scheme is:
ear
- 1 ejb.jar module
- 1 war module
- lib
- 1 jpa.jar module
- dependent jar (like codi..)
WAS normally uses 2 levels of application class loaders : 1 per WAR
and 1 per application as the parent of the previosu one. It can be
configure to use only one per application (all modules + war in the
same classloder) but it is not supported by CDI (OWB under the hood)
in WAS as explained here:
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Fae%2Fcweb_cdi.html
A simple ear file as this one fails to start in WAS v8.5.0.1 :
ear
- war (even with no java at all in it)
- lib
myfaces-extcdi-bundle-jsf20-1.0.5.jar
It fails with a NPE in
org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecycleBroadcaster
line 58.
JsfRequestLifecycleBroadcaster :
...
43 @Inject
44 private Event<PhaseEvent> phaseEvent;
...
54 void broadcastBeforeEvent(PhaseEvent phaseEvent)
55 {
56 this.facesPhaseId = phaseEvent.getPhaseId();
58 this.phaseEvent.select(createAnnotationLiteral(phaseEvent.getPhaseId(),
true)).fire(phaseEvent);
...
On line 58 at application startup, "this.phaseEvent" is null.
This seems to be due to a classloader problem:
- If I configure the app to use only 1 classloader for the whole app,
it works (but not supported by WAS/CDI/OWB implementation as stated
above)
- If I package the CODI jar in WEB-INF/lib. It works... but the
classes in our EJB module later will not "see" CODI artefacts. Not
feasible for us
- I can package the CODI jar + the EJB module in WEB-INF/lib: Not
feasable has will we EJB timers and other ejb related things that are
restricted by this kind of packaging
- I also trie to use the specific package, ie putting the jsf CODI
module in WEB-INF/lib but classes in EJB will use some CODI
annotations.. So not a solution for us
So up to now, CODI is still a no-go and we hope DeltaSpike wil lnot
suffer the same problem in the future
Q: Is this kind of packaging supported? Do anyone use this kind of
packaging with success? maybe with another application server?
I can provide a very simple EAR file to demonstrate this with the
resulting startup stacktrace and/or create a JIRA with the details
Thx in advance
