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.
Created attachment 138077 [details] Exception Scenario: - create simple web project (Java EE6 or Java EE7) - create Persistence Unit with Hibernate JPA 2.0 persistence provider - create Entity class from database - create JSF from Entity class - deploy to GlassFish 4.0 (deployment works) - run the application The following error occurs: ============================================ java.lang.AbstractMethodError at com.sun.enterprise.container.common.impl.EntityManagerWrapper._getDelegate(EntityManagerWrapper.java:197) at com.sun.enterprise.container.common.impl.EntityManagerWrapper.getCriteriaBuilder(EntityManagerWrapper.java:834) at entities.AbstractFacade.findRange(AbstractFacade.java:47) ============================================ The following code throws the error: javax.persistence.criteria.CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery(); Full exception is attached. Please either fix the Hibernate definition or modify generated AbstractFacade class. The code should be transparent and independent from persistence provider. Setting the priority to P2, as the basic functionality is broken.
P2 may be good because generated code do not work, but after google for the issue, it seems to be gf4+hibernate 3.x to 4.3.3 compartibility issue which face a lot of users and I don't have even possible solution for now to be able to workaround it on netbeans side if it worth to do on nb side. Having in mind it's likely not nb issue, downgrade to P3 for now. Use either older hibernate (may work wit old jpa1.0 hibernate_ or gf 3.1.2.2 for sensitive application. We may produce a warning or block jsf from entity wizard for this combination (provider+server) about compartibility issue. In this case it may be moved to jsf area. Or wait for resolve on gf or hibernate side and try to update at least bunndled version with the one without this problem.
In case of "warning" solution, the warning may need to be added to persistence unit wizard instead, and show this warning if pu is created with hibernate provider and with server already set to gf4.
Testing the same project with JBoss EAP 6.1 an it works. So this indicates either Library definition problem or GlassFish with Hibernate problem.
Works with GlassFish 3.1. So this really indicates some Glassfish4+Hibernate problem.
https://java.net/jira/browse/GLASSFISH-20716 next issue is found, before this issue I was sure old providers should work in new environment, but now it's unclear. may be we should ask in the issue. If there is such limitation, I will filter away all providers below 2.1 if used with ee7 server.
But I don't see a way to add any comment to gf issue.
(In reply to comment #5) > I will filter away all providers below 2.1 if used with ee7 server. This makes sense to me. EE7 spec lists JPA 2.1 in its list of required APIs (Table EE.6-1).
yes, it's ee7 requirenment to be ee7 environment, but it may not mean it shouldn't support old providers also. if there will be no reply in gf issue, I'll implement this approach, and it will mean the only one(at least already released) option for gf4 for now. I don't remember exactly, but ee6 requirement is jpa2.0 but was it possible to use toplink jpa1.0? I don't remember any related issue and there was no filter for old providers before.
> I don't remember exactly, but ee6 requirement is jpa2.0 but was it possible to > use toplink jpa1.0? I'd think this is server implementation specific. I can imagine that some server may allow that in addition to what EE spec requires. But restraining plugability and making requirements stricter is likely going to result into better performing more robust server. Not to mention that testing and development of such server is easier too.
In my opinion it's major hit on users applications portability, but it's on gf side and if gf team decide to go this way we can't do much on nb side. Also I'm trying to find some documents like https://java.net/projects/javaee-spec/pages/CompatibilityRequirements but it's yet unclear if ee6 applications should/must run fine on ee7 server.
It may have sense if gf4 plugin will return 2.0 and may be 1.0 as unsupported. On other hand most code before check only upper limit and some changes may be required in more areas.
based on discussion, I'll remove <2.1 providers for gf4, fix will affect server plugin but I would like to make changeset myself as it may be some more complex fix rather then just return false for isJPA1 isJPS20 supported.
Tomas, is org.glassfish.tools.* on gf side? code inside return server version with supported jpa1 and jpa2, in fact it's supported but it's not server feature but more a default provider feature(eclipsleink 2.5) when server itself do not support providers except 2.1.
http://hg.netbeans.org/web-main/rev/e48541936ec7 current fix filter out any providers below 2.1 for ee7 platform, but I suppose some other servers may support old providers and a better fix should involve server plugins response. hibernate 2.0 will still fail of cause, but nb will not suggsst h2.0 selection now.
org.glassfish.tools.* is library that is on java.net. It's common code shared by NetBeans and Eclipse GlassFish plugins. But I can give you access to it, just let me know if you need it.
if it's shared, it may be hard to change meaning of supported jpa versions return by relative code as it's unknown how it may hit eclipse plugin. Yet it may be good either reuse this for purpose to return version of providers supported(but before gf4 it was almost the same and may ecliupselink plugin works this way but I don't know, do you know? ) or introduce new api to have separate jpa version suported ans providers version supported.
Integrated into 'main-silver', will be available in build *201308062300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/e48541936ec7 User: Sergey B. Petrov <sj-nb@netbeans.org> Log: #233726 fix/woraround in persistece+common code, but a better fix should involve server support check