commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Brosius (JIRA)" <>
Subject [jira] [Commented] (BCEL-73) There shouldn't be a singleton Repository instance
Date Sat, 28 May 2016 20:33:12 GMT


Dave Brosius commented on BCEL-73:

Committed revision 1745933

> There shouldn't be a singleton Repository instance
> --------------------------------------------------
>                 Key: BCEL-73
>                 URL:
>             Project: Commons BCEL
>          Issue Type: Improvement
>          Components: Main
>    Affects Versions: unspecified
>         Environment: Operating System: other
> Platform: Other
>            Reporter: Kohsuke Kawaguchi
>            Assignee: Apache Commons Developers
> I'm writing a library that uses BCEL internally. My library is intended to be
> used by applications, which may use BCEL by themselves for other purposes. My
> library may be deployed into a multi-classloader environment, such as a web
> container or application server.
> I found the notion of the singleton Repository (org.apache.bcel.Repository)
> problematic. When my library is used in a web container, Repository by default
> fails to load classes in "my" class loader (instead it only resolves classes in
> the system classpath.) Yet if I change the global Repository._repository
> instance to ClassLoaderRepository that works with my class loader, it may break
> my host application that just happens to be using BCEL.
> The same issue arises when I got multiple threads that each work with different
> classloaders. I have to arbitrate the use of BCEL among those threads, and it
> still doesn't prevent someone else from replacing Repository.
> Here's another way to hit this problem. Suppose you got an Ant task that
> generates class files by using BCEL. If the user runs this task in parallel with
> the <parallel> task, classes that are generated from those parallel threads
> share the same Repository and cause conflicts.
> In more general terms, when BCEL makes a static method invocation like
> Repository.lookupClass("org.acme.Foo"), it's assuming that this name resolves to
> a single class. Unfortunately this is wrong, as we all know that multiple
> classloaders are allowed to resolve this in different classes.

This message was sent by Atlassian JIRA

View raw message