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.
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 - Venkat On 9/27/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Venkat. Sorry for not responding promptly. Please go ahead to make the changes as we discussed and I'll help if necessary. I have attached some code that you may be able to cut and paste into your code. Thanks, Raymond ----- Original Message ----- From: "Venkata Krishnan" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, September 26, 2006 1:51 AM Subject: Re: Queries related to Component Property Loading > 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: <[email protected]> >> 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
