[JBoss JIRA] (JBRULES-3247) PlanningEntityDescriptor does not support write-only properties
by Cédric Schaller (Created) (JIRA)
PlanningEntityDescriptor does not support write-only properties
---------------------------------------------------------------
Key: JBRULES-3247
URL: https://issues.jboss.org/browse/JBRULES-3247
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-planner
Affects Versions: 5.3.0.CR1
Reporter: Cédric Schaller
Assignee: Mark Proctor
The following code:
{code:java}
Method propertyGetter = propertyDescriptor.getReadMethod();
if (propertyGetter.isAnnotationPresent(PlanningVariable.class)) {
{code}
in method {{processPropertyAnnotations()}} assumes that properties always have getters. However, the method {{getReadMethod()}} might indeed return {{null}} if the property is write-only, as explained in the JavaBeans(TM) Specification 1.01 Final Release. A null-check should therefore be added in order to prevent NullPointerExceptions.
--
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, 9 months
[JBoss JIRA] (AS7-2364) CLI Response Verbosity
by Rich Sharples (Created) (JIRA)
CLI Response Verbosity
----------------------
Key: AS7-2364
URL: https://issues.jboss.org/browse/AS7-2364
Project: Application Server 7
Issue Type: Clarification
Components: CLI
Affects Versions: 7.1.0.Alpha1
Environment: all
Reporter: Rich Sharples
Assignee: Alexey Loubyansky
Fix For: 7.1.0.Beta1
The output of the CLI easily interpreted by a machine. Not so easy for a human.
For example, typical error :
{
"outcome" => "failed",
"failure-description" => "No handler for read-operation-namess at address [
(\"server-group\" => \"main-server-group\"),
(\"jvm\" => \"default\")
]",
"rolled-back" => true
}
could be translated to :
ERROR : No handler for "read-operation-namess" command at address server-group=main-server-group, jvm=default
I suggest two modes of operation - human readable responses and verbose (machine readable) responses.
--
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, 9 months
[JBoss JIRA] (JBMESSAGING-1902) JBMessaging cluster stops working after a node gets suspended (kill -STOP) and unsuspended (kill -CONT) after few minutes
by Tom Ross (Created) (JIRA)
JBMessaging cluster stops working after a node gets suspended (kill -STOP) and unsuspended (kill -CONT) after few minutes
-------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1902
URL: https://issues.jboss.org/browse/JBMESSAGING-1902
Project: JBoss Messaging
Issue Type: Feature Request
Components: JMS Clustering
Affects Versions: 1.4.8.SP3
Environment: JBoss EAP 5.1.0
Reporter: Tom Ross
Assignee: Yong Hao Gao
Priority: Blocker
This is a very simple cases where two node JBoss Messaging cluster stops working after one node gets suspended (kill -STOP) for few minutes. It would appear that when the node wakes up from the suspension it misses jgroups notifications and carries on as if nothing ever happened. Meantime while the node was suspended the remaining node performed failover and deleted the suspended node from the jbm_cluster table.
How to reproduce the problem.
Create a two node cluster using all profile.
start node 1
start node 2
after both nodes are running
find out pid of the JVM hosting node 2 and pid of the shell process
ps -fu ${user-name} | grep java
kill -STOP pid-jvm
kill -STOP shell running jvm
wait 5 minutes
kill -CONT shell running jvm
kill -CONT pid-jvm
Observe that
node 1 has noticed that node 2 is missing and performed failover
node 2 has been remved from JBM_CLUSTER table.
JGroups is functioning normally
JBM cluster is not working node 2 is not part of the cluster any longer.
--
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, 9 months
[JBoss JIRA] (AS7-2326) Build fails on Windows in cmp module due to org.codehaus.mojo:javacc-maven-plugin:2.3-jboss-1
by Marko Strukelj (Created) (JIRA)
Build fails on Windows in cmp module due to org.codehaus.mojo:javacc-maven-plugin:2.3-jboss-1
---------------------------------------------------------------------------------------------
Key: AS7-2326
URL: https://issues.jboss.org/browse/AS7-2326
Project: Application Server 7
Issue Type: Bug
Components: Build System
Environment: JBoss AS 7.1.0.Alpha2-SNAPSHOT, Windows 7
Reporter: Marko Strukelj
Assignee: Paul Gier
Build of current master fails on Windows in cmp module with:
[ERROR] Failed to execute goal org.codehaus.mojo:javacc-maven-plugin:2.3-jboss-1:jjtree (jjtree-jbossql) on project jboss-as-cmp: Execution jjtree-jbossql of goal org.codehaus.mojo:javacc-maven-plugin:2.3-jboss-1:jjtree failed: basedir C:\development\git-root\jboss-as7\cmp\C:\development\git-root\jboss-as7\cmp\src\main\jjtree does not exist -> [Help 1]
Looks like a bug (or misconfiguration) in org.codehaus.mojo:javacc-maven-plugin:2.3-jboss-1 - wrong source path generation.
AS 7.1.0.Alpha1 builds fine.
--
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, 9 months