DO NOT REPLY [Bug 38057] New: - There shouldn't be a singleton Repository instance

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38057>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38057

           Summary: There shouldn't be a singleton Repository instance
           Product: BCEL
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Main
        AssignedTo: [email protected]
        ReportedBy: [email protected]


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.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.