[JBoss JIRA] (SECURITY-770) Support external password for keystore of PicketBoxVault implementation
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/SECURITY-770?page=com.atlassian.jira.plug... ]
Ivo Studensky updated SECURITY-770:
-----------------------------------
Attachment: (was: SECURITY-770.patch)
> Support external password for keystore of PicketBoxVault implementation
> -----------------------------------------------------------------------
>
> Key: SECURITY-770
> URL: https://issues.jboss.org/browse/SECURITY-770
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Attachments: SECURITY-770_with_testcase.patch
>
>
> At the moment, the default implementation of Vault supports masked keystore password only. It would be nice to add a facility for external keystore password too so that customers can either define an external command to get the password or define their own class which provides a password for the keystore.
--
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, 4 months
[JBoss JIRA] (SECURITY-770) Support external password for keystore of PicketBoxVault implementation
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/SECURITY-770?page=com.atlassian.jira.plug... ]
Ivo Studensky updated SECURITY-770:
-----------------------------------
Attachment: SECURITY-770_with_testcase.patch
Updated the patch with new test-cases.
> Support external password for keystore of PicketBoxVault implementation
> -----------------------------------------------------------------------
>
> Key: SECURITY-770
> URL: https://issues.jboss.org/browse/SECURITY-770
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Attachments: SECURITY-770_with_testcase.patch
>
>
> At the moment, the default implementation of Vault supports masked keystore password only. It would be nice to add a facility for external keystore password too so that customers can either define an external command to get the password or define their own class which provides a password for the keystore.
--
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, 4 months
[JBoss JIRA] (DROOLS-357) Multiple static initialization makes debugging Maven issues impossible
by Lukáš Petrovický (JIRA)
Lukáš Petrovický created DROOLS-357:
---------------------------------------
Summary: Multiple static initialization makes debugging Maven issues impossible
Key: DROOLS-357
URL: https://issues.jboss.org/browse/DROOLS-357
Project: Drools
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Reporter: Lukáš Petrovický
Assignee: Mario Fusco
When running kie-ci tests against productized binaries, most of the tests in that module fail with this particular exception (or similar):
java.lang.NoClassDefFoundError: Could not initialize class org.kie.scanner.MavenRepository
at org.kie.scanner.KieModuleMavenTest.testKieModulePojoDependencies(KieModuleMavenTest.java:119)
Turns out, this exception is (through multiple levels of static initialization) actually caused here:
https://github.com/droolsjbpm/drools/blob/master/kie-ci/src/main/java/org...
Maven resolution fails, because it cannot find some dependencies in the project being loaded. As a result, the class is never initialized, fast forward two other classes, and you get the above exception. I kindly ask that this behavior be changed in such a way that the original exception bubbles up through the stack - otherwise, the user has no chance to figure out what's going on.
The issue is a bit tricky to reproduce, as it's directly related to artifacts not being resolvable - but it should, if my understanding of the error is correct, be enough to have a parser error in the POM that's being loaded.
--
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, 4 months
[JBoss JIRA] (WFLY-2589) ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2589?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-2589:
----------------------------------
When doing this when reading the legacy model, it should be done with :read-resource(recursive=true,include-aliases=false,include-defaults=false) so that we don't have defaults in either the directly transformed model or the model built up from the operations.
> ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2589
> URL: https://issues.jboss.org/browse/WFLY-2589
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
> This needs a bit of thinking about [~jmesnil] mentioned this a few weeks ago as well. I'd like to see if he remembers before fixing
--
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, 4 months
[JBoss JIRA] (WFLY-2589) ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2589?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-2589:
----------------------------------
In domain mode the defaults are not passed in. For the comparison in the tests, the defaults are nice in a way. Still, we should probably work with what is correct.
> ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2589
> URL: https://issues.jboss.org/browse/WFLY-2589
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
> This needs a bit of thinking about [~jmesnil] mentioned this a few weeks ago as well. I'd like to see if he remembers before fixing
--
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, 4 months
[JBoss JIRA] (WFLY-1569) Not possible to reload server when JTS transactions are activated
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ]
Stefano Maestri resolved WFLY-1569.
-----------------------------------
Resolution: Duplicate Issue
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
> Key: WFLY-1569
> URL: https://issues.jboss.org/browse/WFLY-1569
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
> - <jts/> tag under transactions subsystem
> - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
> at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)
> at org.jacorb.poa.POA.set_servant(POA.java:1979)
> at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)
> ... 5 more
> {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
10 years, 4 months
[JBoss JIRA] (WFLY-2469) Upgrade to HornetQ 2.4.0.CR1
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2469?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-2469:
------------------------------
Comment: was deleted
(was: Jeff Mesnil <jmesnil(a)redhat.com> made a comment on [bug 1029836|https://bugzilla.redhat.com/show_bug.cgi?id=1029836]
Description of problem:
If an error occurs and the JMS bridge tries to reconnect to the JMS provider to look up the JMS resources from its FailureHandler, it fails with the exception:
10:37:02,546 INFO [org.hornetq.jms.server] (pool-3-thread-3) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 1,000 ms
10:37:03,547 WARN [org.hornetq.jms.server] (pool-3-thread-3) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.apache.qpid.jndi.PropertiesFileInitialContextFactory from classloader ModuleClassLoader for Module "org.hornetq:main" from local module loader @ac44b88 (finder: local module finder @5d3ad33d (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
at org.jboss.as.naming.InitialContextFactoryBuilder.createInitialContextFactory(InitialContextFactoryBuilder.java:64)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:681) [rt.jar:1.6.0_24]
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305) [rt.jar:1.6.0_24]
at javax.naming.InitialContext.init(InitialContext.java:240) [rt.jar:1.6.0_24]
at javax.naming.InitialContext.<init>(InitialContext.java:214) [rt.jar:1.6.0_24]
at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55) [hornetq-jms-server.jar:]
at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40) [hornetq-jms-server.jar:]
at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1222) [hornetq-jms-server.jar:]
at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1460) [hornetq-jms-server.jar:]
at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2000(JMSBridgeImpl.java:83) [hornetq-jms-server.jar:]
at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2049) [hornetq-jms-server.jar:]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
How reproducible:
Always
Steps to Reproduce:
1. run a jms-bridge with a JMS provider loaded from a module
2. disconnect the network to make the jms-bridge fails
3. reconnect the network. The jms-bridge will handle the failure and reconnects to the JMS provider
Actual results:
The jms-bridge FailureHandler is not able to load the JMS provider classes.
Expected results:
The jms-bridge FailureHandler must be able to load the JMS provider classes from the module specified when the jms-bridge is added.)
> Upgrade to HornetQ 2.4.0.CR1
> ----------------------------
>
> Key: WFLY-2469
> URL: https://issues.jboss.org/browse/WFLY-2469
> Project: WildFly
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.CR1
>
>
> HornetQ 2.4.0.CR1 depends on Netty 4.0.x versions that broke compatibility with Netty 3.x
--
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, 4 months