Bug 724312 (BRMS-257)

Summary: Remove hard restriction of not being able to have wild card imports
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Tihomir Surdilovic <tsurdilo>
Component: unspecifiedAssignee: Jervis Liu <jliu>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: high    
Version: 5.0.0 GACC: mproctor
Target Milestone: ---   
Target Release: 5.1.0 GA, 5.0.2   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/BRMS-257
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-01 02:31:58 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Deadline: 2010-03-12   

Description Tihomir Surdilovic 2010-02-16 04:08:53 UTC
Date of First Response: 2010-03-04 15:10:11
Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/522653
securitylevel_name: Public

Currently it is not possible to have wild card imports in package configuration imported types text box. 
Code imposes this hard restriction:

http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-compiler/src/main/java/org/drools/guvnor/server/rules/SuggestionCompletionLoader.java

specifically:

private void populateModelInfo(final PackageDescr pkgDescr, final List jars) {
...
if ( className.endsWith( "*" ) ) {
                this.errors.add( "Unable to introspect model for wild card imports (" + className + "). Please explicitly import each fact type you require." );
} else {
   resolver.addImport( className );
final Class clazz = loadClass( className,jars );
...

It would be better to allow wild card imports or have an option to enable/disable it in the package configuration unless there is some hard limit which I do not know of.

Comment 1 Jervis Liu 2010-03-04 07:19:01 UTC
Link: Added: This issue depends GUVNOR-513


Comment 2 Anne-Louise Tangring 2010-03-04 20:10:11 UTC
Approved for 5.0.2 if done by due date.

Comment 3 Jervis Liu 2010-03-15 03:19:38 UTC
DRL rules already supports import *, so this is a purely GUI issue. My impression is that this may not be a good idea, as the GUI needs to be eager and loads all type up for drop downs. This may make the GUI very inefficient. This is different to the import on demand in Java. In the import on demand case, java can be lazy and only resolves and loads classes that are needed during compiling. 

Having said that, we may still support import * if there is a valid use case and this support improves usability. As far as I know, the "Imported types" list is automatically populated with class types when a jar is uploaded. In this case, use does not need to edit the imported types manually, thus he/she does not need to use a import * which may save his/her time. Is there any other use cases when users may need to use import *?

Comment 4 Michael Neale 2010-03-15 03:26:21 UTC
ok, spoke with Jervis about this - we would like to know a bit more about what the underlying requirement is for this. 

The reason is that .* imports don't work well with the GUI - what if there are 1000 classes in that package ? Guvnor/GUI has to load up information for 1000 classes, even if they are not all needed (obviously this is fine for the compiler which can be lazy). 

Or, is this indicative of another problem - ie there is no easy gui to bulk add/update imports (ie you update a jar, you would like to be able to import all classes in a given package name, etc). 

So if we know, then we can pick best approach. 

import x.* could be doable - but would have to find and put an upper limit on the number of classes lest the UI become unresponsive (eg if someone accidentally imports far to many classes). 

Comment 5 Jervis Liu 2010-03-15 08:12:01 UTC
The reason why user raised this issue is because https://jira.jboss.org/jira/browse/BRMS-228. With BRMS-228, they have to manually import types, which is boring and time consuming. This is the only scenario when a user need to use import *. With BRMS-228 being fixed already, I think we can safely close this jira now. 

Comment 7 Jervis Liu 2010-04-07 04:53:24 UTC
The Resolution for this jira is "Wont fix". This is because there is no use cases that a user need to import types manually. See my previous comments. 

Comment 8 Jervis Liu 2010-05-25 06:22:28 UTC
Close this for now. But feel free to reopen if you want this jira to be treated differently. 

Comment 9 David Le Sage 2010-11-01 02:29:58 UTC
Temporarily reopening to add release notes stats.

Comment 10 David Le Sage 2010-11-01 02:30:47 UTC
Release Notes Docs Status: Added: Not Required
Writer: Added: dlesage