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 >
