July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-589) WokingMemoryLogger and generics: ClassCastException

by Francesco Dandrea (JIRA)

WokingMemoryLogger and generics: ClassCastException --------------------------------------------------- Key: JBRULES-589 URL: http://jira.jboss.com/jira/browse/JBRULES-589 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.5 Environment: Java 1.5.0_9 Reporter: Francesco Dandrea Assigned To: Mark Proctor Attachments: BacoJBossRules.zip I'm using Jboss Rules 3.0.5 and Java 1.5.0_09. I'm using generics, but I see that I can't have the character < in a Fact in te drl. This is not a problem, I derived my generic class, and the new derived one is not a Generic class... (public class MyClassCiccio extends Ciccio<MyClass>{}) Now, when I execute the application without log it works. But when I instantiate a WorkingMemoryLogger I have a ClassCastException: Exception in thread "main" java.lang.ClassCastException: it.telecomitalia.netbox.MeasureAlarm at org.drools.base.it.telecomitalia.netbox.TfAlarm$getReferencedElement.getValue(Unknown Source) at org.drools.base.ClassFieldExtractor.getValue(Unknown Source) at org.drools.rule.Declaration.getValue(Unknown Source) at org.drools.audit.WorkingMemoryLogger.extractDeclarations(Unknown Source) at org.drools.audit.WorkingMemoryLogger.activationCreated(Unknown Source) at org.drools.event.AgendaEventSupport.fireActivationCreated(Unknown Source) at org.drools.reteoo.TerminalNode.assertTuple(Unknown Source) at org.drools.reteoo.TerminalNode.assertTuple(Unknown Source) at org.drools.reteoo.TupleSource.propagateAssertTuple(Unknown Source) at org.drools.reteoo.NotNode.assertTuple(Unknown Source) at org.drools.reteoo.LeftInputAdapterNode.createAndAssertTuple(Unknown Source) at org.drools.reteoo.LeftInputAdapterNode.assertObject(Unknown Source) at org.drools.reteoo.ObjectSource.propagateAssertObject(Unknown Source) at org.drools.reteoo.ObjectTypeNode.assertObject(Unknown Source) at org.drools.reteoo.Rete.assertObject(Unknown Source) at org.drools.reteoo.ReteooRuleBase.assertObject(Unknown Source) at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(Unknown Source) at org.drools.common.AbstractWorkingMemory.assertObject(Unknown Source) at org.drools.common.AbstractWorkingMemory.assertObject(Unknown Source) at it.telecomitalia.netbox.Main.main(Main.java:34) I have an example (sent to the mailing list) that gives the exception, but -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Closed: (JBRULES-261) Mismatched types in field constraints

by Edson Tirelli (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-261?page=all ] Edson Tirelli closed JBRULES-261. --------------------------------- Resolution: Done Fixed. Test case added. > Mismatched types in field constraints > ------------------------------------- > > Key: JBRULES-261 > URL: http://jira.jboss.com/jira/browse/JBRULES-261 > Project: JBoss Rules > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Rule Assemply/SPI > Affects Versions: 3.0.1 > Reporter: Michael Neale > Assigned To: Edson Tirelli > Priority: Minor > Fix For: 4.0.0.MR4 > > > Problem: If a rule compares two fields and one of them is a char and the > other one is a String, the match is always negative. No type-mismatch error > or warning is displayed. This can be quite confusing. The attached Eclipse > project illustrates this problem. > Suggested Solution: If all information is available at compile-time an error > should be generated on type mismatches. Otherwise there should be a warning > during run-time and maybe a type conversion attempt. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-261) Mismatched types in field constraints

by Edson Tirelli (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-261?page=all ] Edson Tirelli updated JBRULES-261: ---------------------------------- Issue Type: Bug (was: Task) > Mismatched types in field constraints > ------------------------------------- > > Key: JBRULES-261 > URL: http://jira.jboss.com/jira/browse/JBRULES-261 > Project: JBoss Rules > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Rule Assemply/SPI > Affects Versions: 3.0.1 > Reporter: Michael Neale > Assigned To: Edson Tirelli > Priority: Minor > Fix For: 4.0.0.MR4 > > > Problem: If a rule compares two fields and one of them is a char and the > other one is a String, the match is always negative. No type-mismatch error > or warning is displayed. This can be quite confusing. The attached Eclipse > project illustrates this problem. > Suggested Solution: If all information is available at compile-time an error > should be generated on type mismatches. Otherwise there should be a warning > during run-time and maybe a type conversion attempt. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-761) Consider clean ways of taking a node out of the cluster for maintenance

