Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of
Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #69749] Tue, 26 September 2006 04:56 Go to next message
Martin Taal is currently offline Martin Taal
Messages: 5326
Registered: July 2009
Senior Member
Hi,
I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE to create eenums (and maybe also
other model elements). Would it be possible to let it use
EcorePackage.eINSTANCE.getEFactoryInstance() instead?

The reason that I ask is that this makes it possible to override the default EcoreFactory with our
own implementation (by setting the EcoreFactory in the EcorePackage). We require our own
implementation to make use of our own serializable EEnumLiteral.

Btw, is overriding EcoreFactory a valid approach in this case?

--

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
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #69770 is a reply to message #69749] Tue, 26 September 2006 07:28 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Martin,

No, it must be the case that EcoreFactory.eINSTANCE ==
EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a reasonable
approach. You should use the factory_override extension point to
override the factory for a package (so that the actual
XyzFactory.eINSTANCE is overridden); a given package can have at most
one override in the JVM.

I'd like to understand why EEnumLiteralImpl must be serializeable,
because this implies to me that only serializeable data types can be
supported when that isn't a general restriction for EMF because it uses
the createFromString/convertToString for that. If this is absolutely
needed to support Teneo, I'd rather do it directly in EMF so that you
wouldn't need to override the factory; I know Apache's Tuscany project
is using an override of EcoreFactory.eINSTANCE to create DataObjects,
and it would be nice if Teneo still worked for that too.


Martin Taal wrote:
> Hi,
> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE to
> create eenums (and maybe also other model elements). Would it be
> possible to let it use EcorePackage.eINSTANCE.getEFactoryInstance()
> instead?
>
> The reason that I ask is that this makes it possible to override the
> default EcoreFactory with our own implementation (by setting the
> EcoreFactory in the EcorePackage). We require our own implementation
> to make use of our own serializable EEnumLiteral.
>
> Btw, is overriding EcoreFactory a valid approach in this case?
>
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #69790 is a reply to message #69770] Tue, 26 September 2006 08:38 Go to previous messageGo to next message
Martin Taal is currently offline Martin Taal
Messages: 5326
Registered: July 2009
Senior Member
Hi Ed,
I was expecting that there was more to it.

We are working on using EMF in combination with JSF (Java Server Faces) and also Spring Web Flow (so
not related to Teneo, although it uses it). These frameworks/technologies store state by
java-serializing the data-objects. Java serializability is also used by a number of other frameworks
(jboss seam and jboss work flow also as I understand).

There are different cases:
> Dynamic EMF
1) The DynamicEObjectImpl
I have my own serializable dynamic eobject impl which is java.io.serializable, currently I set my
own serializableeobjectfactory in the epackage to force the use of this serializable dynamiceobject
(but this is not a correct approach?).
2) the EEnumLiteral: when reading a model directly from a xsd, xsdecorebuilder will create
EEnumLiterals, in this step I want to replace the creation of a standard EEnumLiteral by my
serializable eenumliteral. I have now done this by overriding the xsdecorebuilder and changing two
statements. But I did not feel that this was a long term sound approach.

> Generated EMF (java code)
I can make the generated java code serializable by making minor changes to the jet templates. This
is workable. Although I would prefer to just use a serializable EObject.

As we use emf outside of an eclipse environment I don't think that extension-points work.

So overall the above would be much easier if for example the EObject interface would also extend
java.io.Serializable (why not?) and some other smaller changes related to using the correct
singleton enumerate instance.
But maybe/probably I overlook many things here.

gr. Martin

Ed Merks wrote:
> Martin,
>
> No, it must be the case that EcoreFactory.eINSTANCE ==
> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a reasonable
> approach. You should use the factory_override extension point to
> override the factory for a package (so that the actual
> XyzFactory.eINSTANCE is overridden); a given package can have at most
> one override in the JVM.
> I'd like to understand why EEnumLiteralImpl must be serializeable,
> because this implies to me that only serializeable data types can be
> supported when that isn't a general restriction for EMF because it uses
> the createFromString/convertToString for that. If this is absolutely
> needed to support Teneo, I'd rather do it directly in EMF so that you
> wouldn't need to override the factory; I know Apache's Tuscany project
> is using an override of EcoreFactory.eINSTANCE to create DataObjects,
> and it would be nice if Teneo still worked for that too.
>
>
> Martin Taal wrote:
>> Hi,
>> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE to
>> create eenums (and maybe also other model elements). Would it be
>> possible to let it use EcorePackage.eINSTANCE.getEFactoryInstance()
>> instead?
>>
>> The reason that I ask is that this makes it possible to override the
>> default EcoreFactory with our own implementation (by setting the
>> EcoreFactory in the EcorePackage). We require our own implementation
>> to make use of our own serializable EEnumLiteral.
>>
>> Btw, is overriding EcoreFactory a valid approach in this case?
>>


--

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
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #69813 is a reply to message #69790] Tue, 26 September 2006 08:52 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Martin,

Comments below.


Martin Taal wrote:
> Hi Ed,
> I was expecting that there was more to it.
>
> We are working on using EMF in combination with JSF (Java Server
> Faces) and also Spring Web Flow (so not related to Teneo, although it
> uses it). These frameworks/technologies store state by
> java-serializing the data-objects. Java serializability is also used
> by a number of other frameworks (jboss seam and jboss work flow also
> as I understand).
Yes, many frameworks rely on this. I could certainly imagine an
approach similar to what we did to support java.io.Serializeable when
implement SDO 1.0 on top of EMF. I.e., one could effectively serialize
the whole resource set. What isn't always clear is how much of the
"closure" needs to be serialized, so I'm not sure if such a brute force,
one size fits all solutions is a good thing...
>
> There are different cases:
> > Dynamic EMF
> 1) The DynamicEObjectImpl
> I have my own serializable dynamic eobject impl which is
> java.io.serializable, currently I set my own
> serializableeobjectfactory in the epackage to force the use of this
> serializable dynamiceobject (but this is not a correct approach?).
No, this is not generally a great idea. You should use the extension
point or use the same approach as is used to implement the extension point.
> 2) the EEnumLiteral: when reading a model directly from a xsd,
> xsdecorebuilder will create EEnumLiterals, in this step I want to
> replace the creation of a standard EEnumLiteral by my serializable
> eenumliteral. I have now done this by overriding the xsdecorebuilder
> and changing two statements. But I did not feel that this was a long
> term sound approach.
Why is EEnumLiteral so special? Is it because all the other data types
are serializeable?
>
> > Generated EMF (java code)
> I can make the generated java code serializable by making minor
> changes to the jet templates. This is workable. Although I would
> prefer to just use a serializable EObject.
>
> As we use emf outside of an eclipse environment I don't think that
> extension-points work.
Extension points only work within an OSGi environment. But the same
approach (registering a descriptor to create the factory) should be
reusable in any environment.
>
> So overall the above would be much easier if for example the EObject
> interface would also extend java.io.Serializable (why not?) and some
> other smaller changes related to using the correct singleton enumerate
> instance.
> But maybe/probably I overlook many things here.
I've been thinking about perhaps supporting java.io.Serializeable in
general within the implementation classes (i.e., BasicEObjectImpl,
ResourceImpl, ResourceSetImpl), but as I said, the closure issue seems
tricky and I need to be sure that whatever we do wouldn't break clients
who might have taken a different approach already.
>
>
> gr. Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> No, it must be the case that EcoreFactory.eINSTANCE ==
>> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a
>> reasonable approach. You should use the factory_override extension
>> point to override the factory for a package (so that the actual
>> XyzFactory.eINSTANCE is overridden); a given package can have at most
>> one override in the JVM.
>> I'd like to understand why EEnumLiteralImpl must be serializeable,
>> because this implies to me that only serializeable data types can be
>> supported when that isn't a general restriction for EMF because it
>> uses the createFromString/convertToString for that. If this is
>> absolutely needed to support Teneo, I'd rather do it directly in EMF
>> so that you wouldn't need to override the factory; I know Apache's
>> Tuscany project is using an override of EcoreFactory.eINSTANCE to
>> create DataObjects, and it would be nice if Teneo still worked for
>> that too.
>>
>>
>> Martin Taal wrote:
>>> Hi,
>>> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE
>>> to create eenums (and maybe also other model elements). Would it be
>>> possible to let it use EcorePackage.eINSTANCE.getEFactoryInstance()
>>> instead?
>>>
>>> The reason that I ask is that this makes it possible to override the
>>> default EcoreFactory with our own implementation (by setting the
>>> EcoreFactory in the EcorePackage). We require our own implementation
>>> to make use of our own serializable EEnumLiteral.
>>>
>>> Btw, is overriding EcoreFactory a valid approach in this case?
>>>
>
>
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #69830 is a reply to message #69813] Tue, 26 September 2006 09:17 Go to previous messageGo to next message
Martin Taal is currently offline Martin Taal
Messages: 5326
Registered: July 2009
Senior Member
Ed,
Thanks for your reply. Comments below, marked with MT>>.

