1) I don't think your "fix" is right. As I explained before, the sca-contribution.xml can contain composites that are packaged in other contributions. What if we have c1 in the local contribution, and c2 in another contribution? Are you returning one resolved Composite and another unresolved Composite?
2) For the contribution without sca-contribution.xml, it's not clear we should take all of them or none of them as deployables. The SCA spec guys should define how it works. Tuscany happened to choose "all of them". I'm fine to switch to "none of them" too as the composites can be internal composites to be included or used as "implemention.composite", or referenced in another contribution in the sca-contribution.xml. 3) Potentially, we could support incremental resolution when contributions are added, like how OSGi install and resolve bundles. Thanks, Raymond On Fri, Aug 6, 2010 at 7:48 PM, ant elder <[email protected]> wrote: > I agree with you Raymond but i think Yang is right too and the > deployer should be returning the correct unresolved composite objects > not dummy ones if it can even before resolve is run. I've fixed the > code to do that now. > > As a side comment i've noticed that at line 180 in > > org.apache.tuscany.sca.contribution.processor.impl.ContributionContentProcessor > it has code and a comment which says "If no sca-contribution.xml file > was provided then just consider all composites in the contribution as > deployables". That seems wrong to me, does anyone know why it does > that? > > ...ant > > On Fri, Aug 6, 2010 at 4:54 PM, Raymond Feng <[email protected]> wrote: > > 1) We already have a method in the Deployer to handle the "resolve": > > org.apache.tuscany.sca.deployment.Deployer.resolve(Contribution, > > List<Contribution>, Monitor) > > 2) The "resolve" shouldn't be done in the loadContribution() as an > artifact > > can reference other ones from other contributions via import/export, > > including the deployable composites. > > 3) We shouldn't use DeployerImpl directly, instead, you can do: > > > registry.getExtensionPoint(UtilityExtensionPoint.class).getUtility(Deployer.class); > > Thanks, > > Raymond > > ________________________________________________________________ > > Raymond Feng > > [email protected] > > Apache Tuscany PMC member and committer: tuscany.apache.org > > Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com > > Personal Web Site: www.enjoyjava.com > > ________________________________________________________________ > > On Aug 6, 2010, at 2:22 AM, ant elder wrote: > > > > On Fri, Aug 6, 2010 at 4:39 AM, Yang Lei <[email protected]> wrote: > > > > The test logic is added into sample-contribution-binding-sca-calculator's > > > > CalculatorTestCase, so it is using the same contribution definition of > that > > > > sample. > > > > Looking at the directory where the location is used to > loadContribution, I > > > > see sca-contribution.xml under META-INF and composite file under root. > > > > I used the same location to bootstrap the contribution using Node > interface, > > > > which it works. > > > > Contribution[] contributions = > > > > new Contribution[1]; > > > > location = > > > > > ContributionLocationHelper.getContributionLocation("Calculator.composite"); > > > > contributions[0] = > > > > new Contribution("CalculatorTestCase", location); > > > > node = factory.createNode("Calculator.composite",contributions); > > > > node.start(); > > > > SCAClientFactory scaClientFactory = > SCAClientFactory.newInstance(URI.create( > > > > "default")); > > > > calculatorService = scaClientFactory.getService(CalculatorService.class, > > > > "CalculatorServiceComponent"); > > > > System. > > > > out.println("3 - 2 = " + calculatorService.subtract(3, 2)); > > > > Yang. > > > > Whats going on is that the Composite objects that get returned from > > contribution.getDeployables() are not the same instances as the > > Composite objects that are built from the contribution artifacts. > > Thats because when the sca-contribution.xml is read the processor just > > fluffs up a new CompositeImpl object to hold the deployable composite > > QName and its not till the resolve phase when that gets replaced with > > the correct CompositeImpl object for the contribution artifact which > > has all the components. But the resolve phase doesn't run during > > deployer.loadContribution(). > > > > Adding the following code to your test does show all the components: > > > > for (Artifact a : contribution.getArtifacts()) { > > if (a.getModel() instanceof Composite) { > > for (Component c: > ((Composite)a.getModel()).getComponents()) > > System.out.println(c.getName()); > > } > > } > > > > I think the current code does have the opportunity to fix up the > > deployable composite objects during the read phase so if we think this > > is a bug that warrants fixing the a little code added at line 194 of > > > org.apache.tuscany.sca.contribution.processor.impl.ContributionContentProcessor > > could replace the fluffed up deployable Composite objects with the > > correct Composite objects from the contribution artifact. > > > > ...ant > > > > >
