April 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-3455) Generated DRL uses deprecated # comment identifier

by Michael Anstis (JIRA)

Michael Anstis created JBRULES-3455: --------------------------------------- Summary: Generated DRL uses deprecated # comment identifier Key: JBRULES-3455 URL: https://issues.jboss.org/browse/JBRULES-3455 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-decisiontables Affects Versions: 5.2.0.Final Reporter: Michael Anstis Assignee: Michael Anstis Fix For: 5.5.0.Beta1 DRL generated for Decision Tables and Templates contains the deprecated # comment identifer -- 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

14 years, 1 month

2
42
0 / 0

[JBoss JIRA] (JBJCA-731) Eclipse plugin for Ironjacamar

by Jeff Zhang (JIRA)

Jeff Zhang created JBJCA-731: -------------------------------- Summary: Eclipse plugin for Ironjacamar Key: JBJCA-731 URL: https://issues.jboss.org/browse/JBJCA-731 Project: IronJacamar Issue Type: Task Components: Eclipse Reporter: Jeff Zhang Assignee: Jeff Zhang Fix For: 1.0.8.Final -- 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

14 years, 1 month

2
3
0 / 0

[JBoss JIRA] (AS7-4468) Cannot remove and re-add socket-binding group

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-4468: ------------------------------------- Summary: Cannot remove and re-add socket-binding group Key: AS7-4468 URL: https://issues.jboss.org/browse/AS7-4468 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.1.Final Reporter: Michael Voegele Assignee: Brian Stansberry Fix For: 7.1.2.Final-redhat1 Error message when trying to (remove and) add a socket-binding-group in domain mode: First remove: { "operation" => "remove", "address" => [("socket-binding-group" => "standard-sockets")] } Result: { "outcome" : "success", "result" : null, "server-groups" : {"server-group-1" : {"server-1" : { "host" : "master", "response" : {"outcome" : "success"} }}} } Now add again: { "name" : "standard-sockets", "default-interface" : "public", "operation" : "add", "address" : [{ "socket-binding-group" : "standard-sockets" }] } Result: { "outcome" : "failed", "result" : null, "failure-description" : "JBAS010839: Operation failed or was rolled back on all servers.", "rolled-back" : true, "server-groups" : {"server-group-1" : {"server-1" : { "host" : "master", "response" : { "outcome" : "failed", "failure-description" : "JBAS014749: Operation handler failed: Service jboss.socket-binding-manager is already registered", "rolled-back" : true } }}} } For me, this seems a bit strange. If an error shall be produced, then it should be thrown when removing the socket-binding-group, as there is a server running referencing the socket-binding-group via server-group. But if the socket-binding-group can be removed, it should also be possible to add it again (possibly with new defined socket-bindings in the group, then trigger a restart of the server in order to take the newly configured ports into account). -- 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

14 years, 1 month

3
19
0 / 0

[JBoss JIRA] (JGRP-1438) GMS shouldn't bundle requests that can't be processed together

by Benoit Leblanc (JIRA)

Benoit Leblanc created JGRP-1438: ------------------------------------ Summary: GMS shouldn't bundle requests that can't be processed together Key: JGRP-1438 URL: https://issues.jboss.org/browse/JGRP-1438 Project: JGroups Issue Type: Bug Affects Versions: 3.0, 3.1 Reporter: Benoit Leblanc Assignee: Bela Ban Priority: Minor GMS's Requests are divided into two categories: 1/ Can Be Processed Together (CBPT): JOIN, LEAVE and SUSPECT 2 Can Not Be Processed Together (CNBPT) : MERGE and JOIN_WITH_STATE_TRANSFER Bundling concerns only CBPT requests. So when a CNBPT request is received, it should be processed immediately. Currently, a MERGE request is postponed due to bundling instead of being executed immediately. Two conditions to unblock it: - Timeout expiration. - Receiving another message. Note that whatever the following message is, it can't be processed with CBPT message Expected behavior: Treating immediately CNBPT requests A simple solution: Bring a light modification to method GMS.ViewHandler.run() at line 1333 ------------- if(wait_time > 0) becomes : if(wait_time > 0 && firstRequest.canBeProcessedTogether(firstRequest)) ------------- Note that if a request can't be processed with a request of the same type => it coudn't be processed with any other request type -- 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

14 years, 1 month

2
3
0 / 0

[JBoss JIRA] (JBCLUSTER-297) HASingleton custom election policy isn't called with only one member

by James Livingston (JIRA)

