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" <[EMAIL PROTECTED]>
To: <[email protected]>
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" <[EMAIL PROTECTED]>
To: <[email protected]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
