Hi Raymond,

I have done the following: -

- Created a JavaBeansDataBinding with basetype as java.lang.Object and have
included a DOMNode2JavaBean transformer into this binding.  This tranformer
has the xml to javabean transformation that I have done.
- Extended the AbstractPropertyProcessor's method to look for DataType
annotations and then add the databinding name to the Property as extension
metadata.
- I have added the JavaBeansDataBinding and the DOMNode2JavaBean transformer
as system components to databinding.scdl of core.

Here are some queries that I have.  Please help me with some clarity.
1) Now that we have the JavaBeansDataBinding, can we move the Node2Object
and Object2Node out of org.apache.tuscany.core.databinding.xml.  Infact,
Node2Object might get to be replaced by DOMNode2JavaBean.  Also, can the
related type mappers such as SimpleTypeMapper be moved over into this new
databinding.  This sort of consolidation seems to be inevitable since only
one of the transformers can stay registered with the runtime and that will
be the one that is registered last.

2) Could you please help me understand the difference between physical and
logical types in the DataType.  Specifically in the context of
implementations of DataBindings, I am getting the understanding that, for a
DataBinding to handle a specific DataType the physical type of the DataType
must be compatible (say assignable) with the basetype of the DataBinding.
Is this understanding right?

If this is right, then I have an issue understanding the implementation of
the 'introspect' method of the DataBindingExtension class.  I have commented
as "svkrish:" within the following snippet regarding my question.

public DataType introspect(Class<?> javaType) {
       if (baseType == null || javaType == null) {
           return null;))
       }
       if (baseType.isAssignableFrom(javaType)) {
           //svkrish : should this not be...
          //...new DataType<Class>(name, baseType, javaType);
           return new DataType<Class>(name, javaType, baseType);
       } else {
           return null;
       }
   }


Thanks for helping all the way :)

- Venkat


On 1/29/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi, Venkat.

Please see my comments below.

Thanks,
Raymond

----- Original Message -----
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, January 29, 2007 12:36 AM
Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
supported


> Hi Raymond,
>
> I looked up the current implementation and have some queries regarding
> your
> suggestions.  Please help me with some clarifications inline.  Thanks
>
> - Venkat
>
>
> On 1/26/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi, Venkat.
>>
>> I think we should reorganize the code to match what we envisioned
before.
>> Here's the basic idea:
>>
>> 1) The property values are loaded as DOM objects by the runtime during
>> the
>> loading phase
>
>
> This is already in place, isn't it?

Yes, we already have this feature.

>
> 2) The component implementations express their requirements for the
> property
>> values using DataType. For java component, this can be achieved by
>> annotating the property with @DataType. This becomes extensions to the
>> componentType.
>>
> 3) The property injector will transform the property value from DOM to
the
>> target data type (for example, SDO, JAXB, JavaBeans, etc).
>
>
> I understand these two and I guess you have already put things in place
to
> some extent in PropertyObjectFactoryImpl.ObjectFactoryImpl class.  Just
> that
> I have now enabled the target databinding to be picked up from the
> annotations.

Yes. We need to figure out the databinding from the property declaration
(w/
optional @DataType annotation).

>
> For the properties are modeled as JavaBeans, we can do the following:
>>
>> 1) Contribute a Transformer which can convert data from DOM Node to
>> JavaBeans using the algorithm you wrote.
>
>
> I thought the Node2Object transformer was for this purpose and hence
> extended it further to support complex types.  Am I missing something
here
> ?

Object is a bit misleading:-). My intention is to formally define the Java
databinding.

>
> 2) By default, the java properties uses JavaDataBinding which supports
>> simple types and JavaBeans.
>
>
> From the existing code, I suppose this is taken care of by the fact that
> when a property has no target databinding mentioned then it defaults to
'
> java.lang.Object'.  Again you had already put this in place in
> PropertyObjectFactoryImpl.ObjectFactoryImpl.  Isn't this enough?
>
> I have now updated the AbstractPropertyProcessor to pick up DataType
> annotations and fill the databinding name as extensions to component
> properties.

You might want to add a DataType field to the Property model?

>
> 3) Update the PropertyInjector (if needed) to use Meditor to transform
the
>> data before injection.
>
>
> I suppose this is also in place with the Mediator being invoked in the
> 'getInstance' method of the
> PropertyObjectFactoryImpl.ObjectFactoryImplclass.  The FieldInjector
> and MethodInjector call this 'getInstance' method.
>

Yes, I assume so. We probably just have to make the final kick :-) to
complete this feature.

> So in summary, in all of this I've just about had to add code in
> AbstractPropertyProcessor to ensure that databindings specified around
> properties as annotations are picked up.  For the physical and logical
> types
> for the DataType associated with a property, I am retaining the JavaType
> of
> the property concerned.
>
> Please let me know if I am missing something here.  Thanks.
>
> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Venkatakrishnan (JIRA)" <tuscany-dev@ws.apache.org>
>> To: <tuscany-dev@ws.apache.org>
>> Sent: Thursday, January 25, 2007 11:25 AM
>> Subject: [jira] Commented: (TUSCANY-925) Complex properties not
supported
>>
>>
>> >
>> >    [
>> >
>>
https://issues.apache.org/jira/browse/TUSCANY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467506
]
>> >
>> > Venkatakrishnan commented on TUSCANY-925:
>> > -----------------------------------------
>> >
>> > HI,
>> >
>> > A first cut support of Complex Properties has been committed -
>> r499915.  I
>> > have also extended the itest for PropertyTesting.
>> >
>> > This implementation uses the basic JavaBeans naming conventions to
map
>> > properties defined as xml data to java object data.  I'd like to
extend
>> > this mapping further to leverage the support from various
databindings
>> > after some discussions with the community.
>> >
>> > I also intend to run thro the more current version of the specs. and
>> sync
>> > up this implementation as futher steps.
>> >
>> > Please let me know your feedback on this implementation.
>> >
>> > Thanks
>> >
>> > - Venkat
>> >
>> >> Complex properties not supported
>> >> --------------------------------
>> >>
>> >>                 Key: TUSCANY-925
>> >>                 URL:
https://issues.apache.org/jira/browse/TUSCANY-925
>> >>             Project: Tuscany
>> >>          Issue Type: Bug
>> >>          Components: Java SCA Core
>> >>            Reporter: Brent Daniel
>> >>         Assigned To: Venkatakrishnan
>> >>             Fix For: Java-SCA-M3
>> >>
>> >>
>> >> This may be intented to be covered in TUSCANY-773, but it was not
>> >> clear
>> >> to me. Complex properties are currently not supported by the tuscany
>> >> runtime.
>> >> Caused by: java.lang.IllegalArgumentException: Complex property is
not
>> >> supported.
>> >> at
>> >>
>>
org.apache.tuscany.core.property.SimplePropertyObjectFactory.getInstance(
>> SimplePropertyObjectFactory.java:56)
>> >
>> > --
>> > This message is automatically generated by JIRA.
>> > -
>> > You can reply to this email to add a comment to the issue online.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to