You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Yang Lei <yl...@gmail.com> on 2010/08/06 00:10:51 UTC
How to use Deployer
I was trying to use Deploper to load contribution and iterate the deployable
composites' contents. The composite returned does not have any components
returned. The only thing loaded is the composite name. I would like to
understand how I should be using Deployer to get the composite with the
right content.
Thanks for advise.
The following method is added in
sample-contribution-binding-sca-calculator's CalculatorTestCase
*public* *void* testDeployer() *throws* Exception{
ExtensionPointRegistry registry = *new* DefaultExtensionPointRegistry();
Deployer deployer = *new* DeployerImpl(registry);
deployer.start();
Monitor monitor = (Monitor)deployer.createMonitor();
org.apache.tuscany.sca.contribution.Contribution contribution =
deployer.loadContribution( *new* URI("ABC"),*new* URL(location), monitor);
Composite composite = contribution.getDeployables().get(0);
System.*out*.println("Compsite Name:"+composite);
*for* (Component c: composite.getComponents())
System.*out*.println(c.getName());
}
The output:
Compsite Name:Composite (name={http://sample}Calculator)
--
Thanks. Yang.
Re: How to use Deployer
Posted by Yang Lei <yl...@gmail.com>.
Thanks Ant,
I gave it a try and it works.
About if we fix this or not. As the contribution's artifact already resolved
the model, I do not see why we are returnning a dummy model on the
contribution. I wonder what is the purpose to have a dummy composite at
contribution level. Is it because we want to support a scenario that the
contribution artifacts may be resolved lazily (e.g. when calling
getArtifacts) , however we may need to know the composite's name? If that is
the scenario we want to support, maybe we can add an attribute in the
loadContribution method to indicate if we want to resolve the model or
not. And in any cases, I would like to see as soon as the artifact is
resolved in the contribution, the contribution deployable should return
the artifact's model, so we will not have un consistent .
I tried to reload the composite from contribution after retrieving the
artifacts, that composite is still the dummy one.
Yang
Re: How to use Deployer
Posted by ant elder <an...@apache.org>.
On Sat, Aug 7, 2010 at 4:44 AM, Raymond Feng <en...@gmail.com> wrote:
> 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?
>
I think its fine. I'm not sure that having a deployable element to a
composite outside of the contribution is actually valid but even if it
is i think its quite reasonable that the deployables list contains the
actual correct Composite objects be they resolved or unresolved.
...ant
Re: How to use Deployer
Posted by Raymond Feng <en...@gmail.com>.
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 <an...@gmail.com> 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 <en...@gmail.com> 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
> > rfeng@apache.org
> > 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 <yl...@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
> >
> >
>
Re: How to use Deployer
Posted by ant elder <an...@gmail.com>.
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 <en...@gmail.com> 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
> rfeng@apache.org
> 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 <yl...@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
>
>
Re: How to use Deployer
Posted by Raymond Feng <en...@gmail.com>.
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
rfeng@apache.org
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 <yl...@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
Re: How to use Deployer
Posted by ant elder <an...@gmail.com>.
On Fri, Aug 6, 2010 at 4:39 AM, Yang Lei <yl...@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
Re: How to use Deployer
Posted by Yang Lei <yl...@gmail.com>.
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, Isee 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.
Re: How to use Deployer
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Aug 5, 2010 at 3:10 PM, Yang Lei <yl...@gmail.com> wrote:
>
> I was trying to use Deploper to load contribution and iterate the deployable
> composites' contents. The composite returned does not have any components
> returned. The only thing loaded is the composite name. I would like to
> understand how I should be using Deployer to get the composite with the
> right content.
>
> Thanks for advise.
>
>
> The following method is added in
> sample-contribution-binding-sca-calculator's CalculatorTestCase
>
> public void testDeployer() throws Exception{
>
> ExtensionPointRegistry registry =
>
> new DefaultExtensionPointRegistry();
>
> Deployer deployer =
>
> new DeployerImpl(registry);
>
> deployer.start();
>
> Monitor monitor = (Monitor)deployer.createMonitor();
>
> org.apache.tuscany.sca.contribution.Contribution contribution =
> deployer.loadContribution( new URI("ABC"),new URL(location), monitor);
>
> Composite composite = contribution.getDeployables().get(0);
>
> System.
>
> out.println("Compsite Name:"+composite);
>
> for (Component c: composite.getComponents())
>
> System.
>
> out.println(c.getName());
>
> }
>
> The output:
> Compsite Name:Composite (name={http://sample}Calculator)
> --
> Thanks. Yang.
>
How are you defining the deployable ? Do you have a sca-contribution.xml ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/