Re: Multiple servers sharing the same repo and config store
Thanks for the suggestion. This has been implemented. Gianny John Sisson wrote: Gianny, I think we should change the org.apache.geronimo.base.dir property to be org.apache.geronimo.home.dir so it is consistent in meaning with Tomcat's usage of the terms home and base to avoid confusion. In Tomcat: home = the installation directory base = the base directory used for resolving dynamic portions of the Tomcat installation (defaults to home if not set) John Gianny Damour wrote: Hi, This change adds the ability to start multiple server instances against the same bin, config-store, deploy, lib, repository and shema folders of a Geronimo installation. An additional instance can be set-up by copying the var folder to the directory where you want to create a new instance. Then, from the new server directory, you can start the new instance like this: java -Dorg.apache.geronimo.base.dir=Geronimo installation directory -Dorg.apache.geronimo.server.dir=new server directory -jar Geronimo installation directory/bin/server.jar * org.apache.geronimo.base.dir is the full path of the directory where Geronimo has been installed, i.e. it is the directory containing the config-store and repository to be shared; and * org.apache.geronimo.server.dir is the full path of the directory where the new instance has been set-up. This is in this directory that the instance specific working files are created, i.e. the stuff in var. Note that the value of this property can be either an absolute or relative directory. If a relative directory is specified, then it is resolved based on the Geronimo installation directory. If you are happy to start a new instance under the same Geronimo installation directory, then you can create a new nested folder and copy var into it. Then, from the Geronimo installation directory, you can start this new instance like this: java -Dorg.apache.geronimo.server.name=nested folder name -jar bin/server.jar * org.apache.geronimo.server.name is the name of the nested folder. This has a similar effect than starting with org.apache.geronimo.server.dir set to the relative path of the nested folder. Thanks, Gianny Dave Colasurdo wrote: Can you please elaborate a bit more on what exactly this provides? Can I now have two separate instances each with their own unique applications/configurations/logs (i.e. config-store, deploy and var directories) sharing the same geronimo installation binaries (i.e. bin, lib and repository directories)? If so, how do we create the additional instances? I assume the binary distribution creates the the first instance during the build and that users need to create the additional instances manually for now.. Thanks -Dave- Gianny Damour wrote: Hi, 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. I still need to provide a patch for an AMQ GBean, JournalPersistenceAdapterGBean, in order to resolve its directory attribute based on the server directory - will do that during the day. Thanks, Gianny
Re: Multiple servers sharing the same repo and config store
Gianny, I think we should change the org.apache.geronimo.base.dir property to be org.apache.geronimo.home.dir so it is consistent in meaning with Tomcat's usage of the terms home and base to avoid confusion. In Tomcat: home = the installation directory base = the base directory used for resolving dynamic portions of the Tomcat installation (defaults to home if not set) John Gianny Damour wrote: Hi, This change adds the ability to start multiple server instances against the same bin, config-store, deploy, lib, repository and shema folders of a Geronimo installation. An additional instance can be set-up by copying the var folder to the directory where you want to create a new instance. Then, from the new server directory, you can start the new instance like this: java -Dorg.apache.geronimo.base.dir=Geronimo installation directory -Dorg.apache.geronimo.server.dir=new server directory -jar Geronimo installation directory/bin/server.jar * org.apache.geronimo.base.dir is the full path of the directory where Geronimo has been installed, i.e. it is the directory containing the config-store and repository to be shared; and * org.apache.geronimo.server.dir is the full path of the directory where the new instance has been set-up. This is in this directory that the instance specific working files are created, i.e. the stuff in var. Note that the value of this property can be either an absolute or relative directory. If a relative directory is specified, then it is resolved based on the Geronimo installation directory. If you are happy to start a new instance under the same Geronimo installation directory, then you can create a new nested folder and copy var into it. Then, from the Geronimo installation directory, you can start this new instance like this: java -Dorg.apache.geronimo.server.name=nested folder name -jar bin/server.jar * org.apache.geronimo.server.name is the name of the nested folder. This has a similar effect than starting with org.apache.geronimo.server.dir set to the relative path of the nested folder. Thanks, Gianny Dave Colasurdo wrote: Can you please elaborate a bit more on what exactly this provides? Can I now have two separate instances each with their own unique applications/configurations/logs (i.e. config-store, deploy and var directories) sharing the same geronimo installation binaries (i.e. bin, lib and repository directories)? If so, how do we create the additional instances? I assume the binary distribution creates the the first instance during the build and that users need to create the additional instances manually for now.. Thanks -Dave- Gianny Damour wrote: Hi, 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. I still need to provide a patch for an AMQ GBean, JournalPersistenceAdapterGBean, in order to resolve its directory attribute based on the server directory - will do that during the day. Thanks, Gianny
Re: Multiple servers sharing the same repo and config store
+1 -dain On Mar 1, 2006, at 2:49 AM, John Sisson wrote: Gianny, I think we should change the org.apache.geronimo.base.dir property to be org.apache.geronimo.home.dir so it is consistent in meaning with Tomcat's usage of the terms home and base to avoid confusion. In Tomcat: home = the installation directory base = the base directory used for resolving dynamic portions of the Tomcat installation (defaults to home if not set) John Gianny Damour wrote: Hi, This change adds the ability to start multiple server instances against the same bin, config-store, deploy, lib, repository and shema folders of a Geronimo installation. An additional instance can be set-up by copying the var folder to the directory where you want to create a new instance. Then, from the new server directory, you can start the new instance like this: java -Dorg.apache.geronimo.base.dir=Geronimo installation directory -Dorg.apache.geronimo.server.dir=new server directory -jar Geronimo installation directory/bin/server.jar * org.apache.geronimo.base.dir is the full path of the directory where Geronimo has been installed, i.e. it is the directory containing the config-store and repository to be shared; and * org.apache.geronimo.server.dir is the full path of the directory where the new instance has been set-up. This is in this directory that the instance specific working files are created, i.e. the stuff in var. Note that the value of this property can be either an absolute or relative directory. If a relative directory is specified, then it is resolved based on the Geronimo installation directory. If you are happy to start a new instance under the same Geronimo installation directory, then you can create a new nested folder and copy var into it. Then, from the Geronimo installation directory, you can start this new instance like this: java -Dorg.apache.geronimo.server.name=nested folder name -jar bin/server.jar * org.apache.geronimo.server.name is the name of the nested folder. This has a similar effect than starting with org.apache.geronimo.server.dir set to the relative path of the nested folder. Thanks, Gianny Dave Colasurdo wrote: Can you please elaborate a bit more on what exactly this provides? Can I now have two separate instances each with their own unique applications/configurations/logs (i.e. config-store, deploy and var directories) sharing the same geronimo installation binaries (i.e. bin, lib and repository directories)? If so, how do we create the additional instances? I assume the binary distribution creates the the first instance during the build and that users need to create the additional instances manually for now.. Thanks -Dave- Gianny Damour wrote: Hi, 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. I still need to provide a patch for an AMQ GBean, JournalPersistenceAdapterGBean, in order to resolve its directory attribute based on the server directory - will do that during the day. Thanks, Gianny
Re: Multiple servers sharing the same repo and config store
Hi, This change adds the ability to start multiple server instances against the same bin, config-store, deploy, lib, repository and shema folders of a Geronimo installation. An additional instance can be set-up by copying the var folder to the directory where you want to create a new instance. Then, from the new server directory, you can start the new instance like this: java -Dorg.apache.geronimo.base.dir=Geronimo installation directory -Dorg.apache.geronimo.server.dir=new server directory -jar Geronimo installation directory/bin/server.jar * org.apache.geronimo.base.dir is the full path of the directory where Geronimo has been installed, i.e. it is the directory containing the config-store and repository to be shared; and * org.apache.geronimo.server.dir is the full path of the directory where the new instance has been set-up. This is in this directory that the instance specific working files are created, i.e. the stuff in var. Note that the value of this property can be either an absolute or relative directory. If a relative directory is specified, then it is resolved based on the Geronimo installation directory. If you are happy to start a new instance under the same Geronimo installation directory, then you can create a new nested folder and copy var into it. Then, from the Geronimo installation directory, you can start this new instance like this: java -Dorg.apache.geronimo.server.name=nested folder name -jar bin/server.jar * org.apache.geronimo.server.name is the name of the nested folder. This has a similar effect than starting with org.apache.geronimo.server.dir set to the relative path of the nested folder. Thanks, Gianny Dave Colasurdo wrote: Can you please elaborate a bit more on what exactly this provides? Can I now have two separate instances each with their own unique applications/configurations/logs (i.e. config-store, deploy and var directories) sharing the same geronimo installation binaries (i.e. bin, lib and repository directories)? If so, how do we create the additional instances? I assume the binary distribution creates the the first instance during the build and that users need to create the additional instances manually for now.. Thanks -Dave- Gianny Damour wrote: Hi, 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. I still need to provide a patch for an AMQ GBean, JournalPersistenceAdapterGBean, in order to resolve its directory attribute based on the server directory - will do that during the day. Thanks, Gianny
Re: Multiple servers sharing the same repo and config store
Can you please elaborate a bit more on what exactly this provides? Can I now have two separate instances each with their own unique applications/configurations/logs (i.e. config-store, deploy and var directories) sharing the same geronimo installation binaries (i.e. bin, lib and repository directories)? If so, how do we create the additional instances? I assume the binary distribution creates the the first instance during the build and that users need to create the additional instances manually for now.. Thanks -Dave- Gianny Damour wrote: Hi, 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. I still need to provide a patch for an AMQ GBean, JournalPersistenceAdapterGBean, in order to resolve its directory attribute based on the server directory - will do that during the day. Thanks, Gianny David Jencks wrote: On Feb 12, 2006, at 9:17 AM, Vincent Massol wrote: Hi David and everyone, Any progress on this? not yet, sorry. it is pretty easy, but I am tied up in the configid branch right now. david jencks Thanks -Vincent -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 08:23 To: dev@geronimo.apache.org Subject: Multiple servers sharing the same repo and config store 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: Multiple servers sharing the same repo and config store
Hi, 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. I still need to provide a patch for an AMQ GBean, JournalPersistenceAdapterGBean, in order to resolve its directory attribute based on the server directory - will do that during the day. Thanks, Gianny David Jencks wrote: On Feb 12, 2006, at 9:17 AM, Vincent Massol wrote: Hi David and everyone, Any progress on this? not yet, sorry. it is pretty easy, but I am tied up in the configid branch right now. david jencks Thanks -Vincent -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 08:23 To: dev@geronimo.apache.org Subject: Multiple servers sharing the same repo and config store 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: Multiple servers sharing the same repo and config store
On Feb 12, 2006, at 9:17 AM, Vincent Massol wrote: Hi David and everyone, Any progress on this? not yet, sorry. it is pretty easy, but I am tied up in the configid branch right now. david jencks Thanks -Vincent -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 08:23 To: dev@geronimo.apache.org Subject: Multiple servers sharing the same repo and config store 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: Multiple servers sharing the same repo and config store
Hi David and everyone, Any progress on this? Thanks -Vincent -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 08:23 To: dev@geronimo.apache.org Subject: Multiple servers sharing the same repo and config store 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: Multiple servers sharing the same repo and config store
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 [EMAIL PROTECTED] 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
Re: Multiple servers sharing the same repo and config store
I'm not sure if you are suggesting it would be possible for two geronimo instances to share a var/config directory - that would not work as each instance would be attempting to do updates of the one config.xml file. This may also have problems with two instances trying to write log files, journal files of the same name etc. John Paul McMahan wrote: As a programmer type it seems intuitive to me that the presence of a subdir in an alternate server root overrides the default while its absence makes the server instance inherit the default. But its possible that I am mingling system administration with too much OO. At any rate I agree that having to examine the command line and then the alternate server root directory to figure out which repository directory (or var, or config-store, etc.) is in use could be error-prone for some. An informative message shown at the beginning of startup that shows which directories are mapped into the server instance could help. I can think of a few other ways to address this concern but they all tend to sacrifice flexibility or intuitiveness. BTW, I'm not suggesting that the subdirs of the alternate server root directory get weaved into the subdirs of geronimo_home, as that approach *does* seem too indeterminate to me. Oh, and one more thing I'm wondering is how Sachin's req for running applications from within a dev environment might play into this new feature. Seems that ideally the solution for the var subdir would be consistent with the solution for config-store, repository, and whatever else we decide to put in geronimo_home in the future. Here's the JIRA for that req: https://issues.apache.org/jira/browse/GERONIMO-1526 Best wishes, Paul On 1/30/06, *David Jencks* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'm not sure I like that, because IIUC it would mean that the main repository gbean for instance would be looking at different repos depending on both a command line switch and whether a particular directory existed. At the moment I think that is too indeterminate. I would prefer to have each repo gbean point to a single well defined location and to add more repositories for customization. You might be able to argue me out of this position. thanks david jencks
RE: Multiple servers sharing the same repo and config store
Big +1 to either :-) Thanks David -Vincent -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 08:23 To: dev@geronimo.apache.org Subject: Multiple servers sharing the same repo and config store 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: Multiple servers sharing the same repo and config store
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 [EMAIL PROTECTED] 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
Re: Multiple servers sharing the same repo and config store
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 [EMAIL PROTECTED] 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
Re: Multiple servers sharing the same repo and config store
Hi, In WebSphere this is the directory organization: $WAS_HOME/config/cells/$CELL_NAME applications (EAR/WAR/RAR) nodes .$NODE_NAME ..servers (JVM Configurations) ..$SERVER_NAME ..server.xml ..resources.xml ..variables.xmlThe applications are deployed by default in $WAS_HOME/installedApps but the administrator can change the directory (this is a cool functionality)I think that BEA Weblogic has a similar architecture.In WAS 6 there is a new concept (profile).Bye, Dain Sundstrom [EMAIL PROTECTED] escribió: Does anyone know how other J2EE servers structure their directories when they have multiple instances configured?-dainOn 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 store s, 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 <[EMAIL PROTECTED]>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 t hey 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 __Correo Yahoo!Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
Re: Multiple servers sharing the same repo and config store
One approach that seems user friendly to me would be to allow the user to pass an argument to Geronimo startup specifying a server root directory. The immediate subdirectories of this server root directory would trump those in geronimo_home for that server instance. Using this technique would allow the user to make any combination of geronimo's customizable parts shared across all server instances or tailored to a specific server instance. Best wishes, Paul On 1/30/06, David Jencks [EMAIL PROTECTED] wrote: Many people have talked on and off about how to set up multipleservers sharing the same repository and config-store, but we haven'tarrived at an agreed on way to do it.We have a prospective customerfor this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someoneimplement it.I believe any implementation will be more or lesstrivial, 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 abetter way, please speak up.So, we have a ServerInfo gbean that knows where geronimo is locatedand can resolve absolute locations for other components.Then we have things like the repository and config store gbeans thattypically are located outside the var dir and things like thelogging framework,local attribute manager, derby, and tomcat, thattypically keep stuff in the var directory. All or most of these start with the first configuration loaded sothey can't have any attributes overridden by config.xml: in fact thisfile is read by one of the gbeans that we need to relocate. I've thought of two related solutions.Both of them involve givingServerInfo 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 currentlylooking inside var having the var trimmed off the front of theirpaths and using the new resolveVar method.In this case we'd have different servers represented as e.g.var1var2var3...The other would give ServerInfo something like resolveServer whichwould normally resolve to geronimo_home.The gbeans looking inside var would keep their current paths and just call the new resolvemethod instead of the old one.In this case we'd have servers likevarserver1/varserver2/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 serveryou 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 thinkthat providing a different config-store class that uses the newresolvemethod 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 hasgone.Please comment.thanksdavid jencks
Re: Multiple servers sharing the same repo and config store
On Jan 30, 2006, at 8:54 AM, Paul McMahan wrote:One approach that seems user friendly to me would be to allow the user to pass an argument to Geronimo startup specifying a "server root" directory. The immediate subdirectories of this server root directory would trump those in geronimo_home for that server instance. Using this technique would allow the user to make any combination of geronimo's customizable parts shared across all server instances or tailored to a specific server instance.I'm not sure I like that, because IIUC it would mean that the main repository gbean for instance would be looking at different repos depending on both a command line switch and whether a particular directory existed. At the moment I think that is too indeterminate. I would prefer to have each repo gbean point to a single well defined location and to add more repositories for customization.You might be able to argue me out of this position.thanksdavid jencks Best wishes, Paul On 1/30/06, David Jencks [EMAIL PROTECTED] wrote: Many people have talked on and off about how to set up multipleservers sharing the same repository and config-store, but we haven'tarrived at an agreed on way to do it. We have a prospective customerfor this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someoneimplement it. I believe any implementation will be more or lesstrivial, 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 abetter way, please speak up.So, we have a ServerInfo gbean that knows where geronimo is locatedand can resolve absolute locations for other components. Then we have things like the repository and config store gbeans thattypically are "located" outside the var dir and things like thelogging framework, local attribute manager, derby, and tomcat, thattypically keep stuff in the var directory. All or most of these start with the first configuration loaded sothey can't have any attributes overridden by config.xml: in fact thisfile is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve givingServerInfo 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 currentlylooking inside var having the "var" trimmed off the front of theirpaths and using the new resolveVar method. In this case we'd have different servers represented as e.g.var1var2var3...The other would give ServerInfo something like resolveServer whichwould normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolvemethod instead of the old one. In this case we'd have servers likevarserver1/varserver2/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 serveryou 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 thinkthat providing a different config-store class that uses the newresolve 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 hasgone. Please comment.thanksdavid jencks
Re: Multiple servers sharing the same repo and config store
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 [EMAIL PROTECTED] 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
Re: Multiple servers sharing the same repo and config store
As a programmer type it seems intuitive to me that the presence of a subdir in an alternate server root overrides the default while its absence makes the server instance inherit the default. But its possible that I am mingling system administration with too much OO. At any rate I agree that having to examine the command line and then the alternate server root directory to figure out which repository directory (or var, or config-store, etc.) is in use could be error-prone for some. An informative message shown at the beginning of startup that shows which directories are mapped into the server instance could help. I can think of a few other ways to address this concern but they all tend to sacrifice flexibility or intuitiveness. BTW, I'm not suggesting that the subdirs of the alternate server root directory get weaved into the subdirs of geronimo_home, as that approach *does* seem too indeterminate to me. Oh, and one more thing I'm wondering is how Sachin's req for running applications from within a dev environment might play into this new feature. Seems that ideally the solution for the var subdir would be consistent with the solution for config-store, repository, and whatever else we decide to put in geronimo_home in the future. Here's the JIRA for that req: https://issues.apache.org/jira/browse/GERONIMO-1526 Best wishes, Paul On 1/30/06, David Jencks [EMAIL PROTECTED] wrote: I'm not sure I like that, because IIUC it would mean that the main repository gbean for instance would be looking at different repos depending on both a command line switch and whether a particular directory existed. At the moment I think that is too indeterminate. I would prefer to have each repo gbean point to a single well defined location and to add more repositories for customization.You might be able to argue me out of this position.thanksdavid jencks
