After Poc, I chose to abandon OSGI

TIPS:

If your company allows the cost of refactoring the old system or allowing the use of OSGI’s third-party framework, and the ROI is positive, it can still be used.

Runtime Version

The following questions are all based on the Equinox framework & integrating the Spring framework with BluePrint

  • OSGI
    • Org. Eclipse. Osgi 3.15.0 v20190830-1434
  • Equinox version
    • Equinox 4.13
  • Spring Framework
    • 5.0.4 P
    • 3.0.0
  • blueprint
    • 3.0.0. M1
  • mybatis
    • 3.5.3
  • mybatis-spring
    • 1.3.2
  • mysql
    • + 5 + / 8

The status quo

Prerequisites for the following solution: No third-party frameworks (Camel/ Karaf…) .

  • Spring3 integration uses Spring3 to implement SpringMvc integration, but does not support Restful support. After spring3, there seems to be no one to maintain the osgi version jar packages, and to use higher versions, you have to generate your own bundles.
  • Spring5 integrated basic Spring Bean injection has been successful through XML, but there are many missing bundles currently, most importantly JDBC & Transaction. Spring was upgraded to Spring-TX after 3.2, and osGi versions are not available. As a result, most of our existing projects need to be reconfigured, which is a huge amount of work (equivalent to rewriting the Service).

The problem

  1. How do I provide REST Service exposure without using a third-party framework?

    Expose rest service utilization, the osgi own HttpService service, again through the org. Eclipse equinox. Servletbridge. BridgeServlet service bridge to go out

  2. As for the existing Single application of SpringMVC, how to package all methods in each controller as bean services in the bundle and expose them uniformly to the outside world instead of one by one?
  3. How do I use Spring Annotations in bundles?
  4. How do you generate an existing SpringMVC project directly into a full bundle to provide exposed services with little or no intrusion into the existing project?

For a number of reasons:

  1. Community stagnant maintenance, older technology
  2. Third-party open source frameworks can do this, but the problem is that it’s too much of a change to our existing system.
  3. The problems we encounter in the future cannot be solved externally, but we can only expand the bottom layer.
  4. For junior and intermediate friends, the cost of learning is too high (I have consulted most of the materials at home and abroad)
  5. The cost of retrofitting the original system would be too high if a new project could not be written from scratch.
  6. .

alternative

I chose to abandon this solution and use the hot plug provided by Servlet 3.0 to implement the plug-in mode, which only requires reloading the application context. Therefore, I recommend that you deploy multi-instance nodes and use grayscale publishing to reduce the impact when upgrading the service.

Running life garden | | blog segmentfault | spring4all | CSDN Denver | | OSChina book | | Jane headlines | zhihu | 51 cto