November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-765) Release PicketBox 4.0.20.Beta2

by Stefan Guilhen (JIRA)

Stefan Guilhen created SECURITY-765: --------------------------------------- Summary: Release PicketBox 4.0.20.Beta2 Key: SECURITY-765 URL: https://issues.jboss.org/browse/SECURITY-765 Project: PicketBox Issue Type: Task Security Level: Public (Everyone can see) Components: JBossSX, Security SPI Reporter: Stefan Guilhen Assignee: Stefan Guilhen -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2442) Add comments to modify-wsdl-address and wsdl-host elements in jboss-as-webservices_1_2.xsd

by R Searls (JIRA)

[ https://issues.jboss.org/browse/WFLY-2442?page=com.atlassian.jira.plugin.... ] R Searls resolved WFLY-2442. ---------------------------- Resolution: Done https://github.com/wildfly/wildfly/pull/5412 submitted > Add comments to modify-wsdl-address and wsdl-host elements in jboss-as-webservices_1_2.xsd > ------------------------------------------------------------------------------------------- > > Key: WFLY-2442 > URL: https://issues.jboss.org/browse/WFLY-2442 > Project: WildFly > Issue Type: Documentation > Security Level: Public(Everyone can see) > Components: Web Services > Reporter: R Searls > Assignee: R Searls > Priority: Minor > Fix For: 8.0.0.CR1 > > > This is to accomdate the bugzilla request > https://bugzilla.redhat.com/show_bug.cgi?id=1016598 > Bug 1016598 - Add comments to modify-wsdl-address and wsdl-host elements in jboss-as-webservices_1_2.xsd -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2293) Security subsystem is not considering the "module" attribute for JASPI "auth-module" elements

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFLY-2293?page=com.atlassian.jira.plugin.... ] Stefan Guilhen closed WFLY-2293. -------------------------------- Resolution: Duplicate Issue Original Issue: https://issues.jboss.org/browse/WFLY-2108 > Security subsystem is not considering the "module" attribute for JASPI "auth-module" elements > --------------------------------------------------------------------------------------------- > > Key: WFLY-2293 > URL: https://issues.jboss.org/browse/WFLY-2293 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Beta1 > Reporter: Pedro Igor > > This issue impacts users from using their own ServerAuthModule implementations from other modules. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1664) bin]$ ./jboss-cli.sh -c --controller=localhost:9999 - Results in Connection Timed Out

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1664?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-1664: ---------------------------------------- Summary of address handling: - https://community.jboss.org/wiki/CLIConnections-AddressHandling > bin]$ ./jboss-cli.sh -c --controller=localhost:9999 - Results in Connection Timed Out > ------------------------------------------------------------------------------------- > > Key: WFLY-1664 > URL: https://issues.jboss.org/browse/WFLY-1664 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: CLI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.CR1 > > > Port 9999 is by default the native management interface. > The command './jboss-cli.sh -c --controller=localhost:9999' results in the following error: - > {code} > org.jboss.as.cli.CliInitializationException: Failed to connect to the controller > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:291) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:269) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.modules.Module.run(Module.java:270) > at org.jboss.modules.Main.main(Main.java:411) > Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9999 > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:967) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:806) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:778) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:289) > ... 8 more > Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9999. The connection timed out > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:945) > ... 11 more > Caused by: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9999. The connection timed out > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:131) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:176) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:162) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:124) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:115) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:90) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > ... 13 more > {code} > This is because the use of HTTP upgrade is assumed, however clients using the CLI from previous versions were used to using this connection command against the native management interface only. > Workaround: - > Add the URI scheme to the controller paramter: - > {code} > ./jboss-cli.sh -c --controller=remote://localhost:9999 > {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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2443) JMS service shutsdown and doesn't recover after disk fills up.

by Corey Puffalt (JIRA)

