geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Colasurdo <davec...@earthlink.net>
Subject Re: [jira] Commented: (GERONIMO-1638) Multiple servers sharing the same repo and config store
Date Fri, 09 Jun 2006 13:38:15 GMT
BTW, I think additional fixes are required in 1.1.1 before claiming 
support for multiple concurrent server instances from a single 
installation..

Awhile back I was able to start the server using an external var 
directory (via -Dorg.apache.geronimo.server.dir).  After changing all 
the ports and trying to start a second instance from the default 
location, I encountered a startup exception regarding the activemq 
transaction journal.  Suspect code changes are needed to relocate the 
journal to a location outside the installation directory.

Thanks
-Dave-

John Sisson (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415496
] 
> 
> John Sisson commented on GERONIMO-1638:
> ---------------------------------------
> 
> Currently working on scripts as discussed at http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html
. Have made changes but they need to be tested on windows, cygwin and unix, so looks like
this is going to be for 1.1.1 .
> 
> 
> 
>> Multiple servers sharing the same repo and config store
>> -------------------------------------------------------
>>
>>          Key: GERONIMO-1638
>>          URL: http://issues.apache.org/jira/browse/GERONIMO-1638
>>      Project: Geronimo
>>         Type: New Feature
>>     Security: public(Regular issues) 
>>   Components: usability
>>     Versions: 1.0
>>     Reporter: Gianny Damour
>>     Assignee: John Sisson
>>      Fix For: 1.1
> 
>> David J. sent to the dev mailing list:
>> Many people have talked on and off about how to set up multiple  servers sharing
the same repository and config-store, but we haven't  arrived at an agreed on way to do it.
 We have a prospective customer  for this feature (Vincent Massol with Cargo) so I'd like
to move  beyond thinking about it in my head, discuss it, and have someone  implement it.
 I believe any implementation will be more or less  trivial, the hard part is figuring out
what to do.
>> I've only thought of ways to extend what we have now, rather than  restructure anything
or add big new capabilities.  If someone sees a  better way, please speak up.
>> So, we have a ServerInfo gbean that knows where geronimo is located  and can resolve
absolute locations for other components.  Then we  have things like the repository and config
store gbeans that  typically are "located" outside the var dir and things like the  logging
framework,  local attribute manager, derby, and tomcat, that  typically keep stuff in the
var directory.
>> All or most of these start with the first configuration loaded so  they can't have
any attributes overridden by config.xml: in fact this  file is read by one of the gbeans that
we need to "relocate".
>> I've thought of two related solutions.  Both of them involve giving  ServerInfo knowledge
of another path and another resolve method.
>> One would be something like "resolveVar" and would normally resolve  to geronimo_home/var.
 This would involve all the gbeans currently  looking inside var having the "var" trimmed
off the front of their  paths and using the new resolveVar method.  In this case we'd have
 different servers represented as e.g.
>> var1
>> var2
>> var3
>> ...
>> The other would give ServerInfo something like resolveServer which  would normally
resolve to geronimo_home.  The gbeans looking inside  var would keep their current paths and
just call the new resolve  method instead of the old one.  In this case we'd have servers
like
>> var
>> server1/var
>> server2/var
>> ...
>> In either case I think starting geronimo with a command line argument  pointing to
the var directory is the only way to specify which server  you want to run; the default would
presumably be as now "var".
>> Several people have suggested putting an additional config-store into  var for "private"
use by a particular server.  At the moment I think   that providing a different config-store
class that uses the new  resolve  method on server info would be the best way to do this.
>> I'm not attached to these ideas but this is as far as my thinking has  gone.  Please
comment.
>> thanks
>> david jencks
> 

Mime
View raw message