commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ales Dolecek (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CHAIN-62) Use of thread context ClassLoader under OSGi
Date Tue, 10 Jan 2012 21:19:39 GMT

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

Ales Dolecek edited comment on CHAIN-62 at 1/10/12 9:19 PM:
------------------------------------------------------------

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) as OSGi it might be OSGi framework dependent (I use equinox)

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?

And BTW: Is it OK to have public non-final variable CatalogFactory or should I provide static
setter?

Ales
                
      was (Author: alesd):
    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

        

Mime
View raw message