Return-Path: X-Original-To: apmail-myfaces-users-archive@www.apache.org Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1301EE48A for ; Fri, 18 Jan 2013 13:40:24 +0000 (UTC) Received: (qmail 77151 invoked by uid 500); 18 Jan 2013 13:40:23 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 76591 invoked by uid 500); 18 Jan 2013 13:40:17 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 76415 invoked by uid 99); 18 Jan 2013 13:40:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Jan 2013 13:40:14 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [85.31.2.166] (HELO mx2.itandtel.at) (85.31.2.166) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Jan 2013 13:40:08 +0000 X-IronPort-AV: E=Sophos;i="4.84,492,1355094000"; d="scan'208";a="17638366" Received: from unknown (HELO mail4.itandtel.at) ([10.2.1.51]) by mx2.itandtel.at with ESMTP; 18 Jan 2013 14:39:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [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: Fri, 18 Jan 2013 14:39:47 +0100 Message-ID: In-Reply-To: <50F93163.6030401@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [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) Thread-index: Ac31br+ggesB7NDjRhqqCpwIiui+RgADtAhg References: <50F93163.6030401@gmail.com> From: "Thomas Herzog" To: "MyFaces Discussion" , X-Virus-Checked: Checked by ClamAV on apache.org Take a look at this post. I googled a bit and it seems that all of the = issues got resolved by application classloader. Maybe this helps you a little bit. http://grokbase.com/p/myfaces/users/12cchrh53c/codi-codi-v1-0-5-websphere= -v8-5-0-1-problem https://www.ibm.com/developerworks/forums/thread.jspa?threadID=3D391557 http://stackoverflow.com/questions/4051069/cdi-using-interceptors-across-= different-modules-bean-archives http://grokbase.com/p/myfaces/users/12cchrh53c/codi-codi-v1-0-5-websphere= -v8-5-0-1-problem Mit freundlichen Gr=FC=DFen 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=FCngliche Nachricht----- Von: titou10 [mailto:titou10.titou10@gmail.com]=20 Gesendet: Freitag, 18. J=E4nner 2013 12:26 An: MyFaces Discussion Betreff: [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 =3D = 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"=20 =3D"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 (=3Dlab) 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 =E9crit : > > 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=20 > 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=FC=DFen > > 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=FCngliche Nachricht----- > Von: titou10 titou10 [mailto:titou10.titou10@gmail.com] > Gesendet: Donnerstag, 17. J=E4nner 2013 22:51 > An: MyFaces Discussion > Betreff: Re: Re: [CODI] CODI jar in ear/lib with a WAR =3D fail in=20 > WebSphere v8.5 > > I was copied in my previous mail... > > "Avoid trouble: CDI is only supported with the default WebSphere=20 > 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=3D%2Fcom. > ibm.websphere.nd.multiplatform.doc%2Fae%2Fcweb_cdi.html > > 2013/1/17 Thomas Herzog >: > > > > > > I have read the doc in the link you have added but i dot not see=20 > > 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 > > > > > 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=20 > > 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=20 > > 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 =3D 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=20 > > file > > > in application, and not with the alternative, single class loader=20 > > for > > > application setting." > > > - in this scenario, no need to change the WAR/manifest.mf file as=20 > > the > > > codi jar file is in ear/lib and there is no other dependent jar at=20 > > the > > > "root" level of the ear > > > > > > I'm very interested in seeing the way your app is packaged. I can=20 > > also > > > send you our very simple ear file > > > > > > Q: In your your apps, do you use "WAR classloader policy = =3Dapplication" > > > (=3D1 classloader) or "=3DModule" (2 classloaders). > > > > > > The exception: > > > Caused by: java.lang.NullPointerException > > > at > org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLi > fecycleBroadcaster.broadcastBeforeEvent(JsfRequestLifecycleBroadcaster > .java:58) > > > at > org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLi > fecyclePhaseListener.beforePhase(JsfRequestLifecyclePhaseListener.java > :56) > > > at=20 > > org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListene > > rsBefore(PhaseListenerManager.java:76) > > > at=20 > > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImp > > l.java:159) > > > ... 29 more > > > > > > 2013/1/17 Thomas Herzog >: > > >> > > >> 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=20 > >> 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=20 > >> > > > >> 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=20 > >> hood) > > >> in WAS as explained here: > > >> = http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=3D%2Fc > >> om > > >> .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.JsfReques > >> tL > > >> ifecycleBroadcaster > > >> line 58. > > >> JsfRequestLifecycleBroadcaster : > > >> ... > > >> 43 @Inject > > >> 44 private Event phaseEvent; > > >> ... > > >> 54 void broadcastBeforeEvent(PhaseEvent phaseEvent) > > >> 55 { > > >> 56 this.facesPhaseId =3D phaseEvent.getPhaseId(); > > >> 58 > > >> this.phaseEvent.select(createAnnotationLiteral(phaseEvent.getPhaseI > >> d( > > >> ), > > >> 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=20 > >> 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=20 > >> 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 >