Jakieś sprawdzone metody postępowania z Java EE i java.endorsed.dirs?

Question

Niedawno natknąłem się na problem z Glassfish standalone (v3.1) vs Glassfish embedded (v3.1) vs java SE i sposób java.endorsed.dirs. Specyficznym problemem, który miałem, jest here, ale nie sądzę, że to ostatni raz, kiedy wpadnę na coś podobnego.

Informacje, które znalazłem pod numerami here i here, sugerują dodanie wspieranych bibliotek do pliku bootstrap podczas kompilacji. Jednak raport o błędzie z this sugeruje, że trudno jest ustawić prawidłowo zatwierdzone biblioteki, jeśli używasz wbudowanych rybików.

Wygląda na to, że po zainstalowaniu na osobnym pojemniku ze szklanym naczyniem moja aplikacja będzie działać przeciwko wspieranym libs, które zawiera szklarnie, ale w przypadku używania osadzonego pojemnika nie będzie. Napotkałem na swój pierwotny problem, ponieważ wtyczka "Worm-Embedded Glassfish" nie uruchamia "Glassfish" z wykorzystaniem zatwierdzonych bibliotek, takich jak Standarone Glassfish. Nie jestem też pewien, czy inne pojemniki (np. Jboss) zawierają ten sam zestaw zatwierdzonych bibliotek, jak glassfish.

Czy powinienem (1) się zmagać (dużo), aby upewnić się, że moja aplikacja jest skompilowana w stosunku do zatwierdzonych bibliotek i zawsze umieszczana w kontenerze, który jest bootstrapped przy użyciu zatwierdzonych bibliotek lub powinienem (2) po prostu przykleić korzystać z pakietów dostarczanych z Java SE 6?

Jeśli wybiorę (2), czy będę musiał się martwić o niezgodności podczas wdrażania mojej aplikacji do kontenera, który jest bootstrapped z nowszymi zatwierdzonymi bibliotekami?

Byłbym wdzięczny za wszelkie informacje, które każdy może zaoferować.

Answer 1

