Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Storing POJOs in an EMF Resource
Storing POJOs in an EMF Resource [message #1064560] Wed, 19 June 2013 21:34 Go to next message
Eric Rizzo is currently offline Eric Rizzo
Messages: 2245
Registered: July 2009
Senior Member
Is there a straightforward technique for storing POJOs (object that don't extend EObject) in a Resource? I tried googling but didn't find anything useful using various combinations of search terms.
The only idea I can think of is doing a simple EMF model that wraps any Object, and persist that. But that seems a bit crude to me. Is there any better way?
Re: Storing POJOs in an EMF Resource [message #1064581 is a reply to message #1064560] Thu, 20 June 2013 06:04 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26050
Registered: July 2009
Senior Member
Eric,

You'd need to do it as an EDataType, so you could do something like
what's done for EJavaObject which just wraps java.lang.Object or do
something more specific for with more knowledge of the type in
question. In either case, you need to write all the logic to do the
<value> <-> String conversion.


On 19/06/2013 11:34 PM, Eric Rizzo wrote:
> Is there a straightforward technique for storing POJOs (object that
> don't extend EObject) in a Resource? I tried googling but didn't find
> anything useful using various combinations of search terms.
> The only idea I can think of is doing a simple EMF model that wraps
> any Object, and persist that. But that seems a bit crude to me. Is
> there any better way?
Re: Storing POJOs in an EMF Resource [message #1064687 is a reply to message #1064581] Thu, 20 June 2013 14:20 Go to previous messageGo to next message
Eric Rizzo is currently offline Eric Rizzo
Messages: 2245
Registered: July 2009
Senior Member
Ed Merks wrote on Thu, 20 June 2013 02:04
Eric,

You'd need to do it as an EDataType, so you could do something like
what's done for EJavaObject which just wraps java.lang.Object or do
something more specific for with more knowledge of the type in
question. In either case, you need to write all the logic to do the
<value> <-> String conversion.


Ed,
I've never had to define an EDataType, so I'm trying to wrap my head around what you're saying. Doing a little research, it seems that EJavaObject doesn't exist; web searches find only passing references to it and Eclipse doesn't know anything about it (EMF SDK is part of my target platform). Can you provide any direct pointers?

I should also mention that I'm trying to find a way to do this generically, in a framework that encapsulates EMF persistence. Right now, I allow clients to define their own EMF model types (that extend an interface I have defined) and I persist those when I encounter them. I have a need to eliminate the requirement that these objects be EMF-based; I need to be able to persist any arbitrary POJO that I encounter as long as it implements the interface. I'd love to see some examples of defining an EDataType dynamically, icing on the cake would be something that is equally generic to what I need, but a concrete example can probably get me far enough to make the leap to generic/dynamic.

For example, if I encounter an instance of the following class, how do I go about serializing it (and subsequently deserializing)?

public class SomeData implements GenericInterface {
    private boolean someBoolean;
    private String someString;

    public boolean getSomeBoolean() { return someBoolean; }
    public String getSomeString() { return someString; }

    // assume setters, etc.
}


Thanks in advance for any pointers,
Eric


Quote:
On 19/06/2013 11:34 PM, Eric Rizzo wrote:
> Is there a straightforward technique for storing POJOs (object that
> don't extend EObject) in a Resource? I tried googling but didn't find
> anything useful using various combinations of search terms.
> The only idea I can think of is doing a simple EMF model that wraps
> any Object, and persist that. But that seems a bit crude to me. Is
> there any better way?
Re: Storing POJOs in an EMF Resource [message #1064723 is a reply to message #1064687] Thu, 20 June 2013 16:27 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26050
Registered: July 2009
Senior Member
Eric,

Comments below.

On 20/06/2013 4:20 PM, Eric Rizzo wrote:
> Ed Merks wrote on Thu, 20 June 2013 02:04
>> Eric,
>>
>> You'd need to do it as an EDataType, so you could do something like
>> what's done for EJavaObject which just wraps java.lang.Object or do
>> something more specific for with more knowledge of the type in
>> question. In either case, you need to write all the logic to do the
>> <value> <-> String conversion.
>
>
> Ed,
> I've never had to define an EDataType, so I'm trying to wrap my head
> around what you're saying. Doing a little research, it seems that
> EJavaObject doesn't exist; web searches find only passing references
> to it and Eclipse doesn't know anything about it (EMF SDK is part of
> my target platform). Can you provide any direct pointers?
It's an EDataType in Ecore.ecore. The important methods to implement
for an EDataType are the ones in XyzFactoryImpl. You'll get the idea
looking at methods like
org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEJavaObjectFromString(EDataType,
String).
>
> I should also mention that I'm trying to find a way to do this
> generically, in a framework that encapsulates EMF persistence. Right
> now, I allow clients to define their own EMF model types (that extend
> an interface I have defined) and I persist those when I encounter
> them. I have a need to eliminate the requirement that these objects be
> EMF-based; I need to be able to persist any arbitrary POJO that I
> encounter as long as it implements the interface. I'd love to see some
> examples of defining an EDataType dynamically, icing on the cake would
> be something that is equally generic to what I need, but a concrete
> example can probably get me far enough to make the leap to
> generic/dynamic.
The best I can do is point you at something like EcoreFactoryImpl.
>
> For example, if I encounter an instance of the following class, how do
> I go about serializing it (and subsequently deserializing)?
>
> public class SomeData implements GenericInterface {
> private boolean someBoolean;
> private String someString;
>
> public boolean getSomeBoolean() { return someBoolean; }
> public String getSomeString() { return someString; }
>
> // assume setters, etc.
> }
There's nothing in such an interface to help you create a new instance
of the same kind given an existing instance (knowing nothing of what
GenericInterface might help provide).
>
> Thanks in advance for any pointers,
> Eric
>
>
> Quote:
>> On 19/06/2013 11:34 PM, Eric Rizzo wrote:
>> > Is there a straightforward technique for storing POJOs (object that
>> > don't extend EObject) in a Resource? I tried googling but didn't
>> find > anything useful using various combinations of search terms.
>> > The only idea I can think of is doing a simple EMF model that wraps
>> > any Object, and persist that. But that seems a bit crude to me. Is
>> > there any better way?
>
Re: Storing POJOs in an EMF Resource [message #1065727 is a reply to message #1064723] Thu, 27 June 2013 09:37 Go to previous messageGo to next message
Simon Goodall is currently offline Simon Goodall
Messages: 11
Registered: July 2009
Junior Member
Hi,

I've seen something like this for objects implementing Serializable. You
can create an EMF DataType for Serializable, then in your XyzFactoryImpl
convert to string method you can serialize the object and Base64 encode
it. You can perform the reverse to get it back again.

It's not necessarily the most efficient way of storing the object, but
requires little extra work to persist things. Of course you need to be
careful about changing those classes to avoid breaking the deserialization.

Regards,

Simon

On 20/06/2013 17:27, Ed Merks wrote:
> Eric,
>
> Comments below.
>
> On 20/06/2013 4:20 PM, Eric Rizzo wrote:
>> Ed Merks wrote on Thu, 20 June 2013 02:04
>>> Eric,
>>>
>>> You'd need to do it as an EDataType, so you could do something like
>>> what's done for EJavaObject which just wraps java.lang.Object or do
>>> something more specific for with more knowledge of the type in
>>> question. In either case, you need to write all the logic to do the
>>> <value> <-> String conversion.
>>
>>
>> Ed,
>> I've never had to define an EDataType, so I'm trying to wrap my head
>> around what you're saying. Doing a little research, it seems that
>> EJavaObject doesn't exist; web searches find only passing references
>> to it and Eclipse doesn't know anything about it (EMF SDK is part of
>> my target platform). Can you provide any direct pointers?
> It's an EDataType in Ecore.ecore. The important methods to implement
> for an EDataType are the ones in XyzFactoryImpl. You'll get the idea
> looking at methods like
> org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEJavaObjectFromString(EDataType,
> String).
>>
>> I should also mention that I'm trying to find a way to do this
>> generically, in a framework that encapsulates EMF persistence. Right
>> now, I allow clients to define their own EMF model types (that extend
>> an interface I have defined) and I persist those when I encounter
>> them. I have a need to eliminate the requirement that these objects be
>> EMF-based; I need to be able to persist any arbitrary POJO that I
>> encounter as long as it implements the interface. I'd love to see some
>> examples of defining an EDataType dynamically, icing on the cake would
>> be something that is equally generic to what I need, but a concrete
>> example can probably get me far enough to make the leap to
>> generic/dynamic.
> The best I can do is point you at something like EcoreFactoryImpl.
>>
>> For example, if I encounter an instance of the following class, how do
>> I go about serializing it (and subsequently deserializing)?
>>
>> public class SomeData implements GenericInterface {
>> private boolean someBoolean;
>> private String someString;
>>
>> public boolean getSomeBoolean() { return someBoolean; }
>> public String getSomeString() { return someString; }
>>
>> // assume setters, etc.
>> }
> There's nothing in such an interface to help you create a new instance
> of the same kind given an existing instance (knowing nothing of what
> GenericInterface might help provide).
>>
>> Thanks in advance for any pointers,
>> Eric
>>
>>
>> Quote:
>>> On 19/06/2013 11:34 PM, Eric Rizzo wrote:
>>> > Is there a straightforward technique for storing POJOs (object that
>>> > don't extend EObject) in a Resource? I tried googling but didn't
>>> find > anything useful using various combinations of search terms.
>>> > The only idea I can think of is doing a simple EMF model that wraps
>>> > any Object, and persist that. But that seems a bit crude to me. Is
>>> > there any better way?
>>
>
Re: Storing POJOs in an EMF Resource [message #1065730 is a reply to message #1065727] Thu, 27 June 2013 09:42 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26050
Registered: July 2009
Senior Member
Simon,

Yes, that's what EJavaObject does.

On 27/06/2013 11:37 AM, Simon Goodall wrote:
> Hi,
>
> I've seen something like this for objects implementing Serializable.
> You can create an EMF DataType for Serializable, then in your
> XyzFactoryImpl convert to string method you can serialize the object
> and Base64 encode it. You can perform the reverse to get it back again.
>
> It's not necessarily the most efficient way of storing the object, but
> requires little extra work to persist things. Of course you need to be
> careful about changing those classes to avoid breaking the
> deserialization.
>
> Regards,
>
> Simon
>
> On 20/06/2013 17:27, Ed Merks wrote:
>> Eric,
>>
>> Comments below.
>>
>> On 20/06/2013 4:20 PM, Eric Rizzo wrote:
>>> Ed Merks wrote on Thu, 20 June 2013 02:04
>>>> Eric,
>>>>
>>>> You'd need to do it as an EDataType, so you could do something like
>>>> what's done for EJavaObject which just wraps java.lang.Object or do
>>>> something more specific for with more knowledge of the type in
>>>> question. In either case, you need to write all the logic to do the
>>>> <value> <-> String conversion.
>>>
>>>
>>> Ed,
>>> I've never had to define an EDataType, so I'm trying to wrap my head
>>> around what you're saying. Doing a little research, it seems that
>>> EJavaObject doesn't exist; web searches find only passing references
>>> to it and Eclipse doesn't know anything about it (EMF SDK is part of
>>> my target platform). Can you provide any direct pointers?
>> It's an EDataType in Ecore.ecore. The important methods to implement
>> for an EDataType are the ones in XyzFactoryImpl. You'll get the idea
>> looking at methods like
>> org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEJavaObjectFromString(EDataType,
>>
>> String).
>>>
>>> I should also mention that I'm trying to find a way to do this
>>> generically, in a framework that encapsulates EMF persistence. Right
>>> now, I allow clients to define their own EMF model types (that extend
>>> an interface I have defined) and I persist those when I encounter
>>> them. I have a need to eliminate the requirement that these objects be
>>> EMF-based; I need to be able to persist any arbitrary POJO that I
>>> encounter as long as it implements the interface. I'd love to see some
>>> examples of defining an EDataType dynamically, icing on the cake would
>>> be something that is equally generic to what I need, but a concrete
>>> example can probably get me far enough to make the leap to
>>> generic/dynamic.
>> The best I can do is point you at something like EcoreFactoryImpl.
>>>
>>> For example, if I encounter an instance of the following class, how do
>>> I go about serializing it (and subsequently deserializing)?
>>>
>>> public class SomeData implements GenericInterface {
>>> private boolean someBoolean;
>>> private String someString;
>>>
>>> public boolean getSomeBoolean() { return someBoolean; }
>>> public String getSomeString() { return someString; }
>>>
>>> // assume setters, etc.
>>> }
>> There's nothing in such an interface to help you create a new instance
>> of the same kind given an existing instance (knowing nothing of what
>> GenericInterface might help provide).
>>>
>>> Thanks in advance for any pointers,
>>> Eric
>>>
>>>
>>> Quote:
>>>> On 19/06/2013 11:34 PM, Eric Rizzo wrote:
>>>> > Is there a straightforward technique for storing POJOs (object that
>>>> > don't extend EObject) in a Resource? I tried googling but didn't
>>>> find > anything useful using various combinations of search terms.
>>>> > The only idea I can think of is doing a simple EMF model that wraps
>>>> > any Object, and persist that. But that seems a bit crude to me. Is
>>>> > there any better way?
>>>
>>
>
Previous Topic:Use emf.edit.ui in pure E4 app
Next Topic:[EMF] Resolving references in programmatic loading of meta-models
Goto Forum:
  


Current Time: Thu Sep 18 10:04:20 GMT 2014

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

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