Mejores prácticas para hacer referencia a un módulo externo en un proyecto Java

Question

Tengo un proyecto Java que espera que los módulos externos se registren con él. Estos módulos:

• implementar una interfaz en particular en el proyecto principal
• se empaquetan en una uni-jar (junto con cualquier dependencia)
• contener algunos meta-información legible por humanos (como el nombre del módulo) .

Mi proyecto principal debe poder cargar en tiempo de ejecución (por ejemplo, utilizando su propio cargador de clases) cualquiera de estos módulos externos. Mi pregunta es: ¿cuál es la mejor manera de registrar estos módulos con el proyecto principal (prefiero mantener este Java simple, y no usar frameworks/bibliotecas de terceros para este problema aislado)?

Mi solución actual es mantener un único archivo .properties en el proyecto principal con key = name, value = class | delimiter | human-readdable-name (o coordine dos archivos .properties para evitar el análisis del delimitador). En tiempo de ejecución, el proyecto principal se carga en el archivo .properties y utiliza las entradas que encuentra para controlar el cargador de clases.

Esto me resulta muy divertido. ¿Hay una mejor manera de esto?

Answer 1

El enfoque estándar en Java es definir un proveedor de servicios. Véase,

http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider

Answer 2

Deje que todos los módulos expresen sus metadatos a través de un archivo xml estándar. Llámalo "my-module-data.xml".

En su arranque principal del recipiente se busca una ruta de clases *: mi-módulo-data.xml"(que puede tener una clase FrontController) y los delegados de los módulos individuales FrontController clase haga lo que quiera :)

también en google de la primavera en OSGi y su mana puede ser útil aquí.

Answer 3

Ampliando @ZZ Coder ...

El patrón del proveedor de servicios mencionado, y utilizado internamente dentro del JDK, ahora está un poco más formalizado en JDK 6 con ServiceLoader. El concepto se amplía aún más con el Netbeans Lookup API.

La infraestructura subyacente es idéntica. Es decir, ambas API usan los mismos artefactos, de la misma manera. La versión de NetBeans es solo una API más flexible y robusta (que permite servicios alternativos de búsqueda, por ejemplo, así como la predeterminada).

Por supuesto, sería negligente no mencionar los estándares dominantes, más "pesados" de EJB, Spring y OSGi.