1. Install and register a dev build of WebLogic 11g PS3 (10.3.4)
2. In the admin console, switch persistence provider to TopLink (this is a JPA 2.0 implementation)
3. Create entity classes from database. You see that persistence.xml uses version 2.0.
4. Create JSF pages from Entity. The generated code uses JPA 2.0 features, such as the Criteria API.
=> The application can not be compiled, as the JPA 2.0 APIs are not on the classpath.
The problem is that JPA 2.0 APIs are on the classpath, but they are *after* JPA 1.0. So JPA 1.0 versions of the classes are used, which results in the compilation error.
I guess the right solution would be to only include JPA 1.0 or 2.0 APIs on the classpath, based on what is set as the persistence provider. Currently this is not considered, so if Kodo (JPA 1.0) was set as the default provided, the IDE would again generate persistence.xml with version 2.0, which is wrong. If Kodo is the provider persistence.xml version 1.0 should be used. Not sure if there is another solution.
Correction: even if TopLink is selected as the JPA implementation, the supported JPA level is still 1.0. So whether TopLink or Kodo are set as the provider, in either case only JPA 1.0 APIs should be exposed on the classpath, not JPA 2.0.
There will probably be a special way to enable JPA 2.0 with WebLogic 11g R1 PS3 (10.3.4), and it may be worthwhile to support it - I filed a separate enhancement #189348 for that. But the choice of JPA provider alone should not determine the JPA API version available on the classpath.
Fixed in web-main 5d44192b8823.
Integrated into 'main-golden', will be available in build *201008130001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Petr Hejl <email@example.com>
Log: #189205 JPA 2.0 APIs should not be on the classpath for WebLogic
Thanks, the JPA 2.0 API is no longer on the classpath, but the IDE still continues to think that WebLogic supports JPA 2.0, and generates JPA 2.0 code (persistence.xml with version 2.0, criteria API in generated classes etc.) Not sure where this needs to be remedied.
I guess it is caused by wrong assumptions JPA code makes. Here is what I already wrote in bug 189326.
"The UI reports 2.0 versions which is wrong. This is because
PersistenceProviderSuppliers such as WebPersistenceProviderSupplier do not
really care about the level supported by the default provider (at the time of
dialog creation). The created persistence unit spec level however correctly
matches the API on classpath (which is 1.0). I think suppliers should use this
information to display the proper version in combo. In worse case we can add
some constant like "defaultPersistenceProviderJPA1Only" which suppliers would
use and respect."
Perhaps I was wrong about the generated persistence.xml in the comment. Sergey can you investigate please?
Main problem with jpa 1 vs 2 is there is no 1:1 relation between project and version, 1.0 and 2.0 may create the same persistence xml, user can use new eclipselink 2.0 provider with old persistence 1.0 applications. Also it may be hard to guess from classpath as main part except api may be on server classpath. And if user switch from toplink to ecliplink 2.0 there is perisytence 1.0 api on classpath already and if switch from eclipselink 2.0 to toplink 1.0 there is persistence 2.0 api on classpath already.
Some cases may be covered by private project properties, but it will not worjfor old project and also will not work for manual persistence.xml and classpath modifications.
In most cases where 1:many I tried to use/suppose latest spec version, it may be the reason for 2.0 in case of weblogic, but may be this case can be handled better, also suggestion to use 'default...1.0' and 'default...2.0' may work.
Also providers are self-determined and do not use any information from classpath, so if 2.0 is suggested it may be a fault in providers usage/supported providers list creation. It may require update for supported tools check where is '2,0' providers are returned as supported.
as my repository is still building, some more comments:
"But the choice of JPA provider alone should not
determine the JPA API version available on the classpath" there is nothing from classpath, nb have list or supported providers and this list is checked against supported providers in server plugin. I can't verify now if 1.0 and 2.0 have different keys in this case.
Current realization check only provider class 'platform.isToolSupported(provider.getProviderClass())' and it's the same in 1.0/2.0. It may be good to add some option argument to this check either check \(provider.getProviderClass())+'_'+provider.getVersion()\ but it may cause more problems if some place will not be updated.
> And if user switch from toplink to ecliplink 2.0
I would first worry about how we create the setup by default, and then about switching providers by the user - that is P4 IMO. There are other cases when the application will not work correctly if you switch something (e.g. switching a target server on a project that uses JSF), so I would not worry about it much.
> It may be good to add some option argument to this check
I agree this may be a solution. It will get a bit messier, but I don't have other ideas. Are there any other options?
Ok. Just found there is no much usage of selection provider version usage in wizard, will fix it, but after the fix persistence.xml for openjpa(2.0) will have version 2.0. Now need to add both 1.0 and 2.0 providers to providers list and this way server plugin will be able to filter unsupported version if api changes will allow, gf may also filter away 1.0 for eclipselink as it have 2.0 bundled and this way avoid providers list expanding.
Anyway there is nothing with project/server etc path at time when persistence wizards are invoked.
I'm mixed a bit, if I got it right weblogic have eclipselink 2.0/2.1 bundled and this way in some terms support and use eclipselink 2.0 provider (it may also handle properly 2.0 properties in persistence.xml 1.0 but need to test) but do not support jpa2.0 itself and this way no 2.0 version in persistence.xml and no criteria api etc.
So from one point of view show 'EclipselInk(2.0)' or 'OpenJPA(2.0)' in providers list is valid but from other may be mixed with real jpa2.0 usage. Also providers are usually backward compartible and show (2.0) but use (1.0) may not be a big issue (as it was initially). But usage of criteria api/creation of persistence.xml with 2.0 version is a problem.
So are you hesitating about the display name? How about someting like:
EclipseLink 2.1 (JPA 1.0)
EclipseLink 2.1 (JPA 2.0)
Similarly, we could use e.g.:
Hibernate 3.5 (JPA 2.0)
2.1 mean either provider should know about library or wizard should check for a library, it may be implemented for bundled eclipselink, but it may be harder for server side eclipselink to get if it's 2.1 or 2.0 or may be upgraded to 2.2.
I'm not sure if server really care if it's 2.1 or 2.0 and this information is available somewhere. Also nb persistence do not have much support for separate library versions, see next http://netbeans.org/bugzilla/show_bug.cgi?id=171973 for example.
Integrated into 'main-golden', will be available in build *201008170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Sergey B. Petrov <firstname.lastname@example.org>
Log: fix #189205 part fix, now selected provider version dominate over project jpa version, added 1.0 and 2.0 for some providers. In reverse process to get provider from pu exact match is preferrable now instead of biggest supported version.
Regarding persistence.xml 2.0 in case of default eclipselink provider, it's likely the issue with maven project where eclipselink api is added to compile classpath when should be added to processors classpath only.
I can't reproduce it because in my case openJPA(JPA2.0) is default but we have no bundled libraries for openjpa. current logic depends mostly on library/project support when select version for jpa, as if there is no jpa2.0 api on classpath and corresponding library no jpa2.0 dependent code should be generated.
But this logic works for default provider only, if user will select non default eclipselink 2.0, library will be added and there will be jps2.0 api on classpath and in this case something like platform restrictions should be implemented and used by persistence in order to prohibit jpa 2.0 usage even if all staff is available.
Main part is fixed by http://hg.netbeans.org/web-main/rev/2f4abda5a75e
tested with pu wizard, etity wizard, create 2.0 for gf3 and 1.0 for weblogic.
But works for default eclipselink provider for ant projects only because of maven issue related to handling of PROCESSOR_CLASSPATH.
Should this issue be closed now?
Thanks Sergey. Let's close this bug and file new bugs for other problems.
initial issue is fixed
regarding issues need to be filed
- maven PROCESSOR_CLASSPATH (seems not separated from COMPILE_CLASSPATH)
- handle somehow user will use jpa1.0 even if select jpa2.0 provider (may be a warning in wizards?) or handle provider name in case if project(server) do not support JPA2.0 but support corresponding jpa provider.
Thanks a lot Sergey. I tested this and some other (minor) problems I noticed are:
- The wizard still displays the (now irrelevant) warning that JDK 6 is recommended for JPA 2.0
- After entities creation, the project is badged as erroneous, not sure why. This is rather serious, because it creates problems for Deploy on Save and generally looks bad, especially in a screencast. Any ideas?
> - maven PROCESSOR_CLASSPATH (seems not separated from COMPILE_CLASSPATH)
Is something actually wrong in the generated project and the sources? I see that EclipseLink is added with <scope>provided</scope>, which is correct.
> - handle somehow user will use jpa1.0 even if select jpa2.0 provider (may be a
> warning in wizards?) or handle provider name in case if project(server) do not
> support JPA2.0 but support corresponding jpa provider.
I think the provider name should be fixed - it should say "JPA 1.0". I don't think we need to display a warning, because JPA 1.0 is "expected".
red badge need additional investigation as project is buildable, I got it too but wasn't sure it's reproducible.
>Is something actually wrong in the generated project and the sources? I see
that EclipseLink is added with <scope>provided</scope>, which is correct.
Regarding wrong/or not. In maven ecliselink seems to be added to compile classpath and it means jpa2.0 api is on claspath after eclipslink api addition and it means project itself support jpa2.0 now. In ant projects eclipselink is added to processors classpath only and do not affect compile classpath, so there is no api for support spa 2.0 functionality. But I may miss something, haven't tried to use any class from eclipselink.jar and build maven project if it's buildable it's an issue with processors support in maven.
The red error badge problem - filed as a separate bug 189626.