Hi Tim,
Tim Quinn wrote On 04/24/06 08:34,:
> Hi, Jan.
>
> This seems like it would be fairly straightforward. Here are the public
> methods required by URLClassLoader that are not required by
> SecureClassLoader:
> *URLClassLoader method
> * *EJBClassLoader method
> * *Notes
> *
> public void addURL(URL url)
> public void appendURL(URL url)
> Requires adding the addURL method which would simply delegate to appendURL
> public URL findResource(String name)
> protected URL findResource(String name)
> Requires change from protected to public
> public Enumeration<URL> findResources(String name)
> protected Enumeration<URL> findResources(String name)
> Requires change from protected to public
> public URL[] getURLs()
> public URL[] getURLs()
> Already implemented as required
thanks for this analysis!
> Of course changes such as these would require robust testing to make
> sure no existing code was broken, but considering that the changes are
> the addition on one method and the broadening of access on two others,
> these changes would seem relatively low-risk.
>
> Would the web container team be willing to make these changes and run
> the tests to make sure all was well? (hint!)
Yes, we can own this task and make the changes you suggested above.
Thanks!
Jan
>
> - Tim
>
>
>
> Jan Luehe wrote:
>
>> Would it be possible to have com.sun.enterprise.loader.EJBClassLoader
>> extend java.net.URLClassLoader, like most classloaders in the
>> appserver's classloader hierarchy already do?
>>
>> When searching for TLD resources in the classloader delegation chain,
>> the webcontainer currently only considers classloaders that are
>> instances of URLClassLoader, and scans each URL returned by getURLs()
>> for TLDs. Since EJBClassLoader, which is installed as the parent of a
>> webmodule's WebappClassLoader, does not extend EJBClassLoader, its JAR
>> files are skipped, causing
>>
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=590
>>
>> We'd like to avoid special-casing EJBClassLoader, and also must avoid
>> referencing the EJBClassLoader symbol from the webcontainer code.
>>
>> EJBClassLoader currently extends java.security.SecureClassLoader,
>> which it no longer would have to do once it extended URLClassLoader,
>> which in turn already extends SecureClassLoader.
>>
>> From looking at the EJBClassLoader source code, it seems like
>> converting it to a URLClassLoader should be an easy task, since it
>> already manages its resources as a set of URLs (which it exposes via
>> its getURLs() method).
>>
>> Comments?
>>
>> Thanks,
>>
>>
>> Jan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>