geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: Multiple servers sharing the same repo and config store
Date Wed, 01 Feb 2006 22:49:32 GMT
Some ideas..

Currently will invoke a script if present ( in 
the bin directory ).  Maybe we could enhance to also 
invoke a script if present under var for a particular geronimo 
instance.  So the script in geronimo/bin gets invoked first 
(allowing you to set env vars for all instances), followed by 
in myinstance/var/bin (allowing you to append or override the env vars 
that may have been set earlier).

If we have multiple Geronimo instances, then shouldn't each instance 
need a J2EEServer name that is part of the JSR-77 J2EEManagedObject 
name? Could this name and maybe the server name be associated with names 
in the directory structure.  How do we envision the J2EEServer name 
being specified?


Dave Colasurdo wrote:
> As far as directory structure, it seems that WebSphere separates the 
> binaries (e.g. jars, scripts) from the instance data.  Each instance 
> has it's own copy of configuration data, installed applications, logs 
> and properties.  The scripts (e.g. startup/shutdown) are also 
> available in each instance such that the user doesn't need to specify 
> any environmental variables or parameters to indicate "which instance" 
> when executing the scripts.
> -Dave-
> Dain Sundstrom wrote:
>> Does anyone know how other J2EE servers structure their directories 
>> when they have multiple instances configured?
>> -dain
>> On Jan 30, 2006, at 5:04 AM, Aaron Mulder wrote:
>>> This sounds reasonable to me.  I'd prefer to have resolveServer and
>>> always look for /var under there.  If there are multiple config
>>> stores, we'll have to figure out how the deploy tool will know which
>>> one to use.  Perhaps there should be something indicating whether the
>>> config store is "writable" at runtime (vs at server construction time)
>>> and only the server-specific one would be writeable?  Or at least, the
>>> tools would default to writeable ones over not?  (Right now they'd
>>> theoretically deploy to all available config stores, but I think
>>> there's an outstanding issue that the Deployer GBean doesn't let you
>>> specify a config store even if you wanted to.)
>>> Thanks,
>>>     Aaron
>>> On 1/30/06, David Jencks <> wrote:
>>>> 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

View raw message