Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 152373 - Persistence Provider by REST tooling is GlassFish version independent
Persistence Provider by REST tooling is GlassFish version independent
Product: webservices
Classification: Unclassified
Component: REST
Macintosh All
: P2 (vote)
: 6.x
Assigned To: Peter Liu
Depends on:
  Show dependency treegraph
Reported: 2008-11-04 23:42 UTC by arungupta
Modified: 2009-02-19 23:28 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description arungupta 2008-11-04 23:42:59 UTC
Using NB 6.5 RC2, created a web app, Persistence Unit and then exposed that as RESTful entity from Entity class. The
persistence.xml is changed from:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"
  <persistence-unit name="sakilaPU" transaction-type="JTA">


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<persistence xmlns=""
xmlns:xsi="" version="1.0"
  <persistence-unit name="sakilaPU" transaction-type="JTA">

Two issues:

1). The persistence provide is changed to Toplink Essentials even though the application is deployed on v3 Prelude. TLE
is not bundled in v3 and running this application is throwing a ClassNotFoundException.

2). Why entity classes are explicitly included ?
Comment 1 arungupta 2008-11-04 23:44:52 UTC
The workaround is to revert to the original persistence.xml.
Comment 2 _ ludo 2008-11-05 15:50:49 UTC
If possible, I would appreciate a fix for Nb 6.5 Patch 1.
This is killing the user experience when you use together 2 great features: Jersey and GlassFish v3 Prelude...
EclipeLink is the default provider for v3 and should stay like that until the user really says he wants to change it.

Comment 3 Lukas Jungmann 2008-11-06 13:54:51 UTC
looks like exclude-unlisted-classes element was added in issue 104257
Comment 4 Peter Liu 2008-11-07 01:10:50 UTC
The reason for modifying the persistence.xml is to make it work for the various configurations we support, i.e. tomcat
vs gf and with or without spring framework. The modification is done in such a way that the resulting persistence.xml
will work under all the configurations except, of course, v3. 

Ludo, could you point me to how I can determine if a project is running against gf v2 or v3?  I need to do add some code
to specify the appropriate persistence provider  for v3 in the case we are running on top of the spring framework.


Comment 5 _ ludo 2008-11-07 01:32:38 UTC
Adding Vince who can help digging into the j2eeserver apis to check if v3 is a target or not...
Comment 6 Peter Liu 2008-11-12 23:32:13 UTC
This issue is now fixed in the trunk.  We now modify the persistence.xml only when it is necessary based on the
configuration. In addition, for the gfv3/spring configuration, we explicitly set the provider to
org.eclipse.persistence.jpa.PersistenceProvider instead of toplink provider.

Comment 7 Lukas Jungmann 2008-11-13 16:21:42 UTC
cleaner way to fix this - and I'm not saying that current fix doesn't work - would be using J2eeserver API instead of
relying on some project property which value can be (theoretically) changed at any time without any "heads-up" (from
j2eeserver module maintainer).

What I'm talking about is to use sth like (typing from memory, actual method names may be different):

One more thing I don't think is good is that we're silently changing user's choice without giving him any feedback - how
will user know that PersistenceProvider has been changed in non-versioned project? Arun, can I ask you for your opinion
here (since you filed this bug), please?

Comment 8 Peter Liu 2008-11-13 18:51:23 UTC
Lukas, we actually don't override user's choice. If the user has selected something other than the default provider, we
will preserve it (unless the logic is not working.)  So, the currently logic is that if we are using gfv3/spring and
there is no <provider> element in the persistence.xml, we will set it to eclipselink. Similarly, for gfv2/spring, we
will set it to toplink. Note that this is really just to make it explicit for the spring framework which doesn't know
what the default provider is for a server.

As for the server api, I spent a lot of time and I couldn't figure out how to determine whether a server is tomcat, gfv2
or gfv3, so I resorted to using the I hope that is ok.   Otherwise, Vince please let me know what
the proper way is to do this. Of course, if there is a way to determine what the default provider is via the api, it
would be even better.  thanks.
Comment 9 Lukas Jungmann 2008-11-18 12:21:31 UTC
ok, you're right.

re api: I don't think you need to know the server type, I think that what you really need to know is if there's some
default persistence provider and if so then maybe which one and some configuration info about it so you know what to
generate. Another, a bit different approach which should give you enough flexibility and control is to use
websvc.wsstackapi (jaxws impl in websvc.wsstack.jaxws) - OTOH this would require more work; check also issue 80421
Comment 10 Peter Liu 2008-11-18 18:37:45 UTC
I agree about the api to get the default persistence provider. However, I don't think there is such an api for it.

In addition, we still need to know the server type. For some reason, we need to generate the following elements in the
persistence.xml in order for things to work with Tomcat. 


Of course, we can always generate them blindly as before but it will confuse people who use glassfish.

As for the wsstackapi, I'll keep that in mind and wait to see what the plan is going forward.
Comment 11 pslechta 2008-11-20 14:43:12 UTC
Please verify this issue so it can be part of NB 6.5 patch 1.
Comment 12 Lukas Jungmann 2008-11-23 22:57:11 UTC
v. in trunk
Comment 13 pslechta 2008-11-25 10:34:41 UTC
I don't see any changeset that can be used to port this issue into 6.5 patch 1.
Please clarify which changes should be ported!
Comment 14 pgebauer 2008-11-27 16:45:03 UTC
The required changeset wasn't specified by 65patch1 code freeze. The issue has been moved to 65patch2.

Comment 15 pslechta 2008-12-16 14:01:40 UTC
I still don't see any changeset. Please provide one. Or if this fix is not important, should we remove it from patch
candidates? Thanks.
Comment 16 Peter Liu 2008-12-16 18:49:06 UTC
Here is the changeset:

Comment 17 pslechta 2008-12-16 19:34:16 UTC
The fix was ported into release65_fixes repository.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo