You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Todd Wolff (JIRA)" <ji...@apache.org> on 2007/10/29 16:17:50 UTC
[jira] Created: (WSCOMMONS-271) OMAbstractFactory should use thread
context classloader rather than Class.forName(omFactory)
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
[jira] Commented: (WSCOMMONS-271) OMAbstractFactory should use
thread context classloader rather than Class.forName(omFactory)
Posted by "Todd Wolff (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (WSCOMMONS-271) OMAbstractFactory should use
thread context classloader rather than Class.forName(omFactory)
Posted by "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.
[jira] Issue Comment Edited: (WSCOMMONS-271) OMAbstractFactory
should use thread context classloader rather than Class.forName(omFactory)
Posted by "Todd Wolff (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655853#action_12655853 ]
twolff edited comment on WSCOMMONS-271 at 12/11/08 5:56 PM:
----------------------------------------------------------------
@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 X.0 of the dom impl and an application which uses version X.0 of the OM impl - both of which share version X.0 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, e.g. an application which uses version X.0 of the OM impl and an application which uses version X.1 of the OM impl - both of which share version X.1 of the API.
was (Author: twolff):
@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.
[jira] Commented: (WSCOMMONS-271) OMAbstractFactory should use
thread context classloader rather than Class.forName(omFactory)
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (WSCOMMONS-271) OMAbstractFactory should use
thread context classloader rather than Class.forName(omFactory)
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen resolved WSCOMMONS-271.
---------------------------------------
Resolution: Invalid
> 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.