Community
Participate
Working Groups
I am seeing the following NPE in Xtext 2.0M4 and a half. NamesAreUniqueValidator.doCheckUniqueNames(Resource, CancelIndicator) line: 66 NamesAreUniqueValidator.checkUniqueNamesInResourceOf(EObject) line: 62 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 592 AbstractDeclarativeValidator$MethodWrapper.invoke(AbstractDeclarativeValidator$State) line: 111 OCLinEcoreJavaValidator(AbstractDeclarativeValidator).internalValidate(EClass, EObject, DiagnosticChain, Map<Object,Object>) line: 297 because resourceServiceProviderRegistry is null. It would appear that a) there is no underlying deefault for the injection mechanism b) there is a missing null test
The class is not designed to be used without an injector. I've initialized the field with a default, but you shouldn't expect every Xtext class to work outside of Guice generally.
To put it more accurately: Shouldn't expect any class to work without its mandatory dependencies (i.e. any @Inject members without (optional=true)
I don't understand. I'm not aware that I'm deliberately using this class; I think the Xtext framework has provided it for me, although perhaps it was the Xtext 1.0 framework and I've neglected to (re-)align something for 2.0. The invocation was within Eclipse (rather than standalone Junit) so injection should be full configured.
Sorry, it looked like you were instantiating the instance yourself.
Could it be that you instantiated OCLinEcoreJavaValidator using the constructor?
No. The class is actually an empty inheritance of the auto-generated AbstractOCLinEcoreJavaValidator instantiated by: // contributed by org.eclipse.xtext.generator.validation.JavaValidatorFragment @org.eclipse.xtext.service.SingletonBinding(eager=true) public Class<? extends org.eclipse.ocl.examples.xtext.oclinecore.validation.OCLinEcoreJavaValidator> bindOCLinEcoreJavaValidator() { return org.eclipse.ocl.examples.xtext.oclinecore.validation.OCLinEcoreJavaValidator.class; } No other references. I've been finding my M4.5 workspace unsatisfactory for MWE scripts, MWE2 editor comes and goes, ... so perhaps some strange hybrid 1.0/2.0 has occurred. For Xtext 2.0 I had to remove registerForImportedPackages = false from fragment = validation.JavaValidatorFragment No idea why, or what the impact might be.
The line is: final IResourceServiceProvider resourceServiceProvider = resourceServiceProviderRegistry.getResourceServiceProvider(resource.getURI()); Are you sure the registry and not the resource was null? I've added a null check for the resource.
The debugger showed a null resourceServiceProviderRegistry, but the debugger is not always truthful. I didn't switch views to force a refresh so it is perhaps possible that is was a null resource.
I can reproduce the problem by a dummy edit in the following OCLinEcore file: module _'My.ecore' package ; for which the empty package name is a problem. Refreshing the Variables View confirms that resourceServiceProviderRegistry really is null. The fuller stack trace is: NamesAreUniqueValidator.doCheckUniqueNames(Resource, CancelIndicator) line: 66 NamesAreUniqueValidator.checkUniqueNamesInResourceOf(EObject) line: 62 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 592 AbstractDeclarativeValidator$MethodWrapper.invoke(AbstractDeclarativeValidator$State) line: 111 OCLinEcoreJavaValidator(AbstractDeclarativeValidator).internalValidate(EClass, EObject, DiagnosticChain, Map<Object,Object>) line: 297 OCLinEcoreJavaValidator(AbstractInjectableValidator).validate(EClass, EObject, DiagnosticChain, Map<Object,Object>) line: 62 NoEObjectCompositeEValidator(CompositeEValidator).validate(EClass, EObject, DiagnosticChain, Map<Object,Object>) line: 119 CancelableDiagnostician(Diagnostician).validate(EClass, EObject, DiagnosticChain, Map<Object,Object>) line: 165 CancelableDiagnostician(Diagnostician).validate(EObject, DiagnosticChain, Map<Object,Object>) line: 143 CancelableDiagnostician.validate(EObject, DiagnosticChain, Map<Object,Object>) line: 36 CancelableDiagnostician(Diagnostician).validate(EObject, Map<?,?>) line: 126 ResourceValidatorImpl.validate(Resource, CheckMode, CancelIndicator) line: 107 ValidationJob$1.exec(XtextResource) line: 79 ValidationJob$1.exec(Object) line: 1 XtextDocument$XtextDocumentLocker(AbstractReadWriteAcces<P>).readOnly(IUnitOfWork<T,P>) line: 32 OCLinEcoreDocument(XtextDocument).readOnly(IUnitOfWork<T,XtextResource>) line: 86 ValidationJob.createIssues(IProgressMonitor) line: 75 ValidationJob.run(IProgressMonitor) line: 64 Worker.run() line: 54 of which perhaps only NoEObjectCompositeEValidator is unusual. It is my workaround for Bug 322639. public class NoEObjectCompositeEValidator extends CompositeEValidator { public NoEObjectCompositeEValidator() { setUseEObjectValidator(false); // FIXME Find out how to inject at USE_EOBJECT_VALIDATOR } } [Perhaps you can solve my FIXME for me.]
There was some strange "robustness" code, which might have caused the situation. I've changed the implementation so that it fails earlier with better information. Could you do me a favor and retry tomorrow with the latest builds. Unfortunately I'm not able to reproduce your problem.
(In reply to comment #10) > Could you do me a favor and retry tomorrow with the latest builds. > Unfortunately I'm not able to reproduce your problem. Installations are pretty difficult at present. EMF M5 has no Ecore, Xtext nightlies are not self-contained, Itemis nightlies have a dependency on a missing XSD typesystem... Eventually found a selective Itemis update that P2 liked. NPE does not appear, and editor seems sensible, but suddenly there is log4j:WARN No appenders could be found for logger (org.eclipse.xtext.ui.internal.Activator). log4j:WARN Please initialize the log4j system properly. in the Console.
fixed
Closing all bugs that were set to RESOLVED before Neon.0
