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