Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <74e15baa0601300504i4b3069a9qd33f1ca36944f426@mail.gmail.com>
References: <3275C16D-E1E3-4FBE-A1A5-FCCF721CD58A@yahoo.com>
 <74e15baa0601300504i4b3069a9qd33f1ca36944f426@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <94E72415-2495-43B9-9B33-3304564DA9AC@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: Multiple servers sharing the same repo and config store
Date: Mon, 30 Jan 2006 08:08:40 -0800
To: dev@geronimo.apache.org

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 <david_jencks@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
>>
>>
>>