reta commented on code in PR #2582:
URL: https://github.com/apache/cxf/pull/2582#discussion_r2323730722
##########
core/src/main/java/org/apache/cxf/common/logging/JDKBugHacks.java:
##########
@@ -99,91 +96,61 @@ public static void doHacks() {
.setThreadContextClassloader(ClassLoader.getSystemClassLoader());
try {
try {
- //Trigger a call to sun.awt.AppContext.getAppContext()
+ /*
+ * Several components end up calling:
sun.awt.AppContext.getAppContext()
+ *
+ * Those libraries / components known to trigger memory
leaks due to eventual calls to
+ * getAppContext() are:
+ * - Google Web Toolkit via its use of javax.imageio
+ * - Batik
+ * - others TBD
+ *
+ * Note that a call to sun.awt.AppContext.getAppContext()
results in a thread being started named
+ * AWT-AppKit that requires a graphical environment to be
available.
+ */
+
+ // Trigger a call to sun.awt.AppContext.getAppContext().
This
+ // will pin the system class loader in memory but that
shouldn't
+ // be an issue.
if (!skipHack("org.apache.cxf.JDKBugHacks.imageIO",
"true")) {
ImageIO.getCacheDirectory();
}
} catch (Throwable t) {
//ignore
}
- try {
- //DocumentBuilderFactory seems to SOMETIMES pin the
classloader
- if
(!skipHack("org.apache.cxf.JDKBugHacks.documentBuilderFactory")) {
- DocumentBuilderFactory factory =
DocumentBuilderFactory.newInstance();
- factory.newDocumentBuilder();
- }
- } catch (Throwable e) {
- //ignore
- }
- // Several components end up calling:
- // sun.misc.GC.requestLatency(long)
- //
- // Those libraries / components known to trigger memory leaks
due to
- // eventual calls to requestLatency(long) are:
- // - javax.management.remote.rmi.RMIConnectorServer.start()
- try {
- if
(!skipHack("org.apache.cxf.JDKBugHacks.gcRequestLatency")) {
- Class<?> clazz = Class.forName("sun.misc.GC");
- Method method =
clazz.getDeclaredMethod("currentLatencyTarget");
- Long l = (Long)method.invoke(null);
- if (l != null && l.longValue() == 0) {
- //something already set it, move on
- method = clazz.getDeclaredMethod("requestLatency",
Long.TYPE);
- method.invoke(null, Long.valueOf(36000000));
- }
- }
- } catch (Throwable e) {
- //ignore
- }
- // Calling getPolicy retains a static reference to the context
- // class loader.
try {
- // Policy.getPolicy();
- if (!skipHack("org.apache.cxf.JDKBugHacks.policy")) {
- Class<?> policyClass = Class
- .forName("javax.security.auth.Policy");
- Method method = policyClass.getMethod("getPolicy");
- method.invoke(null);
- }
- } catch (Throwable e) {
- // ignore
- }
- try {
- // Initializing javax.security.auth.login.Configuration
retains a static reference
- // to the context class loader.
- if
(!skipHack("org.apache.cxf.JDKBugHacks.authConfiguration")) {
-
Class.forName("javax.security.auth.login.Configuration", true,
- ClassLoader.getSystemClassLoader());
+ /*
+ * Several components end up opening JarURLConnections
without first disabling caching.
+ * This effectively locks the file. Whilst more noticeable
and harder to ignore on Windows,
+ * it affects all operating systems.
+ *
+ * Those libraries/components known to trigger this issue
include:
+ * - log4j versions 1.2.15 and earlier
+ * -javax.xml.bind.JAXBContext.newInstance()
+ *
+ * https://bugs.openjdk.java.net/browse/JDK-8163449
+ *
+ * Disable caching for JAR URLConnections
+ */
+
+ // Set the default URL caching policy to not to cache
+ if
(!skipHack("org.apache.cxf.JDKBugHacks.defaultUsesCaches")) {
+ URLConnection.setDefaultUseCaches("JAR", false);
}
- } catch (Throwable e) {
- // Ignore
- }
- // Creating a MessageDigest during web application startup
- // initializes the Java Cryptography Architecture. Under
certain
- // conditions this starts a Token poller thread with TCCL equal
- // to the web application class loader.
- if (!skipHack("org.apache.cxf.JDKBugHacks.securityProviders"))
{
Review Comment:
This one is also seems to be in effect
(`java.security.Security.getProviders()`), right? Could we keep it?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
