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:45:24 GMT

Le 2012-12-12 18:27, Christian Beikov a écrit :
> 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.
As stated in my previous post, yes. Application or Singleton are not that OK because you have
to manage concurrent acess to methods 
in thos beans. SLSB do that  natively for us, and this very fast (SLSB are pooled..)
>> - "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?
Because the EJB Container manage the transaction for us and SFSB are the perfect construction
for "stateful" data, assigned to one 
"client". So the controleur can acces many methods in different "managers" in the same transaction
natively (eg without extra 
construction or CODI/@Transaction annotations for example) and this even if the SFSB does
not directly access the DB..
With EJB 3.1, EJBs are "transparent" (no interfaces, no super class, no extra constructions),
the only difference with a POJO is the 
@Stateful annotation and you benefit from the EJB container features)
>> - "Managers" are only accessed from Controlers
> Good.
>> - some POJOs (Usually conversation scoped to handle data used by many pages in a
> 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?
Yes (I, learning CDI now, trying to migrate our Seam 2 apps..)
>> 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"
> 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.
No need for that for us. KISS..Entities, when detached (after been "loaded" in a  manager)
are used like any other POJOs.. 
(almost)No difference
>> I would love to see what Gavin King would answer to you on
> 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
No I understand
This is another post, Please comment in the other 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
>>> 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)
> <truncated>

View raw message