> From: Adam Winter [mailto:[EMAIL PROTECTED]]
>
> I'm not new to Java, but I am to EJB's and Orion's server.
> And I have a few
> questions concerning both of those.
Hi! I was in your same shoes a few months ago. Welcome to the list,
it's pretty cool here :-)
> First, assuming a web client, what maps a particular client
> to a Statefull
> Session Bean, particularly on subsequent pages? As a web
> developer, I've
> used cookies to preserve state, I've used client-side
> JavaScript variable,
> I've even had a server that designated certain pages to start
> a session and
> certain ones to end it, but I don't see how state is being
> preserved in
> this case. I understand the concept of one JSP creating a
> Statefull Session
> Bean, but I'm unclear on what's going on behind the scenes
> when the user
> invokes a second JSP and the Statefull Session Bean is still
> there having
> retained the information from the first call. What starts and stops a
> session? What happens if another user invokes the same JSP
> page? What if
> they're both behind a firewall and both appear to the server
> as having the
> same IP?
Put the stateful session EJB in the HttpSession. In a JSP file you can
reference it as the "session" implicit variable, and in a servlet, you
acquire it using "request.getSession(true)". The container manages
cookies (or most of the work of URL rewriting if cookies are not
available) to ensure that the correct http session is always available.
If you are like me, your next question is probably "why not just use the
HttpSession layer and skip the added complexity of the stateful session
bean?" In answer, I would recommend searching the list archives and
checking out the commentary on theserverside.com (look for "wrap entity
beans with session beans"). Basically, stateful session beans are a
better level of abstraction because A) they can be better used from
multiple types of presentation tiers (applets and rich clients as well
as web) and B) they provide a good level of transaction granularity.
There are other reasons as well but those are probably the two best.
> Second, does inheritance of Session Beans, work the same as other
> inheritance in Java? The answer is probably yes, but I've
> never seen this
> covered. Every EJB I've seen has extended EjbObject. Can I still have
> abstract super classes?
Certainly you can derive from your own abstract base classes, as long as
they derive from EJBObject. Out of curiosity, why do you want to do
this?
I don't see why you can't also fully derive session beans from other
session beans. Unlike entity beans, the ejbCreate() method does not
need to return a possibly bean-specific primary key type, so it should
work. Doesn't sound like a good idea, though; why not just encapsulate
the session bean rather than inherit from it?
> Third, what's the deal with user authorization being
> contained in a flat
> file (principals.xml)? Who has a static set of users? In my web
> application, application users are defined in a login table
> within our
> database. How would I express this in Orion/EJB (that user
> authentication
> needs to occur through custom routines in the database)? Am I
> misunderstanding the intent of the principals.xml file? Is it
> just a place
> to handle system logins to the database, such that further
> authentication
> can occur?
The actual mechanism for authentication is not defined by the J2EE spec.
Orion's simple default scheme is the principals.xml file, but you can
easily use other systems. Search the list archives for
DataSourceUserManager for a good discussion of one other approach; you
can also implement your own UserManager if you choose. I don't use the
principals.xml; my users are defined by "Member" entity beans and I
simply layer the DataSourceUserManager over the appropriate entity
table. There are many other ways of addressing this issue as well.
Good luck!
Jeff Schnitzer
[EMAIL PROTECTED]
