Ok, here's another possibility... >From the plug-in, launch a daemon thread (daemon just in case the server has to go down before the thread is done, in which case it won't block the shutdown). Have the thread sleep for some amount of time, 30 seconds maybe, however long on average it takes your app to start up.
Then, the thread fires off a request to some known URL within your app. Just a simple GET using Commons HTTPClient sort of thing. Have that request execute an Action. Within the Action you can get all the info you need, so construct the URI and send it back to the thread. The thread then makes a request to the master, transmitting that constructed URL. The master then should have everything it needs and can go ahead and ping the slave just to be sure. Upon getting a good response back from the slave, the master returns to the thread a message saying "thanks very much, now die". The thread obliges and things should be good to go. What about something like that? If you don't like the whole spawning a thread in a servlet container thing, you should be able to do just about the same thing by sending a message to a JMS queue from your plug-in. That sounds like more work to me though, and I don't like more work :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Thu, March 16, 2006 3:47 pm, Leon Rosenberg said: > hmm, I suppose the poster wants to run a n workers for m applications > scenario with own load balancing, and wants to add new applications > and servers dynamically. > right? > > Leon > > On 3/16/06, Mark Lowe <[EMAIL PROTECTED]> wrote: >> On 3/16/06, Leon Rosenberg <[EMAIL PROTECTED]> wrote: >> > On 3/16/06, Mark Lowe <[EMAIL PROTECTED]> wrote: >> > > Why cant the master server provide the information, as i assume that >> > > some form of request is being made via a socket or otherwise to >> > > register the client? Even if no you can still do what you need by >> > > creating a socket or url connection to the master, and have the >> master >> > > send the details back. >> > > >> > > A bit like when folk ask me for my mobile phone number i never >> > > remember it.. So i get them to give me their number and i call them >> > > and hang up to give them my number.. >> > > >> > > It all seems a bit promiscuous for me, but it should work just >> fine.. >> > >> > No, because when in the webserver you have to unidirectional lines >> > instead of one bidirectional as in the mobile phone. Your caller >> > number is not the same as your callee number :-) >> >> Shit .. yeah, Oh well it was worth a go.. Still cant see why the >> master needs to request the gimp's url anyhow.. Could just send the >> /someaction.do?foo=bar back to the client in the response, at runtime >> (when the relevant actions are called). The master need never know >> anything about the gimp other than what it needs to respond.. send it >> back to the client and let the client do its thing.. >> >> still promiscuous and don't really see why it needs doing in a plugin.. >> >> > >> > > >> > > Mark >> > >> > regards >> > Leon >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
