August 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBMESSAGING-1928) MessagingClusterHealthMBean.makeSureDelay() can loop forever on a virtual machine

by Justin Bertram (JIRA)

Justin Bertram created JBMESSAGING-1928: ------------------------------------------- Summary: MessagingClusterHealthMBean.makeSureDelay() can loop forever on a virtual machine Key: JBMESSAGING-1928 URL: https://issues.jboss.org/browse/JBMESSAGING-1928 Project: JBoss Messaging Issue Type: Bug Components: JMS Clustering Affects Versions: 1.4.8.SP7 Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 1.4.8.SP8 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
5
0 / 0

[JBoss JIRA] (JBAS-9513) Ports conflict between ports-default and ports-10 config

by Shay Matasaro (JIRA)

Shay Matasaro created JBAS-9513: ----------------------------------- Summary: Ports conflict between ports-default and ports-10 config Key: JBAS-9513 URL: https://issues.jboss.org/browse/JBAS-9513 Project: Application Server 3 4 5 and 6 Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Shay Matasaro Assignee: Shay Matasaro -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
1
0 / 0

[JBoss JIRA] (AS7-2017) run.sh -h should show all command line switches

by Jim Tyrrell (Created) (JIRA)

run.sh -h should show all command line switches ----------------------------------------------- Key: AS7-2017 URL: https://issues.jboss.org/browse/AS7-2017 Project: Application Server 7 Issue Type: Feature Request Reporter: Jim Tyrrell This should show all of the options as in the past like -G -m -u -b and maybe an extended mode shows all of the possible -D options that can be passed in. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

7
7
0 / 0

[JBoss JIRA] (AS7-5407) Consider logging "Number of cluster members" on view change like is done at server startup

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-5407: ----------------------------------- Summary: Consider logging "Number of cluster members" on view change like is done at server startup Key: AS7-5407 URL: https://issues.jboss.org/browse/AS7-5407 Project: Application Server 7 Issue Type: Enhancement Components: Clustering Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Optional Fix For: 7.2.0.Alpha1 See https://community.jboss.org/message/754829#754829 Could we just do the same as for the startup? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3609) KnowledgeAgent and Guvnor still communicate in legacy rule Package classes and Guvnor stores it's package snapshots in the legacy class format

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created JBRULES-3609: ----------------------------------------- Summary: KnowledgeAgent and Guvnor still communicate in legacy rule Package classes and Guvnor stores it's package snapshots in the legacy class format Key: JBRULES-3609 URL: https://issues.jboss.org/browse/JBRULES-3609 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 5.4.0.Final Reporter: Geoffrey De Smet Priority: Blocker Fix For: 6.0.0.Beta1 Guvnor has 0 usages of the modern KnowledgeBase or KnowledgePackage. Instead, it's still completely based on the legacy Package of drools-core. For example: - The serialized class instance in the JCR repo is a legacy Package, not a modern KnowledgePackage - The serialized classes instance streamed to the KnowledgeAgent is a legacy Package, not a modern KnowledgePackage That's just the tip of the iceberg. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
2
0 / 0

[JBoss JIRA] (AS7-5404) Review use of 'default' for nillable 'roles' attributes in core-address

by Kabir Khan (JIRA)

Kabir Khan created AS7-5404: ------------------------------- Summary: Review use of 'default' for nillable 'roles' attributes in core-address Key: AS7-5404 URL: https://issues.jboss.org/browse/AS7-5404 Project: Application Server 7 Issue Type: Feature Request Components: JMS Reporter: Kabir Khan Assignee: Jeff Mesnil Fix For: 7.2.0.Alpha1 CompareModelVersionsUtil reports the following before and after the upgrade messaging to use resource definition {code} ====== Resource root address: ["subsystem" => "messaging"] - Current version: 1.2.0; legacy version: 1.2.0 ======= --- Problems for relative address to root ["hornetq-server" => "*","core-address" => "*"]: Different 'value-type' for attribute 'roles'. Current: { "name" => { "type" => STRING, "description" => "The name of the security role.", "expressions-allowed" => false, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L }, "send" => { "type" => BOOLEAN, "description" => "Whether the role has permission to send to the address.", "expressions-allowed" => false, "nillable" => false, "default" => false }, "consume" => { "type" => BOOLEAN, "description" => "Whether the role has permission to consume from the address.", "expressions-allowed" => false, "nillable" => false, "default" => false }, "create-durable-queue" => { "type" => BOOLEAN, "description" => "Whether the role has permission to create a durable queue.", "expressions-allowed" => false, "nillable" => false, "default" => false }, "delete-durable-queue" => { "type" => BOOLEAN, "description" => "Whether the role has permission to delete a durable queue.", "expressions-allowed" => false, "nillable" => false, "default" => false }, "create-non-durable-queue" => { "type" => BOOLEAN, "description" => "Whether the role has permission to create a non-durable queue.", "expressions-allowed" => false, "nillable" => false, "default" => false }, "delete-non-durable-queue" => { "type" => BOOLEAN, "description" => "Whether the role has permission to delete a non-durable queue.", "expressions-allowed" => false, "nillable" => false, "default" => false }, "manage" => { "type" => BOOLEAN, "description" => "Whether the role has permission to manage the address.", "expressions-allowed" => false, "nillable" => false, "default" => false } }; legacy: { "name" => { "description" => "The name of a security role.", "type" => STRING, "nillable" => false }, "send" => { "description" => "This permission allows the user to send a message to matching addresses.", "type" => BOOLEAN, "nillable" => false }, "consume" => { "description" => "his permission allows the user to consume a message from a queue bound to matching addresses.", "type" => BOOLEAN, "nillable" => false }, "create-durable-queue" => { "description" => "This permission allows the user to create a durable queue.", "type" => BOOLEAN, "nillable" => false }, "delete-durable-queue" => { "description" => "This permission allows the user to delete a durable queue.", "type" => BOOLEAN, "nillable" => false }, "create-non-durable-queue" => { "description" => "This permission allows the user to create a temporary queue.", "type" => BOOLEAN, "nillable" => false }, "delete-non-durable-queue" => { "description" => "This permission allows the user to delete a temporary queue.", "type" => BOOLEAN, "nillable" => false }, "manage" => { "description" => "This permission allows the user to invoke management operations by sending management messages to the management a ddress.", "type" => BOOLEAN, "nillable" => false } } {code} The attributes are actually fine, but I just noticed that in the new version you use defaults for non nillable attributes which sounds a bit strange to me. So the purpose of this JIRA is to get a fresh pair of eyes on this :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
1
0 / 0

