[JBoss JIRA] Created: (JBRULES-3211) Rules fires on incorrect condition
by Tommy Odom (JIRA)
Rules fires on incorrect condition
----------------------------------
Key: JBRULES-3211
URL: https://issues.jboss.org/browse/JBRULES-3211
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.2.0.Final
Reporter: Tommy Odom
Assignee: Mark Proctor
We are running into some issues after upgrading to Drools 5.2.0 from Drools 5.1.1. Our rules are no longer executing correctly. The wrong rule fires due to the constraints of a previous rule. I wrote a standalone test that replicates the problem and I've tested with 5.3.0-SNAPSHOT and the tests fail there as well.
Forgive me if what I state is incorrect but I figured I'd try to relay some of what I observed in debugging. It appears that the difference between 5.1.1 and 5.2.0 comes from the handling of the constraints. In 5.1.1, the constraints were created as PredicateConstraints but in 5.2.0 they are being created as LiteralConstraints. As such, in 5.1.1 in the CompositeObjectSinkAdapter adds the new sinks as otherSinks but in 5.2.0 they are registered as FieldIndexes. However, the index value on all of the MVELClassFieldReader instances is 0 so both "engine.engineType.id" and "engine.id" are mapped to the same FieldIndex.
I haven't had time yet to dig into the code to understand the difference between a PredicateConstraint and a LiteralConstraint so I'm not sure if there's something I could be doing differently to avoid this problem.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JBMESSAGING-1896) MessagingClusterHealthMBean may block when stopping a node
by Yong Hao Gao (Created) (JIRA)
MessagingClusterHealthMBean may block when stopping a node
----------------------------------------------------------
Key: JBMESSAGING-1896
URL: https://issues.jboss.org/browse/JBMESSAGING-1896
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Clustering
Affects Versions: 1.4.8.SP3, 1.4.0.SP3.CP14
Reporter: Yong Hao Gao
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP15, 1.4.8.SP4
When a node is shunned from the node but at the same time its DB is also disconnected, the MessagingClusterHealthMBean will shut down the node in the jgroups thread. Because the shutdown happens in the process of view change, it will block on the MessagingPostOffice.stopViewUpdate() method. I will wait for the flag updateInProcess forever because it will never get a chance to update the flag. See the stack trace:
"Incoming-10,192.168.1.110:55200" prio=10 tid=0x00007f619c036800 nid=0x4b2e in Object.wait() [0x00007f618a24a000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000d94c55d8> (a java.lang.Object)
at java.lang.Object.wait(Object.java:502)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.stopViewUpdate(MessagingPostOffice.java:852)
- locked <0x00000000d94c55d8> (a java.lang.Object)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.stop(MessagingPostOffice.java:796)
at org.jboss.messaging.core.jmx.MessagingPostOfficeService.stopService(MessagingPostOfficeService.java:554)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:405)
at org.jboss.system.ServiceMBeanSupport.stop(ServiceMBeanSupport.java:281)
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:616)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.jms.server.MessagingClusterHealthMBean.stopService(MessagingClusterHealthMBean.java:140)
at org.jboss.jms.server.MessagingClusterHealthMBean.stopNodeOnDBFailure(MessagingClusterHealthMBean.java:107)
- locked <0x00000000d731a520> (a org.jboss.jms.server.MessagingClusterHealthMBean)
at org.jboss.jms.server.ServerPeer.stopJBMNodeForRecovery(ServerPeer.java:2115)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.quarantine(MessagingPostOffice.java:1748)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:1568)
at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:609)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:733)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:776)
at org.jgroups.JChannel.up(JChannel.java:1336)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:454)
at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:439)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:153)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:188)
at org.jgroups.protocols.FC.up(FC.java:493)
at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:543)
- locked <0x00000000d94b2c90> (a org.jgroups.Membership)
at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:463)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:749)
at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:192)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:328)
at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:895)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:708)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:136)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
at org.jgroups.protocols.FD.up(FD.java:284)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:328)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:144)
at org.jgroups.protocols.Discovery.up(Discovery.java:264)
at org.jgroups.protocols.PING.up(PING.java:273)
at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2319)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1253)
at org.jgroups.protocols.TP.access$100(TP.java:50)
at org.jgroups.protocols.TP$1.run(TP.java:1177)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
--
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
[JBoss JIRA] (JBCL-180) Classcast Exception while deploying an ear file in jboss 5.1.0
by suresh kumar (Created) (JIRA)
Classcast Exception while deploying an ear file in jboss 5.1.0
--------------------------------------------------------------
Key: JBCL-180
URL: https://issues.jboss.org/browse/JBCL-180
Project: JBoss ClassLoader
Issue Type: Bug
Components: ClassLoader, MetaData
Reporter: suresh kumar
Assignee: Ales Justin
Priority: Blocker
When we tried to migrate our application from jboss-3.2.7 to jboss-5.1.0, we faced this issue.Basically in our application, we have an EAR file packaged with couple of WAR files and a SAR file along with META-INF directory. While deploying the EAR file under server\default\deploy directory, we are getting the below error.Our application do not useany EJB related stuffs. Basically,this error is thrown when we have an SAR file and WAR files packaged together in an EAR file.
Caused by: java.lang.ClassCastException: org.jboss.metadata.ear.jboss.ServiceModuleMetaData cannot be cast to org.jboss.metadata.ear.spec.WebModuleMetaData
at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:327)
at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:97)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(Abstra
ctSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer
.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
... 30 more
--
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
[JBoss JIRA] (AS7-2141) Attribute socket-binding-port-offset for server-group cannot be set to 0
by Rostislav Svoboda (Created) (JIRA)
Attribute socket-binding-port-offset for server-group cannot be set to 0
------------------------------------------------------------------------
Key: AS7-2141
URL: https://issues.jboss.org/browse/AS7-2141
Project: Application Server 7
Issue Type: Bug
Components: CLI, Domain Management
Affects Versions: 7.1.0.Alpha1
Reporter: Rostislav Svoboda
Assignee: Brian Stansberry
Fix For: 7.1.0.CR1
Issue met when invoking these operations in CLI:
/server-group=main-server-group:write-attribute(name="socket-binding-port-offset", value=100)
/host=master/server-config=server-one:restart
/server-group=main-server-group:write-attribute(name="socket-binding-port-offset", value=0)
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "0 is an invalid value for parameter socket-binding-port-offset. A minimum value of 1 is required"},
"rolled-back" => true
}
In standard distribution there is no port offset defined for /server-group=main-server-group.
Tested with latest build from source codes pulled on 2011-10-18.
--
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
[JBoss JIRA] Created: (AS7-1774) NPE in JndiView
by Heiko Braun (JIRA)
NPE in JndiView
---------------
Key: AS7-1774
URL: https://issues.jboss.org/browse/AS7-1774
Project: Application Server 7
Issue Type: Bug
Components: Console
Reporter: Heiko Braun
Assignee: David Bosschaert
Fix For: 7.1.0.CR1
On the admin's console, when going on the naming view.
It's a null point exception that I get on org.jboss.as.ee.subsystem.EEJndiViewExtension.handleModule(JndiViewExtensionContext, DeploymentUnit, ModelNode, ServiceRegistry)
I avoid this, I added:
if (moduleDescription == null) return;
After this, the view is working and I can navigate in the JNDI view.
I have no idea why moduleDescription was null, perhaps it's something wrong with my deployment.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (AS7-1080) XA Datasource w/o xa-properties swllows an exception
by Heiko Braun (JIRA)
XA Datasource w/o xa-properties swllows an exception
----------------------------------------------------
Key: AS7-1080
URL: https://issues.jboss.org/browse/AS7-1080
Project: Application Server 7
Issue Type: Bug
Reporter: Heiko Braun
Fix For: 7.1.0.Alpha1
ry to add an XA Datasource but don't add any XA properties. You will get the error below on the server.
The problem is that the user doesn't see any error message at all. I assume that this is a known class of problem, but I mention here for bookkeeping purposes.
12:45:43,109 WARN [org.jboss.as.controller] (HttpManagementService-threads - 4) Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("xa-data-source" => "foo")
]): org.jboss.as.controller.OperationFailedException: org.jboss.jca.common.api.validator.ValidateException: IJ010069: Missing required element xa-datasource-property in o
rg.jboss.jca.common.metadata.ds.XADataSourceImpl [ "Failed to create XaDataSource instance for [{
\"operation\" => \"add\",
\"address\" => [
(\"subsystem\" => \"datasources\"),
(\"xa-data-source\" => \"foo\")
],
\"name\" => \"foo\",
\"jndi-name\" => \"bar\",
\"enabled\" => true,
\"driver-name\" => \"h2\",
\"driver-class-name\" => \"org.h2.Driver\",
\"driver-major-version\" => 1,
\"driver-minor-version\" => 2,
\"pool-name\" => \"foo_Pool\",
\"user-name\" => \"asdf\",
\"password\" => \"asdf\",
\"xa-data-source-properties\" => {}
}]
reason:IJ010069: Missing required element xa-datasource-property in org.jboss.jca.common.metadata.ds.XADataSourceImpl" ]
at org.jboss.as.connector.subsystems.datasources.XaDataSourceAdd.startConfigAndAddDependency(XaDataSourceAdd.java:64)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:93)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years