This page summarizes the planned changes for the next major release, i.e. Axiom 1.3. Note that it is not intended as a wish list for new features, but identifies a set of changes that break backward compatibility and therefore need to be postponed to the 1.3 release.
The overall goals for the 1.3 are:
There are several APIs that use Object although they expect or return a DataHandler. This is probably a legacy of Axis 1.x where the Activation API was an optional dependency. Today this no longer makes sense:
The following APIs will be changed to use DataHandler directly:
Some methods are declared at the wrong level in the node type hierarchy so that they may be called on nodes for which they are not meaningful:
This section identifies APIs that have become unnecessary or irrelevant. Note that APIs that have already been deprecated in 1.2.x (and will be removed in 1.3 anyway) are not listed here.
In Axiom versions prior to 1.2.9, the sequence of events produced by the XMLStreamReader returned by getXMLStreamReaderWithoutCaching was inconsistent if the underlying stream is XOP encoded (see AXIOM-255). This made it necessary for application code to (partially) handle the XOP processing itself. That is the reason why the XMLStreamReader instance (which is an OMStAXWrapper) implements OMAttachmentAccessor: it allowed the application code to retrieve the binary content for undecoded xop:Include elements.
Starting with Axiom 1.2.9 the sequence of events produced by the XMLStreamReader is always the same (i.e. XOP is always completely decoded) and all binary content is reported through the DataHandlerReader extension, making the OMAttachmentAccessor API unnecessary in that context.
The interface is used in several other contexts as well, but it is actually unnecessary in each of them:
This API can't be preserved as is in Axiom 1.3. There are two reasons for this:
TODO: analyze the use cases for this API to see if we still need it
The XOPBuilder interface is implemented by XOPAwareStAXOMBuilder and MTOMStAXSOAPModelBuilder. With the changes in r1164997 and r1207662, it is no longer used internally by Axiom. The interface declares methods that give access to the Attachments object that was used to create the builder. That is undesirable for two reasons:
Therefore the XOPBuilder API will be removed in Axiom 1.3.
Up to version 1.2.12, the core Axiom code was organized in three modules, namely axiom-api, axiom-impl and axiom-dom, where axiom-api contains both the public API as well as implementation classes shared by LLOM and DOOM. Unfortunately the distinction between the public API and these shared implementation classes has become somewhat blurred over time. In Axiom 1.2.13 a new module axiom-common-impl was introduced with the specific goal of separating the shared implementation classes from the public API. However, in Axiom 1.2.x this only applies to new code because in most cases it is not possible to move classes from axiom-api to axiom-common-impl without the risk of breaking existing code.
A new major release gives us the opportunity to move the existing shared classes to axiom-common-impl as well, so that in Axiom 1.3, axiom-api will only contain Axiom's public API. This is one of the important goals for Axiom 1.3 because it has multiple benefits:
This section identifies the classes and internal APIs that will be removed from axiom-api.
In Axiom 1.2.13, the OMXMLBuilderFactory API allows to create any type of object model builder (plain XML, SOAP, XOP and MTOM). The API also defines two interfaces representing a builder: OMXMLParserWrapper and SOAPModelBuilder. This means that application code should no longer reference the builder implementation classes directly, but only OMXMLBuilderFactory, OMXMLParserWrapper and SOAPModelBuilder. In Axiom 1.3 the implementation classes can therefore be moved to axiom-common-impl. They are:
TODO: there is one API that still references StAXBuilder, namely BuilderAwareReader; it needs to be changed (or removed)
Together with these classes, the following interfaces and helper classes should also be moved to axiom-common-impl:
Some interfaces are part of the public API although they are placed in an impl package. These interfaces need to be moved to another package to make it clear that they are not internal or implementation specific interfaces:
The LifecycleManager API has a couple of issues that can't be fixed without breaking backward compatibility: