[ https://issues.apache.org/jira/browse/GERONIMO-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks closed GERONIMO-1638. ---------------------------------- Resolution: Fixed I think if there are still problems with this anyone who might discover them should open a new issue. > Multiple servers sharing the same repo and config store > ------------------------------------------------------- > > Key: GERONIMO-1638 > URL: https://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 > Assignee: 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. - You can reply to this email to add a comment to the issue online.