myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Forveille <>
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

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


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
> 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
> 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 <>:
>>> 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 <>:
>>>> 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 <>
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(
>>>> at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.handle(
>>>> at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(
>>>> at org.apache.myfaces.lifecycle.LifecycleImpl.execute(
>>>> at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.execute(
>>>> at javax.faces.webapp.FacesServlet.service(
>>>> [truncated]
>>>> Caused by: java.lang.NullPointerException
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecycleBroadcaster.broadcastBeforeEvent(
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecyclePhaseListener.beforePhase(
>>>> at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(
>>>> at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(
>>>> ... 29 more
>>>> [10/12/12 11:04:34:639 EST] 000000e3 servlet       E
>>>> 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(
>>>> at javassist.util.proxy.ProxyFactory.createClass2(
>>>> at javassist.util.proxy.ProxyFactory.createClass1(
>>>> at javassist.util.proxy.ProxyFactory.createClass(
>>>> at org.apache.webbeans.util.SecurityUtil$
>>>> at
>>>> at org.apache.webbeans.util.SecurityUtil.doPrivilegedCreateClass(
>>>> at org.apache.webbeans.proxy.JavassistProxyFactory.getProxyClass(
>>>> at org.apache.webbeans.proxy.JavassistProxyFactory.createNormalScopedBeanProxy(
>>>> at org.apache.webbeans.container.BeanManagerImpl.getReference(
>>>> at
>>>> at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(
>>>> at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(
>>>> at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(
>>>> at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(
>>>> at org.apache.myfaces.extensions.cdi.jsf.impl.util.RequestCache.getBeanEntryFactory(
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.GroupedConversationContext.resolveBeanEntryFactory(
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.core.impl.scope.conversation.AbstractGroupedConversationContext.create(
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.core.impl.scope.conversation.ConversationContextAdapter.get(
>>>> at org.apache.webbeans.context.CustomContextImpl.get(
>>>> at org.apache.webbeans.context.CustomPassivatingContextImpl.get(
>>>> at 
>>>> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(
>>>> at org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(
>>>> at 
>>>> org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry_$$_javassist_50.broadcastRenderedViewId(ViewAccessConversationExpirationEvaluatorRegistry_$$
>>>> at org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(
>>>> at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(
>>>> [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(
>>>> at javassist.util.proxy.ProxyFactory.createClass3(
>>>> ... 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(
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>>> at java.lang.reflect.Method.invoke(
>>>> at javassist.util.proxy.FactoryHelper.toClass2(
>>>> at javassist.util.proxy.FactoryHelper.toClass(
>>>> ... 53 more

View raw message