March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-704) Drools 3.1.M1 Rules build results in java.lang.UnsupportedOperationException

by Thomas Gonzalez (JIRA)

Drools 3.1.M1 Rules build results in java.lang.UnsupportedOperationException ---------------------------------------------------------------------------- Key: JBRULES-704 URL: http://jira.jboss.com/jira/browse/JBRULES-704 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.1-m1 Environment: Windows 2k Reporter: Thomas Gonzalez Assigned To: Mark Proctor Initial issue description sent in following email test: yep - looks like a bug to me on a quick look - do you want to attach a simple test to a JIRA? On 2/23/07, Tom Gonzalez < tomgon(a)nortel.com> wrote: Getting exception below building rules that build in 3.0.4. Looking at FunctionBuilder we have at line 106. The code in red looks suspicious? Seems it should be mapping "mapping" against the name. But that is not what is the cause of the exception apparently put is not supported? String name = pkg.getName() + "." + ucFirst( functionDescr.getName() ); LineMappings mapping = new LineMappings( name ); mapping.setStartLine( functionDescr.getLine() ); mapping.setOffset( functionDescr.getOffset() ); lineMappings.put( name, lineMappings ); [java] INFO: ============== Start build RulePackage: [engrules.ers8600] === ====== [java] Feb 21, 2007 2:38:28 PM com.nortel.connect.rbuilder.RulePackage addR ulesFromDrlFile [java] INFO: adding Rules from: ERS8600Rules.drl (no associated DSL) [java] Feb 21, 2007 2:38:28 PM com.nortel.connect.rbuilder.RulePackage addR ulesFromDrlFile [java] INFO: parsed rules no dsl [java] java.lang.UnsupportedOperationException [java] at java.util.AbstractMap.put(AbstractMap.java:228) [java] at org.drools.semantics.java.FunctionBuilder.build(FunctionBuild er.java:110) [java] at org.drools.compiler.PackageBuilder.addFunction(PackageBuilder .java:326) [java] at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder. java:214) [java] at com.nortel.connect.rbuilder.RulePackage.addRulesFromDrlFile(R ulePackage.java:226) [java] at com.nortel.connect.rbuilder.RulePackager.build(RulePackager.j ava:205) [java] at com.nortel.connect.rbuilder.RulePackager.buildAll(RulePackage r.java:141) [java] at com.nortel.connect.rbuilder.RulePackager.main(RulePackager.ja va:91) A second problem is the cause of the UnsupportedOperationException turns out to be our use of the PackageBuilder in 3.0.4 that is no longer supported by 3.1.M1. We are using the merge rules constructor when we create a rule package from scratch as follows: this.droolsPackage = new org.drools.rule.Package(packageName); PackageBuilderConfiguration config = new PackageBuilderConfiguration(); config.setJavaLanguageLevel("1.5"); this.packageBuilder = new PackageBuilder(droolsPackage, config); This used to work before but in version 3.1.M1 in PackageBuilder the Map lineMappings is only initialized with a HashMap when the newPackage() method is invoked and not when the mergePackage() method is invoked. The assumption is the lineMappings has been initialized when mergePackage() has been invoked. Changing to properly use from scratch and merge constructors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-640) Eliminate duplication of deployment descriptors across repositories (Messaging and AS)

by Ovidiu Feodorov (JIRA)

Eliminate duplication of deployment descriptors across repositories (Messaging and AS) -------------------------------------------------------------------------------------- Key: JBMESSAGING-640 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-640 Project: JBoss Messaging Issue Type: Sub-task Components: Build System Affects Versions: 1.2.0.Alpha2, 1.0.1.GA Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.CR1 To quickly complete integration with JBAS5, I've copied JBoss-specific deployment descriptors accross repositories. remoting-service.xml, connection-factories-service.xml, messaging-service.xml, hsqldb-persistence-service.xml, destinations-service.xml, jms-ds.xml, as well as messaging-users.properties and messaging-roles.properties are duplicated in both https://svn.jboss.org/repos/messaging/src/etc/server/default/deploy and https://svn.jboss.org/repos/jbossas/messaging/src/etc/deploy. Find a solution that would allow maintaining only one copy (SVN links?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

