Re: [wildfly-dev] JBAS011592 the logging subsystem requires the log manager to be org.jboss.logmanager.LogManager

On 20 Oct 2014, at 11:20, Max Rydahl Andersen wrote:> On 20 Oct 2014, at 1:48, James R. Perkins wrote: > >> As Stuart asked more details would help. >> >> The only way this could happen is if something, an agent for example, >> attempts to get a logger before JBoss Modules initializes logging. >> JBoss Modules looks for a META-INF/services/ >> java.util.logging.LogManager service which JBoss Log Manager has. If >> an agent needs to be used the java.util.logging.manager needs to be >> set to org.jboss.logmanager.LogManager before the agent initializes a >> logger. > > It is all in the jira. > > And no, these errors have been happening on what is just plain vanilla > WildFly or EAP/JPP bundles. > > We do not do any agent funkyness afaik. > > And as said the "workaround" so far have been "restart it" and it > works. > > zero changes to the state or arguments. okey so there been some new movement in this. https://bugzilla.redhat.com/show_bug.cgi?id=1037970 Indicating there actually is a race condition if something pings the jvm via jmx during the startup *before* jboss main boot process manages to set the logmanager. Something that will happen because we actually have a feature that scans for locally running jvm's and attach an agent to gather info. Suggested workaround is to add this to our launch: JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager" JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.3.1.Final-redhat-1.jar" -logging org.jboss.logmanager.LogManager Question from us is, is the above workaround proper ? Will EAP/WildFly change their boot arguments to match to avoid this race condition issue for bat/sh launched servers too ?