Hi Jeremy, Thanks for the explanation. I am more convinced now that we should use a data transformation service in binding extension to deal with various data bindings instead of having the data binding knowledge directly embedded in binding (e.g., use SDO TypeHelper directly). To move things forward quickly, I wonder, if most people can agree this is the direction to go, or at least there is no objections to add a data meditation service, can someone has committer right kindly put Raymond's code into sandbox please? Once this code is in svn, we can play with it and help out to resolve the "TODO" list mentioned by Raymond as well as issues like sdo typeHelper.
Thanks, Jervis Liu -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeremy Boynes Sent: Thursday, June 29, 2006 9:25 PM To: [email protected] Subject: Re: TypeHelper WAS: RE: Status of databinding module in sandbox and DataMediation On 6/29/06, Liu, Jervis <[EMAIL PROTECTED]> wrote: > Hi Jeremy, > > So what is the issue with TypeHelper, and when can this be resolved? > SDOXMLHelper.java will need to use typeHelper. Previously in M1, Binding > extension can get TypeHelper from LoaderContext, so how can I get it now > using the new SPI code? From DeploymentContext? (see > sandbox\jboynes\sca\bindings\binding.celtix\src\main\java\org\apache\tuscany\binding\celtix\WebServiceBindingLoader.java). > Thanks. > The big issue is how does type scoping work in a recursive runtime? This isn't something the spec covers so we need to come up with something. In M1 we had <import.sdo> to import types for use in a module which worked well at one level. When we add recursion it brings up the question of which types if any get propogated between the outer and inner composites. My first thought is that component types should be able to declare the types that they depend on. This could be done in the sidefile (using import.sdo) or by annotation of the implementation. This is a more general form of what we had in M1 that can be done now that a composite is an extension of a component type. It would then be the responsibility of the thing that used an implementation to make sure that type dependencies in its component type definition were resolved. This is most likely to be in a composite and could be done with a version of import.sdo that referred to type definition information (e.g. an annotated schema instance). I took the typeHelper out of the LoaderContext for a couple of reasons. The first was that I did not want to have the SPI be dependent on SDO classes (thinking that SDO would be a plugin module rather than fundamental). I was also thinking we would need to support multiple type hierarchies (e.g. both SDO and JAXB) and so would need to have an extensibility point for that. Finally, it should be possible to install type heirarchies on their own and one way to do that would be to have type helper instances become system components. To implement this I was thinking we'd have a system service in the SDO databinding plugin that would be a register for type helpers. The databinding would also contibute annotation processors and XML element handlers that would be used by component builders to handle SDO artifacts (like injecting a helper or creating DataObjects during an invocation). -- 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]
