Hi.
There is a good page on GF classloaders :
http://docs.oracle.com/cd/E18930_01/html/821-2418/beadf.html
I'm trying to understand where does stuff really go, though.
1) when I run 'asadmin add-library' with type 'common', it will be picked
up by "Common" class-loader.
2) 'add-library' with type 'ext', goes into "Extension" class-loader
3) 'add-library' with type 'app' - now, that I don't fully understand. It
seems that they will go to "Applib" classloader. Applib classloader is one
per universe. So, the library will be loaded as many times as there are
individually deployed applications. Some statements for this classloader,
however, are a bit confusing:
- <quote>When multiple deployed applications use the same library, they
share the same instance of the library</quote>
How does this happen? For 2 individual apps, there must be 2 Applib
classloaders, and 2 classloaders, IMHO, can not share classes.
- <quote>One library cannot reference classes from another library</quote>
I assume this meant to say "One library cannot reference classes from
another library deployed in same Applib classloader", but I don't see why
can't they, considering that they are in the same classloader, IMHO, the
only way to prevent access between different classes is to put them into
different classloaders...
4) All classes that are found in a deployed application package, or
generated for it, will live in a single classloader, "Archive". I have one
concern here - then how are dynamically changed JSPs handled? IMHO, it's
not possible to reload a class in a classloader, the only way to - is to
dump the classloader and create a new one. So, any classes that may change,
have to have their own classloader...
When I tried printing out classloader info from a JSP, this is what I see:
- a class from EAR/lib/x.jar is loaded by EarLibClassLoader
- JSP class is loaded by JasperLoader
- JSP can not access a class from a bean, that's part of EAR/beans.jar
(registered in application.xml)
So, would it be fair to say that each EAR has a "library" classloader, then
individual class loader for every deployed module, and then, within each
module, you can also have classloader for run-time generated data, if such
exists for this module? For non-EAR modules, that would be the same, except
that the EAR library classloader will be missing.
Thank you,
Pawel.