Discussions

News: Create Lightweight Spring Plug-Ins—à la Eclipse

  1. Bryant Harris posted "Create Lightweight Spring Plug-Ins—à la Eclipse" on DevX recently, an article discussing how to "leverage the Spring framework as a platform for creating lightweight plug-ins that work seamlessly with your existing J2EE applications."
    One tenet of Eclipse is that everything is a plug-in. From the initial bootstrap of the system, to the Java development environment, to the online help—every contribution of code (even if that code is not Java code) is modeled as a plug-in. This approach has its elegance, but it dictates an industrial plug-in development environment complete with tools for managing the components, debugger support, etc. To their credit, Eclipse provides this, but server-side frameworks with this level of support do not exist (to the best of my knowledge). In server-side development, the established components of EJBs, JSP/Servlets, etc. don't lend themselves well to true plug-ins, which require real work to define and document an extension point. So treating everything as a plug-in would add significant work that probably wouldn't look very familiar to most J2EE engineers (a legitimate concern when trying to staff a team). With that in mind, I try to use the plug-in concept as a tool to target specific areas of customization. As such, leveraging Spring to create lightweight plug-ins that seamlessly work with your existing application and technology makes them very compelling. For the most part, your application remains a fairly vanilla Spring/J2EE application. This is not a trivial accomplishment, as in-house frameworks often crumble under their own weight as lack of documentation and attrition make them more of a burden than a benefit.
  2. EL4J plugins[ Go to top ]

    Thanks for the interesting article. We have a similar abstraction to your plugin abstraction in use for 2 years and in 16 projects and we are very happy with it. Our abstraction is called "module" and is based on the following: * A "module" abstraction in the build system (we currently use our own build system EL4Ant, but are migrating to maven) * A convention on how we name configuration files and a way to extend earlier spring bean configuration settings. So if we want e.g. to set up a performance measurement interceptor (we use the Jamon-Interceptor from Spring), we make a dependency on our "light-statistics" module in the build system and just relaunch the application. The default configuration of the "light-statistics" module automatically sets up the performance interceptor on all spring beans and makes the performance measurements available in JMX. One can easily override the set of beans to intercept. More on the module abstraction can be found in section (I) of http://el4j.sourceforge.net/docs/pdf/EL4J_IntroductionArticle1.pdf Our open-source framework that extends Spring is located here: http://el4j.sourceforge.net/ Cheers, Philipp
  3. People should really take a serious look at OSGi (http://en.wikipedia.org/wiki/OSGi), which has potential to revolutionize almost everything in Java. Eclipse for example already uses it behind its plug-in technology. OSGi is a stablished project backed by major companies, which solves many of Java problems regarding module versioning, extension, classloading, isolation and many others.
  4. Plug-ins and modules[ Go to top ]

    I'm pretty familiar with OSGI since my open source project is based on Eclipse. It is certainly well thought out and industrial strength. One of the areas I mentioned in this article is around developer environment. It's quite easy to throw together a component model (nearly every company I've ever worked for has created one), it's quite another to provide a useable development environment that doesn't have developers slogging away in XML files looking for the one place they forgot to add an entry. In this way Spring created a much more intuitive model that works well with agile development practices. The lightweight plug-in approach is immediately comfortable to anyone who is familiar with Spring. So in this way I think Spring as a platform for plug-in development has a place in shops that are not able to drastically rearchitect their system, but could slip in an unobtrusive framework like Spring. Bryant
  5. In Rod's keynote at SpringOne he discussed the future of Spring post 2.0. They are already working with OSGi on deployment features, versioning etc. I don't know if there is much information online yet, but it could be worth posting on their forums find out more about their plans.
  6. People should really take a serious look at OSGi (http://en.wikipedia.org/wiki/OSGi), which has potential to revolutionize almost everything in Java. Eclipse for example already uses it behind its plug-in technology. OSGi is a stablished project backed by major companies, which solves many of Java problems regarding module versioning, extension, classloading, isolation and many others.
    Not every project need the complexities of OSGi. While I agree that automatic versioning, classloader isolation and all, are very nice featurer to have, sometimes it can be simply too much. For my own pet project (shameless plug-in!), I have implemented a very simple yet very effective plugin system: a plugin is activated by dropping the corresponding jar file in the classpath. I don't think it can get any simpler! :-) Writing a plugin is also very easy: implement an interface (extension point), put a one-line properties file where indicated in the documentation and off you go. Once more, simple and effective. By carefully defining extension points, one can offer tremendous power to the user. Want anything that is not in the core product? Write a plugin! ________ MessAdmin, Notification system and Session administration for J2EE Web Applications
  7. For my own pet project (shameless plug-in!), I have implemented a very simple yet very effective plugin system: a plugin is activated by dropping the corresponding jar file in the classpath. I don't think it can get any simpler! :-)
    Mr. Harris' light weight plug-ins and OSGi also work this way.
  8. Hasn't HiveMind addressed the need for DI with extensibility? How is this different from what HiveMind offers? Note that HiveMind was based heavily on the ideas of Eclipse, in that everything is more or less a plugin.
  9. Well I guess the fact that it involves Spring and not HiveMind would be the first difference :-)
  10. Hasn't HiveMind addressed the need for DI with extensibility? How is this different from what HiveMind offers? Note that HiveMind was based heavily on the ideas of Eclipse, in that everything is more or less a plugin.
    OSGi is not DI, and there's quite a big difference between the two. Frameworks like Spring [core] and HiveMind handle the wiring of pojos together; OSGi manages bundles, and bundles != pojos. Note that I'm not trying to say one is better than the other -- it just depends on what you're doing.