gr. Martin

Ed Merks wrote:
> Martin,
>
> Comments below.
>
>
> Martin Taal wrote:
>> Hi Ed,
>> I was expecting that there was more to it.
>>
>> We are working on using EMF in combination with JSF (Java Server
>> Faces) and also Spring Web Flow (so not related to Teneo, although it
>> uses it). These frameworks/technologies store state by
>> java-serializing the data-objects. Java serializability is also used
>> by a number of other frameworks (jboss seam and jboss work flow also
>> as I understand).
> Yes, many frameworks rely on this. I could certainly imagine an
> approach similar to what we did to support java.io.Serializeable when
> implement SDO 1.0 on top of EMF. I.e., one could effectively serialize
> the whole resource set. What isn't always clear is how much of the
> "closure" needs to be serialized, so I'm not sure if such a brute force,
> one size fits all solutions is a good thing...
MT>> Yes serialization can be very crude (in the end you can serialize the whole jvm heap). But I
think that the one who uses java serialization is responsible for determining what is a correct set
of data to serialize (by removing references to what not should be serialized). At least that is
what the designers of java.io.Serialization thought probably.
So (imho) EMF should just support basic java.io.serialization and leave the other part of the
problem to the java developer. This is in way different from xml-serialization where EMF offers more
control (and therefor has more responsibility I think).

>>
>> There are different cases:
>> > Dynamic EMF
>> 1) The DynamicEObjectImpl
>> I have my own serializable dynamic eobject impl which is
>> java.io.serializable, currently I set my own
>> serializableeobjectfactory in the epackage to force the use of this
>> serializable dynamiceobject (but this is not a correct approach?).
> No, this is not generally a great idea. You should use the extension
> point or use the same approach as is used to implement the extension point.
>> 2) the EEnumLiteral: when reading a model directly from a xsd,
>> xsdecorebuilder will create EEnumLiterals, in this step I want to
>> replace the creation of a standard EEnumLiteral by my serializable
>> eenumliteral. I have now done this by overriding the xsdecorebuilder
>> and changing two statements. But I did not feel that this was a long
>> term sound approach.
> Why is EEnumLiteral so special? Is it because all the other data types
> are serializeable?
MT>> Yes the other base datatypes are serializable and enumliteral is not.

>>
>> > Generated EMF (java code)
>> I can make the generated java code serializable by making minor
>> changes to the jet templates. This is workable. Although I would
>> prefer to just use a serializable EObject.
>>
>> As we use emf outside of an eclipse environment I don't think that
>> extension-points work.
> Extension points only work within an OSGi environment. But the same
> approach (registering a descriptor to create the factory) should be
> reusable in any environment.
>>
>> So overall the above would be much easier if for example the EObject
>> interface would also extend java.io.Serializable (why not?) and some
>> other smaller changes related to using the correct singleton enumerate
>> instance.
>> But maybe/probably I overlook many things here.
> I've been thinking about perhaps supporting java.io.Serializeable in
> general within the implementation classes (i.e., BasicEObjectImpl,
> ResourceImpl, ResourceSetImpl), but as I said, the closure issue seems
> tricky and I need to be sure that whatever we do wouldn't break clients
> who might have taken a different approach already
MT>> Why not just leave the closure problem to the user of EMF?
For me xml serialization and java serialization have different purposes and do not require EMF to
offer the same level of control (through resources, containment etc.).

>>
>>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> No, it must be the case that EcoreFactory.eINSTANCE ==
>>> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a
>>> reasonable approach. You should use the factory_override extension
>>> point to override the factory for a package (so that the actual
>>> XyzFactory.eINSTANCE is overridden); a given package can have at most
>>> one override in the JVM.
>>> I'd like to understand why EEnumLiteralImpl must be serializeable,
>>> because this implies to me that only serializeable data types can be
>>> supported when that isn't a general restriction for EMF because it
>>> uses the createFromString/convertToString for that. If this is
>>> absolutely needed to support Teneo, I'd rather do it directly in EMF
>>> so that you wouldn't need to override the factory; I know Apache's
>>> Tuscany project is using an override of EcoreFactory.eINSTANCE to
>>> create DataObjects, and it would be nice if Teneo still worked for
>>> that too.
>>>
>>>
>>> Martin Taal wrote:
>>>> Hi,
>>>> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE
>>>> to create eenums (and maybe also other model elements). Would it be
>>>> possible to let it use EcorePackage.eINSTANCE.getEFactoryInstance()
>>>> instead?
>>>>
>>>> The reason that I ask is that this makes it possible to override the
>>>> default EcoreFactory with our own implementation (by setting the
>>>> EcoreFactory in the EcorePackage). We require our own implementation
>>>> to make use of our own serializable EEnumLiteral.
>>>>
>>>> Btw, is overriding EcoreFactory a valid approach in this case?
>>>>
>>
>>


--

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
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #69850 is a reply to message #69830] Tue, 26 September 2006 09:40 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Martin,

So far I've only considered writePlace in combination with EMF
serialization (because this eliminates dependencies on specific
implementation classes). I think you're suggesting that just making the
object serializeable and letting Java handle it the normal way is fine;
I've never tried that and didn't think it would work. (E.g., we don't
make transient features transient in the Java sense.) We can have an
in-depth conversation about this at the Eclipse Summit in a few weeks.
;-) I'm certainly willing to consider adding support for
java.io.Serializeable directly to EEnumLiteralImpl in EMF if that makes
folks happy and isn't likely to cause anyone problems. In fact, I'd
suggested someone open a feature request for generating serializeable
type safe enums, which they didn't follow up on; perhaps it doesn't make
sense to do that given that we should be able to generate Java 5.0 enums
in the next release cycle...


