[JBoss JIRA] (WFLY-9161) JobControlTestCase fails with security manager
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-9161?page=com.atlassian.jira.plugin.... ]
Yeray Borges resolved WFLY-9161.
--------------------------------
Fix Version/s: 11.0.0.CR1
Resolution: Cannot Reproduce Bug
Issue already solved by WFLY-9208
> JobControlTestCase fails with security manager
> ----------------------------------------------
>
> Key: WFLY-9161
> URL: https://issues.jboss.org/browse/WFLY-9161
> Project: WildFly
> Issue Type: Bug
> Components: Batch, Test Suite
> Reporter: Hynek Švábek
> Assignee: Yeray Borges
> Fix For: 11.0.0.CR1
>
>
> JobControlTestCase fails with security manager
> Some tests fail with:
> {code}
> aused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/hsvabek/securityworkspace/VERIFICATION/2017_08_02_BEAP-7584/jboss-eap-7.1.0.ER3-src/testsuite/integration/basic/target/jbossas/standalone/tmp/auth/local2441956400719098652.challenge" "read")" in code source "(vfs:/content/test-batch.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test-batch.war" from Service Module Loader")
> DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Server rejected authentication
> at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:109)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:400)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:542)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:504)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:492)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118)
> ... 155 more
> ...
> {code}
> or
> {code}
> Suppressed: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/hsvabek/securityworkspace/VERIFICATION/2017_08_02_BEAP-7584/jboss-eap-7.1.0.ER3-src/testsuite/integration/basic/target/jbossas/standalone/tmp/auth/local471205335337215113.challenge" "read")" in code source "(vfs:/content/test-batch.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test-batch.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350)
> at java.io.FileInputStream.<init>(FileInputStream.java:127)
> at org.wildfly.security.sasl.localuser.LocalUserClient.evaluateMessage(LocalUserClient.java:93)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.util.AbstractSaslClient.evaluateChallenge(AbstractSaslClient.java:59)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.lambda$handleEvent$0(ClientConnectionOpenListener.java:644)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:898)
> ... 3 more
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (LOGMGR-52) Add option to WriterHandler to collapse repeated messages
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-52?page=com.atlassian.jira.plugin.... ]
James Perkins updated LOGMGR-52:
--------------------------------
Fix Version/s: 2.1.0.Alpha6
(was: 2.1.0.Alpha5)
> Add option to WriterHandler to collapse repeated messages
> ---------------------------------------------------------
>
> Key: LOGMGR-52
> URL: https://issues.jboss.org/browse/LOGMGR-52
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 2.1.0.Alpha6
>
>
> The WriterHandler could have a time interval configured wherein a repeated message would be collapsed.
> The last message would be stored in a field for comparison along with a nanoTime tag (the timestamp on the message is not adequate because the clock can have skew or be reset completely at any time). If the current message string equals the last message string, and collapsing is enabled, then instead of logging the message, a count is incremented. If the current message is not equal, then the stored message is logged with a tag indicating the number of repeats (i18n?) and then the next submitted message is logged.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (LOGMGR-131) Add format characters for module name, module version
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-131?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-131:
---------------------------------
Fix Version/s: 2.1.0.Alpha6
(was: 2.1.0.Alpha5)
> Add format characters for module name, module version
> -----------------------------------------------------
>
> Key: LOGMGR-131
> URL: https://issues.jboss.org/browse/LOGMGR-131
> Project: JBoss Log Manager
> Issue Type: Sub-task
> Reporter: David Lloyd
> Fix For: 2.1.0.Alpha6
>
>
> In JDK9, StackTraceElements contain moduleName and moduleVersion fields. This information is useful for debugging purposes, thus format characters should be allocated towards these values. Ideally it'll be something non-conflicting with respect to log4j and other common ancestor/related frameworks, but that is less important than the basic support.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months