This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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 persistence providers. 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 following behavior: * 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. Ludo, comments
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 case.
*** 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.