You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Dave Brosius (JIRA)" <ji...@apache.org> on 2016/05/28 20:33:12 UTC

[jira] [Commented] (BCEL-73) There shouldn't be a singleton Repository instance

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

Dave Brosius commented on BCEL-73:
----------------------------------

Committed revision 1745933

> There shouldn't be a singleton Repository instance
> --------------------------------------------------
>
>                 Key: BCEL-73
>                 URL: https://issues.apache.org/jira/browse/BCEL-73
>             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
(v6.3.4#6332)