On Mar 6, 2007, at 2:10 AM, Dan Murphy wrote:
probably due to my j2ee experiences... I was wondering how / if the runtime would react to different versions of the same component/composite, but I'm sure we have some for of classloader isolation that would handle this...
In 1.x we associated classloaders with composites and the classloader hierarchy matched the composition tree. Users could add to the classpath for each composite classloader using <dependency> elements in the SCDL. There were problems sharing classes between the runtime and application (e.g. SDO or Spring framework classes).
In 2.x we want to support sparse component trees and so are decoupling the classloader hierarchy from the composition hierarchy. ClassLoaders will simply be resources that get created in a physical runtime and referenced by component containers.
just use to the j2ee way and had assumed (due to launcher's command line arguments) that composites needed to be packaged (in a jar or similar) so that they could be contributed to the domain - obviously got that wrong :)
That made sense in 1.x. For 2.0-alpha we wanted to move to a model where the launcher was given a component to launch (of the "launched" implmentation type) and would resolve the resources from the domain (i.e. based on contributed classes). There's still work to be done on the ContributionService to support that so for now we're still basing it on the jar. That should change for alpha2.
-- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
