>Hi, Jan.
>
>This seems like it would be fairly straightforward. Here are the
>public methods required by URLClassLoader that are not required by
>SecureClassLoader:
Based on feedback from Ken Saks, we're also going to rename
"EJBClassLoader" to "ApplicationClassLoader", in order to
disassociate it from the EJB container and to more accurately
reflect its responsibilities.
Jan
>
>*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
>
>
>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!)
>
>- 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