OSGIification of Axiom

[Andreas Veithen <an...@gmail.com>]

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

Re: OSGIification of Axiom

[Andreas Veithen <an...@gmail.com>]

Good point.

Actually, considering that
- OMImplementation only exists in the 1.2.8 release and in the trunk,
- it is not yet complete (no getInstance method),
- it is currently only used in the test cases,
I think we can safely substitute it by an interface. Maybe we should
create that interface under a different name (e.g. OMMetaFactory) but
keep the method signatures, so that if somebody complains about the
fact that OMImplementation is disappearing in 1.2.9, we can put it
back (as an implementation of the new interface) later.

Andreas

On Mon, Feb 9, 2009 at 19:19, David Illsley <da...@gmail.com> wrote:
> 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
> <an...@gmail.com> 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
>>
>

Re: OSGIification of Axiom

[David Illsley <da...@gmail.com>]

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
<an...@gmail.com> 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
>