July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1543) Wrong two n in AnnonymousUser and AnnonymousRole class name

by Antoine Herzog (JIRA)

Wrong two n in AnnonymousUser and AnnonymousRole class name ------------------------------------------------------------ Key: JBPORTAL-1543 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1543 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6 Final Environment: JBP2.6.0GA Reporter: Antoine Herzog Assigned To: Julien Viet Fix For: 2.6.1 Final Class names : AnnonymousUser AnnonymousRole should be : AnonymousUser AnonymousRole one n, more clean and helpfull when searching for "Anonymous" in the source, for understanding how anonymous users are managed. -- 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, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-983) BRLContentHandler trying to expand rule even when no DSL present in the rule (only in package)

by Michael Neale (JIRA)

BRLContentHandler trying to expand rule even when no DSL present in the rule (only in package) ---------------------------------------------------------------------------------------------- Key: JBRULES-983 URL: http://jira.jboss.com/jira/browse/JBRULES-983 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.0.MR3 Reporter: Michael Neale Assigned To: Michael Neale Fix For: 4.0.0.MR4 If a DSL asset exists in a package, it will try to expand all BRL rules - should only do so when it detects a DSL sentence is used in a BRL rule. The logic for detecting DSL presence should be moved from the BRDRLPersistence to RuleModel (and unit tested). -- 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, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-538) ENCRYPT protocol throwing IllegalBlockSizeException

by vivek v (JIRA)

ENCRYPT protocol throwing IllegalBlockSizeException --------------------------------------------------- Key: JGRP-538 URL: http://jira.jboss.com/jira/browse/JGRP-538 Project: JGroups Issue Type: Bug Affects Versions: 2.5 Environment: Windows, Linux Reporter: vivek v Assigned To: Bela Ban Priority: Critical Fix For: 2.5 I use NotificationBus channel and in the member joined method I call, bus.sendNotification(Node) - passing a custom Node object. Upon this I get the following error on the newly joined member, javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..) at javax.crypto.Cipher.doFinal(DashoA13*..) at org.jgroups.protocols.ENCRYPT._decrypt(ENCRYPT.java:838) at org.jgroups.protocols.ENCRYPT.decryptMessage(ENCRYPT.java:831) at org.jgroups.protocols.ENCRYPT.handleUpMessage(ENCRYPT.java:672) at org.jgroups.protocols.ENCRYPT.up(ENCRYPT.java:533) I could reproduce the same problem using NotificationBusDemo.java in JGroups 2.5 CR1. Here is what I did, 1) Generate a keystore using JGroups' KeyStoreGenerator (I also tried with JDK 1.6's keytool to generate secret key) 2) Add the following line in the protocol stack of NotificationBusDemo.java in the main(), "ENCRYPT(key_store_name=jgroups.keystore;store_password=storePassed;alias=mykey):" + 3) Add the following line in the memberJoined(..) method of NotificationBusDemo.java bus.sendNotification("Member Joined"); 4) Run 2 instances of NotificationBusDemo.java 5) You'll get the following error message, > 3828 [WARN] ENCRYPT.up(): - exception occurred decrypting message javax.crypto.BadPaddingException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_h.b(DashoA12275) at com.sun.crypto.provider.SunJCE_h.b(DashoA12275) I am running this on Windows using JGroups 2.5 CR1. The original thread for this issue is at, http://sourceforge.net/forum/forum.php?thread_id=1751571&forum_id=18795 -- 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, 4 months

2
13
0 / 0

[JBoss JIRA] Created: (JBAOP-421) Implement Generics getAssignabilityDegree algorihtm

by Flavia Rainone (JIRA)

Implement Generics getAssignabilityDegree algorihtm --------------------------------------------------- Key: JBAOP-421 URL: http://jira.jboss.com/jira/browse/JBAOP-421 Project: JBoss AOP Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha5 Reporter: Flavia Rainone Assigned To: Flavia Rainone Fix For: 1.5.6.GA Implement an algorith that can say how many hiearchy levels it takes to go from a Type to another Type. Since this involves generics, we will have to convent what means an hierarchy step when dealing with Generics. -- 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, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBFORUMS-244) Change DeletionConfirmationViews

by Ryszard Kozmik (JIRA)

