Home » Modeling » EMF » NPE When Trying To Create A CreateChildCommand For XSD Element Of Complex Type
| NPE When Trying To Create A CreateChildCommand For XSD Element Of Complex Type [message #645163] |
Wed, 15 December 2010 18:22  |
 elvisisking
Messages: 8
Registered: October 2010 |
Junior Member |
|
|
We are now using EMF 2.6. The problem is with an XSD element of a complex type and trying to create a CreateChildCommand for an Annotation. I tested this with an older version of EMF (2.1) and it worked fine. I can provide XSDs if that would help (see snippet at end). See details below.
Much thanks!
========
Here are some details when NPE occurs:
XSD Element: entry (in the Bibliography complex type - see Books.xsd attachment)
eFeature: EReferenceImpl
featureID: 28
dynamicFeatureID: 19
CommandParameter:
owner = org.eclipse.xsd.impl.XSDParticleImpl@12e146a7 (element: [xsd:element: null]) (minOccurs: <unset>, maxOccurs: <unset>)
feature = org.eclipse.emf.ecore.impl.EReferenceImpl@484ae502 (name: annotation) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (containment: true, resolveProxies: false)
value = org.eclipse.xsd.impl.XSDAnnotationImpl@2d010b62 (element: null) (applicationInformation: null, userInformation: null, attributes: null)
stacktrace:
Caused by: java.lang.NullPointerException
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSettingDelegate (BasicEObjectImpl.java:1571)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicIsSet(Ba sicEObjectImpl.java:1281)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1263)
at org.eclipse.xsd.impl.XSDConcreteComponentImpl.eIsSet(XSDConc reteComponentImpl.java:2008)
at org.eclipse.xsd.impl.XSDParticleImpl.eIsSet(XSDParticleImpl. java:479)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1247)
at com.metamatrix.modeler.internal.core.ModelEditorImpl.shouldB eDisabled(ModelEditorImpl.java:407)
at com.metamatrix.modeler.internal.core.ModelEditorImpl.createC ommands(ModelEditorImpl.java:3499)
Complex Type definition:
<xsd:element name="bibliography" type="BooksNS:Bibliography">
<xsd:annotation>
<xsd:documentation>Bibliography.</xsd:documentation>
</xsd:annotation>
</xsd:element>
|
|
|
| Re: NPE When Trying To Create A CreateChildCommand For XSD Element Of Complex Type [message #645165 is a reply to message #645163] |
Wed, 15 December 2010 18:39  |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
How can I reproduce this locally? It might be the case that
ModelEditorImpl.java: is passing in an inappropriate feature and that
changes to make setting delegates extensible uncovers and error. It's
impossible for me to comment definitively without being able to see the
problem in action. It seems clear that at 1247 there's a feature but by
1571 there isn't one anymore. Passing in a bad feature could cause that...
elvisisking wrote:
> We are now using EMF 2.6. The problem is with an XSD element of a
> complex type and trying to create a CreateChildCommand for an
> Annotation. I tested this with an older version of EMF (2.1) and it
> worked fine. I can provide XSDs if that would help (see snippet at
> end). See details below.
>
> Much thanks!
>
> ========
>
> Here are some details when NPE occurs:
>
> XSD Element: entry (in the Bibliography complex type - see Books.xsd
> attachment)
> eFeature: EReferenceImpl
> featureID: 28
> dynamicFeatureID: 19
> CommandParameter:
> owner = mailto:org.eclipse.xsd.impl.XSDParticleImpl@12e146a7
> (element: [xsd:element: null]) (minOccurs: <unset>, maxOccurs: <unset>)
> feature = mailto:org.eclipse.emf.ecore.impl.EReferenceImpl@484ae502
> (name: annotation) (ordered: true, unique: true, lowerBound: 0,
> upperBound: 1) (changeable: true, volatile: false, transient: false,
> defaultValueLiteral: null, unsettable: false, derived: false)
> (containment: true, resolveProxies: false)
> value = mailto:org.eclipse.xsd.impl.XSDAnnotationImpl@2d010b62
> (element: null) (applicationInformation: null, userInformation: null,
> attributes: null)
>
> stacktrace:
>
> Caused by: java.lang.NullPointerException
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSettingDelegate
> (BasicEObjectImpl.java:1571)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicIsSet(Ba
> sicEObjectImpl.java:1281)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj
> ectImpl.java:1263)
> at
> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eIsSet(XSDConc
> reteComponentImpl.java:2008)
> at
> org.eclipse.xsd.impl.XSDParticleImpl.eIsSet(XSDParticleImpl. java:479)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj
> ectImpl.java:1247)
> at
> com.metamatrix.modeler.internal.core.ModelEditorImpl.shouldB
> eDisabled(ModelEditorImpl.java:407)
> at
> com.metamatrix.modeler.internal.core.ModelEditorImpl.createC
> ommands(ModelEditorImpl.java:3499)
>
> Complex Type definition:
>
> <xsd:element name="bibliography" type="BooksNS:Bibliography">
> <xsd:annotation>
> <xsd:documentation>Bibliography.</xsd:documentation>
> </xsd:annotation>
> </xsd:element>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | |
| Re: NPE When Trying To Create A CreateChildCommand For XSD Element Of Complex Type [message #645215 is a reply to message #645182] |
Thu, 16 December 2010 00:10 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050802020206070601070704
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
I'll bet what's happening is that your making an assumption in
com.metamatrix.modeler.internal.core.ModelEditorImpl.shouldB eDisabled(ModelEditorImpl.java:407)
Note that XSDParticleItemProviderAdapter does this:
/**
* * This returns a list of child descriptors based on the particle
content,
* not the particle itself.*
*/
@Override
public Collection<?> getNewChildDescriptors(Object object,
EditingDomain domain, Object sibling)
{
Object content = ((XSDParticle) object).getContent();
return domain.getNewChildDescriptors(content, sibling);
}
So the child creation descriptors will have features that are features
of the particle's content, not of the particle itself...
Why doesn't that break? Because we've specialized the support for
CreateChildCommand like this:
public Command createCommand(final Object object, final
EditingDomain domain, Class<? extends Command> commandClass,
CommandParameter commandParameter)
{
if (commandClass == RemoveCommand.class ||
commandClass == CreateChildCommand.class)
{
* Object owner = ((XSDParticle) object).getContent();
if (owner == null)
{
return UnexecutableCommand.INSTANCE;
}
commandParameter.setOwner(owner);*
So the code in ModelEditorImpl.shouldBeDisabled shouldn't be making
assumptions that descriptor's features will be directly features of
XSDParticle but rather will be feature's of the particle's content...
elvisisking wrote:
> Thanks for the quick reply Ed. I'm a bit over-my-head so I appreciate
> your patience.
>
> We are getting the features from the commands we are using to create
> the New->Child menu for the selected EObject (an XSD element of a
> complex type).
>
> We are getting the commands this way:
>
> EditingDomain domain = container.getEditingDomain();
> Collection result = domain.getNewChildDescriptors(eObject, null);
>
> The "container" is a ResourceSet that implements IEditingDomainProvider.
>
> The "result" is a collection of CommandParameter's each of which have
> a feature. One of these features is "annotation" which is when the NPE
> occurs.
>
> I posted the wrong XSD snippet before. Below you'll find the correct
> complex types definitions. Again the selected EObject at the time of
> the NPE is "Bibliography.entry".
>
> Thanks!
>
> <xsd:complexType name="Bibliography">
> <xsd:annotation>
> <xsd:documentation>Bibliography.</xsd:documentation>
> </xsd:annotation>
> <xsd:sequence minOccurs="0" maxOccurs="unbounded">
> <xsd:element name="entry" type="BooksNS:BilbiographyEntry"/>
> </xsd:sequence>
> </xsd:complexType>
>
> <xsd:complexType name="BilbiographyEntry">
> <xsd:annotation>
> <xsd:documentation>
> Bibliography entry, consisting of a single author, full title,
> publisher, publisher location, and publication year.
> </xsd:documentation>
> </xsd:annotation>
> <xsd:sequence>
> <!-- <xsd:element name="authorList"
> type="BooksNS:CommaSeparatedList"/> --> <!-- List of authors -->
> <xsd:element name="author" type="xsd:string"/> <!-- Only
> one author -->
> <xsd:element name="fullTitle"
> type="BookTypesNS:CommaSeparatedList"/> <!-- Includes title, sub,
> edition -->
> <xsd:element name="publisher" type="xsd:string"/>
> <xsd:element name="publisherLoc" type="xsd:string"/>
> <xsd:element name="published"
> type="BookTypesNS:PublicationYear"/>
> </xsd:sequence>
> </xsd:complexType>
>
--------------050802020206070601070704
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I'll bet what's happening is that your making an assumption in <br>
<blockquote> com.metamatrix.modeler.internal.core.ModelEditorImpl.shouldB eDisabled(ModelEditorImpl.java:407)
<br>
</blockquote>
Note that XSDParticleItemProviderAdapter does this:<br>
<blockquote><small> /**</small><br>
<b><small> * This returns a list of child descriptors based on the
particle content,</small><br>
<small> * not the particle itself.</small></b><br>
<small> */</small><br>
<small> @Override</small><br>
<small> public Collection<?> getNewChildDescriptors(Object
object, EditingDomain domain, Object sibling)</small><br>
<small> {</small><br>
<small> Object content = ((XSDParticle) object).getContent();</small><br>
<small> return domain.getNewChildDescriptors(content, sibling);</small><br>
<small> }</small><br>
</blockquote>
So the child creation descriptors will have features that are features
of the particle's content, not of the particle itself...<br>
<br>
Why doesn't that break? Because we've specialized the support for
CreateChildCommand like this:<small><br>
</small>
<blockquote><small> public Command createCommand(final Object object,
final EditingDomain domain, Class<? extends Command>
commandClass, CommandParameter commandParameter)</small><br>
<small> {</small><br>
<small> if (commandClass == RemoveCommand.class ||</small><br>
<small> commandClass == CreateChildCommand.class)</small><br>
<small> {</small><br>
<b><small> Object owner = ((XSDParticle) object).getContent();</small><br>
<small> if (owner == null)</small><br>
<small> {</small><br>
<small> return UnexecutableCommand.INSTANCE;</small><br>
<small> }</small><br>
<br>
<small> commandParameter.setOwner(owner);</small></b><br>
</blockquote>
So the code in ModelEditorImpl.shouldBeDisabled shouldn't be making
assumptions that descriptor's features will be directly features of
XSDParticle but rather will be feature's of the particle's content...<br>
<br>
<br>
elvisisking wrote:
<blockquote cite="mid:ieb5k9$k8r$1@news.eclipse.org" type="cite">Thanks
for the quick reply Ed. I'm a bit over-my-head so I appreciate your
patience.
<br>
<br>
We are getting the features from the commands we are using to create
the New->Child menu for the selected EObject (an XSD element of a
complex type).
<br>
<br>
We are getting the commands this way:
<br>
<br>
EditingDomain domain = container.getEditingDomain();
<br>
Collection result = domain.getNewChildDescriptors(eObject, null);
<br>
<br>
The "container" is a ResourceSet that implements
IEditingDomainProvider.
<br>
<br>
The "result" is a collection of CommandParameter's each of which have a
feature. One of these features is "annotation" which is when the NPE
occurs.
<br>
<br>
I posted the wrong XSD snippet before. Below you'll find the correct
complex types definitions. Again the selected EObject at the time of
the NPE is "Bibliography.entry".
<br>
<br>
Thanks!
<br>
<br>
<xsd:complexType name="Bibliography">
<br>
<xsd:annotation>
<br>
<xsd:documentation>Bibliography.</xsd:d ocumentation>
<br>
</xsd:annotation>
<br>
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<br>
<xsd:element name="entry" type="BooksNS:BilbiographyEntry"/>
<br>
</xsd:sequence>
<br>
</xsd:complexType>
<br>
<br>
<xsd:complexType name="BilbiographyEntry">
<br>
<xsd:annotation>
<br>
<xsd:documentation>
<br>
Bibliography entry, consisting of a single author, full title,
publisher, publisher location, and publication year.
<br>
</xsd:documentation>
<br>
</xsd:annotation>
<br>
<xsd:sequence>
<br>
<!-- <xsd:element name="authorList"
type="BooksNS:CommaSeparatedList"/> --> <!-- List of authors
-->
<br>
<xsd:element name="author" type="xsd:string"/>
<!-- Only one author -->
<br>
<xsd:element name="fullTitle"
type="BookTypesNS:CommaSeparatedList"/> <!-- Includes title,
sub, edition -->
<br>
<xsd:element name="publisher" type="xsd:string"/>
<br>
<xsd:element name="publisherLoc" type="xsd:string"/>
<br>
<xsd:element name="published"
type="BookTypesNS:PublicationYear"/>
<br>
</xsd:sequence>
<br>
</xsd:complexType>
<br>
<br>
</blockquote>
</body>
</html>
--------------050802020206070601070704--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Goto Forum:
Current Time: Thu Apr 25 15:13:21 GMT 2024
Powered by FUDForum. Page generated in 0.04141 seconds |
] 
Search
Help
Register
Login
Home
