commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BCEL-73) There shouldn't be a singleton Repository instance
Date Sun, 16 Aug 2015 11:26:45 GMT

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

Sebb commented on BCEL-73:
--------------------------

Note that BCEL is not currently designed to be thread-safe. Fixing that would require a lot
more than just allowing multiple Repository instances.

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

Mime
View raw message