geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Pulling Geronimo Configuration
Date Tue, 10 Feb 2009 17:20:18 GMT

On Feb 10, 2009, at 8:09 AM, Chance Yeoman wrote:

> Hello All,
> I am interested in setting up geronimo installations that can pull  
> installed plugins and their dependencies exclusively from a  
> repository within a master geronimo server.  I hope to eventually  
> have an automated process allowing cluster members to poll a cluster- 
> specific geronimo server repository for available, locally  
> uninstalled plugins.  My goal is to be able to more easily manage  
> geographically separated cluster members and to quickly add or  
> reinitialize nodes.
> I've been having trouble getting started as I receive HTTP 401  
> responses when installing remote plugins using the admin interface,  
> even with security turned off on the maven-repo URL.  I can list the  
> contents of the remote server's repository, but not install plugins.

That's pretty odd.  Can you show the urls being used?  You should be  
able to check that it's working with a browser.

> My question is:  Is using the GeronimoAsMavenServlet even the  
> correct approach to pull-based configuration?  How have others  
> implemented configuration pulling?  Any advice would be greatly  
> appreciated.

If you use a geronimo server as the plugin repo then  
GeronimoAsMavenServlet is the correct approach.  However, if I were  
you I would give significant consideration to using nexus as the  
plugin repo.  I think you will have a much easier time integrating  
this with a reasonable build/qa process.  In particular, if you build  
the plugins using maven with the car-maven-plugin, you can set the  
distribution management repos to be the nexus server and have mvn  
deploy or mvn release make the plugin available to the appropriate  
production servers.

I hope you are also aware of the plugin-based clustering/farming  
support that may provide the features you need for easy rollout to  
mutliple servers.  If the existing features there don't exactly match  
your needs please work with us to improve this.  For instance IIUC  
since you indicate your cluster members are geographically separate  
the current multicast discovery of cluster members may not work for  
you... however changing this to a hardcoded set of servers should be  
pretty easy.  Or perhaps you want a hybrid approach where a bunch of  
multicast-connected sub-clusters aggregate to a controller.

david jencks

> Thank you,
> Chance
> --
> Center for the Application of Information Technologies

View raw message