You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Gianny Damour (JIRA)" <de...@geronimo.apache.org> on 2006/02/19 02:40:25 UTC
[jira] Created: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Multiple servers sharing the same repo and config store
-------------------------------------------------------
Key: GERONIMO-1638
URL: http://issues.apache.org/jira/browse/GERONIMO-1638
Project: Geronimo
Type: New Feature
Components: usability
Versions: 1.0
Reporter: Gianny Damour
Assigned to: Gianny Damour
Fix For: 1.1
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
[jira] Updated: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "Prasad Kashyap (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Prasad Kashyap updated GERONIMO-1638:
-------------------------------------
Fix Version/s: (was: 2.0-M5)
2.0
> 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.
[jira] Commented: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12402251 ]
David Jencks commented on GERONIMO-1638:
----------------------------------------
Backported revisions r378827, r379430, r382366 in rev 406493. We still need to tweak the scripts.
> Multiple servers sharing the same repo and config store
> -------------------------------------------------------
>
> Key: GERONIMO-1638
> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
> Project: Geronimo
> Type: New Feature
> Security: public(Regular issues)
> Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: John Sisson
> Fix For: 1.2
>
> 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
[jira] Reopened: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "John Sisson (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=all ]
John Sisson reopened GERONIMO-1638:
-----------------------------------
The geronimo.sh & geronimo.bat startup scripts need to be updated to work with these changes. Assign to me if you want me to look into this.
> Multiple servers sharing the same repo and config store
> -------------------------------------------------------
>
> Key: GERONIMO-1638
> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
> Project: Geronimo
> Type: New Feature
> Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: Gianny Damour
> Fix For: 1.1
>
> 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
[jira] Commented: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "Gianny Damour (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415636 ]
Gianny Damour commented on GERONIMO-1638:
-----------------------------------------
Open a JIRA to fix the AMQ problem reported by Dave Colasurdo.
http://issues.apache.org/activemq/browse/AMQ-746
> Multiple servers sharing the same repo and config store
> -------------------------------------------------------
>
> Key: GERONIMO-1638
> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
> Project: Geronimo
> Type: New Feature
> Security: public(Regular issues)
> Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: John Sisson
> Fix For: 1.1
> 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
[jira] Commented: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "Gianny Damour (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12366943 ]
Gianny Damour commented on GERONIMO-1638:
-----------------------------------------
The second solution has been implemented.
When starting G, it is now possible to specify one of these two system properties:
* org.apache.geronimo.server.name: name of the server to be started. If "server1" is specified, then G will use the directory <geronimo installation dir>/server1; or
* org.apache.geronimo.server.dir: directory of the server to be started. This can be either a relative or an absolute path. For instance, if "./server1" is specified, then G will use the directory <geronimo installation dir>/server1.
> Multiple servers sharing the same repo and config store
> -------------------------------------------------------
>
> Key: GERONIMO-1638
> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
> Project: Geronimo
> Type: New Feature
> Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: Gianny Damour
> Fix For: 1.1
>
> 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
[jira] Updated: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "Matt Hogstrom (JIRA)" <ji...@apache.org>.
[ 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
[jira] Assigned: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "Gianny Damour (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=all ]
Gianny Damour reassigned GERONIMO-1638:
---------------------------------------
Assign To: John Sisson (was: Gianny Damour)
John, could you please have a look to the scripts?
Thanks
> Multiple servers sharing the same repo and config store
> -------------------------------------------------------
>
> Key: GERONIMO-1638
> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
> Project: Geronimo
> Type: New Feature
> Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: John Sisson
> Fix For: 1.1
>
> 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
Re: [jira] Commented: (GERONIMO-1638) Multiple servers sharing the
same repo and config store
Posted by Gianny Damour <gi...@optusnet.com.au>.
Hi Dave,
Thanks for pointing this problem out. I simply forget to provide an AMQ
patch to fix it; this is now done:
http://issues.apache.org/activemq/browse/AMQ-746.
Also, this feature is broken in 1.1. Basically, SharedLib and
FileKeystoreManager do not properly resolve their resources and, as a
consequence, the server simply shuts down.
Thanks,
Gianny
Dave Colasurdo wrote:
> BTW, I think additional fixes are required in 1.1.1 before claiming
> support for multiple concurrent server instances from a single
> installation..
>
> Awhile back I was able to start the server using an external var
> directory (via -Dorg.apache.geronimo.server.dir). After changing all
> the ports and trying to start a second instance from the default
> location, I encountered a startup exception regarding the activemq
> transaction journal. Suspect code changes are needed to relocate the
> journal to a location outside the installation directory.
>
> Thanks
> -Dave-
>
> John Sisson (JIRA) wrote:
>
>> [
>> http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415496
>> ]
>> John Sisson commented on GERONIMO-1638:
>> ---------------------------------------
>>
>> Currently working on scripts as discussed at
>> http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html .
>> Have made changes but they need to be tested on windows, cygwin and
>> unix, so looks like this is going to be for 1.1.1 .
>>
>>
>>
>>> Multiple servers sharing the same repo and config store
>>> -------------------------------------------------------
>>>
>>> Key: GERONIMO-1638
>>> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
>>> Project: Geronimo
>>> Type: New Feature
>>> Security: public(Regular issues) Components: usability
>>> Versions: 1.0
>>> Reporter: Gianny Damour
>>> Assignee: John Sisson
>>> Fix For: 1.1
>>
>>
>>> 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
>>
>>
>
>
Re: [jira] Commented: (GERONIMO-1638) Multiple servers sharing the
same repo and config store
Posted by Dave Colasurdo <da...@earthlink.net>.
BTW, I think additional fixes are required in 1.1.1 before claiming
support for multiple concurrent server instances from a single
installation..
Awhile back I was able to start the server using an external var
directory (via -Dorg.apache.geronimo.server.dir). After changing all
the ports and trying to start a second instance from the default
location, I encountered a startup exception regarding the activemq
transaction journal. Suspect code changes are needed to relocate the
journal to a location outside the installation directory.
Thanks
-Dave-
John Sisson (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415496 ]
>
> John Sisson commented on GERONIMO-1638:
> ---------------------------------------
>
> Currently working on scripts as discussed at http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html . Have made changes but they need to be tested on windows, cygwin and unix, so looks like this is going to be for 1.1.1 .
>
>
>
>> Multiple servers sharing the same repo and config store
>> -------------------------------------------------------
>>
>> Key: GERONIMO-1638
>> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
>> Project: Geronimo
>> Type: New Feature
>> Security: public(Regular issues)
>> Components: usability
>> Versions: 1.0
>> Reporter: Gianny Damour
>> Assignee: John Sisson
>> Fix For: 1.1
>
>> 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
>
[jira] Commented: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "John Sisson (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415496 ]
John Sisson commented on GERONIMO-1638:
---------------------------------------
Currently working on scripts as discussed at http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html . Have made changes but they need to be tested on windows, cygwin and unix, so looks like this is going to be for 1.1.1 .
> Multiple servers sharing the same repo and config store
> -------------------------------------------------------
>
> Key: GERONIMO-1638
> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
> Project: Geronimo
> Type: New Feature
> Security: public(Regular issues)
> Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: John Sisson
> Fix For: 1.1
>
> 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
[jira] Updated: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "Prasad Kashyap (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Prasad Kashyap updated GERONIMO-1638:
-------------------------------------
Patch Info: [Patch Available]
> 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.
[jira] Updated: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "Gianny Damour (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=all ]
Gianny Damour updated GERONIMO-1638:
------------------------------------
Attachment: GERONIMO-1638.patch
This is a patch which fixes a couple of relocation issues for SharedLib and FileKeystoreManager.
> Multiple servers sharing the same repo and config store
> -------------------------------------------------------
>
> Key: GERONIMO-1638
> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
> Project: Geronimo
> Type: New Feature
> Security: public(Regular issues)
> Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: John Sisson
> Fix For: 1.1
> 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
[jira] Closed: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "Gianny Damour (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=all ]
Gianny Damour closed GERONIMO-1638:
-----------------------------------
Resolution: Fixed
Committed.
> Multiple servers sharing the same repo and config store
> -------------------------------------------------------
>
> Key: GERONIMO-1638
> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
> Project: Geronimo
> Type: New Feature
> Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: Gianny Damour
> Fix For: 1.1
>
> 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
[jira] Updated: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "Matt Hogstrom (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=all ]
Matt Hogstrom updated GERONIMO-1638:
------------------------------------
Fix Version: 1.2
(was: 1.1)
> Multiple servers sharing the same repo and config store
> -------------------------------------------------------
>
> Key: GERONIMO-1638
> URL: http://issues.apache.org/jira/browse/GERONIMO-1638
> Project: Geronimo
> Type: New Feature
> Security: public(Regular issues)
> Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: John Sisson
> Fix For: 1.2
> 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
[jira] Closed: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (GERONIMO-1638) Multiple servers sharing the same
repo and config store
Posted by "John Sisson (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=all ]
John Sisson updated GERONIMO-1638:
----------------------------------
Fix Version: 1.1
(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
> Type: New Feature
> Security: public(Regular issues)
> Components: usability
> Versions: 1.0
> Reporter: Gianny Damour
> Assignee: John Sisson
> Fix For: 1.1
>
> 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