geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: Multiple servers sharing the same repo and config store
Date Sun, 19 Feb 2006 01:54:49 GMT
Hi,

The second solution has been implemented.

When starting G, it is now possible to specify one of these two system 
properties:
* org.apache.geronimo.server.name: name of the server to be started. If 
"server1" is specified, then G will use the directory <geronimo 
installation dir>/server1; or
* org.apache.geronimo.server.dir: directory of the server to be started. 
This can be either a relative or an absolute path. For instance, if 
"./server1" is specified, then G will use the directory <geronimo 
installation dir>/server1.

I still need to provide a patch for an AMQ GBean, 
JournalPersistenceAdapterGBean, in order to resolve its directory 
attribute based on the server directory - will do that during the day.

Thanks,
Gianny

David Jencks wrote:

>
> On Feb 12, 2006, at 9:17 AM, Vincent Massol wrote:
>
>> Hi David and everyone,
>>
>> Any progress on this?
>
>
> not yet, sorry.  it is pretty easy, but I am tied up in the configid  
> branch right now.
>
> david jencks
>
>>
>> Thanks
>> -Vincent
>>
>>> -----Original Message-----
>>> From: David Jencks [mailto:david_jencks@yahoo.com]
>>> Sent: lundi 30 janvier 2006 08:23
>>> To: dev@geronimo.apache.org
>>> Subject: Multiple servers sharing the same repo and config store
>>>
>>> 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