You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shale.apache.org by numpsy beelzebub <nu...@gmail.com> on 2006/09/11 19:46:47 UTC
shale session vs ejb 3.0 stateful session beans / jboss seam
hello,
i want to developed an application using shale and ejb 3.0 (within container
jboss).
primary i used stateless session beans for access to the entity beans -
persistenz-layer is ok and how to work with it
as session i will declare a managed bean with an application scope "session"
and save my data in it.
i thought it is the fastest and easiest way, but in comparing to stateful
session beans it is not the only possible solution.
in addition to this a few questions:
1. i'm fit in clay and know how to access normally ejb 3.0 from shale's
application-logic (building context etc)
but how is it possible to access stateful session bean from view etc.
(normally i have direct access, if it is declared as managed bean)
2. i have to initalize context for access ejb, so i thought maybe declare a
interface as managed bean which gives access to stateful session bean
does exist a method in shale except init(), that would be called for
every request, so that i can initialize my access-context
3. if i want to use stateful-session ejb 3.0 - how is it possible out from
session to define when access of specific user ends.
maybe saving access to stateful-session ejb 3.0 into some kind of state
bean in shale declared as managed bean with session scope -> but if i do it
so it seems strange
i save access to a ejb, but i could save the data also direct
4. generally problem - session in shale is only a javabean with the session
scope
<-> stateful session bean is server side component (differences are
clear, but what is best to use - where lies advantages)
it is also a problem because jboss seam gives possibilities for my problems
http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
maybe i need some impressions of developer with some kind of more
experience, including th developers of shale
thx so much
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by stephan opitz <st...@gmail.com>.
try {
context = new InitialContext();
categoriesFacade = (CategoriesFacade) context
.lookup(ShaleTest
+ CategoriesImp.class/local);
} catch (NamingException e) {
e.printStackTrace();
}
in this way it works... strange but maybe it is so... if my
datafactory is in the ejb web-project shale tiger seems not to work ->
because will be included the ejb.jar -> faces-config.xml solves
problem to access the managed bean, but only with jndi- look-up in get
makes no fun, in ejb spec:
http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=javaee-5.0-fr-spec-oth-JSpec&SiteId=JSC&TransactionId=noreg
it is so easy @EJB Cart ...
maybe should shale built a more easy bridge
2006/9/15, stephan opitz <st...@gmail.com>:
> craig...
>
> the possibility with indirect works only if i do a jndi lookup...
>
> @Bean(name = "dataFactory", scope = Scope.SESSION)
> public class DataFactory {
>
> @EJB
> private CategoriesLangFacade categoriesLangFacade;
>
> public CategoriesLangFacade getCategoriesLangFacade() {
>
> return categoriesLangFacade;
> }
>
> }
>
> solves categoriesLangFacade as null;
>
> without @EJB and jndi-lookup in the getCategoriesLangFacade it works
> under jbos s4.04ga - but why resource injection does not work ?
>
> ########################################
>
> public interface CategoriesLangFacade {
>
> public CategoriesLang findById(long categoriesLangId, long languageId);
>
> }
>
> #######################################
>
> @Local({CategoriesLangFacade.class})
> @Stateless
> public class CategoriesLangImp implements CategoriesLangFacade {
>
> @PersistenceContext(unitName = "ShaleTestPU")
> private EntityManager em;
>
> public static final String Remote = CategoriesLangImp.class
> .getSimpleName()
> + "/remote";
>
> public static final String Local = CategoriesLangImp.class
> .getSimpleName()
> + "/local";
>
> public CategoriesLang findById(long categoriesLangId, long languageId) {
> ...
>
>
> any solution or idea?
>
>
>
> 2006/9/13, stephan opitz <st...@gmail.com>:
> > i tried comparable, but without success.
> >
> > anyone who can helps?
> >
> > 2006/9/12, numpsy beelzebub <nu...@gmail.com>:
> > > thx craig,
> > >
> > >
> > > > It is possible to access the stateful session bean *indirectly*, if you
> > > > declare it in a managed bean and then provide a public getter. The
> > > simplest
> > > > way to do this is to leverage the resource injection capabilities of a
> > > Java
> > > > EE 5 container, so you might have something like this:
> > >
> > > > @EJB
> > > > private MySessionBean mySessionBean;
> > >
> > > > public MySessionBean getMySessionBean() { return this.mySessionBean; }
> > >
> > > > and you can then use a binding expression like "#{foo.mySessionBean.bar}"
> > > > where "foo" is the name of the managed bean containing the above
> > > > declaration, and "bar" is a property on the session bean itself.
> > >
> > > > If you are not running inside an EE 5 app server, you'll have to do the
> > > > usual sort of JNDI lookup to get a reference to the stateful session bean
> > > > instead. If you're using Shale's ViewController capabilities, the init()
> > > > method would be a good place to do that so the bean will be available to
> > > > other event handlers (and rendering) associated with this bean.
> > >
> > > can't follow exactly
> > > now i use jboss and ask for my entity beans from shale model objects
> > > try {
> > > Context context = new InitialContext();
> > > contactNotesFassade = (ContactNotesFassade) context
> > > .lookup(Constants.ProjectNameSeparator
> > > + ContactNotesFassadeImp.Local);
> > > } catch (NamingException e) {
> > > messageLang.setFacesMessage("error.ejb");
> > > }
> > > can image how this @EJB works with shale and how i can have easy access in
> > > clay etc...
> > > 1. i declare a stateful session bean mySessionBean mySessionBean
> > > ejb-web-project part
> > > 2. an interface with local - here the part with your @EJB code
> > > 3. access to interface in modelbeans of shale - as you told in init()-method
> > >
> > > how i can have access in clay to this away stateful ejb
> > >
> > >
> > > :-/
> > >
> > > 2006/9/11, Craig McClanahan <cr...@apache.org>:
> > >
> > > > On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > >
> > > > > hello,
> > > > >
> > > > > i want to developed an application using shale and ejb 3.0 (within
> > > > > container
> > > > > jboss).
> > > > > primary i used stateless session beans for access to the entity beans -
> > > > > persistenz-layer is ok and how to work with it
> > > > >
> > > > > as session i will declare a managed bean with an application scope
> > > > > "session"
> > > > > and save my data in it.
> > > > > i thought it is the fastest and easiest way, but in comparing to
> > > > stateful
> > > > > session beans it is not the only possible solution.
> > > > >
> > > > > in addition to this a few questions:
> > > > >
> > > > > 1. i'm fit in clay and know how to access normally ejb 3.0 from shale's
> > > > > application-logic (building context etc)
> > > > > but how is it possible to access stateful session bean from view etc.
> > > > > (normally i have direct access, if it is declared as managed bean)
> > > >
> > > >
> > > > It is possible to access the stateful session bean *indirectly*, if you
> > > > declare it in a managed bean and then provide a public getter. The
> > > > simplest
> > > > way to do this is to leverage the resource injection capabilities of a
> > > > Java
> > > > EE 5 container, so you might have something like this:
> > > >
> > > > @EJB
> > > > private MySessionBean mySessionBean;
> > > >
> > > > public MySessionBean getMySessionBean() { return this.mySessionBean; }
> > > >
> > > > and you can then use a binding expression like "#{foo.mySessionBean.bar}"
> > > > where "foo" is the name of the managed bean containing the above
> > > > declaration, and "bar" is a property on the session bean itself.
> > > >
> > > > If you are not running inside an EE 5 app server, you'll have to do the
> > > > usual sort of JNDI lookup to get a reference to the stateful session bean
> > > > instead. If you're using Shale's ViewController capabilities, the init()
> > > > method would be a good place to do that so the bean will be available to
> > > > other event handlers (and rendering) associated with this bean.
> > > >
> > > >
> > > > 2. i have to initalize context for access ejb, so i thought maybe declare
> > > > a
> > > > > interface as managed bean which gives access to stateful session bean
> > > > > does exist a method in shale except init(), that would be called for
> > > > > every request, so that i can initialize my access-context
> > > >
> > > >
> > > >
> > > > Why do you need a method other than init()? That is exactly what it is
> > > > for.
> > > >
> > > >
> > > > 3. if i want to use stateful-session ejb 3.0 - how is it possible out from
> > > > > session to define when access of specific user ends.
> > > > > maybe saving access to stateful-session ejb 3.0 into some kind of
> > > > state
> > > > > bean in shale declared as managed bean with session scope -> but if i do
> > > > > it
> > > > > so it seems strange
> > > >
> > > >
> > > > My understanding of the typical scenario for Stateful session beans is
> > > > that,
> > > > when you want the user's access to end (i.e. they log out or something),
> > > > then you'll call the remove method o the stateful session bean to make it
> > > > go
> > > > away.
> > > >
> > > >
> > > > i save access to a ejb, but i could save the data also direct
> > > > > 4. generally problem - session in shale is only a javabean with the
> > > > > session
> > > > > scope
> > > > > <-> stateful session bean is server side component (differences are
> > > > > clear, but what is best to use - where lies advantages)
> > > > >
> > > > > it is also a problem because jboss seam gives possibilities for my
> > > > > problems
> > > > > http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
> > > > >
> > > > > maybe i need some impressions of developer with some kind of more
> > > > > experience, including th developers of shale
> > > >
> > > >
> > > > Seam encourages you (but does not require you) to use a stateful session
> > > > bean (SFSB) in a manner fairly similar to using a session scoped backing
> > > > bean in a regular JSF application. If you're using an SFSB for your
> > > > business logic anyway, this can save you writing one class (the typical
> > > > sort
> > > > of backing bean) that primarily serves as an adapter role. The tradeoff
> > > > is
> > > > that you'll typically end up tying the SFSB class to web tier APIs instead
> > > > of being able to make it independent.
> > > >
> > > > A couple of other considerations:
> > > >
> > > > * If you're using Shale view controllers, that only works for request
> > > > scope
> > > > beans,
> > > > so you won't be able to make your SFSB class "implements ViewController"
> > > > and get those sorts of event callbacks.
> > > >
> > > > * A SFSB is automatically a transactional resource (depending on what
> > > > annotations
> > > > or XML metadata settings you use to configure it), so you don't have to
> > > > worry
> > > > about explicitly committing transactions (although you might still need to
> > > > roll back
> > > > if you're partway through an update and you need to abort it). You can
> > > > access
> > > > things like JPA entity classes directly from a JSF backing bean, but you
> > > > need to
> > > > manage transactions yourself.
> > > >
> > > > * A SFSB can only be accessed by one thread at a time, so you might find
> > > > yourself
> > > > in a situation where the locking that enforces this can cause you
> > > > performance issues.
> > > > A classic case is where you've got lots of AJAX-ish calls coming in from
> > > > the client,
> > > > such that there will be multiple requests (on different threads) to the
> > > > same session bean
> > > > at the same time. With session scoped backing beans, the calls happen
> > > > simultaneously
> > > > (but, of course, that means you also need to code your methods in a
> > > > threadsafe manner).
> > > > With an SFSB you don't have to worry about coding for simultaneous access,
> > > > but you do
> > > > need to worry about the performance impact of the locking.
> > > >
> > > > Craig
> > > >
> > > >
> > > >
> > > > thx so much
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by Craig McClanahan <cr...@apache.org>.
On 9/15/06, stephan opitz <st...@gmail.com> wrote:
>
> as i reviewed example from jboss:
> http://docs.jboss.org/ejb3/app-server/tutorial/injection/injection.html
>
> To facilitate test driven development, the EJB 3.0 specification
> allows you to use annotations to inject dependencies through
> annotations on fields or setter methods. Instead of complicated XML
> ejb-refs or resource refs, you can use the @EJB and @Resource
> annotations to set the value of a field or to call a setter method
> within your session bean with anything registered within JNDI.
> You can use the @EJB annotation to inject EJB references and @Resource
> to access datasources.
>
> in conclusion that ejb incejtion only works if registration is within
> jndi, so beans under registred ejb stateful or stateless beans should
> work without problems as managed bean i gave up
Three comments:
* Did you remove the @Bean annotation as I suggested?
Leaving it there is ***guaranteed*** to make injectino fail.
* I know for a fact that injecting things works on a certified Java EE 5
server (Glassfish).
See the shale-mailreader-jpa example, and note that the Logic bean gets
its
EntityManagerFactory bean injected, without any explicit registration of
JNDI
resource.
* Why are you expecting Java EE 5 compliant behavior from a
container that is not yet Java EE 5 compliant? If there's an issue
here, it seems likely to be with JBoss, if they claim to do
the resource injection but do not do so.
Craig
2006/9/15, stephan opitz <st...@gmail.com>:
> > it will created by jsf - i see that tiger annotation does not work at
> this point
> >
> > it seems my problem lies in implementation if the injection
> >
> > public class DataFactory {
> >
> > @EJB
> > private CategoriesLangFacade categoriesLangFacade;
> >
> > public CategoriesLangFacade getCategoriesLangFacade() {
> >
> > return categoriesLangFacade;
> > }
> >
> > }
> >
> >
> /////////////////////////////////////////////////////////////////////////////
> >
> > @Local
> > public interface CategoriesLangFacade {
> >
> > public CategoriesLang findById(long categoriesLangId, long
> languageId);
> >
> > }
> >
> > #######################################
> >
> > @Stateless
> > public class CategoriesLangImp implements CategoriesLangFacade {
> >
> > @PersistenceContext(unitName = "ShaleTestPU")
> > private EntityManager em;
> >
> > public static final String Remote = CategoriesLangImp.class
> > .getSimpleName()
> > + "/remote";
> >
> > public static final String Local = CategoriesLangImp.class
> > .getSimpleName()
> > + "/local";
> >
> > public CategoriesLang findById(long categoriesLangId, long
> languageId) {
> > ...
> > }
> >
> > }
> >
> > but this is the way how to
> >
> > an @local interface, an stateless ejb and DataFactory which should
> > create injection
> >
> >
> >
> > 2006/9/15, Craig McClanahan <cr...@apache.org>:
> > > On 9/15/06, stephan opitz <st...@gmail.com> wrote:
> > > >
> > > > does indeed work - i tried under jboss so many different versions of
> > > > implementation...
> > > >
> > > > craig i know your mailreader jpa based on glassfish...
> > >
> > >
> > > That is true, but I had to follow the advice I gave you ... I had to
> make
> > > the backing beans that receive injection into standard JSF managed
> beans,
> > > not using the Shale Tiger @Bean annotation.
> > >
> > > maybe it is because of jboss ejb implementation?
> > > >
> > > > my managed bean "datafactory" is in the ejb-jar and defined in
> > > > faces-config.xml
> > > > i have access from any shale model class
> > >
> > >
> > > Be sure to take @Bean off as well ... if you leave it there, the Tiger
> > > extensions will be creating the bean, instead of JSF itself, so the
> > > injections will not occur.
> > >
> > > Craig
> > >
> > > if i debug i see
> > > >
> > > > @Resource
> > > > SessionContext sc;
> > > > is null
> > > >
> > > > maybe i have a generall problem with the jboss
> > > >
> > > > does exist any tiger annotation for the postback value?
> > > >
> > > > 5, Craig McClanahan <cr...@apache.org>:
> > > > > On 9/15/06, stephan opitz <st...@gmail.com> wrote:
> > > > > >
> > > > > > craig...
> > > > > >
> > > > > > the possibility with indirect works only if i do a jndi
> lookup...
> > > > > >
> > > > > > @Bean(name = "dataFactory", scope = Scope.SESSION)
> > > > > > public class DataFactory {
> > > > > >
> > > > > > @EJB
> > > > > > private CategoriesLangFacade categoriesLangFacade;
> > > > > >
> > > > > > public CategoriesLangFacade getCategoriesLangFacade() {
> > > > > >
> > > > > > return categoriesLangFacade;
> > > > > > }
> > > > > >
> > > > > > }
> > > > > >
> > > > > > solves categoriesLangFacade as null;
> > > > > >
> > > > > > without @EJB and jndi-lookup in the getCategoriesLangFacade it
> works
> > > > > > under jbos s4.04ga - but why resource injection does not work ?
> > > > >
> > > > >
> > > > > Container resource injection only works on what the *container*
> thinks
> > > > is a
> > > > > JSF managed bean that *it* created. The Tiger Extensions stuff
> (@Bean)
> > > > > intercepts the normal process and creates the bean itself, and
> can't do
> > > > any
> > > > > injections. If you made this a normal managed bean (configured in
> > > > > faces-config.xml), you'll find that the resource injection does
> indeed
> > > > work.
> > > > >
> > > > > It would be an interesting challenge to examine whether it's even
> > > > *possible*
> > > > > to fake the container's normal resource injection for stuff like
> this.
> > > > >
> > > > > Craig
> > > > >
> > > > > ########################################
> > > > > >
> > > > > > public interface CategoriesLangFacade {
> > > > > >
> > > > > > public CategoriesLang findById(long categoriesLangId,
> long
> > > > > > languageId);
> > > > > >
> > > > > > }
> > > > > >
> > > > > > #######################################
> > > > > >
> > > > > > @Local({CategoriesLangFacade.class})
> > > > > > @Stateless
> > > > > > public class CategoriesLangImp implements CategoriesLangFacade {
> > > > > >
> > > > > > @PersistenceContext(unitName = "ShaleTestPU")
> > > > > > private EntityManager em;
> > > > > >
> > > > > > public static final String Remote =
> CategoriesLangImp.class
> > > > > > .getSimpleName()
> > > > > > + "/remote";
> > > > > >
> > > > > > public static final String Local =
> CategoriesLangImp.class
> > > > > > .getSimpleName()
> > > > > > + "/local";
> > > > > >
> > > > > > public CategoriesLang findById(long categoriesLangId,
> long
> > > > > > languageId) {
> > > > > > ...
> > > > > >
> > > > > >
> > > > > > any solution or idea?
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2006/9/13, stephan opitz <st...@gmail.com>:
> > > > > > > i tried comparable, but without success.
> > > > > > >
> > > > > > > anyone who can helps?
> > > > > > >
> > > > > > > 2006/9/12, numpsy beelzebub <nu...@gmail.com>:
> > > > > > > > thx craig,
> > > > > > > >
> > > > > > > >
> > > > > > > > > It is possible to access the stateful session bean
> *indirectly*,
> > > > if
> > > > > > you
> > > > > > > > > declare it in a managed bean and then provide a public
> > > > getter. The
> > > > > > > > simplest
> > > > > > > > > way to do this is to leverage the resource injection
> > > > capabilities of
> > > > > > a
> > > > > > > > Java
> > > > > > > > > EE 5 container, so you might have something like this:
> > > > > > > >
> > > > > > > > > @EJB
> > > > > > > > > private MySessionBean mySessionBean;
> > > > > > > >
> > > > > > > > > public MySessionBean getMySessionBean() { return
> > > > > > this.mySessionBean; }
> > > > > > > >
> > > > > > > > > and you can then use a binding expression like "#{
> > > > > > foo.mySessionBean.bar}"
> > > > > > > > > where "foo" is the name of the managed bean containing the
> above
> > > > > > > > > declaration, and "bar" is a property on the session bean
> itself.
> > > > > > > >
> > > > > > > > > If you are not running inside an EE 5 app server, you'll
> have to
> > > > do
> > > > > > the
> > > > > > > > > usual sort of JNDI lookup to get a reference to the
> stateful
> > > > session
> > > > > > bean
> > > > > > > > > instead. If you're using Shale's ViewController
> capabilities,
> > > > the
> > > > > > init()
> > > > > > > > > method would be a good place to do that so the bean will
> be
> > > > > > available to
> > > > > > > > > other event handlers (and rendering) associated with this
> bean.
> > > > > > > >
> > > > > > > > can't follow exactly
> > > > > > > > now i use jboss and ask for my entity beans from shale model
> > > > objects
> > > > > > > > try {
> > > > > > > > Context context = new InitialContext();
> > > > > > > > contactNotesFassade = (ContactNotesFassade) context
> > > > > > > > .lookup(Constants.ProjectNameSeparator
> > > > > > > > + ContactNotesFassadeImp.Local);
> > > > > > > > } catch (NamingException e) {
> > > > > > > > messageLang.setFacesMessage("error.ejb");
> > > > > > > > }
> > > > > > > > can image how this @EJB works with shale and how i can have
> easy
> > > > > > access in
> > > > > > > > clay etc...
> > > > > > > > 1. i declare a stateful session bean mySessionBean
> mySessionBean
> > > > > > > > ejb-web-project part
> > > > > > > > 2. an interface with local - here the part with your @EJB
> code
> > > > > > > > 3. access to interface in modelbeans of shale - as you told
> in
> > > > > > init()-method
> > > > > > > >
> > > > > > > > how i can have access in clay to this away stateful ejb
> > > > > > > >
> > > > > > > >
> > > > > > > > :-/
> > > > > > > >
> > > > > > > > 2006/9/11, Craig McClanahan <cr...@apache.org>:
> > > > > > > >
> > > > > > > > > On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > hello,
> > > > > > > > > >
> > > > > > > > > > i want to developed an application using shale and ejb
> 3.0(within
> > > > > > > > > > container
> > > > > > > > > > jboss).
> > > > > > > > > > primary i used stateless session beans for access to the
> > > > entity
> > > > > > beans -
> > > > > > > > > > persistenz-layer is ok and how to work with it
> > > > > > > > > >
> > > > > > > > > > as session i will declare a managed bean with an
> application
> > > > scope
> > > > > > > > > > "session"
> > > > > > > > > > and save my data in it.
> > > > > > > > > > i thought it is the fastest and easiest way, but in
> comparing
> > > > to
> > > > > > > > > stateful
> > > > > > > > > > session beans it is not the only possible solution.
> > > > > > > > > >
> > > > > > > > > > in addition to this a few questions:
> > > > > > > > > >
> > > > > > > > > > 1. i'm fit in clay and know how to access normally ejb
> 3.0from
> > > > > > shale's
> > > > > > > > > > application-logic (building context etc)
> > > > > > > > > > but how is it possible to access stateful session bean
> from
> > > > view
> > > > > > etc.
> > > > > > > > > > (normally i have direct access, if it is declared as
> managed
> > > > bean)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > It is possible to access the stateful session bean
> *indirectly*,
> > > > if
> > > > > > you
> > > > > > > > > declare it in a managed bean and then provide a public
> > > > getter. The
> > > > > > > > > simplest
> > > > > > > > > way to do this is to leverage the resource injection
> > > > capabilities of
> > > > > > a
> > > > > > > > > Java
> > > > > > > > > EE 5 container, so you might have something like this:
> > > > > > > > >
> > > > > > > > > @EJB
> > > > > > > > > private MySessionBean mySessionBean;
> > > > > > > > >
> > > > > > > > > public MySessionBean getMySessionBean() { return
> > > > > > this.mySessionBean; }
> > > > > > > > >
> > > > > > > > > and you can then use a binding expression like "#{
> > > > > > foo.mySessionBean.bar}"
> > > > > > > > > where "foo" is the name of the managed bean containing the
> above
> > > > > > > > > declaration, and "bar" is a property on the session bean
> itself.
> > > > > > > > >
> > > > > > > > > If you are not running inside an EE 5 app server, you'll
> have to
> > > > do
> > > > > > the
> > > > > > > > > usual sort of JNDI lookup to get a reference to the
> stateful
> > > > session
> > > > > > bean
> > > > > > > > > instead. If you're using Shale's ViewController
> capabilities,
> > > > the
> > > > > > init()
> > > > > > > > > method would be a good place to do that so the bean will
> be
> > > > > > available to
> > > > > > > > > other event handlers (and rendering) associated with this
> bean.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2. i have to initalize context for access ejb, so i
> thought
> > > > maybe
> > > > > > declare
> > > > > > > > > a
> > > > > > > > > > interface as managed bean which gives access to stateful
> > > > session
> > > > > > bean
> > > > > > > > > > does exist a method in shale except init(), that
> would be
> > > > > > called for
> > > > > > > > > > every request, so that i can initialize my
> access-context
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Why do you need a method other than init()? That is
> exactly
> > > > what it
> > > > > > is
> > > > > > > > > for.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 3. if i want to use stateful-session ejb 3.0 - how is it
> > > > possible
> > > > > > out from
> > > > > > > > > > session to define when access of specific user ends.
> > > > > > > > > > maybe saving access to stateful-session ejb 3.0 into
> some
> > > > kind
> > > > > > of
> > > > > > > > > state
> > > > > > > > > > bean in shale declared as managed bean with session
> scope ->
> > > > but
> > > > > > if i do
> > > > > > > > > > it
> > > > > > > > > > so it seems strange
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > My understanding of the typical scenario for Stateful
> session
> > > > beans
> > > > > > is
> > > > > > > > > that,
> > > > > > > > > when you want the user's access to end (i.e. they log out
> or
> > > > > > something),
> > > > > > > > > then you'll call the remove method o the stateful session
> bean
> > > > to
> > > > > > make it
> > > > > > > > > go
> > > > > > > > > away.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > i save access to a ejb, but i could save the data also
> direct
> > > > > > > > > > 4. generally problem - session in shale is only a
> javabean
> > > > with
> > > > > > the
> > > > > > > > > > session
> > > > > > > > > > scope
> > > > > > > > > > <-> stateful session bean is server side component
> > > > > > (differences are
> > > > > > > > > > clear, but what is best to use - where lies advantages)
> > > > > > > > > >
> > > > > > > > > > it is also a problem because jboss seam gives
> possibilities
> > > > for my
> > > > > > > > > > problems
> > > > > > > > > >
> > > > http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
> > > > > > > > > >
> > > > > > > > > > maybe i need some impressions of developer with some
> kind of
> > > > more
> > > > > > > > > > experience, including th developers of shale
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Seam encourages you (but does not require you) to use a
> stateful
> > > > > > session
> > > > > > > > > bean (SFSB) in a manner fairly similar to using a session
> > > > scoped
> > > > > > backing
> > > > > > > > > bean in a regular JSF application. If you're using an
> SFSB for
> > > > your
> > > > > > > > > business logic anyway, this can save you writing one class
> (the
> > > > > > typical
> > > > > > > > > sort
> > > > > > > > > of backing bean) that primarily serves as an adapter
> role. The
> > > > > > tradeoff
> > > > > > > > > is
> > > > > > > > > that you'll typically end up tying the SFSB class to web
> tier
> > > > APIs
> > > > > > instead
> > > > > > > > > of being able to make it independent.
> > > > > > > > >
> > > > > > > > > A couple of other considerations:
> > > > > > > > >
> > > > > > > > > * If you're using Shale view controllers, that only works
> for
> > > > > > request
> > > > > > > > > scope
> > > > > > > > > beans,
> > > > > > > > > so you won't be able to make your SFSB class "implements
> > > > > > ViewController"
> > > > > > > > > and get those sorts of event callbacks.
> > > > > > > > >
> > > > > > > > > * A SFSB is automatically a transactional resource
> (depending on
> > > > > > what
> > > > > > > > > annotations
> > > > > > > > > or XML metadata settings you use to configure it), so you
> don't
> > > > have
> > > > > > to
> > > > > > > > > worry
> > > > > > > > > about explicitly committing transactions (although you
> might
> > > > still
> > > > > > need to
> > > > > > > > > roll back
> > > > > > > > > if you're partway through an update and you need to abort
> > > > it). You
> > > > > > can
> > > > > > > > > access
> > > > > > > > > things like JPA entity classes directly from a JSF backing
> bean,
> > > > but
> > > > > > you
> > > > > > > > > need to
> > > > > > > > > manage transactions yourself.
> > > > > > > > >
> > > > > > > > > * A SFSB can only be accessed by one thread at a time, so
> you
> > > > might
> > > > > > find
> > > > > > > > > yourself
> > > > > > > > > in a situation where the locking that enforces this can
> cause
> > > > you
> > > > > > > > > performance issues.
> > > > > > > > > A classic case is where you've got lots of AJAX-ish calls
> coming
> > > > in
> > > > > > from
> > > > > > > > > the client,
> > > > > > > > > such that there will be multiple requests (on different
> threads)
> > > > to
> > > > > > the
> > > > > > > > > same session bean
> > > > > > > > > at the same time. With session scoped backing beans, the
> calls
> > > > > > happen
> > > > > > > > > simultaneously
> > > > > > > > > (but, of course, that means you also need to code your
> methods
> > > > in a
> > > > > > > > > threadsafe manner).
> > > > > > > > > With an SFSB you don't have to worry about coding for
> > > > simultaneous
> > > > > > access,
> > > > > > > > > but you do
> > > > > > > > > need to worry about the performance impact of the locking.
> > > > > > > > >
> > > > > > > > > Craig
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > thx so much
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by stephan opitz <st...@gmail.com>.
as i reviewed example from jboss:
http://docs.jboss.org/ejb3/app-server/tutorial/injection/injection.html
To facilitate test driven development, the EJB 3.0 specification
allows you to use annotations to inject dependencies through
annotations on fields or setter methods. Instead of complicated XML
ejb-refs or resource refs, you can use the @EJB and @Resource
annotations to set the value of a field or to call a setter method
within your session bean with anything registered within JNDI.
You can use the @EJB annotation to inject EJB references and @Resource
to access datasources.
in conclusion that ejb incejtion only works if registration is within
jndi, so beans under registred ejb stateful or stateless beans should
work without problems as managed bean i gave up
2006/9/15, stephan opitz <st...@gmail.com>:
> it will created by jsf - i see that tiger annotation does not work at this point
>
> it seems my problem lies in implementation if the injection
>
> public class DataFactory {
>
> @EJB
> private CategoriesLangFacade categoriesLangFacade;
>
> public CategoriesLangFacade getCategoriesLangFacade() {
>
> return categoriesLangFacade;
> }
>
> }
>
> /////////////////////////////////////////////////////////////////////////////
>
> @Local
> public interface CategoriesLangFacade {
>
> public CategoriesLang findById(long categoriesLangId, long languageId);
>
> }
>
> #######################################
>
> @Stateless
> public class CategoriesLangImp implements CategoriesLangFacade {
>
> @PersistenceContext(unitName = "ShaleTestPU")
> private EntityManager em;
>
> public static final String Remote = CategoriesLangImp.class
> .getSimpleName()
> + "/remote";
>
> public static final String Local = CategoriesLangImp.class
> .getSimpleName()
> + "/local";
>
> public CategoriesLang findById(long categoriesLangId, long languageId) {
> ...
> }
>
> }
>
> but this is the way how to
>
> an @local interface, an stateless ejb and DataFactory which should
> create injection
>
>
>
> 2006/9/15, Craig McClanahan <cr...@apache.org>:
> > On 9/15/06, stephan opitz <st...@gmail.com> wrote:
> > >
> > > does indeed work - i tried under jboss so many different versions of
> > > implementation...
> > >
> > > craig i know your mailreader jpa based on glassfish...
> >
> >
> > That is true, but I had to follow the advice I gave you ... I had to make
> > the backing beans that receive injection into standard JSF managed beans,
> > not using the Shale Tiger @Bean annotation.
> >
> > maybe it is because of jboss ejb implementation?
> > >
> > > my managed bean "datafactory" is in the ejb-jar and defined in
> > > faces-config.xml
> > > i have access from any shale model class
> >
> >
> > Be sure to take @Bean off as well ... if you leave it there, the Tiger
> > extensions will be creating the bean, instead of JSF itself, so the
> > injections will not occur.
> >
> > Craig
> >
> > if i debug i see
> > >
> > > @Resource
> > > SessionContext sc;
> > > is null
> > >
> > > maybe i have a generall problem with the jboss
> > >
> > > does exist any tiger annotation for the postback value?
> > >
> > > 5, Craig McClanahan <cr...@apache.org>:
> > > > On 9/15/06, stephan opitz <st...@gmail.com> wrote:
> > > > >
> > > > > craig...
> > > > >
> > > > > the possibility with indirect works only if i do a jndi lookup...
> > > > >
> > > > > @Bean(name = "dataFactory", scope = Scope.SESSION)
> > > > > public class DataFactory {
> > > > >
> > > > > @EJB
> > > > > private CategoriesLangFacade categoriesLangFacade;
> > > > >
> > > > > public CategoriesLangFacade getCategoriesLangFacade() {
> > > > >
> > > > > return categoriesLangFacade;
> > > > > }
> > > > >
> > > > > }
> > > > >
> > > > > solves categoriesLangFacade as null;
> > > > >
> > > > > without @EJB and jndi-lookup in the getCategoriesLangFacade it works
> > > > > under jbos s4.04ga - but why resource injection does not work ?
> > > >
> > > >
> > > > Container resource injection only works on what the *container* thinks
> > > is a
> > > > JSF managed bean that *it* created. The Tiger Extensions stuff (@Bean)
> > > > intercepts the normal process and creates the bean itself, and can't do
> > > any
> > > > injections. If you made this a normal managed bean (configured in
> > > > faces-config.xml), you'll find that the resource injection does indeed
> > > work.
> > > >
> > > > It would be an interesting challenge to examine whether it's even
> > > *possible*
> > > > to fake the container's normal resource injection for stuff like this.
> > > >
> > > > Craig
> > > >
> > > > ########################################
> > > > >
> > > > > public interface CategoriesLangFacade {
> > > > >
> > > > > public CategoriesLang findById(long categoriesLangId, long
> > > > > languageId);
> > > > >
> > > > > }
> > > > >
> > > > > #######################################
> > > > >
> > > > > @Local({CategoriesLangFacade.class})
> > > > > @Stateless
> > > > > public class CategoriesLangImp implements CategoriesLangFacade {
> > > > >
> > > > > @PersistenceContext(unitName = "ShaleTestPU")
> > > > > private EntityManager em;
> > > > >
> > > > > public static final String Remote = CategoriesLangImp.class
> > > > > .getSimpleName()
> > > > > + "/remote";
> > > > >
> > > > > public static final String Local = CategoriesLangImp.class
> > > > > .getSimpleName()
> > > > > + "/local";
> > > > >
> > > > > public CategoriesLang findById(long categoriesLangId, long
> > > > > languageId) {
> > > > > ...
> > > > >
> > > > >
> > > > > any solution or idea?
> > > > >
> > > > >
> > > > >
> > > > > 2006/9/13, stephan opitz <st...@gmail.com>:
> > > > > > i tried comparable, but without success.
> > > > > >
> > > > > > anyone who can helps?
> > > > > >
> > > > > > 2006/9/12, numpsy beelzebub <nu...@gmail.com>:
> > > > > > > thx craig,
> > > > > > >
> > > > > > >
> > > > > > > > It is possible to access the stateful session bean *indirectly*,
> > > if
> > > > > you
> > > > > > > > declare it in a managed bean and then provide a public
> > > getter. The
> > > > > > > simplest
> > > > > > > > way to do this is to leverage the resource injection
> > > capabilities of
> > > > > a
> > > > > > > Java
> > > > > > > > EE 5 container, so you might have something like this:
> > > > > > >
> > > > > > > > @EJB
> > > > > > > > private MySessionBean mySessionBean;
> > > > > > >
> > > > > > > > public MySessionBean getMySessionBean() { return
> > > > > this.mySessionBean; }
> > > > > > >
> > > > > > > > and you can then use a binding expression like "#{
> > > > > foo.mySessionBean.bar}"
> > > > > > > > where "foo" is the name of the managed bean containing the above
> > > > > > > > declaration, and "bar" is a property on the session bean itself.
> > > > > > >
> > > > > > > > If you are not running inside an EE 5 app server, you'll have to
> > > do
> > > > > the
> > > > > > > > usual sort of JNDI lookup to get a reference to the stateful
> > > session
> > > > > bean
> > > > > > > > instead. If you're using Shale's ViewController capabilities,
> > > the
> > > > > init()
> > > > > > > > method would be a good place to do that so the bean will be
> > > > > available to
> > > > > > > > other event handlers (and rendering) associated with this bean.
> > > > > > >
> > > > > > > can't follow exactly
> > > > > > > now i use jboss and ask for my entity beans from shale model
> > > objects
> > > > > > > try {
> > > > > > > Context context = new InitialContext();
> > > > > > > contactNotesFassade = (ContactNotesFassade) context
> > > > > > > .lookup(Constants.ProjectNameSeparator
> > > > > > > + ContactNotesFassadeImp.Local);
> > > > > > > } catch (NamingException e) {
> > > > > > > messageLang.setFacesMessage("error.ejb");
> > > > > > > }
> > > > > > > can image how this @EJB works with shale and how i can have easy
> > > > > access in
> > > > > > > clay etc...
> > > > > > > 1. i declare a stateful session bean mySessionBean mySessionBean
> > > > > > > ejb-web-project part
> > > > > > > 2. an interface with local - here the part with your @EJB code
> > > > > > > 3. access to interface in modelbeans of shale - as you told in
> > > > > init()-method
> > > > > > >
> > > > > > > how i can have access in clay to this away stateful ejb
> > > > > > >
> > > > > > >
> > > > > > > :-/
> > > > > > >
> > > > > > > 2006/9/11, Craig McClanahan <cr...@apache.org>:
> > > > > > >
> > > > > > > > On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > hello,
> > > > > > > > >
> > > > > > > > > i want to developed an application using shale and ejb 3.0(within
> > > > > > > > > container
> > > > > > > > > jboss).
> > > > > > > > > primary i used stateless session beans for access to the
> > > entity
> > > > > beans -
> > > > > > > > > persistenz-layer is ok and how to work with it
> > > > > > > > >
> > > > > > > > > as session i will declare a managed bean with an application
> > > scope
> > > > > > > > > "session"
> > > > > > > > > and save my data in it.
> > > > > > > > > i thought it is the fastest and easiest way, but in comparing
> > > to
> > > > > > > > stateful
> > > > > > > > > session beans it is not the only possible solution.
> > > > > > > > >
> > > > > > > > > in addition to this a few questions:
> > > > > > > > >
> > > > > > > > > 1. i'm fit in clay and know how to access normally ejb 3.0from
> > > > > shale's
> > > > > > > > > application-logic (building context etc)
> > > > > > > > > but how is it possible to access stateful session bean from
> > > view
> > > > > etc.
> > > > > > > > > (normally i have direct access, if it is declared as managed
> > > bean)
> > > > > > > >
> > > > > > > >
> > > > > > > > It is possible to access the stateful session bean *indirectly*,
> > > if
> > > > > you
> > > > > > > > declare it in a managed bean and then provide a public
> > > getter. The
> > > > > > > > simplest
> > > > > > > > way to do this is to leverage the resource injection
> > > capabilities of
> > > > > a
> > > > > > > > Java
> > > > > > > > EE 5 container, so you might have something like this:
> > > > > > > >
> > > > > > > > @EJB
> > > > > > > > private MySessionBean mySessionBean;
> > > > > > > >
> > > > > > > > public MySessionBean getMySessionBean() { return
> > > > > this.mySessionBean; }
> > > > > > > >
> > > > > > > > and you can then use a binding expression like "#{
> > > > > foo.mySessionBean.bar}"
> > > > > > > > where "foo" is the name of the managed bean containing the above
> > > > > > > > declaration, and "bar" is a property on the session bean itself.
> > > > > > > >
> > > > > > > > If you are not running inside an EE 5 app server, you'll have to
> > > do
> > > > > the
> > > > > > > > usual sort of JNDI lookup to get a reference to the stateful
> > > session
> > > > > bean
> > > > > > > > instead. If you're using Shale's ViewController capabilities,
> > > the
> > > > > init()
> > > > > > > > method would be a good place to do that so the bean will be
> > > > > available to
> > > > > > > > other event handlers (and rendering) associated with this bean.
> > > > > > > >
> > > > > > > >
> > > > > > > > 2. i have to initalize context for access ejb, so i thought
> > > maybe
> > > > > declare
> > > > > > > > a
> > > > > > > > > interface as managed bean which gives access to stateful
> > > session
> > > > > bean
> > > > > > > > > does exist a method in shale except init(), that would be
> > > > > called for
> > > > > > > > > every request, so that i can initialize my access-context
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Why do you need a method other than init()? That is exactly
> > > what it
> > > > > is
> > > > > > > > for.
> > > > > > > >
> > > > > > > >
> > > > > > > > 3. if i want to use stateful-session ejb 3.0 - how is it
> > > possible
> > > > > out from
> > > > > > > > > session to define when access of specific user ends.
> > > > > > > > > maybe saving access to stateful-session ejb 3.0 into some
> > > kind
> > > > > of
> > > > > > > > state
> > > > > > > > > bean in shale declared as managed bean with session scope ->
> > > but
> > > > > if i do
> > > > > > > > > it
> > > > > > > > > so it seems strange
> > > > > > > >
> > > > > > > >
> > > > > > > > My understanding of the typical scenario for Stateful session
> > > beans
> > > > > is
> > > > > > > > that,
> > > > > > > > when you want the user's access to end (i.e. they log out or
> > > > > something),
> > > > > > > > then you'll call the remove method o the stateful session bean
> > > to
> > > > > make it
> > > > > > > > go
> > > > > > > > away.
> > > > > > > >
> > > > > > > >
> > > > > > > > i save access to a ejb, but i could save the data also direct
> > > > > > > > > 4. generally problem - session in shale is only a javabean
> > > with
> > > > > the
> > > > > > > > > session
> > > > > > > > > scope
> > > > > > > > > <-> stateful session bean is server side component
> > > > > (differences are
> > > > > > > > > clear, but what is best to use - where lies advantages)
> > > > > > > > >
> > > > > > > > > it is also a problem because jboss seam gives possibilities
> > > for my
> > > > > > > > > problems
> > > > > > > > >
> > > http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
> > > > > > > > >
> > > > > > > > > maybe i need some impressions of developer with some kind of
> > > more
> > > > > > > > > experience, including th developers of shale
> > > > > > > >
> > > > > > > >
> > > > > > > > Seam encourages you (but does not require you) to use a stateful
> > > > > session
> > > > > > > > bean (SFSB) in a manner fairly similar to using a session
> > > scoped
> > > > > backing
> > > > > > > > bean in a regular JSF application. If you're using an SFSB for
> > > your
> > > > > > > > business logic anyway, this can save you writing one class (the
> > > > > typical
> > > > > > > > sort
> > > > > > > > of backing bean) that primarily serves as an adapter role. The
> > > > > tradeoff
> > > > > > > > is
> > > > > > > > that you'll typically end up tying the SFSB class to web tier
> > > APIs
> > > > > instead
> > > > > > > > of being able to make it independent.
> > > > > > > >
> > > > > > > > A couple of other considerations:
> > > > > > > >
> > > > > > > > * If you're using Shale view controllers, that only works for
> > > > > request
> > > > > > > > scope
> > > > > > > > beans,
> > > > > > > > so you won't be able to make your SFSB class "implements
> > > > > ViewController"
> > > > > > > > and get those sorts of event callbacks.
> > > > > > > >
> > > > > > > > * A SFSB is automatically a transactional resource (depending on
> > > > > what
> > > > > > > > annotations
> > > > > > > > or XML metadata settings you use to configure it), so you don't
> > > have
> > > > > to
> > > > > > > > worry
> > > > > > > > about explicitly committing transactions (although you might
> > > still
> > > > > need to
> > > > > > > > roll back
> > > > > > > > if you're partway through an update and you need to abort
> > > it). You
> > > > > can
> > > > > > > > access
> > > > > > > > things like JPA entity classes directly from a JSF backing bean,
> > > but
> > > > > you
> > > > > > > > need to
> > > > > > > > manage transactions yourself.
> > > > > > > >
> > > > > > > > * A SFSB can only be accessed by one thread at a time, so you
> > > might
> > > > > find
> > > > > > > > yourself
> > > > > > > > in a situation where the locking that enforces this can cause
> > > you
> > > > > > > > performance issues.
> > > > > > > > A classic case is where you've got lots of AJAX-ish calls coming
> > > in
> > > > > from
> > > > > > > > the client,
> > > > > > > > such that there will be multiple requests (on different threads)
> > > to
> > > > > the
> > > > > > > > same session bean
> > > > > > > > at the same time. With session scoped backing beans, the calls
> > > > > happen
> > > > > > > > simultaneously
> > > > > > > > (but, of course, that means you also need to code your methods
> > > in a
> > > > > > > > threadsafe manner).
> > > > > > > > With an SFSB you don't have to worry about coding for
> > > simultaneous
> > > > > access,
> > > > > > > > but you do
> > > > > > > > need to worry about the performance impact of the locking.
> > > > > > > >
> > > > > > > > Craig
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > thx so much
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by stephan opitz <st...@gmail.com>.
it will created by jsf - i see that tiger annotation does not work at this point
it seems my problem lies in implementation if the injection
public class DataFactory {
@EJB
private CategoriesLangFacade categoriesLangFacade;
public CategoriesLangFacade getCategoriesLangFacade() {
return categoriesLangFacade;
}
}
/////////////////////////////////////////////////////////////////////////////
@Local
public interface CategoriesLangFacade {
public CategoriesLang findById(long categoriesLangId, long languageId);
}
#######################################
@Stateless
public class CategoriesLangImp implements CategoriesLangFacade {
@PersistenceContext(unitName = "ShaleTestPU")
private EntityManager em;
public static final String Remote = CategoriesLangImp.class
.getSimpleName()
+ "/remote";
public static final String Local = CategoriesLangImp.class
.getSimpleName()
+ "/local";
public CategoriesLang findById(long categoriesLangId, long languageId) {
...
}
}
but this is the way how to
an @local interface, an stateless ejb and DataFactory which should
create injection
2006/9/15, Craig McClanahan <cr...@apache.org>:
> On 9/15/06, stephan opitz <st...@gmail.com> wrote:
> >
> > does indeed work - i tried under jboss so many different versions of
> > implementation...
> >
> > craig i know your mailreader jpa based on glassfish...
>
>
> That is true, but I had to follow the advice I gave you ... I had to make
> the backing beans that receive injection into standard JSF managed beans,
> not using the Shale Tiger @Bean annotation.
>
> maybe it is because of jboss ejb implementation?
> >
> > my managed bean "datafactory" is in the ejb-jar and defined in
> > faces-config.xml
> > i have access from any shale model class
>
>
> Be sure to take @Bean off as well ... if you leave it there, the Tiger
> extensions will be creating the bean, instead of JSF itself, so the
> injections will not occur.
>
> Craig
>
> if i debug i see
> >
> > @Resource
> > SessionContext sc;
> > is null
> >
> > maybe i have a generall problem with the jboss
> >
> > does exist any tiger annotation for the postback value?
> >
> > 5, Craig McClanahan <cr...@apache.org>:
> > > On 9/15/06, stephan opitz <st...@gmail.com> wrote:
> > > >
> > > > craig...
> > > >
> > > > the possibility with indirect works only if i do a jndi lookup...
> > > >
> > > > @Bean(name = "dataFactory", scope = Scope.SESSION)
> > > > public class DataFactory {
> > > >
> > > > @EJB
> > > > private CategoriesLangFacade categoriesLangFacade;
> > > >
> > > > public CategoriesLangFacade getCategoriesLangFacade() {
> > > >
> > > > return categoriesLangFacade;
> > > > }
> > > >
> > > > }
> > > >
> > > > solves categoriesLangFacade as null;
> > > >
> > > > without @EJB and jndi-lookup in the getCategoriesLangFacade it works
> > > > under jbos s4.04ga - but why resource injection does not work ?
> > >
> > >
> > > Container resource injection only works on what the *container* thinks
> > is a
> > > JSF managed bean that *it* created. The Tiger Extensions stuff (@Bean)
> > > intercepts the normal process and creates the bean itself, and can't do
> > any
> > > injections. If you made this a normal managed bean (configured in
> > > faces-config.xml), you'll find that the resource injection does indeed
> > work.
> > >
> > > It would be an interesting challenge to examine whether it's even
> > *possible*
> > > to fake the container's normal resource injection for stuff like this.
> > >
> > > Craig
> > >
> > > ########################################
> > > >
> > > > public interface CategoriesLangFacade {
> > > >
> > > > public CategoriesLang findById(long categoriesLangId, long
> > > > languageId);
> > > >
> > > > }
> > > >
> > > > #######################################
> > > >
> > > > @Local({CategoriesLangFacade.class})
> > > > @Stateless
> > > > public class CategoriesLangImp implements CategoriesLangFacade {
> > > >
> > > > @PersistenceContext(unitName = "ShaleTestPU")
> > > > private EntityManager em;
> > > >
> > > > public static final String Remote = CategoriesLangImp.class
> > > > .getSimpleName()
> > > > + "/remote";
> > > >
> > > > public static final String Local = CategoriesLangImp.class
> > > > .getSimpleName()
> > > > + "/local";
> > > >
> > > > public CategoriesLang findById(long categoriesLangId, long
> > > > languageId) {
> > > > ...
> > > >
> > > >
> > > > any solution or idea?
> > > >
> > > >
> > > >
> > > > 2006/9/13, stephan opitz <st...@gmail.com>:
> > > > > i tried comparable, but without success.
> > > > >
> > > > > anyone who can helps?
> > > > >
> > > > > 2006/9/12, numpsy beelzebub <nu...@gmail.com>:
> > > > > > thx craig,
> > > > > >
> > > > > >
> > > > > > > It is possible to access the stateful session bean *indirectly*,
> > if
> > > > you
> > > > > > > declare it in a managed bean and then provide a public
> > getter. The
> > > > > > simplest
> > > > > > > way to do this is to leverage the resource injection
> > capabilities of
> > > > a
> > > > > > Java
> > > > > > > EE 5 container, so you might have something like this:
> > > > > >
> > > > > > > @EJB
> > > > > > > private MySessionBean mySessionBean;
> > > > > >
> > > > > > > public MySessionBean getMySessionBean() { return
> > > > this.mySessionBean; }
> > > > > >
> > > > > > > and you can then use a binding expression like "#{
> > > > foo.mySessionBean.bar}"
> > > > > > > where "foo" is the name of the managed bean containing the above
> > > > > > > declaration, and "bar" is a property on the session bean itself.
> > > > > >
> > > > > > > If you are not running inside an EE 5 app server, you'll have to
> > do
> > > > the
> > > > > > > usual sort of JNDI lookup to get a reference to the stateful
> > session
> > > > bean
> > > > > > > instead. If you're using Shale's ViewController capabilities,
> > the
> > > > init()
> > > > > > > method would be a good place to do that so the bean will be
> > > > available to
> > > > > > > other event handlers (and rendering) associated with this bean.
> > > > > >
> > > > > > can't follow exactly
> > > > > > now i use jboss and ask for my entity beans from shale model
> > objects
> > > > > > try {
> > > > > > Context context = new InitialContext();
> > > > > > contactNotesFassade = (ContactNotesFassade) context
> > > > > > .lookup(Constants.ProjectNameSeparator
> > > > > > + ContactNotesFassadeImp.Local);
> > > > > > } catch (NamingException e) {
> > > > > > messageLang.setFacesMessage("error.ejb");
> > > > > > }
> > > > > > can image how this @EJB works with shale and how i can have easy
> > > > access in
> > > > > > clay etc...
> > > > > > 1. i declare a stateful session bean mySessionBean mySessionBean
> > > > > > ejb-web-project part
> > > > > > 2. an interface with local - here the part with your @EJB code
> > > > > > 3. access to interface in modelbeans of shale - as you told in
> > > > init()-method
> > > > > >
> > > > > > how i can have access in clay to this away stateful ejb
> > > > > >
> > > > > >
> > > > > > :-/
> > > > > >
> > > > > > 2006/9/11, Craig McClanahan <cr...@apache.org>:
> > > > > >
> > > > > > > On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > hello,
> > > > > > > >
> > > > > > > > i want to developed an application using shale and ejb 3.0(within
> > > > > > > > container
> > > > > > > > jboss).
> > > > > > > > primary i used stateless session beans for access to the
> > entity
> > > > beans -
> > > > > > > > persistenz-layer is ok and how to work with it
> > > > > > > >
> > > > > > > > as session i will declare a managed bean with an application
> > scope
> > > > > > > > "session"
> > > > > > > > and save my data in it.
> > > > > > > > i thought it is the fastest and easiest way, but in comparing
> > to
> > > > > > > stateful
> > > > > > > > session beans it is not the only possible solution.
> > > > > > > >
> > > > > > > > in addition to this a few questions:
> > > > > > > >
> > > > > > > > 1. i'm fit in clay and know how to access normally ejb 3.0from
> > > > shale's
> > > > > > > > application-logic (building context etc)
> > > > > > > > but how is it possible to access stateful session bean from
> > view
> > > > etc.
> > > > > > > > (normally i have direct access, if it is declared as managed
> > bean)
> > > > > > >
> > > > > > >
> > > > > > > It is possible to access the stateful session bean *indirectly*,
> > if
> > > > you
> > > > > > > declare it in a managed bean and then provide a public
> > getter. The
> > > > > > > simplest
> > > > > > > way to do this is to leverage the resource injection
> > capabilities of
> > > > a
> > > > > > > Java
> > > > > > > EE 5 container, so you might have something like this:
> > > > > > >
> > > > > > > @EJB
> > > > > > > private MySessionBean mySessionBean;
> > > > > > >
> > > > > > > public MySessionBean getMySessionBean() { return
> > > > this.mySessionBean; }
> > > > > > >
> > > > > > > and you can then use a binding expression like "#{
> > > > foo.mySessionBean.bar}"
> > > > > > > where "foo" is the name of the managed bean containing the above
> > > > > > > declaration, and "bar" is a property on the session bean itself.
> > > > > > >
> > > > > > > If you are not running inside an EE 5 app server, you'll have to
> > do
> > > > the
> > > > > > > usual sort of JNDI lookup to get a reference to the stateful
> > session
> > > > bean
> > > > > > > instead. If you're using Shale's ViewController capabilities,
> > the
> > > > init()
> > > > > > > method would be a good place to do that so the bean will be
> > > > available to
> > > > > > > other event handlers (and rendering) associated with this bean.
> > > > > > >
> > > > > > >
> > > > > > > 2. i have to initalize context for access ejb, so i thought
> > maybe
> > > > declare
> > > > > > > a
> > > > > > > > interface as managed bean which gives access to stateful
> > session
> > > > bean
> > > > > > > > does exist a method in shale except init(), that would be
> > > > called for
> > > > > > > > every request, so that i can initialize my access-context
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Why do you need a method other than init()? That is exactly
> > what it
> > > > is
> > > > > > > for.
> > > > > > >
> > > > > > >
> > > > > > > 3. if i want to use stateful-session ejb 3.0 - how is it
> > possible
> > > > out from
> > > > > > > > session to define when access of specific user ends.
> > > > > > > > maybe saving access to stateful-session ejb 3.0 into some
> > kind
> > > > of
> > > > > > > state
> > > > > > > > bean in shale declared as managed bean with session scope ->
> > but
> > > > if i do
> > > > > > > > it
> > > > > > > > so it seems strange
> > > > > > >
> > > > > > >
> > > > > > > My understanding of the typical scenario for Stateful session
> > beans
> > > > is
> > > > > > > that,
> > > > > > > when you want the user's access to end (i.e. they log out or
> > > > something),
> > > > > > > then you'll call the remove method o the stateful session bean
> > to
> > > > make it
> > > > > > > go
> > > > > > > away.
> > > > > > >
> > > > > > >
> > > > > > > i save access to a ejb, but i could save the data also direct
> > > > > > > > 4. generally problem - session in shale is only a javabean
> > with
> > > > the
> > > > > > > > session
> > > > > > > > scope
> > > > > > > > <-> stateful session bean is server side component
> > > > (differences are
> > > > > > > > clear, but what is best to use - where lies advantages)
> > > > > > > >
> > > > > > > > it is also a problem because jboss seam gives possibilities
> > for my
> > > > > > > > problems
> > > > > > > >
> > http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
> > > > > > > >
> > > > > > > > maybe i need some impressions of developer with some kind of
> > more
> > > > > > > > experience, including th developers of shale
> > > > > > >
> > > > > > >
> > > > > > > Seam encourages you (but does not require you) to use a stateful
> > > > session
> > > > > > > bean (SFSB) in a manner fairly similar to using a session
> > scoped
> > > > backing
> > > > > > > bean in a regular JSF application. If you're using an SFSB for
> > your
> > > > > > > business logic anyway, this can save you writing one class (the
> > > > typical
> > > > > > > sort
> > > > > > > of backing bean) that primarily serves as an adapter role. The
> > > > tradeoff
> > > > > > > is
> > > > > > > that you'll typically end up tying the SFSB class to web tier
> > APIs
> > > > instead
> > > > > > > of being able to make it independent.
> > > > > > >
> > > > > > > A couple of other considerations:
> > > > > > >
> > > > > > > * If you're using Shale view controllers, that only works for
> > > > request
> > > > > > > scope
> > > > > > > beans,
> > > > > > > so you won't be able to make your SFSB class "implements
> > > > ViewController"
> > > > > > > and get those sorts of event callbacks.
> > > > > > >
> > > > > > > * A SFSB is automatically a transactional resource (depending on
> > > > what
> > > > > > > annotations
> > > > > > > or XML metadata settings you use to configure it), so you don't
> > have
> > > > to
> > > > > > > worry
> > > > > > > about explicitly committing transactions (although you might
> > still
> > > > need to
> > > > > > > roll back
> > > > > > > if you're partway through an update and you need to abort
> > it). You
> > > > can
> > > > > > > access
> > > > > > > things like JPA entity classes directly from a JSF backing bean,
> > but
> > > > you
> > > > > > > need to
> > > > > > > manage transactions yourself.
> > > > > > >
> > > > > > > * A SFSB can only be accessed by one thread at a time, so you
> > might
> > > > find
> > > > > > > yourself
> > > > > > > in a situation where the locking that enforces this can cause
> > you
> > > > > > > performance issues.
> > > > > > > A classic case is where you've got lots of AJAX-ish calls coming
> > in
> > > > from
> > > > > > > the client,
> > > > > > > such that there will be multiple requests (on different threads)
> > to
> > > > the
> > > > > > > same session bean
> > > > > > > at the same time. With session scoped backing beans, the calls
> > > > happen
> > > > > > > simultaneously
> > > > > > > (but, of course, that means you also need to code your methods
> > in a
> > > > > > > threadsafe manner).
> > > > > > > With an SFSB you don't have to worry about coding for
> > simultaneous
> > > > access,
> > > > > > > but you do
> > > > > > > need to worry about the performance impact of the locking.
> > > > > > >
> > > > > > > Craig
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > thx so much
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by Craig McClanahan <cr...@apache.org>.
On 9/15/06, stephan opitz <st...@gmail.com> wrote:
>
> does indeed work - i tried under jboss so many different versions of
> implementation...
>
> craig i know your mailreader jpa based on glassfish...
That is true, but I had to follow the advice I gave you ... I had to make
the backing beans that receive injection into standard JSF managed beans,
not using the Shale Tiger @Bean annotation.
maybe it is because of jboss ejb implementation?
>
> my managed bean "datafactory" is in the ejb-jar and defined in
> faces-config.xml
> i have access from any shale model class
Be sure to take @Bean off as well ... if you leave it there, the Tiger
extensions will be creating the bean, instead of JSF itself, so the
injections will not occur.
Craig
if i debug i see
>
> @Resource
> SessionContext sc;
> is null
>
> maybe i have a generall problem with the jboss
>
> does exist any tiger annotation for the postback value?
>
> 5, Craig McClanahan <cr...@apache.org>:
> > On 9/15/06, stephan opitz <st...@gmail.com> wrote:
> > >
> > > craig...
> > >
> > > the possibility with indirect works only if i do a jndi lookup...
> > >
> > > @Bean(name = "dataFactory", scope = Scope.SESSION)
> > > public class DataFactory {
> > >
> > > @EJB
> > > private CategoriesLangFacade categoriesLangFacade;
> > >
> > > public CategoriesLangFacade getCategoriesLangFacade() {
> > >
> > > return categoriesLangFacade;
> > > }
> > >
> > > }
> > >
> > > solves categoriesLangFacade as null;
> > >
> > > without @EJB and jndi-lookup in the getCategoriesLangFacade it works
> > > under jbos s4.04ga - but why resource injection does not work ?
> >
> >
> > Container resource injection only works on what the *container* thinks
> is a
> > JSF managed bean that *it* created. The Tiger Extensions stuff (@Bean)
> > intercepts the normal process and creates the bean itself, and can't do
> any
> > injections. If you made this a normal managed bean (configured in
> > faces-config.xml), you'll find that the resource injection does indeed
> work.
> >
> > It would be an interesting challenge to examine whether it's even
> *possible*
> > to fake the container's normal resource injection for stuff like this.
> >
> > Craig
> >
> > ########################################
> > >
> > > public interface CategoriesLangFacade {
> > >
> > > public CategoriesLang findById(long categoriesLangId, long
> > > languageId);
> > >
> > > }
> > >
> > > #######################################
> > >
> > > @Local({CategoriesLangFacade.class})
> > > @Stateless
> > > public class CategoriesLangImp implements CategoriesLangFacade {
> > >
> > > @PersistenceContext(unitName = "ShaleTestPU")
> > > private EntityManager em;
> > >
> > > public static final String Remote = CategoriesLangImp.class
> > > .getSimpleName()
> > > + "/remote";
> > >
> > > public static final String Local = CategoriesLangImp.class
> > > .getSimpleName()
> > > + "/local";
> > >
> > > public CategoriesLang findById(long categoriesLangId, long
> > > languageId) {
> > > ...
> > >
> > >
> > > any solution or idea?
> > >
> > >
> > >
> > > 2006/9/13, stephan opitz <st...@gmail.com>:
> > > > i tried comparable, but without success.
> > > >
> > > > anyone who can helps?
> > > >
> > > > 2006/9/12, numpsy beelzebub <nu...@gmail.com>:
> > > > > thx craig,
> > > > >
> > > > >
> > > > > > It is possible to access the stateful session bean *indirectly*,
> if
> > > you
> > > > > > declare it in a managed bean and then provide a public
> getter. The
> > > > > simplest
> > > > > > way to do this is to leverage the resource injection
> capabilities of
> > > a
> > > > > Java
> > > > > > EE 5 container, so you might have something like this:
> > > > >
> > > > > > @EJB
> > > > > > private MySessionBean mySessionBean;
> > > > >
> > > > > > public MySessionBean getMySessionBean() { return
> > > this.mySessionBean; }
> > > > >
> > > > > > and you can then use a binding expression like "#{
> > > foo.mySessionBean.bar}"
> > > > > > where "foo" is the name of the managed bean containing the above
> > > > > > declaration, and "bar" is a property on the session bean itself.
> > > > >
> > > > > > If you are not running inside an EE 5 app server, you'll have to
> do
> > > the
> > > > > > usual sort of JNDI lookup to get a reference to the stateful
> session
> > > bean
> > > > > > instead. If you're using Shale's ViewController capabilities,
> the
> > > init()
> > > > > > method would be a good place to do that so the bean will be
> > > available to
> > > > > > other event handlers (and rendering) associated with this bean.
> > > > >
> > > > > can't follow exactly
> > > > > now i use jboss and ask for my entity beans from shale model
> objects
> > > > > try {
> > > > > Context context = new InitialContext();
> > > > > contactNotesFassade = (ContactNotesFassade) context
> > > > > .lookup(Constants.ProjectNameSeparator
> > > > > + ContactNotesFassadeImp.Local);
> > > > > } catch (NamingException e) {
> > > > > messageLang.setFacesMessage("error.ejb");
> > > > > }
> > > > > can image how this @EJB works with shale and how i can have easy
> > > access in
> > > > > clay etc...
> > > > > 1. i declare a stateful session bean mySessionBean mySessionBean
> > > > > ejb-web-project part
> > > > > 2. an interface with local - here the part with your @EJB code
> > > > > 3. access to interface in modelbeans of shale - as you told in
> > > init()-method
> > > > >
> > > > > how i can have access in clay to this away stateful ejb
> > > > >
> > > > >
> > > > > :-/
> > > > >
> > > > > 2006/9/11, Craig McClanahan <cr...@apache.org>:
> > > > >
> > > > > > On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > > >
> > > > > > > hello,
> > > > > > >
> > > > > > > i want to developed an application using shale and ejb 3.0(within
> > > > > > > container
> > > > > > > jboss).
> > > > > > > primary i used stateless session beans for access to the
> entity
> > > beans -
> > > > > > > persistenz-layer is ok and how to work with it
> > > > > > >
> > > > > > > as session i will declare a managed bean with an application
> scope
> > > > > > > "session"
> > > > > > > and save my data in it.
> > > > > > > i thought it is the fastest and easiest way, but in comparing
> to
> > > > > > stateful
> > > > > > > session beans it is not the only possible solution.
> > > > > > >
> > > > > > > in addition to this a few questions:
> > > > > > >
> > > > > > > 1. i'm fit in clay and know how to access normally ejb 3.0from
> > > shale's
> > > > > > > application-logic (building context etc)
> > > > > > > but how is it possible to access stateful session bean from
> view
> > > etc.
> > > > > > > (normally i have direct access, if it is declared as managed
> bean)
> > > > > >
> > > > > >
> > > > > > It is possible to access the stateful session bean *indirectly*,
> if
> > > you
> > > > > > declare it in a managed bean and then provide a public
> getter. The
> > > > > > simplest
> > > > > > way to do this is to leverage the resource injection
> capabilities of
> > > a
> > > > > > Java
> > > > > > EE 5 container, so you might have something like this:
> > > > > >
> > > > > > @EJB
> > > > > > private MySessionBean mySessionBean;
> > > > > >
> > > > > > public MySessionBean getMySessionBean() { return
> > > this.mySessionBean; }
> > > > > >
> > > > > > and you can then use a binding expression like "#{
> > > foo.mySessionBean.bar}"
> > > > > > where "foo" is the name of the managed bean containing the above
> > > > > > declaration, and "bar" is a property on the session bean itself.
> > > > > >
> > > > > > If you are not running inside an EE 5 app server, you'll have to
> do
> > > the
> > > > > > usual sort of JNDI lookup to get a reference to the stateful
> session
> > > bean
> > > > > > instead. If you're using Shale's ViewController capabilities,
> the
> > > init()
> > > > > > method would be a good place to do that so the bean will be
> > > available to
> > > > > > other event handlers (and rendering) associated with this bean.
> > > > > >
> > > > > >
> > > > > > 2. i have to initalize context for access ejb, so i thought
> maybe
> > > declare
> > > > > > a
> > > > > > > interface as managed bean which gives access to stateful
> session
> > > bean
> > > > > > > does exist a method in shale except init(), that would be
> > > called for
> > > > > > > every request, so that i can initialize my access-context
> > > > > >
> > > > > >
> > > > > >
> > > > > > Why do you need a method other than init()? That is exactly
> what it
> > > is
> > > > > > for.
> > > > > >
> > > > > >
> > > > > > 3. if i want to use stateful-session ejb 3.0 - how is it
> possible
> > > out from
> > > > > > > session to define when access of specific user ends.
> > > > > > > maybe saving access to stateful-session ejb 3.0 into some
> kind
> > > of
> > > > > > state
> > > > > > > bean in shale declared as managed bean with session scope ->
> but
> > > if i do
> > > > > > > it
> > > > > > > so it seems strange
> > > > > >
> > > > > >
> > > > > > My understanding of the typical scenario for Stateful session
> beans
> > > is
> > > > > > that,
> > > > > > when you want the user's access to end (i.e. they log out or
> > > something),
> > > > > > then you'll call the remove method o the stateful session bean
> to
> > > make it
> > > > > > go
> > > > > > away.
> > > > > >
> > > > > >
> > > > > > i save access to a ejb, but i could save the data also direct
> > > > > > > 4. generally problem - session in shale is only a javabean
> with
> > > the
> > > > > > > session
> > > > > > > scope
> > > > > > > <-> stateful session bean is server side component
> > > (differences are
> > > > > > > clear, but what is best to use - where lies advantages)
> > > > > > >
> > > > > > > it is also a problem because jboss seam gives possibilities
> for my
> > > > > > > problems
> > > > > > >
> http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
> > > > > > >
> > > > > > > maybe i need some impressions of developer with some kind of
> more
> > > > > > > experience, including th developers of shale
> > > > > >
> > > > > >
> > > > > > Seam encourages you (but does not require you) to use a stateful
> > > session
> > > > > > bean (SFSB) in a manner fairly similar to using a session
> scoped
> > > backing
> > > > > > bean in a regular JSF application. If you're using an SFSB for
> your
> > > > > > business logic anyway, this can save you writing one class (the
> > > typical
> > > > > > sort
> > > > > > of backing bean) that primarily serves as an adapter role. The
> > > tradeoff
> > > > > > is
> > > > > > that you'll typically end up tying the SFSB class to web tier
> APIs
> > > instead
> > > > > > of being able to make it independent.
> > > > > >
> > > > > > A couple of other considerations:
> > > > > >
> > > > > > * If you're using Shale view controllers, that only works for
> > > request
> > > > > > scope
> > > > > > beans,
> > > > > > so you won't be able to make your SFSB class "implements
> > > ViewController"
> > > > > > and get those sorts of event callbacks.
> > > > > >
> > > > > > * A SFSB is automatically a transactional resource (depending on
> > > what
> > > > > > annotations
> > > > > > or XML metadata settings you use to configure it), so you don't
> have
> > > to
> > > > > > worry
> > > > > > about explicitly committing transactions (although you might
> still
> > > need to
> > > > > > roll back
> > > > > > if you're partway through an update and you need to abort
> it). You
> > > can
> > > > > > access
> > > > > > things like JPA entity classes directly from a JSF backing bean,
> but
> > > you
> > > > > > need to
> > > > > > manage transactions yourself.
> > > > > >
> > > > > > * A SFSB can only be accessed by one thread at a time, so you
> might
> > > find
> > > > > > yourself
> > > > > > in a situation where the locking that enforces this can cause
> you
> > > > > > performance issues.
> > > > > > A classic case is where you've got lots of AJAX-ish calls coming
> in
> > > from
> > > > > > the client,
> > > > > > such that there will be multiple requests (on different threads)
> to
> > > the
> > > > > > same session bean
> > > > > > at the same time. With session scoped backing beans, the calls
> > > happen
> > > > > > simultaneously
> > > > > > (but, of course, that means you also need to code your methods
> in a
> > > > > > threadsafe manner).
> > > > > > With an SFSB you don't have to worry about coding for
> simultaneous
> > > access,
> > > > > > but you do
> > > > > > need to worry about the performance impact of the locking.
> > > > > >
> > > > > > Craig
> > > > > >
> > > > > >
> > > > > >
> > > > > > thx so much
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
>
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by stephan opitz <st...@gmail.com>.
does indeed work - i tried under jboss so many different versions of
implementation...
craig i know your mailreader jpa based on glassfish...
maybe it is because of jboss ejb implementation?
my managed bean "datafactory" is in the ejb-jar and defined in faces-config.xml
i have access from any shale model class
if i debug i see
@Resource
SessionContext sc;
is null
maybe i have a generall problem with the jboss
does exist any tiger annotation for the postback value?
5, Craig McClanahan <cr...@apache.org>:
> On 9/15/06, stephan opitz <st...@gmail.com> wrote:
> >
> > craig...
> >
> > the possibility with indirect works only if i do a jndi lookup...
> >
> > @Bean(name = "dataFactory", scope = Scope.SESSION)
> > public class DataFactory {
> >
> > @EJB
> > private CategoriesLangFacade categoriesLangFacade;
> >
> > public CategoriesLangFacade getCategoriesLangFacade() {
> >
> > return categoriesLangFacade;
> > }
> >
> > }
> >
> > solves categoriesLangFacade as null;
> >
> > without @EJB and jndi-lookup in the getCategoriesLangFacade it works
> > under jbos s4.04ga - but why resource injection does not work ?
>
>
> Container resource injection only works on what the *container* thinks is a
> JSF managed bean that *it* created. The Tiger Extensions stuff (@Bean)
> intercepts the normal process and creates the bean itself, and can't do any
> injections. If you made this a normal managed bean (configured in
> faces-config.xml), you'll find that the resource injection does indeed work.
>
> It would be an interesting challenge to examine whether it's even *possible*
> to fake the container's normal resource injection for stuff like this.
>
> Craig
>
> ########################################
> >
> > public interface CategoriesLangFacade {
> >
> > public CategoriesLang findById(long categoriesLangId, long
> > languageId);
> >
> > }
> >
> > #######################################
> >
> > @Local({CategoriesLangFacade.class})
> > @Stateless
> > public class CategoriesLangImp implements CategoriesLangFacade {
> >
> > @PersistenceContext(unitName = "ShaleTestPU")
> > private EntityManager em;
> >
> > public static final String Remote = CategoriesLangImp.class
> > .getSimpleName()
> > + "/remote";
> >
> > public static final String Local = CategoriesLangImp.class
> > .getSimpleName()
> > + "/local";
> >
> > public CategoriesLang findById(long categoriesLangId, long
> > languageId) {
> > ...
> >
> >
> > any solution or idea?
> >
> >
> >
> > 2006/9/13, stephan opitz <st...@gmail.com>:
> > > i tried comparable, but without success.
> > >
> > > anyone who can helps?
> > >
> > > 2006/9/12, numpsy beelzebub <nu...@gmail.com>:
> > > > thx craig,
> > > >
> > > >
> > > > > It is possible to access the stateful session bean *indirectly*, if
> > you
> > > > > declare it in a managed bean and then provide a public getter. The
> > > > simplest
> > > > > way to do this is to leverage the resource injection capabilities of
> > a
> > > > Java
> > > > > EE 5 container, so you might have something like this:
> > > >
> > > > > @EJB
> > > > > private MySessionBean mySessionBean;
> > > >
> > > > > public MySessionBean getMySessionBean() { return
> > this.mySessionBean; }
> > > >
> > > > > and you can then use a binding expression like "#{
> > foo.mySessionBean.bar}"
> > > > > where "foo" is the name of the managed bean containing the above
> > > > > declaration, and "bar" is a property on the session bean itself.
> > > >
> > > > > If you are not running inside an EE 5 app server, you'll have to do
> > the
> > > > > usual sort of JNDI lookup to get a reference to the stateful session
> > bean
> > > > > instead. If you're using Shale's ViewController capabilities, the
> > init()
> > > > > method would be a good place to do that so the bean will be
> > available to
> > > > > other event handlers (and rendering) associated with this bean.
> > > >
> > > > can't follow exactly
> > > > now i use jboss and ask for my entity beans from shale model objects
> > > > try {
> > > > Context context = new InitialContext();
> > > > contactNotesFassade = (ContactNotesFassade) context
> > > > .lookup(Constants.ProjectNameSeparator
> > > > + ContactNotesFassadeImp.Local);
> > > > } catch (NamingException e) {
> > > > messageLang.setFacesMessage("error.ejb");
> > > > }
> > > > can image how this @EJB works with shale and how i can have easy
> > access in
> > > > clay etc...
> > > > 1. i declare a stateful session bean mySessionBean mySessionBean
> > > > ejb-web-project part
> > > > 2. an interface with local - here the part with your @EJB code
> > > > 3. access to interface in modelbeans of shale - as you told in
> > init()-method
> > > >
> > > > how i can have access in clay to this away stateful ejb
> > > >
> > > >
> > > > :-/
> > > >
> > > > 2006/9/11, Craig McClanahan <cr...@apache.org>:
> > > >
> > > > > On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > >
> > > > > > hello,
> > > > > >
> > > > > > i want to developed an application using shale and ejb 3.0 (within
> > > > > > container
> > > > > > jboss).
> > > > > > primary i used stateless session beans for access to the entity
> > beans -
> > > > > > persistenz-layer is ok and how to work with it
> > > > > >
> > > > > > as session i will declare a managed bean with an application scope
> > > > > > "session"
> > > > > > and save my data in it.
> > > > > > i thought it is the fastest and easiest way, but in comparing to
> > > > > stateful
> > > > > > session beans it is not the only possible solution.
> > > > > >
> > > > > > in addition to this a few questions:
> > > > > >
> > > > > > 1. i'm fit in clay and know how to access normally ejb 3.0 from
> > shale's
> > > > > > application-logic (building context etc)
> > > > > > but how is it possible to access stateful session bean from view
> > etc.
> > > > > > (normally i have direct access, if it is declared as managed bean)
> > > > >
> > > > >
> > > > > It is possible to access the stateful session bean *indirectly*, if
> > you
> > > > > declare it in a managed bean and then provide a public getter. The
> > > > > simplest
> > > > > way to do this is to leverage the resource injection capabilities of
> > a
> > > > > Java
> > > > > EE 5 container, so you might have something like this:
> > > > >
> > > > > @EJB
> > > > > private MySessionBean mySessionBean;
> > > > >
> > > > > public MySessionBean getMySessionBean() { return
> > this.mySessionBean; }
> > > > >
> > > > > and you can then use a binding expression like "#{
> > foo.mySessionBean.bar}"
> > > > > where "foo" is the name of the managed bean containing the above
> > > > > declaration, and "bar" is a property on the session bean itself.
> > > > >
> > > > > If you are not running inside an EE 5 app server, you'll have to do
> > the
> > > > > usual sort of JNDI lookup to get a reference to the stateful session
> > bean
> > > > > instead. If you're using Shale's ViewController capabilities, the
> > init()
> > > > > method would be a good place to do that so the bean will be
> > available to
> > > > > other event handlers (and rendering) associated with this bean.
> > > > >
> > > > >
> > > > > 2. i have to initalize context for access ejb, so i thought maybe
> > declare
> > > > > a
> > > > > > interface as managed bean which gives access to stateful session
> > bean
> > > > > > does exist a method in shale except init(), that would be
> > called for
> > > > > > every request, so that i can initialize my access-context
> > > > >
> > > > >
> > > > >
> > > > > Why do you need a method other than init()? That is exactly what it
> > is
> > > > > for.
> > > > >
> > > > >
> > > > > 3. if i want to use stateful-session ejb 3.0 - how is it possible
> > out from
> > > > > > session to define when access of specific user ends.
> > > > > > maybe saving access to stateful-session ejb 3.0 into some kind
> > of
> > > > > state
> > > > > > bean in shale declared as managed bean with session scope -> but
> > if i do
> > > > > > it
> > > > > > so it seems strange
> > > > >
> > > > >
> > > > > My understanding of the typical scenario for Stateful session beans
> > is
> > > > > that,
> > > > > when you want the user's access to end (i.e. they log out or
> > something),
> > > > > then you'll call the remove method o the stateful session bean to
> > make it
> > > > > go
> > > > > away.
> > > > >
> > > > >
> > > > > i save access to a ejb, but i could save the data also direct
> > > > > > 4. generally problem - session in shale is only a javabean with
> > the
> > > > > > session
> > > > > > scope
> > > > > > <-> stateful session bean is server side component
> > (differences are
> > > > > > clear, but what is best to use - where lies advantages)
> > > > > >
> > > > > > it is also a problem because jboss seam gives possibilities for my
> > > > > > problems
> > > > > > http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
> > > > > >
> > > > > > maybe i need some impressions of developer with some kind of more
> > > > > > experience, including th developers of shale
> > > > >
> > > > >
> > > > > Seam encourages you (but does not require you) to use a stateful
> > session
> > > > > bean (SFSB) in a manner fairly similar to using a session scoped
> > backing
> > > > > bean in a regular JSF application. If you're using an SFSB for your
> > > > > business logic anyway, this can save you writing one class (the
> > typical
> > > > > sort
> > > > > of backing bean) that primarily serves as an adapter role. The
> > tradeoff
> > > > > is
> > > > > that you'll typically end up tying the SFSB class to web tier APIs
> > instead
> > > > > of being able to make it independent.
> > > > >
> > > > > A couple of other considerations:
> > > > >
> > > > > * If you're using Shale view controllers, that only works for
> > request
> > > > > scope
> > > > > beans,
> > > > > so you won't be able to make your SFSB class "implements
> > ViewController"
> > > > > and get those sorts of event callbacks.
> > > > >
> > > > > * A SFSB is automatically a transactional resource (depending on
> > what
> > > > > annotations
> > > > > or XML metadata settings you use to configure it), so you don't have
> > to
> > > > > worry
> > > > > about explicitly committing transactions (although you might still
> > need to
> > > > > roll back
> > > > > if you're partway through an update and you need to abort it). You
> > can
> > > > > access
> > > > > things like JPA entity classes directly from a JSF backing bean, but
> > you
> > > > > need to
> > > > > manage transactions yourself.
> > > > >
> > > > > * A SFSB can only be accessed by one thread at a time, so you might
> > find
> > > > > yourself
> > > > > in a situation where the locking that enforces this can cause you
> > > > > performance issues.
> > > > > A classic case is where you've got lots of AJAX-ish calls coming in
> > from
> > > > > the client,
> > > > > such that there will be multiple requests (on different threads) to
> > the
> > > > > same session bean
> > > > > at the same time. With session scoped backing beans, the calls
> > happen
> > > > > simultaneously
> > > > > (but, of course, that means you also need to code your methods in a
> > > > > threadsafe manner).
> > > > > With an SFSB you don't have to worry about coding for simultaneous
> > access,
> > > > > but you do
> > > > > need to worry about the performance impact of the locking.
> > > > >
> > > > > Craig
> > > > >
> > > > >
> > > > >
> > > > > thx so much
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
>
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by Craig McClanahan <cr...@apache.org>.
On 9/15/06, stephan opitz <st...@gmail.com> wrote:
>
> craig...
>
> the possibility with indirect works only if i do a jndi lookup...
>
> @Bean(name = "dataFactory", scope = Scope.SESSION)
> public class DataFactory {
>
> @EJB
> private CategoriesLangFacade categoriesLangFacade;
>
> public CategoriesLangFacade getCategoriesLangFacade() {
>
> return categoriesLangFacade;
> }
>
> }
>
> solves categoriesLangFacade as null;
>
> without @EJB and jndi-lookup in the getCategoriesLangFacade it works
> under jbos s4.04ga - but why resource injection does not work ?
Container resource injection only works on what the *container* thinks is a
JSF managed bean that *it* created. The Tiger Extensions stuff (@Bean)
intercepts the normal process and creates the bean itself, and can't do any
injections. If you made this a normal managed bean (configured in
faces-config.xml), you'll find that the resource injection does indeed work.
It would be an interesting challenge to examine whether it's even *possible*
to fake the container's normal resource injection for stuff like this.
Craig
########################################
>
> public interface CategoriesLangFacade {
>
> public CategoriesLang findById(long categoriesLangId, long
> languageId);
>
> }
>
> #######################################
>
> @Local({CategoriesLangFacade.class})
> @Stateless
> public class CategoriesLangImp implements CategoriesLangFacade {
>
> @PersistenceContext(unitName = "ShaleTestPU")
> private EntityManager em;
>
> public static final String Remote = CategoriesLangImp.class
> .getSimpleName()
> + "/remote";
>
> public static final String Local = CategoriesLangImp.class
> .getSimpleName()
> + "/local";
>
> public CategoriesLang findById(long categoriesLangId, long
> languageId) {
> ...
>
>
> any solution or idea?
>
>
>
> 2006/9/13, stephan opitz <st...@gmail.com>:
> > i tried comparable, but without success.
> >
> > anyone who can helps?
> >
> > 2006/9/12, numpsy beelzebub <nu...@gmail.com>:
> > > thx craig,
> > >
> > >
> > > > It is possible to access the stateful session bean *indirectly*, if
> you
> > > > declare it in a managed bean and then provide a public getter. The
> > > simplest
> > > > way to do this is to leverage the resource injection capabilities of
> a
> > > Java
> > > > EE 5 container, so you might have something like this:
> > >
> > > > @EJB
> > > > private MySessionBean mySessionBean;
> > >
> > > > public MySessionBean getMySessionBean() { return
> this.mySessionBean; }
> > >
> > > > and you can then use a binding expression like "#{
> foo.mySessionBean.bar}"
> > > > where "foo" is the name of the managed bean containing the above
> > > > declaration, and "bar" is a property on the session bean itself.
> > >
> > > > If you are not running inside an EE 5 app server, you'll have to do
> the
> > > > usual sort of JNDI lookup to get a reference to the stateful session
> bean
> > > > instead. If you're using Shale's ViewController capabilities, the
> init()
> > > > method would be a good place to do that so the bean will be
> available to
> > > > other event handlers (and rendering) associated with this bean.
> > >
> > > can't follow exactly
> > > now i use jboss and ask for my entity beans from shale model objects
> > > try {
> > > Context context = new InitialContext();
> > > contactNotesFassade = (ContactNotesFassade) context
> > > .lookup(Constants.ProjectNameSeparator
> > > + ContactNotesFassadeImp.Local);
> > > } catch (NamingException e) {
> > > messageLang.setFacesMessage("error.ejb");
> > > }
> > > can image how this @EJB works with shale and how i can have easy
> access in
> > > clay etc...
> > > 1. i declare a stateful session bean mySessionBean mySessionBean
> > > ejb-web-project part
> > > 2. an interface with local - here the part with your @EJB code
> > > 3. access to interface in modelbeans of shale - as you told in
> init()-method
> > >
> > > how i can have access in clay to this away stateful ejb
> > >
> > >
> > > :-/
> > >
> > > 2006/9/11, Craig McClanahan <cr...@apache.org>:
> > >
> > > > On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > >
> > > > > hello,
> > > > >
> > > > > i want to developed an application using shale and ejb 3.0 (within
> > > > > container
> > > > > jboss).
> > > > > primary i used stateless session beans for access to the entity
> beans -
> > > > > persistenz-layer is ok and how to work with it
> > > > >
> > > > > as session i will declare a managed bean with an application scope
> > > > > "session"
> > > > > and save my data in it.
> > > > > i thought it is the fastest and easiest way, but in comparing to
> > > > stateful
> > > > > session beans it is not the only possible solution.
> > > > >
> > > > > in addition to this a few questions:
> > > > >
> > > > > 1. i'm fit in clay and know how to access normally ejb 3.0 from
> shale's
> > > > > application-logic (building context etc)
> > > > > but how is it possible to access stateful session bean from view
> etc.
> > > > > (normally i have direct access, if it is declared as managed bean)
> > > >
> > > >
> > > > It is possible to access the stateful session bean *indirectly*, if
> you
> > > > declare it in a managed bean and then provide a public getter. The
> > > > simplest
> > > > way to do this is to leverage the resource injection capabilities of
> a
> > > > Java
> > > > EE 5 container, so you might have something like this:
> > > >
> > > > @EJB
> > > > private MySessionBean mySessionBean;
> > > >
> > > > public MySessionBean getMySessionBean() { return
> this.mySessionBean; }
> > > >
> > > > and you can then use a binding expression like "#{
> foo.mySessionBean.bar}"
> > > > where "foo" is the name of the managed bean containing the above
> > > > declaration, and "bar" is a property on the session bean itself.
> > > >
> > > > If you are not running inside an EE 5 app server, you'll have to do
> the
> > > > usual sort of JNDI lookup to get a reference to the stateful session
> bean
> > > > instead. If you're using Shale's ViewController capabilities, the
> init()
> > > > method would be a good place to do that so the bean will be
> available to
> > > > other event handlers (and rendering) associated with this bean.
> > > >
> > > >
> > > > 2. i have to initalize context for access ejb, so i thought maybe
> declare
> > > > a
> > > > > interface as managed bean which gives access to stateful session
> bean
> > > > > does exist a method in shale except init(), that would be
> called for
> > > > > every request, so that i can initialize my access-context
> > > >
> > > >
> > > >
> > > > Why do you need a method other than init()? That is exactly what it
> is
> > > > for.
> > > >
> > > >
> > > > 3. if i want to use stateful-session ejb 3.0 - how is it possible
> out from
> > > > > session to define when access of specific user ends.
> > > > > maybe saving access to stateful-session ejb 3.0 into some kind
> of
> > > > state
> > > > > bean in shale declared as managed bean with session scope -> but
> if i do
> > > > > it
> > > > > so it seems strange
> > > >
> > > >
> > > > My understanding of the typical scenario for Stateful session beans
> is
> > > > that,
> > > > when you want the user's access to end (i.e. they log out or
> something),
> > > > then you'll call the remove method o the stateful session bean to
> make it
> > > > go
> > > > away.
> > > >
> > > >
> > > > i save access to a ejb, but i could save the data also direct
> > > > > 4. generally problem - session in shale is only a javabean with
> the
> > > > > session
> > > > > scope
> > > > > <-> stateful session bean is server side component
> (differences are
> > > > > clear, but what is best to use - where lies advantages)
> > > > >
> > > > > it is also a problem because jboss seam gives possibilities for my
> > > > > problems
> > > > > http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
> > > > >
> > > > > maybe i need some impressions of developer with some kind of more
> > > > > experience, including th developers of shale
> > > >
> > > >
> > > > Seam encourages you (but does not require you) to use a stateful
> session
> > > > bean (SFSB) in a manner fairly similar to using a session scoped
> backing
> > > > bean in a regular JSF application. If you're using an SFSB for your
> > > > business logic anyway, this can save you writing one class (the
> typical
> > > > sort
> > > > of backing bean) that primarily serves as an adapter role. The
> tradeoff
> > > > is
> > > > that you'll typically end up tying the SFSB class to web tier APIs
> instead
> > > > of being able to make it independent.
> > > >
> > > > A couple of other considerations:
> > > >
> > > > * If you're using Shale view controllers, that only works for
> request
> > > > scope
> > > > beans,
> > > > so you won't be able to make your SFSB class "implements
> ViewController"
> > > > and get those sorts of event callbacks.
> > > >
> > > > * A SFSB is automatically a transactional resource (depending on
> what
> > > > annotations
> > > > or XML metadata settings you use to configure it), so you don't have
> to
> > > > worry
> > > > about explicitly committing transactions (although you might still
> need to
> > > > roll back
> > > > if you're partway through an update and you need to abort it). You
> can
> > > > access
> > > > things like JPA entity classes directly from a JSF backing bean, but
> you
> > > > need to
> > > > manage transactions yourself.
> > > >
> > > > * A SFSB can only be accessed by one thread at a time, so you might
> find
> > > > yourself
> > > > in a situation where the locking that enforces this can cause you
> > > > performance issues.
> > > > A classic case is where you've got lots of AJAX-ish calls coming in
> from
> > > > the client,
> > > > such that there will be multiple requests (on different threads) to
> the
> > > > same session bean
> > > > at the same time. With session scoped backing beans, the calls
> happen
> > > > simultaneously
> > > > (but, of course, that means you also need to code your methods in a
> > > > threadsafe manner).
> > > > With an SFSB you don't have to worry about coding for simultaneous
> access,
> > > > but you do
> > > > need to worry about the performance impact of the locking.
> > > >
> > > > Craig
> > > >
> > > >
> > > >
> > > > thx so much
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by stephan opitz <st...@gmail.com>.
craig...
the possibility with indirect works only if i do a jndi lookup...
@Bean(name = "dataFactory", scope = Scope.SESSION)
public class DataFactory {
@EJB
private CategoriesLangFacade categoriesLangFacade;
public CategoriesLangFacade getCategoriesLangFacade() {
return categoriesLangFacade;
}
}
solves categoriesLangFacade as null;
without @EJB and jndi-lookup in the getCategoriesLangFacade it works
under jbos s4.04ga - but why resource injection does not work ?
########################################
public interface CategoriesLangFacade {
public CategoriesLang findById(long categoriesLangId, long languageId);
}
#######################################
@Local({CategoriesLangFacade.class})
@Stateless
public class CategoriesLangImp implements CategoriesLangFacade {
@PersistenceContext(unitName = "ShaleTestPU")
private EntityManager em;
public static final String Remote = CategoriesLangImp.class
.getSimpleName()
+ "/remote";
public static final String Local = CategoriesLangImp.class
.getSimpleName()
+ "/local";
public CategoriesLang findById(long categoriesLangId, long languageId) {
...
any solution or idea?
2006/9/13, stephan opitz <st...@gmail.com>:
> i tried comparable, but without success.
>
> anyone who can helps?
>
> 2006/9/12, numpsy beelzebub <nu...@gmail.com>:
> > thx craig,
> >
> >
> > > It is possible to access the stateful session bean *indirectly*, if you
> > > declare it in a managed bean and then provide a public getter. The
> > simplest
> > > way to do this is to leverage the resource injection capabilities of a
> > Java
> > > EE 5 container, so you might have something like this:
> >
> > > @EJB
> > > private MySessionBean mySessionBean;
> >
> > > public MySessionBean getMySessionBean() { return this.mySessionBean; }
> >
> > > and you can then use a binding expression like "#{foo.mySessionBean.bar}"
> > > where "foo" is the name of the managed bean containing the above
> > > declaration, and "bar" is a property on the session bean itself.
> >
> > > If you are not running inside an EE 5 app server, you'll have to do the
> > > usual sort of JNDI lookup to get a reference to the stateful session bean
> > > instead. If you're using Shale's ViewController capabilities, the init()
> > > method would be a good place to do that so the bean will be available to
> > > other event handlers (and rendering) associated with this bean.
> >
> > can't follow exactly
> > now i use jboss and ask for my entity beans from shale model objects
> > try {
> > Context context = new InitialContext();
> > contactNotesFassade = (ContactNotesFassade) context
> > .lookup(Constants.ProjectNameSeparator
> > + ContactNotesFassadeImp.Local);
> > } catch (NamingException e) {
> > messageLang.setFacesMessage("error.ejb");
> > }
> > can image how this @EJB works with shale and how i can have easy access in
> > clay etc...
> > 1. i declare a stateful session bean mySessionBean mySessionBean
> > ejb-web-project part
> > 2. an interface with local - here the part with your @EJB code
> > 3. access to interface in modelbeans of shale - as you told in init()-method
> >
> > how i can have access in clay to this away stateful ejb
> >
> >
> > :-/
> >
> > 2006/9/11, Craig McClanahan <cr...@apache.org>:
> >
> > > On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > >
> > > > hello,
> > > >
> > > > i want to developed an application using shale and ejb 3.0 (within
> > > > container
> > > > jboss).
> > > > primary i used stateless session beans for access to the entity beans -
> > > > persistenz-layer is ok and how to work with it
> > > >
> > > > as session i will declare a managed bean with an application scope
> > > > "session"
> > > > and save my data in it.
> > > > i thought it is the fastest and easiest way, but in comparing to
> > > stateful
> > > > session beans it is not the only possible solution.
> > > >
> > > > in addition to this a few questions:
> > > >
> > > > 1. i'm fit in clay and know how to access normally ejb 3.0 from shale's
> > > > application-logic (building context etc)
> > > > but how is it possible to access stateful session bean from view etc.
> > > > (normally i have direct access, if it is declared as managed bean)
> > >
> > >
> > > It is possible to access the stateful session bean *indirectly*, if you
> > > declare it in a managed bean and then provide a public getter. The
> > > simplest
> > > way to do this is to leverage the resource injection capabilities of a
> > > Java
> > > EE 5 container, so you might have something like this:
> > >
> > > @EJB
> > > private MySessionBean mySessionBean;
> > >
> > > public MySessionBean getMySessionBean() { return this.mySessionBean; }
> > >
> > > and you can then use a binding expression like "#{foo.mySessionBean.bar}"
> > > where "foo" is the name of the managed bean containing the above
> > > declaration, and "bar" is a property on the session bean itself.
> > >
> > > If you are not running inside an EE 5 app server, you'll have to do the
> > > usual sort of JNDI lookup to get a reference to the stateful session bean
> > > instead. If you're using Shale's ViewController capabilities, the init()
> > > method would be a good place to do that so the bean will be available to
> > > other event handlers (and rendering) associated with this bean.
> > >
> > >
> > > 2. i have to initalize context for access ejb, so i thought maybe declare
> > > a
> > > > interface as managed bean which gives access to stateful session bean
> > > > does exist a method in shale except init(), that would be called for
> > > > every request, so that i can initialize my access-context
> > >
> > >
> > >
> > > Why do you need a method other than init()? That is exactly what it is
> > > for.
> > >
> > >
> > > 3. if i want to use stateful-session ejb 3.0 - how is it possible out from
> > > > session to define when access of specific user ends.
> > > > maybe saving access to stateful-session ejb 3.0 into some kind of
> > > state
> > > > bean in shale declared as managed bean with session scope -> but if i do
> > > > it
> > > > so it seems strange
> > >
> > >
> > > My understanding of the typical scenario for Stateful session beans is
> > > that,
> > > when you want the user's access to end (i.e. they log out or something),
> > > then you'll call the remove method o the stateful session bean to make it
> > > go
> > > away.
> > >
> > >
> > > i save access to a ejb, but i could save the data also direct
> > > > 4. generally problem - session in shale is only a javabean with the
> > > > session
> > > > scope
> > > > <-> stateful session bean is server side component (differences are
> > > > clear, but what is best to use - where lies advantages)
> > > >
> > > > it is also a problem because jboss seam gives possibilities for my
> > > > problems
> > > > http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
> > > >
> > > > maybe i need some impressions of developer with some kind of more
> > > > experience, including th developers of shale
> > >
> > >
> > > Seam encourages you (but does not require you) to use a stateful session
> > > bean (SFSB) in a manner fairly similar to using a session scoped backing
> > > bean in a regular JSF application. If you're using an SFSB for your
> > > business logic anyway, this can save you writing one class (the typical
> > > sort
> > > of backing bean) that primarily serves as an adapter role. The tradeoff
> > > is
> > > that you'll typically end up tying the SFSB class to web tier APIs instead
> > > of being able to make it independent.
> > >
> > > A couple of other considerations:
> > >
> > > * If you're using Shale view controllers, that only works for request
> > > scope
> > > beans,
> > > so you won't be able to make your SFSB class "implements ViewController"
> > > and get those sorts of event callbacks.
> > >
> > > * A SFSB is automatically a transactional resource (depending on what
> > > annotations
> > > or XML metadata settings you use to configure it), so you don't have to
> > > worry
> > > about explicitly committing transactions (although you might still need to
> > > roll back
> > > if you're partway through an update and you need to abort it). You can
> > > access
> > > things like JPA entity classes directly from a JSF backing bean, but you
> > > need to
> > > manage transactions yourself.
> > >
> > > * A SFSB can only be accessed by one thread at a time, so you might find
> > > yourself
> > > in a situation where the locking that enforces this can cause you
> > > performance issues.
> > > A classic case is where you've got lots of AJAX-ish calls coming in from
> > > the client,
> > > such that there will be multiple requests (on different threads) to the
> > > same session bean
> > > at the same time. With session scoped backing beans, the calls happen
> > > simultaneously
> > > (but, of course, that means you also need to code your methods in a
> > > threadsafe manner).
> > > With an SFSB you don't have to worry about coding for simultaneous access,
> > > but you do
> > > need to worry about the performance impact of the locking.
> > >
> > > Craig
> > >
> > >
> > >
> > > thx so much
> > > >
> > > >
> > >
> > >
> >
> >
>
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by stephan opitz <st...@gmail.com>.
i tried comparable, but without success.
anyone who can helps?
2006/9/12, numpsy beelzebub <nu...@gmail.com>:
> thx craig,
>
>
> > It is possible to access the stateful session bean *indirectly*, if you
> > declare it in a managed bean and then provide a public getter. The
> simplest
> > way to do this is to leverage the resource injection capabilities of a
> Java
> > EE 5 container, so you might have something like this:
>
> > @EJB
> > private MySessionBean mySessionBean;
>
> > public MySessionBean getMySessionBean() { return this.mySessionBean; }
>
> > and you can then use a binding expression like "#{foo.mySessionBean.bar}"
> > where "foo" is the name of the managed bean containing the above
> > declaration, and "bar" is a property on the session bean itself.
>
> > If you are not running inside an EE 5 app server, you'll have to do the
> > usual sort of JNDI lookup to get a reference to the stateful session bean
> > instead. If you're using Shale's ViewController capabilities, the init()
> > method would be a good place to do that so the bean will be available to
> > other event handlers (and rendering) associated with this bean.
>
> can't follow exactly
> now i use jboss and ask for my entity beans from shale model objects
> try {
> Context context = new InitialContext();
> contactNotesFassade = (ContactNotesFassade) context
> .lookup(Constants.ProjectNameSeparator
> + ContactNotesFassadeImp.Local);
> } catch (NamingException e) {
> messageLang.setFacesMessage("error.ejb");
> }
> can image how this @EJB works with shale and how i can have easy access in
> clay etc...
> 1. i declare a stateful session bean mySessionBean mySessionBean
> ejb-web-project part
> 2. an interface with local - here the part with your @EJB code
> 3. access to interface in modelbeans of shale - as you told in init()-method
>
> how i can have access in clay to this away stateful ejb
>
>
> :-/
>
> 2006/9/11, Craig McClanahan <cr...@apache.org>:
>
> > On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > >
> > > hello,
> > >
> > > i want to developed an application using shale and ejb 3.0 (within
> > > container
> > > jboss).
> > > primary i used stateless session beans for access to the entity beans -
> > > persistenz-layer is ok and how to work with it
> > >
> > > as session i will declare a managed bean with an application scope
> > > "session"
> > > and save my data in it.
> > > i thought it is the fastest and easiest way, but in comparing to
> > stateful
> > > session beans it is not the only possible solution.
> > >
> > > in addition to this a few questions:
> > >
> > > 1. i'm fit in clay and know how to access normally ejb 3.0 from shale's
> > > application-logic (building context etc)
> > > but how is it possible to access stateful session bean from view etc.
> > > (normally i have direct access, if it is declared as managed bean)
> >
> >
> > It is possible to access the stateful session bean *indirectly*, if you
> > declare it in a managed bean and then provide a public getter. The
> > simplest
> > way to do this is to leverage the resource injection capabilities of a
> > Java
> > EE 5 container, so you might have something like this:
> >
> > @EJB
> > private MySessionBean mySessionBean;
> >
> > public MySessionBean getMySessionBean() { return this.mySessionBean; }
> >
> > and you can then use a binding expression like "#{foo.mySessionBean.bar}"
> > where "foo" is the name of the managed bean containing the above
> > declaration, and "bar" is a property on the session bean itself.
> >
> > If you are not running inside an EE 5 app server, you'll have to do the
> > usual sort of JNDI lookup to get a reference to the stateful session bean
> > instead. If you're using Shale's ViewController capabilities, the init()
> > method would be a good place to do that so the bean will be available to
> > other event handlers (and rendering) associated with this bean.
> >
> >
> > 2. i have to initalize context for access ejb, so i thought maybe declare
> > a
> > > interface as managed bean which gives access to stateful session bean
> > > does exist a method in shale except init(), that would be called for
> > > every request, so that i can initialize my access-context
> >
> >
> >
> > Why do you need a method other than init()? That is exactly what it is
> > for.
> >
> >
> > 3. if i want to use stateful-session ejb 3.0 - how is it possible out from
> > > session to define when access of specific user ends.
> > > maybe saving access to stateful-session ejb 3.0 into some kind of
> > state
> > > bean in shale declared as managed bean with session scope -> but if i do
> > > it
> > > so it seems strange
> >
> >
> > My understanding of the typical scenario for Stateful session beans is
> > that,
> > when you want the user's access to end (i.e. they log out or something),
> > then you'll call the remove method o the stateful session bean to make it
> > go
> > away.
> >
> >
> > i save access to a ejb, but i could save the data also direct
> > > 4. generally problem - session in shale is only a javabean with the
> > > session
> > > scope
> > > <-> stateful session bean is server side component (differences are
> > > clear, but what is best to use - where lies advantages)
> > >
> > > it is also a problem because jboss seam gives possibilities for my
> > > problems
> > > http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
> > >
> > > maybe i need some impressions of developer with some kind of more
> > > experience, including th developers of shale
> >
> >
> > Seam encourages you (but does not require you) to use a stateful session
> > bean (SFSB) in a manner fairly similar to using a session scoped backing
> > bean in a regular JSF application. If you're using an SFSB for your
> > business logic anyway, this can save you writing one class (the typical
> > sort
> > of backing bean) that primarily serves as an adapter role. The tradeoff
> > is
> > that you'll typically end up tying the SFSB class to web tier APIs instead
> > of being able to make it independent.
> >
> > A couple of other considerations:
> >
> > * If you're using Shale view controllers, that only works for request
> > scope
> > beans,
> > so you won't be able to make your SFSB class "implements ViewController"
> > and get those sorts of event callbacks.
> >
> > * A SFSB is automatically a transactional resource (depending on what
> > annotations
> > or XML metadata settings you use to configure it), so you don't have to
> > worry
> > about explicitly committing transactions (although you might still need to
> > roll back
> > if you're partway through an update and you need to abort it). You can
> > access
> > things like JPA entity classes directly from a JSF backing bean, but you
> > need to
> > manage transactions yourself.
> >
> > * A SFSB can only be accessed by one thread at a time, so you might find
> > yourself
> > in a situation where the locking that enforces this can cause you
> > performance issues.
> > A classic case is where you've got lots of AJAX-ish calls coming in from
> > the client,
> > such that there will be multiple requests (on different threads) to the
> > same session bean
> > at the same time. With session scoped backing beans, the calls happen
> > simultaneously
> > (but, of course, that means you also need to code your methods in a
> > threadsafe manner).
> > With an SFSB you don't have to worry about coding for simultaneous access,
> > but you do
> > need to worry about the performance impact of the locking.
> >
> > Craig
> >
> >
> >
> > thx so much
> > >
> > >
> >
> >
>
>
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by numpsy beelzebub <nu...@gmail.com>.
thx craig,
> It is possible to access the stateful session bean *indirectly*, if you
> declare it in a managed bean and then provide a public getter. The
simplest
> way to do this is to leverage the resource injection capabilities of a
Java
> EE 5 container, so you might have something like this:
> @EJB
> private MySessionBean mySessionBean;
> public MySessionBean getMySessionBean() { return this.mySessionBean; }
> and you can then use a binding expression like "#{foo.mySessionBean.bar}"
> where "foo" is the name of the managed bean containing the above
> declaration, and "bar" is a property on the session bean itself.
> If you are not running inside an EE 5 app server, you'll have to do the
> usual sort of JNDI lookup to get a reference to the stateful session bean
> instead. If you're using Shale's ViewController capabilities, the init()
> method would be a good place to do that so the bean will be available to
> other event handlers (and rendering) associated with this bean.
can't follow exactly
now i use jboss and ask for my entity beans from shale model objects
try {
Context context = new InitialContext();
contactNotesFassade = (ContactNotesFassade) context
.lookup(Constants.ProjectNameSeparator
+ ContactNotesFassadeImp.Local);
} catch (NamingException e) {
messageLang.setFacesMessage("error.ejb");
}
can image how this @EJB works with shale and how i can have easy access in
clay etc...
1. i declare a stateful session bean mySessionBean mySessionBean
ejb-web-project part
2. an interface with local - here the part with your @EJB code
3. access to interface in modelbeans of shale - as you told in init()-method
how i can have access in clay to this away stateful ejb
:-/
2006/9/11, Craig McClanahan <cr...@apache.org>:
> On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
> >
> > hello,
> >
> > i want to developed an application using shale and ejb 3.0 (within
> > container
> > jboss).
> > primary i used stateless session beans for access to the entity beans -
> > persistenz-layer is ok and how to work with it
> >
> > as session i will declare a managed bean with an application scope
> > "session"
> > and save my data in it.
> > i thought it is the fastest and easiest way, but in comparing to
> stateful
> > session beans it is not the only possible solution.
> >
> > in addition to this a few questions:
> >
> > 1. i'm fit in clay and know how to access normally ejb 3.0 from shale's
> > application-logic (building context etc)
> > but how is it possible to access stateful session bean from view etc.
> > (normally i have direct access, if it is declared as managed bean)
>
>
> It is possible to access the stateful session bean *indirectly*, if you
> declare it in a managed bean and then provide a public getter. The
> simplest
> way to do this is to leverage the resource injection capabilities of a
> Java
> EE 5 container, so you might have something like this:
>
> @EJB
> private MySessionBean mySessionBean;
>
> public MySessionBean getMySessionBean() { return this.mySessionBean; }
>
> and you can then use a binding expression like "#{foo.mySessionBean.bar}"
> where "foo" is the name of the managed bean containing the above
> declaration, and "bar" is a property on the session bean itself.
>
> If you are not running inside an EE 5 app server, you'll have to do the
> usual sort of JNDI lookup to get a reference to the stateful session bean
> instead. If you're using Shale's ViewController capabilities, the init()
> method would be a good place to do that so the bean will be available to
> other event handlers (and rendering) associated with this bean.
>
>
> 2. i have to initalize context for access ejb, so i thought maybe declare
> a
> > interface as managed bean which gives access to stateful session bean
> > does exist a method in shale except init(), that would be called for
> > every request, so that i can initialize my access-context
>
>
>
> Why do you need a method other than init()? That is exactly what it is
> for.
>
>
> 3. if i want to use stateful-session ejb 3.0 - how is it possible out from
> > session to define when access of specific user ends.
> > maybe saving access to stateful-session ejb 3.0 into some kind of
> state
> > bean in shale declared as managed bean with session scope -> but if i do
> > it
> > so it seems strange
>
>
> My understanding of the typical scenario for Stateful session beans is
> that,
> when you want the user's access to end (i.e. they log out or something),
> then you'll call the remove method o the stateful session bean to make it
> go
> away.
>
>
> i save access to a ejb, but i could save the data also direct
> > 4. generally problem - session in shale is only a javabean with the
> > session
> > scope
> > <-> stateful session bean is server side component (differences are
> > clear, but what is best to use - where lies advantages)
> >
> > it is also a problem because jboss seam gives possibilities for my
> > problems
> > http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
> >
> > maybe i need some impressions of developer with some kind of more
> > experience, including th developers of shale
>
>
> Seam encourages you (but does not require you) to use a stateful session
> bean (SFSB) in a manner fairly similar to using a session scoped backing
> bean in a regular JSF application. If you're using an SFSB for your
> business logic anyway, this can save you writing one class (the typical
> sort
> of backing bean) that primarily serves as an adapter role. The tradeoff
> is
> that you'll typically end up tying the SFSB class to web tier APIs instead
> of being able to make it independent.
>
> A couple of other considerations:
>
> * If you're using Shale view controllers, that only works for request
> scope
> beans,
> so you won't be able to make your SFSB class "implements ViewController"
> and get those sorts of event callbacks.
>
> * A SFSB is automatically a transactional resource (depending on what
> annotations
> or XML metadata settings you use to configure it), so you don't have to
> worry
> about explicitly committing transactions (although you might still need to
> roll back
> if you're partway through an update and you need to abort it). You can
> access
> things like JPA entity classes directly from a JSF backing bean, but you
> need to
> manage transactions yourself.
>
> * A SFSB can only be accessed by one thread at a time, so you might find
> yourself
> in a situation where the locking that enforces this can cause you
> performance issues.
> A classic case is where you've got lots of AJAX-ish calls coming in from
> the client,
> such that there will be multiple requests (on different threads) to the
> same session bean
> at the same time. With session scoped backing beans, the calls happen
> simultaneously
> (but, of course, that means you also need to code your methods in a
> threadsafe manner).
> With an SFSB you don't have to worry about coding for simultaneous access,
> but you do
> need to worry about the performance impact of the locking.
>
> Craig
>
>
>
> thx so much
> >
> >
>
>
Re: shale session vs ejb 3.0 stateful session beans / jboss seam
Posted by Craig McClanahan <cr...@apache.org>.
On 9/11/06, numpsy beelzebub <nu...@gmail.com> wrote:
>
> hello,
>
> i want to developed an application using shale and ejb 3.0 (within
> container
> jboss).
> primary i used stateless session beans for access to the entity beans -
> persistenz-layer is ok and how to work with it
>
> as session i will declare a managed bean with an application scope
> "session"
> and save my data in it.
> i thought it is the fastest and easiest way, but in comparing to stateful
> session beans it is not the only possible solution.
>
> in addition to this a few questions:
>
> 1. i'm fit in clay and know how to access normally ejb 3.0 from shale's
> application-logic (building context etc)
> but how is it possible to access stateful session bean from view etc.
> (normally i have direct access, if it is declared as managed bean)
It is possible to access the stateful session bean *indirectly*, if you
declare it in a managed bean and then provide a public getter. The simplest
way to do this is to leverage the resource injection capabilities of a Java
EE 5 container, so you might have something like this:
@EJB
private MySessionBean mySessionBean;
public MySessionBean getMySessionBean() { return this.mySessionBean; }
and you can then use a binding expression like "#{foo.mySessionBean.bar}"
where "foo" is the name of the managed bean containing the above
declaration, and "bar" is a property on the session bean itself.
If you are not running inside an EE 5 app server, you'll have to do the
usual sort of JNDI lookup to get a reference to the stateful session bean
instead. If you're using Shale's ViewController capabilities, the init()
method would be a good place to do that so the bean will be available to
other event handlers (and rendering) associated with this bean.
2. i have to initalize context for access ejb, so i thought maybe declare a
> interface as managed bean which gives access to stateful session bean
> does exist a method in shale except init(), that would be called for
> every request, so that i can initialize my access-context
Why do you need a method other than init()? That is exactly what it is for.
3. if i want to use stateful-session ejb 3.0 - how is it possible out from
> session to define when access of specific user ends.
> maybe saving access to stateful-session ejb 3.0 into some kind of state
> bean in shale declared as managed bean with session scope -> but if i do
> it
> so it seems strange
My understanding of the typical scenario for Stateful session beans is that,
when you want the user's access to end (i.e. they log out or something),
then you'll call the remove method o the stateful session bean to make it go
away.
i save access to a ejb, but i could save the data also direct
> 4. generally problem - session in shale is only a javabean with the
> session
> scope
> <-> stateful session bean is server side component (differences are
> clear, but what is best to use - where lies advantages)
>
> it is also a problem because jboss seam gives possibilities for my
> problems
> http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html
>
> maybe i need some impressions of developer with some kind of more
> experience, including th developers of shale
Seam encourages you (but does not require you) to use a stateful session
bean (SFSB) in a manner fairly similar to using a session scoped backing
bean in a regular JSF application. If you're using an SFSB for your
business logic anyway, this can save you writing one class (the typical sort
of backing bean) that primarily serves as an adapter role. The tradeoff is
that you'll typically end up tying the SFSB class to web tier APIs instead
of being able to make it independent.
A couple of other considerations:
* If you're using Shale view controllers, that only works for request scope
beans,
so you won't be able to make your SFSB class "implements ViewController"
and get those sorts of event callbacks.
* A SFSB is automatically a transactional resource (depending on what
annotations
or XML metadata settings you use to configure it), so you don't have to
worry
about explicitly committing transactions (although you might still need to
roll back
if you're partway through an update and you need to abort it). You can
access
things like JPA entity classes directly from a JSF backing bean, but you
need to
manage transactions yourself.
* A SFSB can only be accessed by one thread at a time, so you might find
yourself
in a situation where the locking that enforces this can cause you
performance issues.
A classic case is where you've got lots of AJAX-ish calls coming in from
the client,
such that there will be multiple requests (on different threads) to the
same session bean
at the same time. With session scoped backing beans, the calls happen
simultaneously
(but, of course, that means you also need to code your methods in a
threadsafe manner).
With an SFSB you don't have to worry about coding for simultaneous access,
but you do
need to worry about the performance impact of the locking.
Craig
thx so much
>
>