ClassLoaderLogManager.readConfiguration locates logging.properties incorrectly with JDK 9

2016-07-28 Thread Chris Hegarty 
Hi,

The following exception can be seen when, running with JDK 9 b115 ( early 
access )
and shutting down the Tomcat server. The issue is that the code in 
org.apache.juli.ClassLoaderLogManager.readConfiguration() expects to find the 
‘logging.properties' file in the ‘lib' directory of the JRE image. This is not 
the case in 
JDK 9, it has been moved to the ‘conf' directory of the image. See the "New 
run-time
image structure” of JEP 220 [1] for details of this.

The code can be simply updated to look in the ‘conf’ directory, or 
alternatively can
select between ‘conf’ and ‘lib’ if required to run on multiple releases.

Configuration error
java.io.FileNotFoundException: 
/opt/jdk-9.jdk_b115/Contents/Home/lib/logging.properties (No such file or 
directory)
at java.io.FileInputStream.open0(java.base@9-ea/Native Method)
at java.io.FileInputStream.open(java.base@9-ea/FileInputStream.java:195)
at 
java.io.FileInputStream.(java.base@9-ea/FileInputStream.java:138)
at 
org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:479)
at 
org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:402)
at 
org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:398)
at java.security.AccessController.doPrivileged(java.base@9-ea/Native 
Method)
at 
org.apache.juli.ClassLoaderLogManager.getClassLoaderInfo(ClassLoaderLogManager.java:398)
at 
org.apache.juli.ClassLoaderLogManager.addLogger(ClassLoaderLogManager.java:136)
at 
org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:507)
at 
org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:402)
at 
org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:398)
at java.security.AccessController.doPrivileged(java.base@9-ea/Native 
Method)
at 
org.apache.juli.ClassLoaderLogManager.getClassLoaderInfo(ClassLoaderLogManager.java:398)
at 
org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:493)
at 
org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:309)
at 
java.util.logging.LogManager.readPrimordialConfiguration(java.logging@9-ea/LogManager.java:437)
at 
java.util.logging.LogManager.access$800(java.logging@9-ea/LogManager.java:156)
at 
java.util.logging.LogManager$2.run(java.logging@9-ea/LogManager.java:387)
at java.security.AccessController.doPrivileged(java.base@9-ea/Native 
Method)
at 
java.util.logging.LogManager.ensureLogManagerInitialized(java.logging@9-ea/LogManager.java:380)
at 
java.util.logging.LogManager.getLogManager(java.logging@9-ea/LogManager.java:422)
at 
java.util.logging.SimpleFormatter.getLoggingProperty(java.logging@9-ea/SimpleFormatter.java:63)
at 
jdk.internal.logger.SimpleConsoleLogger$Formatting.getSimpleFormat(java.base@9-ea/SimpleConsoleLogger.java:491)
at 
jdk.internal.logger.SurrogateLogger.getSimpleFormat(java.base@9-ea/SurrogateLogger.java:62)
at 
java.util.logging.SimpleFormatter.(java.logging@9-ea/SimpleFormatter.java:67)
at 
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base@9-ea/Native
 Method)
at 
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base@9-ea/NativeConstructorAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base@9-ea/DelegatingConstructorAccessorImpl.java:45)
at 
java.lang.reflect.Constructor.newInstance(java.base@9-ea/Constructor.java:453)
at java.lang.Class.newInstance(java.base@9-ea/Class.java:550)
at org.apache.juli.logging.DirectJDKLog.(DirectJDKLog.java:49)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:115)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:137)
at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:188)
at org.apache.catalina.startup.Bootstrap.(Bootstrap.java:52)

-Chris.

[1] http://openjdk.java.net/jeps/220


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access builds of JDK 8u112 b04, JDK 9 b130 are available on java.net

2016-08-08 Thread Chris Hegarty 

> On 8 Aug 2016, at 08:51, Rory O'Donnell  wrote:
> 
> Hi Mark,
> 
> There are two fixes to bugs reported by you in b130, can you confirm fixes  ?
> 
> Early Access b130  for JDK 9 is available on 
> java.net, summary of  changes are listed here 
> .
> 
> 8156824 core-libs com.sun.jndi.ldap.pool.PoolCleaner should clear its context 
> class loader
> 8157570 core-libs sun.rmi.transport.GC retains a strong reference to the 
> context class loader

With the two changes above, then several cleanups in
JreMemoryLeakPreventionListener::lifecycleEvent can be done in a JDK 9
specific Tomcat source trunk. Otherwise, if the code needs to run on older
releases, it can be be made version specific, where it is not executed on
JDK 9 or greater.

There is another of these unnecessary retention of the context class loader
issues, 8156841 [1], that I hope to address in a near future build of JDK 9.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8156841
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access builds of JDK 8u112 b04, JDK 9 b130 are available on java.net

2016-08-31 Thread Chris Hegarty 

On 08/08/16 11:20, Chris Hegarty wrote:



On 8 Aug 2016, at 08:51, Rory O'Donnell  wrote:

Hi Mark,

There are two fixes to bugs reported by you in b130, can you confirm fixes  ?

Early Access b130 <https://jdk9.java.net/download/> for JDK 9 is available on 
java.net, summary of  changes are listed here 
<http://download.java.net/java/jdk9/changes/jdk-9+130.html>.

8156824 core-libs com.sun.jndi.ldap.pool.PoolCleaner should clear its context 
class loader
8157570 core-libs sun.rmi.transport.GC retains a strong reference to the 
context class loader


With the two changes above, then several cleanups in
JreMemoryLeakPreventionListener::lifecycleEvent can be done in a JDK 9
specific Tomcat source trunk. Otherwise, if the code needs to run on older
releases, it can be be made version specific, where it is not executed on
JDK 9 or greater.

There is another of these unnecessary retention of the context class loader
issues, 8156841 [1], that I hope to address in a near future build of JDK 9.



JDK bug 8156841 has been fixed in JDK 9 b133. The same
isJre9Available() technique can be used to avoid
tokenPollerProtection.

-Chris.


-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8156841



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org