Re: Queries related to Component Property Loading

[Raymond Feng]

Hi, Venkata.

Please post a patch to the JIRA and I can help you review and apply it. 
Incremental changes are good and we can go step by step.

Thanks,
Raymond


----- Original Message ----- 
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, October 02, 2006 5:52 AM
Subject: Re: Queries related to Component Property Loading


Hi Jim / Raymond,

I have completed this... atleast from my little world of understand.  I
shall post the patch onto a JIRA.  Meanwhile here is a summary that gives 
an
idea of the changes that I have made.  I have successfully tried a test 
with
a component like this...

<component name="HelloWorldJavaReference">
       <implementation.java class="helloworld.HelloWorldServiceImpl"/>
       <property name="greeting">
           Hullow
       </property>
       <property name="helloSayer">
           <firstName>Tuscany</firstName>
           <lastName>World</lastName>
       </property>
</component>


Here are the changes that I have done.

org.apache.tuscany.spi.model.Property
--------------------------------------
- I have included an attribute called 'override' that will take one of the
following values (may, must, no)
- I have removed the attribute 'required' (I suppose this is now addressed
under the attribute 'override')

org.apache.tuscany.spi.model.PropertyValue
------------------------------------------
- I have added an attribute called 'valueDocument' that will contain the
value specified for a property in a component definition in the scdl

org.osoa.sca.annotations.Property
---------------------------------
- removed the attribute 'required'
- added attributes 'overideOptions' and 'xmlType'


org.apache.tuscany.core.loader.PropertyLoader
---------------------------------------------
This class handles the loading of properties from a componentType file
- just about replaced 'required' with 'overide'.

org.apache.tuscany.core.loader.ComponentLoader
----------------------------------------------
This is the class that loads the component defn. from a scdl
- The existing behaviour of creating the appropriate ObjectFactory as and
when the property element is being loaded and setting it to an instance of
PropertyValue has now been pushed to Builders. Instead the property value
specified in the scdl is loaded as a Document and set to an instance of
PropertyValue class. I have pushed the ObjectFactory creation to Builders
because it they who know how to map a Document data to data that could be
understood by the implementation that they build.


org.apache.tuscany.core.implementation.java.JavaComponentBuilder
----------------------------------------------------------------
This is the java builder that will handle the conversion of the property
value from Document form to a form that could be understood by the Java
Implementation (i.e. Java Types).  I guess the builders of other 
containers
such as groovy, javascript, ruby will have to do something similar to suit
groovy, javascript, rubyscript respectively.
- Here I have used the approach that assumes the following : -
    - that the java classes that represent properties have a default
constructor
    - the name of elements in the document that represents the property
values maps with the field names (for example if there is a complex 
property
Customer that has elements firstName and lastName, then it is expected 
that
the corresponding java class has fields with names as firstName, lastName)

- the approach as such is an obvious.  First, since the impl class in 
known,
I access from it a field whose name matches the property name in the
component defn.  Starting from here I reflect recursively into this field
class as I navigate the property value document and set the value to the
field all along.
-  at the end of this recursion I obtain an instance of the property, 
using
which I create the object factory and set it into the map.

Concerns
--------------
Here are some concerns that are outstanding despite this...
*)  I am unable to use the .componentType file.  If I used one then I get
the following exception:
org.apache.tuscany.spi.loader.UnrecognizedElementException: {
http://www.osoa.org/xmlns/sca/1.0}componentType [{
http://www.osoa.org/xmlns/sca/1.0}componentType]
Context stack trace: [application][HelloWorldJavaReference]
   at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:113)

Looks like there is problem if I mention JavaComponentType.class in the 
load
method.  I guess this because all othere containers  have worked around 
this
aspect.

Am I missing something here?

*)  When I initially clipped the existing property value loading behaviour
in the ComponentLoader, the system components could never get initialized.
To go forward with this, I decided to address only application components.
To this end, I retained the existing behaviour when the component is a
SystemImplementation and changed it for other cases.   I am not clear 
about
the direction for this.

Thanks for patiently reading upto this point. :)

- Venkat


On 10/2/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

Hi Jim,

I was going to touch upon that once I completed and posted a patch for
review.

I initially assumed that since our runtime was in Java, the
implementation.system components would just about use the Java container.
However I observed that they never touched the JavaComponentBuilder. 
Also I
observed that for system components there were properties that were 
getting
configured, loaded and built - meaning the property hanlding seemed to be 
in
place (atleast to the extent that things are working).

 In the interest of not disrupting too many things I have chosen to leave
the system components alone - atleast in this iteration.  The
ComponentLoader is however used while loading all components (system or
application) and this is one place I have had to make some changes to the
existing behaviour.  For this I have chosen the apporach of retaining the
existing behaviour whe loading SytemImplementation components and have 
put
in an alternate behaviour for all others.

After I have done with this iteration, I can probably take up the case of
system components with some help from you / jeremy if at all they also 
need
to change.

Thanks

- Venkat



On 10/1/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
> Hi Venkat,
>
> One thing I wanted to make sure about below...
>
> On Oct 1, 2006, at 10:27 AM, Venkata Krishnan wrote:
>
> > Hi Raymond,
> >
> > Just to keep you updated.  I am working on this and have been able
> > to get
> > the simple type property working.  i.e. properties are loaded
> > properly from
> > scdl.   Then I have made some changes to the JavaComponentBuilder
> > to build
> > from these loaded properties.
> Shouldn't any changes for loading properties also apply to system
> services as well?
> >
> > Right now I am trying to see if there is a scheme to get the complex
> > properties working as well.  Hope I am able to post something off by
> > tomorrow for some review and discussion.  Thanks
> >
>
>
> ---------------------------------------------------------------------
> 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]