myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Forveille <denis.forvei...@gmail.com>
Subject Re: [CODI] CODI v1.0.5 + WebSphere v8.5.0.1 problem
Date Wed, 12 Dec 2012 23:01:32 GMT
This is the pattern defined by Seam 2 all the way and the assumption on which it has been designed
on first place...

I don't really understand your points, mostly I think because it seems you describe patterns
we don't use..

At high level, our classes are organized like this :
- "Managers" classes in SLSB  ("Event/ Scope/stateless..). Manager provides generic function
tied to a "business domain" (Customer, 
orders) and deal with the database common access (get a "Customer" list) or service (communicate
with external systems)
- "Controllers" classes in SFSB either in View/Page or Conversation scope. A controller is
basically a JSF backing bean, handling 
one or many (wizards) views. They can also access the databse (Very if this customer already
exist or can delegate this to a manager)
- "Managers" are only accessed from Controlers
- some POJOs (Usually conversation scoped to handle data used by many pages in a conversation)
- and detached entities directly display in the presentation layer..

Sean 2 automatically discard the SFSB when the conversation ends

All our apps are architectured like this and this is great ! This works very well this way
our apps are very clear and concise wit 
the controler/manager separation. No "dao" no transport layers or "extra wiring" structures

I would love to see what Gavin King would answer to you on this..lol

Again I don't follow you in your answer (Usage of ConversationScope etc..) vs my initial post

Cheers

Le 2012-12-12 17:28, Christian Beikov a écrit :
> Why do you want to scope something that is stateless? I mean stateless already is some
kind of scope, like pooled application 
> scoped. Since you don't want to have a state in a stateless bean, why using a scope that
will cause destroying the instance after 
> conversation end?
>
> You should maybe consider using POJO beans scoped with whatever you want for your frontend(backing
beans for views) and use 
> something like application scope, singleton or stateless for your beans in the service
layer.
>
> When this is about transaction handling, I can only recommend you to reconsider defining
transactions in a service level but not 
> in the UI layer. Transactions should also be as short as possible!
>
> Or is it maybe about entity managers being conversation scoped within the bean instances?
In my opinion this is a bad and error 
> prone practice. Keep your stuff as stateless as possible and use transaction scope.
>
> If you have no other choice than keeping on using these scopes for your beans you will
probably have to tweak the class loader 
> configuration as you already mentioned to make it working or consider using the javax.context.ConversationScoped
annotation. 
> Another option might also be to move the beans into the web application, but I am not
sure if that will work 100% and I also 
> discourage that.
>
> Mit freundlichen Grüßen,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 12.12.2012 22:39, schrieb Denis Forveille:
>> Bad news: In fact, in practice this does not work for us.
>>
>> We are moving from seam 2/jsf1.2  to cdi/jsf2.0/codi and we use SLSB
>> (Stateless Session Beans) as JSF backing beans.
>> Those SLSB may be of scope "ViewScope" (= Seam 2 "PageScope") and need
>> to be injected at leats "FacesContext" (to send back messages to the
>> browser)
>>
>> So if we want to use the "@ViewAccessScoped" or "@ViewScope" and or
>> other JSF artefacts (FacesMessages etc.) produced by CODI in our
>> SLSBs, we need to have the codi-jsf jars visible in the classpath of
>> the EJB module.
>>
>> The initial classloader problem with the jsf CODI jars in ear/lib
>> comes because the JSF lifecycle uses JSF CODI classes loaded by
>> another classloader than the one used by the WAR
>>
>> So if we want to setup our application as describes above with CODI,
>> we have those options left:
>> - configure the application classloader to "WAR classloader policy" to
>> "Application/single" instead of "Module/multiple" and put the CODI
>> jars in ear/lib and keep PARENT_FIRST for both app and war. Nothing in
>> MANIFEST files (Tested OK.)
>> - configure the application classloader to "WAR classloader policy" to
>> "Application/single" instead of "Module/multiple" and put the JSF CODI
>> jars at the root of the ear, put the rest of the CODI modules in
>> ear/lib, keep PARENT_FIRST for both, add manifest entries for the WAR
>> and EJB modules to the 2 CODI jsf jars (Tested OK)
>>
>> in brief we need to configure WebSphere to use only one classloader
>> for the whole modules of the application  (ejb+jpa+war+dependent jars)
>>
>>
>> 2012/12/10 Denis Forveille <denis.forveille@gmail.com>:
>>> Thanks Thomas for the pointer
>>> Yes it is a classloader problem
>>> After lots of tries I finally managed to have it working
>>> (FI our EAR projects are all split into a JPA module, an EJB module
>>> and a WAR module)
>>> How I did it:
>>> - in ear/lib, define codi (api+impl) and message-module (api+impl)
>>> - in web/WEB-INF/lib define codi-jsf20-module (api+impl)
>>> - put nothing in web/META-INF/MANIFEST.MF
>>> - set PARENT_FIRST for both ear and web modules
>>>
>>> I will continue my tests with a more realistic application, hoping
>>> that we will not use any codi "features" in our EJB module that will
>>> need to "use" something from the codi-jsf20-module jars.
>>>
>>> Thx
>>>
>>>
>>> 2012/12/10 Thomas Herzog <t.herzog@curecomp.com>:
>>>> We facwd the problem that codi and myfaces interffered together and myfaces
could not start.
>>>>
>>>> We did the following, maybe it helps:
>>>>
>>>> 1. Manifest entry to codi in webapp.
>>>> 2. codi placed in ear/lib or web-inf/lib
>>>> 3. With two webapps in the application.xml 'start in order'
>>>>
>>>> Websphere is always a tricky thing :(
>>>> The manifest entry was the most important thing.
>>>>
>>>> Send via Samsung Galaxy S2Denis Forveille <denis.forveille@gmail.com>
hat geschrieben:Hello
>>>>
>>>> I'm trying to use CODI v1.0.5 in WebSphere v8.5.0.1 with a very simple
>>>> application, Even if the applications deploys and starts well, on the
>>>> first page I receive a NPE
>>>> It seems to be caused by some javassist exception while creating a proxy
..
>>>> Internally, WAS v8.5 uses MyFaces and OpenWebBeans ,and JDK 1.7
>>>>
>>>>
>>>> Anyone has success using CODI in WAS v8.5?
>>>>
>>>> The stack trace is very long ... Here are some pieces of it
>>>>
>>>> [10/12/12 11:04:34:639 EST] 000000e3 ErrorPageWrit E  An exception occurred
>>>> javax.faces.FacesException:
>>>> java.lang.NullPointerException
>>>> at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
>>>> at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
>>>> at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:191)
>>>> at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
>>>> at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.execute(CodiLifecycleWrapper.java:95)
>>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
>>>> [truncated]
>>>> Caused by: java.lang.NullPointerException
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecycleBroadcaster.broadcastBeforeEvent(JsfRequestLifecycleBroadcaster.java:58)
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecyclePhaseListener.beforePhase(JsfRequestLifecyclePhaseListener.java:56)
>>>> at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:76)
>>>> at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:159)
>>>> ... 29 more
>>>> [10/12/12 11:04:34:639 EST] 000000e3 servlet       E
>>>> com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: An
>>>> exception was thrown by one of the service methods of the servlet
>>>> [Faces Servlet] in application [CODITest]. Exception created :
>>>> [java.lang.RuntimeException: by java.lang.IllegalAccessError:
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultBeanEntryFactory
>>>> at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:509)
>>>> at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:486)
>>>> at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:422)
>>>> at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:394)
>>>> at org.apache.webbeans.util.SecurityUtil$PrivilegedActionForProxyFactory.run(SecurityUtil.java:301)
>>>> at java.security.AccessController.doPrivileged(AccessController.java:229)
>>>> at org.apache.webbeans.util.SecurityUtil.doPrivilegedCreateClass(SecurityUtil.java:184)
>>>> at org.apache.webbeans.proxy.JavassistProxyFactory.getProxyClass(JavassistProxyFactory.java:429)
>>>> at org.apache.webbeans.proxy.JavassistProxyFactory.createNormalScopedBeanProxy(JavassistProxyFactory.java:213)
>>>> at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:870)
>>>> at com.ibm.ws.webbeans.services.IBMBeanManagerImpl.getReference(IBMBeanManagerImpl.java:204)
>>>> at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215)
>>>> at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179)
>>>> at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139)
>>>> at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:124)
>>>> at org.apache.myfaces.extensions.cdi.jsf.impl.util.RequestCache.getBeanEntryFactory(RequestCache.java:106)
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.GroupedConversationContext.resolveBeanEntryFactory(GroupedConversationContext.java:162)
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.core.impl.scope.conversation.AbstractGroupedConversationContext.create(AbstractGroupedConversationContext.java:92)
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.core.impl.scope.conversation.ConversationContextAdapter.get(ConversationContextAdapter.java:81)
>>>> at org.apache.webbeans.context.CustomContextImpl.get(CustomContextImpl.java:43)
>>>> at org.apache.webbeans.context.CustomPassivatingContextImpl.get(CustomPassivatingContextImpl.java:41)
>>>> at 
>>>> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:135)
>>>> at org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:95)
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry_$$_javassist_50.broadcastRenderedViewId(ViewAccessConversationExpirationEvaluatorRegistry_$$_javassist_50.java)
>>>> at org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:680)
>>>> at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128)
>>>>
>>>> [truncated]
>>>>
>>>> Caused by: javassist.CannotCompileException: by
>>>> java.lang.IllegalAccessError:
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultBeanEntryFactory
>>>> at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:169)
>>>> at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:501)
>>>> ... 52 more
>>>> Caused by: java.lang.IllegalAccessError:
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultBeanEntryFactory
>>>> at java.lang.ClassLoader.defineClassImpl(Native Method)
>>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:286)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>>>> at java.lang.reflect.Method.invoke(Method.java:613)
>>>> at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:181)
>>>> at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:163)
>>>> ... 53 more
>
>


Mime
View raw message