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
