Antonio, remove your email digital certificate. Most of us can not answer your question since the reply forcing us to have a digital certificate as well.
-Dan ----- Original Message ----- From: "Filip Hanik" <[EMAIL PROTECTED]> Newsgroups: Tomcat Sent: Sunday, June 15, 2003 10:59 AM Subject: RE: Singleton across multiple contexts > I have not followed this thread, > but putting the class in common/lib or shared/lib should make it a singleton > across contexts > > Filip > > > -----Original Message----- > > From: Antonio Fiol Bonnín [mailto:[EMAIL PROTECTED] > > Sent: Sunday, June 15, 2003 10:52 AM > > To: Tomcat Users List > > Subject: Re: Singleton across multiple contexts > > > > > > > > > > > > >>- Extract the component into a separate JVM, and connect to it > > via socket. > > >> > > >>This is what I'd do, but I'd also write a client class to get access. I > > >>suppose you could use RMI or something, but I'm not familiar with that. > > >>Whatever you're comfortable with, I guess. > > >> > > >>You could also spin off this class in it's own thread inside one of your > > >>classloaders. That way it would shutdown and start up with the server > > >>(or maybe that's a drawback...) and you wouldn't have to add the > > >>overhead of another VM. > > >> > > > > In fact, it *is* a thread. It starts and stops with the server. > > Everything was really beautiful until I had to split my app in four > > contexts. > > > > What I dislike is having to go out of the app to do app-internal calls. > > RMI, socket, CORBA, HTTP, ... I don't mind: I just dislike the idea. > > > > >>- Extract the component into another context, and connect to it > > via HTTP. > > >> > > >> > > > > > >yuck. > > > > > > > > >This isn't for locking or something is it? > > > > > > > Nope. ;-) > > > > > I get the feeling you're > > >trying to use a class for storing or accessing something the way most > > >people use a database... > > > > > > > I do have a database. Databases are supposed to store data, > > aren't they? ;-) > > > > Now seriously... My application includes a web interface to a "kind of" > > workflow system. > > > > This component is the "workflow engine", which is in charge for > > automatic (background) state changes and actions. When my > > business/persistence logic changes a state, new potential tasks for this > > "engine" arise. So it has to be notified (=called) from any context that > > may change a state. > > > > > > > > > > > >On Sun, 2003-06-15 at 08:21, Antonio Fiol Bonnín wrote: > > > > > > > > >>Hello, > > >> > > >>This question is probably not specific to Tomcat, but a Tomcat-specific > > >>answer could well suit my needs. > > >> > > >>I have an application which I have split in several different contexts. > > >>I have done so, to allow different kinds of access to the app, > > depending > > >>on the web server the requests are coming from. > > >> > > >>However, I need a common unique component that "ties" all the contexts > > >>together. > > >> > > >>There must be a *single* instance of this component, otherwise > > >>inconsistencies or duplicate work might arise. OTOH, it must be > > >>accessible from all the contexts. > > >> > > >>Calls to this component are very simple (calls to void methods) but > > >>moderately frequent. > > >> > > >>I have thought of several possibilities: > > >> > > >>- Extract the component into a separate JVM, and connect to it > > via socket. > > >>- Extract the component into another context, and connect to it > > via HTTP. > > >>--- I like none of those. > > >> > > >>- Create the instance from the first context needing it, and making it > > >>available to all of them. > > >>--- I like this best, but I have no idea of how to do that. > > >> > > >> > > >>Yours sincerely, > > >> > > >> > > >>Antonio Fiol > > >> > > >> > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
