Hide Forgot
Affects: Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration, Release Notes Steps to Reproduce: Use the attached package inside a business_ruleservice_ruleAgent QS (for example) and notice the above exception. Workaround: Workaround Exists Workaround Description: Just re-build the package with the latest Drools and it should work. (Not tested unfortunately, since we don't have the source file for this particular package.) project_key: SOA While trying BusinessRuleProcessor on a package generated with BRMS 5.0, I get an exception (see below). Since this package worked fine with SOA 5.0 (which already has Drools 5.0), I suggest that this is a backwards compatibility issue in between Drools 5.0 and Drools 5.1 that needs to be resolved. The exception follows, the package will be attached in a second. java.lang.RuntimeException: KnowledgeAgent exception while trying to deserialize KnowledgeDefinitionsPackage at org.drools.agent.impl.KnowledgeAgentImpl.createPackageFromResource(KnowledgeAgentImpl.java:664) at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:889) at org.drools.agent.impl.KnowledgeAgentImpl.rebuildResources(KnowledgeAgentImpl.java:704) at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:584) at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:185) at org.jboss.internal.soa.esb.services.rules.DroolsRuleBaseHelper.createRuleAgent(DroolsRuleBaseHelper.java:230) at org.jboss.internal.soa.esb.services.rules.DroolsRuleService.getRuleBaseStateForRuleAgent(DroolsRuleService.java:332) at org.jboss.internal.soa.esb.services.rules.DroolsRuleService.executeStatelessRulesFromRuleAgent(DroolsRuleService.java:115) at org.jboss.internal.soa.esb.services.rules.RuleServiceCallHelper.executeStateless(RuleServiceCallHelper.java:286) at org.jboss.internal.soa.esb.services.rules.RuleServiceCallHelper.executeRulesService(RuleServiceCallHelper.java:270) at org.jboss.soa.esb.actions.BusinessRulesProcessor.executeRulesService(BusinessRulesProcessor.java:144) at org.jboss.soa.esb.actions.BusinessRulesProcessor.process(BusinessRulesProcessor.java:125) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:649) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:603) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:433) at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:550) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Caused by: java.io.InvalidClassException: org.drools.rule.Package; local class incompatible: stream classdesc serialVersionUID = 400, local class serialVersionUID = 510 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:579) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1600) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1513) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1749) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368) at org.drools.core.util.DroolsStreamUtils.streamIn(DroolsStreamUtils.java:205) at org.drools.core.util.DroolsStreamUtils.streamIn(DroolsStreamUtils.java:174) at org.drools.agent.impl.KnowledgeAgentImpl.createPackageFromResource(KnowledgeAgentImpl.java:653) ... 18 more
Attaching a package that was created using Drools 4.x and demonstrates the issue in SOA-P 5.1.
Attachment: Added: defaultPackage.pkg
Workaround Description: Removed: Just re-build the package with the latest Drools and it works. Added: Just re-build the package with the latest Drools and it should work. (Not tested unfortunately, since we don't have the source file for this particular package.)
Investigate for SOA 5.1.0
Link: Added: This issue related BRMS-430
From ERD that has been approved: SOA-MGUP-1 Existing SOA Platform 5.0 users will be able to upgrade to SOA-P 5.1. No migration will be required. Upgrade is considered a fresh install of SOA Platform and a redeploy (no recompilation required) of customer applications/artifacts.
Drools does not support forward or backwards compatability of any serialised formats. For this reason the rebuild button was added to Guvnor. It is also why the client version must be the same version as Guvnor, you cannot mix and match versions.
See Mark's comment above.
We need to be certain to document the migration/backward compatibility paths that we support - and that users must recompile per Mark's comment.
Affects: Added: [Documentation (Ref Guide, User Guide, etc.)]
Assigning to Darrin Mison as this is moving to a Doc Jira.
Affects: Removed: [Documentation (Ref Guide, User Guide, etc.)] Added: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration]
I have now confirmed that the problem exists with packages created with Drools 5.0. Attachments coming soon.
Attaching a package generated with BRMS 5.0 (= Drools 5.0). Steps for obtaining this package: 1) Log into BRMS. 2) Import sample repository. 3) Convert "defaultPackage" into a binary package. 4) Use the binary file inside SOA-P.
Attachment: Added: defaultPackage_test.pkg
Binary compatability is not kept for any different releases of major or minor, except possible minor.mionor; but either way we say that you must run with the same version jars on client and server and if you drop in new jars to the server regardless of the release then do a rebuild of packages.
This is something we have been preaching to customers as well from the support side since BRMS 5.0 came out - when they upgrade they have to upgrade both sides in order to stay supported....so why this is now an issue i have no clue.
Nobody is disputing what drools, as a project does, but this is an issue that needs to be discussed/resolved at the platform level.
Just to clarify, as I've already received such question via e-mail: As a consequence of this issue, users upgrading to BRMS 5.1 will no longer be able to use its packages inside SOA 5.0. Inbetween BRMS 5.1 and SOA 5.1 releases, there will be a period of time where "latest BRMS" and "latest SOA" are incompatible. Not sure if this use case is relevant to our customers, though.
Link: Added: This issue related SOA-2558
will be documented as a known issue in the SOA 5.1.0 release notes
Release Notes Docs Status: Added: Not Yet Documented Writer: Added: Darrin Labels: Added: release_notes Affects: Removed: [Compatibility/Configuration, Documentation (Ref Guide, User Guide, etc.)] Added: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration, Release Notes]
Writer: Removed: Darrin Added: dlesage
Release Notes Docs Status: Removed: Not Yet Documented Added: Documented as Known Issue Release Notes Text: Added: https://issues.jboss.org/browse/SOA-2454 JBoss Rules does not support forward- or backward-compatability of any serialised formats. Versions of packages created in JBoss Rules 4.x are binary-incompatible with versions created in JBoss Rules 5.x For this reason the rebuild button was added to Rules. It is also why the client version must match the JBoss Rules version. To work around this problem, you must run with the same versions of the JARs on both the client and the server and, if you add news JARs to the server (regardless of the release) you must rebuild the packages.
Release note created.