Re: 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 ?
>  
>
I totally agree. Currently I am not very worried about compatibility 
problems since there is only one version say xerces used by all the 
apps. In my case, I had no way of getting #2 and since we were running 
all the applications on enhydra multiserver that becomes important to me.

>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...!?
>  
>
Agreed. Moreover I dont think setting the parent to null will solve the 
problem. We still need to have hierarchy of loaders and respect their 
namespaces.

Thanks,
Srini.

>-----Ursprüngliche Nachricht-----
>Von: Srinivas Yermal [mailto:[email protected]] 
>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:[email protected]]
>>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
>[email protected] http://www.enhydra.org/mailman/listinfo.cgi/enhydra
>  
>