Migrating from Apache Neethi 2 to 3

Neethi 3 is a major upgrade from Neethi 2 providing several new features and enhanced capabilities. While effort was made to make it easy to transition from Neeth 2 to Neethi 3, some changes are required.

• Java 5 collections - all the collections and iterators have been updated to specify the proper types they contain. Upgrading to Neethi 3 will likely require proper typing in existing code to reduce warnings.
• Assertion.isIgnorable() - to support WS-Policy 1.5, an isIgnorable method was added to the Assertion interface and any policy assertions that implement that interface must be updated to add that method. In addition, it is recommend that all AssertionBuilders builders be updated to look for the ignorable attribute and set it appropriately.
• AssertionBuilders - AssertionBuilders are no longer tied to Axiom. The AssertionBuilder interface is now typed to specify the object model the builder expects for the first parameter for the build method. The type can be any type for which there is a Converter registered. By default, there are converters for DOM Elements and XMLStreamReaders. If the Axiom jars are available, there are Converters for OMElement as well. The easiest migration path is to make your builders implement "AssertionBuilderOMElement".
• The default assertion implement has changed. In 2.x, the default implementation was the XmlPrimitiveAssertion which just wrappered the OMElement. With 3.x, the default depends on the assertion being built. If its a single element with either no content or text content, it will be a PrimitiveAssertion. If it contains a single child Policy element, it will be a PolicyContainingPrimitiveAssertion. Otherwise it will be a XmlPrimitiveAssertion. These changes to the default assertions allows the runtime to know more about the policy so methods like intersect could be added.
• Two new interfaces were added that Assertions can (optionally) implement. The PolicyContainingAssertion interface is used to mark assertions that contain an internal Policy. This allows the normalization and intersect operations to examine the internal policy as well. The IntersectableAssertion interface adds methods that an Assertion can override algorithms in the intersection process to provide custom behavoir. For example, per spec, the intersection algorithm should not consider attributes. However, an application internal policy may want to consider them for various reasons.