Najlepszy sposób na zbudowanie systemu wtyczek w Javie

Jak zaimplementowałbyś system wtyczek do swojej aplikacji Java?

Czy można mieć łatwy w użyciu (dla dewelopera) system, który zapewnia:

• Użytkownicy umieszczają swoje wtyczki w podkatalogu aplikacji
• Wtyczka może udostępniać ekran konfiguracji
• Jeśli używasz frameworka, czy licencja jest zgodna z rozwojem komercyjnym?

Najpierw potrzebujesz interfejsu, który muszą zaimplementować wszystkie wtyczki, np

public interface Plugin {
    public void load(PluginConfiguration pluginConfiguration);
    public void run();
    public void unload();
    public JComponent getConfigurationPage();
}

Autorzy wtyczek powinni następnie umieścić swoje wtyczki w plikach JAR. Twoje aplikacje otwierają plik JAR i mogą następnie użyć atrybutu z manifestu JAR lub listy wszystkich plików w pliku JAR, aby znaleźć klasę implementującą interfejs wtyczki. Utwórz instancję tej klasy, wtyczka jest gotowa do pracy.

Oczywiście możesz również zaimplementować pewien rodzaj piaskownicy, aby wtyczka była ograniczona w tym, co może, a czego nie może zrobić. Stworzyłem małą aplikację testową (i napisałem o niej na blogu ), która składa się z dwóch wtyczek, z których jedna ma odmowę dostępu do lokalnych zasobów.

Użyj OSGi .

Stanowi podstawę systemu wtyczek Eclipse. Equinox to implementacja Eclipse (licencjonowana EPL), a Felix to implementacja projektu Apache (licencjonowana publiczna licencja Apache).

Eclipse zapewnia konkretny przykład, że OSGi może pokryć wspomniane przez Ciebie punkty (lub możesz po prostu zbudować swoją aplikację na bazie Eclipse RCP, jeśli chcesz mieć pełny stos Eclipse / SWT / JFace).

Od wersji 1.6 istnieje java.util.ServiceLoader, którego można użyć, jeśli chcesz zakodować swój własny prosty system.

Ale jeśli chcesz czegoś więcej niż podstawowe funkcje, użyj jednego z istniejących frameworków.

Istnieje również JPF (Java Plugin Framework) .

Użyj PF4J . Obsługuje Web, Spring i Wicket. Łatwy w użyciu i budowaniu aplikacji

Pracowałem nad OSGi przez tydzień - intensywny, tylko tydzień OSGi. Koniec końców to był zły sen, ale wiele się nauczyłem.

Udało mi się uruchomić OSGi (niełatwe, wszystkie przykłady są nieaktualne, wszystko w sieci ma co najmniej trzy lata, jeśli nie pięć), ale miałem poważne problemy z integracją go z istniejącym projektem z powodu problemów z przejawy słoików.

Krótko mówiąc, istnieje tylko kilka mało znanych narzędzi używanych do budowania manifestów i nie są one dobrze udokumentowane (BND Tools nie jest niejasny, ale jest przeznaczony do określonego procesu w Eclipse). Ponadto większość dostępnych informacji OSGi nie jest przeznaczona dla twórców aplikacji, którzy mają już aplikację komputerową.

To sprawia, że ​​kontekst informacji jest niejasny lub nieodpowiedni. Największą pomocą okazały się posty na blogu Neila Bartletta, ale nawet tym nie udało się uzyskać działającego systemu (złapałem kod z samouczka Felixa i poskładałem go razem, aby uruchomić osadzony framework). Znalazłem wersję roboczą jego książki, którą opublikował za darmo lata temu, co jest doskonałe, ale przykłady w Eclipse nie działają z powodu zmian w obsłudze Eclipse OSGi.

Każdy krok jest główną przeszkodą. Później spróbuję opublikować tutaj więcej szczegółów.

Myślę, że rekomendowanie OSGi do rozwiązania powyższego problemu jest bardzo złą radą. OSGi to „właściwy wybór”, ale w scenariuszu takim jak powyższy myślę, że JPF lub jakiś własny minimalistyczny framework jest wystarczający.

Wiele lat temu zacząłem taki projekt i mam nadzieję, że wkrótce będzie gotowy. Zainspirowałem się takimi projektami jak NetBeans i Eclipse, ale w międzyczasie zmieniło się na coś trochę innego. OSGi wygląda teraz na dobry wybór, ale nie miałem okazji porównać go z moim projektem, jest podobny do wspomnianego powyżej JPF, ale jednocześnie różni się pod wieloma względami.

Podstawową ideą, która mnie zmotywowała, jest jak najłatwiejsze budowanie aplikacji Java, bez oddzielania aplikacji internetowych, aplikacji desktopowych lub apletów / aplikacji JWS (oczywiście nie obejmuje to jeszcze UI) jako podstawowej funkcjonalności.

Zbudowałem projekt mając na uwadze kilka celów:

• nie ma znaczenia, czy tworzysz aplikację internetową, czy aplikację desktopową, powinieneś uruchomić aplikację w ten sam sposób, zwykłą główną metodą, Bez fantazyjnej deklaracji web.xml (nie żebym był przeciwnikiem posiadania standardowego deskryptora internetowego, ale nie działa dobrze z systemem wtyczek, w którym dodajesz „serwlety” - nazywam je RequestHandler (s) - dynamiczne do twojej woli).
• łatwe do podłączenia „rozszerzeń” wokół „punktu rozszerzenia” - coś z Eclipse, ale inne podejście.
• samodzielne wdrażanie, ponieważ wszystkie wtyczki są zarejestrowane (pliki XML), aplikacja musi być zdolna do samodzielnego wdrażania niezależnie od systemu kompilacji - oczywiście jest zadanie Ant i Maven MOJO, które są linkami do naszego świata, ale w kończy wywołanie aplikacji i poinstruowanie jej, aby zrealizowała się samodzielnie w określonej lokalizacji.
• pożyczony od Mavena, może pobierać kod z repozytoriów (w tym repozytoriów Maven 1 i 2), dzięki czemu aplikacja może być wdrożona jako pojedynczy mały plik jar, o ile masz dostęp do repozytoriów (przydatne czasami i zasadniczo zapewnia obsługę aktualizacje - czy nie podoba ci się pomysł, aby być powiadamianym przez twoją aplikację internetową, że jest nowsza wersja, została pobrana i potrzebuje tylko Twojej zgody, aby ją zainstalować? Wiem, że to mi się podoba).
• podstawowy monitoring aplikacji o stanie systemu, powiadomienia mailowe w przypadku awarii