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/04/15 13:38:59 UTC
Support for Component Properties
Hi,
I have updated the Trunk for some minor changes to bring in support for
properties. I 'property' iTest is also back fully functional. With this
check it should be possible to have components configured with simple and
complex properties either single valued or many valued. The 'source' and
'file' options are also working from what I tested with the iTest. An
assumption about simple type many values is that if there are many values of
a simple type then they are all provided with spaces separating each value.
For Strings, each string needs to be enclosed within a double quote.
Examples of a many valued 'float' type property and 'string' type property
are...
<property name="manyProp1" many="true">
12.34 56.78 90.12 34.56
</property>
<property name="manyProp2" many="true">
"Apache" "Tuscany" "Java" "SCA"
</property>
The current support for properties does not work for Components whose
implementation is a Composite. There are some issues that I see with doing
this which I'll start in a new thread.
At the present moment I have included the 'databinding' module as a
dependency into the implementation-java-runtime. I have created the
DBRegistry, the Transformation Registry and have explicitly registered the
DOM2JavaBeansTransformer. I have left out the other transformers as I guess
this is going to change with these registries being accessible from the
extentions point registry. When I figure that out, it would probably bring
in the whole suite of transformers.
With this implementation I also have a few observations over which I request
comments: -
- With respect to the attribute 'many' it is 'false' by default and is also
optional. Meaning if a property definition does not mentioned this
attribute then it is taken as 'false'. Given this, if a componentType has a
property that has many='true' then the component that uses this
componentType MUST state many='true' if it also wished to have the property
as many valued. If the component does not mention this attribute, then the
'many' attribute assumes its default value which is 'false' and prevents the
use of many values in the property definition. This could quite be a
surprise if the 'many' attribute is left out of the Component with the
assumption that it will inherit whatever is defined in the underlying
componentType. So in a nutshell, if many values are going to be used then
the Property Defn. in the Component MUST specify many='true' - is this ok ?
- PropertyValues can also be loaded from a file by mentioning the location
of the file in the 'file' attribute. What is the classloader to be used
when loading this file? Must the ContributionService be used? At the
present moment I am using TCCL.
- When a property has 'source' and 'file' defined, the specs says that
'source' takes precedence over file. Now what if 'source' is provided and
also a value is provided. Which takes precedence? Right now the 'source'
is taking precedence.
Thanks for reading upto this point :)
- Venkat
Re: Support for Component Properties
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Hi,
>
> I have updated the Trunk for some minor changes to bring in support for
> properties. I 'property' iTest is also back fully functional.
Great! I added the properties itest to the main build.
> With this
> check it should be possible to have components configured with simple and
> complex properties either single valued or many valued. The 'source' and
> 'file' options are also working from what I tested with the iTest. An
> assumption about simple type many values is that if there are many
> values of
> a simple type then they are all provided with spaces separating each
> value.
> For Strings, each string needs to be enclosed within a double quote.
> Examples of a many valued 'float' type property and 'string' type
> property
> are...
>
> <property name="manyProp1" many="true">
> 12.34 56.78 90.12 34.56
> </property>
> <property name="manyProp2" many="true">
> "Apache" "Tuscany" "Java" "SCA"
> </property>
>
Nice. Do you know if that is going to be added to the spec? I could not
find in the assembly spec any description of how to configure multiple
simple type values (or maybe I missed it).
> The current support for properties does not work for Components whose
> implementation is a Composite. There are some issues that I see with
> doing
> this which I'll start in a new thread.
>
> At the present moment I have included the 'databinding' module as a
> dependency into the implementation-java-runtime. I have created the
> DBRegistry, the Transformation Registry and have explicitly registered
> the
> DOM2JavaBeansTransformer. I have left out the other transformers as I
> guess
> this is going to change with these registries being accessible from the
> extentions point registry. When I figure that out, it would probably
> bring
> in the whole suite of transformers.
I think that's fine for a starting point. You're right, at some point
we'll need to use the extension point mechanism to use the other
databindings as well.
>
> With this implementation I also have a few observations over which I
> request
> comments: -
> - With respect to the attribute 'many' it is 'false' by default and is
> also
> optional. Meaning if a property definition does not mentioned this
> attribute then it is taken as 'false'. Given this, if a componentType
> has a
> property that has many='true' then the component that uses this
> componentType MUST state many='true' if it also wished to have the
> property
> as many valued. If the component does not mention this attribute, then
> the
> 'many' attribute assumes its default value which is 'false' and
> prevents the
> use of many values in the property definition. This could quite be a
> surprise if the 'many' attribute is left out of the Component with the
> assumption that it will inherit whatever is defined in the underlying
> componentType. So in a nutshell, if many values are going to be used then
> the Property Defn. in the Component MUST specify many='true' - is this
> ok ?
>
Here's the text of the spec for componentType property:
many (optional) - whether the property is single-valued (false) or
multi-valued (true). The default is false.
and here's the text for component property:
many (optional) – (optional) whether the property is single-valued
(false) or multi-valued (true). Overrides the many specified for this
property on the implementation. The value can only be equal or further
restrict, i.e. if the implementation specifies many true, then the
component can say false.
I think that you've uncovered a bug in the spec, as it does not clearly
say which value applies when you don't specify the "many" attribute on a
component property. IMO the spec should say that if you don't specify
the "many" attribute on a a component property, then the "many"
attribute specified from the componentType property applies. I think it
was the intention (as this rule generally applies to all configuration
aspects of a component vs its componentType) but the spec should clarify it.
> - PropertyValues can also be loaded from a file by mentioning the
> location
> of the file in the 'file' attribute. What is the classloader to be used
> when loading this file? Must the ContributionService be used? At the
> present moment I am using TCCL.
Using the TCCL is fine for now, but yes I think that the Contribution
service should be used here. We should be able to resolve the referenced
file in the ArtifactProcessor.resolve() method when property
configuration is processed and the assembly model is populated. For
this, the Contribution service should register files in the
ArtifactResolver (or have the DefaultArtifactResolver implementation
find them in the current contribution).
>
> - When a property has 'source' and 'file' defined, the specs says that
> 'source' takes precedence over file. Now what if 'source' is provided and
> also a value is provided. Which takes precedence? Right now the 'source'
> is taking precedence.
I don't know :) we'll have to check with the assembly spec...
>
> Thanks for reading upto this point :)
>
> - Venkat
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for Component Properties
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Raymond Feng wrote:
> Hi,
>
> I found out it's too limited if we hard-code the DataBindingRegistry
> and DOM2JavaBean transformer as the only type of complex property that
> can be supported will be only java beans.
>
> I fixed the code to support property in any databindings under
> r529006. With this change, the OMElement property in the
> echo-databinding sample is working.
>
> Please let me know if other itests are not happy with this.
>
> Thanks,
> Raymond
>
All tests are now passing, I just needed to add a dependency on
tuscany-core-databinding to the bigbank sample and properties itest. I'm
wondering if host-embedded should actually have this dependency with
<scope>runtime</scope> to bring it transitively to all samples and
integration tests that will potentially use SCA properties.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for Component Properties
Posted by scabooz <sc...@gmail.com>.
Hi guys,
Just saw this....WRT multi-valued string properties, there is an errata item
for this against the v1.0 spec. I think the solution looked like this:
<property name="manyProp2" many="true">
<value>Apache</value>
<value>Tuscany</value>
<value>Java</value>
<value>SCA</value>
</property>
But I can't find the details right now. For now, I suggest you
wait until OSOA publishes the errata, rather than relying on my memory.
Dave
----- Original Message -----
From: "Raymond Feng" <en...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Sunday, April 15, 2007 12:52 PM
Subject: Re: Support for Component Properties
> Hi,
>
> I found out it's too limited if we hard-code the DataBindingRegistry and
> DOM2JavaBean transformer as the only type of complex property that can be
> supported will be only java beans.
>
> I fixed the code to support property in any databindings under r529006.
> With this change, the OMElement property in the echo-databinding sample is
> working.
>
> Please let me know if other itests are not happy with this.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Venkata Krishnan" <fo...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Sunday, April 15, 2007 4:38 AM
> Subject: Support for Component Properties
>
>
>> Hi,
>>
>> I have updated the Trunk for some minor changes to bring in support for
>> properties. I 'property' iTest is also back fully functional. With this
>> check it should be possible to have components configured with simple and
>> complex properties either single valued or many valued. The 'source' and
>> 'file' options are also working from what I tested with the iTest. An
>> assumption about simple type many values is that if there are many values
>> of
>> a simple type then they are all provided with spaces separating each
>> value.
>> For Strings, each string needs to be enclosed within a double quote.
>> Examples of a many valued 'float' type property and 'string' type
>> property
>> are...
>>
>> <property name="manyProp1" many="true">
>> 12.34 56.78 90.12 34.56
>> </property>
>> <property name="manyProp2" many="true">
>> "Apache" "Tuscany" "Java" "SCA"
>> </property>
>>
>> The current support for properties does not work for Components whose
>> implementation is a Composite. There are some issues that I see with
>> doing
>> this which I'll start in a new thread.
>>
>> At the present moment I have included the 'databinding' module as a
>> dependency into the implementation-java-runtime. I have created the
>> DBRegistry, the Transformation Registry and have explicitly registered
>> the
>> DOM2JavaBeansTransformer. I have left out the other transformers as I
>> guess
>> this is going to change with these registries being accessible from the
>> extentions point registry. When I figure that out, it would probably
>> bring
>> in the whole suite of transformers.
>>
>> With this implementation I also have a few observations over which I
>> request
>> comments: -
>> - With respect to the attribute 'many' it is 'false' by default and is
>> also
>> optional. Meaning if a property definition does not mentioned this
>> attribute then it is taken as 'false'. Given this, if a componentType
>> has a
>> property that has many='true' then the component that uses this
>> componentType MUST state many='true' if it also wished to have the
>> property
>> as many valued. If the component does not mention this attribute, then
>> the
>> 'many' attribute assumes its default value which is 'false' and prevents
>> the
>> use of many values in the property definition. This could quite be a
>> surprise if the 'many' attribute is left out of the Component with the
>> assumption that it will inherit whatever is defined in the underlying
>> componentType. So in a nutshell, if many values are going to be used
>> then
>> the Property Defn. in the Component MUST specify many='true' - is this ok
>> ?
>>
>> - PropertyValues can also be loaded from a file by mentioning the
>> location
>> of the file in the 'file' attribute. What is the classloader to be used
>> when loading this file? Must the ContributionService be used? At the
>> present moment I am using TCCL.
>>
>> - When a property has 'source' and 'file' defined, the specs says that
>> 'source' takes precedence over file. Now what if 'source' is provided
>> and
>> also a value is provided. Which takes precedence? Right now the
>> 'source'
>> is taking precedence.
>>
>> Thanks for reading upto this point :)
>>
>> - Venkat
>>
>
>
> ---------------------------------------------------------------------
> 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: Support for Component Properties
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I found out it's too limited if we hard-code the DataBindingRegistry and
DOM2JavaBean transformer as the only type of complex property that can be
supported will be only java beans.
I fixed the code to support property in any databindings under r529006. With
this change, the OMElement property in the echo-databinding sample is
working.
Please let me know if other itests are not happy with this.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Sunday, April 15, 2007 4:38 AM
Subject: Support for Component Properties
> Hi,
>
> I have updated the Trunk for some minor changes to bring in support for
> properties. I 'property' iTest is also back fully functional. With this
> check it should be possible to have components configured with simple and
> complex properties either single valued or many valued. The 'source' and
> 'file' options are also working from what I tested with the iTest. An
> assumption about simple type many values is that if there are many values
> of
> a simple type then they are all provided with spaces separating each
> value.
> For Strings, each string needs to be enclosed within a double quote.
> Examples of a many valued 'float' type property and 'string' type
> property
> are...
>
> <property name="manyProp1" many="true">
> 12.34 56.78 90.12 34.56
> </property>
> <property name="manyProp2" many="true">
> "Apache" "Tuscany" "Java" "SCA"
> </property>
>
> The current support for properties does not work for Components whose
> implementation is a Composite. There are some issues that I see with
> doing
> this which I'll start in a new thread.
>
> At the present moment I have included the 'databinding' module as a
> dependency into the implementation-java-runtime. I have created the
> DBRegistry, the Transformation Registry and have explicitly registered the
> DOM2JavaBeansTransformer. I have left out the other transformers as I
> guess
> this is going to change with these registries being accessible from the
> extentions point registry. When I figure that out, it would probably
> bring
> in the whole suite of transformers.
>
> With this implementation I also have a few observations over which I
> request
> comments: -
> - With respect to the attribute 'many' it is 'false' by default and is
> also
> optional. Meaning if a property definition does not mentioned this
> attribute then it is taken as 'false'. Given this, if a componentType has
> a
> property that has many='true' then the component that uses this
> componentType MUST state many='true' if it also wished to have the
> property
> as many valued. If the component does not mention this attribute, then
> the
> 'many' attribute assumes its default value which is 'false' and prevents
> the
> use of many values in the property definition. This could quite be a
> surprise if the 'many' attribute is left out of the Component with the
> assumption that it will inherit whatever is defined in the underlying
> componentType. So in a nutshell, if many values are going to be used then
> the Property Defn. in the Component MUST specify many='true' - is this ok
> ?
>
> - PropertyValues can also be loaded from a file by mentioning the location
> of the file in the 'file' attribute. What is the classloader to be used
> when loading this file? Must the ContributionService be used? At the
> present moment I am using TCCL.
>
> - When a property has 'source' and 'file' defined, the specs says that
> 'source' takes precedence over file. Now what if 'source' is provided and
> also a value is provided. Which takes precedence? Right now the 'source'
> is taking precedence.
>
> Thanks for reading upto this point :)
>
> - Venkat
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org