myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [CODI] Does CODI supports to be deployed in a app server that uses multi-classloader for EARs (was: CODI jar in ear/lib with a WAR = fail in WebSphere v8.5)
Date Sat, 19 Jan 2013 13:17:57 GMT

> Does anyone use CODI in such a way? in Glassfish or JBoss maybe? I think TomEE 
> uses a single classloader...

Yes, I use it that way. Well, we are not actually using a full EAR but a Tomcat with catalina.sharedLoader
set to webapps/lib. This means each WAR gets an own WebAppClassloader and they share a common
ClassLoader. CODI works perfectly well in this case.
The only thing you need to make sure is that all the classes needed by CODI are also available
in the shared ClassLoader. 


E.g. if you move codi-jsf to the shared classpath, then you also need the javax.faces classes
accessible from there. Of course, you could also keep codi-core in the shared loader and move
JSF related parts to each webapp.

Both work perfectly fine. In our app we share a few commonly used dialogues and JSF resources,
thus we also have MyFaces-core available in the shared loader.


LieGrue,
strub




----- Original Message -----
> From: titou10 <titou10.titou10@gmail.com>
> To: MyFaces Discussion <users@myfaces.apache.org>
> Cc: 
> Sent: Friday, January 18, 2013 12:26 PM
> Subject: [CODI]  Does CODI supports to be deployed in a app server that uses multi-classloader
for EARs (was: CODI jar in ear/lib with a WAR = fail in WebSphere v8.5)
> 
> 
> Danke schoen Thomas, you answered my question.
> 
> The key thing here for you is using "deployment_xml_classloader_policy: 
> single classloader" ( "WAR classloader policy" 
> ="application") which is not supported by IBM.
> 
> This is what we were using, this was the only way we found to have our apps 
> working with CODI, PARENT_FIRSTx2 is ok for us as our 
> app is less complex (another way is to pack everything in WAR/WEB-INF/lib, codi 
> and other dependents jar and the project EJB jars)
> .
> This...until I opened a PMR by IBM (PM80276 "CreationalContext Not Created 
> for Custom Scope Stateful EJB" that will be included in 
> WAS v8.5.0.2)  and sent them a very simple ear file demonstrating that CDI 
> custom scoped used in  and EJB caused troubled, so the PMR.
> 
> The IBM guy from level 3 support (=lab) gave us a iFix and wrote (quoting him) :
> "Also of note to the customer: They need to DISABLE the single class 
> loading for application option, which they have set for thier 
> application, as this is not supported by WebSphere's CDI implementation. If 
> the do not disable the single class loading option then 
> their app may appear to be working correctly, but unexpected problems may occur. 
> "
> 
> And he pointed me to the WAS v8.5 infocenter link
> 
> So I come back to my original question, does CODI support to be deployed in an 
> ear with multi-level classloader?
> Does anyone use CODI in such a way? in Glassfish or JBoss maybe? I think TomEE 
> uses a single classloader...
> 
> It is not a classpath problem, but a multi-classloader problem. CODI does not 
> seem to handle this well... Maybe the way ClassUtils 
> loads classes or the PhaseListenerExtension class that handle the JSF lifecycle 
> artefacts (leading to the NPE as decribed before) 
> have some bugs?
> I tried to debug it without success.
> 
> (I changed the title of the post to reflect the question)
> 
> Le 2013-01-18 03:06, Thomas Herzog a écrit :
>> 
>>  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 
> <mailto: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 <mailto: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 
> <mailto: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 <mailto: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
View raw message