I keep coming across this problem. Usually I solve it by passing parameters to all
methods in a SLSB.
However in EJB 1.0, I seem to remember that user information (in addition to things
like UserPrincipal) could be added to the EJBContext, you could use getEnvironment()
to get a properties object.
Does anybody know why there is not a context object, like a servletContext or
sessionContext, in EJB.
Perhaps I am missing something?.. but that would seem to be a nice addition.
>From reading the EJBContext JavaDoc, the deprecated method: getEnvironment(),
>suggests using JNDI to get the environment variables. I have never seen anybody
>caching data in this way. (One could use the principal object as a key to make the
>data session specific)
Any Ideas.
Toby
On Fri, 25 Jan 2002 11:12:21 -0800, Alex Paransky
<[EMAIL PROTECTED]> wrote:
>RE: SFSB QuestionPassing a parameter in to stateless session bean will not
>help you, since the container is free to pool the beans as it wishes. So
>when you are doing an Home.create() call the container is simply picking on
>of existing free session bean objects from it's pool. If you did, somehow,
>managed to initialize the session with the id of the user, it would only
>confuse you later, since the same session would be used for a different
>user.
>
>The best method I can think of, is explicitly passing the parameters to each
>call your client make on to the session bean. You can package those
>parameters into a class called UserContext, for example, and make it easy to
>create the context:
>
>class UserContext implements java.io.Serializable {
> String userId, sessionId, httpRequestId;
>
> public static UserContext getContext(HttpServletRequest request) {...}
>}
>
>There are other methods such as using entity beans without persistence, or
>using statefull session beans. Both of these, however, will reduce the load
>balancing and fail over aspects of your system. Do you really want to
>sacrifice these features for log4j? Perhaps. Perhaps Not. You need to
>decide.
>
>-AP_
>
>
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
>[mailto:[EMAIL PROTECTED]]On Behalf Of Biske, Todd
> Sent: Friday, January 25, 2002 6:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: SFSB Question
>
>
> The initialization parameter that's needed is a logging context object
>that allows us to use the NDC in log4j across VM's. An example would be
>where we want the session id or user id associated with an HTTP request to
>be prepended to all log messages generated in the processing of that
>request. Within a VM, the NDC in log4j handles this. As soon as you make a
>remote call, however, you're executing in a different thread and the
>information in the NDC is lost.
>
> -tb
>
> -----Original Message-----
> From: Alex Paransky [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, January 24, 2002 5:35 PM
> To: Biske, Todd; [EMAIL PROTECTED]
> Subject: RE: SFSB Question
>
> Stateless session beans imply that they cannot hold a state that is of
>any meaning to the client. Thus it does not make sense for the client to
>try to pass in any kind of initialization parameter. If you want to pass
>extra information into the session, that should be done via ejb-jar.xml
>descriptor in the session's environment. If you describe why you need to do
>this, perhaps a better solution could be found.
>
>
> State full sessions beans are expensive, and cannot be cached or re-used
>by the container.
>
> -AP_
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
>[mailto:[EMAIL PROTECTED]]On Behalf Of Biske, Todd
> Sent: Thursday, January 24, 2002 2:58 PM
> To: [EMAIL PROTECTED]
> Subject: SFSB Question
>
>
>
> On the project I'm working on, we've got a situation where it would
>extremely valuable to be able to have parameterized ejbCreate() methods on
>our stateless session beans, but the spec doesn't allow for this (we could
>put them in, but they'd never get invoked).
>
> One alternative would be to use stateful session beans, which allow
>this type of functionality. The client would still be using the session
>bean in a stateless manner, however, e.g. one method call and it's done. Is
>anyone aware of the potential overhead implications of making all of the
>session beans stateful versus stateless? If it matters, the beans would be
>deployed under WL 6.1.
>
> The other alternative that we're currently heading down is to take the
>parameter we'd like to pass in to ejbCreate() and add it to all of the
>business methods defined in the remote/local interface.
>
> Thoughts?
> -tb
>
>
>
>
>
>****************************************************************************
>***********
> WARNING: All e-mail sent to and from this address will be received or
> otherwise recorded by the A.G. Edwards corporate e-mail system and is
> subject to archival, monitoring or review by, and/or disclosure to,
> someone other than the recipient.
>
>****************************************************************************
>***********
>
>
>
>
>
>****************************************************************************
>***********
> WARNING: All e-mail sent to and from this address will be received or
> otherwise recorded by the A.G. Edwards corporate e-mail system and is
> subject to archival, monitoring or review by, and/or disclosure to,
> someone other than the recipient.
>
>****************************************************************************
>***********
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
