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: [sdo] [SDO-22]: Java annotations: Start with Java declarations andcreate SDO Type and Property (SDO Project Objective #6)



Radu Preotiuc [20/Apr/06 08:03 PM] 
I am trying to get my head around this. Is the expectation that the user
will continue to program against his existing Java classes, now
"SDO-ized" by having an SDO Type attached to them? Or that we will use
the Java typing information like we use XMLSchema to generate SDO Types
and then turn around and generate a "different" set of the Java classes
by the same Java Codegen mechanism that we would normally use?

If the former, can we guarantee consistent behavior wrt change tracking,
setters, XPath etc? In what sense would the users still program against
the SDO model?



Ron Barack [21/Apr/06 09:02 AM] 
With the decision to wait till v3 before we go to Java 5, isn't this
(along with the other annotation related issues) per-definition a v3.0
issue?

On the other hand, the ability to store metadata in the form of java
code as opposed to XML/XSD or some other format is important to us,
simply because it integrates better with our development infrastructure.

There are 2 cases here: where the user has a hand-coded interface and
wants to use the SDO infrastucture, but perhaps more important is the
tool supported generation of the interfaces, based for instance on the
structure of database tables. Client side users would typically program
against the generated interface, because that's easiest, but can also
cast to DO in order to use the generic interface, or to get more
detailed metainformation.



Steve Brodsky [11/May/06 06:06 PM] 
JDK 5 really needed for annotations, which would be an SDO 3.0 decision,
so moving to SDO3.



Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.


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