[JBoss JIRA] (AS7-6389) Integrate prunsrv.exe for OOTB Windows service
by Nicklas Karlsson (JIRA)
Nicklas Karlsson created AS7-6389:
-------------------------------------
Summary: Integrate prunsrv.exe for OOTB Windows service
Key: AS7-6389
URL: https://issues.jboss.org/browse/AS7-6389
Project: Application Server 7
Issue Type: Enhancement
Components: Scripts
Affects Versions: 7.2.0.Alpha1
Environment: Windows
Reporter: Nicklas Karlsson
Assignee: Nicklas Karlsson
It would be nice to provide pre-configured scripts for running JBoss as a service on Windows. Tomaž Cerar hinted that the prunsrv.exe in use for EAP should also be used for the community version
--
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
13 years, 5 months
[JBoss JIRA] (JGRP-1571) Race condition in tcpgossip discovery
by Ramky Kandula (JIRA)
Ramky Kandula created JGRP-1571:
-----------------------------------
Summary: Race condition in tcpgossip discovery
Key: JGRP-1571
URL: https://issues.jboss.org/browse/JGRP-1571
Project: JGroups
Issue Type: Bug
Affects Versions: 3.1
Reporter: Ramky Kandula
Assignee: Bela Ban
We are observing a race condition in TCPGOSSIP based discovery.
A is gossip router and B is a node connecting to gossip router.
Timer-1 on B starts connecting, does ping.
Timer-2 on B starts reconnecting
A sees this new connection and closes the old one from Timer-1 from B.
Timer-2 on B does ping
Timer-1 on B tries to do gossip_get and encounters broken pipe as the socket
is closed.
This process goes on forever.
Logs from Gossip Router A
=========================
2012-12-14 13:20:47,687 DEBUG [GossipRouter][] org.jgroups.stack.GossipRouter-
Accepted connection, socket is
Socket[addr=/192.168.1.11,port=21009,localport=12001]
2012-12-14 13:20:47,687 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] entering
receive loop
2012-12-14 13:20:47,749 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] received
CONNECT(group=TestCluster, addr=dd-ace1-20957,
logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
2012-12-14 13:20:47,749 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
/192.168.1.11, logical_addrs: dd-ace1-20957, dd-ace1-20957]] for
addr[dd-ace1-20957]. Closing old connection ...
2012-12-14 13:20:47,749 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] connection handshake completed, added
dd-ace1-20957 to group TestCluster
2012-12-14 13:20:47,749 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] processed CONNECT(group=TestCluster,
addr=dd-ace1-20957, logical_name=dd-ace1-20957,
physical_addrs=192.168.1.11:7800)
2012-12-14 13:20:48,875 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] received PING(group=null, addr=null)
2012-12-14 13:20:48,875 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] processed PING(group=null, addr=null)
2012-12-14 13:20:53,735 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] received CONNECT(group=TestCluster,
addr=dd-ace1-20957, logical_name=dd-ace1-20957,
physical_addrs=192.168.1.11:7800)
2012-12-14 13:20:53,736 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
/192.168.1.11, logical_addrs: dd-ace1-20957]] for addr[dd-ace1-20957]. Closing
old connection ...
2012-12-14 13:20:53,736 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] is being closed
2012-12-14 13:20:53,838 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957, dd-ace1-20957] connection handshake completed,
added dd-ace1-20957 to group TestCluster
2012-12-14 13:20:53,838 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957, dd-ace1-20957] processed
CONNECT(group=TestCluster, addr=dd-ace1-20957,
logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
2012-12-14 13:21:04,023 DEBUG [GossipRouter][] org.jgroups.stack.GossipRouter-
Accepted connection, socket is
Socket[addr=/192.168.1.11,port=37357,localport=12001]
2012-12-14 13:21:04,023 DEBUG [gossip-handlers--9881][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] entering
receive loop
2012-12-14 13:21:04,085 TRACE [gossip-handlers--9881][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] received
CONNECT(group=TestCluster, addr=dd-ace1-20957,
logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
2012-12-14 13:21:04,085 DEBUG [gossip-handlers--9881][]
org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
/192.168.1.11, logical_addrs: dd-ace1-20957, dd-ace1-20957]] for
addr[dd-ace1-20957]. Closing old connection ...
2012-12-14 13:21:04,086 DEBUG [gossip-handlers--9881][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] connection handshake completed, added
dd-ace1-20957 to group TestCluster
2012-12-14 13:21:04,086 TRACE [gossip-handlers--9881][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] processed CONNECT(group=TestCluster,
addr=dd-ace1-20957, logical_name=dd-ace1-20957,
physical_addrs=192.168.1.11:7800)
Logs from Gossip Client B
=========================
2012-12-14 13:20:47,687 DEBUG [GossipRouter][] org.jgroups.stack.GossipRouter-
Accepted connection, socket is
Socket[addr=/192.168.1.11,port=21009,localport=12001]
2012-12-14 13:20:47,687 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] entering
receive loop
2012-12-14 13:20:47,749 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] received
CONNECT(group=TestCluster, addr=dd-ace1-20957,
logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
2012-12-14 13:20:47,749 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
/192.168.1.11, logical_addrs: dd-ace1-20957, dd-ace1-20957]] for
addr[dd-ace1-20957]. Closing old connection ...
2012-12-14 13:20:47,749 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] connection handshake completed, added
dd-ace1-20957 to group TestCluster
2012-12-14 13:20:47,749 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] processed CONNECT(group=TestCluster,
addr=dd-ace1-20957, logical_name=dd-ace1-20957,
physical_addrs=192.168.1.11:7800)
2012-12-14 13:20:48,875 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] received PING(group=null, addr=null)
2012-12-14 13:20:48,875 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] processed PING(group=null, addr=null)
2012-12-14 13:20:53,735 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] received CONNECT(group=TestCluster,
addr=dd-ace1-20957, logical_name=dd-ace1-20957,
physical_addrs=192.168.1.11:7800)
2012-12-14 13:20:53,736 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
/192.168.1.11, logical_addrs: dd-ace1-20957]] for addr[dd-ace1-20957]. Closing
old connection ...
2012-12-14 13:20:53,736 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] is being closed
2012-12-14 13:20:53,838 DEBUG [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957, dd-ace1-20957] connection handshake completed,
added dd-ace1-20957 to group TestCluster
2012-12-14 13:20:53,838 TRACE [gossip-handlers--9882][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957, dd-ace1-20957] processed
CONNECT(group=TestCluster, addr=dd-ace1-20957,
logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
2012-12-14 13:21:04,023 DEBUG [GossipRouter][] org.jgroups.stack.GossipRouter-
Accepted connection, socket is
Socket[addr=/192.168.1.11,port=37357,localport=12001]
2012-12-14 13:21:04,023 DEBUG [gossip-handlers--9881][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] entering
receive loop
2012-12-14 13:21:04,085 TRACE [gossip-handlers--9881][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11] received
CONNECT(group=TestCluster, addr=dd-ace1-20957,
logical_name=dd-ace1-20957, physical_addrs=192.168.1.11:7800)
2012-12-14 13:21:04,085 DEBUG [gossip-handlers--9881][]
org.jgroups.stack.GossipRouter- Found old connection[ConnectionHandler[peer:
/192.168.1.11, logical_addrs: dd-ace1-20957, dd-ace1-20957]] for
addr[dd-ace1-20957]. Closing old connection ...
2012-12-14 13:21:04,086 DEBUG [gossip-handlers--9881][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] connection handshake completed, added
dd-ace1-20957 to group TestCluster
2012-12-14 13:21:04,086 TRACE [gossip-handlers--9881][]
org.jgroups.stack.GossipRouter- ConnectionHandler[peer: /192.168.1.11,
logical_addrs: dd-ace1-20957] processed CONNECT(group=TestCluster,
addr=dd-ace1-20957, logical_name=dd-ace1-20957,
physical_addrs=192.168.1.11:7800)
--
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
13 years, 5 months
[JBoss JIRA] (AS7-6378) BootstrapBundlesIntegration assumes META-INF/MANIFEST.MF is only available from 1 module
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6378?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6378:
----------------------------------
Comment: was deleted
(was: OT: it would be nice if these were repackaged to go in a package o.j.a.t.integration.domain.respawn. Add 'domain' to be more consistent with the resut of the module. Be sure to look at the pom though; a repackage will lead to the tests not running if we aren't careful.)
> BootstrapBundlesIntegration assumes META-INF/MANIFEST.MF is only available from 1 module
> ----------------------------------------------------------------------------------------
>
> Key: AS7-6378
> URL: https://issues.jboss.org/browse/AS7-6378
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Brian Stansberry
> Assignee: Thomas Diesler
> Fix For: 7.2.0.Alpha1
>
>
> BootstrapBundlesIntegration has this:
> {code}
> URL manifestURL = module.getClassLoader().getResource(JarFile.MANIFEST_NAME); // PROBLEM
> if (manifestURL != null) {
> InputStream input = manifestURL.openStream();
> try {
> Manifest manifest = new Manifest(input);
> if (OSGiManifestBuilder.isValidBundleManifest(manifest)) {
> return OSGiMetaDataBuilder.load(manifest);
> }
> } finally {
> input.close();
> }
> }
> {code}
> The line marked // PROBLEM is problematic, since a module may have more than one resource associated with the given path, and that call will return the URL for the first one found, and not necessarily a URL for a resource located inside the intended module. For example, in testing a patch for a different issue I found that the same call for module "org.jboss.netty" could return a URL pointing to:
> org/jboss/logging/main/jboss-logging-3.1.2.GA.jar
> javax/servlet/api/main/jboss-servlet-api_3.0_spec-1.0.2.Final.jar
> org/jboss/netty/main/netty-3.4.5.Final.jar
> The first two modules are listed as dependencies of org.jboss.netty.
> A module could also include more than one jar, again leading to the possibility of multiple URLs with only one being relevant. But I'm not sure what the intended behavior is in that case.
> Calling getResources(JarFile.MANIFEST_NAME) instead of getResource and then iterating through the enumeration and checking to see if the URL is associated with the target module would be a possible fix.
--
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
13 years, 5 months
[JBoss JIRA] (AS7-6387) Improper error handling when attempting to remove a server-config with a running server
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6387:
-------------------------------------
Summary: Improper error handling when attempting to remove a server-config with a running server
Key: AS7-6387
URL: https://issues.jboss.org/browse/AS7-6387
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.3.Final (EAP), 7.1.2.Final (EAP)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1
Trying to remove the config for server-one while it's still running produces an uninformative failure:
[domain@localhost:9999 /] /host=master/server-config=server-one:remove
{
"outcome" => "failed",
"result" => undefined,
"rolled-back" => true,
"server-groups" => undefined
}
An EAP 6 user reported a similar problem but with a different response:
[domain@localhost:9999 /] /host=xyz/server-config=as1:remove
{
"outcome" => "success",
"result" => {
"outcome" => "failed",
"failure-description" => "[core-service, path, server-config, system-property, jvm, interface]",
"rolled-back" => true
},
"failure-description" => undefined
}
--
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
13 years, 5 months
[JBoss JIRA] (LOGMGR-57) Log files cleanup for periodic-rotating-file-handler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-57?page=com.atlassian.jira.plugin.... ]
James Perkins moved JBLOGGING-89 to LOGMGR-57:
----------------------------------------------
Project: JBoss Log Manager (was: JBoss Logging)
Key: LOGMGR-57 (was: JBLOGGING-89)
> Log files cleanup for periodic-rotating-file-handler
> ----------------------------------------------------
>
> Key: LOGMGR-57
> URL: https://issues.jboss.org/browse/LOGMGR-57
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Razvan Popa
> Assignee: David Lloyd
> Priority: Minor
>
> Hi,
> It would be useful for the periodic-rotating-file-handler to have a "max-backup-index" attribute to allow the removal of older files like in the size-rotating-file-handler.
> It would also be nice to have something like "archive-older-than" and "delete-older-than" to also keep some older files archived for a while.
> Regards,
> Razvan
--
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
13 years, 5 months
[JBoss JIRA] (AS7-6334) Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/AS7-6334?page=com.atlassian.jira.plugin.s... ]
James Perkins updated AS7-6334:
-------------------------------
Description:
Task to track the work we've all been doing on expressions/transformers.
See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
2) Basic transformation testing against 7.1.2 and 7.1.3
3) Reject-expression testing against 7.1.2 and 7.1.3
Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
Please edit this description and put an OK after the subsystem name to indicate it's good to go.
clustering/jgroups (OK)
clustering/infinispan
cmp
configadmin [OK]
connector/datasource
connector/jca [OK]
connector/resource-adapter
deployment-scanner
ee
ejb3 [OK]
jacorb - Just a note: the 'security' attribute transformation is not tested
jaxr OK
jaxrs - nothing to do, empty subsystem
jdr - nothing to do, empty subsystem
jmx (OK)
jpa (OK)
jsf [PR https://github.com/jbossas/jboss-as/pull/3925]
jsr77 - nothing to do, empty subsystem
logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
mail
messaging [OK]
modcluster
naming [PR https://github.com/jbossas/jboss-as/pull/3910]
osgi (OK)
pojo - nothing to do, empty subsystem
remoting - [OK]
sar - nothing to do, empty subsystem
security
threads
transactions (just needs AS7-6336)
web
webservices
weld - nothing to do, empty subsystem
xts - nothing to do, susbystem model has not changed since 7.1.2 & 7.1.3
was:
Task to track the work we've all been doing on expressions/transformers.
See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
2) Basic transformation testing against 7.1.2 and 7.1.3
3) Reject-expression testing against 7.1.2 and 7.1.3
Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
Please edit this description and put an OK after the subsystem name to indicate it's good to go.
clustering/jgroups (OK)
clustering/infinispan
cmp
configadmin [OK]
connector/datasource
connector/jca [OK]
connector/resource-adapter
deployment-scanner
ee
ejb3 [OK]
jacorb - Just a note: the 'security' attribute transformation is not tested
jaxr OK
jaxrs - nothing to do, empty subsystem
jdr - nothing to do, empty subsystem
jmx (OK)
jpa (OK)
jsf [PR https://github.com/jbossas/jboss-as/pull/3925]
jsr77 - nothing to do, empty subsystem
logging
mail
messaging [OK]
modcluster
naming [PR https://github.com/jbossas/jboss-as/pull/3910]
osgi (OK)
pojo - nothing to do, empty subsystem
remoting - [OK]
sar - nothing to do, empty subsystem
security
threads
transactions (just needs AS7-6336)
web
webservices
weld - nothing to do, empty subsystem
xts - nothing to do, susbystem model has not changed since 7.1.2 & 7.1.3
> Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6334
> URL: https://issues.jboss.org/browse/AS7-6334
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 7.2.0.Alpha1
>
>
> Task to track the work we've all been doing on expressions/transformers.
> See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
> 1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
> 2) Basic transformation testing against 7.1.2 and 7.1.3
> 3) Reject-expression testing against 7.1.2 and 7.1.3
> Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
> Please edit this description and put an OK after the subsystem name to indicate it's good to go.
> clustering/jgroups (OK)
> clustering/infinispan
> cmp
> configadmin [OK]
> connector/datasource
> connector/jca [OK]
> connector/resource-adapter
> deployment-scanner
> ee
> ejb3 [OK]
> jacorb - Just a note: the 'security' attribute transformation is not tested
> jaxr OK
> jaxrs - nothing to do, empty subsystem
> jdr - nothing to do, empty subsystem
> jmx (OK)
> jpa (OK)
> jsf [PR https://github.com/jbossas/jboss-as/pull/3925]
> jsr77 - nothing to do, empty subsystem
> logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
> mail
> messaging [OK]
> modcluster
> naming [PR https://github.com/jbossas/jboss-as/pull/3910]
> osgi (OK)
> pojo - nothing to do, empty subsystem
> remoting - [OK]
> sar - nothing to do, empty subsystem
> security
> threads
> transactions (just needs AS7-6336)
> web
> webservices
> weld - nothing to do, empty subsystem
> xts - nothing to do, susbystem model has not changed since 7.1.2 & 7.1.3
--
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
13 years, 5 months
[JBoss JIRA] (JBRULES-3708) Map-accessing constraints stop matching after they are jit-optimized
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3708?page=com.atlassian.jira.plug... ]
Mario Fusco resolved JBRULES-3708.
----------------------------------
Fix Version/s: 6.0.0.Alpha1
Resolution: Done
> Map-accessing constraints stop matching after they are jit-optimized
> --------------------------------------------------------------------
>
> Key: JBRULES-3708
> URL: https://issues.jboss.org/browse/JBRULES-3708
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.5.0.Final
> Reporter: Esteban Aliverti
> Assignee: Mario Fusco
> Labels: jit
> Fix For: 6.0.0.Alpha1
>
> Attachments: JITProblems.zip
>
>
> Having the following rules:
> declare TestObject
> data : java.util.Map //This is a Map<Parameter, Double>
> end
> rule "Rule 2"
> when
> TestObject(data[Parameter.PARAM_A] > 3)
> then
> System.out.println("Rule 2 fired!");
> end
> And repeatedly inserting a TestObject with data[PARAM_A] = 4 into a session makes the rule to stop matching.
> Maybe the title of the issue is wrong and JIT has nothing to do, but that is the only explanation I've found.
--
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
13 years, 5 months