Clojure hot swap dla uberjars/.classes

Question

Chcę mieć hot-code wymiany między aktualizacjami projektu, ale nie znalazłem żadnych informacji o tym, jak załadować pliki .class dynamicznie. Dokładniej, chcę coś takiego:

1. Marka lein uberjar, uzyskać some-client-0.0.0-standalone.jar.
2. Uruchom z java -jar some-client-0.0.0-standalone.jar.
3. Wprowadź zmiany w projekcie. Uzyskaj nową wersję programu, some-client-0.0.1-standalone.jar, skopiuj ją do katalogu some-client-0.0.0-standalone.jar.
4. Klient otrzymuje sekwencję poleceń potrzebnych do aktualizacji do nowej wersji.
5. (opcjonalnie) Aktualizuje zasoby. Zasoby ze starego słoika nie są już używane.
6. (opcjonalnie) some-client-0.0.0-standalone.jar można teraz usunąć.

Answer 1

Do ponownego ładowania w czasie wykonywania wyłącznie z plików jar może być konieczne przejrzenie OSGi class loaders. Dla kodu Clojure można zacząć nrepl w kliencie, który nasłuchuje na porcie lokalnym, a następnie, gdy chcesz, aby przeładować kod podłączyć do tego portu i zatelefonować do load-file

Answer 2

Plug-in podejście ramy

Powiedziałeś, że chcesz mieć zamiany hot-code, ale to, czego potrzebujesz, to luźno połączone moduły i zdolność do rozwiązywania problemów w czasie wykonywania. Mówiąc szczerze, pomocna może być dowolna struktura wtyczek, w tym starsze wersje OSGi (zostaną omówione poniżej).

Ponieważ robisz jakąś PoC Proponuję przejrzeć następujący przykład:

1. masz meta aplikacji z niektórych punktów rozszerzeń (metaphor explanation) zdefiniowany
2. funkcjonalność być zaktualizowane lub zastąpione będą implementowane jako luźno powiązane moduły (wtyczki)
3. meta aplikacja wykonuje rozstrzygnięcie na żądanie lub automatycznie w celu znalezienia zaktualizowanej "funkcjonalności" (Zgodnie z określonymi punktami przedłużających)

Mając które definiują simlle uaktualnić scenariusz można zaproponować:

1. użytkownik korzysta z aplikacji
2. Instaluje użytkownika (kopie) słoiku (inny rodzaj wiązki) z nowa implementacja jednego lub kilku punktów rozszerzeń
3. użytkownik wyzwala globalne rozpoznanie systemu lub skanowanie systemu w poszukiwaniu nowych aktualizacji lub wykonania systemu postanawia, że ​​każdy użytkownik urządzenia próbuje uzyskać dostęp do jakiejś funkcjonalności

W taki sposób aplikacja meta będzie mogła zapewnić nową lub zaktualizowaną funkcjonalność bez ponownego uruchamiania.Więc można:

1. spróbować użyć jakiś prosty plug-in Java ramy (jak, na przykład, Java Simple Plugin Framework. 5 minutes and it works. No XML. Takie podejście wydaje się być trochę brzydki
2. wykorzystanie dynamicznego charakteru Clojure, jak sugerowano here

Możesz również przejrzeć i przyjąć Waterfront (Clojure edytor oparty na Clojure) wnioski (to może być potrzebne w celu wzmocnienia zarządzania cyklem życia, etc)

• sprawdzić Modular composition/plugin architecture wątek
• wygląd poprzez kod waterfront on SourceForge

pod względem wykonania, Wybrzeże opiera się na kontekście wzorca. Pozwala to programom obsługi zdarzeń komunikować się w sposób funkcjonalny ( ) (bez efektu ubocznego). Oprócz tego istnieje mechanizm plug-loader ładujący wtyczki określone w pliku konfiguracyjnym Waterfront o numerze . Oznacza to, że można łatwo dodać funkcjonalność lub usunąć (bardzo przydatne przy debugowaniu!).

podejście OSGI

Jak sugerowano OSGi wydaje się być dobrym sposobem na rozwiązanie problemu. Należy również pamiętać, OSGi jest dobry, dojrzały i dostarcza wielu rzeczy po wyjęciu z pudełka, ale jest również nieco skomplikowane:

BTW, OSGi jest długoterminowym celem dla społeczności Clojure. Można sprawdzić Clojure Todo:

> better modularization for OSGi etc 
> * names 
> * no single namespace pool 
> * namespaces found via classes, thus tracks classloader and modules 
> * deal with import proxying a la Class.forName stack walk? 

Istnieją pewne rozwiązania już dostępne:

1. clojure-osgi-utils
2. clojure.osgi

Drugi projekt świadczy przykład Producent konsumentów za pomocą Clojure i OSGi:

• producer service
• consumer service

Szczęśliwy kodowania.