You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2008/01/03 01:05:19 UTC
Re: Using contributions in the tutorial, was: Improving the store
tutorial module structure
Rajini Sivaram wrote:
> Sebastien,
>
> Sorry, ignore my previous note (the one below). Even with assets not in the
> classpath, I can run launch.LaunchCloud as long as the assets contribution
> is added first. The code in svn does:
>
>
> currencyNode.addContribution("http://cloud", cloudContribution);
>
> catalogsNode.addContribution("http://assets", assetsContribution);
>
> assets should be aded to currencyNode before cloud (at least with the
> current code). With that change, it runs without throwing any exceptions.
>
>
With the latest code and after fixing the addContribution calls
LaunchCloud now works for me too. Thanks.
However, after starting LaunchCloud, starting LaunchStore throws the
exception below, as o.a.t.implementation.data.api.collection.Collection
is required by services.ShoppingCart but not on the contribution path.
Adding implementation-data-api.jar and derby.jar as contributions (as I
did in SVN r608288) is not sufficient as these JARs don't have an
sca-contribution.xml exporting their classes.
Summary: classes that depend on existing JARs (likely to happen in many
component implementation classes) cannot be loaded from SCA
contributions, as the existing JARs are not properly handled by the
contribution processor.
I'll try to fix the contribution processor, the contribution ClassLoader
and the import/export machinery later this week.
P.S. Simon, I don't think that you need to wait for the fix for the 1.1
release.
Here's the exception:
Exception in thread "main" java.lang.NoClassDefFoundError:
org.apache.tuscany.sca.implementation.data.collection.Collection
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:228)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:557)
at java.net.URLClassLoader.access$400(URLClassLoader.java:120)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:962)
at java.security.AccessController.doPrivileged(AccessController.java:275)
at java.net.URLClassLoader.findClass(URLClassLoader.java:488)
at
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClassFromContribution(ContributionClassLoader.java:281)
at
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass(ContributionClassLoader.java:85)
at
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.loadClass(ContributionClassLoader.java:142)
at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:228)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:557)
at java.net.URLClassLoader.access$400(URLClassLoader.java:120)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:962)
at java.security.AccessController.doPrivileged(AccessController.java:275)
at java.net.URLClassLoader.findClass(URLClassLoader.java:488)
at
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClassFromContribution(ContributionClassLoader.java:281)
at
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass(ContributionClassLoader.java:85)
at
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass(ContributionClassLoader.java:98)
at
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.loadClass(ContributionClassLoader.java:142)
at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:163)
at
org.apache.tuscany.sca.contribution.java.impl.ClassReferenceModelResolver.resolveModel(ClassReferenceModelResolver.java:95)
at
org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:127)
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:145)
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:1)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:242)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
at
org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:241)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:794)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:1)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:113)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:1)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:423)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:333)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:169)
at
org.apache.tuscany.sca.node.impl.SCANodeImpl.addContributionFromDomain(SCANodeImpl.java:321)
at
org.apache.tuscany.sca.node.impl.SCANodeImpl.addContribution(SCANodeImpl.java:484)
at
org.apache.tuscany.sca.node.impl.SCANodeImpl.addContribution(SCANodeImpl.java:478)
at launch.LaunchStore.main(LaunchStore.java:45)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using contributions in the tutorial, was: Improving the store
tutorial module structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> To summarize, I'm suggesting that:
> - SCA contributions must list dependencies in sca-contribution.xml
I have started to do it in assets.jar in SVN r609100.
> - existing JARs with no sca-contribution.xml export all their classes
Implemented in SVN r609099.
> - most of the code currently in LaunchStore should be automated/hidden
>
More on this later.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using contributions in the tutorial, was: Improving the store
tutorial module structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
>> On 1/3/08, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> (1) and (2) should work the same way. Requiring internal dependencies of
>> assets.jar to be added to the classpath defeats the purpose of using SCA
>> contributions.
>
> Rajini Sivaram wrote:
> (1) store.jar finds classes from assets.jar only if the package containing
> the class is exported by assets.jar (the provider of the package decided to
> export it) AND store.jar imports the package.
>
> How can (2) work in the same way? Will assets.jar explicitly import the
> packages from foo.jar, since it is a regular SCA contribution containing
> export/import statements in sca-contribution.xml?
Yes [1]
>
> What about import/exports for foo.jar? foo.jar is not a regular SCA
> contribution (at least it is different because it doesn't contain
> sca-contribution.xml). Does that mean that all classes from foo.jar are
> considered exported?
I'm considering that, yes.
> What if foo.jar requires another bar.jar? Will
> foo.jar automatically import all classes from all contributions (
> bar.jar and even assets.jar since there is no dependency list for foo)?
>
There may be a better way, but I'm thinking about defining assets.jar's
classpath in assets.jar's sca-contribution.xml. [2]
>
> I am not sure I understand what you meant by "as a user of assets.jar I
> shouldn't have to know".
>
As a developer of store.jar I am using a ShoppingCart component
implementation from assets.jar, I don't want to know that ShoppingCart
has dependencies on derby.jar or foo.jar.
> LaunchStore (which is a user of assets.jar) does:
> node.addContribution("http://org/apache/derby", derbyContribution);
> node.addContribution("
> http://org/apache/tuscany/implementation-data-api", dataAPIContribution);
> node.addContribution("http://assets", assetsContribution);
>
and I should not have to write the above code at all :) [3]
> What is the knowledge that you can do without by adding a dependency as a
> contribution? Unless there is proper provisioning for SCA contributions
> where I can install assets.jar and derby.jar and
> implementation-data-api.jarget automatically installed, I dont see any
> difference in terms of what a
> user needs to know between adding non-SCA contributions as contributions and
> adding them as entries in the thread context classloader. As far as I can
> tell, the difference between contributions and classpath is in package
> visibility scoping which can be explicitly specified for contributions, but
> is free for all with classpath. But won't these rules be diluted by enabling
> internal dependencies to be added as contributions in their own right
> without imposing any visibility restrictions (almost as if they have been
> added to classpath)?
Sorry I'm not able to parse that long question, could you please
summarize it?
>
> IMHO, assets.jar should have some way of specifying that it wants to import
> classes from foo.jar - either an explicit import statement, or a dependency
> on another contribution, which makes the assets contribution classloader
> search foo's contribution classpath.
Yes, same as the "Yes [1]" above.
And foo.jar should preferably be able
> to specify its dependencies on other contributions/jars using the node API
> rather than through sca-contribution.xml.
>
See [2] and [3], I need a reasonable approach to existing JARs and cut
on the API calls.
To summarize, I'm suggesting that:
- SCA contributions must list dependencies in sca-contribution.xml
- existing JARs with no sca-contribution.xml export all their classes
- most of the code currently in LaunchStore should be automated/hidden
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using contributions in the tutorial, was: Improving the store tutorial module structure
Posted by Rajini Sivaram <ra...@googlemail.com>.
On 1/3/08, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Rajini Sivaram wrote:
> >
> > Why would you want to add implementation-data-api.jar and derby.jar as
> > contributions rather than as maven (and Eclipse) project dependencies?
>
> Here's the scenario:
> 1. Contribution store.jar imports classes from contribution assets.jar.
> 2. Classes in assets.jar depend on foo.jar (derby.jar in my example but
> could be any JAR containing runtime and/or business classes).
Sorry, I was confused because I saw implementation-data-api.jar and thought
it was a Tuscany runtime dependency rather than an internal dependency of
assets.jar.
(1) and (2) should work the same way. Requiring internal dependencies of
> assets.jar to be added to the classpath defeats the purpose of using SCA
> contributions.
(1) store.jar finds classes from assets.jar only if the package containing
the class is exported by assets.jar (the provider of the package decided to
export it) AND store.jar imports the package.
How can (2) work in the same way? Will assets.jar explicitly import the
packages from foo.jar, since it is a regular SCA contribution containing
export/import statements in sca-contribution.xml?
What about import/exports for foo.jar? foo.jar is not a regular SCA
contribution (at least it is different because it doesn't contain
sca-contribution.xml). Does that mean that all classes from foo.jar are
considered exported? What if foo.jar requires another bar.jar? Will
foo.jarautomatically import all classes from all contributions (
bar.jar and even assets.jar since there is no dependency list for foo)?
With
> > tuscany-implementation-data-api and derby as dependencies in pom.xml,
> I am
> > able to run LaunchStore without any exceptions (from Eclipse with the
> > .classpath file generated from the modified pom.xml).
>
> Sure, it works for me too, but defeats the purpose of SCA contributions,
> as a user of assets.jar I shouldn't have to know about its dependencies
> on other jars.
I am not sure I understand what you meant by "as a user of assets.jar I
shouldn't have to know".
LaunchStore (which is a user of assets.jar) does:
node.addContribution("http://org/apache/derby", derbyContribution);
node.addContribution("
http://org/apache/tuscany/implementation-data-api", dataAPIContribution);
node.addContribution("http://assets", assetsContribution);
What is the knowledge that you can do without by adding a dependency as a
contribution? Unless there is proper provisioning for SCA contributions
where I can install assets.jar and derby.jar and
implementation-data-api.jarget automatically installed, I dont see any
difference in terms of what a
user needs to know between adding non-SCA contributions as contributions and
adding them as entries in the thread context classloader. As far as I can
tell, the difference between contributions and classpath is in package
visibility scoping which can be explicitly specified for contributions, but
is free for all with classpath. But won't these rules be diluted by enabling
internal dependencies to be added as contributions in their own right
without imposing any visibility restrictions (almost as if they have been
added to classpath)?
IMHO, assets.jar should have some way of specifying that it wants to import
classes from foo.jar - either an explicit import statement, or a dependency
on another contribution, which makes the assets contribution classloader
search foo's contribution classpath. And foo.jar should preferably be able
to specify its dependencies on other contributions/jars using the node API
rather than through sca-contribution.xml.
--
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Thank you...
Regards,
Rajini
Re: Using contributions in the tutorial, was: Improving the store
tutorial module structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Rajini Sivaram wrote:
>
> Why would you want to add implementation-data-api.jar and derby.jar as
> contributions rather than as maven (and Eclipse) project dependencies?
Here's the scenario:
1. Contribution store.jar imports classes from contribution assets.jar.
2. Classes in assets.jar depend on foo.jar (derby.jar in my example but
could be any JAR containing runtime and/or business classes).
(1) and (2) should work the same way. Requiring internal dependencies of
assets.jar to be added to the classpath defeats the purpose of using SCA
contributions.
With
> tuscany-implementation-data-api and derby as dependencies in pom.xml, I am
> able to run LaunchStore without any exceptions (from Eclipse with the
> .classpath file generated from the modified pom.xml).
Sure, it works for me too, but defeats the purpose of SCA contributions,
as a user of assets.jar I shouldn't have to know about its dependencies
on other jars.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using contributions in the tutorial, was: Improving the store tutorial module structure
Posted by Rajini Sivaram <ra...@googlemail.com>.
On 1/3/08, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Rajini Sivaram wrote:
> > Sebastien,
> >
> > Sorry, ignore my previous note (the one below). Even with assets not in
> the
> > classpath, I can run launch.LaunchCloud as long as the assets
> contribution
> > is added first. The code in svn does:
> >
> >
> > currencyNode.addContribution("http://cloud", cloudContribution);
> >
> > catalogsNode.addContribution("http://assets", assetsContribution);
> >
> > assets should be aded to currencyNode before cloud (at least with the
> > current code). With that change, it runs without throwing any
> exceptions.
> >
> >
>
> With the latest code and after fixing the addContribution calls
> LaunchCloud now works for me too. Thanks.
>
> However, after starting LaunchCloud, starting LaunchStore throws the
> exception below, as o.a.t.implementation.data.api.collection.Collection
> is required by services.ShoppingCart but not on the contribution path.
>
> Adding implementation-data-api.jar and derby.jar as contributions (as I
> did in SVN r608288) is not sufficient as these JARs don't have an
> sca-contribution.xml exporting their classes.
>
> Summary: classes that depend on existing JARs (likely to happen in many
> component implementation classes) cannot be loaded from SCA
> contributions, as the existing JARs are not properly handled by the
> contribution processor.
>
> I'll try to fix the contribution processor, the contribution ClassLoader
> and the import/export machinery later this week.
>
> P.S. Simon, I don't think that you need to wait for the fix for the 1.1
> release.
>
> Here's the exception:
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org.apache.tuscany.sca.implementation.data.collection.Collection
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:228)
> at java.security.SecureClassLoader.defineClass(
> SecureClassLoader.java:148)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:557)
> at java.net.URLClassLoader.access$400(URLClassLoader.java:120)
> at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:962)
> at java.security.AccessController.doPrivileged(
> AccessController.java:275)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:488)
> at
>
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClassFromContribution
> (ContributionClassLoader.java:281)
> at
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass
> (ContributionClassLoader.java:85)
> at
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.loadClass
> (ContributionClassLoader.java:142)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:228)
> at java.security.SecureClassLoader.defineClass(
> SecureClassLoader.java:148)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:557)
> at java.net.URLClassLoader.access$400(URLClassLoader.java:120)
> at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:962)
> at java.security.AccessController.doPrivileged(
> AccessController.java:275)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:488)
> at
>
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClassFromContribution
> (ContributionClassLoader.java:281)
> at
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass
> (ContributionClassLoader.java:85)
> at
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass
> (ContributionClassLoader.java:98)
> at
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.loadClass
> (ContributionClassLoader.java:142)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:163)
> at
>
> org.apache.tuscany.sca.contribution.java.impl.ClassReferenceModelResolver.resolveModel
> (ClassReferenceModelResolver.java:95)
> at
>
> org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel
> (ExtensibleModelResolver.java:127)
> at
>
> org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve
> (JavaImplementationProcessor.java:145)
> at
>
> org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve
> (JavaImplementationProcessor.java:1)
> at
>
> org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve
> (DefaultStAXArtifactProcessorExtensionPoint.java:242)
> at
>
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve
> (ExtensibleStAXArtifactProcessor.java:108)
> at
>
> org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation
> (BaseAssemblyProcessor.java:241)
> at
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(
> CompositeProcessor.java:794)
> at
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(
> CompositeProcessor.java:1)
> at
>
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve
> (ExtensibleStAXArtifactProcessor.java:108)
> at
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(
> CompositeDocumentProcessor.java:113)
> at
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(
> CompositeDocumentProcessor.java:1)
> at
>
> org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve
> (ExtensibleURLArtifactProcessor.java:86)
> at
>
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase
> (ContributionServiceImpl.java:423)
> at
>
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution
> (ContributionServiceImpl.java:333)
> at
>
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute
> (ContributionServiceImpl.java:169)
> at
> org.apache.tuscany.sca.node.impl.SCANodeImpl.addContributionFromDomain(
> SCANodeImpl.java:321)
> at
> org.apache.tuscany.sca.node.impl.SCANodeImpl.addContribution(
> SCANodeImpl.java:484)
> at
> org.apache.tuscany.sca.node.impl.SCANodeImpl.addContribution(
> SCANodeImpl.java:478)
> at launch.LaunchStore.main(LaunchStore.java:45)
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Sebastien,
Why would you want to add implementation-data-api.jar and derby.jar as
contributions rather than as maven (and Eclipse) project dependencies? With
tuscany-implementation-data-api and derby as dependencies in pom.xml, I am
able to run LaunchStore without any exceptions (from Eclipse with the
.classpath file generated from the modified pom.xml). I must have missed the
point entirely...
Unlike OSGi bundle dependencies which require all imported packages to be
exported by OSGi bundles, the SCA contribution classloader was designed to
enable Tuscany runtime and other 3rd party libraries to be accessed directly
from contributions without converting these into contributions. The default
thread context classloader is the parent of all contribution classloaders.
Hence all classes in the CLASSPATH are accessible from the contribution
classloader. The packages imported from outside SCA contributions do not
require import statements (import/export statements are used only across SCA
contributions).
Thank you...
Regards,
Rajini
Re: Using contributions in the tutorial, was: Improving the store tutorial module structure
Posted by Simon Laws <si...@googlemail.com>.
On Jan 3, 2008 12:05 AM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Rajini Sivaram wrote:
> > Sebastien,
> >
> > Sorry, ignore my previous note (the one below). Even with assets not in
> the
> > classpath, I can run launch.LaunchCloud as long as the assets
> contribution
> > is added first. The code in svn does:
> >
> >
> > currencyNode.addContribution("http://cloud", cloudContribution);
> >
> > catalogsNode.addContribution("http://assets", assetsContribution);
> >
> > assets should be aded to currencyNode before cloud (at least with the
> > current code). With that change, it runs without throwing any
> exceptions.
> >
> >
>
> With the latest code and after fixing the addContribution calls
> LaunchCloud now works for me too. Thanks.
>
> However, after starting LaunchCloud, starting LaunchStore throws the
> exception below, as o.a.t.implementation.data.api.collection.Collection
> is required by services.ShoppingCart but not on the contribution path.
>
> Adding implementation-data-api.jar and derby.jar as contributions (as I
> did in SVN r608288) is not sufficient as these JARs don't have an
> sca-contribution.xml exporting their classes.
>
> Summary: classes that depend on existing JARs (likely to happen in many
> component implementation classes) cannot be loaded from SCA
> contributions, as the existing JARs are not properly handled by the
> contribution processor.
>
> I'll try to fix the contribution processor, the contribution ClassLoader
> and the import/export machinery later this week.
>
> P.S. Simon, I don't think that you need to wait for the fix for the 1.1
> release.
OK
>
>
> Here's the exception:
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org.apache.tuscany.sca.implementation.data.collection.Collection
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:228)
> at java.security.SecureClassLoader.defineClass(
> SecureClassLoader.java:148)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:557)
> at java.net.URLClassLoader.access$400(URLClassLoader.java:120)
> at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:962)
> at java.security.AccessController.doPrivileged(
> AccessController.java:275)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:488)
> at
>
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClassFromContribution
> (ContributionClassLoader.java:281)
> at
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass
> (ContributionClassLoader.java:85)
> at
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.loadClass
> (ContributionClassLoader.java:142)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:228)
> at java.security.SecureClassLoader.defineClass(
> SecureClassLoader.java:148)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:557)
> at java.net.URLClassLoader.access$400(URLClassLoader.java:120)
> at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:962)
> at java.security.AccessController.doPrivileged(
> AccessController.java:275)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:488)
> at
>
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClassFromContribution
> (ContributionClassLoader.java:281)
> at
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass
> (ContributionClassLoader.java:85)
> at
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass
> (ContributionClassLoader.java:98)
> at
> org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.loadClass
> (ContributionClassLoader.java:142)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:163)
> at
>
> org.apache.tuscany.sca.contribution.java.impl.ClassReferenceModelResolver.resolveModel
> (ClassReferenceModelResolver.java:95)
> at
>
> org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel
> (ExtensibleModelResolver.java:127)
> at
>
> org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve
> (JavaImplementationProcessor.java:145)
> at
>
> org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve
> (JavaImplementationProcessor.java:1)
> at
>
> org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve
> (DefaultStAXArtifactProcessorExtensionPoint.java:242)
> at
>
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve
> (ExtensibleStAXArtifactProcessor.java:108)
> at
>
> org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation
> (BaseAssemblyProcessor.java:241)
> at
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(
> CompositeProcessor.java:794)
> at
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(
> CompositeProcessor.java:1)
> at
>
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve
> (ExtensibleStAXArtifactProcessor.java:108)
> at
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(
> CompositeDocumentProcessor.java:113)
> at
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(
> CompositeDocumentProcessor.java:1)
> at
>
> org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve
> (ExtensibleURLArtifactProcessor.java:86)
> at
>
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase
> (ContributionServiceImpl.java:423)
> at
>
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution
> (ContributionServiceImpl.java:333)
> at
>
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute
> (ContributionServiceImpl.java:169)
> at
> org.apache.tuscany.sca.node.impl.SCANodeImpl.addContributionFromDomain(
> SCANodeImpl.java:321)
> at
> org.apache.tuscany.sca.node.impl.SCANodeImpl.addContribution(
> SCANodeImpl.java:484)
> at
> org.apache.tuscany.sca.node.impl.SCANodeImpl.addContribution(
> SCANodeImpl.java:478)
> at launch.LaunchStore.main(LaunchStore.java:45)
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>