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: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
| 