1) we can support ordinary jars by adding multi-parent support to the composite classloader. This would work in conjunction with the XML dependency mechanism by allowing the dependency to be loaded in an isolated classloader which would then be one parent of the runtime component and one parent of the application component. The extension would determine which resources it wanted to share with the application and which it would want to keep priviate; for example, the AXIOM databinding might choose to share axiom-api but would keep the impl private.
I like this idea as a (relatively) simple answer to how extensions share their dependencies with application code. I assume that the classloader associated with children components in the app tree delegate to their parent component's classloader(s)? So when an app component is given access by to certain resources by its runtime implementation, that access is passed on to the app component's child components? Thoughts on the search order/priority for these classloader hierarchies? Child-before-parent has some real advantages here -- it lets extensions specify exactly what version of a dependency to use and expose to its consumers, rather than have the hosting environment potentially hose it by globally exposing an incompatible version. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
