
sbp introduce plugin oriented programming to Spring Boot. It is inspired and builds
on top of Pf4j project.
Why we need plugin for Spring Boot?
- Spring boot is good, but it is monolithic. It means you have to delivery the whole application
for every single code change every time.
- We need a modern framework with flexibility and extensibility to rapidly deliver solution
for complex business scenario.
- Not all projects need to consider scaling at the beginning stage, like Spring Cloud does.
- With sbp, we could think in micro service architecture only with Spring Boot,
but no need to worried too much about "cloud native" things, like service discovery, traffic control, etc.
- It's a medium level preference between monolithic Spring Boot application and distributed
Spring Cloud application.
Feature / Benefits
- Turn monolithic Spring Boot application to be MODULAR.
- Much more LIGHTWEIGHT development and deployment for spiral extensible architecture.
- Install/update/start/stop plugins ON THE FLY.
- FULL STACK Web/Rest server-side features powered by Spring Boot, including:
- controller for request handling
- persistence (Spring Data/JPA/Jooq/Plain SQL)
- security
- AOP
- resource loading
- Code and test plugin project as STANDALONE Spring Boot project.
- NO extra knowledge NEED TO LEARN as long as you are familiar with Spring Boot.
- NO XML
- OSGi based server need a server container to deploy, which is not cloud friendly.
- OSGi configuration is complex and strict, the learning curve is steep.
- Bundle cannot be run standalone, which is hard for debug and test.
Spring dm server has been dead, and its successor Virgo is now still struggling to live.
vs Spring Cloud
- Spring Cloud does not aim to solve similar problem as
sbp
, but so far it maybe the
best choice to solve application extension problem.
- With sbp, you will no need to consider too much about computer resource arrangement,
everything stick tight within one process.
- Again, sbp is good for medium level applications, which have problem to handle business
change rapidly. For large scale application, Spring Cloud is still your best choice.
- sbp should be able to live with Spring Cloud. After all, it is still a Spring Boot
application, just like any single service provider node in Spring Cloud network.
Getting Start
Create app project
- Create a Spring Boot project with multi sub project structure.
- For Gradle, it means multiple projects
- For Maven, it means multiple modules
- Take the demo projects for reference.
- Introduce
sbp-spring-boot-starter
to dependencies.
- Maven
<dependency>
<groupId>org.laxture</groupId>
<artifactId>sbp-spring-boot-starter</artifactId>
<version>0.1.4</version>
</dependency>
- Gradle
dependencies {
implementation 'org.laxture:sbp-spring-boot-starter:0.1.4'
}
- Latest master code is always available with version
-SNAPSHOT
- Add belows to
application.properties
.
spring.sbp.runtimeMode = development
spring.sbp.enabled = true
# remember to add this line in case you are using IDEA
spring.sbp.classes-directories = "out/production/classes, out/production/resources"
- Add anything you want in this project like
Controller
, Service
, Repository
, Model
, etc.
- Create an empty folder named
plugins
.
Create plugin project
- Create a plain Spring Boot project in the
plugins
folder.
- Add
plugin.properties
file to the plugin project.
plugin.id=<>
plugin.class=demo.sbp.admin.DemoPlugin
plugin.version=0.0.1
plugin.provider=Your Name
plugin.dependencies=
- Introduce
sbp-core
to dependencies.
-
Add Plugin class
public class DemoPlugin extends SpringBootPlugin {
public DemoPlugin(PluginWrapper wrapper) {
super(wrapper);
}
@Override
protected SpringBootstrap createSpringBootstrap() {
return new SpringBootstrap(this, AdminPluginStarter.class);
}
}
- Add anything you want in the plugin project like
Controller
, Service
, Repository
, Model
, etc.
Everything is done and now you could start the app project to test the plugin.
Checkout the demo projects for more details
- demo-shared: Shared code for app and plugin projects.
- demo-security: Security configuration demonstrate how to introduce Spring Security and secure your
API via AOP.
- demo-apis: Class shared between app\<->plugins and plugins\<->plugins need to be declared as API.
- demo-app: The entry point and master project. It provides two
SpringApplication
DemoApp
does not have Spring Security configured.
DomeSecureApp
include Spring Security, so you need to provide authentication information
when access its rest API.
- plugins
- demo-plugin-admin
- Demonstrate Spring Security integration to plugin projects
- Demonstrate Spring Boot profile
feature support.
- demo-plugin-author: Demonstrate share resource (like DataSource, TransactionManager) between
api/plugins.
- demo-plugin-library: Demonstrate using Spring Data/JPA.
- demo-plugin-shelf: Demonstrate api expose and invocation between plugins.
- Every single projects with
SpringApplication
could be run standalone.
- It is basically a skeleton project that you could starts your own project. It almost contains
everything we need in the real project.
Documentation
License
/*
* Copyright (C) 2019-present the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/