JBREM-1019, RemotingClassLoader parent first behavior

[starksm64]

For the jbossas5 app client container, a class loader policy that loads from the child first is used to pickup the client jar manifest references. If such a class loader is registered as the user class loader with the RemotingClassLoader, its not going be delegated to first. This results in duplicate and conflicting classes being loaded. There needs to be an option to delegate to the user class loader before the parent.

[starksm64]

Is https://svn.jboss.org/repos/jbossremoting/remoting2/branches/2.x/ the current branch for the 2.4.x series?

[dmlloyd]

Yes it is.

[ron_sigal]

I've assigned JBREM-1019 to Remoting version 2.4.0.SP1, which is intended for JBossAS-5.0.0.CR2. Do we have an expected date for JBossAS-5.0.0.CR2?

[starksm64]

asap, mid to late aug. I'm working on a patch now so I can test that this really solves the problem. I'll attach the patch to the issue once it looks like its what I need.

[starksm64]

The patch I just attached to the issue allows the appclient tests I have been working on to pass.

[ron_sigal]

"scott.start*jboss.org" wrote:

asap, mid to late aug.

Will do.

[ron_sigal]

Scott, normally we would set up the configuration just at initialization. Is there a reason to respond to the current value of the "org.jboss.remoting.classloadingParentFirstDelegation" system property with each invocation? It adds extra work to the invocation "critical path".