[
https://issues.apache.org/jira/browse/WSCOMMONS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655853#action_12655853
]
Todd Wolff commented on WSCOMMONS-271:
--------------------------------------
@Andreas: To provide a bit of context, I assumed the motive behind splitting
the axiom project into separate artifiacts, i.e. an API artifact, a DOM impl
artifact and an OM impl artifact (and perhaps someday a third party impl
artifact) was to allow for different implementations of the same API within the
scope of a single JVM.
If that's true, then the current architecture does not allow this, e.g. one
deployment cannot choose to use the DOM factory and another the OM factory.
The use-case here involves 'deployments' authored by different organizations,
i.e. an application which uses version y.y of the dom impl and an application
which uses version y.y of the OM impl - both of which share version y.y of the
API.
Mixing impl versions and api versions would be a nice-to-have, but not
critical. I could imagine a situation where future API releases, which are
backwards compatible with impl artifacts, would allow deployments authored by
different organizations to upgrade to a later axiom impl release on different
schedules.
> 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.
