Workaround: Workaround Exists Workaround Description: All Fields must be named starting with small letters (non-capitols/lower-cased). securitylevel_name: Public I just spent three weeks teaching masters students a lab with BRMS. They used 5.0.1 and only the Guided Rule Editor interface (they are students attempting to become analysts) and it was amazing to watch what worked and did not with regards to non-Java people trying to create rules/dsl's/packages/tests/model's. One thing encountered was what I would consider a bug for analysts: Create a Model from the Guided Rule Editor GUI and you can create Objects (Facts) with attributes (Fields). It turns out that the packages will not build if the field names start with capital letters. This seems strange and very Java conventional, something I would not expect an analyst to adhere to.
Making On-QA to retest to see if underlying components have changed. If not, we may want to release note it and may want to set for next release?
Reproduced with 5.2.0 ER3. However, I can build a package if there is a field that is completely upper-case (like FIELD1). After some experimenting with declarative model editor, I have found: - fields that are OK: myFieldXYZ, FIELD123 - fields that break the package build: Field, aField
Fix committed by Mario Fusco.
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: When rules were constructed with the Guided Editor inconsistent case conventions were being enforced to field names, as a result packages that contained fields that started with capital letters would not build.
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 rules were constructed with the Guided Editor inconsistent case conventions were being enforced to field names, as a result packages that contained fields that started with capital letters would not build.+When rules were constructed with the Guided Editor inconsistent case conventions were enforced on field names, as a result packages that contained fields that started with capital letters would not build.
Tested with field names provided by Jiri Locker - build fails with "Field" and "aField", package builds ok with "myFieldXYZ", "FIELD123".
Re-requesting this for 5.3
Edson, Mario, FYI, these are the RegEx used by Guvnors UI: Field Name = "^[a-zA-Z][a-zA-Z\\d_$]*$" Data Type = "^([a-zA-Z][a-zA-Z\\d_$]*\\.)*[a-zA-Z][a-zA-Z\\d_$]*$" (A qualified Java type). If PackageBuilder (or where-ever) expects something different let me know - at least we should be consistent!
Hi All, I was investigating the root cause of this and it turns out there are some weird rules for capitalization in JavaBeans. From the Java API documentation: " Utility method to take a string and convert it to normal Java variable name capitalization. This normally means converting the first character from upper case to lower case, but in the (unusual) special case when there is more than one character and both the first and second characters are upper case, we leave it alone. Thus "FooBah" becomes "fooBah" and "X" becomes "x", but "URL" stays as "URL". " http://download.oracle.com/javase/6/docs/api/java/beans/Introspector.html#decapitalize(java.lang.String) This basically makes it impossible to have a "property name" with first letter in lower case and second letter in uppercase, as: aField Will be inferred as: AField Due to the naming rules above. I will try to find if we can have some kind of fallback algorithm in Drools in a way that if the above defined rule fails to find a valid field/method name, we fallback to other naming conventions. I will keep you posted.
I implemented the fallback algorithm. https://github.com/droolsjbpm/drools/compare/5bea637...10f4a0e It should work now.
(In reply to comment #10) > I implemented the fallback algorithm. > > https://github.com/droolsjbpm/drools/compare/5bea637...10f4a0e > > It should work now. Edson, would you please back out these changes on the 5.2.x branch? The bug didn't receive the 5.2.0 ack and we can't possibly risk a regression this late in the cycle. Thanks for fixing this, we will pick it up in 5.3.
Edson did revert the changes. -> MODIFIED
Fix verified in BRMS 5.3.0.DEV5.
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 rules were constructed with the Guided Editor inconsistent case conventions were enforced on field names, as a result packages that contained fields that started with capital letters would not build.+When rules were constructed with the Guided Editor inconsistent case conventions were enforced on field names, as a result packages that contained fields that started with capital letters would not build. This has been resolved by including a fallback algorithm that checks names and converts them to adhere with the case conventions if necessary.
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.