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: bcel-dev@jakarta.apache.org
ReportedBy: kk@kohsuke.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
|