by Tim Fox (JIRA)

Consider clean ways of taking a node out of the cluster for maintenance ----------------------------------------------------------------------- Key: JBMESSAGING-761 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-761 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Fix For: 1.2.1 We should consider how the system administrator can take a node out of the cluster for maintenance without clients losing messages. If a node is just shut down then any clients connected to that node will failover to another node, potentially losing any non persistent messages - this may not be acceptable. We should also consider functionality on the jmx console where a server cen block the creation of any new connections, and the information such as client machine name, client id, ip address can be displayed for existing connetions. This would allow the sysadmin to contact the clients and shut them down cleanly before bringing the server down. -- 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, 3 months

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-979) Ruleflow should terminate all running node instances when ruleflow process is completed

by Kris Verlaenen (JIRA)

Ruleflow should terminate all running node instances when ruleflow process is completed --------------------------------------------------------------------------------------- Key: JBRULES-979 URL: http://jira.jboss.com/jira/browse/JBRULES-979 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Rule Flow Affects Versions: 4.0.0.MR3 Reporter: Kris Verlaenen Assigned To: Kris Verlaenen Fix For: 4.0.0.MR4 Whenever an end node is reached in a ruleflow, the state of the ruleflow process is set to completed. However, running node instances that are active remain active and can continue executing. Whenever a ruleflow is terminated, all active node instances should be cancelled -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-926) Fix equality support for the new update() call

by Edson Tirelli (JIRA)

Fix equality support for the new update() call ---------------------------------------------- Key: JBRULES-926 URL: http://jira.jboss.com/jira/browse/JBRULES-926 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Edson Tirelli Assigned To: Mark Proctor Fix equality support for the new update() call -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1538) Permissions Caching When Session Abandoned

by Mike Millson (JIRA)

Permissions Caching When Session Abandoned ------------------------------------------ Key: JBPORTAL-1538 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1538 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Security Affects Versions: 2.4.1 SP1 Environment: RHEL 5 Workstation FireFox 1.5.0.1.2 Reporter: Mike Millson Assigned To: Julien Viet Starting with an out-of-box portal deployment: 1) Log in as admin 2) Create a role TestRole 3) Create a user TestUser 4) Assign TestRole to TestUser 5) Create a page TestPage and secure it with TestRole 6) Log out 7) Log in as TestUser. You will see the TestPage tab 8) Abandon the TestUser session by closing the browser or deleting the TestUser session cookie 9) Log in as admin 10) Remove TestRole from TestUser 11) Log out 12) Type in the url to the portal (don't use login screen presented after #11 logout) 13) Log in as TestUser 14) The TestPage tab is displayed, even though TestUser no longer has permission to access it. The TestPage tab does not disappear until I log out and re-login as TestUser. I don't think this is a 2nd level cache or query cache issue, as I disabled both and could still reproduce this. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-60) Partitioned Cache

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-60?page=all ] Manik Surtani updated JBCACHE-60: --------------------------------- JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061375 > Partitioned Cache > ----------------- > > Key: JBCACHE-60 > URL: http://jira.jboss.com/jira/browse/JBCACHE-60 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.2.0.GA > > Original Estimate: 10 weeks > Remaining Estimate: 10 weeks > > - Distributed load across multiple nodes in a cluster > - No replication/redundancy -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-60) Partitioned Cache

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-60?page=comments#action_12368059 ] Manik Surtani commented on JBCACHE-60: -------------------------------------- See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCachePartitioning > Partitioned Cache > ----------------- > > Key: JBCACHE-60 > URL: http://jira.jboss.com/jira/browse/JBCACHE-60 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.2.0.GA > > Original Estimate: 10 weeks > Remaining Estimate: 10 weeks > > - Distributed load across multiple nodes in a cluster > - No replication/redundancy -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1461) Should be possible to rename a window name from the Admin GUI

by Chris Laprun (JIRA)

Should be possible to rename a window name from the Admin GUI ------------------------------------------------------------- Key: JBPORTAL-1461 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1461 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.6.CR2 Reporter: Chris Laprun Fix For: 2.8 Final -- 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, 3 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2007