[JBoss JIRA] (SECURITY-746) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by arjan tijms (JIRA)
arjan tijms created SECURITY-746:
------------------------------------
Summary: EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
Key: SECURITY-746
URL: https://issues.jboss.org/browse/SECURITY-746
Project: PicketBox
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: arjan tijms
Assignee: Anil Saldhana
After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
The problematic part in {{SimpleSecurityManager}}:
{code}
public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
boolean contextPushed = false;
boolean securityContextEstablished = false;
final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
try {
contexts.push(previous);
contextPushed = true;
SecurityContext current = establishSecurityContext(securityDomain);
securityContextEstablished = true;
if (previous != null) {
current.setSubjectInfo(previous.getSubjectInfo());
current.setIncomingRunAs(previous.getOutgoingRunAs());
}
RunAs currentRunAs = current.getIncomingRunAs();
boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
if (trusted == false) {
boolean authenticated = false;
if (SecurityActions.remotingContextIsSet()) {
// ...
}
// If we have a trusted identity no need for a re-auth.
if (authenticated == false) {
// THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
authenticated = authenticate(current, null);
}
{code}
The (condensed) stack that will lead to an exception is the following:
{noformat}
javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
{noformat}
Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-1406) Hibernate cannot process package-info.java any more
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1406?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1406:
------------------------------------------
I just re-build Hibernate-ORM 4.3.0.Beta3, made the small change below in PackageInfoArchiveEntryHandler.java, replaced hibernate-entitymanager-4.3.0.Beta3.jar in WildFly:
the issue is gone.
Original line 71:
{code}
.replace( separatorChar, '.' );
{code}
New line 71:
{code}
.replace( '/', '.' );
{code}
But now I've definitely to leave for vacation.
> Hibernate cannot process package-info.java any more
> ---------------------------------------------------
>
> Key: WFLY-1406
> URL: https://issues.jboss.org/browse/WFLY-1406
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Attachments: javap.log, server.log, server.log.zip, shop2.war, tar.log
>
>
> I tried the snapshot which contains Hibernate 4.3.0.Beta2. However, package-info.java files are causing problems. For instance, the package de.shop.artikelverwaltung.domain has a package-info.java which causes a NoClassDefFoundError:
> "IllegalName: de/shop/artikelverwaltung/domain.package-info". Please see the stacktrace below.
> Here is an example for package-info.java which was working with WildFly 8.0.0.Alpha1:
> @XmlAccessorType(FIELD)
> @Vetoed
> package de.shop.artikelverwaltung.domain;
> import static javax.xml.bind.annotation.XmlAccessType.FIELD;
> import javax.enterprise.inject.Vetoed;
> import javax.xml.bind.annotation.XmlAccessorType;
> The stacktrace:
> ...
> 09:29:53,880 WARN [org.jboss.modules] Failed to define class de/shop/artikelverwaltung/domain.package-info in Module "deployment.shop2.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link de/shop/artikelverwaltung/domain/package-info (Module "deployment.shop2.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:526) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.findClass(ClassLoaderServiceImpl.java:218) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356) [rt.jar:1.7.0_21]
> at org.hibernate.annotations.common.util.ReflectHelper.classForName(ReflectHelper.java:160) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.packageForName(JavaReflectionManager.java:121) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.cfg.AnnotationBinder.bindPackage(AnnotationBinder.java:262) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.cfg.Configuration.addPackage(Configuration.java:792) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildHibernateConfiguration(EntityManagerFactoryBuilderImpl.java:1174) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:839) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:142) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:213) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$800(PersistenceUnitServiceImpl.java:58) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:107) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.lang.NoClassDefFoundError: IllegalName: de/shop/artikelverwaltung/domain.package-info
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:646) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:785) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) [jboss-modules.jar:1.2.0.Final]
> ... 28 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (LOGMGR-58) Handler rollback gets null instance reference if prepare are invoked
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-58?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-58:
-----------------------------------------------
pkremens(a)redhat.com made a comment on [bug 975559|https://bugzilla.redhat.com/show_bug.cgi?id=975559]
Verified on EAP 6.1.1 ER4
> Handler rollback gets null instance reference if prepare are invoked
> --------------------------------------------------------------------
>
> Key: LOGMGR-58
> URL: https://issues.jboss.org/browse/LOGMGR-58
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 1.4.2.Final, 1.5.0.Beta1, 2.0.0.Beta1
>
>
> When a forget/rollback is executed after a prepare the instance has already been removed from the refs. The reference should be held so that it can added back to the refs.
> The least evasive solution is to not invoke the {{applyPostCreate()}} in the prepare. This will require examination of all implementations to make sure values are set, but references are not removed in this phase.
> The other option would be to add a commit step only invoked from the commit phase where references could be removed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (LOGMGR-58) Handler rollback gets null instance reference if prepare are invoked
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-58?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-58:
-----------------------------------------------
pkremens(a)redhat.com changed the Status of [bug 975559|https://bugzilla.redhat.com/show_bug.cgi?id=975559] from ON_QA to VERIFIED
> Handler rollback gets null instance reference if prepare are invoked
> --------------------------------------------------------------------
>
> Key: LOGMGR-58
> URL: https://issues.jboss.org/browse/LOGMGR-58
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 1.4.2.Final, 1.5.0.Beta1, 2.0.0.Beta1
>
>
> When a forget/rollback is executed after a prepare the instance has already been removed from the refs. The reference should be held so that it can added back to the refs.
> The least evasive solution is to not invoke the {{applyPostCreate()}} in the prepare. This will require examination of all implementations to make sure values are set, but references are not removed in this phase.
> The other option would be to add a commit step only invoked from the commit phase where references could be removed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-1503) Unable to remove custom logging handler
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1503?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1503:
-----------------------------------------------
pkremens(a)redhat.com made a comment on [bug 975085|https://bugzilla.redhat.com/show_bug.cgi?id=975085]
Verified on EAP 6.1.1 ER4
> Unable to remove custom logging handler
> ---------------------------------------
>
> Key: WFLY-1503
> URL: https://issues.jboss.org/browse/WFLY-1503
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 8.0.0.Alpha1
> Reporter: Carlo de Wolf
> Assignee: James Perkins
> Priority: Blocker
> Fix For: 8.0.0.Alpha4
>
>
> During removal of the custom handler in {{Log4jCustomHandlerTestCase}} the following error is shown:
> {noformat}
> 09:38:24,266 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "customFileAppender")
> ]): java.lang.IllegalArgumentException: No reference found for 'org.jboss.as.logging.logmanager.Log4jAppenderHandler'
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$5.validate(AbstractPropertyConfiguration.java:399) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$5.validate(AbstractPropertyConfiguration.java:391) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:333) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:292) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:302) [wildfly-logging-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97) [wildfly-logging-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_19]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_19]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_19]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> {noformat}
> This effectively puts the server in a dead state (WFLY-1497 is hiding this issue, because it leaves the handler disabled).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-1503) Unable to remove custom logging handler
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1503?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1503:
-----------------------------------------------
pkremens(a)redhat.com changed the Status of [bug 975085|https://bugzilla.redhat.com/show_bug.cgi?id=975085] from ON_QA to VERIFIED
> Unable to remove custom logging handler
> ---------------------------------------
>
> Key: WFLY-1503
> URL: https://issues.jboss.org/browse/WFLY-1503
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 8.0.0.Alpha1
> Reporter: Carlo de Wolf
> Assignee: James Perkins
> Priority: Blocker
> Fix For: 8.0.0.Alpha4
>
>
> During removal of the custom handler in {{Log4jCustomHandlerTestCase}} the following error is shown:
> {noformat}
> 09:38:24,266 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "customFileAppender")
> ]): java.lang.IllegalArgumentException: No reference found for 'org.jboss.as.logging.logmanager.Log4jAppenderHandler'
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$5.validate(AbstractPropertyConfiguration.java:399) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$5.validate(AbstractPropertyConfiguration.java:391) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:333) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:292) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:302) [wildfly-logging-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97) [wildfly-logging-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_19]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_19]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_19]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> {noformat}
> This effectively puts the server in a dead state (WFLY-1497 is hiding this issue, because it leaves the handler disabled).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-1379) log4j appenders force initialization of the appender/handler on reboot
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1379?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1379:
-----------------------------------------------
pkremens(a)redhat.com made a comment on [bug 971190|https://bugzilla.redhat.com/show_bug.cgi?id=971190]
Verified on EAP 6.1.1 ER4
> log4j appenders force initialization of the appender/handler on reboot
> ----------------------------------------------------------------------
>
> Key: WFLY-1379
> URL: https://issues.jboss.org/browse/WFLY-1379
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 8.0.0.Alpha1
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 8.0.0.Alpha2
>
>
> Adding a log4j appender works until the server is rebooted. The difference in the class names, {{org.apache.log4j.SomeAppender}} and manually added {{org.jboss.as.logging.logmanager.Log4jAppenderHandler}}, results in the handler being reconfigured.
> This also hits a bug (LOGMGR-58) in the logmanager where null references are can be retrieved before a full commit is invoked.
> Stack trace:
> {code}
> 10:53:44,909 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,909 ERROR [stderr] (Controller Boot Thread) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> 10:53:44,912 ERROR [stderr] (Controller Boot Thread) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,912 ERROR [stderr] (Controller Boot Thread) at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,915 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,915 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,920 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:722)
> 10:53:44,920 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,921 ERROR [stderr] (Controller Boot Thread) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> 10:53:44,921 ERROR [stderr] (Controller Boot Thread) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,922 ERROR [stderr] (Controller Boot Thread) at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,922 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,924 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,925 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,925 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,927 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,927 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,929 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,929 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:722)
> 10:53:44,930 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread) at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,932 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,932 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,935 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,935 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,936 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,936 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,938 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,938 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:722)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-1379) log4j appenders force initialization of the appender/handler on reboot
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1379?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1379:
-----------------------------------------------
pkremens(a)redhat.com changed the Status of [bug 971190|https://bugzilla.redhat.com/show_bug.cgi?id=971190] from ON_QA to VERIFIED
> log4j appenders force initialization of the appender/handler on reboot
> ----------------------------------------------------------------------
>
> Key: WFLY-1379
> URL: https://issues.jboss.org/browse/WFLY-1379
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 8.0.0.Alpha1
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 8.0.0.Alpha2
>
>
> Adding a log4j appender works until the server is rebooted. The difference in the class names, {{org.apache.log4j.SomeAppender}} and manually added {{org.jboss.as.logging.logmanager.Log4jAppenderHandler}}, results in the handler being reconfigured.
> This also hits a bug (LOGMGR-58) in the logmanager where null references are can be retrieved before a full commit is invoked.
> Stack trace:
> {code}
> 10:53:44,909 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,909 ERROR [stderr] (Controller Boot Thread) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> 10:53:44,912 ERROR [stderr] (Controller Boot Thread) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,912 ERROR [stderr] (Controller Boot Thread) at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,915 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,915 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,920 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:722)
> 10:53:44,920 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,921 ERROR [stderr] (Controller Boot Thread) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> 10:53:44,921 ERROR [stderr] (Controller Boot Thread) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,922 ERROR [stderr] (Controller Boot Thread) at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,922 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,924 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,925 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,925 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,927 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,927 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,929 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,929 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:722)
> 10:53:44,930 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread) at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,932 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,932 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,935 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,935 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,936 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,936 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,938 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,938 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:722)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months