You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2007/05/29 19:11:18 UTC
Component Property Definition - resolving 'file' attribute
Hi,
The property value definition for a component can have an attribute named
'file' that points to a xml file that might contain the value for a
property. The question is - now that the contribution service is in shape
must it be used to resolve this file as well just like all other artifacts.
If so could somebody please provide some pointers on how to do this. Thanks
- Venkat
Re: Component Property Definition - resolving 'file' attribute
Posted by scabooz <sc...@gmail.com>.
Venkat,
Sebastien is correct, the spec has a hole here, so let's try to
fill in the hole to see what works, and then feed it back to
the spec community. I would have opted for "relative to the
contribution". If the URI is absolute, then it should be treated
as absolute. IMHO, this is not very useful, but maybe someone
can come up with a use case for it.
This gives the developer the freedom to name and package
the XML file anywhere they want so that it can be referenced
from multiple component definitions in the contribution.
Other opinions?
Dave
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, May 29, 2007 6:45 PM
Subject: Re: Component Property Definition - resolving 'file' attribute
> Venkata Krishnan wrote:
>> Hi,
>>
>> The property value definition for a component can have an attribute named
>> 'file' that points to a xml file that might contain the value for a
>> property. The question is - now that the contribution service is in shape
>> must it be used to resolve this file as well just like all other
>> artifacts.
>> If so could somebody please provide some pointers on how to do this.
>> Thanks
>>
>> - Venkat
>>
>
> I think it would be a good idea to use it, this would require a simple
> change to our ArtifactResolver implementation to support something like a
> FileReference object, similar to what we've done for classes with
> ClassReference, but we probably also need to confirm what the SCA assembly
> spec actually means by:
> <<<
> 287 - file (optional) – a dereferencable URI to a file containing a value
> for the property
> >>>
>
> In particular:
> - foo/bar.xml - is foo/bar.xml relative to the current SCA contribution?
> or the referencing composite file?
> - /foo/bar.xml - is /foo/bar relative to my hard drive? or the current SCA
> contribution?
> - http://foo.org/bar - is this allowed?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component Property Definition - resolving 'file' attribute
Posted by Venkata Krishnan <fo...@gmail.com>.
Thanks Sebastien. Will go ahead and check in the changes now.
- Venkat
On 7/31/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Jean-Sebastien Delfino wrote:
> > Venkata Krishnan wrote:
> >> Luciano, you are right... here is the code snippet that I have added
> >> to the CompositeProcessor.resolve()
> >>
> >> for (ComponentProperty componentProperty : component.getProperties()) {
> >> if ( componentProperty.getFile() != null &&
> >> componentProperty.getFile().length() > 0 ) {
> >> DeployedArtifact deployedArtifact =
> >> contributionFactory.createDeployedArtifact();
> >>
> >> deployedArtifact.setURI(componentProperty.getFile());
> >> deployedArtifact =
> >> resolver.resolveModel(DeployedArtifact.class, deployedArtifact);
> >> if ( deployedArtifact.getLocation() != null &&
> >> deployedArtifact.getLocation().length() > 0 ) {
> >>
> >> componentProperty.setFile(deployedArtifact.getLocation());
> >> }
> >> }
> >> }
> >>
> >>
> >> Thanks
> >>
> >> - Venkat
> >>
> >>
> >>
> >
> > OK, I understand better now :) What you're proposing looks fine to me.
> > CompositeProcessor already depends on ArtifactProcessor, ModelResolver
> > etc. which are all from the contribution module. So passing a pointer
> > to ContributionFactory to it does not alter any layering.
> >
>
> One minor comment, I'd suggest to remove the:
> && componentProperty.getFile().length() > 0, as it'll mask a syntax
> error in the .composite file
> and
> && deployedArtifact.getLocation().length() > 0, as it'll mask a serious
> error in the contribution service
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component Property Definition - resolving 'file' attribute
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Venkata Krishnan wrote:
>> Luciano, you are right... here is the code snippet that I have added
>> to the CompositeProcessor.resolve()
>>
>> for (ComponentProperty componentProperty : component.getProperties()) {
>> if ( componentProperty.getFile() != null &&
>> componentProperty.getFile().length() > 0 ) {
>> DeployedArtifact deployedArtifact =
>> contributionFactory.createDeployedArtifact();
>>
>> deployedArtifact.setURI(componentProperty.getFile());
>> deployedArtifact =
>> resolver.resolveModel(DeployedArtifact.class, deployedArtifact);
>> if ( deployedArtifact.getLocation() != null &&
>> deployedArtifact.getLocation().length() > 0 ) {
>>
>> componentProperty.setFile(deployedArtifact.getLocation());
>> }
>> }
>> }
>>
>>
>> Thanks
>>
>> - Venkat
>>
>>
>>
>
> OK, I understand better now :) What you're proposing looks fine to me.
> CompositeProcessor already depends on ArtifactProcessor, ModelResolver
> etc. which are all from the contribution module. So passing a pointer
> to ContributionFactory to it does not alter any layering.
>
One minor comment, I'd suggest to remove the:
&& componentProperty.getFile().length() > 0, as it'll mask a syntax
error in the .composite file
and
&& deployedArtifact.getLocation().length() > 0, as it'll mask a serious
error in the contribution service
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component Property Definition - resolving 'file' attribute
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Luciano, you are right... here is the code snippet that I have added
> to the CompositeProcessor.resolve()
>
> for (ComponentProperty componentProperty : component.getProperties()) {
> if ( componentProperty.getFile() != null &&
> componentProperty.getFile().length() > 0 ) {
> DeployedArtifact deployedArtifact =
> contributionFactory.createDeployedArtifact();
> deployedArtifact.setURI(componentProperty.getFile());
> deployedArtifact =
> resolver.resolveModel(DeployedArtifact.class, deployedArtifact);
> if ( deployedArtifact.getLocation() != null &&
> deployedArtifact.getLocation().length() > 0 ) {
>
> componentProperty.setFile(deployedArtifact.getLocation());
> }
> }
> }
>
>
> Thanks
>
> - Venkat
>
>
>
OK, I understand better now :) What you're proposing looks fine to me.
CompositeProcessor already depends on ArtifactProcessor, ModelResolver
etc. which are all from the contribution module. So passing a pointer to
ContributionFactory to it does not alter any layering.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component Property Definition - resolving 'file' attribute
Posted by Venkata Krishnan <fo...@gmail.com>.
Luciano, you are right... here is the code snippet that I have added
to the CompositeProcessor.resolve()
for (ComponentProperty componentProperty : component.getProperties()) {
if ( componentProperty.getFile() != null &&
componentProperty.getFile().length() > 0 ) {
DeployedArtifact deployedArtifact =
contributionFactory.createDeployedArtifact();
deployedArtifact.setURI(componentProperty.getFile());
deployedArtifact =
resolver.resolveModel(DeployedArtifact.class, deployedArtifact);
if ( deployedArtifact.getLocation() != null &&
deployedArtifact.getLocation().length() > 0 ) {
componentProperty.setFile(deployedArtifact.getLocation());
}
}
}
Thanks
- Venkat
On 7/30/07, Luciano Resende <lu...@gmail.com> wrote:
> I guess Venkata is trying to create the deployedArtifact to resolve...
>
> >To resolve an artifact, you simple need to create a DeployedArtifact -
> >see ContributionFactory.createDeployedArtifact() -, set it's URI to the
> >URI of the artifact inside the SCA contribution, then call
> >ModelResolver.resolve(theDeployedArtifact).
>
> But I'll wait to see the code.
>
> On 7/30/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > Venkata Krishnan wrote:
> > > Hi Sebastien / Luciano,
> > >
> > > I have this going in my local. But I've had to pass the
> > > ContributionFactory down to the CompositeProcessor thus adding one
> > > more argument to the CompositeProcessor contructor. Is there any
> > > violation of layering in our design with this passing? Just want to
> > > check this up before I commit the changes.
> > >
> > > Thanks
> > >
> > > - Venkat
> > >
> > >
> >
> > I'm not quite sure I understand the relationship between
> > ContributionFactory and resolution of a file. Could you post the code
> > somewhere? It'll help me understand. Thanks.
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component Property Definition - resolving 'file' attribute
Posted by Luciano Resende <lu...@gmail.com>.
I guess Venkata is trying to create the deployedArtifact to resolve...
>To resolve an artifact, you simple need to create a DeployedArtifact -
>see ContributionFactory.createDeployedArtifact() -, set it's URI to the
>URI of the artifact inside the SCA contribution, then call
>ModelResolver.resolve(theDeployedArtifact).
But I'll wait to see the code.
On 7/30/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Venkata Krishnan wrote:
> > Hi Sebastien / Luciano,
> >
> > I have this going in my local. But I've had to pass the
> > ContributionFactory down to the CompositeProcessor thus adding one
> > more argument to the CompositeProcessor contructor. Is there any
> > violation of layering in our design with this passing? Just want to
> > check this up before I commit the changes.
> >
> > Thanks
> >
> > - Venkat
> >
> >
>
> I'm not quite sure I understand the relationship between
> ContributionFactory and resolution of a file. Could you post the code
> somewhere? It'll help me understand. Thanks.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component Property Definition - resolving 'file' attribute
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Hi Sebastien / Luciano,
>
> I have this going in my local. But I've had to pass the
> ContributionFactory down to the CompositeProcessor thus adding one
> more argument to the CompositeProcessor contructor. Is there any
> violation of layering in our design with this passing? Just want to
> check this up before I commit the changes.
>
> Thanks
>
> - Venkat
>
>
I'm not quite sure I understand the relationship between
ContributionFactory and resolution of a file. Could you post the code
somewhere? It'll help me understand. Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component Property Definition - resolving 'file' attribute
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien / Luciano,
I have this going in my local. But I've had to pass the
ContributionFactory down to the CompositeProcessor thus adding one
more argument to the CompositeProcessor contructor. Is there any
violation of layering in our design with this passing? Just want to
check this up before I commit the changes.
Thanks
- Venkat
On 6/22/07, Venkata Krishnan <fo...@gmail.com> wrote:
> Thanks Sebastien. I'll try to use this now and see how things go.
>
> - Venkat
>
>
> On 6/19/07, Jean-Sebastien Delfino < jsdelfino@apache.org> wrote:
> > Luciano Resende wrote:
> > > Would we also need to post process the contribution to check for
> > > unresolved references ? I'm guessing that, file references outside
> > > from the contribution scope will always be on the unresolved status
> > > ,and would need further processing.
> > >
> > > On 5/29/07, Jean-Sebastien Delfino < jsdelfino@apache.org> wrote:
> > >> Venkata Krishnan wrote:
> > >> > Hi,
> > >> >
> > >> > The property value definition for a component can have an attribute
> > >> named
> > >> > 'file' that points to a xml file that might contain the value for a
> > >> > property. The question is - now that the contribution service is in
> > >> shape
> > >> > must it be used to resolve this file as well just like all other
> > >> > artifacts.
> > >> > If so could somebody please provide some pointers on how to do this.
> > >> > Thanks
> > >> >
> > >> > - Venkat
> > >> >
> > >>
> > >> I think it would be a good idea to use it, this would require a simple
> > >> change to our ArtifactResolver implementation to support something like
> > >> a FileReference object, similar to what we've done for classes with
> > >> ClassReference, but we probably also need to confirm what the SCA
> > >> assembly spec actually means by:
> > >> <<<
> > >> 287 - file (optional) – a dereferencable URI to a file containing a
> > >> value for the property
> > >> >>>
> > >>
> > >> In particular:
> > >> - foo/bar.xml - is foo/bar.xml relative to the current SCA
> contribution?
> > >> or the referencing composite file?
> > >> - /foo/bar.xml - is /foo/bar relative to my hard drive? or the current
> > >> SCA contribution?
> > >> - http://foo.org/bar - is this allowed?
> > >>
> > >> --
> > >> Jean-Sebastien
> > >>
> > >>
> >
> > In revision r548560 I have added support for resolution of contribution
> > DeployedArtifacts.
> >
> > To resolve an artifact, you simple need to create a DeployedArtifact -
> > see ContributionFactory.createDeployedArtifact() -, set
> it's URI to the
> > URI of the artifact inside the SCA contribution, then call
> > ModelResolver.resolve(theDeployedArtifact). You'll get back the
> > populated/initialized DeployedArtifact, containing its absolute location
> > and the model that was read from it, if any.
> >
> > This can be used to resolve files used to configure properties and
> > implementation files as well.
> >
> > --
> > Jean-Sebastien
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component Property Definition - resolving 'file' attribute
Posted by Venkata Krishnan <fo...@gmail.com>.
Thanks Sebastien. I'll try to use this now and see how things go.
- Venkat
On 6/19/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Luciano Resende wrote:
> > Would we also need to post process the contribution to check for
> > unresolved references ? I'm guessing that, file references outside
> > from the contribution scope will always be on the unresolved status
> > ,and would need further processing.
> >
> > On 5/29/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >> Venkata Krishnan wrote:
> >> > Hi,
> >> >
> >> > The property value definition for a component can have an attribute
> >> named
> >> > 'file' that points to a xml file that might contain the value for a
> >> > property. The question is - now that the contribution service is in
> >> shape
> >> > must it be used to resolve this file as well just like all other
> >> > artifacts.
> >> > If so could somebody please provide some pointers on how to do this.
> >> > Thanks
> >> >
> >> > - Venkat
> >> >
> >>
> >> I think it would be a good idea to use it, this would require a simple
> >> change to our ArtifactResolver implementation to support something like
> >> a FileReference object, similar to what we've done for classes with
> >> ClassReference, but we probably also need to confirm what the SCA
> >> assembly spec actually means by:
> >> <<<
> >> 287 - file (optional) – a dereferencable URI to a file containing a
> >> value for the property
> >> >>>
> >>
> >> In particular:
> >> - foo/bar.xml - is foo/bar.xml relative to the current SCA
> contribution?
> >> or the referencing composite file?
> >> - /foo/bar.xml - is /foo/bar relative to my hard drive? or the current
> >> SCA contribution?
> >> - http://foo.org/bar - is this allowed?
> >>
> >> --
> >> Jean-Sebastien
> >>
> >>
>
> In revision r548560 I have added support for resolution of contribution
> DeployedArtifacts.
>
> To resolve an artifact, you simple need to create a DeployedArtifact -
> see ContributionFactory.createDeployedArtifact() -, set it's URI to the
> URI of the artifact inside the SCA contribution, then call
> ModelResolver.resolve(theDeployedArtifact). You'll get back the
> populated/initialized DeployedArtifact, containing its absolute location
> and the model that was read from it, if any.
>
> This can be used to resolve files used to configure properties and
> implementation files as well.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Component Property Definition - resolving 'file' attribute
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Luciano Resende wrote:
> Would we also need to post process the contribution to check for
> unresolved references ? I'm guessing that, file references outside
> from the contribution scope will always be on the unresolved status
> ,and would need further processing.
>
> On 5/29/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> Venkata Krishnan wrote:
>> > Hi,
>> >
>> > The property value definition for a component can have an attribute
>> named
>> > 'file' that points to a xml file that might contain the value for a
>> > property. The question is - now that the contribution service is in
>> shape
>> > must it be used to resolve this file as well just like all other
>> > artifacts.
>> > If so could somebody please provide some pointers on how to do this.
>> > Thanks
>> >
>> > - Venkat
>> >
>>
>> I think it would be a good idea to use it, this would require a simple
>> change to our ArtifactResolver implementation to support something like
>> a FileReference object, similar to what we've done for classes with
>> ClassReference, but we probably also need to confirm what the SCA
>> assembly spec actually means by:
>> <<<
>> 287 - file (optional) – a dereferencable URI to a file containing a
>> value for the property
>> >>>
>>
>> In particular:
>> - foo/bar.xml - is foo/bar.xml relative to the current SCA contribution?
>> or the referencing composite file?
>> - /foo/bar.xml - is /foo/bar relative to my hard drive? or the current
>> SCA contribution?
>> - http://foo.org/bar - is this allowed?
>>
>> --
>> Jean-Sebastien
>>
>>
In revision r548560 I have added support for resolution of contribution
DeployedArtifacts.
To resolve an artifact, you simple need to create a DeployedArtifact -
see ContributionFactory.createDeployedArtifact() -, set it's URI to the
URI of the artifact inside the SCA contribution, then call
ModelResolver.resolve(theDeployedArtifact). You'll get back the
populated/initialized DeployedArtifact, containing its absolute location
and the model that was read from it, if any.
This can be used to resolve files used to configure properties and
implementation files as well.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component Property Definition - resolving 'file' attribute
Posted by Luciano Resende <lu...@gmail.com>.
Would we also need to post process the contribution to check for
unresolved references ? I'm guessing that, file references outside
from the contribution scope will always be on the unresolved status
,and would need further processing.
On 5/29/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Venkata Krishnan wrote:
> > Hi,
> >
> > The property value definition for a component can have an attribute named
> > 'file' that points to a xml file that might contain the value for a
> > property. The question is - now that the contribution service is in shape
> > must it be used to resolve this file as well just like all other
> > artifacts.
> > If so could somebody please provide some pointers on how to do this.
> > Thanks
> >
> > - Venkat
> >
>
> I think it would be a good idea to use it, this would require a simple
> change to our ArtifactResolver implementation to support something like
> a FileReference object, similar to what we've done for classes with
> ClassReference, but we probably also need to confirm what the SCA
> assembly spec actually means by:
> <<<
> 287 - file (optional) – a dereferencable URI to a file containing a
> value for the property
> >>>
>
> In particular:
> - foo/bar.xml - is foo/bar.xml relative to the current SCA contribution?
> or the referencing composite file?
> - /foo/bar.xml - is /foo/bar relative to my hard drive? or the current
> SCA contribution?
> - http://foo.org/bar - is this allowed?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component Property Definition - resolving 'file' attribute
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Hi,
>
> The property value definition for a component can have an attribute named
> 'file' that points to a xml file that might contain the value for a
> property. The question is - now that the contribution service is in shape
> must it be used to resolve this file as well just like all other
> artifacts.
> If so could somebody please provide some pointers on how to do this.
> Thanks
>
> - Venkat
>
I think it would be a good idea to use it, this would require a simple
change to our ArtifactResolver implementation to support something like
a FileReference object, similar to what we've done for classes with
ClassReference, but we probably also need to confirm what the SCA
assembly spec actually means by:
<<<
287 - file (optional) – a dereferencable URI to a file containing a
value for the property
>>>
In particular:
- foo/bar.xml - is foo/bar.xml relative to the current SCA contribution?
or the referencing composite file?
- /foo/bar.xml - is /foo/bar relative to my hard drive? or the current
SCA contribution?
- http://foo.org/bar - is this allowed?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org