2009-08-21 5 views
18

Qual è il modo migliore per creare un'applicazione java che può essere eseguita utilizzando 'servizio' su Linux? Stavo per usare il JSW disponibile here, ma non posso usare la licenza su questo (la licenza è GPL o costa a mio parere). Avrei bisogno di una licenza di stile Apache.Strumento per la creazione di un servizio daemon Java su Linux

Sto usando Maven per la generazione, quindi sarebbe bello se fosse possibile creare il servizio usando un plugin Maven, ma qualsiasi altro suggerimento sarebbe ottimo.

Ho visto Apache Commons Daemon, c'è un plug-in per questo? Documentazione sembra scarsa, quindi un esempio di lavoro di questo sarebbe bene ...

Grazie

risposta

20

Servizi su Linux sono solo shell script che iniziano i processi in background. Dai un'occhiata a /etc/init.d - puoi aprire i file in un editor di testo. Tutto ciò di cui hai bisogno è uno script bash che risponda ai parametri start e stop in modo appropriato (ad esempio start avvia il servizio e registra l'ID processo in una posizione nota, stop uccide il processo con il PID dal file che hai creato), quindi posizionarlo in /etc/init.d.

Dai un'occhiata alla Init Scripts e An introduction to services, runlevels, and rc.d scripts

13

Per quanto ne so, non esiste un plugin Maven sia per Apache Daemon o Akuma. Sebbene tu possa tentare di invocarli da una build di Maven usando lo maven-exec-plugin.


Per quanto riguarda le prenotazioni aziendali sull'utilizzo di prodotti con licenza GPL, vale la pena di leggere le implicazioni di utilizzo. Non è virulento come temono le corporazioni. Ecco uno interpretation of the GPL. Ovviamente non ha alcun peso giuridico (e potrebbe non essere corretto o supportato da un precedente, non sono un avvocato), ma potrebbe essere sufficiente per consentire di avviare una conversazione con le persone giuridiche.

Dalla pagina di riferimento:

semplicemente combinando un lavoro protetto da copyright con un altro lavoro non crea un lavoro derivato. L'opera originale protetta da copyright deve essere modificata in qualche modo. Il lavoro derivativo che ne deriva deve "rappresentare un lavoro originale di paternità". Quindi, se il licenziatario non modifica il programma originale con licenza GPL, ma lo esegue semplicemente, non sta creando un lavoro derivato.


V'è la Appassembler Maven plugin che penso fa quello che è necessario (anche se non crea wrapper JSW). Crea uno script di shell (e un file bat) e raccoglie tutti i jar dell'applicazione in una directory. Può facoltativamente essere configured per creare configurazioni Daemon basate su JSW.

Ecco una configurazione di esempio che genererà l'applicazione standalone nella cartella target/appassembler e genererà i file wrapper JSW nella directory target/appassamer/jsw/myApp. Si noti che l'obiettivo di assemblaggio è legato alla fase di test di integrazione per garantire la creazione del barattolo del progetto. Per generare il percorso di uscita mvn verificare o per generare solo gli involucri di servizio corrono pacchetto mvn:

<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> 

Per riferimento i file generati sono i seguenti:

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 - grazie per il risposta. Inizialmente avevo fatto qualcosa del genere, ma la licenza di JSW è troppo restrittiva per me (beh, il mio datore di lavoro!). A proposito, è possibile configurare Appassembler dal progetto principale POM su un progetto con più moduli? L'unico modo per capirlo era creare un nuovo modulo con il lavoro specifico di creare gli script di servizio (e RPM nel mio caso) che funzionava dopo che tutti gli altri moduli erano stati impacchettati ... – Lehane

+0

Se si esegue il montaggio obiettivo sul modulo che dipende da tutti gli altri, quelle dipendenze saranno impacchettate nella directory di appassembler. Quindi probabilmente non verrebbe eseguito sul tuo aggregator pom, ma sul modulo con la classe "principale" –

+0

anche la licenza GPL non è così restrittiva come le aziende tendono a credere. Leggi questo: http://www.sitepoint.com/article/public-license-explained/ –