Wstęp

Biblioteka PluginFramework dostarcza system wtyczek, które mogą dowolnie zwiększać funkcjonalność systemu, w którym zostaną zainstalowane. Architektura modułów pozwala w sposób deklaratywny na dostarczanie dowolnej funkcjonalności (np. wsparcie dla Spring MVC) dla wtyczki.

Mechanizm wtyczek opiera się na OSGi. Dzięki czemu wtyczki mogą być dynamicznie uruchamiane i aktualizowane oraz korzystanie z różnych wersji bibliotek.

Konfiguracja

Cała wymagana konfiguracja mechanizmu wtyczek musi znajdować się w pliku suncode-plugins.xml (w classpath).

Plik suncode-plugins.xml zawiera przede wszystkim konfigurację związaną z OSGi i widocznością klas systemowych we wtyczkach.

<?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 - wymagane jeżeli wykorzystujemy spring i 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>

 

Opis poszczególnych sekcji pliku konfiguracyjnego:

NazwaWymaganyOpis
home-directory(tick)

Wskazuje katalog domowy mechanizmu wtyczek. W tym katalogu zapisywane będą wtyczki i inne wymagane ustawienia.

Ścieżka może być absolutna bądź relatywna do serwera.

Mechanizm wtyczek nie korzysta z bazy danych. Wszystkie wymagane dane trzymane są w podanym katalogu. Usunięcie katalogu usunie wszystkie zainstalowane wtyczki.

strict-export

 Domyślnie true - definiuje czy wersje eksportowanych pakietów mają pochodzić z manifestu w przypadku bundli OSGi. Flaga na wypadek problemów z kompatybilnością
bootdelegation 

Ustawienie OSGi (http://wiki.osgi.org/wiki/Boot_Delegation). Wskazuje, jakie klasy powinny być zawsze ładowanie z classloadera, który załadował ten mechanizm wtyczek.

Ustawienie bootdelegation zawsze zawiera wpis com.suncode.plugin.framework.* - ładowanie wszystkich klas mechanizmu wtyczek z systemowego classloadera.

Ustawienie tej właściwości konieczne jest w przypadku gdy wtyczki wykorzystują np. proxy - sekcja ImportPackages nie zawiera takiego pakietu i klasa nie zostanie znaleziona. Można uniknąć tego problemu ustawiając bootdelegation bądź dodając odpowiednie wpisy w MANIFEST.MF

Jeżeli podczas używania Profilera VisualVM do profilowania wtyczek występują wyjątki ClassNotFoundException, to do bootdelegation należy dodać wpis:

org.netbeans.lib.profiler.*
export Lista pakietów eksportowanych z systemu bez względu czy występują one w classpath czy też nie. Konfiguracja używana może być np. aby zdefiniować inną wersję eksportowanego pakietu.
exported-packages 

Lista wzorców (w stylu ant) pakietów, które mają zostać wyeksportowane do środowiska OSGi. Skanowane są wszystkie pliki jar i katalogi w classpath. Dzięki temu, wtyczki mogą korzystać z klas głównego systemu.

Wzorce są wyrażeniami w stylu ant:

    • com.** -> wszystkie pakiety zaczynające się od com.
    • com.suncode.* -> wszystkie pod-pakiety (tylko 1 poziom) w pakiecie com.suncode
    • com.suncode.pwfl -> tylko pakiet com.suncode.pwfl

W OSGi pakiety są także identyfikowane przez wersję. Dlatego exporter próbuje ustalić wersję pakietu, odczytując nazwę pliku jar lub informacje w MANIFEST.MF bądź w plikach tworzonych przez Maven'a.

Jeżeli klasy nie są zawarte w pliku jar, nie ma możliwości odczytania wersji pakietu. W takim wypadku przyporządkowywana jest im wersja 0.0.0

excluded-packages Lista wzorców (w stylu ant - tak jak w exported-packages) pakietów, które mają zostać wykluczone z eksportu do środowiska OSGi.

Pierwsze uruchomienie mechanizmu wtyczek wiąże się ze stworzeniem katalogu domowego oraz skanem całego classpath w poszukiwaniu pakietów/klas spełniających podane wymagania. Jest to proces bardzo czasochłonny (nawet kilka minut - w zależności od maszyny).

Po pierwszym uruchomieniu tworzony jest cache pakietów, co przyśpiesza kolejne uruchomienia.

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.

<?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:

NameRequiredDescription
home-directory(tick)

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

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:

    • com.** -> all packages starting with com.
    • com.suncode.* -> all sub-packages (level 1 only) in the com.suncode
    • com.suncode.pwfl -> only the com.suncode.pwfl package

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.