Bugzilla – Full Text Bug Listing
| Summary: | [delegate] NPE for Query Delegate creation in the absence of other delegates | ||
|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | alex.tugarev, eclipse, jconlon, Kenn.Hussey, laurent.goubet |
| Version: | 3.1.0 | ||
| Target Milestone: | SR1 | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
The repro fails at line 5; there is no "EMF Ecore Data Source" to select.
------
The following JUnit test demonstrates the NPE
public void test_queryExecutionWithLibrary() {
QueryDelegate.Factory factory = QueryDelegate.Factory.Registry.INSTANCE
.getFactory(OCLDelegateDomain.OCL_DELEGATE_URI);
String n = "n";
String expression = "self.name";
Library library = EXTLibraryFactory.eINSTANCE.createLibrary();
library.setName("test");
Map<String, EClassifier> parameters = new HashMap<String, EClassifier>();
parameters.put(n, EcorePackage.Literals.ESTRING);
QueryDelegate delegate = factory.createQueryDelegate(EXTLibraryPackage.Literals.LIBRARY,
parameters, expression);
Map<String, Object> bindings = new HashMap<String, Object>();
bindings.put(n, "test");
Object result = execute(delegate, library, bindings);
assertEquals(result, "test");
}
which is
java.lang.NullPointerException
at org.eclipse.ocl.ecore.delegate.OCLQueryDelegate.prepare(OCLQueryDelegate.java:94)
at org.eclipse.ocl.ecore.delegate.OCLQueryDelegate.execute(OCLQueryDelegate.java:143)
at org.eclipse.ocl.ecore.tests.DelegatesTest.execute(DelegatesTest.java:1152)
The problem is that getDelegateDomain returns null since no delegate domain has been created by the EPackage Annotation that is required for all (other) delegates.
OCL Query delegates seem to have only been tested on packages that also had invocation/setting/validation delegates so the package adapter was created by them.
This is not therefore a regression. The observed behaviour is consistent but unhelpful.
For query delegates at least, callers have no need for EMF registrations, so the getDelegateDomain-or-return-null needs to be getDelegateDomain-or-create.
EGIT doesn't seem to support creating patches, so no patch attached. Branch bug/353171 ready for review. Changes introduce a loadDelegateDomain method with package protection to avoid API versioning problems in SR1. FIXMEs indicate revised protection for 3.2.0. To create a patch, try git diff --no-prefix -b master The --no-prefix avoids the a/ and b/ prefixes and makes it an Eclipse-applicable patch. -b suppresses whitespace changes, as usual. (In reply to comment #3) > To create a patch, try > > git diff --no-prefix -b master > > The --no-prefix avoids the a/ and b/ prefixes and makes it an > Eclipse-applicable patch. -b suppresses whitespace changes, as usual. Wow! EGIT really is not yet fit for purpose. It seems that as an absolute minimum there should be an EGIT Console in which to type all these git command workarounds. What folder, path, environment, ... setup is necessary to make git work with an Eclipse config? Not sure what you mean by "work with an Eclipse config." I use cygwin and the git client coming with it when on Windows and the git command-line tools coming with Debian when on Linux. When you've cloned a git repository to your local disk and have a git command-line client installed, just cd to the directory where the git repository lives (or any subdirectory thereof) and issue the git commands you like. (In reply to comment #2) > Branch bug/353171 ready for review. The pivot changes under examples/ don't need review. The changes in the mature code look good to me except that I suggest introducing "protected" instead of the FIXMEs on master, then cherry-pick onto maintenance/R3_1 and subsequently change to default visibility on maintenance/R3_1. With these changes, +1 Ok, we agree on the end results; I might even add some comments. I'll have to learn a bit more about GIT to get cherry-picking to work; so far the only 'cherry-picking' I have found is in a can't-do error message. On the command line it works as follows: git checkout maintenance/R3_1 git cherry-pick <commit-id from master branch> I can't help but give some input here... We have been using git for EMF Compare since january, and for Acceleo since June. Using eGit 0.x was indeed problematic for some use cases, and eGit 1.0 still has one or two things really aggravating ... but all in all I rarely have to go back to the command line. Let's start with those case : going back to the command line is only necessary to stash changes (and that's because of the way I work, I could also commit the change instead of stashing it). Other than that, I only use the command line to confirm things (git status). The thing that is missing to you is, I believe, the proper use of the git history view in Eclipse. right-click a project (or the repository in the git repoitories view) and use team > show in history. In the history view, click the "database-like" icon (the yellow cilinder) to show the whole history instead of the history for a single file, and the "branch" icon to display all of the branches (okay, with your repository and all of the branches you do for the bugs, that might give a real mess ...). Now, you can right-click a commit to reset (go back in history to that commit), cherry-pick (take a commit from another branch to your currently checked out branch), create a patch for that commit... The one "aggravating" thing with patches is that eGit does not allow you to create a patch without a commit. That does not really matter once you understand how to work around it : commit the changes, right-click the commit and select "create patch", right-click the previous commit and select "reset". a Hard reset will erase the changes in your local copy so that you will have to re-apply the patch if you want the changes. (In reply to comment #1) > OCL Query delegates seem to have only been tested on packages that also had > invocation/setting/validation delegates so the package adapter was created by > them. > > This is not therefore a regression. The observed behaviour is consistent but > unhelpful. I don't know whether it's a regression or not, but I tested the data set wizard thoroughly on packages without an annotation when the feature was being delivered (i.e., around the Indigo M5 timeframe), so something must have changed since then... > For query delegates at least, callers have no need for EMF registrations, so > the getDelegateDomain-or-return-null needs to be getDelegateDomain-or-create. Sounds right to me, thanks. (In reply to comment #2) > Branch bug/353171 ready for review. > > Changes introduce a loadDelegateDomain method with package protection to avoid > API versioning problems in SR1. FIXMEs indicate revised protection for 3.2.0. I've applied that patch to the plugin in my workspace. It works fine for me. I'm looking forward to SR1. Many thanks. *** Bug 353227 has been marked as a duplicate of this bug. *** Merged to origin/master Merged to origin/maintenance/R3_1 CLOSED after a year in the RESOLVED state. |
Raised in response to eclipse.dtp posting by Alex Tugarev, relayed by Kenn Hussey. Original posting: The EMF ODA driver has no category. So uncheck "Group items by category" on the "Install new Software" page. Be forewarned: There is still a bug in connection with OCL dependencies. The field delegateDomain used in org.eclipse.ocl.ecore.delegate.AbstractOCLDelegateFactory.getDelegateDomain(EPackage) is null, though an OCLDelegateDomain object is expected. This bug prevents you finishing the New Data Set Wizard. So the ODA driver is not useable, unless you patch the method mentioned above yourself. Kenn's relay: To try the ODA driver yourself, you can do the following: 1. Install BIRT (and restart). 2. Install the Extended Library examples using the EMF examples installer. 3. From a runtime workspace, create a new project and a new library model using the EXTLibrary Model example editor. 4. Create a new Report project, switch to the Report Design perspective, and create a report. 5. From the Data Explorer view, create a new data source, selecting the "EMF Ecore Data Source" type. 6. Select the model you created in step 3 as the resource and press 'Finish'. 7. Create a new data set for the data source you created in step 5/6. 8. Now, in the data set editor, you can select a Context Type and type an OCL expression to see the syntax highlighting and content assist. If you switch to the Preview Results page, you should see the results of your query. Note that the above fails at step #7 due to an NPE in OCL. The code that triggers is it as follows: factory.createQueryDelegate(context, map, queryText).prepare(); I've debugged this a bit and it seems that the DelegateEPackageAdapter has an empty (not null) delegateDomainMap. Looking at the code, I couldn't understand why, when populating the domain map, it tries to obtain an annotation from the Ecore package: public Map<String, DelegateDomain> getDelegateDomains() { if (delegateDomainMap == null) { delegatedBehaviorMap = new HashMap<String, List<DelegateDomain>>(); delegateDomainMap = new HashMap<String, DelegateDomain>(); EPackage ePackage = getTarget(); EAnnotation eAnnotation = ePackage.getEAnnotation(EcorePackage.eNS_URI); if (eAnnotation != null) { for (DelegatedBehavior<?, ?, ?> delegatedBehavior : AbstractDelegatedBehavior.getDelegatedBehaviors()) { String behaviorName = delegatedBehavior.getName(); String delegateURIs = eAnnotation.getDetails().get(behaviorName); if (delegateURIs != null) { for (StringTokenizer stringTokenizer = new StringTokenizer(delegateURIs); stringTokenizer.hasMoreTokens();) { String delegateURI = stringTokenizer.nextToken(); initializeDelegatedBehavior(delegateURI, delegatedBehavior); } } } } } return delegateDomainMap; } The package in question here is the package for the extended library model, but I also tried it with the Ecore package; neither of these have such an annotation...