OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sdo] ISSUE 5: Defining SDO types by JAVA types


Title: ISSUE 5: Defining SDO types by JAVA types
What is the intended scope for this issue?:

Option #1:  Define Types from SDO Compatible Interfaces
For me the minimum bar for this feature is to ensure that interfaces that can be generated from an XML schema can themselves be the source of the SDO metadata.  Presumably we would also require that all generated interfaces contain the necessary annotations (just as JAXB 2.X does with its generated classes).

Option #2:  Define Types from Any Interface
Similar to option #1, but a heck of a lot more work.  We would need to devise ways of handling all possible Java types including:
  • javax.xml.namespace.QName
  • org.w3c.dom.Element
  • java.util.Calendar
  • javax.xml.datatype.XMLGregorianCalendar
  • java.util.Map
  • org.mydomain.foo.Employee (a POJO not an interface)
Option #3:  Somewhere between Option #1 and Option #2
Somewhere between option #1 & option #2, although we should decide where the line will be drawn.

-Blaise

Barack, Ron wrote:

Hi Everyone,

The current discussion of containment is in large part motivated by the wish to use other sources of metadata as a standard way to define types.

Although we at SAP have always interpreted the spec as at least allowing this, we're probably alone in that interpretation.  The spec is at best very unclear about how this should be done.

One possibility is to interpret TypeHelper.getType(Class) as performing introspection of the class, and returning a type based on this introspection.  In order to standardize this behavior, all we'd need to do is change the second bullet point in 4.8.2 from

    • getType(Class interfaceClass) returns the Type for this interfaceClass or null if not found.

To something like

    • getType(Class interfaceClass) returns the Type for this interfaceClass.  If the interfaceClass is not already associated with a Type, the class will be introspected according to the algorithm in Chapter 6, recursively creating Types as needed for all classes directly or indirectly referenced by interfaceClass.

This is probably fairly surprising behavior.  From the usability standpoint, most people don't expect a getter to do anything other than look up a value.  On the other hand, this is really nothing more than a form of lazy initialization.  The ClassLoader associated with the helper context is implicitly loaded when the helper context is created.

If we want to define a new method, then need to do a little more work, and define a method like

    • defineType(Class interfaceClass) returns the Type for this interfaceClass.  If the interfaceClass is not already associated with a Type, the class will be introspected according to the algorithm in Chapter 6, recursively creating Types as needed for all classes directly or indirectly referenced by interfaceClass.


Note that neither proposal requires us to solve the knottier issue of how the class is introspected, and converted to a SDO type.  This is just putting another stake in the ground, saying that Java classes can be introspected, can be sources of metadata, and that this is the API for doing it.


Best Regards,
Ron




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]