[jboss-jira] [JBoss JIRA] (DROOLS-1198) NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
[
https://issues.jboss.org/browse/DROOLS-1198?page=com.atlassian.jira.plugi...
]
Matteo Mortari commented on DROOLS-1198:
----------------------------------------
Hello [~chrisxaustin], would it be possible for you to provide a reproducer, please?
This is because I've checked your statements but unfortunately I'm unable to
reproduce the error you mentioned.
Here are my assumptions, following your description:
* an {{Alert}} class pojo with a "user" field of type String.
* a {{User}} class pojo, which needs to be imported in the import statements - the actual
definition is not relevant
* the LHS condition as per your description with the operator {{str\[endsWith\]}}
checked against 6.4.0.Final, does not trigger the error you mentioned.
I've attached the Maven project containing the JUnit which I drafted, and running the
test suite the error does not trigger: [^DROOLS-1198-unabletoreproduce.zip]. Possibly
could help you to provide a reproducer?
NoClassDefFoundError when using str[endsWith] on a field that matches
an imported class name
--------------------------------------------------------------------------------------------
Key: DROOLS-1198
URL: https://issues.jboss.org/browse/DROOLS-1198
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.Final
Reporter: Chris Austin
Assignee: Mario Fusco
Priority: Minor
Attachments: DROOLS-1198-unabletoreproduce.zip
This error was triggered when accessing the user field with str[endsWith] when user is
null:
java.lang.NoClassDefFoundError: mssp/io/model/user (wrong name: mssp/io/model/User)
Condition that triggers the error:
$a : Alert(user!=null, user str[endsWith] "$")
This does not trigger the error:
$a : Alert(user!=null, user matches ".+\\$")
If I remove the import for the User class the error will not be triggered. As a
workaround I've switched to using matches instead of str[endsWith], but I'd prefer
to switch back.
I did not experience this issue in 6.3.0-Final, so it appears to be a regression in
6.4.0-Final
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)