Bug 724772 (BRMS-610)

Summary: Improper quoting in metadata
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Tomas Schlosser <tschloss>
Component: 3rd PartyAssignee: Nobody <nobody>
Status: VERIFIED --- QA Contact: Lukáš Petrovický <lpetrovi>
Severity: high Docs Contact:
Priority: high    
Version: BRMS 5.2.0-Dev1CC: atangrin, lpetrovi
Target Milestone: ---   
Target Release: BRMS 5.2.0.GA   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/BRMS-610
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Simple example none

Description Tomas Schlosser 2011-06-24 07:38:43 UTC
securitylevel_name: Public

See JBRULES-2993

Comment 1 Tomas Schlosser 2011-06-24 07:38:59 UTC
Link: Added: This issue depends JBRULES-2993


Comment 2 Edson Tirelli 2011-08-18 15:54:01 UTC
This problem is fixed, but please note:

Due to the need of supporting backward compatible metadata that could be written without "", the current behavior is adopted:

1. The system will try to resolve the annotation value as an MVEL expression. 
1.1. If it succeeds, the result value is returned.
1.2. If it does not succeed, the original content will pass-through as a String.
2. As of 5.2, the old non-quoted syntax for annotation values is deprecated. Needs documentation.
3. As of 5.2, multi-valued annotations for rules are not supported yet, but this is a desirable feature for 5.3

Examples:


    @Test
    public void testRuleAnnotation() {
        String drl = "package org.drools\n" +
                     "rule X\n" +
                     "    @author(\"John Doe\")\n" +
                     "    @output(Hello World!)\n" + // backward compatibility
                     "    @value( 10 + 10 )\n" +
                     "    @alt( \"Hello \"+\"World!\" )\n" +
                     "when\n" +
                     "    Person()\n" +
                     "then\n" +
                     "end";
        KnowledgeBaseConfiguration conf = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
        conf.setOption( EventProcessingOption.STREAM );
        conf.setOption( MBeansOption.ENABLED );

        KnowledgeBase kbase = loadKnowledgeBase( "kb1",
                                                 drl,
                                                 conf );

        Rule rule = kbase.getRule( "org.drools",
                                   "X" );

        Assert.assertEquals( "John Doe",
                             rule.getMetaData().get( "author" ) );
        Assert.assertEquals( "Hello World!",
                             rule.getMetaData().get( "output" ) );
        Assert.assertEquals( 20,
                             ((Number)rule.getMetaData().get( "value" )).intValue() );
        Assert.assertEquals( "Hello World!",
                             rule.getMetaData().get( "alt" ) );

    }

Comment 4 Tomas Schlosser 2011-08-29 10:55:53 UTC
Created attachment 520347 [details]
Simple example

Since the new quoted way is preferred the quotes surrounding the valu should no be counted to resulting string.

@alt(" \"<- these are supposed to be the only quotes ->\" ")

results (when printed to console) to
" "<- these are supposed to be the only quotes ->" "

where I'd expect
"<- these are supposed to be the only quotes ->"

Comment 5 Edson Tirelli 2011-08-29 15:24:44 UTC
Tomas,

This is very tricky because of the backward compatibility issue. The reason the above was not working was because Drools parser was unescaping strings and then MVEL was doing it again during execution of the expression, what was failing and falling back to the legacy mode. So it would require a number of \ for each \... very ugly.

I changed the code again so that the above works as you mentioned, but I am becoming more and more convinced that it is dangerous to support silent backward compatibility as I was trying to. I am wondering if we should add a configuration to explicit work in the 5.1 compatibility mode (i.e., no expression support whatsoever) or in the 5.2+ support (i.e., only expression support, no backward compatibility for invalid expressions).

Anyway, please take a look and check if all your tests pass or please let me know otherwise.

Edson

Comment 7 Tomas Schlosser 2011-09-21 06:22:31 UTC
This bug was fixed in BRMS-5.2.0.ER4