Integration with platonos plugin engine

[darabi]

I don't know if there is general interest in a plugin architecture. In search of one, I found the platonos pluginengine project:

http://platonos.sourceforge.net/quickstart/

which uses a simple plugin.xml configuration file, which defines extension points for or dependencies on other plugins. Plugins can either be deployed in a jar or as a file system directory hierarchy.

I have tried to integrate platonos into the Spring RC. I have an initial version which is partly tested (immediately after coding it, I had to leave
it to do some other work).

The idea behind it is: if an extension point has a name which is equal to a bean name in the application context and no class is specified, then a new extension is constructed during the extension loading process and
provided to the extended plugin.

I think I cannot express it very well, so, here is an example:

plugin.xml contains

<plugin start="true">
   <uid>my.data.plugin</uid>
   <name>My Data Plugin</name>
   <lifecycleclass>xyz.plugin.data.DbMaintenance</lifecycleclass>
   <extensionpoints>
      <extensionpoint name="dataSource" />
   </extensionpoints>
</plugin>

Extension point "dataSource" is a bean which is configured in the main application's spring context.

The plugin java code which uses the bean called dataSource looks like this:

public class DbMaintenance extends SpringPlugin {

	private DriverManagerDataSource ds;

	public DbMaintenance() {
		super();
	}

	protected void onInitialize() {
		// do something useful
	}

	protected void onStart() {
		log.info("Starting");
		ds = (DriverManagerDataSource) getBean("dataSource");
		log.info("data source driver: " + ds.getDriverClassName());
		// ...
	}

	protected void stop() {
		log.info("Stopping");
		// clean up by de-referencing the extensions
		ds = null;
	}

}

Additionally, I have introduced a default spring configuration file 'plugin-context.xml' which can be used to configure beans which
are not injected from the application context, but defined in the plugin itself.

Using this method, a bean 'hibernateDao' defined in plugin-context.xml can be retrieved with

	HibernateDao dao = (HibernateDao) getBean("hibernateDao");

I found this a convenient way to avoid app context creation code.

If there is interest in this code, I could test it and submit a patch for platonos and for spring rich client.


Kambiz

[jfcloutier]

I am interested. I need a plugin architecture. My application must be capable of being modified dynamically as it discovers and loads/unloads plugins.

It seems to me that your extension might belong in the Spring framework proper, not RC. Not only client apps would benefit from plugins.

Also, shouldn't the extension point always be defined as an interface (as Platonos has it), with an extension possibly supplied as a bean? You define the extension point as a bean. That does not seem right or am I missing something?

How about this:

<plugin start="true">
   <uid>my.data.plugin</uid>
   <name>My Data Plugin</name>
   <lifecycleclass>xyz.plugin.data.DbMaintenance</lifecycleclass>
   <extensionpoints>
      <extensionpoint name="dataSource"  interface="javax.sql.DataSource"/>
   </extensionpoints>
</plugin>

<plugin>
   <uid>my.data.extension</uid>
   <name>Extension pluging</name>
   <extensions>
      <extension uid="my.data.plugin" name="dataSource" bean="myDataSourceBean" /> <!-- bean defined in plugin -->
   </extensions>
</plugin>

The onStart() method in DbMaintenance is unaware that the extension comes from a Spring bean. It iterates over extensions as in the Platonos examples.

The question that needs to be resolved is what exactly is the nature of the relationship between Platonos and Spring.

[darabi]

The problem that I tried to solve for myself was: how can I hand over a Spring configured bean which exists in my application context to a plugin. In fact, this is a special case of the general use which you outline.

What you propose for plugins which extend others, is absolutely necessary and should be implemented:

   <extensions>
      <extension uid="my.data.plugin" name="dataSource" bean="myDataSourceBean" /> <!-- bean defined in plugin -->
   </extensions>

The question that needs to be resolved is what exactly is the nature of the relationship between Platonos and Spring.

Well, this is why I asked. I have solved my problem which can be roughly sketched as follows:

- I need a way of delivering small, relatively independent modules ideally in form of a jar file to my customers.

- If the jar is put in a certain directory, it should be loaded into the main application and start its work.

- most such modules need services from the main application or from other plugins to be able to do their work. These services already exist either in the main application context or in the plugin context of other plugins

Instead of creating an own api e.g. like the one Andy proposed a while back (http://forum.springframework.org/showthread.php?t=10657), I took platonos and tried to adapt it to my needs.

And it works well: I don't have to take care of class loader issues. I just drop the jar into a directory, which is watched by the PluginManager:

	<bean id="pluginLauncher" class="org.springframework.richclient.plugin.PluginEngineLauncher">
		<property name="uniqueId" value="MyApp" />
		<property name="location" value="plugins" />
	</bean>

Kambiz

[jfcloutier]

I have the same requirements: dynamically extending a running application without class loader snafus. In fact I want an app that is configured with Spring and mostly assembled and extendable on-the-fly from plugins.

The more specific question is: what should the relationship be between BeanFactory/ApplicationContext and PluginEngine?

[darabi]

The more specific question is: what should the relationship be between BeanFactory/ApplicationContext and PluginEngine?

The PluginEngine takes care of loading (possibly even unloading) the plugins and satisfying the extension points. I just sits there and waits for new jars to be dropped into the watched directory. If if finds a new plugin, it loads and starts it. This functionality fits into a 64 KB jar.

In my implementation, each plugin has a context which is set up automatically. Beans which are not configured in plugin-context.xml can be accessed by injecting them either from other plugins or from the main application's app context.

And you don't even have to bother whether a special bean which you are requesting from the BeanFactory is defined in the context of your plugin, or not.

Kambiz

[jfcloutier]

Did you look at the Java Plugin Framework (http://jpf.sourceforge.net/index.html)?

[darabi]

No, I didn't know of it. At a glance, it looks good, too. The DTD describes many parameters which can be defined for an extension.

If there were others interested in a plugin architecture, I would have a closer look at it.

Following the Spring philosophy, one could try to integrate both.

But, I'm not sure whether there's enough interest in it.


Kambiz

[jfcloutier]

I just started looking the implementation of both Platonos and JPF. One important difference is that JPF is defined with interfaces that it implements. So it is meant to be easily extended. Platonos is all classes, no interfaces.

I also note that JPF does not define an interface as part of the contract between an extension point and an extension, the way Platonos does. Which can be remedied.

JPF's API seems to lead to more verbose code than Platonos, but JPF should be easier to extend than Platonos to play along with Spring.

There's also the Eclipse OSGi plugin framework which can be lifted and reused. I saw a presentation last night at the Maine JUG of a project who did just that (Quantrix - which is a very cool Java-based product).

[jfcloutier]

OSGi is the Java plugin standard (adopted by Eclipse) and there's a high-quality open-source implementation from Knopflerfish (rolls off the tongue, doesn't it?)

I am going thru the doc and I am pretty sure that's what I'll use in conjunction with Spring.

[darabi]

Wow, this is a full-fleged osgi implementation!

I hope there is a simple way of integrating it with spring rich.

Looking forward to your results, Jean-Francois.

Kambiz