Martin Taal wrote:
> Ed,
> Thanks for your reply. Comments below, marked with MT>>.
>
> gr. Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> Comments below.
>>
>>
>> Martin Taal wrote:
>>> Hi Ed,
>>> I was expecting that there was more to it.
>>>
>>> We are working on using EMF in combination with JSF (Java Server
>>> Faces) and also Spring Web Flow (so not related to Teneo, although
>>> it uses it). These frameworks/technologies store state by
>>> java-serializing the data-objects. Java serializability is also used
>>> by a number of other frameworks (jboss seam and jboss work flow also
>>> as I understand).
>> Yes, many frameworks rely on this. I could certainly imagine an
>> approach similar to what we did to support java.io.Serializeable when
>> implement SDO 1.0 on top of EMF. I.e., one could effectively
>> serialize the whole resource set. What isn't always clear is how
>> much of the "closure" needs to be serialized, so I'm not sure if such
>> a brute force, one size fits all solutions is a good thing...
> MT>> Yes serialization can be very crude (in the end you can serialize
> the whole jvm heap). But I think that the one who uses java
> serialization is responsible for determining what is a correct set of
> data to serialize (by removing references to what not should be
> serialized). At least that is what the designers of
> java.io.Serialization thought probably.
> So (imho) EMF should just support basic java.io.serialization and
> leave the other part of the problem to the java developer. This is in
> way different from xml-serialization where EMF offers more control
> (and therefor has more responsibility I think).
>
>>>
>>> There are different cases:
>>> > Dynamic EMF
>>> 1) The DynamicEObjectImpl
>>> I have my own serializable dynamic eobject impl which is
>>> java.io.serializable, currently I set my own
>>> serializableeobjectfactory in the epackage to force the use of this
>>> serializable dynamiceobject (but this is not a correct approach?).
>> No, this is not generally a great idea. You should use the extension
>> point or use the same approach as is used to implement the extension
>> point.
>>> 2) the EEnumLiteral: when reading a model directly from a xsd,
>>> xsdecorebuilder will create EEnumLiterals, in this step I want to
>>> replace the creation of a standard EEnumLiteral by my serializable
>>> eenumliteral. I have now done this by overriding the xsdecorebuilder
>>> and changing two statements. But I did not feel that this was a long
>>> term sound approach.
>> Why is EEnumLiteral so special? Is it because all the other data
>> types are serializeable?
> MT>> Yes the other base datatypes are serializable and enumliteral is
> not.
>
>>>
>>> > Generated EMF (java code)
>>> I can make the generated java code serializable by making minor
>>> changes to the jet templates. This is workable. Although I would
>>> prefer to just use a serializable EObject.
>>>
>>> As we use emf outside of an eclipse environment I don't think that
>>> extension-points work.
>> Extension points only work within an OSGi environment. But the same
>> approach (registering a descriptor to create the factory) should be
>> reusable in any environment.
>>>
>>> So overall the above would be much easier if for example the EObject
>>> interface would also extend java.io.Serializable (why not?) and some
>>> other smaller changes related to using the correct singleton
>>> enumerate instance.
>>> But maybe/probably I overlook many things here.
>> I've been thinking about perhaps supporting java.io.Serializeable in
>> general within the implementation classes (i.e., BasicEObjectImpl,
>> ResourceImpl, ResourceSetImpl), but as I said, the closure issue
>> seems tricky and I need to be sure that whatever we do wouldn't break
>> clients who might have taken a different approach already
> MT>> Why not just leave the closure problem to the user of EMF?
> For me xml serialization and java serialization have different
> purposes and do not require EMF to offer the same level of control
> (through resources, containment etc.).
>
>>>
>>>
>>> gr. Martin
>>>
>>> Ed Merks wrote:
>>>> Martin,
>>>>
>>>> No, it must be the case that EcoreFactory.eINSTANCE ==
>>>> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a
>>>> reasonable approach. You should use the factory_override extension
>>>> point to override the factory for a package (so that the actual
>>>> XyzFactory.eINSTANCE is overridden); a given package can have at
>>>> most one override in the JVM.
>>>> I'd like to understand why EEnumLiteralImpl must be serializeable,
>>>> because this implies to me that only serializeable data types can
>>>> be supported when that isn't a general restriction for EMF because
>>>> it uses the createFromString/convertToString for that. If this is
>>>> absolutely needed to support Teneo, I'd rather do it directly in
>>>> EMF so that you wouldn't need to override the factory; I know
>>>> Apache's Tuscany project is using an override of
>>>> EcoreFactory.eINSTANCE to create DataObjects, and it would be nice
>>>> if Teneo still worked for that too.
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>> Hi,
>>>>> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE
>>>>> to create eenums (and maybe also other model elements). Would it
>>>>> be possible to let it use
>>>>> EcorePackage.eINSTANCE.getEFactoryInstance() instead?
>>>>>
>>>>> The reason that I ask is that this makes it possible to override
>>>>> the default EcoreFactory with our own implementation (by setting
>>>>> the EcoreFactory in the EcorePackage). We require our own
>>>>> implementation to make use of our own serializable EEnumLiteral.
>>>>>
>>>>> Btw, is overriding EcoreFactory a valid approach in this case?
>>>>>
>>>
>>>
>
>
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #69870 is a reply to message #69850] Wed, 27 September 2006 03:07 Go to previous messageGo to next message
Martin Taal is currently offline Martin Taal
Messages: 5326
Registered: July 2009
Senior Member
Hi Ed,
Okay, I am looking forward to an in-depth discussion on java.io.serialization and EMF ;-).

When will there be java 5 support in EMF, or when is the next release cycle planned?

gr. Martin

Ed Merks wrote:
> Martin,
>
> So far I've only considered writePlace in combination with EMF
> serialization (because this eliminates dependencies on specific
> implementation classes). I think you're suggesting that just making the
> object serializeable and letting Java handle it the normal way is fine;
> I've never tried that and didn't think it would work. (E.g., we don't
> make transient features transient in the Java sense.) We can have an
> in-depth conversation about this at the Eclipse Summit in a few weeks.
> ;-) I'm certainly willing to consider adding support for
> java.io.Serializeable directly to EEnumLiteralImpl in EMF if that makes
> folks happy and isn't likely to cause anyone problems. In fact, I'd
> suggested someone open a feature request for generating serializeable
> type safe enums, which they didn't follow up on; perhaps it doesn't make
> sense to do that given that we should be able to generate Java 5.0 enums
> in the next release cycle...
>
>
> Martin Taal wrote:
>> Ed,
>> Thanks for your reply. Comments below, marked with MT>>.
>>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> Comments below.
>>>
>>>
>>> Martin Taal wrote:
>>>> Hi Ed,
>>>> I was expecting that there was more to it.
>>>>
>>>> We are working on using EMF in combination with JSF (Java Server
>>>> Faces) and also Spring Web Flow (so not related to Teneo, although
>>>> it uses it). These frameworks/technologies store state by
>>>> java-serializing the data-objects. Java serializability is also used
>>>> by a number of other frameworks (jboss seam and jboss work flow also
>>>> as I understand).
>>> Yes, many frameworks rely on this. I could certainly imagine an
>>> approach similar to what we did to support java.io.Serializeable when
>>> implement SDO 1.0 on top of EMF. I.e., one could effectively
>>> serialize the whole resource set. What isn't always clear is how
>>> much of the "closure" needs to be serialized, so I'm not sure if such
>>> a brute force, one size fits all solutions is a good thing...
>> MT>> Yes serialization can be very crude (in the end you can serialize
>> the whole jvm heap). But I think that the one who uses java
>> serialization is responsible for determining what is a correct set of
>> data to serialize (by removing references to what not should be
>> serialized). At least that is what the designers of
>> java.io.Serialization thought probably.
>> So (imho) EMF should just support basic java.io.serialization and
>> leave the other part of the problem to the java developer. This is in
>> way different from xml-serialization where EMF offers more control
>> (and therefor has more responsibility I think).
>>
>>>>
>>>> There are different cases:
>>>> > Dynamic EMF
>>>> 1) The DynamicEObjectImpl
>>>> I have my own serializable dynamic eobject impl which is
>>>> java.io.serializable, currently I set my own
>>>> serializableeobjectfactory in the epackage to force the use of this
>>>> serializable dynamiceobject (but this is not a correct approach?).
>>> No, this is not generally a great idea. You should use the extension
>>> point or use the same approach as is used to implement the extension
>>> point.
>>>> 2) the EEnumLiteral: when reading a model directly from a xsd,
>>>> xsdecorebuilder will create EEnumLiterals, in this step I want to
>>>> replace the creation of a standard EEnumLiteral by my serializable
>>>> eenumliteral. I have now done this by overriding the xsdecorebuilder
>>>> and changing two statements. But I did not feel that this was a long
>>>> term sound approach.
>>> Why is EEnumLiteral so special? Is it because all the other data
>>> types are serializeable?
>> MT>> Yes the other base datatypes are serializable and enumliteral is
>> not.
>>
>>>>
>>>> > Generated EMF (java code)
>>>> I can make the generated java code serializable by making minor
>>>> changes to the jet templates. This is workable. Although I would
>>>> prefer to just use a serializable EObject.
>>>>
>>>> As we use emf outside of an eclipse environment I don't think that
>>>> extension-points work.
>>> Extension points only work within an OSGi environment. But the same
>>> approach (registering a descriptor to create the factory) should be
>>> reusable in any environment.
>>>>
>>>> So overall the above would be much easier if for example the EObject
>>>> interface would also extend java.io.Serializable (why not?) and some
>>>> other smaller changes related to using the correct singleton
>>>> enumerate instance.
>>>> But maybe/probably I overlook many things here.
>>> I've been thinking about perhaps supporting java.io.Serializeable in
>>> general within the implementation classes (i.e., BasicEObjectImpl,
>>> ResourceImpl, ResourceSetImpl), but as I said, the closure issue
>>> seems tricky and I need to be sure that whatever we do wouldn't break
>>> clients who might have taken a different approach already
>> MT>> Why not just leave the closure problem to the user of EMF?
>> For me xml serialization and java serialization have different
>> purposes and do not require EMF to offer the same level of control
>> (through resources, containment etc.).
>>
>>>>
>>>>
>>>> gr. Martin
>>>>
>>>> Ed Merks wrote:
>>>>> Martin,
>>>>>
>>>>> No, it must be the case that EcoreFactory.eINSTANCE ==
>>>>> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a
>>>>> reasonable approach. You should use the factory_override extension
>>>>> point to override the factory for a package (so that the actual
>>>>> XyzFactory.eINSTANCE is overridden); a given package can have at
>>>>> most one override in the JVM.
>>>>> I'd like to understand why EEnumLiteralImpl must be serializeable,
>>>>> because this implies to me that only serializeable data types can
>>>>> be supported when that isn't a general restriction for EMF because
>>>>> it uses the createFromString/convertToString for that. If this is
>>>>> absolutely needed to support Teneo, I'd rather do it directly in
>>>>> EMF so that you wouldn't need to override the factory; I know
>>>>> Apache's Tuscany project is using an override of
>>>>> EcoreFactory.eINSTANCE to create DataObjects, and it would be nice
>>>>> if Teneo still worked for that too.
>>>>>
>>>>>
>>>>> Martin Taal wrote:
>>>>>> Hi,
>>>>>> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE
>>>>>> to create eenums (and maybe also other model elements). Would it
>>>>>> be possible to let it use
>>>>>> EcorePackage.eINSTANCE.getEFactoryInstance() instead?
>>>>>>
>>>>>> The reason that I ask is that this makes it possible to override
>>>>>> the default EcoreFactory with our own implementation (by setting
>>>>>> the EcoreFactory in the EcorePackage). We require our own
>>>>>> implementation to make use of our own serializable EEnumLiteral.
>>>>>>
>>>>>> Btw, is overriding EcoreFactory a valid approach in this case?
>>>>>>
>>>>
>>>>
>>
>>


