Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 851100

Summary: RTE with Nested Classes, BRL and Java
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: manstis
Component: BRM (Guvnor)Assignee: manstis
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: BRMS 5.3.1   
Target Milestone: ER2   
Target Release: BRMS 5.3.1 GA   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Some fully qualified inner class names were being incorrectly parsed and the import statements that were automatically generated for nest classes were incorrect. This caused the completion of knowledge packages with the incorrect import statements to fail, and users had to manually alter the generated import statements. This has been resolved by ensuring the fully qualified inner class names are correctly parsed. The import statements generated for inner classes are now correct, and knowledge packages including import statements for inner classes now compile without the need for manually altering of the import statement.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2025-02-10 03:20:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
repository_export.xml with broken rule
none
Image showing "frozen" sections of rule. none

Description manstis 2012-08-23 09:01:33 UTC 
Description of problem:

See linked JIRA.

Version-Release number of selected component (if applicable):

See linked JIRA.

How reproducible:

See linked JIRA.

Steps to Reproduce:
1.
2.
3.
  
Actual results:

Nested classes cause a RTE.

Expected results:

Nested classes can be used in a POJO model.

Additional info:
Comment 3 Jiri Locker 2012-09-25 12:09:57 UTC 
Fix verified in BRMS 5.3.1.ER1.
Comment 4 Jiri Locker 2012-09-25 15:17:07 UTC 
However this bugfix breaks backward compatibility. After delivering this fix (in the current shape) all BRL (guided editor) rules using nested class facts become corrupted. Currently the only way to deal with corrupted rules in guided editor is to archive/delete them and manually re-edit them from scratch. There's no other way I'm aware of.

My proposal is to enahance the guided editor to only higlight corrupted elements of the rule and allow to remove them while the rest of the rule remains preserved.

I'm setting blocker? flag. Please set your ack+ to indicate that this bug should be included with the additional effort to maintain backward compatibility of the guided editor. If blocker is denied then QA does not recommend to include this fix.
Comment 5 manstis 2012-09-25 21:16:29 UTC 
Hello, can you attach a repo with rules that become broken? Ideally I'd like to make them work unmodified. Cheers, Mike
Comment 6 Jiri Locker 2012-09-26 12:13:49 UTC 
Created attachment 617529 [details]
repository_export.xml with broken rule

Hello, please import this repository and open "rule" under "test" package. This rule was created with BRMS 5.3.0. After upgrading to 5.3.1 the rule becomes broken.

Alternatively, you can import the repository attached to the original issue https://issues.jboss.org/browse/GUVNOR-1873 and open "Test_Rule01" under "Test_Package".
Comment 7 manstis 2012-09-27 08:55:04 UTC 
Hello, what do you mean by "broken"? 

I tried and the sections of rules that contain classes that cannot be found are disabled (see screen shot). The inability to delete "frozen" sections is covered by https://issues.jboss.org/browse/GUVNOR-1358 (https://bugzilla.redhat.com/show_bug.cgi?id=724474) which is not included in the scope of 5.3.1.

I propose this BZ remains VERIFIED. WDYT?

Cheers,

Mike
Comment 8 manstis 2012-09-27 09:09:15 UTC 
Created attachment 617953 [details]
Image showing "frozen" sections of rule.
Comment 9 Jiri Locker 2012-09-27 13:00:52 UTC 
My conclusion that the rule with frozen section is broken was hasty. It remains working unless the import statements in the old format using $ delimiter are removed. That's good.

However if you take functions into consideration it becomes more complicated: In order to eliminate the error originally reported in GUVNOR-1873 (combination of nested classes and functions) you have to remove imports using '$' and replace them with imports using '.' only, which eventually breaks those rules referring to the nested class in the form of OuterClass$InnerClass. Since these conditional elements are frozen and cannot be updated the only way to fix these rules is to remove them and re-create from scratch. And I believe we can't force customers to face this after an upgrade.

Can you think of a less painful workaround or a way how the broken rules update could be done automatically?
Comment 10 manstis 2012-09-28 12:14:41 UTC 
Hi,

I have added the ability to delete a "frozen" section of a rule (where the Fact Type is not recognized - https://bugzilla.redhat.com/show_bug.cgi?id=724474).

Hopefully this is the best of both worlds.

Cheers,

Mike
Comment 11 Jiri Locker 2012-10-05 14:56:47 UTC 
Thank you for pushing the old bug 724474 forward, this is a good solution. I'll verify this one as soon as 724474 is done.
Comment 12 Jiri Locker 2012-10-11 14:29:04 UTC 
Fix verified in BRMS 5.3.1.ER3.
Comment 14 lcarlon 2012-10-18 03:26:51 UTC 
Release notes text updated for the release notes. Thanks for providing the text, Mike.

Lee
Comment 21 Red Hat Bugzilla 2025-02-10 03:20:34 UTC 
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.