Plugin-based applications (by alaric)
However, making an application plugin-based doesn't always work so well. Back in 2001, I had to take over maintenance of a JBoss. I've no idea what it's like nowadays, so don't take this as an insult to current JBoss, but at the time it was composed of a bunch of MBeans. All well and good, but it was never clear what they all did. They seemed to be an endless list of connectors and adapters and providers and pools and managers. The problem, I suspect, was that the JBoss developers, wishing to use the management side of MBeans, had converted every module of their application into an MBean; but also wishing to have a good plugin architecture, they'd then made their application into a kind of dynamic MBean registry. So we had a load of compulsory plugins that had to be loaded to make JBoss work properly, specified in the same configuration file as the actual optional plugins, such as choosing which data storage backend to use, whether to run an in-JVM servlet container, and so on.
I think that plugins should only be plugins if they're truly optional, otherwise you'll confuse the user who has to choose which plugins to run. By all means have a dynamic module registry inside your application, and upon startup have all the core modules register themselves in it to provide a centralised management interface, as well as having plugins registered in it as well when they are loaded. But keep the plugin registry for optional things. Sure, you may have certain types of plugin - authentication plugins, for example - that the system may only have one (not zero, not two or more) of active at once; but as long as the system doesn't care which plugin you have active, then they're still optional.
Fri 15th Sep 2006 2:13 pm 
Subscribe