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)