geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Multiple geronimo instances
Date Mon, 28 Nov 2005 07:11:36 GMT

On Nov 24, 2005, at 11:49 AM, Guglielmo.Lichtner@instinet.com wrote:

>
> What would work just as well for me would be to be able to check in a 
> skeleton
> and then deploy the plans the first time I build and deploy the 
> application. I am even willing
> to copy all the files over, as long as I am not checking them in.

I'm not sure what you mean by "checking them in", could you be more 
specific?
>
> If I can help it I will not check in things which can be derived from 
> other things. For example, your config-store
> can be derived from the plans (and I am not sure what else.) The 
> dependencies are third-party jars, etc.
>
> I think you are doing this already when you build geronimo using 
> maven. I just have to find out what steps
> to take between compiling and starting the server. Can I just blow 
> away config-store and then deploy the
> plans I want?

Geronimo is extremely modular, and almost all the configuration pieces 
are in the config-store.  So if you remove the contents of the 
config-store you will have almost nothing left.

To see my idea of how geronimo should be assembled, look at the configs 
and assemblies directories.  The directories under configs each build 
one configuration and store it in the local maven repository.  The 
directories under assemblies assemble a set of configurations specified 
in the project.xml into a geronimo server.  I think this is the best 
approach for constructing anything but the most standard server.  
However, it is not entirely done.  For instance, I haven't figured out 
a reasonable replacement for deployer.jar.

The output of an assemblies module is a geronimo server in a zip file 
in your local maven repo.  As noted, you can include pretty much 
anything you want in it, including j2ee applications.  To install, you 
just unzip it and run.
>
> Is it possible to use this, perhaps:
>
> java -jar deployer.jar deploy <plan> <file>

That works.  I think using one of the maven-based approaches is much 
easier and more development-process-friendly.   One of these is the 
configs/assemblies approach noted above.  You might look at the trade 
app in the sandbox, in the derby module, for an alternate maven based 
deployment approach.

Hope this helps, I'm not entirely sure what you are asking about this 
time :-)

david jencks

>
> Guglielmo
>
>
>
> David Jencks <david_jencks@yahoo.com>
>
> 11/24/2005 11:28 AM
> Please respond to user
>        
>         To:        user@geronimo.apache.org
>         cc:        
>         Subject:        Re: Multiple geronimo instances with little 
> disk usage
>
>
>
> This is not supported yet, but it definitely should be.
>
>  The idea is that everything except the var directory is shared between
>  server instances, and each instance has its own var directory.  So,
>  there are several gbeans with paths into the var directory: several 
> are
>  in the j2ee-system plan.  Some other gbeans in plans such as
>  system-database and activemq-broker also store stuff in var.  The 
> major
>  problem at the moment is that most of these gbeans are in the system
>  plan which is loaded before the config.xml file, so there is no
>  opportunity to replace the "var" with the location of your choice.  
>  Unfortunately this means you have to build a whole set of
>  configurations for each server, since the name of the base config is
>  going to be different.
>
>  Does anyone have a good idea how to make this work with only a single
>  set of configurations?  one possibility would be to have ServerInfo
>  know where the var directory is, all gbeans that use var ask 
> ServerInfo
>  where it is, and have ServerInfo read it from a system property.  Then
>  you could set the var location on the command line.  You can already
>  set the config.xml on the command line, although this might not be
>  needed if the var location could be set.  The only disadvantage I've
>  thought of with this plan is that it builds the concept of the var
>  directory into geronimo in a much more fundamental way than it is now.
>
>  thanks
>  david jencks
>
>
>  On Nov 24, 2005, at 11:11 AM, Guglielmo.Lichtner@instinet.com wrote:
>
>  >
>  > I would like to do this:
>  >
>  > 1) Unpack the geronimo distribution under /usr/local/geronimo (say)
>  > and make it read-only.
>  >
>  > 2) Create many small _instances_ of geronimo running on all 
> different
>  > (sets of) ports, on the same machine.
>  > I would like the _code_ to be in one place, but the configurations 
> of
>  > the instances to all be different.
>  >
>  > Basically a lot like tomcat.
>  >
>  > Thanks
>  > Guglielmo
>  >
>  >
>  >  *****************************************************************
>  >  <<>>
>  >
>  >  In compliance with applicable rules and regulations, Instinet
>  >  reviews and archives incoming and outgoing email communications,
>  >  copies of which may be produced at the request of regulators.
>  >  This message is intended only for the personal and confidential
>  >  use of the recipients named above. If the reader of this email
>  >  is not the intended recipient, you have received this email in
>  >  error and any review, dissemination, distribution or copying is
>  >  strictly prohibited. If you have received this email in error,
>  >  please notify the sender immediately by return email and
>  >  permanently delete the copy you received.
>  >
>  >  Instinet accepts no liability for any content contained in the
>  >  email, or any errors or omissions arising as a result of email
>  >  transmission. Any opinions contained in this email constitute
>  >  the sender's best judgment at this time and are subject to change
>  >  without notice. Instinet does not make recommendations of a
>  >  particular security and the information contained in this email
>  >  should not be considered as a recommendation, an offer or a
>  >  solicitation of an offer to buy and sell securities.
>  >
>  >  *****************************************************************
>
>
>


Mime
View raw message