Sorry I mixed up your 3 emails a bit. Answers inline.
Am 13.12.2012 00:01, schrieb Denis Forveille:
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..
If you don't use "open session/entitymanager/connection in view" the
"patterns" I tried to describe are not so different from what I
understand about yours now.
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)
Your Managers are all stateless then, did I get that right?
If so, this is what I meant by using something like application scope,
singleton or stateless so that's fine then.
- "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)
What I don't get is why you need SFSBs for your controllers. Why not
making them simple POJOs? Also in my opinion, letting the controllers
access the db directly is no good idea. Why not put these data access
methods into your managers or so?
- "Managers" are only accessed from Controlers
Good.
- some POJOs (Usually conversation scoped to handle data used by many
pages in a conversation)
That's nice too.
- and detached entities directly display in the presentation layer..
so you don't use "open session/entitymanager/connection in view" right? :D
Sean 2 automatically discard the SFSB when the conversation ends
Same for Codi conversation and the default CDI conversation, isn't it?
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
Maybe a light dao layer or so might be handy in case you want to
abstract away your persistence technology. At least you shouldn't query
the DB directly in the UI Layer IMO.
I would love to see what Gavin King would answer to you on this..lol
About what exactly?
Again I don't follow you in your answer (Usage of ConversationScope
etc..) vs my initial post
You wrote that it worked with the CDI conversation scope but not with
the codi conversation scope.
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 <[email protected]>:
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 <[email protected]>:
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
<[email protected]> 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
