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