[JDK 11] RFR: 8195096: Exception printed on console with custom LogManager on starting Apache Tomcat
markt at apache.org
Mon Jan 22 17:33:48 UTC 2018
On 22/01/18 16:47, Daniel Fuchs wrote:
> Hi guys,
> Here is my second take at solving the issue.
> There's no change in the public API (no CSR, Yay!),
> and it shouldn't require any changes on the Tomcat
> side. However I haven't tested my changes with Tomcat
> Mark - would you be able to help me with that?
I suspect it will be easier for you to download a Tomcat release and run
it that it will be for me to try and build the JRE.
That said, if you can point me to a snapshot JRE build (Linux, Windows
or OSX) I can test it.
The steps to test this should be:
1. Download Tomcat 9.0.2 (or 9.0.4 which should appear in the next 24
hours) from https://tomcat.apache.org/download-90.cgi
(zip or tar.gz binary distribution.
2. Unpack it to $UNPACK_DIR
3. Set he JAVA_HOME environment variable to point to the JRE you want to
4. Open a command prompt.
5. Navigate to $UNPACK_DIR/apache-tomcat-9.0.2/bin
6. Call start.[sh|bat] as appropriate for your platform.
7. Tomcat should start without stack-trace appearing on the console.
- You should see a stack trace if you use Java10 ea38
- You wont see a stack trace if you build Tomcat from source (the
workaround is in all current versions)
> best regards,
> -- daniel
> On 20/01/2018 13:17, Daniel Fuchs wrote:
>> Hi Mark,
>> Thanks for these links and for trying out a solution.
>> > On 19/01/18 20:14, Mark Thomas wrote:
>> > Thanks again for the hints. I have a work-around that seems to work:
>> > https://svn.apache.org/viewvc?view=revision&revision=1821708
>> I see... so what I think is happening is that in JDK 8, the
>> handlers from ".handlers" where added to the root logger from
>> within addLogger(rootLogger) and because ClassLoaderLogManager
>> overrides LogManager::addLogger, then that part was skipped.
>> In JDK 9 - that behavior changed - the handlers from ".handlers"
>> were no longer added because the root logger was already present
>> in the context when addLogger got called (that was a regression),
>> but since ClassLoaderLogManager overrides LogManager::addLogger
>> anyway - it made no difference for ClassLoaderLogManager.
>> In JDK 10, to fix the issue, I forced a call that would
>> add the handlers from ".handlers" to the root logger, but
>> because this now happens outside of addLogger(rootLogger) (just after)
>> then ClassLoaderLogManager feels the difference.
>> hmmm... let me think on this a bit more.
>> best regards,
>> -- daniel
More information about the core-libs-dev