geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Why is GERONIMO_HOME not passed into the server?
Date Mon, 29 Jan 2007 16:16:19 GMT
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 <david_jencks@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 <jacek@laskowski.net.pl> wrote:
>> >>>> On 1/26/07, Ted Kirby <ted.kirby@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
>> >>>>
>> >>>
>> >>
>> >
>>
>>


Mime
View raw message