[JBoss JIRA] (SECURITY-750) Database*LoginModules should use the transactionManagerJndiName module option
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-750?page=com.atlassian.jira.plug... ]
Stefan Guilhen closed SECURITY-750.
-----------------------------------
Resolution: Done
DButils.getRolesSet() method now receives the TxManagerJNDIName as a parameter. Both DBLoginModules now allow configuration of the txManagerJNDI name and they both propagate the configured value (or the default java:/TransactionManager) to DBUtils when getting the roles.
> Database*LoginModules should use the transactionManagerJndiName module option
> -----------------------------------------------------------------------------
>
> Key: SECURITY-750
> URL: https://issues.jboss.org/browse/SECURITY-750
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Reporter: Stefan Guilhen
> Assignee: Stefan Guilhen
> Fix For: PIcketBox_4_0_19.Final
>
>
> The DatabaseCertLoginModule and DatabaseServerLoginModule use for role search a routine from a class org.jboss.security.auth.spi.DbUtil. But there is a hardcoded reference to JNDI name for Transaction Manager lookup "java:/TransactionManager" - which is not valid in the EAP 6. The JNDI name should be provided as a parameter.
> The login module option "transactionManagerJndiName" is already implemented in the DatabaseServerLoginModule, but it should be also added to the DatabaseCertLoginModule.
--
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
10 years, 8 months
[JBoss JIRA] (WFLY-1899) Conversation timeout is broken
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1899?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann updated WFLY-1899:
-------------------------------------
Attachment: server.log
I attached server.log after setting the TRACE level for org.jboss.weld.Servlet
> Conversation timeout is broken
> ------------------------------
>
> Key: WFLY-1899
> URL: https://issues.jboss.org/browse/WFLY-1899
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha4
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Attachments: server.log
>
>
> When I'm already logged in in a JSF web app and get a CDI/Weld conversation timeout, then an error page should be shown.
> However, I'm getting the stacktrace below, and a blank page instead of the error page is shown.
> The error page is configured in web.xml:
> {code}
> <error-page>
> <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>
> <location>/error/conversationTimeout.xhtml?nocid=true</location>
> </error-page>
> {code}
> Stacktrace with the current snapshot of WildFly using Undertow 1.0.0.Beta8 in the WildFly console:
> 16:20:12,466 ERROR [io.undertow.request] Exception while generating error page /error/conversationTimeout.xhtml?nocid=true: java.lang.RuntimeException: java.lang.IllegalStateException: JBAS017329: No security context found
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:394) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:315) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:222) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:623) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.IllegalStateException: JBAS017329: No security context found
> at org.wildfly.extension.undertow.security.SecurityActions$5.run(SecurityActions.java:119)
> at org.wildfly.extension.undertow.security.SecurityActions$5.run(SecurityActions.java:114)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.extension.undertow.security.SecurityActions.pushRunAsIdentity(SecurityActions.java:114)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:88)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:139) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:388) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> ... 10 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
10 years, 8 months
[JBoss JIRA] (DROOLS-245) Drools sees a type as a package
by georg tornqvist (JIRA)
georg tornqvist created DROOLS-245:
--------------------------------------
Summary: Drools sees a type as a package
Key: DROOLS-245
URL: https://issues.jboss.org/browse/DROOLS-245
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Reporter: georg tornqvist
Assignee: Mark Proctor
Hi,
I want Drools to reason over an axis2 type, but the Drools compiler sees the type as a package, see error message below.
Strictly speaking, the Drools compiler may be right. The type "Client" encapsulates a "Factory" class, making hierarchically speaking the class "Client" a package.
Although I'm fairly new to Drools, I'm pretty sure that the behavior I'm experiencing is not right. The Drools version used in the WSO2BRS-2.0.0 is able to reason over the very same axis2 types.
Error importing : 'nl.domain.www.schema.Client'
Rule Compilation error : [Rule name='Your First Rule']
io31/Rule_Your_First_Rule_16db2a632a4b4efd96dde4c6d6a55cdf.java (2:57) : Only a type can be imported.
nl.domain.www.schema.Client resolves to a package
--
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
10 years, 8 months
[JBoss JIRA] (SECURITY-751) Misleading stacktrace on server startup with malformed security-domain
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-751?page=com.atlassian.jira.plug... ]
Stefan Guilhen closed SECURITY-751.
-----------------------------------
Resolution: Done
There was an incorrect if-else clause in JBossJSSESecurityDomain that was causing the server to print this message when in fact the problem was that the KeyStore URL was null. This has been fixed in PicketBox.
> Misleading stacktrace on server startup with malformed security-domain
> ----------------------------------------------------------------------
>
> Key: SECURITY-751
> URL: https://issues.jboss.org/browse/SECURITY-751
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Reporter: Stefan Guilhen
> Assignee: Stefan Guilhen
> Fix For: PIcketBox_4_0_19.Final
>
>
> Description of problem:
> Misleading stack trace upon server startup. Occurs when adding a <security-domain> with a malformed <jsse> element.
> Version-Release number of selected component (if applicable):
> Picketbox version: 4.0.17.Final-redhat-1
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Start the server in standalone mode.
> ./standalone.sh
> 2. Run the following jboss-cli.sh commands:
> /subsystem=security/security-domain=test:add()
> /subsystem=security/security-domain=test1/jsse=classic:add(keystore={password=123456})
> :reload
> 3. See the stacktrace:
> 11:49:45,138 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.security.security-domain.test: org.jboss.msc.service.StartException in service jboss.security.security-domain.test: JBAS013308: Unable to start the SecurityDomainService service
> at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:107)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.RuntimeException: PBOX000117: Invalid KeyStore type: JKS
> at org.jboss.security.JBossJSSESecurityDomain.loadKeyAndTrustStore(JBossJSSESecurityDomain.java:469)
> at org.jboss.security.JBossJSSESecurityDomain.reloadKeyAndTrustStore(JBossJSSESecurityDomain.java:335)
> at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:104)
> ... 5 more
> Actual results:
> Stacktrace says that the keystore type "JKS" is not supported. This is the default keystore type, so this is not true.
> Expected results:
> I believe that the stacktrace should report that the keystore-url attribute is missing, since adding only that attribute causes the stacktrace to disappear.
--
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
10 years, 8 months
[JBoss JIRA] (WFLY-1385) Override default page-size-bytes in messaging subsystem configuration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1385?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1385:
-----------------------------------------------
Clebert Suconic <csuconic(a)redhat.com> made a comment on [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980]
Jeff is in vacations so I went to look at it.
@Miro: you're right.. this wasn't back ported...
I just sent the PR: https://github.com/jbossas/jboss-eap/pull/328
meaning it will be on the next version as soon as it's merged.
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
> Key: WFLY-1385
> URL: https://issues.jboss.org/browse/WFLY-1385
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 8.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
> Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
> at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown
--
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
10 years, 8 months
[JBoss JIRA] (WFLY-1899) Conversation timeout is broken
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1899?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-1899:
--------------------------------------
Can you enable TRACE logging for org.jboss.weld.Servlet?
Similar to WFLY-1533, this appears to be another issue that should not be able to happen unless listeners are not being invoked, which seems odd.
> Conversation timeout is broken
> ------------------------------
>
> Key: WFLY-1899
> URL: https://issues.jboss.org/browse/WFLY-1899
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha4
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
>
> When I'm already logged in in a JSF web app and get a CDI/Weld conversation timeout, then an error page should be shown.
> However, I'm getting the stacktrace below, and a blank page instead of the error page is shown.
> The error page is configured in web.xml:
> {code}
> <error-page>
> <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>
> <location>/error/conversationTimeout.xhtml?nocid=true</location>
> </error-page>
> {code}
> Stacktrace with the current snapshot of WildFly using Undertow 1.0.0.Beta8 in the WildFly console:
> 16:20:12,466 ERROR [io.undertow.request] Exception while generating error page /error/conversationTimeout.xhtml?nocid=true: java.lang.RuntimeException: java.lang.IllegalStateException: JBAS017329: No security context found
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:394) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:315) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:222) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:623) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.IllegalStateException: JBAS017329: No security context found
> at org.wildfly.extension.undertow.security.SecurityActions$5.run(SecurityActions.java:119)
> at org.wildfly.extension.undertow.security.SecurityActions$5.run(SecurityActions.java:114)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.extension.undertow.security.SecurityActions.pushRunAsIdentity(SecurityActions.java:114)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:88)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:139) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:388) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> ... 10 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
10 years, 8 months
[JBoss JIRA] (SECURITY-751) Misleading stacktrace on server startup with malformed security-domain
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-751?page=com.atlassian.jira.plug... ]
Stefan Guilhen updated SECURITY-751:
------------------------------------
Description:
Description of problem:
Misleading stack trace upon server startup. Occurs when adding a <security-domain> with a malformed <jsse> element.
Version-Release number of selected component (if applicable):
Picketbox version: 4.0.17.Final-redhat-1
How reproducible:
Always
Steps to Reproduce:
1. Start the server in standalone mode.
./standalone.sh
2. Run the following jboss-cli.sh commands:
/subsystem=security/security-domain=test:add()
/subsystem=security/security-domain=test1/jsse=classic:add(keystore={password=123456})
:reload
3. See the stacktrace:
11:49:45,138 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.security.security-domain.test: org.jboss.msc.service.StartException in service jboss.security.security-domain.test: JBAS013308: Unable to start the SecurityDomainService service
at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:107)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.RuntimeException: PBOX000117: Invalid KeyStore type: JKS
at org.jboss.security.JBossJSSESecurityDomain.loadKeyAndTrustStore(JBossJSSESecurityDomain.java:469)
at org.jboss.security.JBossJSSESecurityDomain.reloadKeyAndTrustStore(JBossJSSESecurityDomain.java:335)
at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:104)
... 5 more
Actual results:
Stacktrace says that the keystore type "JKS" is not supported. This is the default keystore type, so this is not true.
Expected results:
I believe that the stacktrace should report that the keystore-url attribute is missing, since adding only that attribute causes the stacktrace to disappear.
> Misleading stacktrace on server startup with malformed security-domain
> ----------------------------------------------------------------------
>
> Key: SECURITY-751
> URL: https://issues.jboss.org/browse/SECURITY-751
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Reporter: Stefan Guilhen
> Assignee: Stefan Guilhen
> Fix For: PIcketBox_4_0_19.Final
>
>
> Description of problem:
> Misleading stack trace upon server startup. Occurs when adding a <security-domain> with a malformed <jsse> element.
> Version-Release number of selected component (if applicable):
> Picketbox version: 4.0.17.Final-redhat-1
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Start the server in standalone mode.
> ./standalone.sh
> 2. Run the following jboss-cli.sh commands:
> /subsystem=security/security-domain=test:add()
> /subsystem=security/security-domain=test1/jsse=classic:add(keystore={password=123456})
> :reload
> 3. See the stacktrace:
> 11:49:45,138 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.security.security-domain.test: org.jboss.msc.service.StartException in service jboss.security.security-domain.test: JBAS013308: Unable to start the SecurityDomainService service
> at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:107)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.RuntimeException: PBOX000117: Invalid KeyStore type: JKS
> at org.jboss.security.JBossJSSESecurityDomain.loadKeyAndTrustStore(JBossJSSESecurityDomain.java:469)
> at org.jboss.security.JBossJSSESecurityDomain.reloadKeyAndTrustStore(JBossJSSESecurityDomain.java:335)
> at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:104)
> ... 5 more
> Actual results:
> Stacktrace says that the keystore type "JKS" is not supported. This is the default keystore type, so this is not true.
> Expected results:
> I believe that the stacktrace should report that the keystore-url attribute is missing, since adding only that attribute causes the stacktrace to disappear.
--
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
10 years, 8 months
[JBoss JIRA] (SECURITY-751) Misleading stacktrace on server startup with malformed security-domain
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-751?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration updated SECURITY-751:
---------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=979117
> Misleading stacktrace on server startup with malformed security-domain
> ----------------------------------------------------------------------
>
> Key: SECURITY-751
> URL: https://issues.jboss.org/browse/SECURITY-751
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Reporter: Stefan Guilhen
> Assignee: Stefan Guilhen
> Fix For: PIcketBox_4_0_19.Final
>
>
> Description of problem:
> Misleading stack trace upon server startup. Occurs when adding a <security-domain> with a malformed <jsse> element.
> Version-Release number of selected component (if applicable):
> Picketbox version: 4.0.17.Final-redhat-1
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Start the server in standalone mode.
> ./standalone.sh
> 2. Run the following jboss-cli.sh commands:
> /subsystem=security/security-domain=test:add()
> /subsystem=security/security-domain=test1/jsse=classic:add(keystore={password=123456})
> :reload
> 3. See the stacktrace:
> 11:49:45,138 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.security.security-domain.test: org.jboss.msc.service.StartException in service jboss.security.security-domain.test: JBAS013308: Unable to start the SecurityDomainService service
> at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:107)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.RuntimeException: PBOX000117: Invalid KeyStore type: JKS
> at org.jboss.security.JBossJSSESecurityDomain.loadKeyAndTrustStore(JBossJSSESecurityDomain.java:469)
> at org.jboss.security.JBossJSSESecurityDomain.reloadKeyAndTrustStore(JBossJSSESecurityDomain.java:335)
> at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:104)
> ... 5 more
> Actual results:
> Stacktrace says that the keystore type "JKS" is not supported. This is the default keystore type, so this is not true.
> Expected results:
> I believe that the stacktrace should report that the keystore-url attribute is missing, since adding only that attribute causes the stacktrace to disappear.
--
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
10 years, 8 months