You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ws.apache.org by ve...@apache.org on 2016/01/04 18:58:54 UTC
svn commit: r1722938 - in /webservices/axiom/trunk:
src/site/markdown/release-notes/ userguide/src/docbkx/
Author: veithen
Date: Mon Jan 4 17:58:54 2016
New Revision: 1722938
URL: http://svn.apache.org/viewvc?rev=1722938&view=rev
Log:
Integrate the change documentation into the respective release notes.
Modified:
webservices/axiom/trunk/src/site/markdown/release-notes/1.2.10.md
webservices/axiom/trunk/src/site/markdown/release-notes/1.2.11.md
webservices/axiom/trunk/src/site/markdown/release-notes/1.2.12.md
webservices/axiom/trunk/src/site/markdown/release-notes/1.2.13.md
webservices/axiom/trunk/src/site/markdown/release-notes/1.2.14.md
webservices/axiom/trunk/src/site/markdown/release-notes/1.2.15.md
webservices/axiom/trunk/src/site/markdown/release-notes/1.2.16.md
webservices/axiom/trunk/src/site/markdown/release-notes/1.2.17.md
webservices/axiom/trunk/src/site/markdown/release-notes/1.2.9.md
webservices/axiom/trunk/userguide/src/docbkx/userguide.xml
Modified: webservices/axiom/trunk/src/site/markdown/release-notes/1.2.10.md
URL: http://svn.apache.org/viewvc/webservices/axiom/trunk/src/site/markdown/release-notes/1.2.10.md?rev=1722938&r1=1722937&r2=1722938&view=diff
==============================================================================
--- webservices/axiom/trunk/src/site/markdown/release-notes/1.2.10.md (original)
+++ webservices/axiom/trunk/src/site/markdown/release-notes/1.2.10.md Mon Jan 4 17:58:54 2016
@@ -1,5 +1,5 @@
Apache Axiom 1.2.10 Release Note
---------------------------------
+================================
Axiom 1.2.10 is a maintenance release that contains the following improvements:
Modified: webservices/axiom/trunk/src/site/markdown/release-notes/1.2.11.md
URL: http://svn.apache.org/viewvc/webservices/axiom/trunk/src/site/markdown/release-notes/1.2.11.md?rev=1722938&r1=1722937&r2=1722938&view=diff
==============================================================================
--- webservices/axiom/trunk/src/site/markdown/release-notes/1.2.11.md (original)
+++ webservices/axiom/trunk/src/site/markdown/release-notes/1.2.11.md Mon Jan 4 17:58:54 2016
@@ -1,5 +1,5 @@
Apache Axiom 1.2.11 Release Note
---------------------------------
+================================
Axiom 1.2.11 is a maintenance release to support the upcoming Axis2 1.6 release.
It also introduces a couple of new APIs that make it easier to support alternative
@@ -18,6 +18,71 @@ Resolved JIRA issues:
* [AXIOM-351] - Links in Javadoc JARs are broken
* [AXIOM-352] - StAXDialectDetector doesn't recognize com.bea.core.weblogic.stax_1.7.0.0.jar
-Please refer to the [user guide][1] for additional information about changes in Axiom 1.2.11.
+Changes in this release
+-----------------------
-[1]: ../userguide/ch04.html#changes-1.2.11
+### Resurrection of the OMXMLBuilderFactory API
+
+Historically, `org.apache.axiom.om.impl.llom.factory.OMXMLBuilderFactory` was used to create Axiom
+trees from XML documents. Unfortunately, this class is located in the wrong package and JAR (it is
+implementation independent but belongs to LLOM). In Axiom 1.2.10, the standard way to create an
+Axiom tree was therefore to instantiate `StAXOMBuilder` or one of its subclasses directly. However,
+this is not optimal for two reasons:
+
+* It relies on the assumption that every implementation of the Axiom API necessarily uses
+ `StAXOMBuilder`. This means that an implementation doesn't have the freedom to provide its own
+ builder implementation (e.g. in order to implement some special optimizations).
+
+* `StAXOMBuilder` and its subclasses belong to packages which have `impl` in their names. This
+ tends to blur the distinction between the public API and internal implementation classes.
+
+Therefore, in Axiom 1.2.11, a new abstract API for creating builder instances was introduced. It is
+again called `OMXMLBuilderFactory`, but located in the `org.apache.axiom.om` package. The methods
+defined by this new API are similar to the ones in the original (now deprecated)
+`OMXMLBuilderFactory`, so that migration should be easy.
+
+### Changes in the behavior of certain iterators
+
+In Axiom 1.2.10 and previous versions, iterators returned by methods such as
+`OMIterator#getChildren()` internally stayed one step ahead of the node returned by the `next()`
+method. This meant that sometimes, using such an iterator had the side effect of building elements
+that were not intended to be built. In Axiom 1.2.11 this behavior was changed such that `next()` no
+longer builds the nodes it returns. In a few cases, this change may cause issues in existing code.
+One known instance is the following construct (which was used internally by Axiom itself):
+
+ while (children.hasNext()) {
+ OMNodeEx omNode = (OMNodeEx) children.next();
+ omNode.internalSerializeAndConsume(writer);
+ }
+
+One would expect that the effect of this code is to consume the child nodes. However, in Axiom
+1.2.10 this is not the case because `next()` actually builds the node. Note that the code actually
+doesn't make sense because once a child node has been consumed, it is no longer possible to retrieve
+the next sibling. Since in Axiom 1.2.11 the call to `next()` no longer builds the child node, this
+code will indeed trigger an exception.
+
+Another example is the following piece of code which removes all child elements with a given name:
+
+ Iterator iterator = element.getChildrenWithName(qname);
+ while (iterator.hasNext()) {
+ OMElement child = (OMElement)iterator.next();
+ child.detach();
+ }
+
+In Axiom 1.2.10 this works as expected. Indeed, since the iterator stays one node ahead, the current
+node can be safely removed using the `detach()` method. In Axiom 1.2.11, this is no longer the case
+and the following code (which also works with previous versions) should be used instead:
+
+ Iterator iterator = element.getChildrenWithName(qname);
+ while (iterator.hasNext()) {
+ iterator.next();
+ iterator.remove();
+ }
+
+Note that this is actually compatible with the behavior of the Java 2 collection framework, where a
+`ConcurrentModificationException` may be thrown if a thread modifies a collection directly while it
+is iterating over the collection with an iterator.
+
+In Axiom 1.2.12, the iterator implementations have been further improved to detect this situation
+and to throw a `ConcurrentModificationException`. This enables early detection of problematic usages
+of iterators.
Modified: webservices/axiom/trunk/src/site/markdown/release-notes/1.2.12.md
URL: http://svn.apache.org/viewvc/webservices/axiom/trunk/src/site/markdown/release-notes/1.2.12.md?rev=1722938&r1=1722937&r2=1722938&view=diff
==============================================================================
--- webservices/axiom/trunk/src/site/markdown/release-notes/1.2.12.md (original)
+++ webservices/axiom/trunk/src/site/markdown/release-notes/1.2.12.md Mon Jan 4 17:58:54 2016
@@ -1,5 +1,5 @@
Apache Axiom 1.2.12 Release Note
---------------------------------
+================================
Axiom 1.2.12 contains fixes for the following JIRA issues:
Modified: webservices/axiom/trunk/src/site/markdown/release-notes/1.2.13.md
URL: http://svn.apache.org/viewvc/webservices/axiom/trunk/src/site/markdown/release-notes/1.2.13.md?rev=1722938&r1=1722937&r2=1722938&view=diff
==============================================================================
--- webservices/axiom/trunk/src/site/markdown/release-notes/1.2.13.md (original)
+++ webservices/axiom/trunk/src/site/markdown/release-notes/1.2.13.md Mon Jan 4 17:58:54 2016
@@ -1,5 +1,5 @@
Apache Axiom 1.2.13 Release Note
---------------------------------
+================================
Axiom 1.2.13 contains fixes for over thirty [JIRA issues][1] as well as lots of other improvements,
mainly related to XOP/MTOM processing, namespace handling, DOM support, documentation and code
@@ -9,11 +9,134 @@ The most prominent change in 1.2.13 is t
relies on [Apache James Mime4J][2] for XOP/MTOM processing. This was done in order to support
streaming of the content of MIME parts in XOP/MTOM messages: they can now be processed without
writing them to memory or disk first. This also applies to the root/SOAP part, which in previous
-versions was always read into memory before parsing could start.
+versions was always read into memory before parsing could start. For more information, see below.
-For more information about the possible impact on existing application code of the changes
-included in Axiom 1.2.13, please refer to the [user guide][3].
+Changes in this release
+-----------------------
+
+### Handling of illegal namespace declarations
+
+Both XML 1.0 and XML 1.1 forbid binding a namespace prefix to the empty namespace name. Only the
+default namespace can have an empty namespace name. In XML 1.0, prefixed namespace bindings may not
+be empty, as explained in [section 5 of the Namespaces in XML 1.0 specification][3]:
+
+> In a namespace declaration for a prefix (i.e., where the NSAttName is a PrefixedAttName), the
+> attribute value MUST NOT be empty.
+
+In Axiom 1.2.12, the `declareNamespace` methods in `OMElement` didn't enforce this constraint and
+namespace declarations violating this requirement were silently dropped during serialization. This
+behavior is problematic because it may result in subtle issues such as unbound namespace prefixes.
+In Axiom 1.2.13 these methods have been changed so that they throw an exception if an attempt is
+made to bind the empty namespace name to a prefix.
+
+In XML 1.1, prefixed namespace bindings may be empty, but rather than binding the empty namespace
+name to a prefix, such a namespace declaration "undeclares" the prefix, as explained in [section 5
+of the Namespaces in XML 1.1 specification][4]:
+
+> The namespace prefix, unless it is `xml` or `xmlns`, must have been declared in a namespace
+> declaration attribute in either the start-tag of the element where the prefix is used or in an
+> ancestor element (i.e. an element in whose content the prefixed markup occurs). Furthermore, the
+> attribute value in the innermost such declaration must not be an empty string.
+
+Although the same syntax is used in both cases, adding a namespace declaration to bind a prefix to a
+(non empty) namespace URI and adding a namespace declaration to undeclare a prefix are two
+fundamentally different operations from the point of view of the application. Therefore, to support
+prefix undeclaring for XML 1.1 infosets, a new method `undeclarePrefix` has been added to
+`OMElement` in Axiom 1.2.13.
+
+As a corollary of the above, neither XML 1.0 nor XML 1.1 allows creating prefixed elements or
+attributes with an empty namespace name. In Axiom 1.2.12, when attempting to create such invalid
+information items, the behavior was inconsistent: in some cases, the prefix was silently dropped, in
+other cases the invalid information item was actually created, resulting in problems during
+serialization. Axiom 1.2.13 consistently throws an exception when an attempt is made to create such
+an invalid information item.
+
+### OMNamespace normalization
+
+Methods that return an `OMNamespace` object may in principle use two different ways to represent the
+absence of a namespace: as a `null` value or as an `OMNamespace` instance that has both prefix and
+namespaceURI properties set to the empty string. This applies in particular to
+`OMElement#getNamespace()`, `OMElement#getDefaultNamespace()` and `OMAttriute#getNamespace()`. The
+API of Axiom 1.2.12 didn't clearly specify which representation was used, although in most cases a
+`null` value was used. As a consequence application code had to take into account the possibility
+that such methods returned `OMNamespace` instances with an empty prefix and namespace URI.
+
+In Axiom 1.2.13 the situation has been clarified and the aforementioned APIs now always return
+`null` to indicate the absence of a namespace. Note that this may have an impact on flawed
+application code that doesn't handle `null` in the same way as an `OMNamespace` instance with an
+empty prefix and namespace URI. Such application code needs to be fixed to work correctly with Axiom
+1.2.13.
+
+### New abstract APIs
+
+Axiom 1.2.13 introduces a couple of new abstract APIs which give implementations of the Axiom API
+the freedom to do additional optimizations. Application code should be migrated to take advantage of
+these new APIs:
+
+* Instead of instantiating an `OMSource` object directly, `OMContainer#getSAXSource(boolean)`
+ should be used.
+
+* `org.apache.axiom.om.impl.dom.DOOMAbstractFactory` has been deprecated because it ties
+ application code that requires an object model factory supporting DOM to a particular Axiom
+ implementation (DOOM). Instead use `OMAbstractFactory.getMetaFactory(String)` with
+ `OMAbstractFactory.FEATURE_DOM` as parameter value to get a meta factory for an Axiom
+ implementation that supports DOM.
+
+* The `DocumentBuilderFactory` implementation provided by DOOM should no longer be instantiated
+ directly. Instead, application code should request a meta factory for DOM (see previous item),
+ cast it to `DOMMetaFactory` and invoke `newDocumentBuilderFactory` via that interface.
+
+The last two changes imply that `axiom-dom` should no longer be used as a compile time dependency,
+but only as a runtime dependency.
+
+Also note that some of the superseded APIs may disappear in Axiom 1.3.
+
+### Usage of Apache James Mime4J as MIME parser
+
+Starting with version 1.2.13, Axiom uses [Apache James Mime4J][2] as MIME parser implementation
+instead of its own custom parser implementation. The public API as defined by the `Attachments`
+class remains unchanged, with the following exceptions:
+
+* The `getIncomingAttachmentsAsSingleStream` method is no longer supported.
+
+* The `fileThreshold` specified during the construction of the `Attachments` object is now
+ interpreted relative to the size of the decoded content of the attachment instead of the size of
+ the encoded content. Note that this only makes a difference if the attachment has a content
+ transfer encoding other than `binary`.
+
+Several internal classes related to the old MIME parsing code have been removed, are no longer
+public or have been changed in an incompatible way:
+
+* `MIMEBodyPartInputStream`
+* `BoundaryDelimitedStream`
+* `BoundaryPushbackInputStream`
+* `MultipartAttachmentStreams`
+* `PartFactory` and related classes
+
+Although these classes were public, they are not considered part of the public API. Application code
+that depends on these classes needs to be rewritten before upgrading to Axiom 1.2.13.
+
+When upgrading to 1.2.13, projects that use Axiom's XOP/MTOM features must make sure that Apache
+James Mime4J is added to the dependencies. For projects that use Maven (or tools that support Maven
+repositories and metadata) this happens automatically. Projects that use other build tools must
+explicity add the `apache-mime4j-core` library to the list of dependencies.
+
+Axiom uses Mime4J in strict mode. This means that some non conforming MIME messages that would have
+been processed successfully by previous Axiom versions may be rejected by Axiom 1.2.13. Please note
+that Axiom doesn't make any guarantees about its ability to process invalid messages.
+
+### Support for MIME part streaming
+
+Axiom 1.2.13 has support for MIME part streaming. Pre-existing APIs continue to work as documented,
+but there are some minor changes in behavior that may be visible to code that makes assumptions that
+are not covered by the API contract:
+
+* The `DataHandler` instances returned by `Attachments` for MIME parts read from a stream now
+ always implement `DataHandlerExt`, while in 1.2.12 this was only the case for parts buffered
+ using temporary files. For memory buffered MIME parts, a call to `purgeDataSource` has the
+ effect of releasing the allocated memory.
[1]: http://s.apache.org/axiom-changes-1.2.13
[2]: http://james.apache.org/mime4j/
-[3]: ../userguide/ch04.html#changes-1.2.13
+[3]: http://www.w3.org/TR/2009/REC-xml-names-20091208/#ns-using
+[4]: http://www.w3.org/TR/2006/REC-xml-names11-20060816/#ns-using
Modified: webservices/axiom/trunk/src/site/markdown/release-notes/1.2.14.md
URL: http://svn.apache.org/viewvc/webservices/axiom/trunk/src/site/markdown/release-notes/1.2.14.md?rev=1722938&r1=1722937&r2=1722938&view=diff
==============================================================================
--- webservices/axiom/trunk/src/site/markdown/release-notes/1.2.14.md (original)
+++ webservices/axiom/trunk/src/site/markdown/release-notes/1.2.14.md Mon Jan 4 17:58:54 2016
@@ -1,21 +1,38 @@
Apache Axiom 1.2.14 Release Note
---------------------------------
+================================
Axiom 1.2.14 contains fixes for more than twenty [JIRA issues][1] as well as lots of other
improvements.
-Users upgrading to 1.2.14 should take into account the following changes:
+Changes in this release
+-----------------------
-* Axiom now uses Woodstox 4.1.x as StAX implementation (although 3.2.x and 4.0.x are still
- supported).
+### Upgrade of Woodstox
-* `OMFactory` implementations for DOOM are now stateless.
-
-* Several deprecated classes have been moved to a new JAR file named `axiom-compat` and are no
- longer included in the core artifacts (`axiom-api`, `axiom-impl` and `axiom-dom`).
-
-For more information about the possible impact on existing application code of these changes,
-please refer to the [user guide][2].
+Woodstox 3.2.x is no longer maintained. Starting with version 1.2.14, Axiom depends on Woodstox
+4.1.x, although using 3.2.x (and 4.0.x) is still supported. This may have an impact on projects that
+use Maven, because the artifact ID used by Woodstox changed from `wstx-asl` to `woodstox-core-asl`.
+These projects may need to update their dependencies to avoid depending on two different versions of
+Woodstox.
+
+### DOOM factories are now stateless
+
+In contrast to previous versions, the `OMFactory` implementations for DOOM are stateless in Axiom
+1.2.14. This makes it easier to write application code that is portable between LLOM and DOOM (in
+the sense that code that is known to work with LLOM will usually work with DOOM without changes).
+However, this slightly changes the behavior of DOOM with respect to owner documents, which means
+that in some cases existing code written for DOOM may trigger `WRONG_DOCUMENT_ERR` exceptions if it
+uses the DOM API on a tree created or manipulated using the Axiom API.
+
+For more information about the new semantics, refer to the Javadoc of `DOMMetaFactory` and to
+[AXIOM-412][2].
+
+### Removal of deprecated classes from core artifacts
+
+Several deprecated classes have been moved to a new JAR file named `axiom-compat` and are no longer
+included in the core artifacts (`axiom-api`, `axiom-impl` and `axiom-dom`). If you rely on these
+deprecated classes or get `NoClassDefFoundError`s after upgrading to Axiom 1.2.14, then you need to
+add this new JAR to your project's dependencies.
[1]: http://s.apache.org/axiom-changes-1.2.14
-[2]: ../userguide/ch04.html#changes-1.2.14
+[2]: https://issues.apache.org/jira/browse/AXIOM-412
Modified: webservices/axiom/trunk/src/site/markdown/release-notes/1.2.15.md
URL: http://svn.apache.org/viewvc/webservices/axiom/trunk/src/site/markdown/release-notes/1.2.15.md?rev=1722938&r1=1722937&r2=1722938&view=diff
==============================================================================
--- webservices/axiom/trunk/src/site/markdown/release-notes/1.2.15.md (original)
+++ webservices/axiom/trunk/src/site/markdown/release-notes/1.2.15.md Mon Jan 4 17:58:54 2016
@@ -1,14 +1,43 @@
Apache Axiom 1.2.15 Release Note
---------------------------------
+================================
Axiom 1.2.15 ships fixes for over a dozen [JIRA issues][1] and contains many other improvements,
mainly related to consistency between the LLOM and DOOM implementations and how serialization is
performed. In particular the builder is now able to continue building the Axiom tree after an
element has been consumed (see [AXIOM-288][2]).
-For information about other changes and their potential impact, please refer to the [user
-guide][3].
+Changes in this release
+-----------------------
+
+### Removal of the JavaMail dependency
+
+Axiom 1.2.15 no longer uses JavaMail and the corresponding dependency has been removed. If your
+project relies on Axiom to introduce JavaMail as a transitive dependency, you need to update your
+build.
+
+### Serialization changes
+
+In previous Axiom versions, the `serialize` and `serializeAndConsume` methods skipped empty SOAP
+`Header` elements. On the other hand, such elements would still appear in the representations
+produced by `getXMLStreamReader` and `getSAXSource`. For consistency, starting with Axiom 1.2.15,
+SOAP `Header` elements are always serialized. This may change the output of existing code,
+especially code that uses the `getDefaultEnvelope()` defined by `SOAPFactory`. However, it is
+expected that this will not break anything because empty SOAP `Header` elements should be ignored by
+the receiver.
+
+To avoid producing empty `Header` elements, projects should switch from using `getDefaultEnvelope()`
+(in `SOAPFactory`) and `getHeader()` (in `SOAPEnvelope`) to using `createDefaultSOAPMessage()` and
+`getOrCreateHeader()`.
+
+For more information, see [AXIOM-430][3].
+
+### Introduction of AspectJ
+
+The implementation JARs (`axiom-impl` and `axiom-dom`) are now built with [AspectJ][4] (to reduce
+source code duplication) and contain a small subset of classes from the AspectJ runtime library.
+There is a small risk that this may cause conflicts with other code that uses AspectJ.
[1]: http://s.apache.org/axiom-changes-1.2.15
[2]: https://issues.apache.org/jira/browse/AXIOM-288
-[3]: ../userguide/ch04.html#changes-1.2.15
+[3]: https://issues.apache.org/jira/browse/AXIOM-430
+[4]: https://eclipse.org/aspectj/
Modified: webservices/axiom/trunk/src/site/markdown/release-notes/1.2.16.md
URL: http://svn.apache.org/viewvc/webservices/axiom/trunk/src/site/markdown/release-notes/1.2.16.md?rev=1722938&r1=1722937&r2=1722938&view=diff
==============================================================================
--- webservices/axiom/trunk/src/site/markdown/release-notes/1.2.16.md (original)
+++ webservices/axiom/trunk/src/site/markdown/release-notes/1.2.16.md Mon Jan 4 17:58:54 2016
@@ -1,5 +1,5 @@
Apache Axiom 1.2.16 Release Note
---------------------------------
+================================
Axiom 1.2.16 comes with the following new features:
@@ -13,7 +13,8 @@ In addition, the sources can now be buil
A list of other issues fixed in this release can be found [here][2].
-### Changes in this release
+Changes in this release
+-----------------------
* The semantics of the `OMInformationItem#getOMFactory()` method have slightly changed in Axiom
1.2.16. In previous versions, `getOMFactory()` returned the `OMFactory` instance that was used
Modified: webservices/axiom/trunk/src/site/markdown/release-notes/1.2.17.md
URL: http://svn.apache.org/viewvc/webservices/axiom/trunk/src/site/markdown/release-notes/1.2.17.md?rev=1722938&r1=1722937&r2=1722938&view=diff
==============================================================================
--- webservices/axiom/trunk/src/site/markdown/release-notes/1.2.17.md (original)
+++ webservices/axiom/trunk/src/site/markdown/release-notes/1.2.17.md Mon Jan 4 17:58:54 2016
@@ -1,5 +1,5 @@
Apache Axiom 1.2.17 Release Note
---------------------------------
+================================
Axiom 1.2.17 is a maintenance release that contains fixes for [AXIOM-476][1] and
[AXIOM-477][2]. There are no other significant changes in this release.
Modified: webservices/axiom/trunk/src/site/markdown/release-notes/1.2.9.md
URL: http://svn.apache.org/viewvc/webservices/axiom/trunk/src/site/markdown/release-notes/1.2.9.md?rev=1722938&r1=1722937&r2=1722938&view=diff
==============================================================================
--- webservices/axiom/trunk/src/site/markdown/release-notes/1.2.9.md (original)
+++ webservices/axiom/trunk/src/site/markdown/release-notes/1.2.9.md Mon Jan 4 17:58:54 2016
@@ -1,5 +1,5 @@
Apache Axiom 1.2.9 Release Note
--------------------------------
+================================
Note: Starting with release 1.2.9, Axiom requires Java 1.5. While the API is
still compatible with Java 1.4, Axiom relies on classes from the Java 1.5
@@ -70,3 +70,67 @@ Resolved JIRA issues:
* WSCOMMONS-417 Clarify the status of the JavaMail dependency
* WSCOMMONS-414 Namespace issue in SOAP message generated
* WSCOMMONS-111 Careless exception handling needs to be fixed
+
+Changes in this release
+-----------------------
+
+### System properties used by OMAbstractFactory
+
+Prior to Axiom 1.2.9, `OMAbstractFactory` used system properties as defined in the following table
+to determine the factory implementations to use:
+
+Object model | Method | System property | Default
+------------ | -------------------- | ---------------- | ---------------------------------------------------------------
+Plain XML | `getOMFactory()` | `om.factory` | `org.apache.axiom.om.impl.llom.factory.OMLinkedListImplFactory`
+SOAP 1.1 | `getSOAP11Factory()` | `soap11.factory` | `org.apache.axiom.soap.impl.llom.soap11.SOAP11Factory`
+SOAP 1.2 | `getSOAP12Factory()` | `soap12.factory` | `org.apache.axiom.soap.impl.llom.soap12.SOAP12Factory`
+
+This in principle allowed to mix default factory implementations from different implementations of
+the Axiom API (e.g. an `OMFactory` from the LLOM implementation and SOAP factories from DOOM). This
+however doesn't make sense. The system properties as described above are no longer supported in
+1.2.9 and the default Axiom implementation is chosen using the new
+`org.apache.axiom.om.OMMetaFactory` system property. For LLOM, you should set:
+
+ org.apache.axiom.om.OMMetaFactory=org.apache.axiom.om.impl.llom.factory.OMLinkedListMetaFactory
+
+This is the default and is equivalent to the defaults in 1.2.8. For DOOM, you should set:
+
+ org.apache.axiom.om.OMMetaFactory=org.apache.axiom.om.impl.dom.factory.OMDOMMetaFactory
+
+### Factories returned by StAXUtils
+
+In versions prior to 1.2.9, the `XMLInputFactory` and `XMLOutputFactory` instances returned by
+`StAXUtils` were mutable, i.e. it was possible to change the properties of these factories. This is
+obviously an issue since the factory instances are cached and can be shared among several thread. To
+avoid programming errors, starting from 1.2.9, the factories are immutable and any attempt to change
+their state will result in an `IllegalStateException`.
+
+Note that the possibility to change the properties of these factories could be used to apply
+application wide settings. Starting with 1.2.9, Axiom has a proper mechanism to allow this.
+This feature is described in the [user guide][1].
+
+### Changes in XOP/MTOM handling
+
+In Axiom 1.2.8, `XMLStreamReader` instances provided by Axiom could belong to one of three different
+categories:
+
+1. `XMLStreamReader` instances delivering plain XML.
+
+2. `XMLStreamReader` instances delivering plain XML and implementing a custom extension to retrieve
+ optimized binary data.
+
+3. `XMLStreamReader` instances representing XOP encoded data.
+
+As explained in [AXIOM-255][2] and [AXIOM-122][3], in Axiom 1.2.8, the type of stream reader
+provided by the API was not always well defined. Sometimes the type of the stream reader even
+depended on the state of the Axiom tree (i.e. whether some part of it has been accessed or not).
+
+In release 1.2.9 the behavior of Axiom was changed such that it never delivers XOP encoded data
+unless explicitly requested to do so. By default, any `XMLStreamReader` provided by Axiom now
+represents plain XML data and optionally implements the `DataHandlerReader` extension to retrieve
+optimized binary data. An XOP encoded stream can be requested from the `getXOPEncodedStream` method
+in `XOPUtils`.
+
+[1]: ../userguide/ch04.html#factory.properties
+[2]: https://issues.apache.org/jira/browse/AXIOM-255
+[3]: https://issues.apache.org/jira/browse/AXIOM-122
Modified: webservices/axiom/trunk/userguide/src/docbkx/userguide.xml
URL: http://svn.apache.org/viewvc/webservices/axiom/trunk/userguide/src/docbkx/userguide.xml?rev=1722938&r1=1722937&r2=1722938&view=diff
==============================================================================
--- webservices/axiom/trunk/userguide/src/docbkx/userguide.xml (original)
+++ webservices/axiom/trunk/userguide/src/docbkx/userguide.xml Mon Jan 4 17:58:54 2016
@@ -1035,497 +1035,14 @@ with CRLF</root>]]></screen>
<section>
<title>Migrating from older Axiom versions</title>
<para>
- This section provides information about changes in Axiom that might impact existing
- code when migrating from an older version of Axiom. Note that this section is not
+ The release notes provide information about changes in Axiom that might impact existing
+ code when migrating from an older version of Axiom. Note that they are not
meant as a change log that lists all changes or new features. Also, before upgrading
to a newer Axiom version, you should always check if your code uses methods or classes
that have been deprecated. You should fix all deprecation warnings before changing the
Axiom version. In general the Javadoc of the deprecated class or method gives you
a hint on how to change your code.
</para>
- <section>
- <title>Changes in Axiom 1.2.9</title>
- <section>
- <title>System properties used by <classname>OMAbstractFactory</classname></title>
- <para>
- Prior to Axiom 1.2.9, <classname>OMAbstractFactory</classname> used system properties
- as defined in the following table to determine the factory implementations to use:
- </para>
- <segmentedlist>
- <?dbhtml list-presentation="table"?>
- <segtitle>Object model</segtitle>
- <segtitle>Method</segtitle>
- <segtitle>System property</segtitle>
- <segtitle>Default</segtitle>
- <seglistitem>
- <seg>Plain XML</seg>
- <seg><methodname>getOMFactory()</methodname></seg>
- <seg><varname>om.factory</varname></seg>
- <seg><literal>org.apache.axiom.om.impl.llom.factory.OMLinkedListImplFactory</literal></seg>
- </seglistitem>
- <seglistitem>
- <seg>SOAP 1.1</seg>
- <seg><methodname>getSOAP11Factory()</methodname></seg>
- <seg><varname>soap11.factory</varname></seg>
- <seg><literal>org.apache.axiom.soap.impl.llom.soap11.SOAP11Factory</literal></seg>
- </seglistitem>
- <seglistitem>
- <seg>SOAP 1.2</seg>
- <seg><methodname>getSOAP12Factory()</methodname></seg>
- <seg><varname>soap12.factory</varname></seg>
- <seg><literal>org.apache.axiom.soap.impl.llom.soap12.SOAP12Factory</literal></seg>
- </seglistitem>
- </segmentedlist>
- <para>
- This in principle allowed to mix default factory implementations from different implementations
- of the Axiom API (e.g. an OMFactory from the LLOM implementation and SOAP factories from DOOM).
- This however doesn't make sense. The system properties as described above are no longer
- supported in 1.2.9 and the default Axiom implementation is chosen using the new
- <varname>org.apache.axiom.om.OMMetaFactory</varname> system property. For LLOM, you should set:
- </para>
-<programlisting><?db-font-size 70%?>org.apache.axiom.om.OMMetaFactory=org.apache.axiom.om.impl.llom.factory.OMLinkedListMetaFactory</programlisting>
- <para>
- This is the default and is equivalent to the defaults in 1.2.8. For DOOM, you should set:
- </para>
-<programlisting><?db-font-size 70%?>org.apache.axiom.om.OMMetaFactory=org.apache.axiom.om.impl.dom.factory.OMDOMMetaFactory</programlisting>
- </section>
- <section>
- <title>Factories returned by <classname>StAXUtils</classname></title>
- <para>
- In versions prior to 1.2.9, the <classname>XMLInputFactory</classname> and
- <classname>XMLOutputFactory</classname> instances returned by <classname>StAXUtils</classname>
- were mutable, i.e. it was possible to change the properties of these factories. This is obviously
- an issue since the factory instances are cached and can be shared among several thread.
- To avoid programming errors, starting from 1.2.9, the factories are immutable and any attempt to
- change their state will result in an <classname>IllegalStateException</classname>.
- </para>
- <para>
- Note that the possibility to change the properties of these factories could be used to apply
- application wide settings. Starting with 1.2.9, Axiom has a proper mechanism to allow this.
- This feature is described in <xref linkend="factory.properties"/>.
- </para>
- </section>
- <section>
- <title>Changes in XOP/MTOM handling</title>
- <para>
- In Axiom 1.2.8, <classname>XMLStreamReader</classname> instances provided by Axiom could
- belong to one of three different categories:
- </para>
- <orderedlist>
- <listitem>
- <para>
- <classname>XMLStreamReader</classname> instances delivering plain XML.
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>XMLStreamReader</classname> instances delivering plain XML and
- implementing a custom extension to retrieve optimized binary data.
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>XMLStreamReader</classname> instances representing XOP
- encoded data.
- </para>
- </listitem>
- </orderedlist>
- <para>
- As explained in <link xlink:href="https://issues.apache.org/jira/browse/AXIOM-255">AXIOM-255</link>
- and <link xlink:href="https://issues.apache.org/jira/browse/AXIOM-122">AXIOM-122</link>,
- in Axiom 1.2.8, the type of stream reader provided by the API was not always well defined.
- Sometimes the type of the stream reader even depended on the state of the Axiom tree
- (i.e. whether some part of it has been accessed or not).
- </para>
- <para>
- In release 1.2.9 the behavior of Axiom was changed such that it never delivers XOP
- encoded data unless explicitly requested to do so. By default, any <classname>XMLStreamReader</classname>
- provided by Axiom now represents plain XML data and optionally implements the
- <classname>DataHandlerReader</classname> extension to retrieve optimized
- binary data. An XOP encoded stream can be requested from the <methodname>getXOPEncodedStream</methodname>
- method in <classname>XOPUtils</classname>.
- </para>
- </section>
- </section>
- <section xml:id="changes-1.2.11">
- <title>Changes in Axiom 1.2.11</title>
- <section xml:id="OMXMLBuilderFactory">
- <title>Resurrection of the <classname>OMXMLBuilderFactory</classname> API</title>
- <para>
- Historically, <classname>org.apache.axiom.om.impl.llom.factory.OMXMLBuilderFactory</classname> was used to
- create Axiom trees from XML documents. Unfortunately, this class is located in the wrong package and JAR
- (it is implementation independent but belongs to LLOM). In Axiom 1.2.10, the standard way to create an Axiom tree
- was therefore to instantiate <classname>StAXOMBuilder</classname> or one of its subclasses directly. However, this
- is not optimal for two reasons:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- It relies on the assumption that every implementation of the Axiom API necessarily uses
- <classname>StAXOMBuilder</classname>. This means that an implementation doesn't have the freedom to
- provide its own builder implementation (e.g. in order to implement some special optimizations).
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>StAXOMBuilder</classname> and its subclasses belong to packages which have
- <literal>impl</literal> in their names. This tends to blur the distinction between the public
- API and internal implementation classes.
- </para>
- </listitem>
- </itemizedlist>
- <para>
- Therefore, in Axiom 1.2.11, a new abstract API for creating builder instances was introduced.
- It is again called <classname>OMXMLBuilderFactory</classname>, but located in the
- <package>org.apache.axiom.om</package> package. The methods defined by this new API are similar
- to the ones in the original (now deprecated) <classname>OMXMLBuilderFactory</classname>, so that
- migration should be easy.
- </para>
- </section>
- <section xml:id="iterator-changes">
- <title>Changes in the behavior of certain iterators</title>
- <para>
- In Axiom 1.2.10 and previous versions, iterators returned by methods such as <methodname>OMIterator#getChildren()</methodname>
- internally stayed one step ahead of the node returned by the <methodname>next()</methodname> method.
- This meant that sometimes, using such an iterator had the side effect of building elements that
- were not intended to be built.
- In Axiom 1.2.11 this behavior was changed such that <methodname>next()</methodname> no longer builds the nodes
- it returns. In a few cases, this change may cause issues in existing code. One known instance
- is the following construct (which was used internally by Axiom itself):
- </para>
-<programlisting>while (children.hasNext()) {
- OMNodeEx omNode = (OMNodeEx) children.next();
- omNode.internalSerializeAndConsume(writer);
-}</programlisting>
- <para>
- One would expect that the effect of this code is to consume the child nodes. However, in Axiom 1.2.10 this
- is not the case because <methodname>next()</methodname> actually builds the node.
- Note that the code actually doesn't make sense because once a child node has been consumed, it is
- no longer possible to retrieve the next sibling. Since in Axiom 1.2.11 the call to <methodname>next()</methodname>
- no longer builds the child node, this code will indeed trigger an exception.
- </para>
- <para>
- Another example is the following piece of code which removes all child elements with a given name:
- </para>
-<programlisting>Iterator iterator = element.getChildrenWithName(qname);
-while (iterator.hasNext()) {
- OMElement child = (OMElement)iterator.next();
- child.detach();
-}</programlisting>
- <para>
- In Axiom 1.2.10 this works as expected. Indeed, since the iterator stays one node ahead, the current
- node can be safely removed using the <methodname>detach()</methodname> method.
- In Axiom 1.2.11, this is no longer the case and the following code (which also works
- with previous versions) should be used instead:
- </para>
-<programlisting>Iterator iterator = element.getChildrenWithName(qname);
-while (iterator.hasNext()) {
- iterator.next();
- iterator.remove();
-}</programlisting>
- <para>
- Note that this is actually compatible with the behavior of the Java 2 collection framework, where
- a <classname>ConcurrentModificationException</classname> may be thrown if a thread modifies a
- collection directly while it is iterating over the collection with an iterator.
- </para>
- <para>
- In Axiom 1.2.12, the iterator implementations have been further improved to detect this situation
- and to throw a <classname>ConcurrentModificationException</classname>. This enables early detection
- of problematic usages of iterators.
- </para>
- </section>
- </section>
- <section xml:id="changes-1.2.13">
- <title>Changes in Axiom 1.2.13</title>
- <section>
- <title>Handling of illegal namespace declarations</title>
- <para>
- Both XML 1.0 and XML 1.1 forbid binding a namespace prefix to the empty namespace name.
- Only the default namespace can have an empty namespace name.
- In XML 1.0, prefixed namespace bindings may not be empty, as explained in section 5 of
- <xref linkend="bib.xmlns"/>:
- </para>
- <blockquote>
- <para>
- In a namespace declaration for a prefix (i.e., where the NSAttName is a PrefixedAttName), the
- attribute value MUST NOT be empty.
- </para>
- </blockquote>
- <para>
- In Axiom 1.2.12, the <methodname>declareNamespace</methodname> methods in <classname>OMElement</classname>
- didn't enforce this constraint and namespace declarations violating this requirement were silently
- dropped during serialization. This behavior is problematic because it may result in subtle issues
- such as unbound namespace prefixes. In Axiom 1.2.13 these methods have been changed so that they
- throw an exception if an attempt is made to bind the empty namespace name to a prefix.
- </para>
- <para>
- In XML 1.1, prefixed namespace bindings may be empty, but rather than binding the empty namespace name
- to a prefix, such a namespace declaration "undeclares" the prefix, as explained in section 5
- of <xref linkend="bib.xmlns11"/>:
- </para>
- <blockquote>
- <para>
- The namespace prefix, unless it is <literal>xml</literal> or <literal>xmlns</literal>, must
- have been declared in a namespace declaration attribute in either the start-tag of the
- element where the prefix is used or in an ancestor element
- (i.e. an element in whose content the prefixed markup occurs). Furthermore, the attribute
- value in the innermost such declaration must not be an empty string.
- </para>
- </blockquote>
- <para>
- Although the same syntax is used in both cases, adding a namespace declaration to bind a prefix
- to a (non empty) namespace URI and adding a namespace declaration to undeclare a prefix are two
- fundamentally different operations from the point of view of the application. Therefore, to
- support prefix undeclaring for XML 1.1 infosets, a new method <methodname>undeclarePrefix</methodname>
- has been added to <classname>OMElement</classname> in Axiom 1.2.13.
- </para>
- <para>
- As a corollary of the above, neither XML 1.0 nor XML 1.1 allows creating prefixed elements or
- attributes with an empty namespace name. In Axiom 1.2.12, when attempting to create such invalid
- information items, the behavior was inconsistent: in some cases,
- the prefix was silently dropped, in other cases the invalid information item was actually created,
- resulting in problems during serialization. Axiom 1.2.13 consistently throws an exception when
- an attempt is made to create such an invalid information item.
- </para>
- </section>
- <section>
- <title><classname>OMNamespace</classname> normalization</title>
- <para>
- Methods that return an <classname>OMNamespace</classname> object may in principle use two different
- ways to represent the absence of a namespace: as a <literal>null</literal> value or as an
- <classname>OMNamespace</classname> instance that has both prefix and namespaceURI properties set to
- the empty string. This applies in particular to <methodname>OMElement#getNamespace()</methodname>,
- <methodname>OMElement#getDefaultNamespace()</methodname> and <methodname>OMAttriute#getNamespace()</methodname>.
- The API of Axiom 1.2.12 didn't clearly specify which representation was used,
- although in most cases a <literal>null</literal> value was used. As a consequence application code
- had to take into account the possibility that such methods returned <classname>OMNamespace</classname>
- instances with an empty prefix and namespace URI.
- </para>
- <para>
- In Axiom 1.2.13 the situation has been clarified and the aforementioned APIs now always return
- <literal>null</literal> to indicate the absence of a namespace. Note that this
- may have an impact on flawed application code that doesn't handle <literal>null</literal> in the same
- way as an <classname>OMNamespace</classname> instance with an empty prefix and namespace URI.
- Such application code needs to be fixed to work correctly with Axiom 1.2.13.
- </para>
- </section>
- <section>
- <title>New abstract APIs</title>
- <para>
- Axiom 1.2.13 introduces a couple of new abstract APIs which give implementations of the Axiom API
- the freedom to do additional optimizations. Application code should be migrated to take
- advantage of these new APIs:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Instead of instantiating a <classname>OMSource</classname> object directly,
- <methodname>OMContainer#getSAXSource(boolean)</methodname> should be used.
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>org.apache.axiom.om.impl.dom.DOOMAbstractFactory</classname> has been deprecated
- because it ties application code that requires an object model factory supporting DOM to
- a particular Axiom implementation (DOOM). Instead use <methodname>OMAbstractFactory.getMetaFactory(String)</methodname>
- with <literal>OMAbstractFactory.FEATURE_DOM</literal> as parameter value to get a meta factory
- for an Axiom implementation that supports DOM.
- </para>
- </listitem>
- <listitem>
- <para>
- The <classname>DocumentBuilderFactory</classname> implementation provided by DOOM should no
- longer be instantiated directly. Instead, application code should request a meta factory for
- DOM (see previous item), cast it to <classname>DOMMetaFactory</classname> and invoke
- <methodname>newDocumentBuilderFactory</methodname> via that interface.
- </para>
- </listitem>
- </itemizedlist>
- <tip>
- <para>
- The last two changes imply that <literal>axiom-dom</literal> should no longer be used as a
- compile time dependency, but only as a runtime dependency.
- </para>
- </tip>
- <para>
- Note that some of the superseded APIs may disappear in Axiom 1.3.
- </para>
- </section>
- <section>
- <title>Usage of Apache James Mime4J as MIME parser</title>
- <para>
- Starting with version 1.2.13, Axiom uses <link xlink:href="http://james.apache.org/mime4j/">Apache
- James Mime4J</link> as MIME parser implementation instead of its own custom parser
- implementation. The public API as defined by the <classname>Attachments</classname> class
- remains unchanged, with the following exceptions:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The <methodname>getIncomingAttachmentsAsSingleStream</methodname> method is no longer
- supported.
- </para>
- </listitem>
- <listitem>
- <para>
- The <literal>fileThreshold</literal> specified during the construction of the
- <classname>Attachments</classname> object is now interpreted relative to the size of the decoded
- content of the attachment instead of the size of the encoded content. Note that
- this only makes a difference if the attachment has a content transfer encoding other
- than <literal>binary</literal>.
- </para>
- </listitem>
- </itemizedlist>
- <para>
- Several internal classes related to the old MIME parsing code have been removed, are
- no longer public or have been changed in an incompatible way:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <classname>MIMEBodyPartInputStream</classname>
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>BoundaryDelimitedStream</classname>
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>BoundaryPushbackInputStream</classname>
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>MultipartAttachmentStreams</classname>
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>PartFactory</classname> and related classes
- </para>
- </listitem>
- </itemizedlist>
- <para>
- Although these classes were public, they are not considered part of the public API.
- Application code that depends on these classes needs to be rewritten before upgrading
- to Axiom 1.2.13.
- </para>
- <para>
- When upgrading to 1.2.13, projects that use Axiom's XOP/MTOM features must make sure
- that Apache James Mime4J is added to the dependencies. For projects that use Maven
- (or tools that support Maven repositories and metadata) this happens automatically.
- Projects that use other build tools must explicity add the <filename>apache-mime4j-core</filename>
- library to the list of dependencies.
- </para>
- <para>
- Axiom uses Mime4J in strict mode. This means that some non conforming MIME messages
- that would have been processed successfully by previous Axiom versions may be rejected by
- Axiom 1.2.13. Please note that Axiom doesn't make any guarantees about its ability to process
- invalid messages.
- </para>
- </section>
- <section>
- <title>Support for MIME part streaming</title>
- <para>
- Axiom 1.2.13 has support for MIME part streaming. Pre-existing APIs continue to work
- as documented, but there are some minor changes in behavior that may be visible to
- code that makes assumptions that are not covered by the API contract:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The <classname>DataHandler</classname> instances returned by <classname>Attachments</classname>
- for MIME parts read from a stream now always implement <classname>DataHandlerExt</classname>, while
- in 1.2.12 this was only the case for parts buffered using temporary files. For memory buffered
- MIME parts, a call to <methodname>purgeDataSource</methodname> has the effect of releasing the
- allocated memory.
- </para>
- </listitem>
- </itemizedlist>
- </section>
- </section>
- <section xml:id="changes-1.2.14">
- <title>Changes in Axiom 1.2.14</title>
- <section>
- <title>Upgrade of Woodstox</title>
- <para>
- Woodstox 3.2.x is no longer maintained. Starting with version 1.2.14, Axiom depends on Woodstox 4.1.x,
- although using 3.2.x (and 4.0.x) is still supported. This may have an impact on projects that use
- Maven, because the artifact ID used by Woodstox changed from <literal>wstx-asl</literal> to
- <literal>woodstox-core-asl</literal>. These projects may need to update their dependencies
- to avoid depending on two different versions of Woodstox.
- </para>
- </section>
- <section>
- <title>DOOM factories are now stateless</title>
- <para>
- In contrast to previous versions, the <classname>OMFactory</classname> implementations for DOOM are
- stateless in Axiom 1.2.14. This makes it easier to write application code that is portable between
- LLOM and DOOM (in the sense that code that is known to work with LLOM will usually work with DOOM without
- changes). However, this slightly changes the behavior of DOOM with respect to owner documents, which means that
- in some cases existing code written for DOOM may trigger <literal>WRONG_DOCUMENT_ERR</literal> exceptions
- if it uses the DOM API on a tree created or manipulated using the Axiom API.
- </para>
- <para>
- For more information about the new semantics, refer to the Javadoc of <classname>DOMMetaFactory</classname>
- and to <link xlink:href="https://issues.apache.org/jira/browse/AXIOM-412">AXIOM-412</link>.
- </para>
- </section>
- <section>
- <title>Removal of deprecated classes from core artifacts</title>
- <para>
- Several deprecated classes have been moved to a new JAR file named <filename>axiom-compat</filename> and are
- no longer included in the core artifacts (<filename>axiom-api</filename>, <filename>axiom-impl</filename>
- and <filename>axiom-dom</filename>). If you rely on these deprecated classes or get <classname>NoClassDefFoundError</classname>s
- after upgrading to Axiom 1.2.14, then you need to add this new JAR to your project's dependencies.
- </para>
- </section>
- </section>
- <section xml:id="changes-1.2.15">
- <title>Changes in Axiom 1.2.15</title>
- <section>
- <title>Removal of the JavaMail dependency</title>
- <para>
- Axiom 1.2.15 no longer uses JavaMail and the corresponding dependency has
- been removed. If your project relies on Axiom to introduce JavaMail as a
- transitive dependency, you need to update your build.
- </para>
- </section>
- <section>
- <title>Serialization changes</title>
- <para>
- In previous Axiom versions, the <methodname>serialize</methodname> and <methodname>serializeAndConsume</methodname>
- methods skipped empty SOAP <tag class="element">Header</tag> elements. On the other hand, such elements would still
- appear in the representations produced by <methodname>getXMLStreamReader</methodname> and
- <methodname>getSAXSource</methodname>.
- For consistency, starting with Axiom 1.2.15, SOAP <tag class="element">Header</tag> elements are always serialized.
- This may change the output of existing code, especially code that uses the <methodname>getDefaultEnvelope()</methodname>
- defined by <classname>SOAPFactory</classname>.
- However, it is expected that this will not break anything because empty SOAP <tag class="element">Header</tag> elements
- should be ignored by the receiver.
- </para>
- <para>
- To avoid producing empty <tag class="element">Header</tag> elements, projects should switch from using
- <methodname>getDefaultEnvelope()</methodname> (in <classname>SOAPFactory</classname>)
- and <methodname>getHeader()</methodname> (in <classname>SOAPEnvelope</classname>)
- to using <methodname>createDefaultSOAPMessage()</methodname> and <methodname>getOrCreateHeader()</methodname>.
- </para>
- <para>
- For more information, see <link xlink:href="https://issues.apache.org/jira/browse/AXIOM-430">AXIOM-430</link>.
- </para>
- </section>
- <section>
- <title>Introduction of AspectJ</title>
- <para>
- The implementation JARs (<filename>axiom-impl</filename> and <filename>axiom-dom</filename>) are now built with
- <link xlink:href="https://eclipse.org/aspectj/">AspectJ</link> (to reduce source code duplication) and contain a
- small subset of classes from the AspectJ runtime library. There is a small risk that this may cause conflicts with
- other code that uses AspectJ.
- </para>
- </section>
- </section>
</section>
</chapter>