Hi all,
I have a kind of limitations in the classloader with the RMI component.
Here is the explanation. I have a set of SU/SA. All of theses SU use a
set of jar. To reduce the size of the SU and be able to update theses
jars without rebuilding/redeploy SU, I have add theses jars in the
lib/optional directory.
Now, I have create a RMI consumer endpoint that use a POJO:
<rmi:consumer service="my:service" endpoint="RmiEndpoint"
name="my/service/rmi">
<rmi:pojo>
<bean class="org.apache.servicemix.sample.RmiTest"/>
</rmi:pojo>
</rmi:consumer>
In the RMI component, I have CXF jars embedded to manage the WSDL
generation and data binding.
For example, if I want to use CXF in my RmiTest POJO (for example to
create a WS client), I have a classloader issue. By default, the
classloader hierarchy is: container / component / SU.
In my case, the POJO uses the CXF jars at the component classloader
level in place of the SU level.
I tried to define classloader self-delegation (in the pom and using
<classpath inverse="true"/> in the xbean.xml), and this, I got a
Spring/XBean exception ("the namspace doesn't implement ...", even if I
add exclusion in pom dependency).
For now, the only workaround that I found is to remove all the CXF stuff
in the RMI component.
I haven't yet tried to create a shared lib and refer it in my xbean.xml.
As SMX3/NMR is a container, I would like to have your feedback about
extend the classloader policy. Currently, we can:
- inverse the classloader order
- extend the SU classloader to use the component/shared lib/external jar
(using the <classpath/> tag).
I propose to give a way to the use to define more fine grained
classloading policy:
- be able to define a unique classloader (like in JBoss by default when
you don't use isolated property)
- be able to define the classloader order at the container level
- be able to merge classloaders (for example, define a classaloder
policy like container / component)
- be able to add a SU classloader defining parent first/parent last
(like we can do using a shared lib).
Like this, the user can defined the classloader that cover a large scope
of classloading issue.
What do you think on this ?
Regards
JB