--

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
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #69893 is a reply to message #69870] Wed, 27 September 2006 07:28 Go to previous message
Eclipse User
Originally posted by: merks.ca.ibm.com

Martin,

Our latest coop student is working on AST-based JMerge, which we need to
support Java 5.0 syntax in the generator, while the rest of us
developers (Marcelo, Dave and I) are still working on completing the
second edition of the book. With EMF 2.2.1 development completed today,
we (especially me, because I don't like working on the book!) will
likely start our 3.0 development stream in the next week or two and the
cycle completes on Eclipse's regular yearly cycle that ends each June.


Martin Taal wrote:

> Hi Ed,
> Okay, I am looking forward to an in-depth discussion on
> java.io.serialization and EMF ;-).
>
> When will there be java 5 support in EMF, or when is the next release
> cycle planned?
>
> gr. Martin
>
> Ed Merks wrote:
>
>> Martin,
>>
>> So far I've only considered writePlace in combination with EMF
>> serialization (because this eliminates dependencies on specific
>> implementation classes). I think you're suggesting that just making
>> the object serializeable and letting Java handle it the normal way is
>> fine; I've never tried that and didn't think it would work. (E.g., we
>> don't make transient features transient in the Java sense.) We can
>> have an in-depth conversation about this at the Eclipse Summit in a
>> few weeks. ;-) I'm certainly willing to consider adding support for
>> java.io.Serializeable directly to EEnumLiteralImpl in EMF if that
>> makes folks happy and isn't likely to cause anyone problems. In
>> fact, I'd suggested someone open a feature request for generating
>> serializeable type safe enums, which they didn't follow up on;
>> perhaps it doesn't make sense to do that given that we should be able
>> to generate Java 5.0 enums in the next release cycle...
>>
>>
>> Martin Taal wrote:
>>
>>> Ed,
>>> Thanks for your reply. Comments below, marked with MT>>.
>>>
>>> gr. Martin
>>>
>>> Ed Merks wrote:
>>>
>>>> Martin,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>
>>>>> Hi Ed,
>>>>> I was expecting that there was more to it.
>>>>>
>>>>> We are working on using EMF in combination with JSF (Java Server
>>>>> Faces) and also Spring Web Flow (so not related to Teneo, although
>>>>> it uses it). These frameworks/technologies store state by
>>>>> java-serializing the data-objects. Java serializability is also
>>>>> used by a number of other frameworks (jboss seam and jboss work
>>>>> flow also as I understand).
>>>>
>>>> Yes, many frameworks rely on this. I could certainly imagine an
>>>> approach similar to what we did to support java.io.Serializeable
>>>> when implement SDO 1.0 on top of EMF. I.e., one could effectively
>>>> serialize the whole resource set. What isn't always clear is how
>>>> much of the "closure" needs to be serialized, so I'm not sure if
>>>> such a brute force, one size fits all solutions is a good thing...
>>>
>>> MT>> Yes serialization can be very crude (in the end you can
>>> serialize the whole jvm heap). But I think that the one who uses
>>> java serialization is responsible for determining what is a correct
>>> set of data to serialize (by removing references to what not should
>>> be serialized). At least that is what the designers of
>>> java.io.Serialization thought probably.
>>> So (imho) EMF should just support basic java.io.serialization and
>>> leave the other part of the problem to the java developer. This is
>>> in way different from xml-serialization where EMF offers more
>>> control (and therefor has more responsibility I think).
>>>
>>>>>
>>>>> There are different cases:
>>>>> > Dynamic EMF
>>>>> 1) The DynamicEObjectImpl
>>>>> I have my own serializable dynamic eobject impl which is
>>>>> java.io.serializable, currently I set my own
>>>>> serializableeobjectfactory in the epackage to force the use of
>>>>> this serializable dynamiceobject (but this is not a correct
>>>>> approach?).
>>>>
>>>> No, this is not generally a great idea. You should use the
>>>> extension point or use the same approach as is used to implement
>>>> the extension point.
>>>>
>>>>> 2) the EEnumLiteral: when reading a model directly from a xsd,
>>>>> xsdecorebuilder will create EEnumLiterals, in this step I want to
>>>>> replace the creation of a standard EEnumLiteral by my serializable
>>>>> eenumliteral. I have now done this by overriding the
>>>>> xsdecorebuilder and changing two statements. But I did not feel
>>>>> that this was a long term sound approach.
>>>>
>>>> Why is EEnumLiteral so special? Is it because all the other data
>>>> types are serializeable?
>>>
>>> MT>> Yes the other base datatypes are serializable and enumliteral
>>> is not.
>>>
>>>>>
>>>>> > Generated EMF (java code)
>>>>> I can make the generated java code serializable by making minor
>>>>> changes to the jet templates. This is workable. Although I would
>>>>> prefer to just use a serializable EObject.
>>>>>
>>>>> As we use emf outside of an eclipse environment I don't think that
>>>>> extension-points work.
>>>>
>>>> Extension points only work within an OSGi environment. But the
>>>> same approach (registering a descriptor to create the factory)
>>>> should be reusable in any environment.
>>>>
>>>>>
>>>>> So overall the above would be much easier if for example the
>>>>> EObject interface would also extend java.io.Serializable (why
>>>>> not?) and some other smaller changes related to using the correct
>>>>> singleton enumerate instance.
>>>>> But maybe/probably I overlook many things here.
>>>>
>>>> I've been thinking about perhaps supporting java.io.Serializeable
>>>> in general within the implementation classes (i.e.,
>>>> BasicEObjectImpl, ResourceImpl, ResourceSetImpl), but as I said,
>>>> the closure issue seems tricky and I need to be sure that whatever
>>>> we do wouldn't break clients who might have taken a different
>>>> approach already
>>>
>>> MT>> Why not just leave the closure problem to the user of EMF?
>>> For me xml serialization and java serialization have different
>>> purposes and do not require EMF to offer the same level of control
>>> (through resources, containment etc.).
>>>
>>>>>
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>> Martin,
>>>>>>
>>>>>> No, it must be the case that EcoreFactory.eINSTANCE ==
>>>>>> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a
>>>>>> reasonable approach. You should use the factory_override
>>>>>> extension point to override the factory for a package (so that
>>>>>> the actual XyzFactory.eINSTANCE is overridden); a given package
>>>>>> can have at most one override in the JVM.
>>>>>> I'd like to understand why EEnumLiteralImpl must be
>>>>>> serializeable, because this implies to me that only serializeable
>>>>>> data types can be supported when that isn't a general restriction
>>>>>> for EMF because it uses the createFromString/convertToString for
>>>>>> that. If this is absolutely needed to support Teneo, I'd rather
>>>>>> do it directly in EMF so that you wouldn't need to override the
>>>>>> factory; I know Apache's Tuscany project is using an override of
>>>>>> EcoreFactory.eINSTANCE to create DataObjects, and it would be
>>>>>> nice if Teneo still worked for that too.
>>>>>>
>>>>>>
>>>>>> Martin Taal wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I noticed that the XSDEcoreBuilder uses the
>>>>>>> EcoreFactory.eINSTANCE to create eenums (and maybe also other
>>>>>>> model elements). Would it be possible to let it use
>>>>>>> EcorePackage.eINSTANCE.getEFactoryInstance() instead?
>>>>>>>
>>>>>>> The reason that I ask is that this makes it possible to override
>>>>>>> the default EcoreFactory with our own implementation (by setting
>>>>>>> the EcoreFactory in the EcorePackage). We require our own
>>>>>>> implementation to make use of our own serializable EEnumLiteral.
>>>>>>>
>>>>>>> Btw, is overriding EcoreFactory a valid approach in this case?
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #598762 is a reply to message #69749] Tue, 26 September 2006 07:28 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
Martin,