Change DeletionConfirmationViews -------------------------------- Key: JBFORUMS-244 URL: http://jira.jboss.com/jira/browse/JBFORUMS-244 Project: JBoss Forums Issue Type: Sub-task Components: Forum Enhancements, Forum View Layer Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Fix For: 1.0.1 RC We need to rewrite to new design views where user confirms deletion of a poll, a topic, a post. -- 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, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1011) Serverfailover should merge prepared transactions

by Clebert Suconic (JIRA)

Serverfailover should merge prepared transactions ------------------------------------------------- Key: JBMESSAGING-1011 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1011 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.CR1 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.4.0.CR1 -- 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, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-753) Engine allows more than one rule with same name

by Marcos Tengelmann (JIRA)

Engine allows more than one rule with same name ----------------------------------------------- Key: JBRULES-753 URL: http://jira.jboss.com/jira/browse/JBRULES-753 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.5 Environment: Any OS. Reporter: Marcos Tengelmann Assigned To: Mark Proctor Engine allows more than one rule with same name. This leads to unpredicatable behavior, but one thing for sure. Wrong resutls. This is not an easy problem to identify, althrought is quite simple to solve once it is found. -- 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, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-549) Better support for linebreaks in LHS

by Dirk Bergstrom (JIRA)

Better support for linebreaks in LHS ------------------------------------ Key: JBRULES-549 URL: http://jira.jboss.com/jira/browse/JBRULES-549 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Reporter: Dirk Bergstrom Assigned To: Mark Proctor I have some rules with very long LHS expressions. I'd like to split them across multiple lines for readability. However, the parser has limited support for breaks. These work: when ObjectTypeName( p0_exit_epoch > (RUM.now()), p0_exit_epoch > (RUM.daysAgo(7)) ) variable : OtherObjectType($rlis : rlis -> (RUM.countFieldsMatching($rlis, "state", "dev-maybe") > 0)) These don't: variable : OtherObjectType($rlis : rlis -> (RUM.countFieldsMatching($rlis, "state", "dev-maybe") > 0)) variable : OtherObjectType(($rlis : rlis -> (RUM.countFieldsMatching($rlis, "state", "dev-maybe") > 0)) variable : OtherObjectType($rlis : rlis -> (RUM.countFieldsMatching($rlis, "state", "dev-maybe") > 0)) While I'm at it, I'd love to have support for multiline expressions in DSL files, but I can imagine that would be a bit harder... -- 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, 4 months

4
3
0 / 0

[JBoss JIRA] Created: (JBRULES-782) Bug if you modify a fact without notifying the engine and then call workingmemory getFactHandle

by Mark Proctor (JIRA)

Bug if you modify a fact without notifying the engine and then call workingmemory getFactHandle ----------------------------------------------------------------------------------------------- Key: JBRULES-782 URL: http://jira.jboss.com/jira/browse/JBRULES-782 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 3.1-m1 Reporter: Mark Proctor Assigned To: Mark Proctor If a pojo is modified and working memory .getFactHandle() is called which causes the hashcode to change, then we won't be able to retrieve the fact handle. -- 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, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-859) Switching off alpha node sharing changes rule behaviour

by Shahad Ahmed (JIRA)

Switching off alpha node sharing changes rule behaviour ------------------------------------------------------- Key: JBRULES-859 URL: http://jira.jboss.com/jira/browse/JBRULES-859 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.0.MR2 Environment: Windows XP SP2, Intel x86 Pentium 4 3.0MHz, 1Gb RAM Reporter: Shahad Ahmed Assigned To: Mark Proctor In release 4.0MR2, switching off alpha node sharing appears to change the results produced by a set of rules. I'll illustrate the behaviour with the two rules "First" and Second" defined below. Both rules work with a class Customer, which is a simple object with an attribute age. rule "First" salience 10 when c: Customer(age <= 10) then System.out.println("First - Customer age less than 10"); end rule "Second" salience 5 when c: Customer(age <= 10) then System.out.println("Second - Customer age less than 10"); end For the default case where alpha node sharing is on, I assert a customer with age 5 and fireAllRules to get the following (hopefully, correct) output: First - Customer age less than 10 Second - Customer age less than 10 However, if I call setShareAlphaNodes(false) in RuleBaseConfiguration to turn off alpha node sharing I get the following output: First - Customer age less than 10 Alpha node sharing is an optimization and switching it on or off should give the same output for a set of rules. I've tried switching off alpha node sharing both directly via the API method, and using the system property option, but the behaviour is the same in both cases. Shahad -- 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, 4 months

3
3
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