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:
Nazwa | Wymagany | Opis |
---|---|---|
home-directory | ![]() | Wyskazuje 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 VisualVM Profiler 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:
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ę z 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.