One thing I noticed when looking at the current v3 code:
WebModuleListener.configJsp calls the
ASClassLoadeUtil.getModuleClassPath to set its classpath, and the
deployment libraries is added as the part of this call through
ASClassLoaderUtil.addDeployParamLibrariesForModule. In case of the
standalone war, the moduleId passed into ASClassLoaderUtil is the proper
application name, so the libraries were added as expected. In case of
the ear, the moduleId passed into ASClassLoaderUtil is "" so the
libraries were not added. The WebModuleListener uses webModule.getID()
to get the id, not sure why it's empty string. I expect it might be
something like appName#webModuleName which we would derive the app name
from, but it should not be an empty string?
Jan, any idea?
- Hong
Sahoo wrote:
> Unless JSP module does something special, this bug should show up in
> v3 as well. The fix may not be entirely possible given the modular
> nature of V3, which means we are not in control of classloaders for
> all modules of an application. However, we can definitely fix the
> problem for most cases. Actually I am pretty sure there are many more
> URLs not added to JSPC's classpath in v3. e.g., URLs of deployed
> standalone RARs. The fix is needed in following places:
>
> 1. add a getClassPath() method in
> org.glassfish.internal.api.DelegatingClassLoader.ClassFinder. Add
> getClassPath method in
> org.glassfish.internal.api.DelegatingClassLoader. The implementation
> of the latter method should delegate to all the delegates before
> asking if the parent has any ClassPath.
>
> 2. add a similar method in classloaders below AppLibClassLoader and
> use it in appropriate place.
>
> Thanks,
> Sahoo
>
> Dies Koper wrote:
>
>> Hi Siva, Jerome, Kin-Man, Sahoo,
>>
>> Could you assist me to fix issue #7507?
>> (Kin-Man reported a similar issue (#4883) and reported it was fixed, but
>> may that was just for WAR files, I'm seeing it for EAR files.)
>>
>> I have attached a fix to the issue. I confirmed it works on V2.1.
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=7507
>>
>> I changed the following class (who's in charge of this file?).
>> glassfish/appserv-core/src/java/com/sun/appserv/server/util/ClassLoaderChain.java
>>
>>
>> Could you review it?
>>
>> When compiling the JSP, the classpath is taken from the
>> WebappClassLoader up. The path specified to the --libraries option is
>> kept in ASURLClassLoader, which is held by ClassLoaderChain.
>>
>> ConnectorClassLoader (extends URLClassLoader)
>> |
>> ClassLoaderChain (extends SecureClassLoader) <---
>> |
>> EJBClassLoader (extends URLClassLoader)
>> |
>> WebappClassLoader (extends URLClassLoader)
>> |
>> JspLoader (extends URLClassLoader)
>>
>> The classpath is constructed using URLClassLoader#getURLs but
>> ClassLoaderChain does not extend URLClassLoader so the path can't be
>> obtained that way, and it provides no method to obtain the URLs from the
>> classloader it holds.
>> The proposed patch offers that method.
>>
>>
>> This class has been refactored out in V3. Where would I put these
>> methods to make it work for GF V3 too?
>>
>> Thanks,
>> Dies
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>