Just for test. Try to put codi dependencies in each webapp lib and not in ear lib. El 18/01/2013 02:07, "Thomas Herzog" <t.her...@curecomp.com> escribió:
> Here I sent you our config:**** > > ** ** > > **1. **application_xml_initilaize_in_order: we faced the iisue that > codi wont start properly when the wars are not initialized in order.**** > > **2. **application_xml_war_order: we ha to initiliaze the new war > first because it uses codi, jsf, cdi and so on.**** > > **3. **deployment_xml_classloader_policy: single classloader, new > war PARENT_LAST, rest PARENT_FIRST**** > > **4. **ear_lib: contains all of our for all projects accessible > used util jars.**** > > **5. **new_war_web_inf_lib: contains all jars only the new war > needs access to.**** > > **6. **websphere_ear_classloader_deployed: See the classloader of > the ear on websphere when its deployed.**** > > ** ** > > We needed some time to get codi running because of classloading issues and > startup of codi.**** > > Hopefully this will help you J**** > > ** ** > > Mit freundlichen Grüßen**** > > ** ** > > Thomas Herzog**** > > Softwareentwicklung**** > > ** ** > > curecomp Software Services GmbH**** > > Hafenstrasse 47-51**** > > 4020 Linz**** > > ** ** > > web: www.curecomp.com**** > > e-Mail: t.her...@curecomp.com**** > > tel: +43 (0)732 9015-5563**** > > mobile: +43 (0)664 8867 9829**** > > ** ** > > ** ** > > ** ** > > ** ** > > -----Ursprüngliche Nachricht----- > Von: titou10 titou10 [mailto:titou10.tito...@gmail.com] > Gesendet: Donnerstag, 17. Jänner 2013 22:51 > An: MyFaces Discussion > Betreff: Re: Re: [CODI] CODI jar in ear/lib with a WAR = fail in WebSphere > v8.5 > > ** ** > > I was copied in my previous mail...**** > > ** ** > > "Avoid trouble: CDI is only supported with the default WebSphere > Application Server class loader policy, Class loader for each WAR file in > application, and not with the alternative, single class loader for > application setting."**** > > ** ** > > > http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Fae%2Fcweb_cdi.html > **** > > ** ** > > 2013/1/17 Thomas Herzog <t.her...@curecomp.com>:**** > > >** ** > > > I have read the doc in the link you have added but i dot not see your > problem clear. Please copy paste the part you mean it says only classloader > policy module is supportet by cdi.**** > > >** ** > > >** ** > > >** ** > > > Send via Samsung Galaxy S2titou10 titou10 <titou10.tito...@gmail.com> ** > ** > > > hat geschrieben:- PARENT_FIRST on all classloaders: same here**** > > > - In the very simple ear described before, we just have 1 war module *** > * > > > and the codi jar in ear/lib. The application does not start. There is ** > ** > > > no CNF or unsatisfied link exceptions. Just the NPE in **** > > > JsfRequestLifecycleBroadcaster due to "this.phaseEvent" being null.**** > > > Using "WAR classloader policy" to "application" make it to start but *** > * > > > it is not supported by "CDI in WebSphere". Sorry for my previous **** > > > statement that was not clear, on the page in the WAS infocenter given ** > ** > > > previously. The is not supported by "CDI in WebSphere" as stated in **** > > > the link given previsouly, this is what I meant in my first post **** > > > (sorry for my previous statement that was not clear) . Only "WAR **** > > > classloader policy = module" is supported: (Quote from infocenter) **** > > > "Avoid trouble: CDI is only supported with the default WebSphere **** > > > Application Server class loader policy, Class loader for each WAR file * > *** > > > in application, and not with the alternative, single class loader for ** > ** > > > application setting."**** > > > - in this scenario, no need to change the WAR/manifest.mf file as the ** > ** > > > codi jar file is in ear/lib and there is no other dependent jar at the * > *** > > > "root" level of the ear**** > > >** ** > > > I'm very interested in seeing the way your app is packaged. I can also * > *** > > > send you our very simple ear file**** > > >** ** > > > Q: In your your apps, do you use "WAR classloader policy =application"** > ** > > > (=1 classloader) or "=Module" (2 classloaders).**** > > >** ** > > > The exception:**** > > > Caused by: java.lang.NullPointerException**** > > > at > org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecycleBroadcaster.broadcastBeforeEvent(JsfRequestLifecycleBroadcaster.java:58) > **** > > > at > org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecyclePhaseListener.beforePhase(JsfRequestLifecyclePhaseListener.java:56) > **** > > > at > org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:76) > **** > > > at > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:159) > **** > > > ... 29 more**** > > >** ** > > > 2013/1/17 Thomas Herzog <t.her...@curecomp.com>:**** > > >>** ** > > >> 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.tito...@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.JsfRequestL** > ** > > >> ifecycleBroadcaster**** > > >> 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**** >
