2009-08-21 21 views
18

¿Cuál es la mejor manera de crear una aplicación java que se pueda ejecutar usando 'servicio' en Linux? Iba a usar el JSW disponible here, pero no puedo usar la licencia (la licencia es GPL o cuesta dinero por lo que puedo decir). Necesitaría una licencia de estilo apache.Herramienta para crear un servicio demonio Java en Linux

Estoy usando maven para compilar, por lo que sería grandioso si fuera posible crear el servicio usando un plugin maven, pero cualquier otra sugerencia sería genial.

He visto Apache Commons Daemon, ¿hay un complemento maven para esto? Documentación parece escasa, por lo que un ejemplo práctico de esto sería bueno ...

Gracias

Respuesta

20

Servicios en Linux sólo son shell scripts que inician procesos de fondo. Eche un vistazo en /etc/init.d - puede abrir los archivos en un editor de texto. Todo lo que necesita es un script bash que responda a los parámetros start y stop de manera apropiada (por ejemplo, start iniciará su servicio y registrará el ID del proceso en una ubicación conocida, stop matará el proceso con el PID del archivo que creó), y luego colóquelo en /etc/init.d.

Tenga una mirada en Init Scripts y An introduction to services, runlevels, and rc.d scripts

13

Por lo que yo sé que no es un plugin de Maven, ya sea para Apache o Daemon Akuma. Aunque podría intentar invocarlos desde una construcción Maven utilizando el maven-exec-plugin.


En cuanto a sus empresas reservas sobre el uso de productos con licencia GPL, vale la pena leer sobre las implicaciones de su uso. No es tan virulento como temen las corporaciones. Aquí hay un interpretation of the GPL. Por supuesto, no tiene ningún peso en la ley (y puede no ser correcto o respaldado por un precedente, no soy un abogado), pero podría ser suficiente para permitirle comenzar una conversación con su gente legal.

Desde la página de referencia:

simplemente la combinación de una obra con derechos de autor con otro trabajo no crea una obra derivada. El trabajo original con derechos de autor debe ser modificado de alguna manera. El trabajo derivado resultante debe en sí mismo "representar una obra original de autoría". Entonces, si el licenciatario no modifica el programa original con licencia de GPL, sino que simplemente lo ejecuta, no está creando un trabajo derivado.


No es el Appassembler Maven plugin que creo que hace lo que usted necesita (aunque sí crea envolturas JSW). Crea un script de shell (y un archivo bat) y recopila todos los archivos jar de aplicaciones en un directorio. Opcionalmente, puede ser configured para crear configuraciones de Daemon basadas en JSW.

Aquí hay una configuración de ejemplo que generará la aplicación independiente en la carpeta destino/appassembler, y generará los archivos envoltorios JSW en el directorio target/appassembler/jsw/myApp. Tenga en cuenta que el objetivo de ensamblaje está vinculado a la fase de prueba de integración para garantizar que se cree el jar del proyecto. Para generar la carrera de salida mvn verificar o simplemente para generar los envoltorios de servicios se ejecutan mvn package:

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

Como referencia los archivos generados son los siguientes:

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 - gracias por la responder. Originalmente había hecho algo como esto, pero la licencia de JSW es ​​demasiado restrictiva para mí (¡y mi empleador!). Por cierto, ¿es posible configurar Appassembler desde el proyecto principal POM en un proyecto con múltiples módulos? La única forma que tenía de hacerlo era crear un nuevo módulo con el trabajo específico de crear las secuencias de comandos del servicio (y RPM en mi caso) que se ejecutaban después de que todos los otros módulos estaban empaquetados ... – Lehane

+0

Si ejecuta el ensamblado objetivo en el módulo que depende de todos los demás, esas dependencias se empaquetarán en el directorio appassembler. Por lo tanto, probablemente no se ejecute en su agregador pom, pero en el módulo con la clase "principal" –

+0

también la licencia GPL no es tan restrictiva como las corporaciones tienden a creer. Lea esto: http://www.sitepoint.com/article/public-license-explained/ –

Cuestiones relacionadas