Re: Multiple servers sharing the same repo and config store

[John Sisson <jr...@gmail.com>]

Some ideas..

Currently geronimo.sh/bat will invoke a setenv.sh script if present ( in 
the bin directory ).  Maybe we could enhance geronimo.sh/bin to also 
invoke a setenv.sh script if present under var for a particular geronimo 
instance.  So the setenv.sh script in geronimo/bin gets invoked first 
(allowing you to set env vars for all instances), followed by setenv.sh 
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?

John

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 <da...@yahoo.com> 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
>>>>
>>>>
>>>>
>>
>>
>>
>