Introduction
The PluginFramework library provides a system of plugins that can freely enhance the functionality of the system in which they are installed. The module architecture allows declaratively to provide any functionality (e.g. support for Spring MVC) for a plugin.
The plug-in mechanism is based on OSGi. This allows plug-ins to be dynamically launched and updated and the use of different versions of libraries.
Configuration
All the required configuration of the plug-in mechanism must be in the suncode-plugins.xml file (in classpath).
The suncode-plugins.xml file primarily contains configuration related to OSGi and visibility of system classes in plugins.
Example configuration
<?xml version='1.0' encoding='utf-8'?> <suncode-plugins > <home-directory>../plugins</home-directory> <osgi strict-export="true"> <bootdelegation> <!-- Core libs --> <package>org.springframework.*</package> <package>org.hibernate.*</package> <!-- Proxy - required if using spring and hibernate--> <package>javassist.*</package> <package>org.aopalliance.*</package> </bootdelegation> <export> <package version="1.4.0">org.apache.commons.io</package> <package version="1.4.0">org.apache.commons.io.filefilter</package> </export> <exported-packages> <pattern>com.**</pattern> <pattern>org.**</pattern> <pattern>net.**</pattern> <pattern>javax.**</pattern> </exported-packages> <excluded-packages> </excluded-packages> </osgi> </suncode-plugins>
Description of each section of the configuration file:
| Name | Required | Description |
|---|---|---|
| home-directory |  | Indicates the home directory of the plugin mechanism. Plugins and other required settings will be saved in this directory. The path can be absolute or relative to the server. The plug-in mechanism does not use a database. All required data is kept in the specified directory. Deleting the directory will remove all installed plug-ins. |
strict-export | Default true - defines whether versions of exported packages should come from the manifest in case of OSGi bundles. Flag for compatibility issues | |
| bootdelegation | The OSGi setting (http://wiki.osgi.org/wiki/Boot_Delegation). Indicates what classes should always be loaded from the classloader that loaded this plug-in mechanism. The bootdelegation setting always includes the entry com.suncode.plugin.framework.* - loading all plugin mechanism classes from the system classloader Setting this property is necessary if the plug-ins use a proxy, for example - ImportPackages section does not contain such a package and the class can't be found. You can avoid this problem by setting bootdelegation or adding appropriate entries in MANIFEST.MF VisualVM Profiler If Profilera VisualVM exceptions occur when using VisualVM Profiler to profile plug-ins, add an entry to bootdelegation: org.netbeans.lib.profiler.* | |
| export | A list of packages exported from the system regardless of whether they appear in classpath or not. Configuration can be used, for example, to define a different version of the exported package. | |
| exported-packages | A list of template (ant style) packages to be exported to the OSGi environment. All jar files and directories in the classpath are scanned. The patterns are ant style expressions:
In OSGi, packages are also identified by version. Therefore, the exporter tries to determine the package version by reading the name of the jar file or the information in MANIFEST.MF or in files created by Maven. If the classes are not included in the jar file, there is no possibility to read the package version. In that case, they are assigned version 0.0.0 | |
| excluded-packages | A list of patterns (ant-style - as in exported-packages) of packages to be excluded from export to the OSGi environment. |
The first launch of the plug-in mechanism involves creating a home directory and scanning the entire classpath for packages/classes that meet the given requirements. This is a very time-consuming process (even several minutes - depending on the machine).
After the first run, a cache of packages is created, which speeds up subsequent runs.