i tried comparable, but without success.
anyone who can helps?
2006/9/12, numpsy beelzebub <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
> On 9/11/06, numpsy beelzebub <[EMAIL PROTECTED]> 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
> >
> >
>
>
