myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Herzog" <t.her...@curecomp.com>
Subject AW: [CODI] CODI jar in ear/lib with a WAR = fail in WebSphere v8.5
Date Thu, 17 Jan 2013 21:03:52 GMT

We are working on was 8.0.0.1 and are using codi and deltaspike and we do have the jars in
ear lib.
We do have application classloader and parent first and works.
One problem was that tha modules must have manifest entries to their depended modules.
E.g.: webmodule must have manifest entries for serviceImpl and serviceAPI. Otherwise a UnsatifiedResolution
will occur because cdi would not be able to find the implementation.

I do not understand what you mean with not supported by cdi ?
Its no standard owb but codi and deltaspike are working. We faced classloading issues but
normal for websphere ;-)

Kep me notified and tomorow i can give you a detail about our config.



Send via Samsung Galaxy S2titou10 titou10 <titou10.titou10@gmail.com> hat geschrieben: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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message