Java8, Netbeans i JPQL Query

Od lat moim ulubionym IDE jest Netbeans, którego używam od wersji 5 (choć ostatnio próbuję flirtować z Intellij Idea). Jest w nim taka funkcja którą rzadko używam – Run JPQL Query.

nb-jpql-menu

Funkcja jest fajna – umożliwia pisanie zapytań w JPA QL (z podpowiedziami) i ich wykonywanie na istniejącej bazie. Nie używam jej jakoś namiętnie bo wymaga zdefiniowania jednostki utrwalania (ang. persistence unit) która odwołuje się do zarejestrowanego w IDE źródła danych, a najczęściej korzystam ze źródła ODBC zdefiniowanego po stronie serwera aplikacji. Oczywiście da się zrobić kilka jednostek w pliku persistence.xml, dopisać trochę kodu i nadal korzystać z wstrzykiwania domyślnego ale jakoś nigdy mi się nie chciało walczyć, zwłaszcza, że przy takiej konfiguracji bywają problemy z kompilacją. Lepiej jest to zorganizowane w Intellij Idea – tam konkretnej jednostce utrwalania można przypisać źródło danych wykorzystywane w konsoli QL.

W każdym razie kilka dni temu chciałem sobie ficzer uruchomić, więc poprawiłem persistence.xml, uruchomiłem konsolę JPQL i … dupa. Błąd:

Internal Exception: Exception [EclipseLink-7151] (Eclipse Persistence Services – 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.ValidationException Exception Description: The type [class pl.harpy.lib.datamodel.entities.RegistryType] for the attribute [debitRegistry] on the entity class [class pl.harpy.lib.datamodel.entities.Decree] is not a valid type for an enumerated mapping. The attribute must be defined as a Java enum.

No to się trochę zdziwiłem. Rzeczony enum był na pewno enumem:


public enum RegistryType {

   ......

}

O co więc chodzi? Na chwilę zgłupiałem ale coś mi po karku zaczęło chodzić, wujek google i miałem: https://blogs.oracle.com/theaquarium/entry/jpa_and_java_se_8.

Faktycznie w RegistryType było coś takiego:


public static Set<RegistryType> findAllRegistries(AccountingOwnerType ownerType){
   return Arrays.stream(RegistryType.values()).filter(p -> p.getOwnerType() == ownerType).collect(Collectors.toSet());
}

No ale to już kiedyś przerabiałem – w czasach używania Glassfisha podmieniałem wersję EclipseLink na taką z wprowadzonym obejściem (bez sypały się wszystkie strumienie pochodzące z kolekcji rodem z encji – tzn. dostawałem puste). W aktualnej Payarze (4.1.1.162) EclipseLink jest w dobrej wersji (2.6.2). Przyjrzałem się błędowi jeszcze raz i o dziwo wersja EclipseLink była 2.5.2.v20140319-9ad6abd. Skąd? Pierwsze podejrzenia: maven, faktycznie w pliku pom.xml:


<dependency>
   <groupId>org.eclipse.persistence</groupId>
   <artifactId>eclipselink</artifactId>
   <version>2.5.2</version>
   <scope>provided</scope>
</dependency>

nb-maven-dependecies

Poprawiłem w pom.xml, „download depnedencies (mamy 2.6.2) próba – nie działa, nadal mam błąd z 2.5.2-cośtam. No to pokombinowałem z jednostkami utrwalania w persistence.xml (generowanie adnotacji nie funkcjonuje OK jak jest więcej niż jedna jednostka w pliku), „Clean and build project”, dalej nic. Usunąłem z katalogu mavena wersję 2.5.2. Nic. Zgnębiony zaglądam do pom.xml, a tam 2.5.2!!!! Skąd? Przecież zmieniałem. ???? Chwilę pokombinowałem i eureka – biblioteki Netbeans:

nb-libraries

Netbeans używa do konsoli JPQL własnych bibliotek….

 

Wydawało się, że po usunięciu bibliotek pójdzie z górki. Niestety. Nadal przy obsłudze JPQL pojawia się w logach błędów 2.5.2.v20140319-9ad6abd. Fizyczne usunięcie jarów dało rezultat ale nieco inny od oczekiwanego – Netbeans pokazał czerwony znaczek informacji „Unexpected Exception”

java.lang.ClassNotFoundException: org.eclipse.persistence.jpa.PersistenceProvider
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:222)

Na chwilę zgłupiałem po raz kolejny – przecież IDE ma zarejestrowane biblioteki JPA z „Glassfisha” (znaczy się widzi je z zarejestrowanej Payary) – ale po chwili przypomniałem sobie że chyba moduły Netbeans mają swoje obce zależności wklejone na sztywno. Coś mi się tak mikiciło, ale coś większego pisałem na Netbeans Platform w okolicach 2010 roku. Zajrzałem do adekwatnych modułów: org-netbeans-modules-j2ee-eclipselink.jarorg-netbeans-modules-j2ee-eclipselinkmodelgen.jar i niestety w plikach *_lib.xml stały adekwatne zależności:

 <volume>
<type>classpath</type>
<resource>jar:nbinst://org.netbeans.modules.j2ee.eclipselink/modules/ext/eclipselink/eclipselink.jar!/</resource>
<resource>jar:nbinst://org.netbeans.modules.j2ee.eclipselink/modules/ext/eclipselink/javax.persistence_2.1.0.v201304241213.jar!/</resource>
<resource>jar:nbinst://org.netbeans.modules.j2ee.eclipselink/modules/ext/eclipselink/org.eclipse.persistence.jpa.jpql_2.5.2.v20140319-9ad6abd.jar!/</resource>
</volume>

Ożesz franca…. Na razie odpuszczam, spróbuję zaglądnąć do wersji „nightly build”, ewentualnie ściągnąć źródła i spróbować zrobić uaktualnienie.

P.S. Intellij Idea nie ma takich problemów. Wykorzystuje biblioteki używane w projckcie. Jedyny problem jaki zauważyłem to to by w cache mavena (.m2) nie było starszych (2.5.2) bibliotek. Może to znak coby się jednak przesiąść?

Leave a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *