Hi Denis, I've already checked your post (very instructive, thanks). I'm sure SINGLE_CLASSLOADER for ear will resolve this issue. Problem is I don't know how to specify it in JBoss AS 7 (I don't think it's supported - JBoss always creates an isolated classloader for each war)
Going to use your instructions for WAS in the future (I'm using both JBoss AS 7 and WAS 8). For the moment, no problem with WAS 8 and ear packaging, everything is under WEB-INF/lib (no EJB Timer for the moment). BTW, updated sample app (moved codi to ear) : it's in ear branch https://github.com/gonzalad/codi-ear-viewaccessscoped/tree/ear If I don't find a packaging solution, perhaps I'll give a try modifying locally CODI code, but not sure which approach is best (the 3rd one perhaps but not sure it will work ;( ) : Sorry those are rough notes, and I don't master CDI : 1. modify ClassUtils.getClassloader add a configurationparameter to return ClassUtils.class.getClassloader(). cons : we're still relying on classloader and potentially will have a pb with another appserver. 2. remove @JsfPhaseListener and rely on classic phaseListeners configured with faces-config.xml cons : non CDI 3. use CDI to communicate phaseListener class in CODI consumeJsfPhaseListener i.e. we could perhaps add dynamically a bean or producer of type Class with a custom annotation, i.e. @JsfPhaseListener Class. then in consumer, we @Inject @JsfPhaseListener Instance<Class> jsfPhaseListenerClasses Afterwards, we instanciate phaseListener iterating on jsfPhaseListenerClasses.iterator(). cons : make a test with a JsfPhaseListener1 in webapp1 and JSFPhaseListener2 in webapp2, both being in the same EAR. Check that webapp1 has only listener JsfPhaseListener1 and not both of them. ________________________________ De : titou10 titou10 <titou10.tito...@gmail.com> À : MyFaces Discussion <users@myfaces.apache.org>; Adrian Gonzalez <adr_gonza...@yahoo.fr> Envoyé le : Mardi 19 mars 2013 22h37 Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x Maybe you should check my previous post named "CODI jar in ear/lib with a WAR = fail in WebSphere v8.5" and then "Does CODI supports to be deployed in a app server that uses multi-classloader..." started January 17 because it seems that you have the same problem we have with WebSphere v8.5 If I try to deploy the CODI jar into ear/lib, some PhaseListener magical initialisation was not working at startup (=first page accessed)... And I also have the same feeling as you that this is the way CODI use the classloaders that causes the problem ... The only solutions we found: configure WAS to use only 1 classloader for all the modules in the ear, (but this is not supported by the OWB implementation packaged with WAS), or deploy everything in war WEB-INF/lib, including the ejb jars. In fact we put "any module that uses CDI (inject/producers)" in web-inf/lib and the other in ear/lib (slf4j, hibernate, jpa module etc) This is what we are doing even if I don't like it... Mark Struberg answered that he was using CODI with a multi level CL without problem... 2013/3/19 Adrian Gonzalez <adr_gonza...@yahoo.fr>: > I've just put myfaces-extcdi-bundle-jsf20-1.0.5.jar into ear (and removed it > from WEB-INF/lib), no more luck. > > I'll try to update my sample tomorrow with ear packaging and debug it. > > Thanks once more for the help Christian ! > > P.S. I'm wondering if the root cause of this bug isn't in CODI (classloader > usage in Java EE & CDI appears to be under-specified, so I'm not sure a CDI > extension should rely on TCCL for its internals) > > > ________________________________ > De : Christian Beikov <c.bei...@curecomp.com> > À : users@myfaces.apache.org > Envoyé le : Mardi 19 mars 2013 21h20 > Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x > > I used the xml file to be able to put the CODI bundle into EAR/lib. > The problem was that JSF is not on the classpath which the deployment > xml should fix. > My CODI bundle is currently in EAR/lib and it deploys successfully with > this configuration. > > Am 19.03.2013 20:43, schrieb Adrian Gonzalez: >> Hi Christian, >> >> Thanks for the tip ! >> >> Just made a quick test using your file with my sample, but no luck, it >> doesn't work. >> I'm using JBoss jsf impl (so no jsf jars in my app). >> I've also putting myfaces-extcdi-bundle-jsf20-1.0.5.jar in the war, >> WEB-INF/lib. >> >> Do you have the same setup ? >> >> >> ________________________________ >> De : Christian Beikov <c.bei...@curecomp.com> >> À : users@myfaces.apache.org >> Envoyé le : Mardi 19 mars 2013 17h18 >> Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x >> >> Hey, >> >> I had the same problem a time ago. Just add following >> jboss-deployment-structure.xml into META-INF of the EAR: >> >> <?xml version="1.0" encoding="UTF-8"?> >> <jboss-deployment-structure> >> <!-- Make sub deployments isolated by default, so they cannot see each >>others >> classes without a Class-Path entry --> >> <ear-subdeployments-isolated>true</ear-subdeployments-isolated> >> <!-- This corresponds to the top level deployment. For a war this is the >> war's module, for an ear --> >> <!-- This is the top level ear module, which contains all the classes in >> the EAR's lib folder --> >> <deployment> >> <!-- This allows you to define additional dependencies, it is the >>same >> as using the Dependencies: manifest attribute --> >> <dependencies> >> <module name="org.w3c.css.sac" /> >> <module name="net.sourceforge.cssparser" /> >> <module name="com.sun.jsf-impl" /> >> <module name="javax.api" /> >> <module name="javax.faces.api" /> >> <module name="javax.xml.bind.api" /> >> <module name="javax.xml.jaxp-provider" /> >> <module name="com.google.guava" /> >> </dependencies> >> </deployment> >> </jboss-deployment-structure> >> >> Am 19.03.2013 16:34, schrieb Adrian Gonzalez: >>> Hello, >>> >>> This is a follow up on >>> http://mail-archives.apache.org/mod_mbox/myfaces-users/201212.mbox/%3c1354617133.46780.yahoomail...@web172404.mail.ir2.yahoo.com%3E. >>> >>> @ViewAccessScoped is not working when deploying an EAR on JBoss 7.1.0 >>> (tested it with 7.1.3 same result). >>> If I deploy only a war, it works. >>> Sample project is here [1]. >>> >>> I used the debugguer and found that when using and EAR : >>> * the classloader obtained in PhaseListenerExtension#addPhaseListener >>>is the EAR classloader >>> ModuleClassLoader for Module >>>"deployment.viewaccessscoped-ear.ear:main" from Service Module Loader >>> * the classloader obtained in >>>consumePhaseListeners#consumePhaseListeners() is the WAR classloader >>> ModuleClassLoader for Module >>>"deployment.viewaccessscoped-ear.ear.viewaccessscoped-web.war:main" from >>>Service Module Loader >>> >>> This means that phaselisteners annotated with @JsfPhaseListener are not >>> executed. >>> >>> The following phaselisteners are not registered with the war classloader >>> when using an EAR : >>> * class >>>org.apache.myfaces.extensions.cdi.jsf.impl.config.view.PhasesLifecycleCallbackPhaseListener >>> * class >>>org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecyclePhaseListener >>> >>> Thanks for the help ! >>> >>> [1] Sample project here : >>> https://github.com/gonzalad/codi-ear-viewaccessscoped >>> To reproduce it, >>> 1. Testing the war >>> a. add the war on JBoss >>> b. http://localhost:8080/viewaccessscoped-web/test.faces >>> you'll see on sysout that CODI ViewAccessScoped bean has been >>>instantiated >>> 16:24:52,778 INFO [stdout] (http--0.0.0.0-8080-1) @PostConstruct >>> c. click on first link. >>> you should see nothing on sysout (this means the previous bean >>>instance is reused) >>> 1. Testing the ear - incorrect behaviour >>> a. add the ear on JBoss (remove the previous war) >>> b. http://localhost:8080/viewaccessscoped-web/test.faces >>> you'll see on sysout that CODI ViewAccessScoped bean has been >>>instantiated >>> 16:22:49,186 INFO [stdout] (http--0.0.0.0-8080-1) @PostConstruct >>> c. click on first link. >>> you'll see on sysout that previous CODI ViewAccessScoped instance >>>has been destroyed and a new one is created. >>> 16:23:24,389 INFO [stdout] (http--0.0.0.0-8080-1) @PreDestroy >>> 16:23:24,389 INFO [stdout] (http--0.0.0.0-8080-1) @PostConstruct >>>
