geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Kirby" <ted.ki...@gmail.com>
Subject Re: Why is GERONIMO_HOME not passed into the server?
Date Sun, 28 Jan 2007 21:20:44 GMT
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.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 <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