On Fri, Aug 6, 2010 at 4:39 AM, Yang Lei <yl.yangle...@gmail.com> 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
