Red Hat Bugzilla – Bug 839759
Drools brings compile error when trying to length-check a Fact's attribute.U
Last modified: 2018-01-29 09:05:23 EST
Description of problem: Using the 'business_rules_service' quickstart, make the following modifications: <<<to Customer.java>>> private String FIRMA = "aFirma"; public String getFIRMA() { return FIRMA; } public void setFIRMA(String FIRMA) { this.FIRMA = FIRMA; } <<<to MyBusinessRules.drl >>>> rule "Length check " when # FAILS customer: Customer( FIRMA.Length() > 0) # FAILS customer: Customer( FIRMA.length() > 0) # FAILS customer: Customer( FIRMA.getLength() > 0) # FAILS customer: Customer( FIRMA.toString().getLength() > 0) # FAILS customer: Customer( FIRMA.toString().length() > 0) $cust : Customer() # FAILS eval ($cust.getFIRMA().length >2) eval ($cust.getFIRMA().getLength() >2) then System.out.println("How can I check length?"); end ---------------------------------------------------------------------------- All the above attempts will result in errors like: 2012-07-12 12:45:00,227 DEBUG [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] (pool-118-thread-1) Unexpected exception caught while processing the action pipeline org.jboss.soa.esb.actions.ActionProcessingException: Generation raised the following errors: Rule Compilation error : [Rule name='Length check 2'] com/jboss/soa/esb/routing/cbr/Rule_Length_check_2_0.java (8:614) : The method getLength() is undefined for the type String
pCtx object contains a map of variableVisibility. debugging shows that the attribute "FIRMA" is saved a "fIRMA" with first character been converted to the other case where tk.getAbsoluteName() is FIRMA. this fails in ParserContext.isVariableVisible(String var)[2] I will run one additional test. I'll change the src attribute to "firma". this will confirm that its not the length thats the problem here. [1] if (!propVerifier.isMethodCall() && !returnType.isEnum() && !pCtx.isOptimizerNotified() && pCtx .isStrongTyping() && !pCtx.isVariableVisible(tk.getAbsoluteName()) && !tk.isFQCN()) { throw new CompileException("no such identifier: " + tk.getAbsoluteName(), expr, tk.getStart()); } [2] if (AbstractParser.LITERALS.containsKey(var) || hasImport(var)) { return true; }
Related to: https://issues.jboss.org/browse/JBRULES-3147 http://drools.46999.n3.nabble.com/rules-users-Capitalized-element-names-td3201971.html
Confirmed this *works* under SOA-P 5.3ER4. ---------------------------------------------------------------------------- JBRULES-3147 references the following fix code from MVEL fix: https://github.com/mvel/mvel/pull/22/files It contains: (ParserContext.java) - scope.add(ReflectionUtil.getPropertyFromAccessor(m.getName())); 456 + String propertyName = ReflectionUtil.getPropertyFromAccessor(m.getName()); 457 + scope.add(propertyName); 458 + propertyName = propertyName.substring(0, 1).toUpperCase() + propertyName.substring(1); 459 + scope.add(propertyName);
SOA-P 5.3ER4 does not exhibit this bug. But it has 3 versions of mvel: ./server/production/deployers/esb.deployer/lib/mvel2-2.1.0.drools10.jar ./server/production/deploy/bpel-console/gwt-console.war/WEB-INF/lib/mvel2-2.0.18-RC4.jar ./server/production/deploy/jbrules.esb/mvel2-2.1.0.drools16.jar Looking at the two likely to be used (outside the gwt war), we see the above code *is* applied to ParserContext.