[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
17 years
[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
17 years
[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
17 years
[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
17 years