
git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@668359 13f79535-47bb-0310-9956-ffa450edef68
88 lines
No EOL
4.8 KiB
Text
88 lines
No EOL
4.8 KiB
Text
What's New in SDO Java M2
|
|
|
|
1. `java.io.Serializable` support for `DataObject`s including objects not in a `DataGraph` (TUSCANY-22)
|
|
2. Java code generator improvements
|
|
3. XML Schema generation (TUSCANY-535)
|
|
4. StAX-based Load load and save support (TUSCANY-118)
|
|
5. new SDOUtil methods
|
|
6. CrossScopeCopyHelper (TUSCANY-627)
|
|
7. open content creation API (SDO 2.1 enhancement early implementation - see draft 2.1 spec)
|
|
8. sample programs
|
|
9. More than 12 new bugfixes
|
|
|
|
Details are described below.
|
|
|
|
SDO Java M2 is a superset of previous SDO Java M1 release.
|
|
Anything in M1 is also in M2, but M2 contains features and bugfixes not present in M1 release.
|
|
|
|
Downloading
|
|
http://incubator.apache.org/tuscany/downloads.html#Apache%20Tuscany%20Java%20Downloads
|
|
|
|
Compatibility Concerns
|
|
M2 is still on SDO Java specification 2.01 same as M1.
|
|
SDO Java M2 maintains API/SPI compatibility with M1 release, by only adding new functions.
|
|
A program written to the M1 API/SPI can both compile and run using M2 libraries.
|
|
However, a program written for M2 cannot necessarily compile or run against M1 libraries.
|
|
|
|
Command Line Output Changes
|
|
Although the SDO Java developers try hard to keep output from the command line programs compatible between releases,
|
|
new information sometimes has to be added. This might break scripts that rely on the exact format of the output.
|
|
In M2, for example, SDO static code generator help information is updated as new options available.
|
|
|
|
New Features
|
|
|
|
1. `java.io.Serializable` support for `DataObject`s including objects not in a `DataGraph` (TUSCANY-22)
|
|
DataObject used to be required to put into DataGraph before being Java serialized;
|
|
from M2 on, DataObject can be Java serialized standalone.
|
|
And the data object serialization format conforms to SDO Java specification 2.01.
|
|
At the same time, DataGraph serialization is also working now although whose format is still not compliant yet.
|
|
|
|
2. Java code generator improvements
|
|
A new option (-interfaceDataObject) is available to generate interfaces that extend commonj.sdo.DataObject (TUSCANY-254).
|
|
The existed option (-noEMF) pattern has been improved, e.g.,
|
|
inheritance and bidirectional references are now working (sca-core.xsd can be generated).
|
|
On the other hand, generated interfaces now extend java.io.Serializable by default convenient to remote invocation.
|
|
|
|
3. XML Schema generation (TUSCANY-535)
|
|
XSDHelper used to go only one way that #define methods import models from XML Schema,
|
|
SDO Java M2 has implemented `XSDHelper.generate()` methods to export models as XML Schema.
|
|
|
|
4. StAX-based Load load and save support (TUSCANY-118)
|
|
A new helper XMLStreamHelper has been added,
|
|
it's based on Stream API for XML which makes SDO convenient to use in StAX environment.
|
|
On the other hand, StAX load/save is a better-performance alternative sometimes.
|
|
|
|
5. new SDOUtil methods
|
|
|
|
* SDOUtil.getSubstitutionValues()
|
|
SDO user used to assume the SDO implementation is based on EMF
|
|
and use EMF API/SPI to access substitutable Property since no such API/SPI available in SDO Java M1.
|
|
M2 has provided such non-EMF way to get the Sequence corresponding to a substitutable Property (TUSCANY-502/503)
|
|
|
|
* SDOUtil.isRequired()
|
|
Determine if a property is required, that is, minOccurs > 0 (TUSCANY-504)
|
|
|
|
* SDOUtil.setRootObject()
|
|
SDO user used to be only able to get the root object of a DataGraph in SDO Java M1,
|
|
M2 has enabled setting the root object of a DataGraph (TUSCANY-512)
|
|
|
|
* SDOUtil.getTypes()
|
|
Gets all of the types associated with a uri (TUSCANY-583)
|
|
|
|
* SDOUtil.registerDataGraphTypes
|
|
DataObject/DataGraph serialization used to be instances only;
|
|
models are expected on the other endpoint otherwise either anyType will be used to deserialize DataObject/DataGraph
|
|
or ClassNotFoundException will be thrown.
|
|
Even if no ClassNotFoundException, anyType isn't always satisfying.
|
|
SDO Java M2 has enabled models seriallization by registering Types to be serialized along with a DataGraph (TUSCANY-670)
|
|
|
|
6. CrossScopeCopyHelper (TUSCANY-627)
|
|
Types are registered within certain scopes (TypeHelpers).
|
|
Two Types from different scopes (TypeHelper) are two different types even if imported from very same source such as XML Schema.
|
|
Some scenario such as local invocation prefers copying to serialization
|
|
which requires copying to use Types from (invocation) destination endpoint instead of the source/original one.
|
|
SDO Java M2 has enabled copying DataObject instances from one TypeHelper to another scope.
|
|
|
|
7. open content creation API (SDO 2.1 enhancement early implementation - see draft 2.1 spec)
|
|
* TypeHelper.createOpenContentProperty()
|
|
* TypeHelper.getOpenContentProperty() |