Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Storing GMF diagram object with teneo
Storing GMF diagram object with teneo [message #113077] Sun, 24 February 2008 12:27 Go to next message
Manfred Hahn is currently offline Manfred HahnFriend
Messages: 64
Registered: July 2009
Member
Hi everybody

I am writing a GMF application and try for the first time to store the GMF
diagram model information into a Hibernate database using teneo. The
diagram itself is empty, but I have to create a diagram object when I want
to open a new diagram editor.

I got a null pointer exception when I am saving this resource.
The exception is thrown in the EListPropertyHandler.set() method, because
the javaField, determined with FieldUtil.getField(), is null.

Debugging the problem I found out, that the field name for the
getField-method is the name of a feature of the diagram-object: "children"
(in fact it is a feature of the base class "View").

The getField() method tries to get a java class field in the class
"Diagram" or the base classes, but there is no field with that name. The
fields that are found have names like "persistedChildren" or
"transientChildren" or "allChildren".

So the features of the Diagram class and the fields of the Diagram class
are different. The field to save will never be found using this strategie.

Has anyone a hint how I can solve this problem?

Thank you,
Manfred

Report message to a moderator

Re: Storing GMF diagram object with teneo [message #113104 is a reply to message #113077] Mon, 25 February 2008 06:49 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Manfred,
I think you have encountered the same issue with gmf as I have a long while back:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=159226#c12

Probably I will be looking into the gmf integration the coming weeks (before eclipsecon). So then I
will look again at this topic. Until that time I don't know if it is solvable.

gr. Martin

Manfred Hahn wrote:
> Hi everybody
>
> I am writing a GMF application and try for the first time to store the
> GMF diagram model information into a Hibernate database using teneo. The
> diagram itself is empty, but I have to create a diagram object when I
> want to open a new diagram editor.
>
> I got a null pointer exception when I am saving this resource. The
> exception is thrown in the EListPropertyHandler.set() method, because
> the javaField, determined with FieldUtil.getField(), is null.
>
> Debugging the problem I found out, that the field name for the
> getField-method is the name of a feature of the diagram-object:
> "children" (in fact it is a feature of the base class "View").
>
> The getField() method tries to get a java class field in the class
> "Diagram" or the base classes, but there is no field with that name. The
> fields that are found have names like "persistedChildren" or
> "transientChildren" or "allChildren".
> So the features of the Diagram class and the fields of the Diagram class
> are different. The field to save will never be found using this strategie.
>
> Has anyone a hint how I can solve this problem?
>
> Thank you,
> Manfred


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: Storing GMF diagram object with teneo [message #113129 is a reply to message #113104] Mon, 25 February 2008 08:09 Go to previous messageGo to next message
Manfred Hahn is currently offline Manfred HahnFriend
Messages: 64
Registered: July 2009
Member
Hi Martin,

thank you for your quick answer.

Since it's been a long time ago you wrote about the same problem and the
gmf team did not change anything I will look for another solution, i.e.
changing the FieldUtil.getField() method for this particular case, hoping
this is the only unregular case.

I'd like to put everthing into the database in my RCP program so I don't
have to deal with files anymore.

If I have found a workaround I will let you know.

Manfred

Report message to a moderator

Re: Storing GMF diagram object with teneo [message #114073 is a reply to message #113104] Fri, 07 March 2008 15:45 Go to previous message
Manfred Hahn is currently offline Manfred HahnFriend
Messages: 64
Registered: July 2009
Member
Hi Martin,

if you are investigating in gmf resolution here is my workaround for
STORING the diagram:

In order to use my specialized getField() method I did the following

- I subclassed the EListPropertyHandler and copied the get() and set()
methods from the original, then I changed the call to getField() to use my
own new Utility Class for it

- I wrote this Utility Class with a new specialized getField()-Method,
where I first call FieldUtil.getField().If this method returns with null I
check for two special situations:
- if the class is assignable from View and the field name is "children"
I return the field View.persistedChildren()
- if the class is assignable from Diagram and the field name is "edges"
I return the field Diagram.persistedEdges()
- I registered my own EListPropertyHandler as an extension to the
HbDataStore
- Because of the editing problems I have with a loaded diagram I made a
centralized editing domain and do no new load when I create a new diagram
(the original generated code did!). But this of course will not be
necessary when the editing problem is solved.

Since the automaticly generated mapping of the GMF diagram model has some
problems with multi inheritance I had to make two small changes to the
hibernate mapping: Both the entities DiagramStyle and ShapeStyle should be
changed to extended="Style" instead of extended="Ecore_eobject". After
that the diagram could be stored without errors.

These changes were fairly easy to do, but they are a little bit dirty,
too. But the root of the getField()-Problem is that the name of the
feature does not necesserily have to be the name of the field, so to
handle these unusual situations I'd like to have a clear point where I can
plug in my specialized handling.

I expect to run into some more problems.
With the first reload of the diagram I saw that positions and sizes of
diagram elements had changed. After a new save this problem seems to
vanish.

I also noticed the reload problem after unloading the resource that was
the reason for your question in in the emf newsgroup.

Best regards
Manfred

Report message to a moderator

Re: Storing GMF diagram object with teneo [message #615550 is a reply to message #113077] Mon, 25 February 2008 06:49 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Manfred,
I think you have encountered the same issue with gmf as I have a long while back:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=159226#c12

Probably I will be looking into the gmf integration the coming weeks (before eclipsecon). So then I
will look again at this topic. Until that time I don't know if it is solvable.

gr. Martin

Manfred Hahn wrote:
> Hi everybody
>
> I am writing a GMF application and try for the first time to store the
> GMF diagram model information into a Hibernate database using teneo. The
> diagram itself is empty, but I have to create a diagram object when I
> want to open a new diagram editor.
>
> I got a null pointer exception when I am saving this resource. The
> exception is thrown in the EListPropertyHandler.set() method, because
> the javaField, determined with FieldUtil.getField(), is null.
>
> Debugging the problem I found out, that the field name for the
> getField-method is the name of a feature of the diagram-object:
> "children" (in fact it is a feature of the base class "View").
>
> The getField() method tries to get a java class field in the class
> "Diagram" or the base classes, but there is no field with that name. The
> fields that are found have names like "persistedChildren" or
> "transientChildren" or "allChildren".
> So the features of the Diagram class and the fields of the Diagram class
> are different. The field to save will never be found using this strategie.
>
> Has anyone a hint how I can solve this problem?
>
> Thank you,
> Manfred


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: Storing GMF diagram object with teneo [message #615552 is a reply to message #113104] Mon, 25 February 2008 08:09 Go to previous message
Manfred Hahn is currently offline Manfred HahnFriend
Messages: 64
Registered: July 2009
Member
Hi Martin,

thank you for your quick answer.

Since it's been a long time ago you wrote about the same problem and the
gmf team did not change anything I will look for another solution, i.e.
changing the FieldUtil.getField() method for this particular case, hoping
this is the only unregular case.

I'd like to put everthing into the database in my RCP program so I don't
have to deal with files anymore.

If I have found a workaround I will let you know.

Manfred

Report message to a moderator

Re: Storing GMF diagram object with teneo [message #615624 is a reply to message #113104] Fri, 07 March 2008 15:45 Go to previous message
Manfred Hahn is currently offline Manfred HahnFriend
Messages: 64
Registered: July 2009
Member
Hi Martin,

if you are investigating in gmf resolution here is my workaround for
STORING the diagram:

In order to use my specialized getField() method I did the following

- I subclassed the EListPropertyHandler and copied the get() and set()
methods from the original, then I changed the call to getField() to use my
own new Utility Class for it

- I wrote this Utility Class with a new specialized getField()-Method,
where I first call FieldUtil.getField().If this method returns with null I
check for two special situations:
- if the class is assignable from View and the field name is "children"
I return the field View.persistedChildren()
- if the class is assignable from Diagram and the field name is "edges"
I return the field Diagram.persistedEdges()
- I registered my own EListPropertyHandler as an extension to the
HbDataStore
- Because of the editing problems I have with a loaded diagram I made a
centralized editing domain and do no new load when I create a new diagram
(the original generated code did!). But this of course will not be
necessary when the editing problem is solved.

Since the automaticly generated mapping of the GMF diagram model has some
problems with multi inheritance I had to make two small changes to the
hibernate mapping: Both the entities DiagramStyle and ShapeStyle should be
changed to extended="Style" instead of extended="Ecore_eobject". After
that the diagram could be stored without errors.

These changes were fairly easy to do, but they are a little bit dirty,
too. But the root of the getField()-Problem is that the name of the
feature does not necesserily have to be the name of the field, so to
handle these unusual situations I'd like to have a clear point where I can
plug in my specialized handling.

I expect to run into some more problems.
With the first reload of the diagram I saw that positions and sizes of
diagram elements had changed. After a new save this problem seems to
vanish.

I also noticed the reload problem after unloading the resource that was
the reason for your question in in the emf newsgroup.

Best regards
Manfred

Report message to a moderator

Previous Topic:Error: XSD: Type reference '#null' is unresolved in XML Schema Import into EMF
Next Topic:Error: XSD: Type reference '#null' is unresolved in XML Schema Import into EMF
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Wed Apr 24 23:51:05 GMT 2024

Powered by FUDForum. Page generated in 0.03518 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly