2009-08-21 14 views
18

Jaki jest najlepszy sposób utworzenia aplikacji java, którą można uruchomić przy użyciu "usługi" w systemie Linux? Miałem zamiar użyć JSW dostępnego pod numerem here, ale nie mogę na tym skorzystać z licencji (licencja jest na licencji GPL lub kosztuje tyle ile się da). Potrzebowałbym licencji na styl Apache.Narzędzie do tworzenia usługi demona Java w systemie Linux

Używam programu maven do tworzenia, więc byłoby wspaniale, gdyby można było utworzyć usługę przy użyciu wtyczki maven, ale wszelkie inne sugestie byłyby świetne.

Widziałem Apache Commons Daemon, czy istnieje do tego dodatek? Dokumentacja wydaje się rzadki, więc przykład działa to byłoby dobre ...

Dzięki

Odpowiedz

20

Usługi Linux to tylko skrypty powłoki, które rozpoczynają procesy w tle. Zajrzyj pod numer /etc/init.d - możesz otwierać pliki w edytorze tekstów. Potrzebujesz tylko skryptu bash, który w odpowiedni sposób odpowiada na parametry start i stop (np. start uruchomi twoją usługę i zapisze identyfikator procesu w znanej lokalizacji, stop zabije proces z PID z pliku, który utworzyłeś), a następnie umieść go w /etc/init.d.

Wystarczy popatrzeć na Init Scripts i An introduction to services, runlevels, and rc.d scripts

13

O ile wiem, nie ma wtyczki Maven dla obu Apache Daemon lub Akuma. Chociaż można próbować wywołać je z poziomu kompilacji Mavena za pomocą maven-exec-plugin.


miarę swoich zastrzeżeń firm O użyciu licencji GPL produkty, warto czytać o konsekwencjach stosowania. Nie jest tak groźny, jak obawiają się korporacje. Oto interpretation of the GPL. Nie ma oczywiście żadnej wagi prawnej (i może nie być poprawne lub wspierane przez precedens, nie jestem prawnikiem), ale może wystarczyć, aby rozpocząć rozmowę ze swoimi legalnymi ludźmi.

Od wskazanej stronie:

prostu łącząc dzieła chronionego prawem autorskim z innej pracy nie tworzy prac pochodnych. Oryginalne dzieło chronione prawem autorskim musi zostać w jakiś sposób zmodyfikowane. Wynikające z tego prace pochodne muszą same w sobie "reprezentować oryginalne dzieło autorstwa". Jeśli więc licencjobiorca nie modyfikuje oryginalnego programu objętego licencją GPL, a jedynie uruchamia go, nie tworzy pracy pochodnej.


Istnieje Appassembler Maven plugin że myślę, że robi to, co trzeba (choć nie tworzy owijarki JSW). Tworzy skrypt powłoki (i plik bat) i gromadzi wszystkie słoiki aplikacji w katalogu. Opcjonalnie może być configured, aby utworzyć konfiguracje demona oparte na JSW.

Oto przykładowa konfiguracja, która wygeneruje autonomiczną aplikację w folderze target/appassembler i wygeneruje pliki opakowania JSW w katalogu target/appassembler/jsw/myApp. Zwróć uwagę, że cel montażu jest związany z fazą testu integracji, aby zapewnić utworzenie słoika projektu. Aby wygenerować przebieg wyjściowy mvn zweryfikować lub po prostu wygenerować owijarki serwis prowadzony mvn pakiet:

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>appassembler-maven-plugin</artifactId> 
    <version>1.0</version> 
    <executions> 
     <execution> 
     <id>assemble-standalone</id> 
     <phase>integration-test</phase> 
     <goals> 
      <goal>assemble</goal> 
     </goals> 
     <configuration> 
      <programs> 
      <program> 
       <mainClass>name.seller.rich.MyMainClass</mainClass> 
       <name>myShellScript</name> 
      </program> 
      </programs> 
      <platforms> 
      <platform>windows</platform> 
      <platform>unix</platform> 
      </platforms> 
      <!--collect all jars into the lib directory--> 
      <repositoryLayout>flat</repositoryLayout> 
      <repositoryName>lib</repositoryName> 
     </configuration> 
     </execution> 
     <execution> 
     <id>generate-jsw-scripts</id> 
     <phase>package</phase> 
     <goals> 
      <goal>generate-daemons</goal> 
     </goals> 
     <configuration> 
      <!--declare the JSW config --> 
      <daemons> 
      <daemon> 
       <id>myApp</id> 
       <mainClass>name.seller.rich.MyMainClass</mainClass> 
       <commandLineArguments> 
       <commandLineArgument>start</commandLineArgument> 
       </commandLineArguments> 
       <platforms> 
       <platform>jsw</platform> 
       </platforms>    
      </daemon> 
      </daemons> 
      <target>${project.build.directory}/appassembler</target> 
     </configuration> 
     </execution> 
    </executions> 
    </plugin> 

Dla porównania wygenerowane pliki są w następujący sposób:

myApp\bin\myApp 
myApp\bin\myApp.bat 
myApp\bin\wrapper-linux-x86-32 
myApp\bin\wrapper-macosx-universal-32 
myApp\bin\wrapper-solaris-x86-32 
myApp\bin\wrapper-windows-x86-32.exe 
myApp\conf\wrapper.conf 
myApp\lib\libwrapper-linux-x86-32.so 
myApp\lib\libwrapper-macosx-universal-32.jnilib 
myApp\lib\libwrapper-solaris-x86-32.so 
myApp\lib\wrapper-windows-x86-32.dll 
myApp\lib\wrapper.jar 
+0

@Rich - dzięki za odpowiedź. Pierwotnie zrobiłem coś takiego, ale licencja JSW jest zbyt restrykcyjna dla mnie (dobrze mojego pracodawcy!). A propos, czy można skonfigurować Appassembler z głównego projektu POM na projekcie z wieloma modułami? Jedyny sposób, w jaki mogłem to zrobić, to stworzyć nowy moduł z konkretnym zadaniem tworzenia skryptów serwisowych (i RPM w moim przypadku), które działały po zapakowaniu wszystkich pozostałych modułów ... – Lehane

+0

Jeśli uruchomisz zestaw cel w module, który zależy od wszystkich innych, te zależności zostaną spakowane w katalogu appassembler. Prawdopodobnie nie byłby uruchomiony na twoim agregatorze pom, ale na module z "główną" klasą –

+0

również licencja GPL nie jest tak restrykcyjna, jak to zwykle bywa w korporacjach. Czytać o tym: http://www.sitepoint.com/article/public-license-explained/ –

Powiązane problemy