2011-06-29 12 views
30

Cada paquete en mi proyecto OSGi tiene su propio BundleActivator, que creo que es normal. Esto pasa el actual BundleContext, que es útil para obtener referencias de servicio y otras cosas.¿La mejor técnica para obtener el contexto del paquete OSGi?

Sin embargo, de las clases en mi paquete, ¿cómo puedo obtener el BundleContext? Asignarlo a un campo estático público en el BundleActivator es una mierda y pasarlo como un argumento también es una mierda. ¿Hay una manera más inteligente?

+1

En segundo lugar esto: El activador predeterminado generado por el PDE es muy cuestionable. Considero que esto es un error: https://bugs.eclipse.org/bugs/show_bug.cgi?id=392919 – oberlies

Respuesta

44

Puede usar FrameworkUtil.getBundle(ClassFromBundle).getBundleContext().

Ver FrameworkUtil JavaDoc.

+2

Gracias, esta técnica es exactamente lo que estaba buscando. – xconspirisist

+1

¿Cómo es eso mejor que una variable estática en su Activador? En lugar de su propia clase, ahora depende de un método de marco estático. Esto hace que su código sea aún más difícil de probar. –

+1

No es necesariamente mejor, pero 1. no es necesario escribir el activador 2. puede obtener el contexto de otro paquete. En cualquier caso, RaduK tiene razón acerca de centralizar el código específico de OSGi. –

-4

No hay magia aquí. Necesita alguna forma de proporcionar la información a las otras clases. Por lo tanto, está disponible a través de la pila de llamadas o en algún lugar conocido (por ejemplo, estático).

13

Una buena práctica al desarrollar paquetes OSGi en mi opinión es tratar de escribir el código OSGi lo más centralizado posible. De esta forma, si desea usar su código en un entorno que no sea OSGi, el esfuerzo de migración es mínimo.

Por lo tanto, no es una buena idea usar referencias estáticas o FrameworkUtil por todas partes. Ninguno de los dos está usando OSGi simple. Intente mirar iPOJO o los servicios declarativos.

+0

Un comentario perspicaz, gracias. Reconozco que las clases que se integran estrechamente con OSGi son malas prácticas, pero FrameworkUtil de la otra respuesta respondió la pregunta. Gracias también por las referencias a servicios declarativos, leeré sobre eso también. – xconspirisist

9

Otra alternativa es usar los servicios declarativos, que le permiten recibir el BundleContext en su método de activación. Por ejemplo, suponiendo que el uso del Bnd Anotaciones para DS:

@Activate 
public void activate(BundleContext context) { 
    // ... 
} 

Sin embargo, como dijo RaduK, que es mucho mejor si se puede escribir la mayor parte de su código en el estilo POJO sin necesidad de utilizar las API de OSGi como BundleContext.

Cuestiones relacionadas