Developing lightweight spring plug-ins based on eclipse

Abstract This article describes how to use the spring framework as a platform in eclipse to create lightweight plug-ins that seamlessly integrate with your existing Java EE applications.

I. INTRODUCTION

Generally, enterprise software products require customization at the client side, and typically require updates when customers have to modify the configuration of their core products to introduce their own customizations. With highly modular software that is easily scalable and scalable, plug-in technology can provide a perfect solution for this typical location.

Note 1-What is a plugin? What kind of code does a plugin consist of?

Among the many definitions, I think the best definition is defined in the Eclipse Project: A plug-in is a code contribution that can add code to a well-known extension point in a system. In other words, a plug-in is a well-defined code package (such as a jar file or directory) that provides sufficient configuration to enable the insertion and activation of itself in a particular well-known location in the system.

The plug-in itself can also define extension points that other plug-ins can extend. An extension point defines a language interface (the plugin will provide one of its implementations) and the components that use the discovered plug-in. An extension point can accept plug-ins that are dynamically discovered and configured at run time.

With a plug-in environment with well-defined extension points, the core product is free to upgrade, and the plug-in itself can be released and upgraded according to an independent plan. For example, with my open source Classpath Assistant Project (based on the Eclipse plug-in framework), I can upgrade my eclipse as usual, and I can easily release an updated version of my own plug-in.

In particular for Java developers, is it not a plug-in for the existing EE component (Reference annotation 2-J2EE component)? The plug-in provides a better upgrade technology than the other. You can imagine that many of your ejbs are built by different development teams, and then you can integrate them into one application when you understand that they work well. A plug-in architecture should be allowed for this level of component.

Note 2-J2EE component is not a plug-in?

Yes, the Java EE components, such as EJB and servlet, are not plug-ins. Although they all have a certain degree of "pluggable" (which means you can swap an EJB or servlet implementation), configuring them is not as clear and crisp, and they lack the easy upgrade capabilities of a plugin. For example, the servlet cannot combine code with configuration. Therefore, although you can package a servlet implementation in its own jar file, you often need to modify web.xml so that the servlet container can recognize it.

At first glance, EJBs seem more like plug-ins-they contain publication descriptors that provide information about themselves. However, EJBs are not plug-ins, because, typically, they require an external configuration (a reference in the ear's application.xml) and, typically, they refer to each other in their respective release descriptors. Both of these features make an EJB unable to be "plug-in-enabled."

With the Beanfactorypostprocessor interface of the popular spring framework, developers can easily create a lightweight plug-in framework. This article just wants to discuss how to do this, and to show you a working example of using a lightweight plug-in.

Two. Prepare your plugin platform

Before your platform can support pluggable components, it needs to meet the following two criteria:

Component must be discovered by itself. You've learned that the Java EE component cannot be the exact reason for a true plug-in. Typically, you should find an external configuration file that needs to be upgraded so that the platform can perceive the new code.

The component must contain enough information to integrate or configure itself within the application.

If you just add code that doesn't need to collaborate with the system (that is, loosely coupled), then automatic discovery is simple. The real challenge is to combine the self discovery with tight integration.