351921 – [DB] NPE in GMF notation caused by CoreTypeMappings$TMCustom.getDefaultValue

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 351921 - [DB] NPE in GMF notation caused by CoreTypeMappings$TMCustom.getDefaultValue

Summary: [DB] NPE in GMF notation caused by CoreTypeMappings$TMCustom.getDefaultValue

Status:	CLOSED FIXED

Alias:	None

Product:	EMF
Classification:	Modeling
Component:	cdo.db (show other bugs)
Version:	4.1
Hardware:	PC Windows 7

Importance:	P3 normal (vote)
Target Milestone:	---
Assignee:	Stefan Winkler
QA Contact:	Eike Stepper

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2011-07-13 04:02 EDT by Steve Monnier
Modified:	2012-09-21 07:18 EDT (History)
CC List:	2 users (show)

See Also:

Flags:	stepper: review+

Attachments
A small patch to fix this issue (788 bytes, patch) 2011-07-13 10:14 EDT, Steve Monnier	no flags	Details \| Diff
Patch-v2 (5.08 KB, patch) 2011-07-16 06:40 EDT, Stefan Winkler	no flags	Details \| Diff
Patch-v3 (5.08 KB, patch) 2011-07-18 10:32 EDT, Stefan Winkler	no flags	Details \| Diff
Patch v4 (5.11 KB, patch) 2011-07-21 23:22 EDT, Eike Stepper	no flags	Details \| Diff
Patch-v5 (5.14 KB, patch) 2011-07-22 11:03 EDT, Stefan Winkler	no flags	Details \| Diff
Show Obsolete (4) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Steve Monnier

2011-07-13 04:02:42 EDT

Build Identifier: 

Hello,

I have a GMF diagram stored in my repository that causes the following stack trace (on commit after modification on a connection):

org.eclipse.emf.cdo.util.CommitException: Rollback in DBStore: java.lang.NullPointerException
at org.eclipse.gmf.runtime.notation.impl.NotationFactoryImpl.convertRelativeBendpointListToString(NotationFactoryImpl.java:1221)
at org.eclipse.gmf.runtime.notation.impl.NotationFactoryImpl.convertToString(NotationFactoryImpl.java:288)
at org.eclipse.emf.cdo.server.internal.db.mapping.CoreTypeMappings$TMCustom.getDefaultValue(CoreTypeMappings.java:847)
at org.eclipse.emf.cdo.server.db.mapping.AbstractTypeMapping.setDefaultValue(AbstractTypeMapping.java:99)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchingClassMapping.detachAttributes(HorizontalBranchingClassMapping.java:691)
...

It appears that in CoreTypeMappings$TMCustom.getDefaultValue() the expression getFeature().getDefaultValue(); returns a null value. Is it possible to test if it is null? It seems to be tested in CoreTypeMappings$TMEnum.getDefaultValue().

Note that this exception happens on the server side, not on a client.

Thanks,
Steve

Reproducible: Always

Comment 1 Eike Stepper

2011-07-13 04:25:57 EDT

Stefan will eventually look into it. You should be able to work around it in the meantime by not deploying GMF to the server.

Comment 2 Steve Monnier

2011-07-13 10:14:47 EDT

Created attachment 199586 [details]
A small patch to fix this issue

Comment 3 Stefan Winkler

2011-07-16 06:37:22 EDT

Thanks for your patch, Steve. 

Yet, it's not entirely correct. Your patch will store the empty string in the database ("") if the default value of a feature is null.
This eliminates the storing problem and works in all cases in which createFromString() -- which is called during reading from the DB -- can handle the empty string.
But there might be custom data types which cannot serialize to the empty string (or worse: in which the empty string has a different meaning than null!)

Therefor, I've created a test case and slightly modified your patch: If the default value is null, we write a null value to the database. This passes my testcase.
Would you be so kind and test this patch for your situation and give feedback?

Comment 4 Stefan Winkler

2011-07-16 06:40:41 EDT

Created attachment 199782 [details]
Patch-v2

Modified Patch and Testcase.

Comment 5 Steve Monnier

2011-07-18 04:51:54 EDT

Hi,

I tested your patch, Stefan. It works fine for my situation.
Is it possible to have this fix on the 4.0 branch as well?

Thanks

Comment 6 Stefan Winkler

2011-07-18 10:21:27 EDT

I see no problem in backporting it to 4.0, after it has gone into 4.1.

I think we need a separate Bugzilla for this, if I am not mistaken.

Comment 7 Stefan Winkler

2011-07-18 10:32:19 EDT

Created attachment 199838 [details]
Patch-v3

synchronized with TRUNK

Comment 8 Eike Stepper

2011-07-21 23:22:46 EDT

Created attachment 200139 [details]
Patch v4

Comment 9 Stefan Winkler

2011-07-22 11:02:59 EDT

Committed revision 8808:
- trunk/plugins/org.eclipse.emf.cdo.server.db
- trunk/plugins/org.eclipse.emf.cdo.tests

Comment 10 Stefan Winkler

2011-07-22 11:03:41 EDT

Created attachment 200205 [details]
Patch-v5

synced with Trunk.
Ready to be committed.

Comment 11 Stefan Winkler

2011-07-22 11:04:37 EDT

Note: Commit of comment#9 was done using patch-v5

Comment 12 Alex Lagarde

2011-07-27 04:43:36 EDT

Is this possible to apply this fix on the 4.0.X maintenance version ?

It would be great, thanks !

Comment 13 Eike Stepper

2012-09-21 07:18:54 EDT

Closing.