Bug 724350 (BRMS-296)
| Summary: | Packge build fails if Fact Model contains Fields with capitol letters | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise BRMS Platform 5 | Reporter: | Eric D. Schabell <erics> |
| Component: | BRE (Expert, Fusion) | Assignee: | Nobody <nobody> |
| Status: | CLOSED UPSTREAM | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.0.1 | CC: | manstis, trikkola |
| Target Milestone: | ER1 | ||
| Target Release: | BRMS 5.3.0.GA | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://jira.jboss.org/jira/browse/BRMS-296 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
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.
|
Story Points: | --- |
| Clone Of: | Environment: |
Linux (Fedora 12), x86, EAP-4.3, java5, BRMS 5.0.1
|
|
| Last Closed: | 2025-02-10 03:13:46 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: | |||
|
Description
Eric D. Schabell
2010-04-06 07:47:53 UTC
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. |