You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myromatours.com> on 2006/07/18 23:12:54 UTC
Data binding extensions and changes to the SCA spec
I would like to get started on support for for XPath in SCDL as it is
part of the recent SCA spec changes. This will likely require
changes to the loader infrastructure and in particular
StringParserPropertyFactory. Instead of having a PropertyFactory
create an ObjectFactory responsible for returning a value that is
injected into a component implementation instance, we will need to
have a more flexible approach as property values may now be based off
of XPath expressions to composite properties.
What I would like to propose is that we have creation of the
ObjectFactory for the property handled by the builder in much the
same way as it handles wires. I think we can leverage the data
transformation service for this. In this case, the builder will be
given a representation of the parsed XML, probably DOM. If the
property value was an XPath expression, the builder will have to use
an XPath engine to evaluate and retrieve this actual value (Jaxen?)
represented as a Node. The builder will then in turn use the
transformation service to create a "bound type". The builder will
subsequently create an ObjectFactory for the bound type responsible
for injecting on the target component implementation instance. The
specific kind of ObjectFactory will depend on the kind of property it
is:
- If it is immutable, the builder will use a SingletonObjectFactory
- If it is mutable, but the property is configured as "safe" (i.e.
the component does not mutate it), the builder will use a
SingletonObjectFactory). We can also assume by default values are
"safe" unless explicitly marked.
- If it is mutable, marked "not safe," and Cloneable, a
CloningObjectFactory is used which clones on getInstance()
-If it is mutable, marked "not safe" and is not Cloneable, the
builder avoids the call to the transformation service and instead
uses an ObjectFactory which calls out the to transformation service
on every getInstance() invoke.
For some implementation types, a builder may not want to use
ObjectFactory (perhaps the implementation just takes a DOM or some
other format). In that case, the builder would be free to use the
transformation service or not.
Raymond, does this sound like it would fit with the transformation
service? If so, I think we need to look at incorporating the base
data transformation framework into SPI and core.
I'd also be willing to work on an XStream binding extension which
would enable handling of basic POJO binding.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data binding extensions and changes to the SCA spec
Posted by Raymond Feng <en...@gmail.com>.
I'll give a try.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, July 18, 2006 7:10 PM
Subject: Re: Data binding extensions and changes to the SCA spec
>
> On Jul 18, 2006, at 5:28 PM, Raymond Feng wrote:
>
>> Hi,
>>
>> It should be a good fit to use Transfomation service to present
>> property values in a preferred way indicated by the property receiver.
>>
>> Here're some use cases I can imagine:
>>
>> 1) Parse the XML for a property value to create a DOM
>> representation (StAX XMLStreamReader-->DOM Node)
>>
>> 2) Inject the property to the target instance:
>>
>> For example,
>>
>> @DataBinding(type="sdo", ...)
>> @Property
>> private MyProperty myProperty;
>>
> We could support the annotation but I was also thinking we could have
> a Tuscany runtime configuration set per component implementation
> type. I like the configuration approach with an attribute override
> since it allows implementation code to remain agnostic of the
> databinding unless it needs something specific (in which case it
> could use the annotation).
>
> Raymond, do you want to take a stab at separating packages into what
> should go into an SPI and what should go into core?
>
> Jim
>
>> Then DOM Node --> SDO DataObject can be applied.
>>
>> Thanks,
>> Raymond
>>
>>
>> ----- Original Message ----- From: "Jim Marino"
>> <jm...@myromatours.com>
>> To: <tu...@ws.apache.org>
>> Sent: Tuesday, July 18, 2006 2:12 PM
>> Subject: Data binding extensions and changes to the SCA spec
>>
>>
>>> I would like to get started on support for for XPath in SCDL as it
>>> is part of the recent SCA spec changes. This will likely require
>>> changes to the loader infrastructure and in particular
>>> StringParserPropertyFactory. Instead of having a PropertyFactory
>>> create an ObjectFactory responsible for returning a value that is
>>> injected into a component implementation instance, we will need
>>> to have a more flexible approach as property values may now be
>>> based off of XPath expressions to composite properties.
>>>
>>> What I would like to propose is that we have creation of the
>>> ObjectFactory for the property handled by the builder in much the
>>> same way as it handles wires. I think we can leverage the data
>>> transformation service for this. In this case, the builder will
>>> be given a representation of the parsed XML, probably DOM. If
>>> the property value was an XPath expression, the builder will have
>>> to use an XPath engine to evaluate and retrieve this actual value
>>> (Jaxen?) represented as a Node. The builder will then in turn use
>>> the transformation service to create a "bound type". The builder
>>> will subsequently create an ObjectFactory for the bound type
>>> responsible for injecting on the target component implementation
>>> instance. The specific kind of ObjectFactory will depend on the
>>> kind of property it is:
>>>
>>> - If it is immutable, the builder will use a SingletonObjectFactory
>>>
>>> - If it is mutable, but the property is configured as
>>> "safe" (i.e. the component does not mutate it), the builder will
>>> use a SingletonObjectFactory). We can also assume by default
>>> values are "safe" unless explicitly marked.
>>>
>>> - If it is mutable, marked "not safe," and Cloneable, a
>>> CloningObjectFactory is used which clones on getInstance()
>>>
>>> -If it is mutable, marked "not safe" and is not Cloneable, the
>>> builder avoids the call to the transformation service and instead
>>> uses an ObjectFactory which calls out the to transformation
>>> service on every getInstance() invoke.
>>>
>>> For some implementation types, a builder may not want to use
>>> ObjectFactory (perhaps the implementation just takes a DOM or
>>> some other format). In that case, the builder would be free to
>>> use the transformation service or not.
>>>
>>> Raymond, does this sound like it would fit with the transformation
>>> service? If so, I think we need to look at incorporating the base
>>> data transformation framework into SPI and core.
>>>
>>> I'd also be willing to work on an XStream binding extension which
>>> would enable handling of basic POJO binding.
>>>
>>> Jim
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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: Data binding extensions and changes to the SCA spec
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 18, 2006, at 5:28 PM, Raymond Feng wrote:
> Hi,
>
> It should be a good fit to use Transfomation service to present
> property values in a preferred way indicated by the property receiver.
>
> Here're some use cases I can imagine:
>
> 1) Parse the XML for a property value to create a DOM
> representation (StAX XMLStreamReader-->DOM Node)
>
> 2) Inject the property to the target instance:
>
> For example,
>
> @DataBinding(type="sdo", ...)
> @Property
> private MyProperty myProperty;
>
We could support the annotation but I was also thinking we could have
a Tuscany runtime configuration set per component implementation
type. I like the configuration approach with an attribute override
since it allows implementation code to remain agnostic of the
databinding unless it needs something specific (in which case it
could use the annotation).
Raymond, do you want to take a stab at separating packages into what
should go into an SPI and what should go into core?
Jim
> Then DOM Node --> SDO DataObject can be applied.
>
> Thanks,
> Raymond
>
>
> ----- Original Message ----- From: "Jim Marino"
> <jm...@myromatours.com>
> To: <tu...@ws.apache.org>
> Sent: Tuesday, July 18, 2006 2:12 PM
> Subject: Data binding extensions and changes to the SCA spec
>
>
>> I would like to get started on support for for XPath in SCDL as it
>> is part of the recent SCA spec changes. This will likely require
>> changes to the loader infrastructure and in particular
>> StringParserPropertyFactory. Instead of having a PropertyFactory
>> create an ObjectFactory responsible for returning a value that is
>> injected into a component implementation instance, we will need
>> to have a more flexible approach as property values may now be
>> based off of XPath expressions to composite properties.
>>
>> What I would like to propose is that we have creation of the
>> ObjectFactory for the property handled by the builder in much the
>> same way as it handles wires. I think we can leverage the data
>> transformation service for this. In this case, the builder will
>> be given a representation of the parsed XML, probably DOM. If
>> the property value was an XPath expression, the builder will have
>> to use an XPath engine to evaluate and retrieve this actual value
>> (Jaxen?) represented as a Node. The builder will then in turn use
>> the transformation service to create a "bound type". The builder
>> will subsequently create an ObjectFactory for the bound type
>> responsible for injecting on the target component implementation
>> instance. The specific kind of ObjectFactory will depend on the
>> kind of property it is:
>>
>> - If it is immutable, the builder will use a SingletonObjectFactory
>>
>> - If it is mutable, but the property is configured as
>> "safe" (i.e. the component does not mutate it), the builder will
>> use a SingletonObjectFactory). We can also assume by default
>> values are "safe" unless explicitly marked.
>>
>> - If it is mutable, marked "not safe," and Cloneable, a
>> CloningObjectFactory is used which clones on getInstance()
>>
>> -If it is mutable, marked "not safe" and is not Cloneable, the
>> builder avoids the call to the transformation service and instead
>> uses an ObjectFactory which calls out the to transformation
>> service on every getInstance() invoke.
>>
>> For some implementation types, a builder may not want to use
>> ObjectFactory (perhaps the implementation just takes a DOM or
>> some other format). In that case, the builder would be free to
>> use the transformation service or not.
>>
>> Raymond, does this sound like it would fit with the transformation
>> service? If so, I think we need to look at incorporating the base
>> data transformation framework into SPI and core.
>>
>> I'd also be willing to work on an XStream binding extension which
>> would enable handling of basic POJO binding.
>>
>> Jim
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data binding extensions and changes to the SCA spec
Posted by Raymond Feng <en...@gmail.com>.
Hi,
It should be a good fit to use Transfomation service to present property
values in a preferred way indicated by the property receiver.
Here're some use cases I can imagine:
1) Parse the XML for a property value to create a DOM representation (StAX
XMLStreamReader-->DOM Node)
2) Inject the property to the target instance:
For example,
@DataBinding(type="sdo", ...)
@Property
private MyProperty myProperty;
Then DOM Node --> SDO DataObject can be applied.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, July 18, 2006 2:12 PM
Subject: Data binding extensions and changes to the SCA spec
>I would like to get started on support for for XPath in SCDL as it is part
>of the recent SCA spec changes. This will likely require changes to the
>loader infrastructure and in particular StringParserPropertyFactory.
>Instead of having a PropertyFactory create an ObjectFactory responsible
>for returning a value that is injected into a component implementation
>instance, we will need to have a more flexible approach as property values
>may now be based off of XPath expressions to composite properties.
>
> What I would like to propose is that we have creation of the
> ObjectFactory for the property handled by the builder in much the same
> way as it handles wires. I think we can leverage the data transformation
> service for this. In this case, the builder will be given a
> representation of the parsed XML, probably DOM. If the property value was
> an XPath expression, the builder will have to use an XPath engine to
> evaluate and retrieve this actual value (Jaxen?) represented as a Node.
> The builder will then in turn use the transformation service to create a
> "bound type". The builder will subsequently create an ObjectFactory for
> the bound type responsible for injecting on the target component
> implementation instance. The specific kind of ObjectFactory will depend
> on the kind of property it is:
>
> - If it is immutable, the builder will use a SingletonObjectFactory
>
> - If it is mutable, but the property is configured as "safe" (i.e. the
> component does not mutate it), the builder will use a
> SingletonObjectFactory). We can also assume by default values are "safe"
> unless explicitly marked.
>
> - If it is mutable, marked "not safe," and Cloneable, a
> CloningObjectFactory is used which clones on getInstance()
>
> -If it is mutable, marked "not safe" and is not Cloneable, the builder
> avoids the call to the transformation service and instead uses an
> ObjectFactory which calls out the to transformation service on every
> getInstance() invoke.
>
> For some implementation types, a builder may not want to use
> ObjectFactory (perhaps the implementation just takes a DOM or some other
> format). In that case, the builder would be free to use the
> transformation service or not.
>
> Raymond, does this sound like it would fit with the transformation
> service? If so, I think we need to look at incorporating the base data
> transformation framework into SPI and core.
>
> I'd also be willing to work on an XStream binding extension which would
> enable handling of basic POJO binding.
>
> Jim
>
> ---------------------------------------------------------------------
> 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