Może brakuje mi czegoś oczywistego, ale ... Czy nie jest GlassFish Embbeded dostarczany z bibliotekami zgodnymi ze specyfikacją Java EE? I czy te biblioteki nie są załadowane domyślnie? (Jeśli tak nie jest, proszę wypełnić błąd tutaj: http://java.net/jira/browse/EMBEDDED_GLASSFISH).

Co mam na myśli to: Powinieneś skompilować się z API specyfikacji Java EE i po prostu pozwolić kontu użyć własnych implementacji.

W pierwszej części, jeśli używasz Mavena, podoba mi się sposób, w jaki Codehaus archetypes ustawia zatwierdzone biblioteki. Jest to zarówno czyste i Application Server Agnostyk:

<properties> 
    <endorsed.dir>${project.build.directory}/endorsed</endorsed.dir> 
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
</properties> 

...

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-compiler-plugin</artifactId> 
    <version>2.3.2</version> 
    <configuration> 
     <source>1.6</source> 
     <target>1.6</target> 
     <compilerArguments> 
      <endorseddirs>${endorsed.dir}</endorseddirs> 
     </compilerArguments> 
    </configuration> 
</plugin> 

...

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-dependency-plugin</artifactId> 
    <version>2.1</version> 
    <executions> 
     <execution> 
      <phase>validate</phase> 
      <goals> 
       <goal>copy</goal> 
      </goals> 
      <configuration> 
       <outputDirectory>${endorsed.dir}</outputDirectory> 
       <silent>true</silent> 
       <artifactItems> 
        <artifactItem> 
         <groupId>javax</groupId> 
         <artifactId>javaee-endorsed-api</artifactId> 
         <version>6.0</version> 
         <type>jar</type> 
        </artifactItem> 
       </artifactItems> 
      </configuration> 
     </execution> 
    </executions> 
</plugin> 

co jest dość dużo wszystko trzeba kompilować swoje projekty przed Java EE 6 interfejsów API. Każdy serwer aplikacji zgodny z Java EE 6 powinien świadczyć te usługi, a Ty nie powinieneś się martwić o to, jak udostępniają tę aplikację.

Odpowiedzialność za uruchamianie usług Java EE powinna należeć do serwera aplikacji. Jeśli spróbujesz swojego własnego rozwiązania "na miejscu", istnieje szansa, że ​​piekło JAR uwolni się.

Cheers,

Answer 2

EDIT: Podejście javaee-endorsed-api powyżej prawdopodobnie będzie działać dobrze, ale daje mi nerwów. Nie sądzę, że jest już produkowany lub utrzymywany.Ponadto zawarte w nim odzwierciedla, że ​​w pewnym momencie nazywało się to javaee-compact-api i można zobaczyć, jak usuwają z niego klasy implementacji. Natomiast wybór słoików API, które chcesz wykorzystać jako zatwierdzone (jak zalecam poniżej) wydaje się być bardziej stabilny i elastyczny. Na koniec, jeśli nadal chcesz zastosować podejście javaee-endorsed-api, możesz nadal korzystać z zalecanego przeze mnie ogólnego podejścia i wskazać na javaee-endorsed-api.jar.

Ryan; Właśnie przeczesałem tę długą ścieżkę (dotykając StackOverflow, forów java.net itp.) W tej samej podróży.

Podczas testowania urządzenia lub integracji musisz ustawić właściwość System java.endorsed.dirs, jak wiesz.

Podstępem jest to, że musisz to zrobić w taki sposób, aby JVM przeprowadzająca testy go podniosła. A to zależy od tego, jak działa Surefire.

Jeśli z jakiegoś powodu masz Surefire ustawiony na , a nie na, jest to prawdopodobnie zła rzecz i powinieneś dokonać ponownej oceny konfiguracji tutaj.

Jeśli masz Surefire zestaw do talerza, a potem myślisz może po prostu zawierać java.endorsed.dirs w systemPropertyVariables strofy, na przykład:

<systemPropertyVariables> 
    <java.endorsed.dirs>weWillGetToThisInAMoment</java.endorsed.dirs> 
</systemPropertyVariables> 

... ale to byłoby źle. Powodem jest fakt, że program, który faktycznie działa, jest nazywany ForkedBooter, a program ForkedBooter programowo ustawia właściwości systemu dla testów jednostkowych. Oznacza to, że przed odczytywaniem zwrotki <systemPropertyVariables> przez ForkedBooter jest już za późno.

Ale może używać <argLine> w Surefire konfiguracji jak poniżej:

<configuration> 
    <argLine>-Djava.endorsed.dirs=weWillGetToThisInAMoment</argLine> 
</configuration> 

Teraz VM że Surefire widelce będą mieć zatwierdzone katalogi odpowiednio ustawione. Porozmawiajmy teraz o tym, jaką wartość dostarczyć.

Chcesz wiśnia wybierz interfejsy API, aby zastąpić. W twoim przypadku javax.annotation.* jest uzasadnionym wyborem. Chcesz dostarczyć katalog do lokalnego repozytorium Maven zawierającego odpowiedni słoik.

Oto wartości, które używam:

${settings.localRepository}${file.separator}org${file.separator}glassfish${file.separator}main${file.separator}javaee-api${file-separator}javax.annotation${file.separator}${javaxAnnotationVersion} 

• Maven gwarantuje, że ${settings.localRepository} wzrośnie do wartości życia, gdzie lokalne repozytorium Mavena.
• ${file.separator} to sposób na uzyskanie wartości System.getProperty("file.separator") w zamian za nieruchomość Maven.
• W moim przypadku już zadeklarowałem <dependency> na the GlassFish artifact that bundles up the javax.annotation package as defined in Java EE 6. Więc tutaj skonstruowałem ścieżkę do artefaktu. Zdefiniowałem również właściwość o nazwie javaxAnnotationVersion, która dla mnie jest ustawiona na 3.1.2.

Kiedy to wszystko zrobić, wtedy gdy Surefire widelce VM do uruchamiania testów jednostkowych, potwierdzony katalogi zostaną ustawione do katalogu w lokalnym repozytorium Maven zawierający słoik, który mieści się javax.annotation zajęcia, a teraz wbudowany GlassFish —, który działa w procesie — będzie używał klas Java EE 6 wersji javax.annotation zamiast wersji Java SE 6. Mam nadzieję, że to ci pomoże.