No, it must be the case that EcoreFactory.eINSTANCE ==
EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a reasonable
approach. You should use the factory_override extension point to
override the factory for a package (so that the actual
XyzFactory.eINSTANCE is overridden); a given package can have at most
one override in the JVM.

I'd like to understand why EEnumLiteralImpl must be serializeable,
because this implies to me that only serializeable data types can be
supported when that isn't a general restriction for EMF because it uses
the createFromString/convertToString for that. If this is absolutely
needed to support Teneo, I'd rather do it directly in EMF so that you
wouldn't need to override the factory; I know Apache's Tuscany project
is using an override of EcoreFactory.eINSTANCE to create DataObjects,
and it would be nice if Teneo still worked for that too.


Martin Taal wrote:
> Hi,
> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE to
> create eenums (and maybe also other model elements). Would it be
> possible to let it use EcorePackage.eINSTANCE.getEFactoryInstance()
> instead?
>
> The reason that I ask is that this makes it possible to override the
> default EcoreFactory with our own implementation (by setting the
> EcoreFactory in the EcorePackage). We require our own implementation
> to make use of our own serializable EEnumLiteral.
>
> Btw, is overriding EcoreFactory a valid approach in this case?
>
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #598771 is a reply to message #69770] Tue, 26 September 2006 08:38 Go to previous message
Martin Taal is currently offline Martin Taal
Messages: 5326
Registered: July 2009
Senior Member
Hi Ed,
I was expecting that there was more to it.

We are working on using EMF in combination with JSF (Java Server Faces) and also Spring Web Flow (so
not related to Teneo, although it uses it). These frameworks/technologies store state by
java-serializing the data-objects. Java serializability is also used by a number of other frameworks
(jboss seam and jboss work flow also as I understand).

There are different cases:
> Dynamic EMF
1) The DynamicEObjectImpl
I have my own serializable dynamic eobject impl which is java.io.serializable, currently I set my
own serializableeobjectfactory in the epackage to force the use of this serializable dynamiceobject
(but this is not a correct approach?).
2) the EEnumLiteral: when reading a model directly from a xsd, xsdecorebuilder will create
EEnumLiterals, in this step I want to replace the creation of a standard EEnumLiteral by my
serializable eenumliteral. I have now done this by overriding the xsdecorebuilder and changing two
statements. But I did not feel that this was a long term sound approach.

> Generated EMF (java code)
I can make the generated java code serializable by making minor changes to the jet templates. This
is workable. Although I would prefer to just use a serializable EObject.

As we use emf outside of an eclipse environment I don't think that extension-points work.

So overall the above would be much easier if for example the EObject interface would also extend
java.io.Serializable (why not?) and some other smaller changes related to using the correct
singleton enumerate instance.
But maybe/probably I overlook many things here.

gr. Martin

Ed Merks wrote:
> Martin,
>
> No, it must be the case that EcoreFactory.eINSTANCE ==
> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a reasonable
> approach. You should use the factory_override extension point to
> override the factory for a package (so that the actual
> XyzFactory.eINSTANCE is overridden); a given package can have at most
> one override in the JVM.
> I'd like to understand why EEnumLiteralImpl must be serializeable,
> because this implies to me that only serializeable data types can be
> supported when that isn't a general restriction for EMF because it uses
> the createFromString/convertToString for that. If this is absolutely
> needed to support Teneo, I'd rather do it directly in EMF so that you
> wouldn't need to override the factory; I know Apache's Tuscany project
> is using an override of EcoreFactory.eINSTANCE to create DataObjects,
> and it would be nice if Teneo still worked for that too.
>
>
> Martin Taal wrote:
>> Hi,
>> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE to
>> create eenums (and maybe also other model elements). Would it be
>> possible to let it use EcorePackage.eINSTANCE.getEFactoryInstance()
>> instead?
>>
>> The reason that I ask is that this makes it possible to override the
>> default EcoreFactory with our own implementation (by setting the
>> EcoreFactory in the EcorePackage). We require our own implementation
>> to make use of our own serializable EEnumLiteral.
>>
>> Btw, is overriding EcoreFactory a valid approach in this case?
>>


--

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
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #598779 is a reply to message #69790] Tue, 26 September 2006 08:52 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
Martin,

Comments below.


Martin Taal wrote:
> Hi Ed,
> I was expecting that there was more to it.
>
> We are working on using EMF in combination with JSF (Java Server
> Faces) and also Spring Web Flow (so not related to Teneo, although it
> uses it). These frameworks/technologies store state by
> java-serializing the data-objects. Java serializability is also used
> by a number of other frameworks (jboss seam and jboss work flow also
> as I understand).
Yes, many frameworks rely on this. I could certainly imagine an
approach similar to what we did to support java.io.Serializeable when
implement SDO 1.0 on top of EMF. I.e., one could effectively serialize
the whole resource set. What isn't always clear is how much of the
"closure" needs to be serialized, so I'm not sure if such a brute force,
one size fits all solutions is a good thing...
>
> There are different cases:
> > Dynamic EMF
> 1) The DynamicEObjectImpl
> I have my own serializable dynamic eobject impl which is
> java.io.serializable, currently I set my own
> serializableeobjectfactory in the epackage to force the use of this
> serializable dynamiceobject (but this is not a correct approach?).
No, this is not generally a great idea. You should use the extension
point or use the same approach as is used to implement the extension point.
> 2) the EEnumLiteral: when reading a model directly from a xsd,
> xsdecorebuilder will create EEnumLiterals, in this step I want to
> replace the creation of a standard EEnumLiteral by my serializable
> eenumliteral. I have now done this by overriding the xsdecorebuilder
> and changing two statements. But I did not feel that this was a long
> term sound approach.
Why is EEnumLiteral so special? Is it because all the other data types
are serializeable?
>
> > Generated EMF (java code)
> I can make the generated java code serializable by making minor
> changes to the jet templates. This is workable. Although I would
> prefer to just use a serializable EObject.
>
> As we use emf outside of an eclipse environment I don't think that
> extension-points work.
Extension points only work within an OSGi environment. But the same
approach (registering a descriptor to create the factory) should be
reusable in any environment.
>
> So overall the above would be much easier if for example the EObject
> interface would also extend java.io.Serializable (why not?) and some
> other smaller changes related to using the correct singleton enumerate
> instance.
> But maybe/probably I overlook many things here.
I've been thinking about perhaps supporting java.io.Serializeable in
general within the implementation classes (i.e., BasicEObjectImpl,
ResourceImpl, ResourceSetImpl), but as I said, the closure issue seems
tricky and I need to be sure that whatever we do wouldn't break clients
who might have taken a different approach already.
>
>
> gr. Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> No, it must be the case that EcoreFactory.eINSTANCE ==
>> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a
>> reasonable approach. You should use the factory_override extension
>> point to override the factory for a package (so that the actual
>> XyzFactory.eINSTANCE is overridden); a given package can have at most
>> one override in the JVM.
>> I'd like to understand why EEnumLiteralImpl must be serializeable,
>> because this implies to me that only serializeable data types can be
>> supported when that isn't a general restriction for EMF because it
>> uses the createFromString/convertToString for that. If this is
>> absolutely needed to support Teneo, I'd rather do it directly in EMF
>> so that you wouldn't need to override the factory; I know Apache's
>> Tuscany project is using an override of EcoreFactory.eINSTANCE to
>> create DataObjects, and it would be nice if Teneo still worked for
>> that too.
>>
>>
>> Martin Taal wrote:
>>> Hi,
>>> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE
>>> to create eenums (and maybe also other model elements). Would it be
>>> possible to let it use EcorePackage.eINSTANCE.getEFactoryInstance()
>>> instead?
>>>
>>> The reason that I ask is that this makes it possible to override the
>>> default EcoreFactory with our own implementation (by setting the
>>> EcoreFactory in the EcorePackage). We require our own implementation
>>> to make use of our own serializable EEnumLiteral.
>>>
>>> Btw, is overriding EcoreFactory a valid approach in this case?
>>>
>
>
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #598783 is a reply to message #69813] Tue, 26 September 2006 09:17 Go to previous message
Martin Taal is currently offline Martin Taal
Messages: 5326
Registered: July 2009
Senior Member
Ed,
Thanks for your reply. Comments below, marked with MT>>.

gr. Martin

