sbp (Spring Boot Plugin)

sbp provides a lightweight, spiral expansion architecture for Spring Boot applications with the following capabilities:

• Plugin Lifecycle Management: Supports online installation, upgrading, starting, and stopping of plugins.
• Full-Stack Spring Boot Integration: Plugins can leverage the entire Spring Boot ecosystem, including:
  • Controllers (@Controller, @RestController)
  • RouterFunction and WebFlux
  • Static resource loading and template engines (Freemarker, Velocity, Thymeleaf)
  • Persistence middleware (Spring Data, JPA, jOOQ, MyBatis Plain SQL)
  • Spring Security and AOP
• Development Workflow: Allows developing, debugging, and testing plugins within an independent, executable Spring Boot project.
• Low Learning Curve: Requires only Spring Boot knowledge; no additional framework expertise is needed.
• Configuration: Uses NO XML.

This is the simplest and recommended way to handle persistence in sbp. You can share a single DataSource from the main application to its plugins using sbp bean management. This provides local transaction support.

Supported Middlewares:

• JdbcTemplate
• Jooq
• Mybatis

Note: JPA/Hibernate is not a suitable option for this specific approach because of how it manages internal state and EntityManagers.

See SharedDataSourceSpringBootstrap for implementation details.

The sbp framework allows you to extend security control from the main application down to individual plugins. This enables the entire application to run under a unified security policy.

Because security requirements vary by use case, sbp does not provide a one-size-fits-all security implementation. Instead, it provides the infrastructure to integrate your own Spring Security configuration. A reference implementation can be found in the demo-security project.

To use Spring Boot frameworks or libraries (like JPA, Quartz, etc.) within a plugin environment, you must make them dynamically registerable/unregisterable. This is achieved by extending IPluginConfigurer.

Configurers are invoked during the plugin's ApplicationContext bootstrap process, allowing you to register or unregister plugin resources within the main ApplicationContext.

public class LibraryPlugin extends SpringBootPlugin {

    public LibraryPlugin(PluginWrapper wrapper) {
      super(wrapper, 
        // SbpWebConfigurer is mandatory, so it will be config automatically.        
        new SbpJpaConfigurer(new String[] {"demo.sbp.library.model"}),
        new SbpSpringDocConfigurer()
      );
    }
}

When deploying a plugin for SBP, the packaging format depends on whether your plugin has 3rd-party dependencies:

1. No 3rd-party dependencies: A normal JAR is sufficient. However, you must sign the JAR manifest with the required plugin attributes.
2. With 3rd-party dependencies: The "Fat-jar" format (a JAR inside a JAR, such as a standard Spring Boot executable JAR) is not supported. You must use one of two workarounds:
   • Flat lib jar: Extract all classes and resources from your dependency JARs and pack them into a single, flat JAR file alongside your plugin classes.
   • Zip format: Use the PF4J zip format. Place all 3rd-party dependency JARs under a /lib directory and your plugin classes under a /classes directory, then package everything into a .zip file.

The sbp project extends the standard SpringApplication via a class called SpringBootstrap. This allows the system to bootstrap a dedicated plugin ApplicationContext alongside the main application context.

Note on Classloading: While sbp is based on pf4j, it implements a custom rewritten classloading behavior that differs significantly from the original pf4j implementation.