Uzyskiwanie kompilatora scala do pracy w środowisku wykonawczym OSGi

Question

Używam silnika szablonów Scala (Scalate) do kompilowania szablonów w środowisku wykonawczym w środowisku OSGi (Scala 2.9.1). Szablony nie mogą być wstępnie skompilowane, ponieważ są budowane dynamicznie.

Aby to działało, kompilator Scala musi działać w środowisku OSGi. Jednak ponieważ kompilator Scala nie może pobrać programu ładującego klasy jako wejścia, nie działa to po wyjęciu z pudełka.

Z moich badań, wydaje się być dwa ogólne rozwiązanie zbliża.

1) Wtyczka scala kompilator (there is one started here ale nie została dotknięta od 2009 roku, a messages on the scala list in 2009 stwierdził, że nie był gotowy do użytku produkcyjnego

2) Utworzenie wirtualnego systemu plików na górze kontekstu pakunku, który może być następnie użyty przez kompilator Scala. Najwyraźniej ludzie z procy Apache mają successfully wykorzystali to podejście w starszej wersji Scali.

Czy ktoś uzyskał Scalate, Scala 2.9.1 i OSGi do wspólnej pracy, aby dynamicznie kompilować szablony?

Answer 1

Mój zespół ma teraz kompilację Scala i jej wykonanie działające na Scalate w obrębie OSGi.

Ogólnie, ustawienia ScalaCompiler powinny być dostarczane z zestawem obiektów AbstractFile, które odpowiadają odpowiednim pakunkom OSGi. Jest to obsługiwane przez Guggla zgodnie z odnośnikiem @michid. Ale podczas gdy Guggla dostarcza warstwę AbstractFile, nie dostarcza jeszcze żadnych przykładów ani kodu do tworzenia instancji AbstractFile w środowisku OSGi. Przykładowy kod do tego ostatniego można znaleźć w projekcie Sling (pochodzenie samego Guggla), a także w projekcie Scalate (patrz ScalaCompiler, ale zauważmy poniżej nasze zmiany).

Wybraliśmy pakiety OSGi-ified scala (compiler i library) z projektu ServiceMix. Zobacz issue SMX-1048 (with patch) na pakiecie kompilatora scala.

Naszą pierwotną intencją było, aby działało to w wersji skalowanej, a reszta tej odpowiedzi jest specyficzna dla tego projektu.

Kod Scalate zawierał już większość logiki niezbędnej do pracy w środowisku OSGi, w tym wirtualną warstwę AbstractFile, a także ustawianie ścieżki klasy kompilatora. Jednak musieliśmy załatać Scalate (https://github.com/scalate/scalate/pull/16), aby to działa:

1) OsgiCompiler przesłanianie klasy ScalaCompiler nie był prawidłowo włączona, a więc pakiet nie były wykrywane jako wejścia ścieżki klasy do kompilatora i

2) Program ładujący klasy wykonawczej (czas wykonywania) został ustawiony na program ładujący klasy pakietu scalate-core, co powoduje, że w środowisku wykonawczym CNFE.

Powyższe żądanie ściągnięcia konfiguruje skalowanie w środowisku OSGi do domyślnego programu ładującego klasy kontekstowego wątku w środowisku wykonawczym. Wydaje się, że jest to najprostszy sposób, aby uzyskać odwołanie do programu ładującego klasy dzwoniącego bez konieczności jawnego wstrzykiwania go przez wywołującego (na przykład deklaracja Spring-DM osgi:service eksportująca usługę szablonu może użyć atrybutu context-class-loader="service-provider", aby ustawić to automatycznie. zachowanie w czasie działania Skalate OSGi odpowiada istniejącemu zachowaniu podczas kompilacji, które już używało TCCL:

Dlatego wywołujący Scalate powinien ustawić TCCL na swój własny moduł ładujący klasy lub jawnie wprowadzić pożądany moduł ładujący klasy do silnika szablonu, np. templateEngine.classLoader = ... przed wykonaniem szablonu

Aktualizacja 31-sie-2012: Scalate-Master zawiera teraz wszystkie poprawki wspomniane w tym poście:

Aktualizacja 10-kwi-2013: Scalate 1.6.1 z kompilacją szablonów wykonawczych za pośrednictwem kompilatora Scala jest zgodna z OSGi. Również Scala 2.10 i wyższe są poprawnymi pakietami OSGi.

Answer 2

Myślę, że trzeba ustawić zasadę znajomego. Poniższe powinny pomóc.

http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements#Buddy_Policy

http://www.eclipsezone.com/eclipse/forums/t90282.html

http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html

W swoim pakiecie można powiedzieć, trzeba korzystać z tego samego programu ładującego klasy jako inny pakiet.