Corey Puffalt created WFLY-2443: ----------------------------------- Summary: JMS service shutsdown and doesn't recover after disk fills up. Key: WFLY-2443 URL: https://issues.jboss.org/browse/WFLY-2443 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS Environment: RHEL 5.2 JDK 1.7.0_07 Reporter: Corey Puffalt Assignee: Jeff Mesnil Priority: Critical In AS 7.1.2 we had a disk fill up and we see warnings (not an error??): {code} 06:07:40,641 WARNING [org.hornetq.core.server.impl.HornetQServerImpl] (Thread-1973 (HornetQ-remoting-threads-HornetQServerImpl::serverUUID=d7fd8a09-5f3c-11e2-a072-49b352663c05-1554718086-1713338353)) Critical IO Error, shutting down the server. code=6, message=No space left on device 06:07:40,892 WARN [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (Thread-15478 (HornetQ-client-global-threads-251718996)) Connection failure has been detected: The connection was disconnected because of server shutdown [code=4] 06:07:40,893 WARN [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-15478 (HornetQ-client-global-threads-251718996)) being disconnected for server shutdown: HornetQException[errorCode=4 message=The connection was disconnected because of server shutdown] at org.hornetq.core.client.impl.ClientSessionFactoryImpl$Channel0Handler$1.run(ClientSessionFactoryImpl.java:1468) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07] {code} After the disk space issue was resolved JMS services didn't recover (though we didn't notice this for awhile) so we didn't restart JBoss as we didn't realize there was an issue. In checking the logs after the fact we see periodic warnings (again, it seems strange this is just a warning instead of an error): {code} 08:28:51,564 WARN [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Periodic Recovery) Can't connect to XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null] on auto-generated resource recovery: HornetQException[errorCode=2 message=Cannot connect to server(s). Tried with all available servers.] at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:774) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:347) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:262) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:76) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:503) [jbossjts-4.16.4.Final.jar:] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:471) [jbossjts-4.16.4.Final.jar:] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:385) [jbossjts-4.16.4.Final.jar:] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:166) [jbossjts-4.16.4.Final.jar:] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-4.16.4.Final.jar:] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-4.16.4.Final.jar:] 08:28:51,646 WARN [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Periodic Recovery) Can't connect to any hornetq server on recovery [XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]] 08:28:51,647 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Error trying to connect to any providers for xa recovery at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:76) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:503) [jbossjts-4.16.4.Final.jar:] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:471) [jbossjts-4.16.4.Final.jar:] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:385) [jbossjts-4.16.4.Final.jar:] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:166) [jbossjts-4.16.4.Final.jar:] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-4.16.4.Final.jar:] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-4.16.4.Final.jar:] Caused by: HornetQException[errorCode=2 message=null] at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:396) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:262) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] ... 7 more {code} It seems if the whole server process isn't going to shutdown when the disk fills up then services like JMS should just reject messages if the disk fills up rather than shutting down. That way services nicely recover as soon as there's disk space again. The way it is currently, it's easy to miss that JBoss is only partially inoperable. Thanks, Corey -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1850) Add support for aliases to be defined in the jboss-cli.xml for connection settings.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1850?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-1850: ---------------------------------------- Summary of address handling: - https://community.jboss.org/wiki/CLIConnections-AddressHandling > Add support for aliases to be defined in the jboss-cli.xml for connection settings. > ----------------------------------------------------------------------------------- > > Key: WFLY-1850 > URL: https://issues.jboss.org/browse/WFLY-1850 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: CLI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 8.0.0.CR1 > > > An alias would allow > connect {alias_name} > With the scheme/protocol, host name and port loaded from the config. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2435) Upgrade Generic JMS RA to 1.0.1.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2435?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2435: ----------------------------------------------- Dimitris Andreadis <dandread(a)redhat.com> made a comment on [bug 1026397|https://bugzilla.redhat.com/show_bug.cgi?id=1026397] Thanks Jeff. > Upgrade Generic JMS RA to 1.0.1.Final > ------------------------------------- > > Key: WFLY-2435 > URL: https://issues.jboss.org/browse/WFLY-2435 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.CR1 > > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2383) resource-adapter id attribute has to match ra name otherwise MDB is not deployed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2383: ----------------------------------------------- Dimitris Andreadis <dandread(a)redhat.com> made a comment on [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044] Stefano, are you looking at it? This is the final week to get fixes for CR, which should hopefully be the last build. > resource-adapter id attribute has to match ra name otherwise MDB is not deployed > -------------------------------------------------------------------------------- > > Key: WFLY-2383 > URL: https://issues.jboss.org/browse/WFLY-2383 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-87) NDC formatting is wrong with AsyncHandler

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-87?page=com.atlassian.jira.plugin.... ] James Perkins reassigned LOGMGR-87: ----------------------------------- Assignee: James Perkins (was: David Lloyd) > NDC formatting is wrong with AsyncHandler > ----------------------------------------- > > Key: LOGMGR-87 > URL: https://issues.jboss.org/browse/LOGMGR-87 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Valter Karacek > Assignee: James Perkins > > NDC information is not logged when used with asynchronous log handler. > The problem appears to be with Formatters.ndcFormatStep that return the value from NDC class, instead getting from ExtLogRecord.getNdc(). > <pattern-formatter pattern="%d | %-5p | [%c] | (%t:%x) | %m%n"/> -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-87) NDC formatting is wrong with AsyncHandler

by Valter Karacek (JIRA)

Valter Karacek created LOGMGR-87: ------------------------------------ Summary: NDC formatting is wrong with AsyncHandler Key: LOGMGR-87 URL: https://issues.jboss.org/browse/LOGMGR-87 Project: JBoss Log Manager Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Valter Karacek Assignee: David Lloyd NDC information is not logged when used with asynchronous log handler. The problem appears to be with Formatters.ndcFormatStep that return the value from NDC class, instead getting from ExtLogRecord.getNdc(). <pattern-formatter pattern="%d | %-5p | [%c] | (%t:%x) | %m%n"/> -- 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, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2013