[jboss-jira] [JBoss JIRA] Commented: (JBRULES-867) Can't load classes from expanded class dir on windows

[Michael Neale (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBRULES-867?page=comments#action_12367797 ] 
            
Michael Neale commented on JBRULES-867:
---------------------------------------

I tried this, adding a class folder to an eclipse project, and it worked fine for me - need more information to reproduce, perhaps some samples or a project etc.

> 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: Edson Tirelli
>            Priority: Minor
>             Fix For: FUTURE
>
>
> 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