Ed Merks wrote:
> Martin,
>
> Comments below.
>
>
> Martin Taal wrote:
>> Hi Ed,
>> I was expecting that there was more to it.
>>
>> We are working on using EMF in combination with JSF (Java Server
>> Faces) and also Spring Web Flow (so not related to Teneo, although it
>> uses it). These frameworks/technologies store state by
>> java-serializing the data-objects. Java serializability is also used
>> by a number of other frameworks (jboss seam and jboss work flow also
>> as I understand).
> Yes, many frameworks rely on this. I could certainly imagine an
> approach similar to what we did to support java.io.Serializeable when
> implement SDO 1.0 on top of EMF. I.e., one could effectively serialize
> the whole resource set. What isn't always clear is how much of the
> "closure" needs to be serialized, so I'm not sure if such a brute force,
> one size fits all solutions is a good thing...
MT>> Yes serialization can be very crude (in the end you can serialize the whole jvm heap). But I
think that the one who uses java serialization is responsible for determining what is a correct set
of data to serialize (by removing references to what not should be serialized). At least that is
what the designers of java.io.Serialization thought probably.
So (imho) EMF should just support basic java.io.serialization and leave the other part of the
problem to the java developer. This is in way different from xml-serialization where EMF offers more
control (and therefor has more responsibility I think).

>>
>> There are different cases:
>> > Dynamic EMF
>> 1) The DynamicEObjectImpl
>> I have my own serializable dynamic eobject impl which is
>> java.io.serializable, currently I set my own
>> serializableeobjectfactory in the epackage to force the use of this
>> serializable dynamiceobject (but this is not a correct approach?).
> No, this is not generally a great idea. You should use the extension
> point or use the same approach as is used to implement the extension point.
>> 2) the EEnumLiteral: when reading a model directly from a xsd,
>> xsdecorebuilder will create EEnumLiterals, in this step I want to
>> replace the creation of a standard EEnumLiteral by my serializable
>> eenumliteral. I have now done this by overriding the xsdecorebuilder
>> and changing two statements. But I did not feel that this was a long
>> term sound approach.
> Why is EEnumLiteral so special? Is it because all the other data types
> are serializeable?
MT>> Yes the other base datatypes are serializable and enumliteral is not.

>>
>> > Generated EMF (java code)
>> I can make the generated java code serializable by making minor
>> changes to the jet templates. This is workable. Although I would
>> prefer to just use a serializable EObject.
>>
>> As we use emf outside of an eclipse environment I don't think that
>> extension-points work.
> Extension points only work within an OSGi environment. But the same
> approach (registering a descriptor to create the factory) should be
> reusable in any environment.
>>
>> So overall the above would be much easier if for example the EObject
>> interface would also extend java.io.Serializable (why not?) and some
>> other smaller changes related to using the correct singleton enumerate
>> instance.
>> But maybe/probably I overlook many things here.
> I've been thinking about perhaps supporting java.io.Serializeable in
> general within the implementation classes (i.e., BasicEObjectImpl,
> ResourceImpl, ResourceSetImpl), but as I said, the closure issue seems
> tricky and I need to be sure that whatever we do wouldn't break clients
> who might have taken a different approach already
MT>> Why not just leave the closure problem to the user of EMF?
For me xml serialization and java serialization have different purposes and do not require EMF to
offer the same level of control (through resources, containment etc.).

>>
>>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> No, it must be the case that EcoreFactory.eINSTANCE ==
>>> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a
>>> reasonable approach. You should use the factory_override extension
>>> point to override the factory for a package (so that the actual
>>> XyzFactory.eINSTANCE is overridden); a given package can have at most
>>> one override in the JVM.
>>> I'd like to understand why EEnumLiteralImpl must be serializeable,
>>> because this implies to me that only serializeable data types can be
>>> supported when that isn't a general restriction for EMF because it
>>> uses the createFromString/convertToString for that. If this is
>>> absolutely needed to support Teneo, I'd rather do it directly in EMF
>>> so that you wouldn't need to override the factory; I know Apache's
>>> Tuscany project is using an override of EcoreFactory.eINSTANCE to
>>> create DataObjects, and it would be nice if Teneo still worked for
>>> that too.
>>>
>>>
>>> Martin Taal wrote:
>>>> Hi,
>>>> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE
>>>> to create eenums (and maybe also other model elements). Would it be
>>>> possible to let it use EcorePackage.eINSTANCE.getEFactoryInstance()
>>>> instead?
>>>>
>>>> The reason that I ask is that this makes it possible to override the
>>>> default EcoreFactory with our own implementation (by setting the
>>>> EcoreFactory in the EcorePackage). We require our own implementation
>>>> to make use of our own serializable EEnumLiteral.
>>>>
>>>> Btw, is overriding EcoreFactory a valid approach in this case?
>>>>
>>
>>


--

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
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #598792 is a reply to message #69830] Tue, 26 September 2006 09:40 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
Martin,

So far I've only considered writePlace in combination with EMF
serialization (because this eliminates dependencies on specific
implementation classes). I think you're suggesting that just making the
object serializeable and letting Java handle it the normal way is fine;
I've never tried that and didn't think it would work. (E.g., we don't
make transient features transient in the Java sense.) We can have an
in-depth conversation about this at the Eclipse Summit in a few weeks.
;-) I'm certainly willing to consider adding support for
java.io.Serializeable directly to EEnumLiteralImpl in EMF if that makes
folks happy and isn't likely to cause anyone problems. In fact, I'd
suggested someone open a feature request for generating serializeable
type safe enums, which they didn't follow up on; perhaps it doesn't make
sense to do that given that we should be able to generate Java 5.0 enums
in the next release cycle...


Martin Taal wrote:
> Ed,
> Thanks for your reply. Comments below, marked with MT>>.
>
> gr. Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> Comments below.
>>
>>
>> Martin Taal wrote:
>>> Hi Ed,
>>> I was expecting that there was more to it.
>>>
>>> We are working on using EMF in combination with JSF (Java Server
>>> Faces) and also Spring Web Flow (so not related to Teneo, although
>>> it uses it). These frameworks/technologies store state by
>>> java-serializing the data-objects. Java serializability is also used
>>> by a number of other frameworks (jboss seam and jboss work flow also
>>> as I understand).
>> Yes, many frameworks rely on this. I could certainly imagine an
>> approach similar to what we did to support java.io.Serializeable when
>> implement SDO 1.0 on top of EMF. I.e., one could effectively
>> serialize the whole resource set. What isn't always clear is how
>> much of the "closure" needs to be serialized, so I'm not sure if such
>> a brute force, one size fits all solutions is a good thing...
> MT>> Yes serialization can be very crude (in the end you can serialize
> the whole jvm heap). But I think that the one who uses java
> serialization is responsible for determining what is a correct set of
> data to serialize (by removing references to what not should be
> serialized). At least that is what the designers of
> java.io.Serialization thought probably.
> So (imho) EMF should just support basic java.io.serialization and
> leave the other part of the problem to the java developer. This is in
> way different from xml-serialization where EMF offers more control
> (and therefor has more responsibility I think).
>
>>>
>>> There are different cases:
>>> > Dynamic EMF
>>> 1) The DynamicEObjectImpl
>>> I have my own serializable dynamic eobject impl which is
>>> java.io.serializable, currently I set my own
>>> serializableeobjectfactory in the epackage to force the use of this
>>> serializable dynamiceobject (but this is not a correct approach?).
>> No, this is not generally a great idea. You should use the extension
>> point or use the same approach as is used to implement the extension
>> point.
>>> 2) the EEnumLiteral: when reading a model directly from a xsd,
>>> xsdecorebuilder will create EEnumLiterals, in this step I want to
>>> replace the creation of a standard EEnumLiteral by my serializable
>>> eenumliteral. I have now done this by overriding the xsdecorebuilder
>>> and changing two statements. But I did not feel that this was a long
>>> term sound approach.
>> Why is EEnumLiteral so special? Is it because all the other data
>> types are serializeable?
> MT>> Yes the other base datatypes are serializable and enumliteral is
> not.
>
>>>
>>> > Generated EMF (java code)
>>> I can make the generated java code serializable by making minor
>>> changes to the jet templates. This is workable. Although I would
>>> prefer to just use a serializable EObject.
>>>
>>> As we use emf outside of an eclipse environment I don't think that
>>> extension-points work.
>> Extension points only work within an OSGi environment. But the same
>> approach (registering a descriptor to create the factory) should be
>> reusable in any environment.
>>>
>>> So overall the above would be much easier if for example the EObject
>>> interface would also extend java.io.Serializable (why not?) and some
>>> other smaller changes related to using the correct singleton
>>> enumerate instance.
>>> But maybe/probably I overlook many things here.
>> I've been thinking about perhaps supporting java.io.Serializeable in
>> general within the implementation classes (i.e., BasicEObjectImpl,
>> ResourceImpl, ResourceSetImpl), but as I said, the closure issue
>> seems tricky and I need to be sure that whatever we do wouldn't break
>> clients who might have taken a different approach already
> MT>> Why not just leave the closure problem to the user of EMF?
> For me xml serialization and java serialization have different
> purposes and do not require EMF to offer the same level of control
> (through resources, containment etc.).
>
>>>
>>>
>>> gr. Martin
>>>
>>> Ed Merks wrote:
>>>> Martin,
>>>>
>>>> No, it must be the case that EcoreFactory.eINSTANCE ==
>>>> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a
>>>> reasonable approach. You should use the factory_override extension
>>>> point to override the factory for a package (so that the actual
>>>> XyzFactory.eINSTANCE is overridden); a given package can have at
>>>> most one override in the JVM.
>>>> I'd like to understand why EEnumLiteralImpl must be serializeable,
>>>> because this implies to me that only serializeable data types can
>>>> be supported when that isn't a general restriction for EMF because
>>>> it uses the createFromString/convertToString for that. If this is
>>>> absolutely needed to support Teneo, I'd rather do it directly in
>>>> EMF so that you wouldn't need to override the factory; I know
>>>> Apache's Tuscany project is using an override of
>>>> EcoreFactory.eINSTANCE to create DataObjects, and it would be nice
>>>> if Teneo still worked for that too.
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>> Hi,
>>>>> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE
>>>>> to create eenums (and maybe also other model elements). Would it
>>>>> be possible to let it use
>>>>> EcorePackage.eINSTANCE.getEFactoryInstance() instead?
>>>>>
>>>>> The reason that I ask is that this makes it possible to override
>>>>> the default EcoreFactory with our own implementation (by setting
>>>>> the EcoreFactory in the EcorePackage). We require our own
>>>>> implementation to make use of our own serializable EEnumLiteral.
>>>>>
>>>>> Btw, is overriding EcoreFactory a valid approach in this case?
>>>>>
>>>
>>>
>
>
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #598796 is a reply to message #69850] Wed, 27 September 2006 03:07 Go to previous message
Martin Taal is currently offline Martin Taal
Messages: 5326
Registered: July 2009
Senior Member
Hi Ed,
Okay, I am looking forward to an in-depth discussion on java.io.serialization and EMF ;-).

