[jira] Commented: (WSCOMMONS-271) OMAbstractFactory should use thread context classloader rather than Class.forName(omFactory)

["Andreas Veithen (JIRA)" <ji...@apache.org>]

    [ 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.