Yes, provided this is not also used in the jsp classpath. If it is, another way of providing the jsp classpath is needed. It should not be relevant for the jdt based compiler though.

The standard URL CL getURLs method is used for these things in Tomcat: scanning for TLDs (in Catalina and Jasper), security manager permissions setup (in Jasper), and classpath setup for Jasper.

Hello,

I have added a patch to the 5022 request.
I am not sure of it, so can you give a quick look at it ?

Thanks,

Thanks for the patch, but I would not expect the aspects/src/main/org/jboss/aspects/remoting/InvokeRemoteInterceptor.java to be involved. Are you using aop remoting in your setup?

No I don't think that I am using aop. But I am not very skilled in EJBs & so.

My setup was this one :

- A Tomcat server (with jbossall-client.jar) with a web app which was calling an ejb remotely.
- A JBoss server on an other machin, which was serving the EJB.

When I was using a method with a parameter which was a class of my WebApp, all the classpath of the Tomcat was sent in the RMI call. This classpath was of no use for JBoss. And it was flooding the network.

I just used an old and good debugger to find where was the problem. And I thought it was the best way of patching it.

The issue here is
WebappClassLoader.toURLs() returning a lot of data that gets added
to the RMI streams as "annotations".

We don't want this, so this either needs to be fixed by

* returning

@Override
public URL[] getURLs()
{
 return new URL[0]; // Optimize away the Memory Allocation
}

* Works for me. I'll commit it to test it.
* This used to be the useJBossWebLoader option, but it seems it has been removed.