|Re: Restricting certain JPA facet versions for particular runtimes [message #618698 is a reply to message #618697]
||Tue, 19 January 2010 20:47
| Leonard Theivendra
Registered: July 2009
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:
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 #618704 is a reply to message #618702]
||Wed, 20 January 2010 16:16
| Paul Fullbright
Registered: July 2009
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.
Powered by FUDForum
. Page generated in 0.02488 seconds