https://bz.apache.org/bugzilla/show_bug.cgi?id=68067
Bug ID: 68067
Summary: Issue with BCEL Repository in Multi-Classloader
Environments
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
URL: https://www.taxiserviceinsomnath.com
Status: NEW
Severity: enhancement
Priority: P2
Component: All
Assignee: bugs@httpd.apache.org
Reporter: taxiserviceinsomnath@gmail.com
Target Milestone: ---
I am developing a library that internally uses the Byte Code Engineering
Library (BCEL). My library is intended for use in applications, which may also
independently utilize BCEL for other purposes. It is essential to note that my
library may be deployed in multi-classloader environments, such as web
containers or application servers.
The problem I've encountered is related to the singleton Repository class
(org.apache.bcel.Repository) used by BCEL. When my library is deployed in a web
container, the default behavior of the Repository class is problematic. It
fails to load classes from the class loader associated with my library and,
instead, only resolves classes from the system classpath. This poses
challenges, especially when other applications are using BCEL alongside my
library.
To address this issue, I've tried changing the global Repository._repository
instance to ClassLoaderRepository, which can work with my class loader.
However, this approach may inadvertently break the host application that also
relies on BCEL.
The problem becomes even more complex when multiple threads are involved, each
working within different classloaders. In such cases, I must manage and
arbitrate the use of BCEL among these threads. Furthermore, even if I do this,
it doesn't prevent others from replacing the Repository.
This problem can also manifest when, for instance, an Ant task generates class
files using BCEL. If a user runs this task in parallel with the <parallel>
task, the classes generated by those parallel threads share the same
Repository, leading to conflicts.
In summary, BCEL assumes a single class for a given name when making a static
method invocation, like Repository.lookupClass("org.acme.Foo"). However, in
multi-classloader environments, this assumption is invalid, as different
classloaders may resolve this name to different classes.
I kindly request a review and a potential solution to address this issue in
BCEL to better support multi-classloader environments and avoid conflicts that
can arise due to Repository's singleton nature.
Thank you for your attention to this matter.
Best regards,
Taxi Sercice in Somnath
Ground Floor, Hotel Shiv Sadan, Near Somnath Trust Bhojnalay Somnath, Gujarat,
362268
+918155978006
https://taxiserviceinsomnath.com
https://goo.gl/maps/KdHBcHEyNpEano4w7
taxiserviceinsomnath@gmail.com
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
Bug ID: 68067
Summary: Issue with BCEL Repository in Multi-Classloader
Environments
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
URL: https://www.taxiserviceinsomnath.com
Status: NEW
Severity: enhancement
Priority: P2
Component: All
Assignee: bugs@httpd.apache.org
Reporter: taxiserviceinsomnath@gmail.com
Target Milestone: ---
I am developing a library that internally uses the Byte Code Engineering
Library (BCEL). My library is intended for use in applications, which may also
independently utilize BCEL for other purposes. It is essential to note that my
library may be deployed in multi-classloader environments, such as web
containers or application servers.
The problem I've encountered is related to the singleton Repository class
(org.apache.bcel.Repository) used by BCEL. When my library is deployed in a web
container, the default behavior of the Repository class is problematic. It
fails to load classes from the class loader associated with my library and,
instead, only resolves classes from the system classpath. This poses
challenges, especially when other applications are using BCEL alongside my
library.
To address this issue, I've tried changing the global Repository._repository
instance to ClassLoaderRepository, which can work with my class loader.
However, this approach may inadvertently break the host application that also
relies on BCEL.
The problem becomes even more complex when multiple threads are involved, each
working within different classloaders. In such cases, I must manage and
arbitrate the use of BCEL among these threads. Furthermore, even if I do this,
it doesn't prevent others from replacing the Repository.
This problem can also manifest when, for instance, an Ant task generates class
files using BCEL. If a user runs this task in parallel with the <parallel>
task, the classes generated by those parallel threads share the same
Repository, leading to conflicts.
In summary, BCEL assumes a single class for a given name when making a static
method invocation, like Repository.lookupClass("org.acme.Foo"). However, in
multi-classloader environments, this assumption is invalid, as different
classloaders may resolve this name to different classes.
I kindly request a review and a potential solution to address this issue in
BCEL to better support multi-classloader environments and avoid conflicts that
can arise due to Repository's singleton nature.
Thank you for your attention to this matter.
Best regards,
Taxi Sercice in Somnath
Ground Floor, Hotel Shiv Sadan, Near Somnath Trust Bhojnalay Somnath, Gujarat,
362268
+918155978006
https://taxiserviceinsomnath.com
https://goo.gl/maps/KdHBcHEyNpEano4w7
taxiserviceinsomnath@gmail.com
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org