[
https://issues.apache.org/jira/browse/CHAIN-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182397#comment-13182397
]
Simone Tripodi commented on CHAIN-62:
-------------------------------------
Good catch Ales,
what about if we provide 2 methods:
* {{CatalogFactory#getInstance(ClassLoader)}}
* {{CatalogFactory#getInstance()}} which uses
{{CatalogFactory.class.getClassLoader}}?
would it be helpful to be used inside an OSGi container?
> Use of thread context ClassLoader under OSGi
> --------------------------------------------
>
> Key: CHAIN-62
> URL: https://issues.apache.org/jira/browse/CHAIN-62
> Project: Commons Chain
> Issue Type: Bug
> Affects Versions: 1.2
> Environment: OSGi
> Reporter: Ales Dolecek
> Priority: Minor
>
> The CatalogFactory#getInstance() is using thread context ClassLoader which
> gives undefined behavior under OSGi.
> This leads to problems with ConfigCatalogRule and especislly LookupCommand.
> Two bundles wired to same commons chain may use different catalog factories
> when parsing commands from XML or looking up commands from catalog.
> I think that CatalogFactory#getClassLoader() might allow disabling use of
> thread context class loader - either
> a) detect that it is used inside OSGi framework, or
> b) provide static boolean flag to disable it
> Combination of both might be via use of bundle activator that would set the
> flag. The activator would be used only under OSGi acting as "auto-detection"
> and still some other bundle might revert to default if required.
> Ales
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
