[jboss-jira] [JBoss JIRA] Updated: (JBRULES-1998) Classes with same name but difference packages cannot be used as Facts in BRL definitions

Michael Neale (JIRA) jira-events at lists.jboss.org
Sun Mar 29 23:25:22 EDT 2009


     [ https://jira.jboss.org/jira/browse/JBRULES-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale updated JBRULES-1998:
-----------------------------------

       Issue Type: Feature Request  (was: Bug)
    Fix Version/s: FUTURE


OK changing this to a feature request, as  a fair bit of design work is needed. 

A better approach: 
Have import aliasing (scala has this): 

import foo.bar.SomeClass => SomeOtherNameForTheClass
(or something like that). 

Alternatively, have for GUI reasons type aliasing (so you can create a name for whatever you want) and you will of course see 2 different names. 

> Classes with same name but difference packages cannot be used as Facts in BRL definitions
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1998
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1998
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-guvnor
>    Affects Versions: 5.0.0.M5
>            Reporter: Chris LeCompte
>            Assignee: Michael Neale
>             Fix For: FUTURE
>
>
> Guvnor (as well as Drools in general) allows for defining packages which import facts from different java packages with the same name.  In a technical rules file, this problem can be resolved obviously by fully qualifying the names of the facts used in the rule(s).  In the business rule editor however the user is presented with two names in the facts drop down and can only pull properties from the last type added in the imports.  The editor should have some capability to sort this out either by appending a package name where collisions occur or by appending a (1), (2),..., (n) suffix to the names of the classes and internally mapping the facts back to their respective classes.  The error in the logs when validating a resultant rule using the editor gives the error:
> Unable to find unambiguously defined class...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jboss-jira mailing list