[
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)
