Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Dali » Restricting certain JPA facet versions for particular runtimes
Restricting certain JPA facet versions for particular runtimes [message #618692] Mon, 18 January 2010 18:34 Go to next message
Leonard Theivendra is currently offline Leonard TheivendraFriend
Messages: 36
Registered: July 2009
Member
Hi, given that org.eclipse.jpt.core (dali 3.0) defines the following runtime extension below, it appears that all jpa facet versions will be available for choice when a user targets any runtime:

<extension point="org.eclipse.wst.common.project.facet.core.runtimes">
<supported>
<runtime-component any="true"/>
<facet id="jpt.jpa"/>
</supported>


Given that adopter extension point definitions listing specific jpa facet versions for particular runtimes will be overridden by the above definition, can this be removed? i.e. if a particular runtime version only supported JPA 1.0, the user will still be able to choose JPA 2.0

Is there a reason why org.eclipse.jpt.core needs to define this as opposed to particular runtime implementation plugins?
Re: Restricting certain JPA facet versions for particular runtimes [message #618697 is a reply to message #618692] Tue, 19 January 2010 18:37 Go to previous messageGo to next message
Paul Fullbright is currently offline Paul FullbrightFriend
Messages: 201
Registered: July 2009
Senior Member
Yes, there is a reason.

JPA works as an SE spec as well as an EE spec, so it's possible to provide your own JPA implementation to the container. A runtime need not *provide* a JPA 2.0 (or any at all) implementation in order for it to be a valid JPA runtime. If it supports Java 5 (and that constraint is captured elsewhere) it's likely able to support this SE/EE JPA use case.

Where the runtime support level comes into play is in the library used for the JPA implementation. When configuring the JPA facet, the user may choose to use the runtime implementation (if the facet versions line up) or provide his own. If using the runtime implementation, then the appropriate JPA libraries contributed by the runtime will show up in the project classpath.

This is all obviously different from EE in general, so there are going to be some use case impedance mismatches, but in general it works fairly well. And that extension point definition is a necessary evil.

If you have problems, though, please do let us know what they are specifically and we can attempt to work through those. Always looking for more use cases ...

- Paul
Re: Restricting certain JPA facet versions for particular runtimes [message #618698 is a reply to message #618697] Tue, 19 January 2010 20:47 Go to previous messageGo to next message
Leonard Theivendra is currently offline Leonard TheivendraFriend
Messages: 36
Registered: July 2009
Member
Hi Paul, ok so let me outline the issues we are seeing:

1) When launching the JPA project creation wizard, for certain runtimes we want to restrict the choices of JPA facet versions (i.e. JPA 1.0 only as opposed to both JPA 1.0 and 2.0 since version X of a particular runtime Y might only support up to JPA 1.0, or no JPA at all, etc)

2) Similarly, once a project is created and the user goes to configure more facets via the project properties, given the runtime chosen, we want to control what JPA facet version choices are shown.

All of this filtering of facet version choices is taken care of by the facet framework in all the wizards and facet config UIs, and each server vendor implementation uses the org.eclipse.wst.common.project.facet.core.runtimes ext point to define what facet versions are supported in their impl plugins. i.e:

<supported>
<runtime-component
id="com.xxx.yyy.runtime"
version="2.0"/>
<facet
id="jpt.jpa"
version="1.0"/>
</supported>

This is similar to what is done for other facets like EJB's jst.ejb, etc.

But since the dali core plugin implements this ext point and allows *any* runtime to add *any* JPA facet version, the more restrictive declarations defined by the runtime vendors are overridden by the <runtime-component any="true"/> part.. and therefore the user can choose for example a JPA 2.0 facet level on a runtime that doesn't support JPA 2.0.

Perhaps there's a problem in the facet framework here in that for a particular runtime component it's configuration of facet choices/versions should override everything else.

I understand your point about a SEE5 capable server being able to support JPA w/o explicitly providing a JPA impl, but I'm trying to figure out how to restrict JPA facet version levels for certain runtimes if we choose to do so.
Re: Restricting certain JPA facet versions for particular runtimes [message #618701 is a reply to message #618698] Tue, 19 January 2010 22:14 Go to previous messageGo to next message
Paul Fullbright is currently offline Paul FullbrightFriend
Messages: 201
Registered: July 2009
Senior Member
I'm not understanding I guess. Are you wanting to restrict choices *beyond* what are valid configurations?

I'm not sure how we could accomplish that with facets. Perhaps with wizard configurations?

A very common use case is to enable JPA on a dynamic web project, and some runtimes that support that use case do not support JEE at all. Without our setup, such a scenario would be impossible.
Re: Restricting certain JPA facet versions for particular runtimes [message #618702 is a reply to message #618692] Wed, 20 January 2010 15:31 Go to previous messageGo to next message
Leonard Theivendra is currently offline Leonard TheivendraFriend
Messages: 36
Registered: July 2009
Member
Basically what we want to do is, if a particular runtime vendor does explicitly provide a JPA implementation, it should be able to control what versions of the JPA facet will be available for choice when the user chooses that runtime as the target in the project creation wizards & project properties UI. This is all handled currently in the facet/server-tools framework/wizards, and all that the runtime vendor needs to do is to configure this extension point.

i.e. if I were to comment out your impl of this extension point in org.eclipse.jpt.core, and also defined the following for my particular runtime server:

<extension point="org.eclipse.wst.common.project.facet.core.runtimes">
<supported>
<runtime-component
id="com.xxx.yyy.runtime"
version="2.0"/>
<facet
id="jpt.jpa"
version="1.0"/>
</supported>

Then when the user launches the new JPA project wizard and chooses my runtime as the target, the wizard will only show the jpa 1.0 facet and associated configurations as available for choice, etc (i.e. the JPA 2.0 facet and configurations will be hidden from view)
Re: Restricting certain JPA facet versions for particular runtimes [message #618704 is a reply to message #618702] Wed, 20 January 2010 16:16 Go to previous messageGo to next message
Paul Fullbright is currently offline Paul FullbrightFriend
Messages: 201
Registered: July 2009
Senior Member
So do you want to completely eliminate the possibility of users running, for instance, a web app with a third party JPA implementation, such as Hibernate or EclipseLink?

a) I'm not sure that's something you *should* be doing. But I guess that's up to you.

b) That's completely outside the scope of Dali. We *have* to have this, or else runtimes that don't provide JPA implementations will also have to say that they support JPA, just so users who *are* providing their own implementation can enable a JPA application on that runtime.

What this sounds like is a facets problem. There is a no difference in the facets world between "enablement" (*has* it) and "compatibility" (can *work* with it). An EJB 2.0 enabled runtime is also an EJB 2.0 compatible runtime. A Java 5 compatible runtime is also a Java 5 enabled runtime. But a JPA compatible runtime is not the same thing as a JPA enabled runtime. The way that facets work now, in order for us to support use cases, we have to treat all runtimes as JPA compatible (and if they're Java 5 compatible, they're JPA compatible) because the interpretation of the runtime spec is that facets define enablement. A web server would never specify that it supports the JPA facet, since it has no libraries for the JPA facet. But it is (potentially) compatible with the JPA facet.

If a runtime had two sets of facets: those that it provides, and those that it is compatible with, then both our problems would be solveable, but that is currently not the case.

Or alternatively, if a runtime could specify *overrides*, those facets (versions) that it specifically does not support, then that would also solve our problem. That is currently also unavailable.

As it stands, I do not see how we can make this change to our facet definition to support your use case without also unsupporting some of our core use cases.

I'd support change requests to the facets framework to address this problem.
Re: Restricting certain JPA facet versions for particular runtimes [message #618705 is a reply to message #618692] Wed, 20 January 2010 19:18 Go to previous message
Leonard Theivendra is currently offline Leonard TheivendraFriend
Messages: 36
Registered: July 2009
Member
Hi Paul thanks for your input. Yes this is looking more like an issue best fixed in the facet framework (at the very least specific runtime vendors should be able to override behaviour if they choose to do so, and perhaps a larger scale change of allowing multiple types of runtime targetting, etc)

Will pursue with that team and keep you in the loop on any enhancement requests/bugzillas I open. Let me know if any were already opened by Dali against the facet framework in this area.
Previous Topic:Re: Eclipse JPA project - defining connection to Oracle RAC
Next Topic:Re: Restricting certain JPA facet versions for particular runtimes
Goto Forum:
  


Current Time: Wed Sep 26 10:33:20 GMT 2018

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

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

Back to the top