Bug 38057

Summary: There shouldn't be a singleton Repository instance
Product: BCEL - Now in Jira Reporter: Kohsuke Kawaguchi <kk>
Component: MainAssignee: issues <issues>
Status: ASSIGNED ---    
Severity: enhancement    
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: other   

Description Kohsuke Kawaguchi 2005-12-28 02:27:20 UTC
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.
Comment 1 Dave Brosius 2005-12-28 03:20:49 UTC
What if your custom classloader loaded bcel, then you would have n 
Repositories, no?
Comment 2 Torsten Curdt 2006-01-27 14:07:28 UTC
I came across the same limitation ...I totally agree the static approach is a real problem