Hi Christian, Thanks for the update. I'm also testing on JBoss 7.1.0.Final. I've modified [1] with your remarks (except dependentWarExcludes which is deprecated - I don't use overlays for now).
Still no luck, I've got the following sysout when clicking on first link of page http://localhost:8080/viewaccessscoped-web/test.faces. 09:47:35,644 INFO [stdout] (http--0.0.0.0-8080-1) @PreDestroy 09:47:35,644 INFO [stdout] (http--0.0.0.0-8080-1) @PostConstruct So ViewAccessScoped bean is reinstantiated. I've tested it with both m2e-wtp, and packaging/deploying by hand (mvn clean package). Thanks very much for your help on this topic ! [1] https://github.com/gonzalad/codi-ear-viewaccessscoped/tree/ear ----- Mail original ----- De : Christian Beikov <christian.bei...@gmail.com> À : users@myfaces.apache.org Cc : Envoyé le : Mercredi 20 mars 2013 3h07 Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x I just tested your example application. First of all you need to add Faces Servlet to web.xml, otherwise JSF won't be loaded. Next you should also put the myfaces extcdi jar into EAR/lib as suggested by using the following maven config for the EAR Plugin: <configuration> <defaultLibBundleDir>lib</defaultLibBundleDir> <defaultJavaBundleDir>lib</defaultJavaBundleDir> <skinnyWars>true</skinnyWars> <version>6</version> </configuration> The addClasspath option in the war plugin is not necessary then. You should also consider using dependentWarExcludes in the war plugin config so you can also exclude the jar from overlay projects. Tested with JBoss AS 7.1.0 Final Mit freundlichen Grüßen, ------------------------------------------------------------------------ *Christian Beikov* Am 19.03.2013 22:51, schrieb Adrian Gonzalez: > 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 >>>>
