2012/11/12 Daniel Kulp <[email protected]>: > Interesting. In theory, those classes are all provides by the system runtime > since they've been built into the JDK for a long time. Thus, they should be > pulled from there unless they are either endorsed via the normal endorse > mechanisms or something explicitely sets some sort of parent last class > loader and doesn't allow them to pass through.
You're totally right, that's why only some persons have this issue: I voluntary changed the behavior of the classloader using ocntainer-specific parameters in jonas and jboss. Why ? Because many java EE containers come with tons of "services". However those services (like jax-ws auto deployment based on CXF ^_^) come with a fixed version of ... CXF in this case. But I want to use CXF 2.7.0, and my container contains CXF 2.5.2. I don't want to ask the installation team to mess with the container, so I put the parameter to change the classpath order. Now, for my war only, the embedded jars will be looked at first when looking for a class. That way I'm not dependent (well... less than before) of the container. Of course my war is bigger because I don't re-use the container's included libs. But in this case, a usually invisible problem (the alien classes in xmlbeans) becomes visible ^_^ Anyway, thanks a lot for your support ! I realize that i mightbe in a specific situation, wanting asynchronous api and NIO everywhere, and even with this classloader tweak ! !
