Raymond Feng wrote:
Hi,
I don't want to intercept the discussion but I'm wondering if we should
define the pluggability of the classloading scheme for SCA contributions.
Typically we have the following information for a ready-to-deploy unit:
* The URL of the deploment composite (deployable composite)
* A collection of URLs for the required contributions to support the SCA
composite
There are some class relationship defined using "import.java" and
"export.java". In different environments, we may need to have different
classloaders to deal with java classes in the collection of
contributions. Should we define a SPI as follows to provide the
pluggability?
public interface ClassLoaderProvider {
// Start the classloader provider for a collection of contributions
(deployment unit)
void start(List<Contribution> contributions);
// Get the classloader for a given contribution in the deployment unit
ClassLoader getClassLoaders(Contribution contribution);
// Remove the contributions from the provider
void stop(List<Contribution> contributions);
}
Thanks,
Raymond
This is an interesting proposal but I think it's orthogonal to the
discussion we've been having on contribution import cycles and support
for partial packages.
Import cycles and partial namespaces are not specific to Java and can
occur too with WSDL/XSD. I think we should handle them in a Java (and
ClassLoader) independent way.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
