myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From José Luis Cetina <maxtorz...@gmail.com>
Subject Re: AW: Re: [CODI] CODI jar in ear/lib with a WAR = fail in WebSphere v8.5
Date Fri, 18 Jan 2013 17:26:47 GMT
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.herzog@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.herzog@curecomp.com****
>
> tel: +43 (0)732 9015-5563****
>
> mobile: +43 (0)664 8867 9829****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> -----Ursprüngliche Nachricht-----
> Von: titou10 titou10 [mailto:titou10.titou10@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.herzog@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.titou10@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.herzog@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.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.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****
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message