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
----- Original Message -----
From: "Rajini Sivaram" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Friday, February 22, 2008 12:38 PM
Subject: Re: Classloading code in core contribution processing
Sebastien,
On 2/22/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Cut some sections and reordered for readability.
...
>> Jean-Sebastien Delfino wrote:
>> - we can use ModelResolvers (1) or bypass them (2)
>> - ModelResolvers don't handle import cycles and partial packages
>>
>> I think that (1) is better. Do you have a use case for cycles and
>> partial packages right now or can it be fixed later?
...
Rajini Sivaram wrote:
> ContributionTestCase in itest/contribution-classloader contains a test
which
> runs into stack overflow if classes are resolved using ModelResolver. I
have
> added another test in there for testing for ClassNotFoundException in
the
> same scenario. To trigger the failure, you need to modify
> ContributionClassLoader.findClass to use the model resolver of
> exporting
> contributions to resolve classes instead of their classloader.
Great to see a *test* case for cycles, but my question was: Do you have
a *use* case for cycles and partial packages right now or can it be
fixed later?
No, I dont have an use-case, at least not an SCA one. But there are plenty
of them in OSGi - eg. Tuscany modules cannot run in OSGi without support
for
split-packages. Of course you can fix it later. But IMHO, breaking
classloading to improve modularity is hardly worthwhile (all the
classloading related implementation code is now contained in
contribution-java, so the improvement will be very marginal). Classloading
errors tend to be hard to fix because classloading is often triggered by
the
VM and not explicitly by the application. If potential stack overflows are
introduced into classloading, it wont be long before someone else
complains
"All this complexity related to classloading makes my head spin". And
chances are we will be back to a single CLASSPATH based classloader. That
is
just my opinion.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thank you...
Regards,
Rajini
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
