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