4
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-854) JMX Management rationalization

by Brian Stansberry (JIRA)

JMX Management rationalization ------------------------------ Key: JBCACHE-854 URL: http://jira.jboss.com/jira/browse/JBCACHE-854 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.GA In 2.0 JBC no longer inherits from the AS's ServiceMBeanSupport class, and JMX registration is handled differently. This is a parent task for sorting out issues related to JMX in this new environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-823) Add security integration tests

by Ovidiu Feodorov (JIRA)

Add security integration tests ------------------------------ Key: JBMESSAGING-823 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-823 Project: JBoss Messaging Issue Type: Task Components: Tests and Performance Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.CR1 Make sure we cover the situation described here: http://jira.jboss.org/jira/browse/JBMESSAGING-807 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

2
6
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-910) Single persistent message always routed in transaction

by Tim Fox (JIRA)

Single persistent message always routed in transaction ------------------------------------------------------ Key: JBMESSAGING-910 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-910 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Priority: Minor Fix For: 1.2.1 When routing a single persistent message to a single local queue using the clustered router, the logs report that an internal transaction is being created to route it since there are more than one queues. This seems unnecessary. Need to investigate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-819) Use of stopping flag in DefaultClusteredPostOffice introduces race conditions

by Tim Fox (JIRA)

Use of stopping flag in DefaultClusteredPostOffice introduces race conditions ----------------------------------------------------------------------------- Key: JBMESSAGING-819 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-819 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta2 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.CR1 Using a stopping flag is not a good approach and introduces a race condition the code can check stopping and find it to be false, then the service can stop, setting stopping to true then actually stopping the post office, then the same thread that checked stopping continues and performs its action only to find the service stopped. Should use a read-write lock instead. One way to minimise the chance of the race happening is to sleep for a little while after setting stopping to true before actually stopping the service (see below) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

3
8
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-901) RedistributionWithDefaultMessagePullPolicyTest tests fail occasionally

by Ovidiu Feodorov (JIRA)

RedistributionWithDefaultMessagePullPolicyTest tests fail occasionally ---------------------------------------------------------------------- Key: JBMESSAGING-901 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-901 Project: JBoss Messaging Issue Type: Bug Components: Tests and Performance Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Blocker Fix For: 1.2.0.GA I marked the failure points with // <- in test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

3
10
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-907) Add a new "default redistribution policy" DistributedQueueExample and smoke test

by Ovidiu Feodorov (JIRA)

