commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ales Dolecek (Commented) (JIRA)" <>
Subject [jira] [Commented] (CHAIN-62) Use of thread context ClassLoader under OSGi
Date Tue, 10 Jan 2012 14:36:39 GMT


Ales Dolecek commented on CHAIN-62:


  I'm afraid it won't help. I can actually "simulate" this with following code:

ClassLoader savedCl = Thread.currentThread().getContextClassLoader();
try {
  // do something
} finally {

I choose getClass().getClassLoader() which is actually the bundle class loader (provided that
the class that contain the code is in my bundle).

There are two problems: 

a) initial population of Catalog with commands
  - suppose two different bundles each populating one catalog
  - the bundles will use different classloaders
  - not problem with Digester that is creating the commands
    - if both bundles import same packages their *different* classloaders will see *same*
  - commons chains will however assign the catalog to different catalog factory

  => The bundles must agree on class loader to use
    - best bet is CatalogFactory.class.getClassLoader()
    - but that class loader would not see the classes of commands provided by the bundles
(because digester has also to use thread context class loader as explained above)

  => The bundles therefore must use classloader of class from bundle which imports *all*
required classes that implement some commands added to catalogs. Clearly against the modularity
concept of OSGi.

  It is "catch 22" situation - either satisfy CatalogFactory and Digester will be "blind"
or give Digester "usefull" class loader and you are forced to temporary set it every time
you use the chains.

b) lookup command
  - the lookup command uses CatalogFactory instance to find the target command
  - if it is not provided then CatalogFactory#getInstance() is used
  - since it is the Digester who actually create/configure the instance you can't control
which CatalogFactory will the lookup instance use
  => you need to add rule that assigns some specific CatalogFactory to every LookupCommand
  => this means tweaking the rules used by digester which might be very problematic
    - although you can generally check that the class specified by the command creation rule
is (subclass of) LookupCommand it does not work 100% correct since there might be classes
that actually delegate to LookupCommand like:

  class MyCommand implements Filter {

    private LookupCommand delegate;

  boolean execute(Context context) {
    return delegate.execute(context);

  boolean postprocess(Context context, Exception exception) {
    return delegate.postprocess(context, exception);
> Use of thread context ClassLoader under OSGi
> --------------------------------------------
>                 Key: CHAIN-62
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


View raw message