myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Beikov <christian.bei...@gmail.com>
Subject Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
Date Wed, 20 Mar 2013 13:44:53 GMT
Also tested it, I can confirm that the described behavior occurs.
By the way, after the second postback it seems to work.
I get an exception in JBoss log about the usage of a TCCL.

Sorry but here ends my knowledge, I was thinking that it worked. 
Hopefully someone one the list can help on this?

Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 20.03.2013 10:04, schrieb Adrian Gonzalez:
> 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.beikov@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.titou10@gmail.com>
>> À : MyFaces Discussion <users@myfaces.apache.org>; Adrian Gonzalez <adr_gonzalez@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_gonzalez@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.beikov@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.beikov@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.YahooMailNeo@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
>>>>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message