myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Gonzalez <>
Subject Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
Date Tue, 19 Mar 2013 21:51:08 GMT
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

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
 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 <>
À : MyFaces Discussion <>; Adrian Gonzalez <>

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
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 <>:
> 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 <>
> À :
> 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 <>
>> À :
>> 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
>>          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
>>          the EAR's lib folder -->
>>      <deployment>
>>          <!-- This allows you to define additional dependencies, it is the
>>              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="" />
>>          </dependencies>
>>      </deployment>
>> </jboss-deployment-structure>
>> Am 19.03.2013 16:34, schrieb Adrian Gonzalez:
>>> Hello,
>>> This is a follow up on
>>> @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 :
>>> 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-- @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-- @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-- @PreDestroy
>>>          16:23:24,389 INFO  [stdout] (http-- @PostConstruct
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message