I agree with the analysis and like the proposed solution, but I think that OMImplementation not being an interface will cause problems in the OSGI case as it injects instances of a declared interface.
We could add an additional interface that OMImplementation implements, or perhaps you know that OSGI sill support the abstract class? WDYT? David On Mon, Feb 9, 2009 at 9:50 AM, Andreas Veithen <[email protected]> wrote: > All, > > I had a look at David's OSGIification changes in Axiom. I think that > the underlying factory mechanism in Axiom should be simplified and > improved and this would also make the OSGi injection much simpler. > Indeed (independently of the OSGi question), the current > implementation of the factories in Axiom has a number of issues: > > 1) There are currently three independent factories (1 x OMFactory and > 2 x SOAPFactory) and their implementations are specified by three > system properties. I think that in general it would not make sense 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). Instead of having system properties for the > individual factories, it would make much more sense to have just one > system property specifying the concrete API implementation to use by > default. > > 2) As explained in the Javadoc [1], the current implementation of > OMAbstractFactory doesn't take into account the lifecycle requirements > for the factory implementations: while LLOM factories are stateless > (implying that the same instance can be used to build any number of > documents), with DOOM, a new factory instance must be created for each > document. > > 3) There is code that needs to work with different API implementations > chosen at runtime (where switching using system properties is not > possible). With the current mechanism (more precisely with Axiom > version prior to 1.2.8; see below), this requires to pass all three > factory instances to the code (at least if the code uses SOAP), which > is quite cumbersome. > > In order to overcome these issues (primarily the last one), in 1.2.8 I > introduced a new class called OMImplementation [2] which can be best > described as a meta factory: it is a factory for OMFactory and > SOAPFactory instances. My proposal would be to redesign the existing > factory mechanism around this class. This can be done in a backward > compatible way. For this we would > > * implement a static getInstance() method on OMImplementation that (in > a non OSGi environment) loads the implementation based on a system > property (with LLOM as default); > * change OMAbstractFactory to delegate to the default OMImplementation > instance. > > The existing OMImplementation code already solves issue 3 (and is used > to implement reusable unit tests). The extensions described above > would obviously address issue 1. They also solve issue 2 because > OMImplementation is lifecycle-aware (i.e. the implementation may > choose to always return the same factory instance or a new one on > every invocation). Finally, this would simplify the OSGi issue because > there will be only a single component (instead of three) to inject. > > WDYT? > > Andreas > > [1] > http://ws.apache.org/commons/axiom/apidocs/org/apache/axiom/om/OMAbstractFactory.html > [2] http://ws.apache.org/commons/axiom/apidocs/index.html >
