[JBoss JIRA] Created: (JBRULES-867) Can't load classes from expanded class dir on windows
by Dan Lipofsky (JIRA)
Can't load classes from expanded class dir on windows
-----------------------------------------------------
Key: JBRULES-867
URL: http://jira.jboss.com/jira/browse/JBRULES-867
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 3.0.6
Environment: Windows XP SP2 (problem not reproducable on Linux), JDK 1.5.0_11-b03, Ant 1.7.0, Eclipse 3.2.2
Reporter: Dan Lipofsky
Assigned To: Mark Proctor
Priority: Minor
When running some JUnit tests of our rules from an Ant task or from
Eclipse, we got the following rule compile errors:
org.drools.rule.InvalidRulePackage: Rule Compilation error
The import com.bricsnet.core.util.constants cannot be resolved
UserGroup cannot be resolved
The same rules compile perfectly on the server.
On the server the class is question is only available from a JAR file.
In Eclipse it in an expanded class dir. In the Ant task both the
expanded class dir and the JAR file were in the classpath, but the
expanded class dir was first. Putting the JAR first on the classpath
solved the problem for the ant task (but this is not possible for
eclipse since the JAR is not available). Therefore we believe the
problem is specifically related to loading from an expanded class dir.
The problem seems to occur on Windows but not Linux.
Finally the problem only seems to occur for some classes.
All 3 of the classes in the sample rule file below are
in the same boat, but for some reason only UserGroup
is a problem (it might be the
Example 1 (fails):
package com.foobar.rules;
import com.foobar.core.util.constants.UserGroup;
import com.foobar.core.util.security.principal.UserPrincipal;
import com.foobar.core.util.security.auth.RuleAuthorization;
rule "test_rule"
when
r: RuleAuthorization()
u: UserPrincipal()
eval(u.hasGroup(123))
then
r.setLevel(RuleAuthorization.READ);
end
Example 2 (works):
package com.foobar.rules;
import com.foobar.core.util.security.principal.UserPrincipal;
import com.foobar.core.util.security.auth.RuleAuthorization;
rule "test_rule"
when
r: RuleAuthorization()
u: UserPrincipal()
eval(u.hasGroup(123))
then
r.setLevel(RuleAuthorization.READ);
end
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (JBRULES-1289) BRMS gives unusable error messages when validating DSL based rules
by Phil Verghese (JIRA)
BRMS gives unusable error messages when validating DSL based rules
------------------------------------------------------------------
Key: JBRULES-1289
URL: http://jira.jboss.com/jira/browse/JBRULES-1289
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-brms
Affects Versions: 4.0.2
Reporter: Phil Verghese
Assigned To: Mark Proctor
The error messages that are shown when you click "Validate" when editing a business rule that uses a DSL in the BRMS are not user-friendly at all. If I make a small typo and misspell the name of an attribute (a very likely thing for a BRMS user to do), and click the Validate button, the error I get back is a big stack trace starting with "java.lang.RuntimeException: SNO: Conversion failed at org.codehaus.janino.UnitCompiler.numericPromotion(UnitCompiler.java) at ..." Nowhere in that stack trace is anything that gives a hint that
the error is just a typo of an attribute name.
Contrast this with the rather helpful error message I get if I make the same typo when editing a DRL rule: "Unable to create Field Extractor for 'overtimHours'". (The error is that I misspelled overtimeHours).
The BRMS needs to give the same type of helpful error message on validation errors when editing a DSL rule.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (JBRULES-1133) Janino and eclipse compiler might need to be optional for 4.1
by Geoffrey De Smet (JIRA)
Janino and eclipse compiler might need to be optional for 4.1
-------------------------------------------------------------
Key: JBRULES-1133
URL: http://jira.jboss.com/jira/browse/JBRULES-1133
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 4.0.0.GA
Reporter: Geoffrey De Smet
Assigned To: Geoffrey De Smet
Priority: Minor
Fix For: FUTURE
I didn't want to make this change for 4.0.x as it would require our users to put a direct dependency on either janino or eclipse-compiler.
Drools-compiler needs one of both.
Currently users get bloated with a transitive dependency on both.
Making them optional would force them to make a dependency on one of the themselves... which makes the "hello world" program harder.
As it would also force jbrms's etc tests to choose one.
Why shouldn't do this before 4.1, if we even want to do this.
What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (JBRULES-1249) Allow repository location to be specified in BRMS web client
by Shahad Ahmed (JIRA)
Allow repository location to be specified in BRMS web client
------------------------------------------------------------
Key: JBRULES-1249
URL: http://jira.jboss.com/jira/browse/JBRULES-1249
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-brms
Affects Versions: 4.0.1
Reporter: Shahad Ahmed
Assigned To: Mark Proctor
At present, any custom location of the repository is set in a components.xml file inside the WEB-INF directory of the BRMS war file. It would be better if the user could specify the location using the BRMS web client itself, rather than have to unzip, modify and zip up the WAR file. Perhaps this functionality could be added to the Admin section of the BRMS.
One advantage of this is that users could also then work with multiple repositories (e.g. for different projects). In effect there would be an option to create a new repository (specified by a directory given by the user), open an existing repository and close a repository.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months