Description vega 2010-06-08 10:18:56 EDT

Created attachment 171404 [details]
modified org.eclipse.emf.validation.examples.general to reproduce the problem

If you specify a qualified Id in the definition of a ConstraintProvider extension, there is a NullPointerException in JavaConstraintParser.

After digging a little with the debugger I pinpointed the problem to method JavaConstraintParser.parseConstraint() which uses IExtension.getNamespaceIdentifier() of the declaring extension as the Id of the bundle (used to load the AbstractModelConstraint class).

In the case of a qualified Ids, the namespace identifier is different than the bundle Id.

The workaround is simple, change the ID to use the plugin Id as name space, or use simple (non qualified) Ids in the ConstraintProviders definition.

However, it seems to me that this behavior is not consistent with other plug-ins in the platform, and more importantly it is not consistent with the behavior of IConfigurationElement.createExecutableExtension.
 
I think you should instead use IConfigurationElement.getContributor to get the bundleID, see the following quote from the documentation of the deprecated method IConfigurationElement.getNamespace

<quote>

As namespace is no longer restricted to the contributor name, use {@link #getNamespaceIdentifier()} to obtain namespace name or {@link #getContributor()} to get the name of the contributor of this registry element.

In the past namespace was dictated by the name of the bundle. If bundle <code>org.abc</code> contributed registry element with Id of <code>MyId</code>, the namespace of the element was always set to <code>org.abc</code>, producing the qualified name of <code>org.abc.MyId</code>.

The namespace used to be the same as the bundle name. As a result, the {@link #getNamespace()} method was used both to obtain the name of the bundle and to obtain the namespace of a registry element.

Since 3.2, the extension registry allows elements to specify qualified name. The extension point of the plug-in <code>org.abc</code> could specify <code>org.zzz.MyExtPoint</code> as an Id. In this case, namespace name is <code>org.zzz</code>, but the contributor name is <code>org.abc</code>.

(The use of a simple Id is still a preferred way. Whenever possible, specify only the simple Id and let runtime take care of the rest.)

If your code used the {@link #getNamespace()} to obtain the name of the contributing bundle, use {@link #getContributor()}. The typical usage pattern here is to find a bundle name to obtain some information from the corresponding OSGi bundle. For example, deducing the file location
specified as a relative path to the bundle install location would fall into this group.

If your code used the {@link #getNamespace()} to obtain the namespace of the registry element, use {@link #getNamespaceIdentifier()}. Typically, this is the case when code is trying to process registry elements belonging to some logical group. For example, processing notifications for all elements belonging to the <code>org.abc</code> namespace would fall into this category.

</quote> 

The same assumption regarding the bundleId is done at several other places in the framework, particularly in class XmlConstraintDescriptor

I attach a modified version of org.eclipse.emf.validation.examples.general to reproduce the problem. All the modifications are in the plugin.xml file. 

The important modification is specifying a qualified Id for the ConstraintProviders extension defintion. 

There is a another subtle difference in the file plugin.xml w.r.t the original: the header of the file specifies an eclipse version greater than 3.2 <?eclipse version="3.4"?>. Otherwise, the platform considers that this is an pre-3.2 plugin file and a compatibility layer kicks-in that interprets the Ids in the old way, always returning the pluginId as namespace identifier, and the problem doesn't show up.

I have tested in Galileo+EMF-2.5+Validation-1.3 and also in Helios+EMF-2.6+Validation-1.4, an although the NPE happens in different places the error is present.