Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Generated interfaces
Generated interfaces [message #431131] Mon, 29 June 2009 21:47 Go to next message
Jason Henriksen is currently offline Jason HenriksenFriend
Messages: 231
Registered: July 2009
Senior Member
Hi all,

I came to a odd surprise today. I'm using EMF in an OSGI like
environment where the interfaces need to be in a separate class loader
from the implementations. I was very surprised to be reminded that the
generated interface contain a reference to the default implementations!
And it's not enough to just null out the interface variable, you
also have to change the constructor of the Impl not to reference the
variable in the interface.

Has that been updated already? I'm still on EMF 2.4.2 so I know I'm
quite a bit behind. But I thought I'd ask since it seems like an odd
choice. For now, I'm just fixing my local JET templates.

Thanks,

Jason
Re: Generated interfaces [message #431133 is a reply to message #431131] Mon, 29 June 2009 23:07 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30692
Registered: July 2009
Senior Member
Jason,

Comments below.

jason henriksen wrote:
> Hi all,
>
> I came to a odd surprise today. I'm using EMF in an OSGI like
> environment where the interfaces need to be in a separate class loader
> from the implementations.
That's your requirement?
> I was very surprised to be reminded that the generated interface
> contain a reference to the default implementations!
XyzPackage.eINSTANCE you mean? It calls a static method that uses the
registry would could in fact yield an override.
> And it's not enough to just null out the interface variable, you
> also have to change the constructor of the Impl not to reference the
> variable in the interface.
Which Impl?
>
> Has that been updated already?
You could answer that yourself right? With the obvious answer being of
course not, it's the way it's designed to work.
> I'm still on EMF 2.4.2 so I know I'm quite a bit behind. But I
> thought I'd ask since it seems like an odd choice. For now, I'm just
> fixing my local JET templates.
You've been pretty vague so far. Of course it's been this way always,
so I'm not sure why you'd expect it to change...
>
> Thanks,
>
> Jason
Re: Generated interfaces [message #431134 is a reply to message #431133] Mon, 29 June 2009 23:27 Go to previous messageGo to next message
Jason Henriksen is currently offline Jason HenriksenFriend
Messages: 231
Registered: July 2009
Senior Member
Ed Merks wrote:
> Jason,
>
> Comments below.
>
> jason henriksen wrote:
>> Hi all,
>>
>> I came to a odd surprise today. I'm using EMF in an OSGI like
>> environment where the interfaces need to be in a separate class loader
>> from the implementations.
> That's your requirement?
>> I was very surprised to be reminded that the generated interface
>> contain a reference to the default implementations!
> XyzPackage.eINSTANCE you mean? It calls a static method that uses the
> registry would could in fact yield an override.
>> And it's not enough to just null out the interface variable, you
>> also have to change the constructor of the Impl not to reference the
>> variable in the interface.
> Which Impl?
>>
>> Has that been updated already?
> You could answer that yourself right? With the obvious answer being of
> course not, it's the way it's designed to work.
>> I'm still on EMF 2.4.2 so I know I'm quite a bit behind. But I
>> thought I'd ask since it seems like an odd choice. For now, I'm just
>> fixing my local JET templates.
> You've been pretty vague so far. Of course it's been this way always,
> so I'm not sure why you'd expect it to change...
>>
>> Thanks,
>>
>> Jason

Sorry, Ed. It's actually the .INSTANCE member that appears in the
FooPackage interface, not the .eINSTANCE that appears in the
FooPackageImpl. I think I got confused because it seems to be an
artifact of using the SDO generation style.

Anyways, sorry to be a bother. I was mostly just wondering why an
interface would ever want a member that refers to a specific impl class
and if there was some sage reason for it that I hadn't grasped yet.

Jason
Re: Generated interfaces [message #431136 is a reply to message #431134] Tue, 30 June 2009 01:02 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30692
Registered: July 2009
Senior Member
Jason,

Given that nature of XyzPackage, i.e., the description of the model,
it's hard to imagine how there could be alternatives. XyzFactory is a
slightly different story, but consider the possibilities for how one
would get at the default instance. Is there anything other than a class
with a method that returns it? I.e., something just like the
XyzFactoryImpl's init method()? A call to a registry perhaps which
must return a generic result which is cast? Given it wasn't a design
point to specify a different factory nor to separate the bundles for the
interfaces and the implementations, we simply generated the simplest
thing...


jason henriksen wrote:
> Ed Merks wrote:
>> Jason,
>>
>> Comments below.
>>
>> jason henriksen wrote:
>>> Hi all,
>>>
>>> I came to a odd surprise today. I'm using EMF in an OSGI like
>>> environment where the interfaces need to be in a separate class
>>> loader from the implementations.
>> That's your requirement?
>>> I was very surprised to be reminded that the generated interface
>>> contain a reference to the default implementations!
>> XyzPackage.eINSTANCE you mean? It calls a static method that uses
>> the registry would could in fact yield an override.
>>> And it's not enough to just null out the interface variable, you
>>> also have to change the constructor of the Impl not to reference the
>>> variable in the interface.
>> Which Impl?
>>>
>>> Has that been updated already?
>> You could answer that yourself right? With the obvious answer being
>> of course not, it's the way it's designed to work.
>>> I'm still on EMF 2.4.2 so I know I'm quite a bit behind. But I
>>> thought I'd ask since it seems like an odd choice. For now, I'm
>>> just fixing my local JET templates.
>> You've been pretty vague so far. Of course it's been this way
>> always, so I'm not sure why you'd expect it to change...
>>>
>>> Thanks,
>>>
>>> Jason
>
> Sorry, Ed. It's actually the .INSTANCE member that appears in the
> FooPackage interface, not the .eINSTANCE that appears in the
> FooPackageImpl. I think I got confused because it seems to be an
> artifact of using the SDO generation style.
>
> Anyways, sorry to be a bother. I was mostly just wondering why an
> interface would ever want a member that refers to a specific impl
> class and if there was some sage reason for it that I hadn't grasped yet.
>
> Jason
Previous Topic:[EMF Databinding] Properly disposing of observables?
Next Topic:CDO 2.0 multiple repositories using one cdo server with one database
Goto Forum:
  


Current Time: Thu Dec 12 20:58:19 GMT 2019

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

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

Back to the top