Add a new "default redistribution policy" DistributedQueueExample and smoke test -------------------------------------------------------------------------------- Key: JBMESSAGING-907 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-907 Project: JBoss Messaging Issue Type: Feature Request Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.1 The development team came to the conclusion that the best choice for a default message redistribution policy configuration - the configuration the release ships with - is org.jboss.messaging.core.plugin.postoffice.cluster.NullMessagePullPolicy. This is the most common case, and this is what should be the out-of-the-box configuration. However, this renders the current DefaultQueueExample, which assumes a DefaultMessagePolicy, irrelevant. It's actually worse, it breaks it. I am changing the DistributedQueueExample to work with NullMessagePullPolicy, and so make it work out-of-the-box. That also makes it extremely boring. We need to add another DistributedQueueExample, that shows how DefaultMessagePullPolicy works. It will require changing some configuration on the fly, so there is no time to write and test it before 1.2.0. This is the original example (the default distribution policy one): --------------------------------------------------------------------------------------------------------------------------------- /** * The example creates two connections to two distinct cluster nodes on which we have previously * deployed a distributed queue. The example creates and sends a message using a connection, and * attempts to receive the message using the other connection. This is an example of message * redistribution in clustered environment at work. The JBoss Messaging clustered Post Offices * need to be configured with a default message redistribution policy for this example to work * correctly. * * Since this example is also used as a smoke test, it is essential that the VM exits with exit * code 0 in case of successful execution and a non-zero value on failure. * * @author <a href="mailto:ovidiu@jboss.org">Ovidiu Feodorov</a> * @version <tt>$Revision: 1001 $</tt> * * $Id: TopicExample.java 1001 2006-06-24 09:05:40Z timfox $ */ public class DistributedQueueExample extends ExampleSupport { public void example() throws Exception { String destinationName = getDestinationJNDIName(); InitialContext ic = null; Connection connection0 = null; Connection connection1 = null; try { // connecting to the first node ic = new InitialContext(); ConnectionFactory cf = (ConnectionFactory)ic.lookup("/ConnectionFactory"); Queue distributedQueue = (Queue)ic.lookup(destinationName); log("Distributed queue " + destinationName + " exists"); // When connecting to a messaging cluster, the ConnectionFactory has the capability of // transparently creating physical connections to different cluster nodes, in a round // robin fashion ... // ... so this is a connection to a cluster node connection0 = cf.createConnection(); // ... and this is a connection to a different cluster node connection1 = cf.createConnection(); // Let's make sure that (this example is also a smoke test) assertNotEquals(getServerID(connection0), getServerID(connection1)); // Create a session and a producer on the first connection Session session0 = connection0.createSession(false, Session.AUTO_ACKNOWLEDGE); MessageProducer publisher = session0.createProducer(distributedQueue); // Create another session and a consumer on the second connection Session session1 = connection1.createSession(false, Session.AUTO_ACKNOWLEDGE); MessageConsumer consumer = session1.createConsumer(distributedQueue); ExampleListener messageListener = new ExampleListener("MessageListener"); consumer.setMessageListener(messageListener); // Start connection1, so we can receive the message connection1.start(); // Send the message TextMessage message = session0.createTextMessage("Hello!"); publisher.send(message); log("The message was successfully sent to the distributed queue"); // Wait longer than clustered Post Office's "StatsSendPeriod", which is usually 10 secs messageListener.waitForMessage(15000); message = (TextMessage)messageListener.getMessage(); log(messageListener.getName() + " received message: " + message.getText()); assertEquals("Hello!", message.getText()); displayProviderInfo(connection0.getMetaData()); } finally { if (ic != null) { try { ic.close(); } catch(Exception e) { throw e; } } try { if (connection0 != null) { connection0.close(); } } catch(JMSException e) { log("Could not close connection " + connection0 + ", exception was " + e); throw e; } try { if (connection1 != null) { connection1.close(); } } catch(JMSException e) { log("Could not close connection " + connection1 + ", exception was " + e); throw e; } } } protected boolean isQueueExample() { return true; } public static void main(String[] args) { new DistributedQueueExample().run(); } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-546) Please implement "collect( ... ) from" functionality

by Dirk Bergstrom (JIRA)

Please implement "collect( ... ) from" functionality ---------------------------------------------------- Key: JBRULES-546 URL: http://jira.jboss.com/jira/browse/JBRULES-546 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Dirk Bergstrom Assigned To: Mark Proctor I need to count the number of sub-objects that meet various criteria. As an example, suppose I have several hundred Town objects, each of which has a list of perhaps a few hundred Person objects. I need to write rules like: "Find all the towns that have more than three disabled people with incomes over $100K." "For each town with more than 1000 residents that has more than 50 poor children under the age of 8, add a teacher for every 25 children." I'm shaky on JBR syntax, but I think those would translate to something like: rule "disabled" when ArrayList(size > 50) from collect( Person( disabled == "yes", income > 100000 ) from town.getPersons() ) then //do stuff end rule "teachers" when town : Town( population > 1000 ) count : Arraylist from collect( Person( disabled == "yes", income > 100000 ) from town.getPersons() ) count( size > 50 ) then town.addTeachers(count.size() / 25) end (I'm not really working with towns and people, but it makes for easily understood examples) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

5
6
0 / 0

[JBoss JIRA] Created: (JBRULES-543) Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS

by Sridhar Chandrasekharan (JIRA)

Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS ---------------------------------------------------------------------------------------- Key: JBRULES-543 URL: http://jira.jboss.com/jira/browse/JBRULES-543 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Sridhar Chandrasekharan Assigned To: Mark Proctor Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS. Jess has a (halt) command which allows a rule to specify that rule execution should be stopped. I could find no such command in JBoss rules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

2
3
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 March 2007