Hi,
I found two issues with the commit.
1) The "core" cannot be compiled at more. There's a class
"org.apache.tuscany.core.databinding.xml.Node2Object" still references a
class that was deleted in your checkin.
public class Node2Object extends XMLType2JavaTransformer<Node> {
...
}
2) I'm not very sure if we should have a separate extension for the
JavaBeans databinding. Should we merge it into the core where we already
have transformers dealing with XML parsing technologies.
BTW, we also fix some checkstyle violations.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, February 01, 2007 1:07 AM
Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
supported
> Hi Raymond,
>
> I have committed a JavaBeans databinding and have refactored somethings
> that
> were related to this that I had added to the SPI earlier. I shall add
> more
> transformers in later increments, looking at the Axis2 link you have
> provided.
>
> Thanks
>
> - Venkat
>
> On 1/30/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi, Venkat.
>>
>> Please see my comments inline.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> Sent: Tuesday, January 30, 2007 4:07 AM
>> Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
>> supported
>>
>>
>> > Hi Raymond,
>> >
>> > I have done the following: -
>> >
>> > - Created a JavaBeansDataBinding with basetype as
>> > java.lang.Objectand
>> > have
>> > included a DOMNode2JavaBean transformer into this binding. This
>> > tranformer
>> > has the xml to javabean transformation that I have done.
>>
>> We probably need to add more transformers. Some code in the Axis2 ADB
>> might
>> help:
>>
>>
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/adb/src/org/apache/axis2/databinding/utils/
>> .
>>
>> > - Extended the AbstractPropertyProcessor's method to look for
DataType
>> > annotations and then add the databinding name to the Property as
>> extension
>> > metadata.
>>
>> Yes.
>>
>> > - 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.
>>
>> I think we should consider the simple types as special cases of java
>> beans.
>> It makes sense to me that we unify them and use it as the default
>> databinding in the java world.
>>
>> >
>> > 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?
>>
>> I think Jeremy has already explained this. Please see
>> http://www.mail-archive.com/[email protected]/msg13192.html.
>>
>> >
>> > 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: <[email protected]>
>> >> 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.ObjectFactoryImplclass.
>> >> > 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)" <[email protected]>
>> >> >> To: <[email protected]>
>> >> >> 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]
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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]
