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
>>

Reply via email to