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: [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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
