June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBFORUMS-243) safeClose method never more used in Portal common project

by Luca Stancapiano (JIRA)

safeClose method never more used in Portal common project --------------------------------------------------------- Key: JBFORUMS-243 URL: http://jira.jboss.com/jira/browse/JBFORUMS-243 Project: JBoss Forums Issue Type: Bug Components: Forum Model Layer Affects Versions: 1.0.1 RC Environment: forums taken at http://anonsvn.labs.jboss.com/labs/jbossforums/branches/forums101P26 since 12 jun 2007 portal taken at http://anonsvn.jboss.org/repos/portal/trunk since 12 jun 2007 Reporter: Luca Stancapiano Assigned To: Ryszard Kozmik Fix For: 1.0.1 RC Attachments: TCCLXProperties.java hi ryszak....it seems that safeClose(Object in) method of org.jboss.portal.common.util.Tools of Portal 2.6 common project is never more used. I rewrote org.jboss.portlet.forums.properties.TCCLXProperties class : row 85 finally { Tools.safeClose(in); } so: finally { in.close(); } bye -- 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

19 years

2
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1091) CMS UI : order : for lists of languages, folders, files names

by Antoine Herzog (JIRA)

CMS UI : order : for lists of languages, folders, files names ------------------------------------------------------------- Key: JBPORTAL-1091 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1091 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.4 Final Environment: JBoss Portal 2.4, WXP, CMS repository in filesystem, Reporter: Antoine Herzog Assigned To: Roy Russo Priority: Minor In the CMS UI, the ordering of the folders and the files names is "Date of creation". Wish : the ordering by names (more convenient to work). even better : feature to choose the ordering on name, dates, description (second priority). In the list of languages, when you use it with another user language than english, the list is in a very messy order : I guess it is the order of the languages names in english, but showed in the "other language". example : "english" is written "anglais" and can be found after "grec" (greek) and before "esperanto". solution : order the list with the i18n label of each items. even better : propose in top of list the few languages that are supported by the portal. propose a one (or a few) strategie(s) of ordering. -- 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

19 years

4
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

19 years

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

19 years

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

19 years

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

19 years

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

19 years

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

19 years

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

19 years

3
3
0 / 0

[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

19 years

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 June 2007