Eclipse Community Forums: Dali » Generating Interfaces

Home » Eclipse Projects » Dali » Generating Interfaces

Tue, 01 April 2008 14:59

Eclipse User

Probably the biggest thing I need to handle in my JPA implementation
that is nonstandard (and therefore not handled by Dali) is to generate
interfaces, rather than classes, as the JPA-annotated types.

I'm not sure where JPA 2.0 comes down on this -- I had talked to Linda
DeMichiel about this around JavaOne time last year, and it sounded like
support of interfaces was something that would be considered. It
doesn't appear the spec is out for public review yet, so I have no idea
whether that made it in.

So, my questions are how can I implement this, and is it of any interest
to the Dali community to have it contributed back? I think the second
question is important in knowing how to answer the first.

It doesn't look like the API provides a way to substitute for the
included PackageGenerator and EntityGenerator classes. If interface
support is not going to be of interest to anyone but me, I will need
some way to replace the EntityGenerator with my own class.

If interface support is generally useful, then I can add an option for
that in the wizard, and a boolean in EntityGenerator.Config that would
then control code generation accordingly.

I haven't gotten much further than this in seeing how extensive the
changes would be to the code generation, but these seem like the first
questions that I need to figure out.

(By the way, if anyone is attending JavaOne and has any interest in
hearing what we're doing, check out session TS-7550, 'Introducing
eBay's Scalable Innovation Platform'). Only a part of that
talk is concerned with the JPA/database stuff, but it should be a
good overview to how we're using JPA here)

Thanks,
Mike

