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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
