geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Help needed in creating enterprise application deployment plan
Date Wed, 13 Jun 2007 16:56:13 GMT

On Jun 13, 2007, at 9:03 AM, wrote:

> On 6/13/07, Hernan Cunico <> wrote:
>> Did you see these docs
>> There are also some sample apps here
>> HTH
>> Cheers!
>> Hernan
> I have yet to find documentation about the benefits of creating a
> plan.  I think plans are just  platform-specific overrides for web.xml
> with platform-specific extended configuration.
> Is this correct?

More or less, yes.  You need plans for datasources to tell where your  
database is.  Often you need to map jndi names to stuff like  
datasource names, although usually you can avoid this by careful  
naming.  You can also use the environment element in a plan to  
specify the classloader for your app very precisely.  This can for  
instance let you put all the dependency jars in the geronimo  
repository where they can be shared rather than in WEB-INF/lib where  
each app needs its own copy.  You can also use one app as a parent of  
another which can let you split up large apps without duplicating  
classes.  You can construct a classloader with a lot of dependency  
jars in it and use it as a parent of all your apps, so the dependency  
classes are only loaded once.  etc etc.
> The Geronimo documentation includes an "inverse-classloading" setting.
> This setting may be required to make Geronimo sane.  I just posted
> about an issue that may have been solved with this setting.  Why is
> this not the default?

I don't think inverse-classloading should affect the problem you  
described with jaxp libraries: if it does i'd be inclined to regard  
it as a bug, although it might be a misconfiguration.  I think that  
generally one wants to have only one copy of a class in a classloader  
graph, its the simplest and least error-prone situation.  We provide  
inverse-classloading and the hidden-classes and non-overridable- 
classes so that if for some reason you need to deal with multiple  
copies of a class, you can usually come up with  some way to get the  
one you want, where you want it.  But its often better to try to  
eliminate the problem by having only one version of each class.

david jencks
> solprovider

View raw message