Paul;
I am somewhat of a newbie to EJB's, but I have a
simple suggestion that may work for you.
We found that with simple servlets, we lacked a global
cache. So we implemented a basic Servlet (not HTTP
servlet) and basically implemented an object store in
the servlet that was accessible (through some
libraries and convenience methods) to pretty much
manage all sorts of globally cached objects. We have
methods like:
Object getGlobalObject(String name)
void setGlobalObject(Object obj, String name)
Each object has a time out period if it implements an
interface that we designed.
So essentially, it is somewhat what you were looking
for.
//Nicholas
--- Paul Nicklin <[EMAIL PROTECTED]> wrote:
>
>
> I thought of that too - but I need attributes of the
> client at some lower levels
> in the app, so I have to pass it into the session
> bean and beyond... this seemed
> rather cumbersome.
> I notice that things like the security principal are
> passed into each bean's
> session context, and maybe what I need to do is try
> to exploit this.
>
> The key 'requirement' is to know which market the
> customer operates in so that
> business rules can be tailored to that market, most
> of the rules are the same
> (so the 'top level' session beans are identical) but
> lower down I divert
> according to market (using a class factory),
> currently I have these diversions
> as different session beans (and use JNDI) or classes
> (and use class loading).
> Ideally the class factory could use something
> 'environmental' to determine this,
> like the WebLogic userid, but unless the info is ON
> the security principal I
> must do an entity bean lookup each time I use the
> factory.
>
> I can't make is a system property because I have to
> run both simultaneously.
>
>
>
>
>
> (Embedded Chris Raber <[EMAIL PROTECTED]>
> image moved 24/01/2000 16:18
> to file:
> pic12829.pcx)
>
>
>
>
>
> Please respond to A mailing list for Enterprise
> JavaBeans development
> <[EMAIL PROTECTED]>
>
> To: [EMAIL PROTECTED]
> cc: (bcc: Paul Nicklin/GBPTD/ABB)
> Subject: Re: Equivalent of HTTPSession for an Java
> Application client
>
> Security Level:? Internal
>
>
>
> Why not simply keep client state in the client
> itself? Since you have a "fat
> client" you might was well use its RAM!
>
> -Chris.
>
> > -----Original Message-----
> > From: Paul Nicklin [SMTP:[EMAIL PROTECTED]]
> > Sent: Monday, January 24, 2000 5:22 AM
> > To: [EMAIL PROTECTED]
> > Subject: Equivalent of HTTPSession for an
> Java Application client
> >
> > I'm currently builing a Java client application
> using EJBs in the server.
> > I have to store information about the currently
> connected user, and I
> > can't find
> > a useful vehicle - I thought that the session
> context would work, but a
> > new one
> > is created per 'use' of the bean. If this were an
> HTTP (web page/JSP etc)
> > then I
> > could carry this info on the HTTP Session object,
> is there an equivalent
> > object
> > that 'follows' a particular connected client?
> > What is the alternative?
> >
> > Paul.
> >
> >
>
==========================================================================
> > =
> > 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".
>
>
>
>
>
>
>
> ATTACHMENT part 2 application/octet-stream
name=pic12829.pcx
=====
"Piper, Piper the red red worm
awoke last night to the sound of the storm
the words are the words I sailed upon."
Piper, Phish
--
Nicholas Whitehead
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
===========================================================================
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".
