Home/ Questions/Q 1048217
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T16:25:18+00:00

I’m building a J2EE application in which I want to allows plugins. I’m fairly

  • 0

I’m building a J2EE application in which I want to allows plugins. I’m fairly convince of the goodness of IoC framework, and so the application will have one to manage services.

Now, I want to allows plugins to be added as simple JAR dropped in the classpath + perhaps a simple configuration file to edit to activate them, in no way something looking like Spring XML config files.

Most of the plugin architecture will be base around strategy/pipeline/chain of command patterns: for example the best plugin for an action is chosen by strategy, several plugins add filtering actions to an user input thanks to a pipeline, and so one.

So, I want to be able to:

  • define service interfaces in the core application,
  • set-up core implementation for extensible services with the chosen pattern in the main application,
  • let third party plugins register themselves in these hooks.

The first 2 points are quite easy, with or without IoC. The last one seems more complex without support at the IoC container level, or at least there is a lot of plumbing to do (how to manage classpath/sevice discovery, how to manage service orders in pipeline when the context change (new plugins), how to manage service overriding, etc).

I do know that Tapestry5 is great in that regards[1], but I can’t find anything really relevant for Spring and Guice. And my company is more a String/Guice one than a T5 one (well, if I’m able to show that it’s the best solution…)

So I’m wondering:

  • if I missed some obvious documentation;
  • if my requirement are so specials;
  • if an IoC container is not the right tool for that, and I should look for OSGi or something else.

Thanks for any tips !

[1] http://tapestry.apache.org/tapestry5.1/tapestry-ioc/configuration.html

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’m not sure how this would work with exactly what you’re looking to do, but Guice’s basic mechanic for handling plugins is Multibindings. How you handle discovery of plugins is up to you, but there are a variety of choices including scanning the classpath for implementations of plugin interfaces, having plugins provide a Module that adds their implementation(s) to the multibinder(s), using a config file that lists the plugin implementation classes, etc.

    As the link mentions, you’d need OSGi if you need plugins to be addable at runtime with no restart.

    • 0