You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Ted Kirby <te...@gmail.com> on 2007/01/26 15:40:00 UTC
Why is GERONIMO_HOME not passed into the server?
Providing the org.apache.geronimo.home.dir system property to allow
the home directory to be passed in is good, but if this is not used
(and I'd don't feel it should be required/used in the normal case),
DirectoryUtils.getGeronimoInstallDirectory() is used to determine the
home directory. This method uses machinations that do not resolve
correctly if the home directory is a symbolic link. Since the
invoking geronimo script sets and uses GERONIMO_HOME, why does it not
pass this value into the server? I would think that BasicServerInfo
would want to set baseDirectory to GERONIMO_HOME (if the
org.apache.geronimo.home.dir system property is not set), and invoke
DirectoryUtils.getGeronimoInstallDirectory() only if GERONIMO_HOME is
not set.
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jan 27, 2007, at 8:09 PM, David Jencks wrote:
> AFAIK support for everything needed to do this is already there,
> all you need is another module with an additional repository which
> might be located by default in var/repository.
>
> Existing command line properties:
> -Dorg.apache.geronimo.home.dir=/path/to/geronimo/home speciifies
> where the geronimo installation (bin dir etc) are located. I
> haven't figured out how this is useful yet.... but its there.
> -Dorg.apache.geronimo.server.name=foo makes geronimo look for var
> at <geronimo_home>/foo
> -Dorg.apache.geronimo.server.dir=/path/to/var/dir specifies where
> var is as an absolute path (if you don't supply a absolute path,
> its the same as "name")
>
> We support running with multiple repositories, and deploying to a
> specific repository with a deployer command line argument
> java -jar bin/deployer.jar -target repo-name
>
Some of it is in place. I was playing with it last week. Its still
a little rough in that you have to manually create the directory
structure. I don't remember all the details but I think Gianny did
start on this and has most of the hard work done :)
Re: Why is GERONIMO_HOME not passed into the server?
Posted by David Jencks <da...@yahoo.com>.
On Jan 30, 2007, at 7:13 AM, Ted Kirby wrote:
> On 1/29/07, David Jencks <da...@yahoo.com> wrote:
>> One slight convenience I thought of would be to add a flag to the
>> Maven2Repository to determine if it resolves root against the base or
>> server directory from serverinfo. With what we have now, you'd
>> presumably put the new repo inside var, but then if you used the
>> command line to relocate var, you'd have to override the root
>> location in config.xml so the correct repo was picked up. With a
>> flag in the repo gbean, the standard repo could be resolved against
>> base but the additional repo from the plugin could be resolved
>> against server.
>
> I think that is a good suggestion. You mean adding an attribute, like
> "relative" or "rootBase", which would support values of "server" or
> "base"? The code currently checks if root is absolute, but we could
> allow a value of "absolute".
I was actually thinking of a boolean attribute resolveToServer so if
you left it out you'd get the current behavior.
>
> My other question is, what about hot deployment? I am not that
> familiar with how it works. In what repo are hot-deployed
> applications placed? Is there a way to configure it? It seems now
> that if you don't specify a target on deploy, the module is deployed
> to *all* repos. I don't think that is the best default, in light of
> this separation and sharing discussion.
>
I don't know if it already has one, but I'd add a targetConfigStore
attribute or reference to the hot deployer gbean.
thanks
david jencks
> Thanks
> Ted Kirby
>
>> thanks
>> david jencks
>>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Ted Kirby <te...@gmail.com>.
On 1/29/07, David Jencks <da...@yahoo.com> wrote:
> One slight convenience I thought of would be to add a flag to the
> Maven2Repository to determine if it resolves root against the base or
> server directory from serverinfo. With what we have now, you'd
> presumably put the new repo inside var, but then if you used the
> command line to relocate var, you'd have to override the root
> location in config.xml so the correct repo was picked up. With a
> flag in the repo gbean, the standard repo could be resolved against
> base but the additional repo from the plugin could be resolved
> against server.
I think that is a good suggestion. You mean adding an attribute, like
"relative" or "rootBase", which would support values of "server" or
"base"? The code currently checks if root is absolute, but we could
allow a value of "absolute".
My other question is, what about hot deployment? I am not that
familiar with how it works. In what repo are hot-deployed
applications placed? Is there a way to configure it? It seems now
that if you don't specify a target on deploy, the module is deployed
to *all* repos. I don't think that is the best default, in light of
this separation and sharing discussion.
Thanks
Ted Kirby
> thanks
> david jencks
>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by David Jencks <da...@yahoo.com>.
I'm really glad someone took the time to check that this actually
works!. I'd like to see it be a standard plugin. IIRC there might
be some way to get the plugin machinery to create the directory for you?
One slight convenience I thought of would be to add a flag to the
Maven2Repository to determine if it resolves root against the base or
server directory from serverinfo. With what we have now, you'd
presumably put the new repo inside var, but then if you used the
command line to relocate var, you'd have to override the root
location in config.xml so the correct repo was picked up. With a
flag in the repo gbean, the standard repo could be resolved against
base but the additional repo from the plugin could be resolved
against server.
thanks
david jencks
On Jan 28, 2007, at 1:20 PM, Ted Kirby wrote:
> On 1/27/07, David Jencks <da...@yahoo.com> wrote:
>> AFAIK support for everything needed to do this is already there, all
>> you need is another module with an additional repository which might
>> be located by default in var/repository.
>>
>> Existing command line properties:
>> -Dorg.apache.geronimo.home.dir=/path/to/geronimo/home speciifies
>> where the geronimo installation (bin dir etc) are located. I haven't
>> figured out how this is useful yet.... but its there.
>> -Dorg.apache.geronimo.server.name=foo makes geronimo look for var at
>> <geronimo_home>/foo
>> -Dorg.apache.geronimo.server.dir=/path/to/var/dir specifies where var
>> is as an absolute path (if you don't supply a absolute path, its the
>> same as "name")
>>
>> We support running with multiple repositories, and deploying to a
>> specific repository with a deployer command line argument
>> java -jar bin/deployer.jar -target repo-name
>>
>> All we need is to add another module/configuration that has a
>> repository gbean and a config store gbean pointing to var/
>> repository. I think this should be a plugin.
>
> This second repo stuff is just way cool! It also works, in 1.1 and
> 2.0!
>
> Here is my repo2.xml plan:
>
> <module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.2">
> <environment>
> <moduleId>
> <groupId>org.example.configs</groupId>
> <artifactId>myrepo</artifactId>
> <version>2.0-SNAPSHOT</version>
> <type>car</type>
> </moduleId>
> <dependencies>
> <dependency>
> <groupId>org.apache.geronimo.configs</groupId>
> <artifactId>j2ee-system</artifactId>
> <version>2.0-SNAPSHOT</version>
> <type>car</type>
> </dependency>
> </dependencies>
> <hidden-classes/>
> <non-overridable-classes/>
> </environment>
> <!--Repository-->
> <gbean name="Repo2"
> class="org.apache.geronimo.system.repository.Maven2Repository">
> <attribute name="root">repo2/</attribute>
> <reference name="ServerInfo">
> <name>ServerInfo</name>
> </reference>
> </gbean>
> <!--Configuration Store service-->
> <gbean name="Local2"
> class="org.apache.geronimo.system.configuration.RepositoryConfiguratio
> nStore">
> <reference name="Repository">
> <name>Repo2</name>
> </reference>
> </gbean>
> </module>
>
> mkdir <germonimo_home/repo2
>
> deploy repo2.xml
>
> The target names are long and cumbersome:
>> java deployer.jar list-targets
>
> Available Targets:
> org.example.configs/myrepo/2.0-SNAPSHOT/car?
> ServiceModule=org.example.configs/myrepo/2.0-SNAPSHOT/
> car,j2eeType=ConfigurationStore,name=Local2
> org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?
> ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/
> car,j2eeType=ConfigurationStore,name=Local
>
> Use of environment variables recommended for command-line use.
>
> To deploy to the new repo, use:
>
> deploy --targets %REPO2% sample.war
>
> deploy list-modules also gives those long target names on each module.
>
> However, deploy list-modules %REPO2% gives the accustomed short
> output.
>
>> So, I don't think this requires any code, just someone to write the
>> module plan and check everything works. I don't see how this affects
>> the server file structure except for the already present capability
>> to relocate var.
>>
>> Not everyone will want to have a separate per server additional
>> repository for running many servers off one files system copy. For
>> instance if all the servers use the same apps you might as well
>> deploy them all to the regular repository.
>>
>> thanks
>> david jencks
>>
>> On Jan 27, 2007, at 2:38 PM, Jason Dillon wrote:
>>
>> > I think in order to allow multiple instances to work off of the
>> > same installation effectively we need to have a tiered repository
>> > support, so that each instance could include a shared read-only
>> > repository (the system repository), and then a read-write
>> > repository (instance repository), where artifact resolution would
>> > first check the instance repo, then the system repo.
>> >
>> > If we do want to start supporting this, I suggest we also revisit
>> > the basic server's file structure, as we will need to insert a
>> > hierarchy for the instance data.
>> >
>> > --jason
>> >
>> >
>> > On Jan 27, 2007, at 1:51 PM, Matt Hogstrom wrote:
>> >
>> >> I've been looking at this recently interms of being able to run
>> >> multiple oag instances out of the same filesystem. This means we
>> >> need to identify several different points in the filesystem. This
>> >> is not exhaustive but really for discussion since Ted brought
>> it up.
>> >>
>> >> One is the location of the Geronimo server. I'll refer to this as
>> >> $GERONIMO_HOME. This directory is the root of the Geronimo
>> >> installation.
>> >>
>> >> The next Location is the $GERONIMO_INSTANCE which would contain
>> >> the parts of the repository that an individual instance would
>> >> need. This would include a repository, var entries for config,
>> >> logs, etc. One approach would be to make the GERONIMO_INSTANCE be
>> >> a shadow of the normal dir structure for GERONIMO_HOME that is
>> >> only populated with items that are different from the base
>> >> install. I think this would include things like:
>> >>
>> >> ./repository
>> >> ./lib
>> >> ./var/log
>> >> config
>> >> activemq
>> >> howl
>> >>
>> >> The above is not exhaustive but for discussion. It would be
>> >> useful for multiple server instances to have their own repository
>> >> for installing applications so that individual instances would be
>> >> seperate and could actually be managed with different OS userid
>> >> authentication. If GERONIMO_HOME was not the same as
>> >> GERONIMO_INSTANCE then the dir tree for instance would be searched
>> >> first and if a file wasn't found then we could then look in
>> >> GERONIMO_HOME. Write access would always (as far as I can tell)
>> >> be in the GERONIMO_INSTANCE tree.
>> >>
>> >> I'm not sure how deeply we need to flush this out but at a high
>> >> level I think we should rev the kernel to support the above for
>> >> 2.0 so we don't have to modify the way it operates down the road.
>> >>
>> >> Thoughts?
>> >>
>> >> Matt
>> >>
>> >>
>> >> On Jan 27, 2007, at 9:39 AM, Ted Kirby wrote:
>> >>
>> >>> Thanks Jacek. That is a good suggestion. Here is what I have
>> >>> come up
>> >>> with in thinking about a patch:
>> >>>
>> >>> The server java code has two directory notions: base, used with
>> >>> ServerInfo.resolve(), and baseServer, used with
>> >>> ServerInfo.resolveServer(). Base can be set with the oag.home.dir
>> >>> system property, and baseServer can be set with the
>> >>> oag.server.dir and
>> >>> oag.server.name system properties (where oag is short for
>> >>> org.apache.geronimo).
>> >>>
>> >>> The geronimo script uses GERONIMO_HOME for the bin directory, and
>> >>> GERONIMO_BASE for the lib and var directories. If
>> GERONIMO_BASE is
>> >>> not set, it will set it to GERONIMO_HOME. Finally, on java
>> >>> invocation, it sets the system property oag.base.dir to
>> >>> GERONIMO_BASE.
>> >>> The java code does not read this system property!
>> >>>
>> >>> I thus have two recommendations:
>> >>>
>> >>> The quick and conservative one is to have the geronimo script set
>> >>> oag.home.dir to GERONIMO_BASE, instead of setting oag.base.dir.
>> >>>
>> >>> The more complex and radical recommendation is to remove
>> >>> GERONIMO_BASE
>> >>> from the geronimo script, replacing it with GERONIMO_HOME.
>> >>>
>> >>> Thanks,
>> >>> Ted
>> >>>
>> >>> On 1/26/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
>> >>>> On 1/26/07, Ted Kirby <te...@gmail.com> wrote:
>> >>>> > Providing the org.apache.geronimo.home.dir system property to
>> >>>> allow
>> >>>> > the home directory to be passed in is good, but if this is not
>> >>>> used
>> >>>> > (and I'd don't feel it should be required/used in the normal
>> >>>> case),
>> >>>> > DirectoryUtils.getGeronimoInstallDirectory() is used to
>> >>>> determine the
>> >>>> > home directory. This method uses machinations that do not
>> >>>> resolve
>> >>>> > correctly if the home directory is a symbolic link. Since the
>> >>>> > invoking geronimo script sets and uses GERONIMO_HOME, why does
>> >>>> it not
>> >>>> > pass this value into the server? I would think that
>> >>>> BasicServerInfo
>> >>>> > would want to set baseDirectory to GERONIMO_HOME (if the
>> >>>> > org.apache.geronimo.home.dir system property is not set), and
>> >>>> invoke
>> >>>> > DirectoryUtils.getGeronimoInstallDirectory() only if
>> >>>> GERONIMO_HOME is
>> >>>> > not set.
>> >>>>
>> >>>> I think you might want to provide a patch that someone will
>> >>>> review and
>> >>>> commit. What do you think? if it doesn't break the tests it's a
>> >>>> good
>> >>>> start.
>> >>>>
>> >>>> Jacek
>> >>>>
>> >>>> --
>> >>>> Jacek Laskowski
>> >>>> http://www.JacekLaskowski.pl
>> >>>>
>> >>>
>> >>
>> >
>>
>>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Ted Kirby <te...@gmail.com>.
On 1/27/07, David Jencks <da...@yahoo.com> wrote:
> AFAIK support for everything needed to do this is already there, all
> you need is another module with an additional repository which might
> be located by default in var/repository.
>
> Existing command line properties:
> -Dorg.apache.geronimo.home.dir=/path/to/geronimo/home speciifies
> where the geronimo installation (bin dir etc) are located. I haven't
> figured out how this is useful yet.... but its there.
> -Dorg.apache.geronimo.server.name=foo makes geronimo look for var at
> <geronimo_home>/foo
> -Dorg.apache.geronimo.server.dir=/path/to/var/dir specifies where var
> is as an absolute path (if you don't supply a absolute path, its the
> same as "name")
>
> We support running with multiple repositories, and deploying to a
> specific repository with a deployer command line argument
> java -jar bin/deployer.jar -target repo-name
>
> All we need is to add another module/configuration that has a
> repository gbean and a config store gbean pointing to var/
> repository. I think this should be a plugin.
This second repo stuff is just way cool! It also works, in 1.1 and 2.0!
Here is my repo2.xml plan:
<module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.2">
<environment>
<moduleId>
<groupId>org.example.configs</groupId>
<artifactId>myrepo</artifactId>
<version>2.0-SNAPSHOT</version>
<type>car</type>
</moduleId>
<dependencies>
<dependency>
<groupId>org.apache.geronimo.configs</groupId>
<artifactId>j2ee-system</artifactId>
<version>2.0-SNAPSHOT</version>
<type>car</type>
</dependency>
</dependencies>
<hidden-classes/>
<non-overridable-classes/>
</environment>
<!--Repository-->
<gbean name="Repo2"
class="org.apache.geronimo.system.repository.Maven2Repository">
<attribute name="root">repo2/</attribute>
<reference name="ServerInfo">
<name>ServerInfo</name>
</reference>
</gbean>
<!--Configuration Store service-->
<gbean name="Local2"
class="org.apache.geronimo.system.configuration.RepositoryConfigurationStore">
<reference name="Repository">
<name>Repo2</name>
</reference>
</gbean>
</module>
mkdir <germonimo_home/repo2
deploy repo2.xml
The target names are long and cumbersome:
>java deployer.jar list-targets
Available Targets:
org.example.configs/myrepo/2.0-SNAPSHOT/car?ServiceModule=org.example.configs/myrepo/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local2
org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local
Use of environment variables recommended for command-line use.
To deploy to the new repo, use:
deploy --targets %REPO2% sample.war
deploy list-modules also gives those long target names on each module.
However, deploy list-modules %REPO2% gives the accustomed short output.
> So, I don't think this requires any code, just someone to write the
> module plan and check everything works. I don't see how this affects
> the server file structure except for the already present capability
> to relocate var.
>
> Not everyone will want to have a separate per server additional
> repository for running many servers off one files system copy. For
> instance if all the servers use the same apps you might as well
> deploy them all to the regular repository.
>
> thanks
> david jencks
>
> On Jan 27, 2007, at 2:38 PM, Jason Dillon wrote:
>
> > I think in order to allow multiple instances to work off of the
> > same installation effectively we need to have a tiered repository
> > support, so that each instance could include a shared read-only
> > repository (the system repository), and then a read-write
> > repository (instance repository), where artifact resolution would
> > first check the instance repo, then the system repo.
> >
> > If we do want to start supporting this, I suggest we also revisit
> > the basic server's file structure, as we will need to insert a
> > hierarchy for the instance data.
> >
> > --jason
> >
> >
> > On Jan 27, 2007, at 1:51 PM, Matt Hogstrom wrote:
> >
> >> I've been looking at this recently interms of being able to run
> >> multiple oag instances out of the same filesystem. This means we
> >> need to identify several different points in the filesystem. This
> >> is not exhaustive but really for discussion since Ted brought it up.
> >>
> >> One is the location of the Geronimo server. I'll refer to this as
> >> $GERONIMO_HOME. This directory is the root of the Geronimo
> >> installation.
> >>
> >> The next Location is the $GERONIMO_INSTANCE which would contain
> >> the parts of the repository that an individual instance would
> >> need. This would include a repository, var entries for config,
> >> logs, etc. One approach would be to make the GERONIMO_INSTANCE be
> >> a shadow of the normal dir structure for GERONIMO_HOME that is
> >> only populated with items that are different from the base
> >> install. I think this would include things like:
> >>
> >> ./repository
> >> ./lib
> >> ./var/log
> >> config
> >> activemq
> >> howl
> >>
> >> The above is not exhaustive but for discussion. It would be
> >> useful for multiple server instances to have their own repository
> >> for installing applications so that individual instances would be
> >> seperate and could actually be managed with different OS userid
> >> authentication. If GERONIMO_HOME was not the same as
> >> GERONIMO_INSTANCE then the dir tree for instance would be searched
> >> first and if a file wasn't found then we could then look in
> >> GERONIMO_HOME. Write access would always (as far as I can tell)
> >> be in the GERONIMO_INSTANCE tree.
> >>
> >> I'm not sure how deeply we need to flush this out but at a high
> >> level I think we should rev the kernel to support the above for
> >> 2.0 so we don't have to modify the way it operates down the road.
> >>
> >> Thoughts?
> >>
> >> Matt
> >>
> >>
> >> On Jan 27, 2007, at 9:39 AM, Ted Kirby wrote:
> >>
> >>> Thanks Jacek. That is a good suggestion. Here is what I have
> >>> come up
> >>> with in thinking about a patch:
> >>>
> >>> The server java code has two directory notions: base, used with
> >>> ServerInfo.resolve(), and baseServer, used with
> >>> ServerInfo.resolveServer(). Base can be set with the oag.home.dir
> >>> system property, and baseServer can be set with the
> >>> oag.server.dir and
> >>> oag.server.name system properties (where oag is short for
> >>> org.apache.geronimo).
> >>>
> >>> The geronimo script uses GERONIMO_HOME for the bin directory, and
> >>> GERONIMO_BASE for the lib and var directories. If GERONIMO_BASE is
> >>> not set, it will set it to GERONIMO_HOME. Finally, on java
> >>> invocation, it sets the system property oag.base.dir to
> >>> GERONIMO_BASE.
> >>> The java code does not read this system property!
> >>>
> >>> I thus have two recommendations:
> >>>
> >>> The quick and conservative one is to have the geronimo script set
> >>> oag.home.dir to GERONIMO_BASE, instead of setting oag.base.dir.
> >>>
> >>> The more complex and radical recommendation is to remove
> >>> GERONIMO_BASE
> >>> from the geronimo script, replacing it with GERONIMO_HOME.
> >>>
> >>> Thanks,
> >>> Ted
> >>>
> >>> On 1/26/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> >>>> On 1/26/07, Ted Kirby <te...@gmail.com> wrote:
> >>>> > Providing the org.apache.geronimo.home.dir system property to
> >>>> allow
> >>>> > the home directory to be passed in is good, but if this is not
> >>>> used
> >>>> > (and I'd don't feel it should be required/used in the normal
> >>>> case),
> >>>> > DirectoryUtils.getGeronimoInstallDirectory() is used to
> >>>> determine the
> >>>> > home directory. This method uses machinations that do not
> >>>> resolve
> >>>> > correctly if the home directory is a symbolic link. Since the
> >>>> > invoking geronimo script sets and uses GERONIMO_HOME, why does
> >>>> it not
> >>>> > pass this value into the server? I would think that
> >>>> BasicServerInfo
> >>>> > would want to set baseDirectory to GERONIMO_HOME (if the
> >>>> > org.apache.geronimo.home.dir system property is not set), and
> >>>> invoke
> >>>> > DirectoryUtils.getGeronimoInstallDirectory() only if
> >>>> GERONIMO_HOME is
> >>>> > not set.
> >>>>
> >>>> I think you might want to provide a patch that someone will
> >>>> review and
> >>>> commit. What do you think? if it doesn't break the tests it's a
> >>>> good
> >>>> start.
> >>>>
> >>>> Jacek
> >>>>
> >>>> --
> >>>> Jacek Laskowski
> >>>> http://www.JacekLaskowski.pl
> >>>>
> >>>
> >>
> >
>
>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by David Jencks <da...@yahoo.com>.
AFAIK support for everything needed to do this is already there, all
you need is another module with an additional repository which might
be located by default in var/repository.
Existing command line properties:
-Dorg.apache.geronimo.home.dir=/path/to/geronimo/home speciifies
where the geronimo installation (bin dir etc) are located. I haven't
figured out how this is useful yet.... but its there.
-Dorg.apache.geronimo.server.name=foo makes geronimo look for var at
<geronimo_home>/foo
-Dorg.apache.geronimo.server.dir=/path/to/var/dir specifies where var
is as an absolute path (if you don't supply a absolute path, its the
same as "name")
We support running with multiple repositories, and deploying to a
specific repository with a deployer command line argument
java -jar bin/deployer.jar -target repo-name
All we need is to add another module/configuration that has a
repository gbean and a config store gbean pointing to var/
repository. I think this should be a plugin.
So, I don't think this requires any code, just someone to write the
module plan and check everything works. I don't see how this affects
the server file structure except for the already present capability
to relocate var.
Not everyone will want to have a separate per server additional
repository for running many servers off one files system copy. For
instance if all the servers use the same apps you might as well
deploy them all to the regular repository.
thanks
david jencks
On Jan 27, 2007, at 2:38 PM, Jason Dillon wrote:
> I think in order to allow multiple instances to work off of the
> same installation effectively we need to have a tiered repository
> support, so that each instance could include a shared read-only
> repository (the system repository), and then a read-write
> repository (instance repository), where artifact resolution would
> first check the instance repo, then the system repo.
>
> If we do want to start supporting this, I suggest we also revisit
> the basic server's file structure, as we will need to insert a
> hierarchy for the instance data.
>
> --jason
>
>
> On Jan 27, 2007, at 1:51 PM, Matt Hogstrom wrote:
>
>> I've been looking at this recently interms of being able to run
>> multiple oag instances out of the same filesystem. This means we
>> need to identify several different points in the filesystem. This
>> is not exhaustive but really for discussion since Ted brought it up.
>>
>> One is the location of the Geronimo server. I'll refer to this as
>> $GERONIMO_HOME. This directory is the root of the Geronimo
>> installation.
>>
>> The next Location is the $GERONIMO_INSTANCE which would contain
>> the parts of the repository that an individual instance would
>> need. This would include a repository, var entries for config,
>> logs, etc. One approach would be to make the GERONIMO_INSTANCE be
>> a shadow of the normal dir structure for GERONIMO_HOME that is
>> only populated with items that are different from the base
>> install. I think this would include things like:
>>
>> ./repository
>> ./lib
>> ./var/log
>> config
>> activemq
>> howl
>>
>> The above is not exhaustive but for discussion. It would be
>> useful for multiple server instances to have their own repository
>> for installing applications so that individual instances would be
>> seperate and could actually be managed with different OS userid
>> authentication. If GERONIMO_HOME was not the same as
>> GERONIMO_INSTANCE then the dir tree for instance would be searched
>> first and if a file wasn't found then we could then look in
>> GERONIMO_HOME. Write access would always (as far as I can tell)
>> be in the GERONIMO_INSTANCE tree.
>>
>> I'm not sure how deeply we need to flush this out but at a high
>> level I think we should rev the kernel to support the above for
>> 2.0 so we don't have to modify the way it operates down the road.
>>
>> Thoughts?
>>
>> Matt
>>
>>
>> On Jan 27, 2007, at 9:39 AM, Ted Kirby wrote:
>>
>>> Thanks Jacek. That is a good suggestion. Here is what I have
>>> come up
>>> with in thinking about a patch:
>>>
>>> The server java code has two directory notions: base, used with
>>> ServerInfo.resolve(), and baseServer, used with
>>> ServerInfo.resolveServer(). Base can be set with the oag.home.dir
>>> system property, and baseServer can be set with the
>>> oag.server.dir and
>>> oag.server.name system properties (where oag is short for
>>> org.apache.geronimo).
>>>
>>> The geronimo script uses GERONIMO_HOME for the bin directory, and
>>> GERONIMO_BASE for the lib and var directories. If GERONIMO_BASE is
>>> not set, it will set it to GERONIMO_HOME. Finally, on java
>>> invocation, it sets the system property oag.base.dir to
>>> GERONIMO_BASE.
>>> The java code does not read this system property!
>>>
>>> I thus have two recommendations:
>>>
>>> The quick and conservative one is to have the geronimo script set
>>> oag.home.dir to GERONIMO_BASE, instead of setting oag.base.dir.
>>>
>>> The more complex and radical recommendation is to remove
>>> GERONIMO_BASE
>>> from the geronimo script, replacing it with GERONIMO_HOME.
>>>
>>> Thanks,
>>> Ted
>>>
>>> On 1/26/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
>>>> On 1/26/07, Ted Kirby <te...@gmail.com> wrote:
>>>> > Providing the org.apache.geronimo.home.dir system property to
>>>> allow
>>>> > the home directory to be passed in is good, but if this is not
>>>> used
>>>> > (and I'd don't feel it should be required/used in the normal
>>>> case),
>>>> > DirectoryUtils.getGeronimoInstallDirectory() is used to
>>>> determine the
>>>> > home directory. This method uses machinations that do not
>>>> resolve
>>>> > correctly if the home directory is a symbolic link. Since the
>>>> > invoking geronimo script sets and uses GERONIMO_HOME, why does
>>>> it not
>>>> > pass this value into the server? I would think that
>>>> BasicServerInfo
>>>> > would want to set baseDirectory to GERONIMO_HOME (if the
>>>> > org.apache.geronimo.home.dir system property is not set), and
>>>> invoke
>>>> > DirectoryUtils.getGeronimoInstallDirectory() only if
>>>> GERONIMO_HOME is
>>>> > not set.
>>>>
>>>> I think you might want to provide a patch that someone will
>>>> review and
>>>> commit. What do you think? if it doesn't break the tests it's a
>>>> good
>>>> start.
>>>>
>>>> Jacek
>>>>
>>>> --
>>>> Jacek Laskowski
>>>> http://www.JacekLaskowski.pl
>>>>
>>>
>>
>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 29/01/2007, at 3:56 AM, David Jencks wrote:
>
> On Jan 28, 2007, at 3:48 AM, Gianny Damour wrote:
>
>> On 28/01/2007, at 7:26 PM, David Jencks wrote:
<snip>
>>> I don't see any value in having a hierarchy here: I think that
>>> each item should be present in exactly one place. For instance
>>> if you have identical artifacts in 2 repos I'd regard that as an
>>> error, although since they are identical it wouldn't matter which
>>> one you picked. Could you provide an example of something your
>>> proposed search strategy would be useful for?
>>>
>> i think that this may be useful in some very specific scenario.
>> For instance, a developer may want to upgrade some dependencies
>> used by a module his team is working on in a sandbox. If he simply
>> drops a newer version in the shared repository, then all the
>> developers will see the newer version upon server restart. This
>> can be avoided by updating the artifact_aliases property file of
>> each developer; however, this is less transparent than a solution
>> based on an hierarchical dependency resolution mechanism.
>>
>
> I don't think I understand what you have in mind yet. I would
> expect that in a setup with multiple servers the stuff that's
> specific to a particular server would be in the server-specific
> repo we've been talking about. So if you want to upgrade a
> dependency to a newer version you'd put the newer version in your
> server-specific repo where your apps would find it but no one
> else's apps would. The only scenario I can think of so far where
> this wouldn't work is if it's a snapshot dependency so the old and
> new files have exactly the same file name. I really think we
> should NOT support anything that tries to distinguish between 2
> files with the same artifact Id. If people want to have different
> versions of a snapshot artifact in the server they should all be in
> server-specific repos.
>
I was trying to consider the case where a non server-specific
dependency is to be upgraded. I was wrongly believing that artifact
version resolution was returning the highest version available of the
first Repository storing the to be resolved Artifact. Following your
comment, I checked the artifact resolution approach implemented by
DefaultArtifactResolver and I now understand why hierarchical
dependency resolution is useless. Thanks for taking the time to
explain it.
Gianny
> thanks
> david jencks
Re: Why is GERONIMO_HOME not passed into the server?
Posted by David Jencks <da...@yahoo.com>.
On Jan 28, 2007, at 3:48 AM, Gianny Damour wrote:
> On 28/01/2007, at 7:26 PM, David Jencks wrote:
>
>>
>> On Jan 27, 2007, at 6:11 PM, Matt Hogstrom wrote:
>>
>>>
>>> On Jan 27, 2007, at 5:38 PM, Jason Dillon wrote:
>>>
>>>> I think in order to allow multiple instances to work off of the
>>>> same installation effectively we need to have a tiered
>>>> repository support, so that each instance could include a shared
>>>> read-only repository (the system repository), and then a read-
>>>> write repository (instance repository), where artifact
>>>> resolution would first check the instance repo, then the system
>>>> repo.
>>>>
>>>> If we do want to start supporting this, I suggest we also
>>>> revisit the basic server's file structure, as we will need to
>>>> insert a hierarchy for the instance data.
>>>>
>>>> --jason
>>>
>>>
>>> IWhat if we started somthing in var like:
>>>
>>> ./var/servers/server.n
>>>
>>> The server.n sould be some arbitrary name that users would
>>> identify the names of the server instance. We would look in the
>>> instance tree first and if something wasn't found we'd look in
>>> the main tree. Is that what you meant?
>>>
>>>
>> IIRC we discussed this fairly extensively a long time ago and
>> concluded that what made the most sense was to keep the var
>> directory structure the same as it is now but allow relocating it,
>> so that's what's currently implemented. So, the expected
>> directory structure would be
>>
>> <geronimo_base>/servers/server.n/var
>
> I also remember some discussions on the best approach to share a
> Geronimo installation and the above directory structure was
> preferred to the other solutions.
>
>>
>> I don't see any value in having a hierarchy here: I think that
>> each item should be present in exactly one place. For instance if
>> you have identical artifacts in 2 repos I'd regard that as an
>> error, although since they are identical it wouldn't matter which
>> one you picked. Could you provide an example of something your
>> proposed search strategy would be useful for?
>>
> i think that this may be useful in some very specific scenario. For
> instance, a developer may want to upgrade some dependencies used by
> a module his team is working on in a sandbox. If he simply drops a
> newer version in the shared repository, then all the developers
> will see the newer version upon server restart. This can be avoided
> by updating the artifact_aliases property file of each developer;
> however, this is less transparent than a solution based on an
> hierarchical dependency resolution mechanism.
>
I don't think I understand what you have in mind yet. I would expect
that in a setup with multiple servers the stuff that's specific to a
particular server would be in the server-specific repo we've been
talking about. So if you want to upgrade a dependency to a newer
version you'd put the newer version in your server-specific repo
where your apps would find it but no one else's apps would. The only
scenario I can think of so far where this wouldn't work is if it's a
snapshot dependency so the old and new files have exactly the same
file name. I really think we should NOT support anything that tries
to distinguish between 2 files with the same artifact Id. If people
want to have different versions of a snapshot artifact in the server
they should all be in server-specific repos.
thanks
david jencks
> I am not sure that the above example is worth to support; at least,
> it is less important than a plugin adding a repository into var.
>
> Thanks,
> Gianny
>
>
>> thanks
>> david jencks
>>
>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 28/01/2007, at 7:26 PM, David Jencks wrote:
>
> On Jan 27, 2007, at 6:11 PM, Matt Hogstrom wrote:
>
>>
>> On Jan 27, 2007, at 5:38 PM, Jason Dillon wrote:
>>
>>> I think in order to allow multiple instances to work off of the
>>> same installation effectively we need to have a tiered repository
>>> support, so that each instance could include a shared read-only
>>> repository (the system repository), and then a read-write
>>> repository (instance repository), where artifact resolution would
>>> first check the instance repo, then the system repo.
>>>
>>> If we do want to start supporting this, I suggest we also revisit
>>> the basic server's file structure, as we will need to insert a
>>> hierarchy for the instance data.
>>>
>>> --jason
>>
>>
>> IWhat if we started somthing in var like:
>>
>> ./var/servers/server.n
>>
>> The server.n sould be some arbitrary name that users would
>> identify the names of the server instance. We would look in the
>> instance tree first and if something wasn't found we'd look in the
>> main tree. Is that what you meant?
>>
>>
> IIRC we discussed this fairly extensively a long time ago and
> concluded that what made the most sense was to keep the var
> directory structure the same as it is now but allow relocating it,
> so that's what's currently implemented. So, the expected directory
> structure would be
>
> <geronimo_base>/servers/server.n/var
I also remember some discussions on the best approach to share a
Geronimo installation and the above directory structure was preferred
to the other solutions.
>
> I don't see any value in having a hierarchy here: I think that each
> item should be present in exactly one place. For instance if you
> have identical artifacts in 2 repos I'd regard that as an error,
> although since they are identical it wouldn't matter which one you
> picked. Could you provide an example of something your proposed
> search strategy would be useful for?
>
i think that this may be useful in some very specific scenario. For
instance, a developer may want to upgrade some dependencies used by a
module his team is working on in a sandbox. If he simply drops a
newer version in the shared repository, then all the developers will
see the newer version upon server restart. This can be avoided by
updating the artifact_aliases property file of each developer;
however, this is less transparent than a solution based on an
hierarchical dependency resolution mechanism.
I am not sure that the above example is worth to support; at least,
it is less important than a plugin adding a repository into var.
Thanks,
Gianny
> thanks
> david jencks
>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by David Jencks <da...@yahoo.com>.
On Jan 27, 2007, at 6:11 PM, Matt Hogstrom wrote:
>
> On Jan 27, 2007, at 5:38 PM, Jason Dillon wrote:
>
>> I think in order to allow multiple instances to work off of the
>> same installation effectively we need to have a tiered repository
>> support, so that each instance could include a shared read-only
>> repository (the system repository), and then a read-write
>> repository (instance repository), where artifact resolution would
>> first check the instance repo, then the system repo.
>>
>> If we do want to start supporting this, I suggest we also revisit
>> the basic server's file structure, as we will need to insert a
>> hierarchy for the instance data.
>>
>> --jason
>
>
> IWhat if we started somthing in var like:
>
> ./var/servers/server.n
>
> The server.n sould be some arbitrary name that users would identify
> the names of the server instance. We would look in the instance
> tree first and if something wasn't found we'd look in the main
> tree. Is that what you meant?
>
>
IIRC we discussed this fairly extensively a long time ago and
concluded that what made the most sense was to keep the var
directory structure the same as it is now but allow relocating it, so
that's what's currently implemented. So, the expected directory
structure would be
<geronimo_base>/servers/server.n/var
I don't see any value in having a hierarchy here: I think that each
item should be present in exactly one place. For instance if you
have identical artifacts in 2 repos I'd regard that as an error,
although since they are identical it wouldn't matter which one you
picked. Could you provide an example of something your proposed
search strategy would be useful for?
thanks
david jencks
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Jason Dillon <ja...@planet57.com>.
Ya I was just hinting that we should come up with a standard place to
put the instance data tree, which might mean a slight alteration of
the standard tree too... but I'm not really sure, just wanted to put
it out there.
--jason
On Jan 27, 2007, at 6:11 PM, Matt Hogstrom wrote:
>
> On Jan 27, 2007, at 5:38 PM, Jason Dillon wrote:
>
>> I think in order to allow multiple instances to work off of the
>> same installation effectively we need to have a tiered repository
>> support, so that each instance could include a shared read-only
>> repository (the system repository), and then a read-write
>> repository (instance repository), where artifact resolution would
>> first check the instance repo, then the system repo.
>>
>> If we do want to start supporting this, I suggest we also revisit
>> the basic server's file structure, as we will need to insert a
>> hierarchy for the instance data.
>>
>> --jason
>
>
> IWhat if we started somthing in var like:
>
> ./var/servers/server.n
>
> The server.n sould be some arbitrary name that users would identify
> the names of the server instance. We would look in the instance
> tree first and if something wasn't found we'd look in the main
> tree. Is that what you meant?
>
>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jan 27, 2007, at 5:38 PM, Jason Dillon wrote:
> I think in order to allow multiple instances to work off of the
> same installation effectively we need to have a tiered repository
> support, so that each instance could include a shared read-only
> repository (the system repository), and then a read-write
> repository (instance repository), where artifact resolution would
> first check the instance repo, then the system repo.
>
> If we do want to start supporting this, I suggest we also revisit
> the basic server's file structure, as we will need to insert a
> hierarchy for the instance data.
>
> --jason
IWhat if we started somthing in var like:
./var/servers/server.n
The server.n sould be some arbitrary name that users would identify
the names of the server instance. We would look in the instance tree
first and if something wasn't found we'd look in the main tree. Is
that what you meant?
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Jason Dillon <ja...@planet57.com>.
I think in order to allow multiple instances to work off of the same
installation effectively we need to have a tiered repository support,
so that each instance could include a shared read-only repository
(the system repository), and then a read-write repository (instance
repository), where artifact resolution would first check the instance
repo, then the system repo.
If we do want to start supporting this, I suggest we also revisit the
basic server's file structure, as we will need to insert a hierarchy
for the instance data.
--jason
On Jan 27, 2007, at 1:51 PM, Matt Hogstrom wrote:
> I've been looking at this recently interms of being able to run
> multiple oag instances out of the same filesystem. This means we
> need to identify several different points in the filesystem. This
> is not exhaustive but really for discussion since Ted brought it up.
>
> One is the location of the Geronimo server. I'll refer to this as
> $GERONIMO_HOME. This directory is the root of the Geronimo
> installation.
>
> The next Location is the $GERONIMO_INSTANCE which would contain the
> parts of the repository that an individual instance would need.
> This would include a repository, var entries for config, logs,
> etc. One approach would be to make the GERONIMO_INSTANCE be a
> shadow of the normal dir structure for GERONIMO_HOME that is only
> populated with items that are different from the base install. I
> think this would include things like:
>
> ./repository
> ./lib
> ./var/log
> config
> activemq
> howl
>
> The above is not exhaustive but for discussion. It would be useful
> for multiple server instances to have their own repository for
> installing applications so that individual instances would be
> seperate and could actually be managed with different OS userid
> authentication. If GERONIMO_HOME was not the same as
> GERONIMO_INSTANCE then the dir tree for instance would be searched
> first and if a file wasn't found then we could then look in
> GERONIMO_HOME. Write access would always (as far as I can tell) be
> in the GERONIMO_INSTANCE tree.
>
> I'm not sure how deeply we need to flush this out but at a high
> level I think we should rev the kernel to support the above for 2.0
> so we don't have to modify the way it operates down the road.
>
> Thoughts?
>
> Matt
>
>
> On Jan 27, 2007, at 9:39 AM, Ted Kirby wrote:
>
>> Thanks Jacek. That is a good suggestion. Here is what I have
>> come up
>> with in thinking about a patch:
>>
>> The server java code has two directory notions: base, used with
>> ServerInfo.resolve(), and baseServer, used with
>> ServerInfo.resolveServer(). Base can be set with the oag.home.dir
>> system property, and baseServer can be set with the oag.server.dir
>> and
>> oag.server.name system properties (where oag is short for
>> org.apache.geronimo).
>>
>> The geronimo script uses GERONIMO_HOME for the bin directory, and
>> GERONIMO_BASE for the lib and var directories. If GERONIMO_BASE is
>> not set, it will set it to GERONIMO_HOME. Finally, on java
>> invocation, it sets the system property oag.base.dir to
>> GERONIMO_BASE.
>> The java code does not read this system property!
>>
>> I thus have two recommendations:
>>
>> The quick and conservative one is to have the geronimo script set
>> oag.home.dir to GERONIMO_BASE, instead of setting oag.base.dir.
>>
>> The more complex and radical recommendation is to remove
>> GERONIMO_BASE
>> from the geronimo script, replacing it with GERONIMO_HOME.
>>
>> Thanks,
>> Ted
>>
>> On 1/26/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
>>> On 1/26/07, Ted Kirby <te...@gmail.com> wrote:
>>> > Providing the org.apache.geronimo.home.dir system property to
>>> allow
>>> > the home directory to be passed in is good, but if this is not
>>> used
>>> > (and I'd don't feel it should be required/used in the normal
>>> case),
>>> > DirectoryUtils.getGeronimoInstallDirectory() is used to
>>> determine the
>>> > home directory. This method uses machinations that do not resolve
>>> > correctly if the home directory is a symbolic link. Since the
>>> > invoking geronimo script sets and uses GERONIMO_HOME, why does
>>> it not
>>> > pass this value into the server? I would think that
>>> BasicServerInfo
>>> > would want to set baseDirectory to GERONIMO_HOME (if the
>>> > org.apache.geronimo.home.dir system property is not set), and
>>> invoke
>>> > DirectoryUtils.getGeronimoInstallDirectory() only if
>>> GERONIMO_HOME is
>>> > not set.
>>>
>>> I think you might want to provide a patch that someone will
>>> review and
>>> commit. What do you think? if it doesn't break the tests it's a good
>>> start.
>>>
>>> Jacek
>>>
>>> --
>>> Jacek Laskowski
>>> http://www.JacekLaskowski.pl
>>>
>>
>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I've been looking at this recently interms of being able to run
multiple oag instances out of the same filesystem. This means we
need to identify several different points in the filesystem. This is
not exhaustive but really for discussion since Ted brought it up.
One is the location of the Geronimo server. I'll refer to this as
$GERONIMO_HOME. This directory is the root of the Geronimo
installation.
The next Location is the $GERONIMO_INSTANCE which would contain the
parts of the repository that an individual instance would need. This
would include a repository, var entries for config, logs, etc. One
approach would be to make the GERONIMO_INSTANCE be a shadow of the
normal dir structure for GERONIMO_HOME that is only populated with
items that are different from the base install. I think this would
include things like:
./repository
./lib
./var/log
config
activemq
howl
The above is not exhaustive but for discussion. It would be useful
for multiple server instances to have their own repository for
installing applications so that individual instances would be
seperate and could actually be managed with different OS userid
authentication. If GERONIMO_HOME was not the same as
GERONIMO_INSTANCE then the dir tree for instance would be searched
first and if a file wasn't found then we could then look in
GERONIMO_HOME. Write access would always (as far as I can tell) be
in the GERONIMO_INSTANCE tree.
I'm not sure how deeply we need to flush this out but at a high level
I think we should rev the kernel to support the above for 2.0 so we
don't have to modify the way it operates down the road.
Thoughts?
Matt
On Jan 27, 2007, at 9:39 AM, Ted Kirby wrote:
> Thanks Jacek. That is a good suggestion. Here is what I have come up
> with in thinking about a patch:
>
> The server java code has two directory notions: base, used with
> ServerInfo.resolve(), and baseServer, used with
> ServerInfo.resolveServer(). Base can be set with the oag.home.dir
> system property, and baseServer can be set with the oag.server.dir and
> oag.server.name system properties (where oag is short for
> org.apache.geronimo).
>
> The geronimo script uses GERONIMO_HOME for the bin directory, and
> GERONIMO_BASE for the lib and var directories. If GERONIMO_BASE is
> not set, it will set it to GERONIMO_HOME. Finally, on java
> invocation, it sets the system property oag.base.dir to GERONIMO_BASE.
> The java code does not read this system property!
>
> I thus have two recommendations:
>
> The quick and conservative one is to have the geronimo script set
> oag.home.dir to GERONIMO_BASE, instead of setting oag.base.dir.
>
> The more complex and radical recommendation is to remove GERONIMO_BASE
> from the geronimo script, replacing it with GERONIMO_HOME.
>
> Thanks,
> Ted
>
> On 1/26/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
>> On 1/26/07, Ted Kirby <te...@gmail.com> wrote:
>> > Providing the org.apache.geronimo.home.dir system property to allow
>> > the home directory to be passed in is good, but if this is not used
>> > (and I'd don't feel it should be required/used in the normal case),
>> > DirectoryUtils.getGeronimoInstallDirectory() is used to
>> determine the
>> > home directory. This method uses machinations that do not resolve
>> > correctly if the home directory is a symbolic link. Since the
>> > invoking geronimo script sets and uses GERONIMO_HOME, why does
>> it not
>> > pass this value into the server? I would think that
>> BasicServerInfo
>> > would want to set baseDirectory to GERONIMO_HOME (if the
>> > org.apache.geronimo.home.dir system property is not set), and
>> invoke
>> > DirectoryUtils.getGeronimoInstallDirectory() only if
>> GERONIMO_HOME is
>> > not set.
>>
>> I think you might want to provide a patch that someone will review
>> and
>> commit. What do you think? if it doesn't break the tests it's a good
>> start.
>>
>> Jacek
>>
>> --
>> Jacek Laskowski
>> http://www.JacekLaskowski.pl
>>
>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Ted Kirby <te...@gmail.com>.
Thanks Jacek. That is a good suggestion. Here is what I have come up
with in thinking about a patch:
The server java code has two directory notions: base, used with
ServerInfo.resolve(), and baseServer, used with
ServerInfo.resolveServer(). Base can be set with the oag.home.dir
system property, and baseServer can be set with the oag.server.dir and
oag.server.name system properties (where oag is short for
org.apache.geronimo).
The geronimo script uses GERONIMO_HOME for the bin directory, and
GERONIMO_BASE for the lib and var directories. If GERONIMO_BASE is
not set, it will set it to GERONIMO_HOME. Finally, on java
invocation, it sets the system property oag.base.dir to GERONIMO_BASE.
The java code does not read this system property!
I thus have two recommendations:
The quick and conservative one is to have the geronimo script set
oag.home.dir to GERONIMO_BASE, instead of setting oag.base.dir.
The more complex and radical recommendation is to remove GERONIMO_BASE
from the geronimo script, replacing it with GERONIMO_HOME.
Thanks,
Ted
On 1/26/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 1/26/07, Ted Kirby <te...@gmail.com> wrote:
> > Providing the org.apache.geronimo.home.dir system property to allow
> > the home directory to be passed in is good, but if this is not used
> > (and I'd don't feel it should be required/used in the normal case),
> > DirectoryUtils.getGeronimoInstallDirectory() is used to determine the
> > home directory. This method uses machinations that do not resolve
> > correctly if the home directory is a symbolic link. Since the
> > invoking geronimo script sets and uses GERONIMO_HOME, why does it not
> > pass this value into the server? I would think that BasicServerInfo
> > would want to set baseDirectory to GERONIMO_HOME (if the
> > org.apache.geronimo.home.dir system property is not set), and invoke
> > DirectoryUtils.getGeronimoInstallDirectory() only if GERONIMO_HOME is
> > not set.
>
> I think you might want to provide a patch that someone will review and
> commit. What do you think? if it doesn't break the tests it's a good
> start.
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 1/26/07, Ted Kirby <te...@gmail.com> wrote:
> Providing the org.apache.geronimo.home.dir system property to allow
> the home directory to be passed in is good, but if this is not used
> (and I'd don't feel it should be required/used in the normal case),
> DirectoryUtils.getGeronimoInstallDirectory() is used to determine the
> home directory. This method uses machinations that do not resolve
> correctly if the home directory is a symbolic link. Since the
> invoking geronimo script sets and uses GERONIMO_HOME, why does it not
> pass this value into the server? I would think that BasicServerInfo
> would want to set baseDirectory to GERONIMO_HOME (if the
> org.apache.geronimo.home.dir system property is not set), and invoke
> DirectoryUtils.getGeronimoInstallDirectory() only if GERONIMO_HOME is
> not set.
I think you might want to provide a patch that someone will review and
commit. What do you think? if it doesn't break the tests it's a good
start.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Why is GERONIMO_HOME not passed into the server?
Posted by Sachin Patel <sp...@gmail.com>.
I forget which properties do what, but I think it is needed for
multiple instance support.
On Jan 26, 2007, at 9:40 AM, Ted Kirby wrote:
> Providing the org.apache.geronimo.home.dir system property to allow
> the home directory to be passed in is good, but if this is not used
> (and I'd don't feel it should be required/used in the normal case),
> DirectoryUtils.getGeronimoInstallDirectory() is used to determine the
> home directory. This method uses machinations that do not resolve
> correctly if the home directory is a symbolic link. Since the
> invoking geronimo script sets and uses GERONIMO_HOME, why does it not
> pass this value into the server? I would think that BasicServerInfo
> would want to set baseDirectory to GERONIMO_HOME (if the
> org.apache.geronimo.home.dir system property is not set), and invoke
> DirectoryUtils.getGeronimoInstallDirectory() only if GERONIMO_HOME is
> not set.
-sachin