[
https://issues.apache.org/jira/browse/WSCOMMONS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654143#action_12654143
]
Andreas Veithen commented on WSCOMMONS-271:
-------------------------------------------
If we implemented this, we could no longer cache the factory instances in
static attributes as we do now. This means that either we would have to look up
the factory class and create a new instance on each invocation of one of the
OMAbstractFactory methods, or we would have to implement a mechanism that
caches the factory instances by class loader. The former solution is
inefficient and the latter is quite tricky to implement (and could lead to
unexpected results).
For this reason I'm against this change except if there is enough added value,
which I don't see here. Indeed, since the factory class names are determined by
system properties which have VM scope, the only use case would be to have
axiom-api in a parent (or shared) class loader and different versions of
axiom-impl in child class loaders (if I understand correctly, this is what the
reporter wants to do here). However, this means that there is at least one
combination of axiom-api/axiom-impl with versions that don't correspond. I
don't think that it is recommended to mix one version of axiom-impl with
axiom-api from a different version.
> 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.
