AW: AW: MultiClassLoader changes

Hi !

I think if we discuss this scenario further we will end up with a
Tomcat-like classloader scenario:

1) Classes that are just used by multiserver it self and NOT visible to
applications
2) Classes that are loaded for all applications
3) Classes that are loaded for ONE application

If we do not have No 1), we will one time end up with compatibility
problems between different versions of libraries used by multiserver and
applications, right ?

So multiserver.conf would have to be extended with some kind of
"CommonApplicationClassPath"-entry specifying jars for No 2). These
classes should then be loaded by a classloader #2 which would be the
parent of all #3-classloaders...!?

Greetings.

Alfred

-----Ursprüngliche Nachricht-----
Von: Srinivas Yermal [mailto:syermal@xxxxxxxxxxx] 
Bereitgestellt: Montag, 17. November 2003 19:49
Bereitgestellt in: Enhydra
Unterhaltung: AW: Enhydra: MultiClassLoader changes
Betreff: Re: AW: Enhydra: MultiClassLoader changes


Hi Alfred,

The scenario as I said in my earlier mail was basically to deal with 
access to global objects. Now if you look at the enhydra application, 
you can specify the path to a class in two different places. One in the 
local classpath to multiserver and then in the configuration file of the

enhydra application. If a war needs to be able to access a class then it

has to be specified in the classpath, and if the enhydra application 
needs access to a class it has to be specified in the conf file.

If for example, you use Barracuda's objectRepository, you expect that 
this repository (global) is available to all servlets and wars running 
under enhydra. But that was not the case. I was getting an entirely 
different reference to the repository when I access it from enhydra 
application. This we figured was because of the class loading happening 
twice by two different classloaders which were not connected and hence 
the class was in different namespaces. If multiclassloader were to allow

its parent to load the class before it tried to load, this wouldnot 
happen. If you look into the code instantiating the multiclassloader, 
the parent classloader is always set to null. This change is done to 
avoid the parent being set to null so that a single classloader loads 
all the classes that are specified outside the namespaces of enhydra 
application as well as those that are specified in both places.

So if a single classloader loads the class, then the global objects like

objectRepository can be accessed by all applications running under 
enhydra multiserver. Hope this helps.

Thanks,
Srini.

P.S: Please note that I am talking about enhydra 3.1.1
Madl Alfred wrote:

>Hi Srini !
>
>Could you please provide a simple description what is possible to do 
>with your patch that did not work before. Just want to understand the 
>usage scenario !
>
>Thanks.
>
>Alfred
>
>-----Ursprüngliche Nachricht-----
>Von: Srinivas Yermal [mailto:syermal@xxxxxxxxxxx]
>Bereitgestellt: Samstag, 15. November 2003 02:47
>Bereitgestellt in: Enhydra
>Unterhaltung: Enhydra: MultiClassLoader changes
>Betreff: Enhydra: MultiClassLoader changes
>
>
>Folks,
>
>We have been using enhydra 3.1 for quite sometime now and we have not
>yet made the transition to 5.1 yet. The multiclass loader that comes 
>with enhydra is ok but seems to be quite old. Moreover we were having 
>troubles trying to share common DODS objects with other servlets and 
>application wars.
>
>Hence I have changed the way MultiClassLoader handles parent
>classloader. I am not quite sure whether these changes are according to

>your standards or specifications, but it works for us. I have attached 
>the patch file to 
>ENHYDRA_SRCDIR/modules/Core/src/com/lutris/classloader/MultiClassLoader
.
>java. 
>There are only log4j changes in 5.1 tree for this file. Please do 
>comment on the changes if you apply them.
>Thanks,
>Srini.
>  
>


_______________________________________________
Enhydra mailing list
Enhydra@xxxxxxxxxxx http://www.enhydra.org/mailman/listinfo.cgi/enhydra

smime.p7s
Description: S/MIME cryptographic signature