Release Notes Text: Removed: Person fact with enum (attached)

public class Person {
	
	public enum Sex{
		MALE,FEMALE
	}	
	public Sex getSex() {
		return sex;
	}
	public void setSex(Sex sex) {
		this.sex = sex;
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
	private Sex sex;
	private String name;
}

And a rule like the printcreen attached.
It should generate the code:


1.	|	rule "rule1"
2.	|	    dialect "mvel"
3.	|	    when
4.	|	        Person( sex == Person.Sex.Female )
5.	|	    then
6.	|	        System.out.println("sexo feminino")
7.	|	end



But it should not. It generated this:

1.	|	rule "rule1"
2.	|	    dialect "mvel"
3.	|	    when
4.	|	        Person( sex == "1" )
5.	|	    then
6.	|	        System.out.println("sexo feminino")
7.	|	end

... that never (obviously) is matched. 
Steps to Reproduce: Removed: obviously Added: Person fact with enum (attached)

public class Person {
	
	public enum Sex{
		MALE,FEMALE
	}	
	public Sex getSex() {
		return sex;
	}
	public void setSex(Sex sex) {
		this.sex = sex;
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
	private Sex sex;
	private String name;
}

And a rule like the printcreen attached.
It should generate the code:


1.	|	rule "rule1"
2.	|	    dialect "mvel"
3.	|	    when
4.	|	        Person( sex == Person.Sex.Female )
5.	|	    then
6.	|	        System.out.println("sexo feminino")
7.	|	end



But it should not. It generated this:

1.	|	rule "rule1"
2.	|	    dialect "mvel"
3.	|	    when
4.	|	        Person( sex == "1" )
5.	|	    then
6.	|	        System.out.println("sexo feminino")
7.	|	end

... that never (obviously) is matched.

Steps to Reproduce: Removed: Person fact with enum (attached)

public class Person {
	
	public enum Sex{
		MALE,FEMALE
	}	
	public Sex getSex() {
		return sex;
	}
	public void setSex(Sex sex) {
		this.sex = sex;
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
	private Sex sex;
	private String name;
}

And a rule like the printcreen attached.
It should generate the code:


1.	|	rule "rule1"
2.	|	    dialect "mvel"
3.	|	    when
4.	|	        Person( sex == Person.Sex.Female )
5.	|	    then
6.	|	        System.out.println("sexo feminino")
7.	|	end



But it should not. It generated this:

1.	|	rule "rule1"
2.	|	    dialect "mvel"
3.	|	    when
4.	|	        Person( sex == "1" )
5.	|	    then
6.	|	        System.out.println("sexo feminino")
7.	|	end

... that never (obviously) is matched. Added: Person fact with enum (attached)

public class Person {
	
	public enum Sex{
		MALE,FEMALE
	}	
	public Sex getSex() {
		return sex;
	}
	public void setSex(Sex sex) {
		this.sex = sex;
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
	private Sex sex;
	private String name;
}

And a rule like the printcreen attached.
It should generate the code:


1.	|	rule "rule1"
2.	|	    dialect "mvel"
3.	|	    when
4.	|	        Person( sex == Person.Sex.Female )
5.	|	    then
6.	|	        System.out.println("sexo feminino")
7.	|	end



but it does not. It generated this:

1.	|	rule "rule1"
2.	|	    dialect "mvel"
3.	|	    when
4.	|	        Person( sex == "1" )
5.	|	    then
6.	|	        System.out.println("sexo feminino")
7.	|	end

... that never (obviously) is matched.

fact model

Attachment: Added: person2.jar

Link: Added: This issue is related to GUVNOR-182

I can't reopen GUVNOR-182, I don t have grants for it. Please, can you reopen Tihomir?

Done, you should be able to add your comments to it now.

Diffs for fix

Attachment: Added: EnumDropDownLabel.patch
Attachment: Added: ConstraintValueEditor.patch
Attachment: Added: sceb.patch
Attachment: Added: BRDRLPersistence.patch

Link: Added: This issue is related to GUVNOR-1171

Escaping all literals with quotes is a wider issue than just enums. Create any rule with literals and they're all enclosed in quotes on IIRC all editors that generate their DRL from FactModel.

I believe this has been fixed for 5.2.

GSS prioritizes 'medium'.  Customer is watching issue, it's been a long time.

After checking the commit log, I think this issue should be fixed for BRMS-5.2 ER3.
So I will change it to ON_QA state

The source looks ok, POJO model with enum usable in rules, test scenarios show the rules are fired exactly when they should be.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
https://bugzilla.redhat.com/show_bug.cgi?id=724629

When using Java Enums in fact model the Guided Editor showed a combo box with the correct values however, the values were parsed as strings and didn't work as expected. This has been resolves and the values are being parsed as expected.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,3 +1 @@
-https://bugzilla.redhat.com/show_bug.cgi?id=724629
-
 When using Java Enums in fact model the Guided Editor showed a combo box with the correct values however, the values were parsed as strings and didn't work as expected. This has been resolves and the values are being parsed as expected.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-When using Java Enums in fact model the Guided Editor showed a combo box with the correct values however, the values were parsed as strings and didn't work as expected. This has been resolves and the values are being parsed as expected.+When using Java Enums in a fact model the Guided Editor showed a combo box with the correct values however, the values were parsed as strings and didn't work as expected. This has been resolves and the values are being parsed as expected.

This issue was not totally fixed yet. If you click on Literal Value instead of Formula (in BRL editor), you will look a value like Person$Sex.MALE wich is not valid.

Using nested Enum definitions inside classes is a very common approach. Please follow the steps commented in this BZ to test it.

PS: I've tested with Drools/BRMS 5.3 bits and the issue happens there too

Removed linked JIRA as it was unrelated. This Bugzilla item is shown as VERIFIED which normally means it has passed testing however the above comments suggest it has not. Which is correct?

This has been fixed in master and community 5.4.x branch. Please advise if you want back-ported to 5.3.x branch.

(In reply to comment #22)
> This has been fixed in master and community 5.4.x branch. Please advise if you
> want back-ported to 5.3.x branch.

Please do. Comment 15 explains why this was marked as VERIFIED - if there were some other manifestations of the problem, we probably didn't know about them.

(In reply to comment #19)
> This issue was not totally fixed yet. If you click on Literal Value instead of
> Formula (in BRL editor), you will look a value like Person$Sex.MALE wich is not
> valid.
> 
> Using nested Enum definitions inside classes is a very common approach. Please
> follow the steps commented in this BZ to test it.

(In reply to comment #21)
> Removed linked JIRA as it was unrelated. This Bugzilla item is shown as
> VERIFIED which normally means it has passed testing however the above comments
> suggest it has not. Which is correct?


This is a slightly different issue, IMO. And it might have been introduced after this bug was verified, with the transition to 5.3 - which would also explain why it slipped through our testing as there were a lot of changes. I'd suggest a separate BZ.

The enum issue reported herein (need for Person.Sex.MALE for a Sex enumeration nested inside the Person class, and not Person$Sex.MALE or other literal values) has been fixed and back-ported to 5.3.x branch. Set to MODIFIED so it can be tested with the next BRMS build.

This fix has been committed to project branch which BRMS 5.3 used.

Request block+ flag.

And the target release, and flag information seems not valid since it's expected for BRMS 5.3.0 and not a support patch.

This has been added to some previous product build and is working. I don't know, why it's still only MODIFIED - setting to VERIFIED, so it can be closed.