[
https://issues.apache.org/jira/browse/LOG4J2-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14104947#comment-14104947
]
Matt Sicker edited comment on LOG4J2-658 at 8/21/14 2:30 AM:
-------------------------------------------------------------
One possible hackish solution would be to reflectively take some control over
the {{java.lang.Shutdown.hooks}} field. In JDK6, it's an ArrayList, so if we
subclasses ArrayList and forced our own shutdown hook to always be the last one
in the list, that could be one possible solution. I'll go look at the newer
JDKs as well to see if we can rely on that in OpenJDK.
Edit: JDK7 and JDK8 use {{Runnable[]}} instead of {{ArrayList<Runnable>}}.
Plus, the static method {{Shutdown.add}} has a different signature in 6 versus
7/8. In 6, it takes a Runnable. In 7+, it takes an int (for the index in the
array), a boolean to indicate if the hook can be registered during shutdown,
and then the Runnable.
ApplicationShutdownHooks is not a great place to try and insert the shutdown
hook as it uses IdentityHashMap to store the hooks. That means (at least in
JDK6) the order of shutdown hooks is basically random. The hash used in that
class is the default hash code, not the one returned by Object.hashCode().
Plus, that gets modified based on the current size of the backing array for the
map. So, that's a no-go in terms of forcing our hook to be last without
replacing its IdentityHashMap instance with a subclass.
JDK7 is where the mentioned registerShutdownHook method was added to
JavaLangAccess. Plus, based on its signature, it looks like it just gives
access to {{Shutdown.add}}. That might be accessible through reflection.
was (Author: jvz):
One possible hackish solution would be to reflectively take some control over
the {{java.lang.Shutdown.hooks}} field. In JDK6, it's an ArrayList, so if we
subclasses ArrayList and forced our own shutdown hook to always be the last one
in the list, that could be one possible solution. I'll go look at the newer
JDKs as well to see if we can rely on that in OpenJDK.
> shutdown hook called too early
> ------------------------------
>
> Key: LOG4J2-658
> URL: https://issues.apache.org/jira/browse/LOG4J2-658
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.0-rc1, 2.0-rc2
> Reporter: Romain Manni-Bucau
>
> Hi
> this issue follow few mail exchanges from the commons list. Here the
> interesting part for log4j2:
> {quote}
> Here what I do (we can move it to another thread since that's 100% log4j2
> related): unzip apache-tomee-1.7.0-SNAPSHOT-webprofile.zip && cd
> apache-tomee-webprofile-1.7.0-SNAPSHOT/ && rm conf/logging.properties &&
> echo 'openejb.log.factory=log4j'>conf/system.properties && cp ~/log4j2.xml
> conf/log4j2.xml && cp
> ~/.m2/repository/org/apache/logging/log4j/log4j-api/2.0-rc2-SNAPSHOT/log4j-api-2.0-rc2-SNAPSHOT.jar
> lib/ && cp
> ~/.m2/repository/org/apache/logging/log4j/log4j-core/2.0-rc2-SNAPSHOT/log4j-core-2.0-rc2-SNAPSHOT.jar
> lib/ && cp
> ~/.m2/repository/org/apache/logging/log4j/log4j-1.2-api/2.0-rc2-SNAPSHOT/log4j-1.2-api-2.0-rc2-SNAPSHOT.jar
> lib/ && ./bin/catalina.sh
> it makes server starting with log4j2 logs, if you ctrl+c logs are not
> printed. Sure it is cause context is closed too early and then loggers have
> NullConfiguration. (If I debug in java.lang.ApplicationShutdownHooks#runHooks
> to wait all hooks exec it works)
> {quote}
> Basically the issue is that when shutting down with ctrl+C some logs are
> swallowed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
