Are these slaves servers that you have some degree of control over? I
ask because if so, can you just dictate that they have to run on some
known port, and then you can still get the rest of the information
dynamically.
Or, almost as good... although my idea of scanning for the port was
obviously a bit tongue-in-cheek, what if you could say that you app has
to run on one of a few known ports? Scanning 5-10 possible ports might
not be so unreasonable. To reiterate, the basic idea was that you send
a request from the plugin to the same server, on a given port, and see
if you get a specific response. I *think* it would work, and like I
said, might not be so bad if it's only a handful of possible ports.
Just trying to think out of the box a bit since a simple solution
doesn't seem to be forthcoming from any of us :)
Frank
Wojciech Ciesielski wrote:
I didn't expect to trigger such an elaborate discussion ;-)
Personally, I still think that parsing the server.xml and the
context.xml or whatever config files the webserver is using is the
second best option.
There is another problem - how can you get path to tomcat root directory?
It's not that obvious... I can easily obtain real absolute path to directory
where application is deployed but it does not have to be within tomcat
(context registered outside tomcat root). Also acquiring working directory
from java system properties is not ok because it changes - for example when
tomcat is launched from within Eclipse during development then java working
dir is set to Eclipse home...
The best option imho would be simply configure it with an external
configuration file / system and don't spend too much time with magic
and trickery.
The point is that we are preparing processing system with unknown
(dynamically changing) amount of slave servers. What we were trying to
achieve is:
- ease of deployment on 20-100 machines. That's why setting different params
in some config file for each server, packaging the WAR and sending it to the
server would be pain in the ... ;-) It's also a reason for choosing
tomcat-deployed web-apps as processing units - it's very easy to deploy on
multiple machines...
- possibility of coexistence of different versions of processing software on
one machine. It's up to master application what servers are going to be used
at particular processing
- ability to easily access particular processing unit, see it's statistics
and logs, alter it's configuration etc. That's why using web-applications
with some administration tools was chosen
---------------------------------------------------------------------
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]