Re: Generating Interfaces [message #434838 is a reply to message #434835]

Fri, 04 April 2008 15:00

Eclipse User

Hi Mike,

Sorry for the delay in response. We wanted to get the scoop on 2.0
changes that might be related here, and as a result, this briefly went off
of my radar.

At the moment, there aren't any plans to support the annotation of
Interfaces in 2.0. As a result, it probably isn't something that we would
need as a contribution, at least not in the near future.

As for the implementation, you would need to write your own Entity
Generator and possibly UI. The only extension provided in this area is to
implement the generateEntities(...) method in your JpaPlatformUI
implementation, which would allow you to call your own Entity Generator
UI. So, when the user chooses to generate Entities from the JPA Tools
menu, they will be getting your wizard, which can call whatever generation
code you want it to (assuming of course that they are using your
Platform).

Hope this helps,

Neil

Mike Yawn wrote:

> Probably the biggest thing I need to handle in my JPA implementation
> that is nonstandard (and therefore not handled by Dali) is to generate
> interfaces, rather than classes, as the JPA-annotated types.

> I'm not sure where JPA 2.0 comes down on this -- I had talked to Linda
> DeMichiel about this around JavaOne time last year, and it sounded like
> support of interfaces was something that would be considered. It
> doesn't appear the spec is out for public review yet, so I have no idea
> whether that made it in.

> So, my questions are how can I implement this, and is it of any interest
> to the Dali community to have it contributed back? I think the second
> question is important in knowing how to answer the first.

> It doesn't look like the API provides a way to substitute for the
> included PackageGenerator and EntityGenerator classes. If interface
> support is not going to be of interest to anyone but me, I will need
> some way to replace the EntityGenerator with my own class.

> If interface support is generally useful, then I can add an option for
> that in the wizard, and a boolean in EntityGenerator.Config that would
> then control code generation accordingly.

> I haven't gotten much further than this in seeing how extensive the
> changes would be to the code generation, but these seem like the first
> questions that I need to figure out.

> (By the way, if anyone is attending JavaOne and has any interest in
> hearing what we're doing, check out session TS-7550, 'Introducing
> eBay's Scalable Innovation Platform'). Only a part of that
> talk is concerned with the JPA/database stuff, but it should be a
> good overview to how we're using JPA here)

> Thanks,
> Mike

Re: Generating Interfaces [message #434841 is a reply to message #434838]

Fri, 04 April 2008 16:26

Eclipse User

Neil,

Thanks for the response.

I've been looking into hooking into JpaPlatformUI.generateEntities(), as
you suggest.

It seems like I'd probably end up copying over a lot of code that would
end up being only slightly modified -- EntitiesGenerator, the
GenerateEntitiesWizard, PackageGenerator, EntityGenerator, GenTable,
GenScope, probably others (it seems like a lot of the stuff in
org.eclipse.jpt.gen.internal would end up being largely duplicated as
well). Obviously there's no real requirement that I follow the
structure of the existing codegen, but I'd like to minimize the
maintenance burden in the future, and it seems like the more I follow
what is there, the easier it will be to evaluate 2.0 changes (or other
updates) to see what similar updates should be applied in my code. For
the same reason, I'd rather extend those classes that do large-scale cut
and paste; they're not API, obviously, but I'm curious as to what you
think about approaching it that way.

I'm not sure I have any suggestion of how it might be easier to support
dropping in a different EntityGenerator, but it would be nice to be able
to leverage some of the existing code generation stuff.

If I end up completely replacing all of the codegen, it would at least
be nice to use all of the O/R mapping stuff that Dali has already
figured out. Some if this is in Table, which is API, but the GenTable
is not, and I think a lot of what Dali has figured out as far as the
mappings is not easily API-accessible (or I just haven't figured out the
right way to do that yet).

For the moment, I'm taking some tentative steps along the path of
subclassing some of the internal implementation classes, starting with
EntitiesGenerator.

Thanks,
Mike

Neil Hauge wrote:
> Hi Mike,
>
> Sorry for the delay in response. We wanted to get the scoop on 2.0
> changes that might be related here, and as a result, this briefly went
> off of my radar.
>
> At the moment, there aren't any plans to support the annotation of
> Interfaces in 2.0. As a result, it probably isn't something that we
> would need as a contribution, at least not in the near future.
>
> As for the implementation, you would need to write your own Entity
> Generator and possibly UI. The only extension provided in this area is
> to implement the generateEntities(...) method in your JpaPlatformUI
> implementation, which would allow you to call your own Entity Generator
> UI. So, when the user chooses to generate Entities from the JPA Tools
> menu, they will be getting your wizard, which can call whatever
> generation code you want it to (assuming of course that they are using
> your Platform).
> Hope this helps,
>
> Neil
>
>
> Mike Yawn wrote:
>
>> Probably the biggest thing I need to handle in my JPA implementation
>> that is nonstandard (and therefore not handled by Dali) is to generate
>> interfaces, rather than classes, as the JPA-annotated types.
>
>> I'm not sure where JPA 2.0 comes down on this -- I had talked to Linda
>> DeMichiel about this around JavaOne time last year, and it sounded
>> like support of interfaces was something that would be considered. It
>> doesn't appear the spec is out for public review yet, so I have no
>> idea whether that made it in.
>
>> So, my questions are how can I implement this, and is it of any
>> interest to the Dali community to have it contributed back? I think
>> the second question is important in knowing how to answer the first.
>
>> It doesn't look like the API provides a way to substitute for the
>> included PackageGenerator and EntityGenerator classes. If interface
>> support is not going to be of interest to anyone but me, I will need
>> some way to replace the EntityGenerator with my own class.
>
>> If interface support is generally useful, then I can add an option for
>> that in the wizard, and a boolean in EntityGenerator.Config that would
>> then control code generation accordingly.
>
>> I haven't gotten much further than this in seeing how extensive the
>> changes would be to the code generation, but these seem like the first
>> questions that I need to figure out.
>
>> (By the way, if anyone is attending JavaOne and has any interest in
>> hearing what we're doing, check out session TS-7550, 'Introducing
>> eBay's Scalable Innovation Platform'). Only a part of that
>> talk is concerned with the JPA/database stuff, but it should be a
>> good overview to how we're using JPA here)
>
>> Thanks,
>> Mike
>
>

Re: Generating Interfaces [message #434843 is a reply to message #434841]

Tue, 08 April 2008 17:45

Eclipse User

I've got a start on this -- generating the interface and the primary key
fields so far.

I notice a couple of things that I'm not sure about. The behavior on
these is the same between the Dali-standard EntityGenerator and the
entity generator I'm plugging in, so it must be a configuration issue
rather than something with the code I've added.

In a generated entity file:
- The @Entity annotation is flagged as in error, saying
Schema "null" cannot be resolved for table "Category"
that happens on all tables, with either my code generator or the
standard one.

- All column names (if there is no @Column annotation) or @Column name
attributes are flagged as errors saying
Colunn "<colname>" cannot be resolved

Any ideas what I may have misconfigured or otherwise messed up?

Another issue: When I set the platform (Under the JPA preferences pane)
to Generic or EclipseLink, that setting is remembered. But when I set
it to my platform string (DAL 3.0), if I close the preferences pane and
re-open it the platform is unset (shows blank).

Any suggestions would be appreciated!

Thanks,
Mike

Mike Yawn wrote:
> Neil,
>
> Thanks for the response.
>
> I've been looking into hooking into JpaPlatformUI.generateEntities(), as
> you suggest.
>
> It seems like I'd probably end up copying over a lot of code that would
> end up being only slightly modified -- EntitiesGenerator, the
> GenerateEntitiesWizard, PackageGenerator, EntityGenerator, GenTable,
> GenScope, probably others (it seems like a lot of the stuff in
> org.eclipse.jpt.gen.internal would end up being largely duplicated as
> well). Obviously there's no real requirement that I follow the
> structure of the existing codegen, but I'd like to minimize the
> maintenance burden in the future, and it seems like the more I follow
> what is there, the easier it will be to evaluate 2.0 changes (or other
> updates) to see what similar updates should be applied in my code. For
> the same reason, I'd rather extend those classes that do large-scale cut
> and paste; they're not API, obviously, but I'm curious as to what you
> think about approaching it that way.
>
> I'm not sure I have any suggestion of how it might be easier to support
> dropping in a different EntityGenerator, but it would be nice to be able
> to leverage some of the existing code generation stuff.
>
> If I end up completely replacing all of the codegen, it would at least
> be nice to use all of the O/R mapping stuff that Dali has already
> figured out. Some if this is in Table, which is API, but the GenTable
> is not, and I think a lot of what Dali has figured out as far as the
> mappings is not easily API-accessible (or I just haven't figured out the
> right way to do that yet).
>
> For the moment, I'm taking some tentative steps along the path of
> subclassing some of the internal implementation classes, starting with
> EntitiesGenerator.
>
>
> Thanks,
> Mike
>
>
> Neil Hauge wrote:
>> Hi Mike,
>>
>> Sorry for the delay in response. We wanted to get the scoop on 2.0
>> changes that might be related here, and as a result, this briefly went
>> off of my radar.
>>
>> At the moment, there aren't any plans to support the annotation of
>> Interfaces in 2.0. As a result, it probably isn't something that we
>> would need as a contribution, at least not in the near future.
>>
>> As for the implementation, you would need to write your own Entity
>> Generator and possibly UI. The only extension provided in this area
>> is to implement the generateEntities(...) method in your JpaPlatformUI
>> implementation, which would allow you to call your own Entity
>> Generator UI. So, when the user chooses to generate Entities from the
>> JPA Tools menu, they will be getting your wizard, which can call
>> whatever generation code you want it to (assuming of course that they
>> are using your Platform). Hope this helps,
>>
>> Neil
>>
>>
>> Mike Yawn wrote:
>>
>>> Probably the biggest thing I need to handle in my JPA implementation
>>> that is nonstandard (and therefore not handled by Dali) is to
>>> generate interfaces, rather than classes, as the JPA-annotated types.
>>
>>> I'm not sure where JPA 2.0 comes down on this -- I had talked to
>>> Linda DeMichiel about this around JavaOne time last year, and it
>>> sounded like support of interfaces was something that would be
>>> considered. It doesn't appear the spec is out for public review yet,
>>> so I have no idea whether that made it in.
>>
>>> So, my questions are how can I implement this, and is it of any
>>> interest to the Dali community to have it contributed back? I think
>>> the second question is important in knowing how to answer the first.
>>
>>> It doesn't look like the API provides a way to substitute for the
>>> included PackageGenerator and EntityGenerator classes. If interface
>>> support is not going to be of interest to anyone but me, I will need
>>> some way to replace the EntityGenerator with my own class.
>>
>>> If interface support is generally useful, then I can add an option
>>> for that in the wizard, and a boolean in EntityGenerator.Config that
>>> would then control code generation accordingly.
>>
>>> I haven't gotten much further than this in seeing how extensive the
>>> changes would be to the code generation, but these seem like the
>>> first questions that I need to figure out.
>>
>>> (By the way, if anyone is attending JavaOne and has any interest in
>>> hearing what we're doing, check out session TS-7550, 'Introducing
>>> eBay's Scalable Innovation Platform'). Only a part of that
>>> talk is concerned with the JPA/database stuff, but it should be a
>>> good overview to how we're using JPA here)
>>
>>> Thanks,
>>> Mike
>>
>>

Re: Generating Interfaces [message #434845 is a reply to message #434843]

Wed, 09 April 2008 11:21

Eclipse User

Hi Mike,

Take a look at this bug, it explains some of the issues surrounding
setting a schema on a JPA project:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=195095

> Another issue: When I set the platform (Under the JPA preferences pane)
> to Generic or EclipseLink, that setting is remembered. But when I set
> it to my platform string (DAL 3.0), if I close the preferences pane and
> re-open it the platform is unset (shows blank).

I am not sure what is going on here, are there any errors in the error
log? Maybe take a look in the debugger in JpaProjectPropertiesPage line
184 where it calls JpaModelManager.instance().rebuildJpaProject(project);
You could try to see if the new platform is actually getting set. Also,
do your JpaPlatformUi extension point and JpaPlatform extension point have
ids that match?

Karen

Re: Generating Interfaces [message #434847 is a reply to message #434845]

Wed, 09 April 2008 17:53

Eclipse User

Karen Butzke wrote:
> Also, do your
> JpaPlatformUi extension point and JpaPlatform extension point have ids
> that match?

They did not (had an extra .ui. in the id of the JpaPlatformUi
extension). Once I changed that, my selection is now being remembered.

Thanks!
Mike

Re: Generating Interfaces [message #434849 is a reply to message #434847]

Thu, 10 April 2008 13:24

Eclipse User

Mike Yawn wrote:

> Karen Butzke wrote:
>> Also, do your
>> JpaPlatformUi extension point and JpaPlatform extension point have ids
>> that match?

> They did not (had an extra .ui. in the id of the JpaPlatformUi
> extension). Once I changed that, my selection is now being remembered.

> Thanks!
> Mike

This is actually something I've been meaning to change (just entered bug
226570). You should be able to have a different id for each and then the
JpaPlatformUi just needs an extra setting for jpaPlatformId. Then you
would be able to put your extra .ui on the JpaPlatformUi extension point.
I also thought we logged an error message for this use case, but maybe
that was in the 1.0 release and has disappeared recently. If we decide to
change these extension points (which is probably unlikely at this late
date in 2.0) we will certainly make it public before doing so. Though it
would probably be easy enough to ensure that the old support works by not
requiring the new jpaPlatformId setting.

thanks,
Karen

Parsing Interfaces [message #434850 is a reply to message #434849]

Mon, 14 April 2008 16:34

Eclipse User

I think I have the code generation working (although I need to run it
through a lot more test cases to verify that).

I'm a little unclear on how things work in the other direction -- when I
click on a location in the Java editor, how is it communicating back
to Dali what nodes to select in the JPA Details and JPA Structure views?

I seem to have broken something here. Simple properties, for the most
part, are working, but associations (ManyToOne, OneToMany) aren't shown
in the either the Details or Structure views, so something about the
code I've generated is not parsing correctly. (I've changed the
collection type from Set to List but that's about the only change).

Can someone suggest what classes to study to get an understanding of how
the editor is connected to the Dali views?

I'm also going to be adding additional code to support some of our own
(non-JPA annotations); I'll also need to be able to communicate to the
model when these are seen in the edited source.

Thanks,
Mike

Re: Parsing Interfaces [message #434854 is a reply to message #434850]

Mon, 14 April 2008 17:40

Eclipse User

Mike,

Could you post an example type that does not display the associations in
the structure view?

Karen

Re: Parsing Interfaces [message #434856 is a reply to message #434854]

Mon, 14 April 2008 18:06

Eclipse User

This is a multi-part message in MIME format.
--------------060600080102060800060407
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Karen Butzke wrote:
> Mike,
>
> Could you post an example type that does not display the associations in
> the structure view?
>
> Karen
>
If the attachments don't come through I'll repost as text . . .

In both cases, the association fields (ManyToOne and OneToMany) are the
only ones which aren't showing up in the structure and details views.

Thanks,
Mike

--------------060600080102060800060407
Content-Type: text/plain;
name="Category.java"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="Category.java"

cGFja2FnZSBkZWRlLmFydGlmYWN0czsNCg0KaW1wb3J0IGphdmF4LnBlcnNp c3RlbmNlLkVu
dGl0eTsNCmltcG9ydCBqYXZheC5wZXJzaXN0ZW5jZS5JZDsNCmltcG9ydCBq YXZhLmxhbmcu
U3RyaW5nOw0KaW1wb3J0IGphdmEudXRpbC5MaXN0Ow0KaW1wb3J0IGphdmEu dXRpbC5TZXQ7
DQoNCmltcG9ydCBqYXZheC5wZXJzaXN0ZW5jZS5PbmVUb01hbnk7DQppbXBv cnQgamF2YXgu
cGVyc2lzdGVuY2UuVGFibGU7DQoNCkBFbnRpdHkNCkBUYWJsZShzY2hlbWE9 ImNvb2tib29r
IikNCnB1YmxpYyBpbnRlcmZhY2UgQ2F0ZWdvcnkgew0KCUBJZA0KCXB1Ymxp YyBpbnQgZ2V0
SWQoKTsNCg0KCXB1YmxpYyB2b2lkIHNldElkKGludCBpZCk7DQoNCglwdWJs aWMgU3RyaW5n
IGdldFRpdGxlKCk7DQoNCglwdWJsaWMgdm9pZCBzZXRUaXRsZShTdHJpbmcg dGl0bGUpOw0K
DQoJQE9uZVRvTWFueShtYXBwZWRCeSA9ICJjYXRlZ29yeSIpDQoJcHVibGlj IFNldDxSZWNp
cGU+IGdldFJlY2lwZUNvbGxlY3Rpb24oKTsNCn0=
--------------060600080102060800060407
Content-Type: text/plain;
name="Recipe.java"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="Recipe.java"

cGFja2FnZSBkZWRlLmFydGlmYWN0czsNCg0KaW1wb3J0IGphdmF4LnBlcnNp c3RlbmNlLkVu
dGl0eTsNCmltcG9ydCBqYXZheC5wZXJzaXN0ZW5jZS5JZDsNCmltcG9ydCBq YXZhLmxhbmcu
U3RyaW5nOw0KaW1wb3J0IGphdmF4LnBlcnNpc3RlbmNlLkxvYjsNCmltcG9y dCBqYXZhLnV0
aWwuRGF0ZTsNCmltcG9ydCBqYXZheC5wZXJzaXN0ZW5jZS5Db2x1bW47DQpp bXBvcnQgamF2
YXgucGVyc2lzdGVuY2UuTWFueVRvT25lOw0KaW1wb3J0IGphdmF4LnBlcnNp c3RlbmNlLlRh
YmxlOw0KDQpARW50aXR5DQpAVGFibGUoc2NoZW1hPSJjb29rYm9vayIpDQpw dWJsaWMgaW50
ZXJmYWNlIFJlY2lwZSB7DQoJQElkDQoJcHVibGljIGludCBnZXRJZCgpOw0K DQoJcHVibGlj
IHZvaWQgc2V0SWQoaW50IGlkKTsNCg0KCXB1YmxpYyBTdHJpbmcgZ2V0VGl0 bGUoKTsNCg0K
CXB1YmxpYyB2b2lkIHNldFRpdGxlKFN0cmluZyB0aXRsZSk7DQoNCglwdWJs aWMgU3RyaW5n
IGdldERlc2NyaXB0aW9uKCk7DQoNCglwdWJsaWMgdm9pZCBzZXREZXNjcmlw dGlvbihTdHJp
bmcgZGVzY3JpcHRpb24pOw0KDQoJQExvYg0KCXB1YmxpYyBTdHJpbmcgZ2V0 SW5zdHJ1Y3Rp
b24oKTsNCg0KCXB1YmxpYyB2b2lkIHNldEluc3RydWN0aW9uKFN0cmluZyBp bnN0cnVjdGlv
bik7DQoNCglwdWJsaWMgRGF0ZSBnZXREYXRlKCk7DQoNCglwdWJsaWMgdm9p ZCBzZXREYXRl
KERhdGUgZGF0ZSk7DQoNCglwdWJsaWMgaW50IGdldFByZXB0aW1lKCk7DQoN CglwdWJsaWMg
dm9pZCBzZXRQcmVwdGltZShpbnQgcHJlcHRpbWUpOw0KDQoJcHVibGljIFN0 cmluZyBnZXRM
b3djYWxvcmllKCk7DQoNCglwdWJsaWMgdm9pZCBzZXRMb3djYWxvcmllKFN0 cmluZyBsb3dj
YWxvcmllKTsNCg0KCXB1YmxpYyBTdHJpbmcgZ2V0RmlsZXVuZGVyKCk7DQoN CglwdWJsaWMg
dm9pZCBzZXRGaWxldW5kZXIoU3RyaW5nIGZpbGV1bmRlcik7DQoNCglwdWJs aWMgRGF0ZSBn
ZXRMYXN0bW9kaWZpZWQoKTsNCg0KCXB1YmxpYyB2b2lkIHNldExhc3Rtb2Rp ZmllZChEYXRl
IGxhc3Rtb2RpZmllZCk7DQoNCglwdWJsaWMgaW50IGdldE9wdGxvY2soKTsN Cg0KCXB1Ymxp
YyB2b2lkIHNldE9wdGxvY2soaW50IG9wdGxvY2spOw0KDQoJQENvbHVtbihu YW1lID0gImVu
dW1faW50IikNCglwdWJsaWMgaW50IGdldEVudW1JbnQoKTsNCg0KCXB1Ymxp YyB2b2lkIHNl
dEVudW1JbnQoaW50IGVudW1JbnQpOw0KDQoJQENvbHVtbihuYW1lID0gImVu dW1fc3RyaW5n
IikNCglwdWJsaWMgU3RyaW5nIGdldEVudW1TdHJpbmcoKTsNCg0KCXB1Ymxp YyB2b2lkIHNl
dEVudW1TdHJpbmcoU3RyaW5nIGVudW1TdHJpbmcpOw0KDQoJQE1hbnlUb09u ZQ0KCXB1Ymxp
YyBDYXRlZ29yeSBnZXRDYXRlZ29yeSgpOw0KDQoJcHVibGljIHZvaWQgc2V0 Q2F0ZWdvcnko
Q2F0ZWdvcnkgY2F0ZWdvcnkpOw0KfQ==
--------------060600080102060800060407--

Re: Parsing Interfaces [message #434858 is a reply to message #434856]

Mon, 14 April 2008 21:45

Eclipse User

Hi Mike,

I had the feeling this was the problem, you don't have a corresponding
setter for the Collection getter. The JPA spec expects there to be a
setter that matches, so we are filtering. I have thought about this type
of filtering in the past and have come to the conclusion there are cases
where we should be using validation instead of filtering things out of the
model. With validation we could give an error for this case rather than
the user just wondering why their mapping isn't appearing. And in your
case, where you might not want a setter, you could not add that validation
error. Could you enter a bug for this case? And if you want to see the
code, take a look at
JPTTools.methodIsPersistablePropertyGetter(IMethodBinding)

thanks,
Karen

Re: Parsing Interfaces [message #434860 is a reply to message #434858]

Tue, 15 April 2008 12:15

Eclipse User

Karen Butzke wrote:
> Hi Mike,
>
> I had the feeling this was the problem, you don't have a corresponding
> setter for the Collection getter. The JPA spec expects there to be a
> setter that matches, so we are filtering. I have thought about this
> type of filtering in the past and have come to the conclusion there are
> cases where we should be using validation instead of filtering things
> out of the model. With validation we could give an error for this case
> rather than the user just wondering why their mapping isn't appearing.
> And in your case, where you might not want a setter, you could not add
> that validation error. Could you enter a bug for this case? And if you
> want to see the code, take a look at
> JPTTools.methodIsPersistablePropertyGetter(IMethodBinding)
>
> thanks,
> Karen
>

Bug 227160 filed.

Re: Generating Interfaces [message #609906 is a reply to message #434835]

Fri, 04 April 2008 15:00

Eclipse User