Have no experience with (1) and agree (2) is too heavy weight.
Wouldn't it be possible to use the Service loader mechanism in commons? which I think can use OSGi services or the service loader, depending upon which environment it is in - Eric would obviously be the best person to comment on this? So although OSGi on its own would be too heavy weight - if running in an OSGi container there is no extra overhead, so the mechanism could be leveraged.
It's possible to use the service loading mechanism already in overlord-commons, but that assumes everything is on the classpath. A true plugin mechanism would presumably work at runtime. So we'd either need something else or else the overlord-commons loader would need to be enhanced in some way.
I agree that when running in an OSGi environment we should definitely use OSGi. That should be easy enough to do - it's just a matter of using the OSGi service registry.
The question is what to do when running in some other environment. I'm thinking that packaging up a plugin as a WAR (or something similar) is the way to go. We then just need a classloader that can understand a WAR format. Perhaps there is something open source we can leverage for this. WAR is nice because it can do what we need and is easy to produce. Whatever the unit of packaging is, it would need to include 3rd party dependencies inside of it - another reason WAR is a nice choice.
It would probably be worth our time to list out all of the functionality that would need to be provided by apiman plugins. I'll start and we can add content as we think of it:
- Policy Implementations
- Policy Definition meta-data (consumed by the management layer to show users what policies are available?)
- Components (used by policy implementations - examples include the Shared State Component and the HTTP Client Component)