[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=all ]
Matt Hogstrom updated GERONIMO-1638:
------------------------------------
Fix Version/s: 1.x
2.0
(was: 1.2)
> Multiple servers sharing the same repo and config store
> -------------------------------------------------------
>
> Key: GERONIMO-1638
> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: usability
> Affects Versions: 1.0
> Reporter: Gianny Damour
> Assigned To: John Sisson
> Fix For: 1.x, 2.0
>
> Attachments: GERONIMO-1638.patch
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
