[HiveMind] Pluggable modules?

[Christian Essl <ch...@yahoo.de>]

After quite some time, and after reading the Server Side articel
(http://theserverside.com/home/thread.jsp?thread_id=22371) another idea I
had about HiveMind. In the articel Zhengmao Hu posted some code to combine
HiveMind and Spring. I think that shows that people want to have the choice
and it fits good to the glue aproach of HiveMind.

I think HiveMind could integrate other Service frameworks (Carbon
http://carbon.sourceforge.net/ - good thing) if services could be Modules
registered with the Registry. An example:



<module id="some.module" version="1.0.0">
  <!-- new tag plugin-module: defines module(s) based on a service. The
module(s) name(s) are all prefixed with 'some.module.spring.'. And the
modules can be gotten from Registry.getModule("some.module.spring.(factory
specific)") -->
  <plugin-module id="spring" factory-id="springfactory">
	factory parameters
  </plugin-module>

  <!-- alternative which loads one module -->

  <plugin-module id="spring2" service-id="springmodule"/>

  <!-- the module factory -->
  <service id="springfactory" interface="org.hivemind.ModuleFactory">
    <schema>
      ...
    </schema>
    <invoke-factory service-id="BuilderFactory">
      <construct class="org....SpringModuleFactory">
       .....
      </construct>
    </invoke>
  </service>

  <!-- one module -->
  <service id="springmodule" interface="org.hivemind.Module">
   ...
  </service>
</module>

The factory inerface:
public ModuleFactory{
   public Module[] getModules(List parameters,String modulePrefix, Module
definingModule);
}

Obviously services and config-points gotten from such modules are not
managed by HiveMind but rather by the module implementation.

I think this could also be used to define custom transformers, rules etc,
or even to build a Registry on top another Registry and than intercept
calls to the Registry, load modules from different locations etc.


-- 
Christian Essl http://jucas.sourceforge.net


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org