[
https://issues.apache.org/jira/browse/WSCOMMONS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656156#action_12656156
]
Andreas Veithen commented on WSCOMMONS-271:
-------------------------------------------
I was not involved in the choice of splitting Axiom into api, impl and dom, but
I guess that this had more to do with a cleaner organization of the code and
with dependency management. The way the artifacts are organized now for example
allows to depend only on the standard implementation (with api as transitive
dependency), so that when packaging an application, the DOM implementation is
not included.
Note that your argument is not valid because default factories are determined
by system properties, which have VM wide scope. Therefore you can't have two
"deployments" on the same VM, one using the standard implementation and the
other DOM as default factories. To support this kind of requirements,
OMAbstractFactory would have to be extended with a provider location mechanism
that looks up the available implementation from the classpath. In this case of
course the context classloader would be used.
Finally, two additional comments that are relevant here:
* The DOM implementation actually can't be used with OMAbstractFactory. See
WSCOMMONS-348 for an explanation of this issue (that BTW I personally consider
as a severe design flaw...).
* Loading the Axiom API from a shared classloader only really makes sense if
different "deployments" exchange objects with types defined in the API (e.g.
OMElements or SOAPEnvelopes). Otherwise (considering the small size of the API
artifact), this would not be useful and should be avoided to prevent version
conflicts.
> OMAbstractFactory should use thread context classloader rather than
> Class.forName(omFactory)
> --------------------------------------------------------------------------------------------
>
> Key: WSCOMMONS-271
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-271
> Project: WS-Commons
> Issue Type: Improvement
> Components: AXIOM
> Reporter: Todd Wolff
>
> Different 'deployments' should be able to 'share' the axiom api artifact,
> i.e. deployments should be able to hide their choice of implementation from
> other 'deployments.' By using Class.forName(), which uses OMAbstractFactory's
> defining classloader, and requiring a system property to identify the factory
> impl, the choice of implementation must be the same for all 'deployments.'
> If thread context classloader is used instead, along with the java service
> provider loading mechanism, each deployment could effectively 'scope' its
> desired version of the axiom impl artifact to its deployment (each of which
> has its own classloader), along with a service provider file which indicates
> the factory impl choice. The axiom api artifact (loaded by a 'shared'
> classloader) could then be 'shared' across deployments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
