Skip to end of metadata
Go to start of metadata

Introduction

Each plugin has its own application context (ApplicationContext), where its components, controllers, imported services etc. are registered. This allows the plug-in to be written just like any other application using SpringFramework.

The context can be configured in 2 ways:

  1. via the plugin-context.xml file in the /META-INF/spring/ directory
  2. via a class with the @Configuration annotation

XML configuration

If the plugin contains the /META-INF/spring/plugin-context.xml file XmlOsgiPluginContext is created based on it.

If the project builds Maven, the file should be in src/main/resources/META-INF/spring/plugin-context.xml

 

The configuration file is a standard springframework application context configuration file and can look like this:

plugin-context.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xmlns:tx="http://www.springframework.org/schema/tx"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.2.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.2.xsd">
	
	<!-- Enabling plugin scanning for @Component -->
	<context:component-scan base-package="com.suncode.plugin.tutorial" />
	
</beans>

Configuration via an XML file has its pros and cons. Ultimately, it all depends on the skills of the plug-in author.

Java configuration

Since SpringFramework 3, it is possible to configure the application context entirely using Java classes marked with the @Configuration annotation.

If the plugin engine does not find the /META-INF/spring/plugin-context.xml file it will create a default application context that scans the entire plugin for @Component (and thus also @Configuration).

The configuration class in such a case is not needed at all, but usually we want additional functionality like database access, transactivity, etc.

Example configuration (registers only 1 bean of class String):

Java Configuration
package com.suncode.plugin.tutorial;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class Config {
    @Bean
    public String someString() {
        return "asd";
    }
}

 

 

 

 

  • No labels