Hi Raymond... thanks.
Please see my understanding of this or more questions :) inline.
In all of what you have mentioned I am not clear on the things that you'd
like me to do. Please let me know.
Thanks again.
- Venkat.
On 9/26/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Venkata.
Please see my comments below.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, September 25, 2006 2:52 AM
Subject: Re: Queries related to Component Property Loading
> Hi Jeremy, Raymond,
>
> Hi Jeremy / Raymond,
>
> - Here is what I propose to do w.r.t. Component Properties
>
> 1) I have added a new attribute called 'override' to capture the
override
> options and have defined three constants 'must', 'may', 'no' that can
> be
> set
> to this attribute. I have done away with the attribute called
'required'
"required" seems to be from the java @Property annotation. How is it
related
to "override"?
But isn't the purpose of this just about the same as the 'overideOptions'.
i.e. if 'required' stands to denote if a property 'requires' to be defined
or not, then isnt' it the same as stating the 'overideOptions=must'. If
this is the case then maybe we must change the annotation too. Or do the
annotations serve some other purpose which I am missing out?
> 2) In the component loader, during the property loading phase...
> - PropertyValue objects will be created only if the corresponding
> Property's
> 'override' attribute is either 'may' or 'must'. It it is 'no', an
> exception
> will be thrown.
Yes.
> - After all properties defined in the scdl have been loaded, the list
> of
> properties in the component type will be checked to see if there is any
> property who 'override' attribute is 'must' and is not defined as part
of
> the component defn. If there exists one then an exception is thrown
I think this validation step can only be done at "build" phase, right?
From what I can understand, we will be able to do this in loading phase
itself. There are two things required to do this validation 1) the set of
properties defined in the componentType for an implementation 2) the set
of
properties defined in the component definition that uses this
implementation
(in a scdl). Both of these are available during the loading phase and
hence
this validation can be done there.
But then if there is a possibility of builders adding in properties to a
component defn., then yes.. this validation has to be during building.
This
would mean that for properties not defined in the scdl defaults could come
from the compontType defn or from the builder. Is this a possibility?
- I understand that the value of component properties will also be
defined
> as xml similar to how the default values are defined in the component
type
> file i.e. property values will also be xml document fragments
The current code doesn't handle the property value correctly. The SCA
spec
defines the following syntax:
<property name="xs:NCName" source="xs:string"? file="xs:anyURI"?>*
property-value
</property>
The spec takes the order as "source", "file" and content-value.
The property value will represented by a DOM Document which can be
evaluated
against the composite property by XPath, loaded from the file URI, or
parsed
from the current StAX reader. Can the XPath evaluation be done at "load"
phase? I have the code for the XPath part.
I am doubtful about this because when a comp. defn. is being loaded there
is
no guarantee that all of the parent composite's properties are completely
loaded. So there is a possibility that the XPath is referring a property
that is yet to be loaded.
IMHO, we could probably start with supporting property values embeded as
XML
elements within the component defn. and get the rest of the stuff working
after which we can add the two more cases of reading values thro xpath and
file. Because more than supporting loading from diff. sources I want to
complete what we do with the loaded property values and how we transform
them. What do you say?
- Each property has an xml type specified, but where do we locate the
> xsd for this type?
Maybe we can start with "xsi:schemaLocation". By the spec, the "type" is
required. Should we add an attribute to @Property for xmlType? For simple
types, we can use Java2XML mapping in SimpleTypeMapperExtension.
Where will "xsi:schemaLocation" will be defined - as an attribute of the
'ComponentType' element or as an attirbute of the 'Composite' element or
as
an attribute in 'Property' element? And then there must be an attribute
for
"xsi:schemaLocation" in @Property too .. right?
xmlType in @Property will be required if we are loading componenttype info
thro introspection only and when the side file is not available.
I assume that the Java2XML mapping that you mention here is going to be a
part of the Databinding-based property factory you have created (as
mentioned in the next para by you). Have you committed this factory - can
I
take a look? What about mapping the 'not simple' types. Is it something
that this factory is going to handle?
The current code uses "StAXPropertyFactory" to create the target property
value (for simple types). I have created a Databinding-based property
factory which knows how to create the value out of the DOM Document.
> - The property value as an xml document will be passed to the
> ComponentBuilders (js component builder, ruby component builder...)
which
> will handle the logic of transforming them into data forms that can be
> injected into the implementations (javascript, rubyscript...).
I'm thinking of adding the following "build" logic to
ComponentBuilderExtension.
For each property in the component type, we either use the default value
(override="no" or override="may" but no property value is found), or the
configured value from the property value (override="must" or
override="may"
and a matching property is found) to create an instance of ObjectFactory
which knows how to transform the DOM Node into the target type using our
DataBinding support).
'transforming the DOM Node into the target type' - is what I am lost about
currently. Getting around the rest is pretty clear to me. Do you mean
you
will transform the DOM to an appropriate target java type even the target
type is nowhere specified?
The JavaComponentBuilder will inject the property values into the target
POJO instance. Other component builders may have their own way to pass
properties to their implementations.
Yes this is ok to do when the property values have arrived in the right
types they can be injected into the implementaiton instance.
> Am I on track with this?
>
> Thanks
>
> - Venkat
>
> On 9/20/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>>
>> Hi Raymond,
>>
>> I will be out of town tomorrow on some pressing personal work and will
be
>> back on Friday. When I am back I will set on to this with lots of
>> help
>> from
>> you ;-). Thanks.
>>
>> - Venkat
>>
>> On 9/19/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>> >
>> > Couple of comments inline - I'll leave other areas to Raymond.
>> >
>> > On Sep 19, 2006, at 10:54 AM, Venkata Krishnan wrote:
>> >
>> > > 1) I find that the DefaultValue in the class Property is supposed
>> > > to be
>> > > present as a Document instance.
>> >
>> > > //Added by Venkat for this mail : should the following line
>> > > be added
>> > > to fix this problem.
>> > > doc.appendChild(root);
>> >
>> > > Is this a right fix? Otherwise what am I missing here?
>> >
>> > Seems reasonable.
>> >
>> > >
>> > > 2) Assuming the DefaultValue is available in its Document form in
the
>> > > implementation (say javascript or ruby container impl), I would
>> > > need to
>> > > convert it to Java Object and from it to data that javascript /
>> > > ruby can
>> > > understand. I imagine that I must be using the DataBinding
>> > > framework /
>> > > service here for this conversion. How will this be made available
>> > > to the
>> > > implementation - as a autowired service or just as framework whos
>> > > classes I
>> > > must instantiate and use appropriately? Is there a transformer in
>> > > the
>> > > databinding framework to convert between Document to Java
>> > > (something like
>> > > OMElement2Java or Java2OMElement) ?
>> >
>> > I would think the builder would autowire to the framework somehow.
>> > Raymond, any details?
>> >
>> > >
>> > > 3) In the ComponentLoader where PropertyValue instances are
>> > > created
>> > > (as a
>> > > result of property specification in the component defn) why can't
>> > > it be that
>> > > 'PropertyValue' instances are first created for all 'Property'
>> > > instances as
>> > > found in the componentType. Then the values are set either to
>> > > whatever is
>> > > specified for value in the component definition or to whatever is
>> > > available
>> > > in 'DefaultValue' attribute of the Property class. So, when the
>> > > component
>> > > builders are called, the component defn. instances that are passed
>> > > will be
>> > > already populated with property values. Is this thinking right?
>> >
>> > I was thinking the builder would just look for the PropertyValue
>> > first and then if nothing was specified go to the default. That
>> > avoids copying the values, and allows for the case where the value
>> > is
>> > totally undefined ( e.g. optional with no default).
>> >
>> > > Again over
>> > > here, to convert the values specified in the component defns. I
>> > > guess we
>> > > should employ the databinding framework - right?
>> >
>> > Yes.
>> >
>> > >
>> > > 4) In the current implementation of ComponentLoader, while create
>> > > a
>> > > PropertyValue the 'JavaType' attribute of the property seems to be
>> > > required
>> > > so that the right object factories can be created. However this
>> > > JavaType
>> > > attribute is never set and this results in a NPE. I guess if the
>> > > databinding framework is going to be used here to convert Document
>> > > data to
>> > > java objects this problem would be resolved - is this right?
>> >
>> > The ComponentLoader still needs to be converted to using the DOM
>> > form
>> > and have all the xpath stuff added. I think this is just a bug that
>> > should go away when these changes are made. I don't think anyone is
>> > working on that.
>> >
>> > >
>> > > 5) Finally (if you have managed to bear with me until this
>> > > point :)), why is
>> > > it that I must deal with an object factory to get a property
>> > > value. Can I
>> > > not be allowed to simply access it as ' propertyValue.getValue()'.
>> > > Now it
>> > > seems like I must do a propertyValue.getValueFactory().getInstance
>> > > () to get
>> > > the value of a property. Why?
>> >
>> > Because the value may need to be injected multiple times which may
>> > involve creating different instances of it to avoid aliasing bugs.
>> >
>> > --
>> > Jeremy
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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]
