No, EJB 1.0 didn't have what you are asking for. WebSphere 4 has a proprietary add-on called "Workspaces" (as an enterprise extension) that is exactly what you are looking for. I would also vote for adding a similar construct to the spec!
/johan -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Toby Weston Sent: den 28 januari 2002 15:57 To: [EMAIL PROTECTED] Subject: Re: SFSB Question 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". =========================================================================== 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".
