myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From titou10 <titou10.tito...@gmail.com>
Subject Re: [CODI] Does CODI supports to be deployed in a app server that uses multi-classloader for EARs
Date Mon, 21 Jan 2013 23:44:56 GMT
Thanks Mark for the information.

I'll try to debug it in WAS, there no reason it does not work if you use it yourself with
a multi-level hiearchy CL.

Could you point me out where in the code the object injected in line  44 of JsfRequestLifecycleBroadcaster
(Event<PhaseEvent> 
phaseEvent) is declared/produced?

Thanks

Denis

Le 2013-01-19 08:17, Mark Struberg a écrit :
>> 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