[ 
https://issues.apache.org/jira/browse/CHAIN-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183572#comment-13183572
 ] 

Ales Dolecek commented on CHAIN-62:
-----------------------------------

Hello,

  I haven't wrote any unit tests for OSGi as I do not know how can I 
effectively run them. And this case would be rather problematic as:

a) it requires 2 different bundles to exploit the wrong behavior, and
b) is OSGi might be OSGi framework dependent

I can, however provide simple test case that calls 
{{CatalogFactory#getInstance()}} with different thread context class loaders 
and confirm that

a) the method returns different CatalogFactory for each call if the INSTANCE is 
null, and
b) the method returns same CatalogFactory if the INSTANCE is set and that the 
factory is the INSTANCE

Is this sufficient?

Ales
                
> 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
>         Attachments: CatalogFactory.patch
>
>
> The {{CatalogFactory#getInstance()}} is using thread context ClassLoader 
> which gives undefined behavior under OSGi.
> This leads to problems with {{ConfigCatalogRule}} and especially 
> {{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

        

Reply via email to