When will there be java 5 support in EMF, or when is the next release cycle planned?

gr. Martin

Ed Merks wrote:
> Martin,
>
> So far I've only considered writePlace in combination with EMF
> serialization (because this eliminates dependencies on specific
> implementation classes). I think you're suggesting that just making the
> object serializeable and letting Java handle it the normal way is fine;
> I've never tried that and didn't think it would work. (E.g., we don't
> make transient features transient in the Java sense.) We can have an
> in-depth conversation about this at the Eclipse Summit in a few weeks.
> ;-) I'm certainly willing to consider adding support for
> java.io.Serializeable directly to EEnumLiteralImpl in EMF if that makes
> folks happy and isn't likely to cause anyone problems. In fact, I'd
> suggested someone open a feature request for generating serializeable
> type safe enums, which they didn't follow up on; perhaps it doesn't make
> sense to do that given that we should be able to generate Java 5.0 enums
> in the next release cycle...
>
>
> Martin Taal wrote:
>> Ed,
>> Thanks for your reply. Comments below, marked with MT>>.
>>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> Comments below.
>>>
>>>
>>> Martin Taal wrote:
>>>> Hi Ed,
>>>> I was expecting that there was more to it.
>>>>
>>>> We are working on using EMF in combination with JSF (Java Server
>>>> Faces) and also Spring Web Flow (so not related to Teneo, although
>>>> it uses it). These frameworks/technologies store state by
>>>> java-serializing the data-objects. Java serializability is also used
>>>> by a number of other frameworks (jboss seam and jboss work flow also
>>>> as I understand).
>>> Yes, many frameworks rely on this. I could certainly imagine an
>>> approach similar to what we did to support java.io.Serializeable when
>>> implement SDO 1.0 on top of EMF. I.e., one could effectively
>>> serialize the whole resource set. What isn't always clear is how
>>> much of the "closure" needs to be serialized, so I'm not sure if such
>>> a brute force, one size fits all solutions is a good thing...
>> MT>> Yes serialization can be very crude (in the end you can serialize
>> the whole jvm heap). But I think that the one who uses java
>> serialization is responsible for determining what is a correct set of
>> data to serialize (by removing references to what not should be
>> serialized). At least that is what the designers of
>> java.io.Serialization thought probably.
>> So (imho) EMF should just support basic java.io.serialization and
>> leave the other part of the problem to the java developer. This is in
>> way different from xml-serialization where EMF offers more control
>> (and therefor has more responsibility I think).
>>
>>>>
>>>> There are different cases:
>>>> > Dynamic EMF
>>>> 1) The DynamicEObjectImpl
>>>> I have my own serializable dynamic eobject impl which is
>>>> java.io.serializable, currently I set my own
>>>> serializableeobjectfactory in the epackage to force the use of this
>>>> serializable dynamiceobject (but this is not a correct approach?).
>>> No, this is not generally a great idea. You should use the extension
>>> point or use the same approach as is used to implement the extension
>>> point.
>>>> 2) the EEnumLiteral: when reading a model directly from a xsd,
>>>> xsdecorebuilder will create EEnumLiterals, in this step I want to
>>>> replace the creation of a standard EEnumLiteral by my serializable
>>>> eenumliteral. I have now done this by overriding the xsdecorebuilder
>>>> and changing two statements. But I did not feel that this was a long
>>>> term sound approach.
>>> Why is EEnumLiteral so special? Is it because all the other data
>>> types are serializeable?
>> MT>> Yes the other base datatypes are serializable and enumliteral is
>> not.
>>
>>>>
>>>> > Generated EMF (java code)
>>>> I can make the generated java code serializable by making minor
>>>> changes to the jet templates. This is workable. Although I would
>>>> prefer to just use a serializable EObject.
>>>>
>>>> As we use emf outside of an eclipse environment I don't think that
>>>> extension-points work.
>>> Extension points only work within an OSGi environment. But the same
>>> approach (registering a descriptor to create the factory) should be
>>> reusable in any environment.
>>>>
>>>> So overall the above would be much easier if for example the EObject
>>>> interface would also extend java.io.Serializable (why not?) and some
>>>> other smaller changes related to using the correct singleton
>>>> enumerate instance.
>>>> But maybe/probably I overlook many things here.
>>> I've been thinking about perhaps supporting java.io.Serializeable in
>>> general within the implementation classes (i.e., BasicEObjectImpl,
>>> ResourceImpl, ResourceSetImpl), but as I said, the closure issue
>>> seems tricky and I need to be sure that whatever we do wouldn't break
>>> clients who might have taken a different approach already
>> MT>> Why not just leave the closure problem to the user of EMF?
>> For me xml serialization and java serialization have different
>> purposes and do not require EMF to offer the same level of control
>> (through resources, containment etc.).
>>
>>>>
>>>>
>>>> gr. Martin
>>>>
>>>> Ed Merks wrote:
>>>>> Martin,
>>>>>
>>>>> No, it must be the case that EcoreFactory.eINSTANCE ==
>>>>> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a
>>>>> reasonable approach. You should use the factory_override extension
>>>>> point to override the factory for a package (so that the actual
>>>>> XyzFactory.eINSTANCE is overridden); a given package can have at
>>>>> most one override in the JVM.
>>>>> I'd like to understand why EEnumLiteralImpl must be serializeable,
>>>>> because this implies to me that only serializeable data types can
>>>>> be supported when that isn't a general restriction for EMF because
>>>>> it uses the createFromString/convertToString for that. If this is
>>>>> absolutely needed to support Teneo, I'd rather do it directly in
>>>>> EMF so that you wouldn't need to override the factory; I know
>>>>> Apache's Tuscany project is using an override of
>>>>> EcoreFactory.eINSTANCE to create DataObjects, and it would be nice
>>>>> if Teneo still worked for that too.
>>>>>
>>>>>
>>>>> Martin Taal wrote:
>>>>>> Hi,
>>>>>> I noticed that the XSDEcoreBuilder uses the EcoreFactory.eINSTANCE
>>>>>> to create eenums (and maybe also other model elements). Would it
>>>>>> be possible to let it use
>>>>>> EcorePackage.eINSTANCE.getEFactoryInstance() instead?
>>>>>>
>>>>>> The reason that I ask is that this makes it possible to override
>>>>>> the default EcoreFactory with our own implementation (by setting
>>>>>> the EcoreFactory in the EcorePackage). We require our own
>>>>>> implementation to make use of our own serializable EEnumLiteral.
>>>>>>
>>>>>> Btw, is overriding EcoreFactory a valid approach in this case?
>>>>>>
>>>>
>>>>
>>
>>


