Implementation of J2eePlatform#isToolSupported has been changed lately, now it
returns true for all persistence providers whereas it used to return false for
others than TopLink. Ideally, it should behave like JBoss plugin (see issue
76398), but if that is not doable for 5.5, it would be better to return false
for others than TopLink. Now that it returns true, we let the user to choose
also Hibernate or Kodo on GlassFish even if they don't exist on the server nor
in the project's classpath.
It is possible to setup glassfish to use Hibernate as persistence provider.
There is a tech article/nlog on java.net for this. The Appserver persistence
team indiacted that they would like the list to provide all the available
The approach used by Jboss plugin is not suffecient because that will work only
when the server is installed locally. There is no way of figuring out if a
connected remote server supports a persistence provider.
Yes, it is of course possible to use Hibernate on GF, and it was possible
before the implementation of the method was changed as we scan the project
libraries for additional persistence providers. From my point of view, it would
be nice if server plugins could behave consistently - it is an API method after
all. From the user's perspective, I find it rather confusing that you can
choose any persistence provider even though they don't exist on server nor in
the project libraries. As this behaviour is different from what was discussed
when developing the UI, I would like get Jano's opionion this.
I see Nitya's point. OTOH, I'm not sure that returning "true" for isToolSupported is the right solution.
The idea for showing only "configured" persistence providers was to let the user select only those that
are ready to work on the app server (put the remote server aside for now). With showing Hibernate in
the combo box, we might give the user a false impression that Hibernate is *included* in the app
server, which might cause surprise when build/run doesn't work properly. I understand we don't want
to give the user a false impression that only TopLink can be used with the app server. I suggest the
* Local app server instance:
Show all supported providers in the combo box. The configured providers are shown in "black". Those
not configured on the app server yet are shown in "gray". If the user selects a black one, everything
works as now. If the user selects a gray one, we show up a warning with a link to instructions (help
page?) how to configure specific persistence provider on the app server. We probably should not let the
user proceed until she/he configures the app server.
* Remote instance:
Show all supported providers in the combo box in black color. If the user selects provider other than
TopLink, we show a warning message saying something like "Make sure the TopLink is configured on
the server and add it to classpath of your project." or something similar. I don't know all the library/app
server configuration the user needs to do in order to make it work properly with remote server.
Okay? Too big change for 5.5?
BTW, do we still require a local installation of app server even if the user uses a remote server? Maybe
we should require that the user configures the persistence provider with the local instance even if she/
he uses a remote server.
Thechanges in teh color of the deployed list, if done, will need to happen on
the IDE side of things. The plugin does not generate the list.
All the providers were included after discussion with the appserver team.
Searching for jar installations to add additional items in the list is not the
best solution and there is no need for everyone to do that.
Yes, a local server installation is still required to be able to connect
remotely and no, forcing the user to configure persistence providers in the
lcoal machine just to use it in the remote case is not a valid implementation.
Again, this issue is a Will Not Fix.
Definitely RFE now. We do not disallow this as before. Now whether we can fully
detect that hibernate is correctly configured on the server side cannot be done
100%: the framework could be in the deployed web app, in the lib dir of the
server, or anywhere the user could decide, in different jar file names etc.
The server does not provide a way to detect this as well in the remote case.
In case the persistence provider can't be detected by the plugin, we can still
let the user to register the provider in libraries - this covers the case when
the provider is deployed with the web app (or when the provider is in some
other user chosen location). As for not being able to detect providers on a
remote server, I think that Jano's suggestion covers that pretty well.
I wonder how many users actually deploy to remote servers from IDE. I think
maybe 1% or less? Do you have any data? The reason I am asking is that we should
not compromise usability for most users to cover a theoretically possible corner
*** Issue 76398 has been marked as a duplicate of this issue. ***
Obsolete milestone, please reevaluate
Is this even valid anymore?
Please be ready to discuss this issue on 2008/10/22
> Is this even valid anymore?
I would assume so, though I don't know whether something has changed in j2ee.persistence in this area. Adding the
current owner, Dongmei, to CC.
This is still valid, meaning we still list all the providers (Toplink, Hibernate, KODO, OpenJPA) in the Persistence
Provider combo box. But there was a change/enhancement made in NB 6.1. In NB 6.1 and later, if Hibernate is selected as
a provider, the Hibernate library reference will be added into the project automatically. This is a special case only
done for Hibernate provider.
no bug should be assigned to issues. distributing the load.