2009-01-12 13 views
7

Tengo una aplicación que se ejecuta como una colección de paquetes OSGi. Lo comienzo usando una envoltura muy pequeña que incrusta el marco de Felix. La necesidad de esa envoltura me irrita un poco, al igual que el hecho de que depende de Félix (mientras que la aplicación en sí misma podría funcionar igual en, digamos, Equinox), así que quiero deshacerme de ella, y usar el Félix predeterminado. lanzacohetes.acceder a los argumentos de línea de comandos del paquete OSGi

Lo único que realmente hace el envoltorio es pasar los argumentos de la línea de comandos al marco OSGi lanzado, para que un paquete pueda reaccionar ante ellos. Tenga en cuenta que en realidad no analiza los argumentos, simplemente empuja la cadena [] en mi aplicación.

¿Hay una manera estándar (o al menos una forma estándar de Felix) para acceder a los parámetros de la línea de comandos de un paquete, para poder eliminar el selector personalizado?

+0

¿Cómo esto resultó? ¿Fuiste con la opción de lanzamiento de framework al final sobre los parámetros de JVM? Si es así, ¿sería posible publicar alguna información sobre su solución? Gracias. – Chris

Respuesta

1

Probablemente no. Creo que el iniciador estándar de Felix realiza una validación de línea de comandos y solo acepta el dir del caché del paquete como argumento. Más de un argumento y el iniciador se cierra.

Puede usar las propiedades del sistema para pasar información en la línea de comandos, y creo que funciona no solo en felix sino también en otros contenedores de osgi, pero probablemente haga que su aplicación no sea muy fácil de usar.

+0

Sí. "-Dthis -DandThat" parece funcionar, pero en realidad es bastante feo ... – Thilo

2

Última respuesta, pero tal vez alguien lo encuentre útil.

Estaba teniendo bastante el mismo problema. Mi aplicación se ejecuta en OSGi pero tengo interfaces externas que debo cumplir, lo que implica leer los argumentos de la línea de comando.

La clave para esto es algo que se define en la nueva especificación 4.2 de OSGi, concretamente el lanzamiento de Framework. Puede leer sobre esto en la especificación Draft (que se encuentra en Draft en www.osgi.org) en la sección Capa de ciclo de vida.

Es una forma estándar de iniciar un marco OSGi (cualquier implementación que admita OSGi 4.2) desde una aplicación java independiente. Lo ingenioso es que no necesita saber qué implementación inicia (Felix, Equinox, ...) mientras se encuentre en CLASSPATH.

De esta manera, la aplicación de su iniciador lee los argumentos de la línea de comandos, crea una instancia e inicia una estructura OSGi y pasa los argumentos a su paquete (de la manera que desee). Lo que obtienes en la aplicación de inicio es un contexto del marco desde el que puedes comunicarte con tus paquetes.

A partir de Equinox 3.5M6 (creo, bueno al menos M6) esto es compatible. La última versión de Apache Felix también lo admite.

+2

Daría un millón de dólares por algunos enlaces salpicados en esta respuesta – drozzy

+1

El lanzamiento de un marco OSGI está bastante bien descrito, estoy de acuerdo, pero no tanto el "pasar los argumentos a su paquete". –

7

Si usa bnd (herramientas) puede usar su iniciador. Registra los argumentos de la línea de comando como una propiedad del servicio 'launcher.arguments'.

Esto funciona extremadamente bien cuando se combina con el comando bnd package. Este comando toma un proyecto bnd o un archivo bndrun que describe el entorno en ejecución (paquetes, propiedades, marco) y se convierte en un contenedor principal independiente. Entonces desarrollas y depuras en bndtools y cuando estás contento lo conviertes en un solo archivo ejecutable. Ejemplo:

@Component 
public class MyApp { 
    String args; 

    @Activate 
    void activate() { 
     System.out.println("Args: " + args); 
    } 

    @Reference(target="(launcher.arguments=*)") 
    void args(Object object, Map<String,Object> map) { 
     args = (String) map.get("launcher.arguments"); 
    } 
} 

# to turn into an executable 
bnd package myapp.bnd 
java -jar myapp.jar -a somearg *.file 
1

Soy consciente de que ha buscado únicamente a Felix. Entonces, esta solución solo de Equinox podría no ser útil. Lo dejo aquí, porque alguien más podría tropezar con esta pregunta y ejecutar Equinox.

Desde cualquier paquete y cualquier marco, puede ser difícil. Si usa org.eclipse.core.runtime.punto de extensión de aplicaciones, debe ser fácil. Condición previa: NO pasa la consola como parámetro.

public class Application implements IApplication { 

    @Override 
    public Object start(IApplicationContext context) throws Exception { 
     String[] args = (String[])context.getArguments().get("application.args"); 
     // args.length == 0 if no arguments have been passed 
    } 
} 

referencia en plugin.xml

<plugin> 
    <extension 
      id="myApp" 
      point="org.eclipse.core.runtime.applications"> 
     <application> 
      <run class="package.Application" /> 
     </application> 
    </extension> 
</plugin> 
Cuestiones relacionadas