--

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
Re: Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of [message #598803 is a reply to message #69870] Wed, 27 September 2006 07:28 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
Martin,

Our latest coop student is working on AST-based JMerge, which we need to
support Java 5.0 syntax in the generator, while the rest of us
developers (Marcelo, Dave and I) are still working on completing the
second edition of the book. With EMF 2.2.1 development completed today,
we (especially me, because I don't like working on the book!) will
likely start our 3.0 development stream in the next week or two and the
cycle completes on Eclipse's regular yearly cycle that ends each June.


Martin Taal wrote:

> Hi Ed,
> Okay, I am looking forward to an in-depth discussion on
> java.io.serialization and EMF ;-).
>
> When will there be java 5 support in EMF, or when is the next release
> cycle planned?
>
> gr. Martin
>
> Ed Merks wrote:
>
>> Martin,
>>
>> So far I've only considered writePlace in combination with EMF
>> serialization (because this eliminates dependencies on specific
>> implementation classes). I think you're suggesting that just making
>> the object serializeable and letting Java handle it the normal way is
>> fine; I've never tried that and didn't think it would work. (E.g., we
>> don't make transient features transient in the Java sense.) We can
>> have an in-depth conversation about this at the Eclipse Summit in a
>> few weeks. ;-) I'm certainly willing to consider adding support for
>> java.io.Serializeable directly to EEnumLiteralImpl in EMF if that
>> makes folks happy and isn't likely to cause anyone problems. In
>> fact, I'd suggested someone open a feature request for generating
>> serializeable type safe enums, which they didn't follow up on;
>> perhaps it doesn't make sense to do that given that we should be able
>> to generate Java 5.0 enums in the next release cycle...
>>
>>
>> Martin Taal wrote:
>>
>>> Ed,
>>> Thanks for your reply. Comments below, marked with MT>>.
>>>
>>> gr. Martin
>>>
>>> Ed Merks wrote:
>>>
>>>> Martin,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>
>>>>> Hi Ed,
>>>>> I was expecting that there was more to it.
>>>>>
>>>>> We are working on using EMF in combination with JSF (Java Server
>>>>> Faces) and also Spring Web Flow (so not related to Teneo, although
>>>>> it uses it). These frameworks/technologies store state by
>>>>> java-serializing the data-objects. Java serializability is also
>>>>> used by a number of other frameworks (jboss seam and jboss work
>>>>> flow also as I understand).
>>>>
>>>> Yes, many frameworks rely on this. I could certainly imagine an
>>>> approach similar to what we did to support java.io.Serializeable
>>>> when implement SDO 1.0 on top of EMF. I.e., one could effectively
>>>> serialize the whole resource set. What isn't always clear is how
>>>> much of the "closure" needs to be serialized, so I'm not sure if
>>>> such a brute force, one size fits all solutions is a good thing...
>>>
>>> MT>> Yes serialization can be very crude (in the end you can
>>> serialize the whole jvm heap). But I think that the one who uses
>>> java serialization is responsible for determining what is a correct
>>> set of data to serialize (by removing references to what not should
>>> be serialized). At least that is what the designers of
>>> java.io.Serialization thought probably.
>>> So (imho) EMF should just support basic java.io.serialization and
>>> leave the other part of the problem to the java developer. This is
>>> in way different from xml-serialization where EMF offers more
>>> control (and therefor has more responsibility I think).
>>>
>>>>>
>>>>> There are different cases:
>>>>> > Dynamic EMF
>>>>> 1) The DynamicEObjectImpl
>>>>> I have my own serializable dynamic eobject impl which is
>>>>> java.io.serializable, currently I set my own
>>>>> serializableeobjectfactory in the epackage to force the use of
>>>>> this serializable dynamiceobject (but this is not a correct
>>>>> approach?).
>>>>
>>>> No, this is not generally a great idea. You should use the
>>>> extension point or use the same approach as is used to implement
>>>> the extension point.
>>>>
>>>>> 2) the EEnumLiteral: when reading a model directly from a xsd,
>>>>> xsdecorebuilder will create EEnumLiterals, in this step I want to
>>>>> replace the creation of a standard EEnumLiteral by my serializable
>>>>> eenumliteral. I have now done this by overriding the
>>>>> xsdecorebuilder and changing two statements. But I did not feel
>>>>> that this was a long term sound approach.
>>>>
>>>> Why is EEnumLiteral so special? Is it because all the other data
>>>> types are serializeable?
>>>
>>> MT>> Yes the other base datatypes are serializable and enumliteral
>>> is not.
>>>
>>>>>
>>>>> > Generated EMF (java code)
>>>>> I can make the generated java code serializable by making minor
>>>>> changes to the jet templates. This is workable. Although I would
>>>>> prefer to just use a serializable EObject.
>>>>>
>>>>> As we use emf outside of an eclipse environment I don't think that
>>>>> extension-points work.
>>>>
>>>> Extension points only work within an OSGi environment. But the
>>>> same approach (registering a descriptor to create the factory)
>>>> should be reusable in any environment.
>>>>
>>>>>
>>>>> So overall the above would be much easier if for example the
>>>>> EObject interface would also extend java.io.Serializable (why
>>>>> not?) and some other smaller changes related to using the correct
>>>>> singleton enumerate instance.
>>>>> But maybe/probably I overlook many things here.
>>>>
>>>> I've been thinking about perhaps supporting java.io.Serializeable
>>>> in general within the implementation classes (i.e.,
>>>> BasicEObjectImpl, ResourceImpl, ResourceSetImpl), but as I said,
>>>> the closure issue seems tricky and I need to be sure that whatever
>>>> we do wouldn't break clients who might have taken a different
>>>> approach already
>>>
>>> MT>> Why not just leave the closure problem to the user of EMF?
>>> For me xml serialization and java serialization have different
>>> purposes and do not require EMF to offer the same level of control
>>> (through resources, containment etc.).
>>>
>>>>>
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>> Martin,
>>>>>>
>>>>>> No, it must be the case that EcoreFactory.eINSTANCE ==
>>>>>> EcorePackage.eINSTANCE.getEFactoryInstance() so this is not a
>>>>>> reasonable approach. You should use the factory_override
>>>>>> extension point to override the factory for a package (so that
>>>>>> the actual XyzFactory.eINSTANCE is overridden); a given package
>>>>>> can have at most one override in the JVM.
>>>>>> I'd like to understand why EEnumLiteralImpl must be
>>>>>> serializeable, because this implies to me that only serializeable
>>>>>> data types can be supported when that isn't a general restriction
>>>>>> for EMF because it uses the createFromString/convertToString for
>>>>>> that. If this is absolutely needed to support Teneo, I'd rather
>>>>>> do it directly in EMF so that you wouldn't need to override the
>>>>>> factory; I know Apache's Tuscany project is using an override of
>>>>>> EcoreFactory.eINSTANCE to create DataObjects, and it would be
>>>>>> nice if Teneo still worked for that too.
>>>>>>
>>>>>>
>>>>>> Martin Taal wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I noticed that the XSDEcoreBuilder uses the
>>>>>>> EcoreFactory.eINSTANCE to create eenums (and maybe also other
>>>>>>> model elements). Would it be possible to let it use
>>>>>>> EcorePackage.eINSTANCE.getEFactoryInstance() instead?
>>>>>>>
>>>>>>> The reason that I ask is that this makes it possible to override
>>>>>>> the default EcoreFactory with our own implementation (by setting
>>>>>>> the EcoreFactory in the EcorePackage). We require our own
>>>>>>> implementation to make use of our own serializable EEnumLiteral.
>>>>>>>
>>>>>>> Btw, is overriding EcoreFactory a valid approach in this case?
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Previous Topic:Feature request: can XSDEcoreBuilder use EcorePackage.eINSTANCE.getEFactoryInstance() instead of
Next Topic:nested import declaration
Goto Forum:
  


Current Time: Thu Jul 31 20:03:44 EDT 2014

Powered by FUDForum. Page generated in 0.02388 seconds