James Livingston created JBCLUSTER-297: ------------------------------------------ Summary: HASingleton custom election policy isn't called with only one member Key: JBCLUSTER-297 URL: https://issues.jboss.org/browse/JBCLUSTER-297 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Components: HA-Server-API Affects Versions: HA-Server-API 1.2.0.Final Reporter: James Livingston Assignee: Paul Ferraro This is a backport of AS7-3295 to 5.x's clustering code. A custom HASingleton election policy is not called when there is only one member in the cluster. The hard-coded check for size == 1 should be removed, and the custom policy should always be called. This bug prevents policies that do not start HASingletons if a quorum is not reached. -- 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

14 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-1355) Enhance ExecutionRunner to allow for better extensibility and safe shut down

by William Burns (JIRA)

Enhance ExecutionRunner to allow for better extensibility and safe shut down ---------------------------------------------------------------------------- Key: JGRP-1355 URL: https://issues.jboss.org/browse/JGRP-1355 Project: JGroups Issue Type: Enhancement Affects Versions: 2.12.1 Reporter: William Burns Assignee: Bela Ban Fix For: 3.0 The ExecutionRunner class which is used for running distributed tasks currently doesn't allow for nice extensibility. This is caused due to no real hook points or callbacks to add additional local functionality if a user desires. One such functionality may be to automatically rollback or commit a local database transaction after the task is finished. This would allow for calling code to not have to care about transactional awareness and be more usuable across a target suite. Also today there is no nice way of shutting down an ExecutionRunner, it is done today purely with interrupts, and if a task is currently running this will receive an interrupt request which could be problematic. We should have a way so that when an ExecutionRunner is interrupted that it will shutdown only after finishing the current request or immediately if there is no request. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
8
0 / 0

[JBoss JIRA] Created: (JBVFS-166) Deployment archives that are symlinks do not get cached properly when jboss.vfs.forceCanonical is set to 'true'

by Mike Clark (JIRA)

Deployment archives that are symlinks do not get cached properly when jboss.vfs.forceCanonical is set to 'true' --------------------------------------------------------------------------------------------------------------- Key: JBVFS-166 URL: https://jira.jboss.org/browse/JBVFS-166 Project: JBoss VFS Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.GA Reporter: Mike Clark Assignee: John Bailey When a deployment, such as an .ear file, is a symlink and the jboss.vfs.forceCanonical property is set to "true" to address JBVFS-137, the deployment fails to be properly cached leading to an ever increasing vfs-nested.tmp directory. JBVFS-137 addresses the problem that permanentRoots in the VFSCache get set according to their canonical path by the URL PropertyEditor. Without the fix, if the deployment directory is a symlink, it will be stored in the cache using a different path than lookups will use. To correct this, when checking for items in the cache, the canonical path must be used, or else there will not be a match. Setting the jboss.vfs.forceCanonical property enables conversion of the deployment's path to a canonical path for this purpose. However, in the case of a deployment that is a symbolic link within the deploy directory (i.e., someApp.ear is itself a symbolic link), there is no initial modification of the path to a canonical path. (Because the URL is not being set via a PropertyEditor.) So, it is stored based on the non-canonical path. But, with jboss.vfs.forceCanonical set to true, the lookup is based on the canonical path, which doesn't match. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
7
0 / 0

[JBoss JIRA] Created: (JBRULES-3229) Stack overflow using recursive types

by Michael Anstis (JIRA)

Stack overflow using recursive types ------------------------------------ Key: JBRULES-3229 URL: https://issues.jboss.org/browse/JBRULES-3229 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Michael Anstis Assignee: Edson Tirelli The following DRL produces a stack overflow in org.drools.compiler.PackageBuilder$Node.accept(PackageBuilder.java:2684):- package com.sample declare Type child: Type end rule "test" when Type( ) then end -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
13
0 / 0

[JBoss JIRA] (AS7-3950) Add role handling with --silent mode into AddPropertiesUser (add-user.sh)

by Tomohisa igarashi (JIRA)

Tomohisa igarashi created AS7-3950: -------------------------------------- Summary: Add role handling with --silent mode into AddPropertiesUser (add-user.sh) Key: AS7-3950 URL: https://issues.jboss.org/browse/AS7-3950 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management Affects Versions: 7.1.0.Final Reporter: Tomohisa igarashi Assignee: Brian Stansberry When I add a user using AddPropertiesUser with --silent, there is no way to handle the role of that user right now. -- 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

14 years, 1 month

5
16
0 / 0

[JBoss JIRA] (AS7-3641) Lock down HornetQ default cluster user

by Justin Bertram (JIRA)

Justin Bertram created AS7-3641: ----------------------------------- Summary: Lock down HornetQ default cluster user Key: AS7-3641 URL: https://issues.jboss.org/browse/AS7-3641 Project: Application Server 7 Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram The HornetQ default cluster user is a security hole. AS7 should plug this hole when it starts HornetQ. -- 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

14 years, 1 month

2
5
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 April 2012