[JBoss JIRA] (AS7-5366) runtime attribute is described with configuration storage in domain mode

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-5366: -------------------------------- Summary: runtime attribute is described with configuration storage in domain mode Key: AS7-5366 URL: https://issues.jboss.org/browse/AS7-5366 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management Reporter: Jeff Mesnil Assignee: Brian Stansberry a messaging subsystem resource defines a *runtime* read-only attribute "started". In standalone mode, the attribute storage is described as "runtime". In domain mode, it is also the case when accessing the server directly: {noformat} [domain@localhost:9999 /] /host=master/server=server-one/subsystem=messaging/hornetq-server=default/in-vm-acceptor=in-vm:read-resource-description { ... "started" => { "description" => "Whether this acceptor is started.", "type" => BOOLEAN, "nillable" => false, "access-type" => "read-only", "storage" => "runtime" } } {noformat} However when the resource is described through the domain's profile, it is erroneously described with a "configuration" storage: {noformat} [domain@localhost:9999 /] /profile=full/subsystem=messaging/hornetq-server=default/in-vm-acceptor=in-vm:read-resource-description { ... "started" => { "description" => "Whether this acceptor is started.", "type" => BOOLEAN, "nillable" => false, "access-type" => "read-only", "storage" => "configuration" } } {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
7
0 / 0

[JBoss JIRA] (EJBTHREE-2286) Exception handling of EJB container for MDB is incorrect

by Adam Kovari (JIRA)

13 years, 10 months

1
2
0 / 0

[JBoss JIRA] (AS7-5329) Transaction leak protection for web requests is too restrictive (possibly violating the spec)

by Marko Strukelj (JIRA)

Marko Strukelj created AS7-5329: ----------------------------------- Summary: Transaction leak protection for web requests is too restrictive (possibly violating the spec) Key: AS7-5329 URL: https://issues.jboss.org/browse/AS7-5329 Project: Application Server 7 Issue Type: Bug Components: Transactions, Web Affects Versions: 7.1.2.Final (EAP) Reporter: Marko Strukelj Assignee: Jason Greene In order to prevent leaking active transactions from processing of web requests a TransactionRollbackSetupAction is installed by transactions subsystem for web subsystem to use. This causes usecases where we want JTA TX to span different web apps over cross-context includes to fail, as the setup action is applied around each cross-context include, and forcefully rolls back any TX still active at the end of dispatching. A concrete use case are portals that rely on cross-context includes. Java EE Platform 6 Spec says the following in section EE.4.2.2: "Returning from the service method to the network client with an active transaction context is an error. The web container is required to detect this error and abort the transaction. As specified above in Section EE.4.2.1.2, “Transaction Non-Requirements,” requests made within a web container using the RequestDispatcher must propagate any transaction context to the called class. Unless the called class commits or aborts the transaction, the transaction must remain active when the called class returns." There is no talk here about cross-context includes or application boundaries. Therefore it seems the current implementation is not spec-compliant. TransactionRollbackSetupAction should only be applied on an original incoming web request, not on each cross-context include. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

4
5
0 / 0

[JBoss JIRA] (AS7-2832) subdeployment dependency to a module with optional="true" leads to a deployment failure when the dependency not available

by Radim Hanus (Created) (JIRA)

subdeployment dependency to a module with optional="true" leads to a deployment failure when the dependency not available ------------------------------------------------------------------------------------------------------------------------- Key: AS7-2832 URL: https://issues.jboss.org/browse/AS7-2832 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.0.Beta1 Reporter: Radim Hanus details in referenced forum thread -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

4
4
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 August 2012