Widoczność miedzy EAR'ami
DanielMikucki
Mam następujacy problem. Chciałbym skorzystać z bean'a/komponentu
który znajduje się w innym EAR na tym samym serwerze. Nie mam za
bardzo pomysłu jak to zrobić. Można oczywiście wykorzystać remote'a,
ale w sumie to chyba mało wydajne rozwiązanie. Aplikacja jest pisana w
Seam 2.1 na JBoss oraz ANT'a. Moze warto by użyć Maven'a np ? Proszę o
jakies sugestie i pomysły.
Pozdrawiam,
Daniel Mikucki
Tomek Szymański
(nie wiem ;-) )
T.
>
> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie "Warszawa Java User Group (Warszawa JUG)".
>
> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres warsza...@googlegroups.com.
> Aby anulować subskrypcję tej grupy, wyślij e-mail na adres warszawa-jug...@googlegroups.com.
> Aby uzyskać więcej informacji, odwiedź tę grupę pod adresem http://groups.google.com/group/warszawa-jug?hl=pl.
>
>
Daniel Mikucki
Tomek Bujok
> Pr�bowa�em tak, ale wypisuje ClassNotFoundException.
No a wrzuci�e� interfejsy bean�w do osobnego artyfaktu - i doda�e� na
classpath drugiego eara?
Pozdrawiam,
Tomek Bujok
Tomek Szymański
On Dec 16, 2009, at 9:24 , Daniel Mikucki wrote:
> Próbowałem tak, ale wypisuje ClassNotFoundException.
http://community.jboss.org/wiki/classloadingconfiguration
(classloaderow w jbossie NIKT nie rozumie, takze sie nie przejmuj w razie co ;-) )
albo lepsze rozwiazanie (bo powyzsze moze ci stwarzac nieprzywidywane dzialanie, to zrobic jara klienckiego z interfejsami, ktorych chcesz uzywac w tym drugim earze i dorzucenie go tam.
T.
Tomek Bujok
> (classloaderow w jbossie NIKT nie rozumie, takze sie nie przejmuj w razie co ;-) )
http://community.jboss.org/wiki/ClassLoading
Ale troch� jest to rzeczywi�cie zakr�cone.
Pozdrawiam
Tomek Bujok
Daniel Mikucki
Tomek Szymański pisze:
>
> (classloaderow w jbossie NIKT nie rozumie, takze sie nie przejmuj w razie co ;-) )
Kiedyś w to wnikałem - i nie jest tak źle, po przeczytaniu poniższego:
http://community.jboss.org/wiki/ClassLoading
Ale trochę jest to rzeczywiście zakręcone.
Pozdrawiam
Tomek Bujok
Dariusz Kordonski
po co kombinowac z classloaderami. EARy generalnie powinny byc samowystraczalne w zakresie zaleznosci javovo-klasowych, a nie zagladac za kolnierz innym EARom. Stad cala koncepcja WARowych i EARowych classloaderow w JEE, szukania klas parent-last i takich tam. Sugeruje wrzucic feralny komponent w jakis osobny (lub przynajmniej niezbyt wielki) modul Maven'owy (chyba ze juz jest) i dodac powstajacy w ten sposob artefakt JARowy do zaleznosci obu EARow, tak jak zreszta koledzy przede mna wspominali.
Darek
Adam Warski
Jeżeli tak, to może warto się pomęczyć z classloaderami i robić wywołania lokalne.
W przypadku izolacji i załadowania jar-a z interfejsami przez dwa różne classloadery możliwe są tylko wywołania zdalne.
Pozdrowienia,
Adam
Dariusz Kordonski
Darek
Adam Warski
> Jasne ale watpie zeby 2 osobne EARy sie duzo wzajmnie wolaly. Zakladam ze po to z nich zrobiono EARy zeby byly 2 osobnymi aplikacjami ktore laczy ew. tylko wspolna baza danych. Wywolania lokalne (rozumiem ze chodzi o EJB) powinny zdaje sie generalnie zachodzic w ramach jendego EARa, jesli jest ich duzo pomiedzy EARami to chyba oznaka jakis niedociagniec w projekcie.
Adam
Waldek Kot
<dariusz.kordon...@googlemail.com> wrote:
> EARy generalnie powinny byc
> samowystraczalne w zakresie zaleznosci javovo-klasowych, a nie zagladac za
> kolnierz innym EARom. Stad cala koncepcja WARowych i EARowych classloaderow
> w JEE, szukania klas parent-last i takich tam.
Cześć,
@Dariusz:
Pozwól, że się nie zgodzę z tą "samowystarczalnością" EAR'ów i
"niezaglądaniem za kołnierz".
Motywacji za tym, że współdzielenie EAR'ów ma sens jest conajmniej
kilka:
1. dlaczego po stronie Java EE ograniczać się do prymitywnego
mechanizmu JAR'ów, który daje Java SE ? Skoro Java EE wzbogaca ten
mechanizm dosyć istotnie, np. jeśli chodzi o konfigurowalność modułów,
dodatkowe metadane, czy model deployment'u ? W tym ostatnim np. JSR-88
Java EE Application Deployment - od Java EE 5 bardzo praktyczna rzecz
- możliwość zmiany konfiguracji modułów - WAR, EAR, RAR - [tj. ich
deployment descriptor'ów] bez potrzeby modyfikacji zawartości modułu.
"Praktyczne", bo chyba w każdym przyzwoitym wdrożeniu przydatne jest
mieć środowiska DEV, QA, PROD i inne, a w każdym z nich konfiguracja
modułu jest trochę inna). Na marginesie powiem, że smutne, że wciąż -
mimo 11 lat Java EE - większość framework'ów dedykowanych do Java EE
dystrybuowana jest w postaci jar'ów...
2. podział pracy - można łatwo wyobrazić sobie, że jeden zespół tworzy
zestaw EJB i dystrybuuje je w postaci EAR'a, a inne zespoły korzystają
z tych EJB budując inne aplikacje. Nawet w ramach tej samej aplikacji
mogą budować inne warstwy prezentacji, korzystające z tych samych EJB.
"Niedociągnięciem w projekcie" nazwałbym (niestety powszechną)
praktykę kopiowania takich EJB do projektu (albo jeszcze bardziej
diabelski pomysł - wkładania ich na wspólny classpath). Takie
kopiowanie z całą pewnością nie ułatwia zarządzania zależnościami,
powoduje chociażby"puchnięcie" rozmiaru aplikacji (co ma wpływ na czas
deploymentu - szczególnie w wielowęzłowym klastrze serwerów
aplikacyjnych), zużycie pamięci (wiele kopii tego samego kodu w
pamięci), problemy z koniecznością restartu całego serwera
aplikacyjnego, gdy chcemy ten wspólny kod zmodyfikować, itp. Podobnie,
o sensownym wersjonowaniu takiego wspóldzielonego kodu można zapomnieć
(np. gdyby chciało się mieć wiele wersji tych EJB - ale równie dobrze
servlet'ów, czy wręcz całych WAR'ów, EAR'ów, czy RAR'ów - równocześnie
zainstalowanych i aktywnych w kontenerze aplikacyjnym).
Nie wiem, czy można współdzielenie WAR'ów czy EAR'ów robić na JBossie,
ale od ładnych paru lat (wersja 9.0, czyli 2006 rok) taka
funkcjonalność jest dostępna na technologii, z którą ja mam
przyjemność pracować - polecam zobaczyć mechanizm "Shared Libraries" w
WebLogic Server (http://download.oracle.com/docs/cd/E15523_01/web.1111/
e13706/libraries.htm). OSGi, jeśli (?) będzie zaaplikowane do Java EE,
da tu potencjalnie znacznie więcej możliwości, ale główne zalety OSGi
dotyczące współdzielenia i wersjonowania kodu, są aplikacjom Java EE
poprzez mechanizm Shared Libraries dostępne.
W skrócie chodzi o to że:
- można robić deployment modułów Java EE (JAR, WAR, EAR, RAR) zarówno
"normalnie" (tj. jako aplikacje), jak i jako biblioteki (Shared
Library). To drugie oznacza, że aplikacja Java EE może poprzez
referencję w swoim deployment descriptorze odwołać się do takiej
współdzielonej biblioteki. Wtedy klasy we współdzielonej bibliotece
zostają dodane do classloader'a tej aplikacji i są dla niej widoczne.
- bibliotek do których odwołuje się klasa może być dowolna liczba,
kolejność referencji do nich w deployment descriptorze aplikacji
określa widoczność klas na classpath.
- wiele aplikacji może odwoływać się do tej samej współdzielonej
biblioteki (poprzez jej nazwę)
- biblioteki mogą być wersjonowane - zarówno w zakresie interfejsów
("specification"), jak i implementacji (np. specyfikacja framework'a w
wersji 1.x.x, implementacja 1.2.3). Aplikacja, odwołuje się do
konkretnej wersji biblioteki (ale może też odwoływać się do najnowszej
dostępnej implementacji).
- wywołania między aplikacją a shared library są oczywiście typu "call
by reference"
- ten sam moduł (np. EAR) może być zarówno aktywnie działającą
aplikacją, jak i współdzieloną biblioteką, używaną przez inne
aplikacje.
- od strony deploymentu'u nie ma specjalnych różnic między modułem,
który jest aplikacją, a tym, który jest biblioteką. Co oznacza, że
można używać dokładnie tych samych mechanizmów (np. deployment na
wielowęzłowy klaster) i narzędzi (w tym wspomnianego przeze mnie
wcześniej JSR-88 - Java EE Application Deployment). Oczywiście,
oznacza to też, że np. nie ma potrzeby modyfikacji serwerowego
classpath, a współdzielone biblioteki instaluje się, de-instaluje się
bez potrzeby restartu serwera. Przydatne przy (nieuniknionych)
migracjach na wyższe wersje współdzielonego kodu, np. framework'ów
(zresztą aplikacje też mogą istnieć w wielu wersjach równocześnie).
Przy takiej migracji niemal nie dotyka się skryptów startujących/
stopujących serwer aplikacyjny, bo większość zależności aplikacji jest
"niej samej".
- oczywiście, deployment modułu jako shared library nie wymaga
jakichkolwiek w nim modyfikacji (choć warto dodać do META-INF/
MANIFEST.MF modułu 3 dodatkowe metadane: nazwa, wersja specyfikacji,
wersja implementacji - najlepiej niech to robi narzędzie do
automatycznego build'owania)
Rzecz jest całkiem przydatna i wielu z Klientów z którymi pracowałem
używa tego dosyć namiętnie... Zwłaszcza, że jest to o tyle
nieinwazyjne podejście, że wymaga w zasadzie trochę innego ostatniego
kroku składania aplikacji, tzn. zamiast pakować wszystkie
współdzielone JARy do EAR'a (ew. na server classpath), robi się
najpierw deployment współdzielonego kodu, a potem aplikacji. Do tego,
trzeba zmodyfikować deployment descriptor aplikacji (ten specyficzny
dla danego kontenera aplikacyjnego) i umieścić w nim referencje do
współdzielonego kodu. Zawsze więc można "wycofać" się z takiego
deploymentu i wrócić do "średniowiecza"...
Pozdrawiam,
Waldek Kot
PS
@Shimano: mam nadzieję, że żartujesz z tym "classloaderow w jbossie
NIKT nie rozumie", bo smutkiem to napawa... Mówi się, że nawet małpa
opierając się przypadkowo łokciem na klawiaturze potrafi program w
Javie napisać, a tu takie kwiatki u ludzi, którzy mają ambicję pisać
serwer aplikacyjny ? Czyżby Marc przed pójściem na plażę pić drinki z
palemką NIKOMU tej wiedzy nie przekazał ? ;-)
Tomek Szymański
> @Dariusz:
>
> ( CIACH CIACH CIACH)
>
> @Shimano
> (CIACH CIACH CIACH)
Waldi czy ty w ogole przeczytales to co bylo wczesniej w tym watku napisane, czy nie ?
1) Dalem linka jak zrobic zeby, eary (i nie tylko) mialy wspoldzielony loader-repository
2) Nikt nie chcial wrzucac wszedzie EJB, a tylko interfejsy. Jesli znasz jakis sposob na wolanie remote metod bez dorzucenia interfejsu, to prosze oswiec mnie.
3) Kolega pyta o JBossa, a ty wyjezdzasz z reklama jakiegos serwera firmy na O.
4) Dodatkowo musial pasc "OSGi". Gdzie tu w ogole cos bylo o jakims osgiu ? Jest JBoss jest ant i jest seam. Nic wiecej.
5) Post scriptum ponizej gosnosci, wiec nawet nie skomentuje. Juz nie mowiac o tym, ze nawet moja ksywke z bledem napisales :-p
pozdro,
SZimano
Waldek Kot
On Dec 18, 5:25 pm, Tomek Szymański <szim...@szimano.org> wrote:
> Waldi czy ty w ogole przeczytales to co bylo wczesniej w tym watku napisane, czy nie ?
No SZimano (!) ja przeczytałem. A Ty moją wypowiedź ? Bo zauważ, że
odnosiłem się nie do pytania Daniela, tylko do opinii Darka. I to
zaznaczyłem od pierwszego wyrazu w mojej wypowiedzi. Jakby więc
większość z Twoich zarzutów przestaje mieć w tym momencie sens...
Co do OSGi, które jak i wszystko pozostałe padło w kontekście
współdzielenia kodu w Java EE, a nie JBoss-a/Seam-a/ant-a, to owszem,
uważam, że warto było o nim wspomnieć. Przeczytasz dokładniej,
zrozumiesz dlaczego.
Pozdrawiam,
Waldek Kot
Tomek Szymański
On Dec 18, 2009, at 18:13 , Waldek Kot wrote:
>
>
> On Dec 18, 5:25 pm, Tomek Szymański <szim...@szimano.org> wrote:
>> Waldi czy ty w ogole przeczytales to co bylo wczesniej w tym watku napisane, czy nie ?
>
> No SZimano (!) ja przeczytałem. A Ty moją wypowiedź ? Bo zauważ, że
> odnosiłem się nie do pytania Daniela, tylko do opinii Darka. I to
> zaznaczyłem od pierwszego wyrazu w mojej wypowiedzi. Jakby więc
> większość z Twoich zarzutów przestaje mieć w tym momencie sens...
Aha. Czyli rozumiem jak jest dyskusja, to odnosimy sie tylko do ostatniej wypowiedzi, zapominajac o reszcie.
Bede pamietal.
Ja w JBossie juz nie pracuje (rok), ale widze ze za punkt honoru stawiasz sobie zostawianie takich "niedomowien", zeby sypnac troche soli w JB ASa.
"Nie wiem, czy można współdzielenie WAR'ów czy EAR'ów robić na JBossie," no przeciez pare postow wyzej napisalem, ze mozna. Ale widze, ze lepiej jest napisac 7 akapitow tekstu o rewolucyjnej technologii w weblogicu, ktora wyprowadzi programistow JBossa (i byc moze innych tez) ze sredniowiecza.
A tak w temacie specyfikacje JEE5 definiuje EAR jako sposob pakowania aplikacji i przewiduje ich deployment w osobnym classloaderze (strona 164 dla ciekawych), wiec nie wydaje mi sie, zeby dostarczanie bibliotek w postaci JARow mimo 11 lat istnienia EE bylo jakims wielkim problemem. A w uzywaniu w dwoch aplikacjach na jednym serwerze tych samych beanow nie widze wiekszego sensu. Dwa frontendy (a nawet 300) mozna sobie opakowac w jeden EAR i tak to przewiduje specyfikacja.
Tomek
Waldek Kot
> > No SZimano (!) ja przeczytałem. A Ty moją wypowiedź ? Bo zauważ, że
> > odnosiłem się nie do pytania Daniela, tylko do opinii Darka. I to
> > zaznaczyłem od pierwszego wyrazu w mojej wypowiedzi. Jakby więc
> > większość z Twoich zarzutów przestaje mieć w tym momencie sens...
>
> Aha. Czyli rozumiem jak jest dyskusja, to odnosimy sie tylko do ostatniej wypowiedzi, zapominajac o reszcie.
> Bede pamietal.
Przyznam, że nie wiem o co Ci chodzi - w mojej wypowiedzi odwołałem
się do konkretnej opinii. Co do reszty się nie wypowiadałem, bo nie
znam JBoss'a (co też notabene napisałem, w przywołanym przez Ciebie
miejscu). Zaciekawiła mnie opinia Darka nt. EAR'ów, powiedziałem
swoją, żeby nie teoretyzować podałem miejsce gdzie ktoś zainteresowany
może znaleźć przykład praktycznego sposobu rozwiązania omawianego
problemu i tyle.
> ale widze ze za punkt honoru stawiasz sobie zostawianie takich "niedomowien", zeby sypnac troche soli w JB ASa.
Nie mój problem, ale źle widzisz. Lista dyskusyjna JUG'a to
nienajlepsze miejsce na tego rodzaju dyskusje. Przynajmniej ja to tak
widzę, wnioskuję z Twojej wypowiedzi, że uważasz inaczej ? Trudno, nie
poradzę...
Jeśli już cokolwiek mogę stawiać sobie "za punkt honoru" (choć "honor"
to zdecydowanie zbyt wygórowane sformułowanie tutaj), to może
dyskutowanie o tym, co się w świecie serwerowych aplikacji Java
dzieje. Uważam, że taka dyskusja będzie dosyć smutna (i ze szkodą dla
ludzi interesujących się tą tematyką), jeśli się pominie w niej to, co
oferują highend-owe rozwiązania. To tak, jakby na rozwój technologii
bazodanowych patrzeć przez pryzmat np. MS Access'a. Albo, pomijać F1 i
na samochody patrzeć przez pryzmat malucha. Ja bym nie chciał... I -
powtórzę - że bez podawania konkretnych przykładów, będziemy sobie
teoretyzować. A to, IMHO, nie-po-inżyniersku...
> A tak w temacie specyfikacje JEE5 definiuje EAR jako sposob pakowania aplikacji i przewiduje ich deployment w osobnym classloaderze (strona 164 dla ciekawych), wiec nie wydaje mi sie, zeby dostarczanie bibliotek w postaci JARow mimo 11 lat istnienia EE bylo jakims wielkim problemem. A w uzywaniu w dwoch aplikacjach na jednym serwerze tych samych beanow nie widze wiekszego sensu. Dwa frontendy (a nawet 300) mozna sobie opakowac w jeden EAR i tak to przewiduje specyfikacja.
No i w ten sposób zbyt wielu praktycznych problemów nie rozwiążesz. A
jak ze współistnieniem równocześnie wielu wersji współdzielonego kodu
(np. Spring 1.2.1, 2.5.3, 2.5.4, itd.) ? Odwoływaniem się do
konkretnej wersji, itd. ? Wydajność (call-by-value vs. call-by-
reference) ? Puchnięcie aplikacji (300 frontend'ów w jednym EAR to i
parę GB może dać) ? Hot deployment ?
Nie twierdzę, że Shared Library z WLS to ideał (i nie ma takich), ale
- zanim (jeśli ?) pojawi się "OSGi dla Java EE" - to z wieloma z tych
problemów można sobie poradzić. Sorry, ale Twoje propozycje "opakować
wszystko w jeden EAR", czy "zmodyfikować classloading aplikacji" to
IMHO - w kontekście problemu współdzielenia kodu w Java EE - jest
droga do nikąd (jeśli nie do większych kłopotów).
Jak rozumiem zainteresowanie ludzi tematem zarządzania zależnościami
(OSGi, a wcześniej Spring i Maven) też uznajesz za objaw "sypania
soli", czy "wyjeżdżania z reklamą". Cóż, nie poradzę... Na szukanie
spisku, "systemu", czy "sieci" też nie...
Pozdrawiam,
Waldek Kot
Dariusz Kordonski
Waldku, ja nadal utrzymuje swoja opinie (uzasadnienie ponizej).
Waldek Kot wrote:
> On Dec 16, 1:12 pm, Dariusz Kordonski
> <dariusz.kordon...@googlemail.com> wrote:
>
>> EARy generalnie powinny byc
>> samowystraczalne w zakresie zaleznosci javovo-klasowych, a nie zagladac za
>> kolnierz innym EARom. Stad cala koncepcja WARowych i EARowych classloaderow
>> w JEE, szukania klas parent-last i takich tam.
>>
>
> Cze��,
>
> @Dariusz:
> Pozw�l, �e si� nie zgodz� z t� "samowystarczalno�ci�" EAR'�w i
> "niezagl�daniem za ko�nierz".
> Motywacji za tym, �e wsp�dzielenie EAR'�w ma sens jest conajmniej
> kilka:
> 1. dlaczego po stronie Java EE ograniczaďż˝ siďż˝ do prymitywnego
> mechanizmu JAR'�w, kt�ry daje Java SE ? Skoro Java EE wzbogaca ten
> mechanizm dosy� istotnie, np. je�li chodzi o konfigurowalno�� modu��w,
> dodatkowe metadane, czy model deployment'u ? W tym ostatnim np. JSR-88
> Java EE Application Deployment - od Java EE 5 bardzo praktyczna rzecz
> - mo�liwo�� zmiany konfiguracji modu��w - WAR, EAR, RAR - [tj. ich
> deployment descriptor'�w] bez potrzeby modyfikacji zawarto�ci modu�u.
> "Praktyczne", bo chyba w ka�dym przyzwoitym wdro�eniu przydatne jest
> mie� �rodowiska DEV, QA, PROD i inne, a w ka�dym z nich konfiguracja
> modu�u jest troch� inna). Na marginesie powiem, �e smutne, �e wci�� -
> mimo 11 lat Java EE - wi�kszo�� framework'�w dedykowanych do Java EE
> dystrybuowana jest w postaci jar'�w...
>
Pytasz dlaczego ograniczac sie do prymitywnych (==prostych) rozwiazan. A
ja zapytam przekornie - dlaczego komplikowac sobie zycie jakimis
bajerami, jesli nie sa one potrzebne do rozwiazania danego problemu? Ja
szczerze mowiac, przy calym moim szacunku dla standardow JEE (szacunek
zaczyna sie od JEE5:) staram sie jak najbardziej ograniczac wszelkie
dobra, jakie one oferuja. Tak mi sie wydaje, ze im wiecej XMLi,
anotacji, DDow itp. tym mniej Javy w Javie:) A ja sobie stara dobra Jave
cenie najbardziej.
A tak schodzac na nizszy poziom abstrakcji, to nie wiem czy dobrze
wytlumaczylem o co mi chodzilo w przypadku problemu opisanego przez
Daniela. Jak rozumiem jest sobie jakis lokalny sesyjny EJB, sa sobie 2
EARy i jest potrzeba uzycia tego ziarna w obu. Za build odpowiedzialny
jest Maven, wiec zakladam ze projekt jest podzielony na jakies moduly
POMowe, z ktorych produkowane sa artefakty w postaci JARow, WARow i
EARow. W tej sytuacji najprostszym i najbardziej przejrzystym
rozwiazaniem jest umieszczenie klas zwiazanych z feralnym ziarnem w
jakims module dostepnym dla obu EARow i skonfigurowanie builda tak, by
trafialy one do obu ERAow, czy to w postaci JARow, czy wprost do
APP-INF. Oczywiscie do tego musi dojsc odpowiednia konfiguracja w DD czy
tez anotacje na klasach, tak aby w obu aplikacjach ten bean byl dostepny
w srodowisku. Bron boze nie sugerowalem zdegradowania naszego bean'a do
poziomu ordynarnej javowej klasy!:) Takze nie do konca rozumiem jak sie
ma do tego uwaga o JSR-88...
Co do uwagi o framework'ach, to jakie konkretnie masz na mysli?
Osobiscie uwazam ze przewazajaca wiekszosc frameworkow jest uzyteczna
zarowno w przestrzeni SE jak i EE, a wiec dystrybuowanie ich jako EARow
niepotrzebnie ograniczylo by zakres uzytkownikow tych bibliotek. Chyba
ze postulujesz wprowadzenie tej formy jako dodatkowej do standardowej.
Ale wtedy znow pytanie - po co (zob. akapit 1)? Przeciez EARy tak czy
owak, obok meta, i meta-meta, i meta-meta-meta-danych i roznych innych
dziwnych zasobow;) skladaja sie w duzej czesci ze skompilowanych do
bajtkodu klas, a JARy sa po prostu wygodnym standardem dystrybuowania
tych klas.
> 2. podzia� pracy - mo�na �atwo wyobrazi� sobie, �e jeden zesp� tworzy
> zestaw EJB i dystrybuuje je w postaci EAR'a, a inne zespo�y korzystaj�
> z tych EJB buduj�c inne aplikacje. Nawet w ramach tej samej aplikacji
> mog� budowa� inne warstwy prezentacji, korzystaj�ce z tych samych EJB.
>
Jesli chodzi o argument z zespolem to nie spotkalem sie jeszcze z takim
modelem pracy, ale rzeczywiscie byc moze w jakichs naprawde duzych
projektach tak moze byc. Jednak nadal uwazam EARy same w sobie byly
pomyslane jako samodzielne aplikacje i moga wewnatrz siebie zawierac
dowolna liczbe modulow EJB (i innych), i to te moduly sa moim zdaniem
odpowiednim poziomem abstrakcji do podzielenia pracy miedzy zespoly (nie
wspominajac juz o tym, ze zdaje sie, metodyki (a moze metodologie:D)
Agile promuja pionowy podzial pracy nad wymaganiami, tzn. implementacje
wymagania przez jeden zespol w poprzek wszystkich warstw aplikacji).
> "Niedoci�gni�ciem w projekcie" nazwa�bym (niestety powszechn�)
> praktykďż˝ kopiowania takich EJB do projektu (albo jeszcze bardziej
> diabelski pomys� - wk�adania ich na wsp�lny classpath). Takie
> kopiowanie z ca�� pewno�ci� nie u�atwia zarz�dzania zale�no�ciami,
> powoduje chocia�by"puchni�cie" rozmiaru aplikacji (co ma wp�yw na czas
> deploymentu - szczeg�lnie w wielow�z�owym klastrze serwer�w
> aplikacyjnych), zu�ycie pami�ci (wiele kopii tego samego kodu w
> pami�ci), problemy z konieczno�ci� restartu ca�ego serwera
> aplikacyjnego, gdy chcemy ten wsp�lny kod zmodyfikowa�, itp. Podobnie,
> o sensownym wersjonowaniu takiego wsp�ldzielonego kodu mo�na zapomnie�
> (np. gdyby chcia�o si� mie� wiele wersji tych EJB - ale r�wnie dobrze
> servlet'�w, czy wr�cz ca�ych WAR'�w, EAR'�w, czy RAR'�w - r�wnocze�nie
> zainstalowanych i aktywnych w kontenerze aplikacyjnym).
>
>
Moje rozwiazanie nie zakladalo kopiowania kodu zrodlowego, tylko
odpowiednie skonfigurowanie build'a, zeby ziarno znalazlo sie w obu
docelowych EARach. Podkreslam rowniez, ze ja skupialem sie na konkretnym
problemie, jaki mial Daniel. W tym przypadku mamy 2 EARy, kazdy robi co
innego (tak zakladam), i oba potrzebuja tego samego ziarna. Wrzucanie
tego ziarna do jednego z tych EARow i wolanie go z drugiego efektywanie
uzaleznia jeden EAR od drugiego i sprowadza nasze aplikacje do jednej,
niszczac modularnosc, jaka przedtem mialy. To oznacza m.in., ze nie
bedzie mozna zdeployowac jednego EARa bez drugiego, co okreslilbym jako
'niedociagniecie w projekcie'.
> Nie wiem, czy mo�na wsp�dzielenie WAR'�w czy EAR'�w robi� na JBossie,
> ale od �adnych paru lat (wersja 9.0, czyli 2006 rok) taka
> funkcjonalno�� jest dost�pna na technologii, z kt�r� ja mam
> przyjemno�� pracowa� - polecam zobaczy� mechanizm "Shared Libraries" w
> WebLogic Server (http://download.oracle.com/docs/cd/E15523_01/web.1111/
> e13706/libraries.htm). OSGi, je�li (?) b�dzie zaaplikowane do Java EE,
> da tu potencjalnie znacznie wi�cej mo�liwo�ci, ale g��wne zalety OSGi
> dotycz�ce wsp�dzielenia i wersjonowania kodu, s� aplikacjom Java EE
> poprzez mechanizm Shared Libraries dost�pne.
> W skr�cie chodzi o to �e:
> - mo�na robi� deployment modu��w Java EE (JAR, WAR, EAR, RAR) zar�wno
> "normalnie" (tj. jako aplikacje), jak i jako biblioteki (Shared
> Library). To drugie oznacza, �e aplikacja Java EE mo�e poprzez
> referencj� w swoim deployment descriptorze odwo�a� si� do takiej
> wsp�dzielonej biblioteki. Wtedy klasy we wsp�dzielonej bibliotece
> zostajďż˝ dodane do classloader'a tej aplikacji i sďż˝ dla niej widoczne.
> - bibliotek do kt�rych odwo�uje si� klasa mo�e by� dowolna liczba,
> kolejno�� referencji do nich w deployment descriptorze aplikacji
> okre�la widoczno�� klas na classpath.
> - wiele aplikacji mo�e odwo�ywa� si� do tej samej wsp�dzielonej
> biblioteki (poprzez jej nazwďż˝)
> - biblioteki mog� by� wersjonowane - zar�wno w zakresie interfejs�w
> ("specification"), jak i implementacji (np. specyfikacja framework'a w
> wersji 1.x.x, implementacja 1.2.3). Aplikacja, odwo�uje si� do
> konkretnej wersji biblioteki (ale mo�e te� odwo�ywa� si� do najnowszej
> dost�pnej implementacji).
> - wywo�ania mi�dzy aplikacj� a shared library s� oczywi�cie typu "call
> by reference"
> - ten sam modu� (np. EAR) mo�e by� zar�wno aktywnie dzia�aj�c�
> aplikacj�, jak i wsp�dzielon� bibliotek�, u�ywan� przez inne
> aplikacje.
> - od strony deploymentu'u nie ma specjalnych r�nic mi�dzy modu�em,
> kt�ry jest aplikacj�, a tym, kt�ry jest bibliotek�. Co oznacza, �e
> mo�na u�ywa� dok�adnie tych samych mechanizm�w (np. deployment na
> wielow�z�owy klaster) i narz�dzi (w tym wspomnianego przeze mnie
> wcze�niej JSR-88 - Java EE Application Deployment). Oczywi�cie,
> oznacza to te�, �e np. nie ma potrzeby modyfikacji serwerowego
> classpath, a wsp�dzielone biblioteki instaluje si�, de-instaluje si�
> bez potrzeby restartu serwera. Przydatne przy (nieuniknionych)
> migracjach na wy�sze wersje wsp�dzielonego kodu, np. framework'�w
> (zreszt� aplikacje te� mog� istnie� w wielu wersjach r�wnocze�nie).
> Przy takiej migracji niemal nie dotyka si� skrypt�w startuj�cych/
> stopuj�cych serwer aplikacyjny, bo wi�kszo�� zale�no�ci aplikacji jest
> "niej samej".
> - oczywi�cie, deployment modu�u jako shared library nie wymaga
> jakichkolwiek w nim modyfikacji (choďż˝ warto dodaďż˝ do META-INF/
> MANIFEST.MF modu�u 3 dodatkowe metadane: nazwa, wersja specyfikacji,
> wersja implementacji - najlepiej niech to robi narz�dzie do
> automatycznego build'owania)
>
> Rzecz jest ca�kiem przydatna i wielu z Klient�w z kt�rymi pracowa�em
> u�ywa tego dosy� nami�tnie... Zw�aszcza, �e jest to o tyle
> nieinwazyjne podej�cie, �e wymaga w zasadzie troch� innego ostatniego
> kroku sk�adania aplikacji, tzn. zamiast pakowa� wszystkie
> wsp�dzielone JARy do EAR'a (ew. na server classpath), robi si�
> najpierw deployment wsp�dzielonego kodu, a potem aplikacji. Do tego,
> trzeba zmodyfikowaďż˝ deployment descriptor aplikacji (ten specyficzny
> dla danego kontenera aplikacyjnego) i umie�ci� w nim referencje do
> wsp�dzielonego kodu. Zawsze wi�c mo�na "wycofa�" si� z takiego
> deploymentu i wr�ci� do "�redniowiecza"...
>
>
Niestety nie mialem okazji pracowac z takim rozwiazaniem. Na pewno
Waldek ma o wiele wieksze doswiadczenie ode mnie w tej kwestii, wiec
trudno mi tu dyskutowac. Zagram jednak przez chwie adwokata diabla:)
Skoro klasy z shared libraries sa ladowane przez classloader'a kazdej
odwolujacej sie do niej aplikacji, to efekt netto rozmiaru tych klas w
runtimie jest taki sam. Mamy tylko jedna wspolna definicje bean'a, ale
czy to jakas oszczednosc? Serwer tak czy owak bedzie tworzyl odpowiednia
liczbe instancji bean'a zeby obsluzyc workload wiec w rezultacie
rozmiarowo bedzie to bardzo podobne do rozwiazania, w ktorym klasy
zwiazane z tym ziarnem sa osobno we wszystkich potrzebujacych ich
EARach. Odpada wiec argument o obciazeniu pamieci.
Jak bedzie trzeba wspolny kod zmodyfikowac, to i tak bedzie trzeba
zredeployowac tego EARa ze wspolnym kodem (nie wymaga to czasem restartu
wszystkich EARow ktore go uzywaja?:), wiec roznica ew. w ilosci EARow to
zredeployowania. Pytanie wiec, jak duza i skomplikowana musi byc
aplikacja i jej wspolna funkcjonalnosc, zeby mialo to znaczenie?
Ogolnie fajnie to wszystko wyglada na papierze (szczegolnie do mnie
przemawia to zarzadzanie wersjami), ale tak czy owak wydaje mi sie, ze
wymaga jakichs dodatkowych sztuczek konfiguracyjnych i dodatkowej wiedzy
fachowej nt. weblogicowego DD (zob 1 akapit:). Jak widac do takich
projektow trzeba bylo bardzo specjalistycznej weblogicowej wiedzy
Waldka, pytanie jak by sobie z takimi bajerami poradzil przecietny
zespol programistow, dla ktorego opanowanie samego stosu standardow JEE
stanowi nie lada wyzwanie? Mowiac wprost, takie niestandardowe
rozwiazania kosztuja, bo wymagaja wiedzy, ktora albo mozna kupic albo
zmusic pracownikow do nabycia. I potem stale dbac o to, zeby ktos z taka
wiedza byl 'w poblizu'. Pytanie zatem, jak duzy i kompleksowy musi byc
projekt, zeby faktycznie sie to oplacalo? Ja jeszcze przy takim
projekcie w kazdym razie nie pracowalem i wydaje mi sie, ze jakis duzy
ulamek projektow, z ktorymi mamy na co dzien do czynienia moze sie
doskonale obejsc z uzyciem 'sredniowiecznych' rozwiazan:) Na taki mi tez
wyglada projekt Daniela, ktory byl glownym przedmiotem mojej poprzedniej
wypowiedzi.
Pozdrawiam,
Darek
P.S. Jesli standardowe Javowe rozwiazania sa teraz sredniowieczne, to
mam nadzieje, ze wiekszosc swojej kariery spedze w takim sredniowieczu,
bo jakies ono bardziej oczywiste, przejrzyste i klarowne niz magiczne
fajerwerki JEE;)
Waldek Kot
<dariusz.kordon...@googlemail.com> wrote:
> Pytasz dlaczego ograniczac sie do prymitywnych (==prostych) rozwiazan. A
> ja zapytam przekornie - dlaczego komplikowac sobie zycie jakimis
> bajerami, jesli nie sa one potrzebne do rozwiazania danego problemu?
Hmm... Jak najprostsze, ale nie prostsze ;-) Tak jak w tym
przykładzie, który podajesz, czasem to co proste na początku (albo dla
wybranych osób, tu: deweloperów), komplikuje życie później (albo innym
osobom, np. tu: administratorom). Trudno zdefiniować co to znaczy
"proste", ale IMHO trzeba sobie zadawać pytanie, czy dany problem jest
rozwiązywany (a przynajmniej minimalizowany), czy tylko przesuwany na
później. W sumie dla nas deweloperów jest to coś oczywistego, z czym
spotykamy się non-stop. Przykład: Prościej jest programować bez
pisania testów. Trudniej jest programować z użyciem takiej techniki
jak Dependency Injection (niż z użyciem operatora 'new' do
wszystkiego). "Pakujemy" się w DI (czytaj: inwestujemy czas i pot),
żeby nasz kod był łatwiej testowalny. Piszemy testy (czytaj:
inwestujemy czas i pot), bo wiemy, że to się opłaci później. Jeśli
tego nie robimy, przesuwamy problem na później. Etc, etc...
Ja nie jestem za ograniczaniem "dobra", które niosą ze sobą
technologie, bo to marnotrawstwo. Jako "dobro" czytam określenie
"bajery", choć to słowo w kontekście problemu o którym rozmawiamy -
możliwości współdzielenia kodu, w tym dostarczanego w postaci EAR'ów -
nie pasuje. To trochę jak kupić samochód z 6-cio biegową skrzynią, ale
jeździć maksymalnie na 4-tym. Staram się te "dobra" zrozumieć,
zrozumieć gdzie mogą się przydać i inteligentnie ich użyć.
"Inteligentnie" to także oznacza, czy mogę się z danego
"dobrodziejstwa" wycofać. W podanym wcześniej poście opisałem, że
akurat z czegoś takiego jak Shared Library da się bardzo łatwo zrobić
krok wstecz (="mało inwazyjne podejście"). Oczywiście, wszystkiego
można nadużyć, ale IMHO to taki sam błąd, jak zamknąć oczy i "niedo-
użyć"...
> A tak schodzac na nizszy poziom abstrakcji, to nie wiem czy dobrze
> wytlumaczylem o co mi chodzilo w przypadku problemu opisanego przez
> Daniela.
Co do Twojego podejścia ze skopiowaniem kodu EJB do obu EAR'ów -
jasne, to zadziała. W tym specyficznym przypadku będzie to pewnie
nawet najprostsze rozwiązanie i nie mam nic do niego. Ja odwołałem się
raczej do Twojej opinii nt. możliwości współdzielenia EAR'ów. Można
też potraktować to rozwiązanie z kopiowaniem szerzej (i jest ono
niestety najszerzej dzisiaj stosowanym rozwiązaniem). Pytanie, czy
jest to rozwiązanie problemu współdzielenia kodu ? Kopiujemy kod
(DRY ?), a tym samym pakujemy się w problem utrzymywania wielu miejsc
w których ten sam kod jest używany. Kopiujemy, czyli zwiększamy
rozmiar tego EAR'a (tego nie ma w Twoim przykładzie, ale -
parafrazując klasyka - "idąc tą drogą" do tych EAR'ów będą pakowane
kolejne rzeczy: frameworki, logika biznesowa i potencjalnie setki
innych współdzielonych artefaktów). I wszystkie inne (złe) rzeczy o
których też wspomniałem... Myślę, że nie tędy droga (a przynajmniej
nie zawsze tędy droga i osobiście chciałbym mieć dodatkowe opcje). Nie
byłoby takiego zainteresowania OSGi, modularyzacją Java, także
wspomnianym przez Ciebie Mavenem czy Springiem (one tylko "obsługują"
inny rodzaj zależności), gdyby to nie był (bolesny) problem
występujący w praktyce. Oczywiście można zamknąć oczy (trochę tak to
robi Java EE, zajmując się innymi, IMHO mniej istotnymi, rzeczami),
ale problem nie zniknie.
> Takze nie do konca rozumiem jak sie
> ma do tego uwaga o JSR-88...
JSR-88 jest jednym z moich ulubionych (bo prostych ;-)) rzeczy w Java
EE. Bo rozwiązuje (minimalizuje ?) powszechny _praktyczny_ problem -
potrzeby różnej konfiguracji kodu w zależności od środowiska (DEV,
QA, ...). Metadane w postaci adnotacji czy DD mogą być nieinwazyjnie
(!) modyfikowane w zależności od środowiska w którym dany kod
uruchamiamy. "Nieinwazyjnie" = nie trzeba nic modyfikować w kodzie,
który uruchamiamy - może on nadal być w postaci EAR'a/WAR'a/itd.
"Bajer", ale _upraszczający_ życie. Alternatywą jest rozszycie EAR'a/
WAR'a, dodanie DD specyficznych dla środowiska i ponowne zaszycie
modułu. Znowu DRY. Jasne, że można sprawę "rozwiązać" na poziomie
automatycznego build'a, ale chyba nie tędy droga. Dla wielu
scenariuszy nawet to "rozwiązanie" nie pasuje - moduł, którego
deployment wykonujemy nie musi przechodzić ponownie przez praktycznie
cały automatic build... IMHO JSR-88 jest przydatny i albo powinien
znaleźć się na poziomie Java SE (w co nie wierzę, że się stanie), albo
frameworki (szczególnie te _dedykowane_ dla Java EE), powinny (móc)
korzystać z dobrodziejstwa Java EE (mało sobie zdajemy sprawę ile
prostoty w nasze życie wniosło ustandaryzowanie modelu deployment'u
przez J2EE/Java EE), w tym także skorzystać z JSR-88... Być może
problem ten (dodając przy okazji możliwości) rozwiąże OSGi (a po
części także SCA ze swoim super-deployment-descriptorem), ale kiedy to
nastąpi, nie wiadomo...
> Chyba ze postulujesz wprowadzenie tej formy jako dodatkowej do standardowej.
Dokładnie tak.
> Ale wtedy znow pytanie - po co (zob. akapit 1)? Przeciez EARy tak czy
> owak, obok meta, i meta-meta, i meta-meta-meta-danych i roznych innych
> dziwnych zasobow;) skladaja sie w duzej czesci ze skompilowanych do
> bajtkodu klas, a JARy sa po prostu wygodnym standardem dystrybuowania
> tych klas.
I w coraz większym stopniu jest potrzeba dodawania do tych JAR'ów
metadanych (patrz obserwowany od pewnego czasu renesans zastosowania
MANIFEST.MF). Nie o konkretną metodę mi chodzi, ale o jakieś
rozwiązanie sprawy. Najlepiej w nieinwazyjny sposób.
> Jednak nadal uwazam EARy same w sobie byly
> pomyslane jako samodzielne aplikacje i moga wewnatrz siebie zawierac
> dowolna liczbe modulow EJB (i innych), i to te moduly sa moim zdaniem
> odpowiednim poziomem abstrakcji do podzielenia pracy miedzy zespoly
Znowu - jak pokazuje wzrost zainteresowania OSGi (a właściwie wzrost
zainteresowania problemem modularyzacji aplikacji w Java, zarządzania
zależnościami, itd), ten poziom abstrakcji przestaje wystarczać.
J2EE/Java EE daje mechanizm EAR'ów, WAR'ów - ale także libraries (!!!)
- natomiast o tym, że EAR ma być "samodzielną aplikacją" specyfikacja
nic nie mówi. To by było już trochę zbyt dużo, żeby specyfikacja
mówiła deweloperom jak - z jakich modułów - mają konstruować swoje
aplikacje, co jest "samodzielne", a co nie. Java EE ustandaryzowała
wagonik, którym nasz kod jest przewożony do stacji Serwer Aplikacyjny,
ale - IMHO na szczęście - nie mówi co mamy wozić i do czego. Notabene
- Java EE 6 nawet znosi pewne ograniczenia, np. daje możliwość
pakowania EJB bezpośrednio do WAR'ów. Po co ? Widać ludzie chcieli
mieć dodatkową, w pewnych scenariuszach prostszą, opcję. Mechanizmu
takiego jak Shared Library też prędzej, czy później się doczekamy.
Mogę się założyć o dobre wino, że będzie on bardzo podobny do tego,
jaki jest w WLS-ie. Dlaczego ? Bo jest. Bo OSGi - mimo iż daje
największe możliwości - nie jest prosty. Bo może warto zrobić jakiś
krok pośredni. Notabene, historia się powtórzy, bo o ile mi wiadomo,
to wspomniany przez Ciebie mechanizm z APP-INF, a dokładniej z
możliwością współdzielenia JAR'ów w ramach całego EAR'a poprzez
umieszczenie ich w określonym folderze [library-directory], został
przeszczepiony do Java EE 5 z wcześniejszych wersji WebLogic Server.
Tyle, że w WLS ten folder to był stricte folder o nazwie "APP-INF",
natomiast w Java EE to może być dowolny folder. Spora część ludzi
pracujących nad specyfikacją na co dzień pracuje programując serwery
aplikacyjne - doświadczenia ze standaryzacji Java EE pokazują, że
najlepiej standaryzować to, co miało szansę sprawdzić się w boju...
> wspominajac juz o tym, ze zdaje sie, metodyki (a moze metodologie:D)
> Agile promuja pionowy podzial pracy nad wymaganiami, tzn. implementacje
> wymagania przez jeden zespol w poprzek wszystkich warstw aplikacji).
Zgoda, czemu więc nie miałbyś dodawać tych wertykalnych
funkcjonalności dynamicznie, w postaci kolejnych EAR'ów ? A DRY -
czyli po co rozszywać i robić re-deployment _całej_ aplikacji ? Fajnie
byłoby nie zatrzymywać pozostałych ? I móc określić, żeby były używane
zarówno najnowsze wersje, jak i konkretne wersje ? Polegając na
kopiowaniu JAR'ów i ręcznym manipulowaniu classloaderami żadnego z
postulatów Agile się tu nie osiąga... Takie podejścia jak Shared
Library, czy możliwość równoczesnego deployment'u wielu wersji
aplikacji owszem, przynajmniej przybliża.
> Moje rozwiazanie nie zakladalo kopiowania kodu zrodlowego, tylko
> odpowiednie skonfigurowanie build'a, zeby ziarno znalazlo sie w obu
> docelowych EARach. Podkreslam rowniez, ze ja skupialem sie na konkretnym
> problemie, jaki mial Daniel.
Zgoda - moja opinia dotyczyła szerszego problemu, nie podanego przez
Ciebie rozwiązania.
> Skoro klasy z shared libraries sa ladowane przez classloader'a kazdej
> odwolujacej sie do niej aplikacji, to efekt netto rozmiaru tych klas w
> runtimie jest taki sam.
Rzeczywiście, to co napisałem było nieprecyzyjne i mogło tak wyglądać
- chodziło mi raczej o to, że szybszy będzie deployment aplikacji/
modułów które są małe, czyli jeśli spore ich fragmenty (współdzielony
kod, np. frameworki) zostaną z nich wyłączone i zainstalowane
wcześniej jako współdzielona biblioteka, do której taka aplikacja
zawiera jedynie referencję. Deployment 150 MB jest wolniejszy niż 1.5
MB. Oczywiście, w runtime'ie, każda aplikacja korzystająca ze
współdzielonej biblioteki ma ODDZIELNĄ kopię klas.
> Jak bedzie trzeba wspolny kod zmodyfikowac, to i tak bedzie trzeba
> zredeployowac tego EARa ze wspolnym kodem (nie wymaga to czasem restartu
> wszystkich EARow ktore go uzywaja?:), wiec roznica ew. w ilosci EARow to
> zredeployowania.
Znowu zgoda, z tym, że ja odnosiłem się do sytuacji z wpakowaniem
współdzielonego kodu do serwerowego classpath. Tu, po modyfikacji
takiego kodu, musi nastąpić restart całego serwera. Z Shared Library
możesz wykonać redeployment aplikacji. Niekoniecznie wszystkich,
chyba, że wszystkie muszą używać tej nowej wersji (bo shared library,
znowu w przeciwieństwie do kodu na server classpath, mogą istnieć w
wielu wersjach). Wybór możliwości jakby większy. Do pełnego obrazu
dodałbym jeszcze możliwość istnienia wielu wersji aplikacji
równocześnie. Wtedy taka operacja modyfikacji może być prawie
całkowicie bez przerwy w działaniu aplikacji.
> Pytanie wiec, jak duza i skomplikowana musi byc
> aplikacja i jej wspolna funkcjonalnosc, zeby mialo to znaczenie?
Stopień skomplikowania aplikacji tu zbyt ważny nie jest. Ważniejsza
jest jej krytyczność. Jeśli aplikacja to okienko bankowości
internetowej, albo portal internetowy, to każda minuta przestoju jest
boleśnie policzalna.
> Ogolnie fajnie to wszystko wyglada na papierze (szczegolnie do mnie
> przemawia to zarzadzanie wersjami), ale tak czy owak wydaje mi sie, ze
> wymaga jakichs dodatkowych sztuczek konfiguracyjnych i dodatkowej wiedzy
> fachowej nt. weblogicowego DD (zob 1 akapit:). Jak widac do takich
> projektow trzeba bylo bardzo specjalistycznej weblogicowej wiedzy
> Waldka, pytanie jak by sobie z takimi bajerami poradzil przecietny
> zespol programistow, dla ktorego opanowanie samego stosu standardow JEE
> stanowi nie lada wyzwanie?
Nie wiem, czy na papierze, ale z moich obserwacji powiem, że sporo
Klientów z którymi pracuję tego używa (a funkcjonalność jest na rynku
od ponad 3 lat. Od czasu akwizycji wiele z produktów Oracle też z tego
korzysta). Bardzo często w postaci Shared Library są instalowane
frameworki (np. Spring).
Ja przy takich drobiazgach nie doradzam (no, może tylko informuję o
korzyściach albo odczarowuję mity, że można, itd.).
Ale masz rację - jak ze wszystkim trzeba popróbować i wyrobić sobie
zdanie - inne niż papierowe.
Wiedza specjalistyczna jest _żadna_ (BEA to nie była IBM, konsultingu
wdrożeniowego nie było, bo nie było potrzeby. Filozofia była prosta:
to co wychodziło z dewelopmentu miało być produktem dla Klientów).
Podsumując:
1. deployment shared library robi się TAK SAMO jak deployment
aplikacji (EAR/WAR)
2. jedyne co warto dodać to do MANIFEST.MF takiej współdzielonej
biblioteki dodać 3, opcjonalne, metadane: nazwę modułu, wersję
specyfikacji (interfejsu), wersję implementacji.
3. do tego dochodzi dodanie referencji do takiej biblioteki w DD
aplikacji korzystającej z tej biblioteki. Innego miejsca niż DD
specyficzny dla kontenera w Java EE na to nie ma.
4. cała referencja sprowadza się do odwołania się do tych 3 metadanych
- nazwy biblioteki i opcjonalnie wersji.
Nie wiem, gdzie dostrzegłeś potrzebę tych "sztuczek" ? Niezbyt widzę
też, jak możnaby zrobić to jeszcze prościej ? Pójść drogą OSGi, Spring-
DM czy Spring dm Server i dodać te metadane (w tym referencję) do
plików MANIFEST.MF ? OK, ale różnica w praktyce jest żadna (no może
taka, jak między plikiem płaskim .properties a XML)...
Wspominając o "specjalistycznej wiedzy", "przeciętności", itd.
odwołałbym się do rozwiązania z modyfikacją classloader'ów - TO wymaga
specjalistycznej i głębokiej wiedzy. Shared library nie. Tym razem ja
przywołam Twój "akapit 1" - ten dotyczący prostoty...
Na marginesie, to przyznam też, że ja nie kupuję tego nagminnie
pojawiającego się ostatnio argumentu o "nielada wyzwaniu" w opanowaniu
stosu Java EE (czy innego dotyczącego web services). Jakoś wierzę w
potencjał intelektualny ludzi, którzy się parają budową takich
aplikacji. Ani całego stosu znać nie trzeba, ani nie wszystkich
detali. Ilu z nas (chociaż) przeczytało specyfikację protokołu HTTP,
czy TCP/IP (RFC dla którego prawdopodobnie kilka razy przewyższa
liczbę specyfikacji w całej Java) ? A jakoś sprawnie możemy ich
używać...
> Mowiac wprost, takie niestandardowe
> rozwiazania kosztuja, bo wymagaja wiedzy, ktora albo mozna kupic albo
> zmusic pracownikow do nabycia. I potem stale dbac o to, zeby ktos z taka
> wiedza byl 'w poblizu'.
O fetyszu standaryzacji się już wypowiadałem (patrz F1 vs maluch, czy
MS Access vs. technologie bazodanowe) - dyskusja o świecie serwerowych
aplikacji Java będzie smutna i szkodliwa, jeśli przymknie się oczy i
ograniczy się tylko do tego, co aktualnie oferuje dany standard, czy
dana technologia. Zwłaszcza, że na grupie dyskusyjnej JUG'a nie
dyskutujemy o pieniądzach/kosztach, tylko o technologii.
Twojej opinii o konieczności posiadania "wiedzy w pobliżu" przyznam,
że nie zrozumiałem. "Wiedza w pobliżu" do czegoś co wymaga 3 prostych
kroków (z tego pierwszy jest standardowy, a drugi opcjonalny) i może 6
linii tekstu ?
> Pytanie zatem, jak duzy i kompleksowy musi byc
> projekt, zeby faktycznie sie to oplacalo?
Co do wielkości/kompleksowości projektu - podobnie jak z każdą inna
techniką/technologią - najlepiej niech o tym decydują sami
użytkownicy, jaka modularność jest im potrzebna. Z modularnością
jednak tak jest, że im większa aplikacja, tym bardziej modularności
potrzeba ("jak najprościej, ale nie prościej"). Tak jak napisałem
wcześniej - IMHO, nieinwazyjność polega m.in. na tym, że nie ma
przymusu używania i że łatwo się z danego podejścia wycofać.
> P.S. Jesli standardowe Javowe rozwiazania sa teraz sredniowieczne, to
> mam nadzieje, ze wiekszosc swojej kariery spedze w takim sredniowieczu,
> bo jakies ono bardziej oczywiste, przejrzyste i klarowne niz magiczne
> fajerwerki JEE;)
Moją wypowiedź co do powrotu do średniowiecza należy czytać w ten
sposób, że KAŻDA technologia jest najpierw high-endem, a potem ma
swoje Średniowiecze. Nie jest to obraźliwe. To naturalna kolej rzeczy.
I przyznam Ci rację, bo nie należy równać w dół - nie każdy danej
technologii (nie) potrzebuje.
Pozdrawiam,
Waldek Kot
Dariusz Kordonski
hmmm dyskusja zeszla troche na manowce w stosunku do oryginalnego posta i troche sie rozlegla zrobila (pewnie juz tylko ja i Waldek czytamy ten watek:), wiec porusze tylko najwazniejsze wg mnie aspekty.
1) wydaje mi sie zatem ze jestesmy zgodni co do tego, ze rozwiazania trzeba dobierac na miare problemow i dazyc do prostoty i redukcji kompleksowosci. Rozni nas zdaje sie wycena prostoty / zlozonosci (a moze nie rozni? w sumie poza przypadkiem Daniela dyskusja byla bardzo wysoko w chmurach, w sensie nie poruszania konkretnych przypadkow, wiec trudno to ocenic), ale to w sumie w duzej mierze kwestia tzw. gustow, a o tym sie ponoc nie dyskutuje.
2) w pewnym miejscu wspomniales, ze zaproponowane przeze mnie rozwiazanie polega na kopiowaniu kodu i w zwiazku z tym narusza zasade DRY. Nie zgadzam sie z tym. Rozwiazanie polega na skonfigurowaniu builda tak, aby EJB trafial do dwoch EARow w procesie automatycznego builda. W repozytorium zrodlowym mamy jedno miejsce z kodem / zasobami / metadanymi ziarna, wiec DRY nie jest naruszone. DRY dotyczy wg mnie nie powtarzania sie kodu (i innych zasobow) w repozytorium zrodlowym projektu, bo tylko to powoduje wzrost nakladow na utrzymanie aplikacji (zmiany w wielu miejscach zamiast jednego). To, czy dany kod po skompilowaniu do wyjsciowego artefaktu trafi w 1 miejsce, czy w 8, nie ma znaczenia. W takiej interpretacji kazdorazowe dodawanie bibliotek zewnetrznych do wyjsciowego artefaktu aplikacji naruszalo by zasade DRY, co jest lekka przesada.
3) w innym miejscu wspomniales, ze zaproponowane przeze mnie rozwiazanie wymaga manipulacji classloaderami. Nic bardziej dalszego od prawdy! To wlasnie ta nieszczesna alternatywa polegajaca na wolaniu ziarna pomiedzy EARami wymagala by manipulacji, rozwiazanie polegajace na dodaniu ziarna do obu EARow temu zapobiega! I dlatego wlasnie takie rozwiazanie polecalem.
4) nie jestem przeciwnikiem promowanego przez Ciebie rozwiazania, i nie neguje istnienia problemow, o ktorych pisales (szczegolnie odnosnie roznych wersji zaleznosci). Uwazam jednak ze w rzeczywistosci nie wystepuja one tak czesto. Np. wspomniane OSGi. Najbardziej znane projekty uzywajace tej technologii (przynajmniej mi najbardziej znane) to Eclipse i Glassfish. Kombajn IDE i serwer aplikacyjny - to niestety niekoniecznie to, z czym wiekszosc z nas pracuje na co dzien. Z drugiej strony mamy systemy typu 'embedded', gdzie redukcja zasobow pamieciowych zuzywanych przez aplikacje jest sprawa kluczowa. Byc moze to czesciowo skutek jeszcze malego rozprzestrzenienia OSGi (choc IMHO jest on juz w swoim 'mainstreamie'), ale mnie sie bardziej wydaje, ze 'typowe' projekty nie wykazuja sie wystarczajacym stopniem kompleksowosci i nie stwarzaja tak wielkich problemow, aby oplacalo sie inwestowac sie znaczace naklady w opanowanie tego typu technologii (przyczyna -> sa one nietrywialne, bo rowniez rozwiazuja nietrywialne probley). Rowniez w przypadku Jigsaw, o ile sie nie myle, glownym celem jest modularyzacja samej platformy Javy, aby np. nie trzeba bylo do obejrzenia apletu ladowac z internetu API do obslugi CORBy;) A API Javy bynajmniej trywialnym kawalkiem software'u nie jest.
5) nie do konca przemawia do mnie Twoje porownanie Mercedes vs. Maluch (wzglednie jezdzenie na 4-biegu samochodem 6-biegowym, bo to podobna analogia). Zauwaz, ze raz opanowawszy sztuke prowadzenia samochodu, przesiadka z Malucha do Mercedesa nie stanowi z reguly zadnego problemu (podkreslam Z REGULY!:), bo pomimo znaczacych roznic w 'implementacji' przemawiajacych na korzysc Mercedesa, ogolna koncepcje mamy taka sama:kierownica, biegi, 4 kola itd. Dlatego wiekszosc z nas zawsze wybierze Mercedesa, majac taki wybor (czy tez - zawsze wrzuci ten 6ty bieg, bo to kwestia tylko przezucania wajchy). Z kolei w przypadku rozwoju aplikacji zastosowanie nowego, bardziej zaawansowanego rozwiazania zamiast prostszego, dobrze znanego zawsze wiaze sie z nakladami na jego opanowanie (wzglednie na oplacenie odpowiednich ludzi:) Szczegolnie 'chlonne' sa wlasnie rozwiazania niestandardowe, specyficzne dla dostawcy. Dlatego, ze taka wiedza jest ulotna (takich rozwiazan nie stosujemy w kazdym projekcie) i czesto 'gubi sie', przez co trzeba ponownie ponosic ten sam wydatek na jej 'odzyskanie' (to mialem na mysli piszac, ze trzeba 'trzymac ludzi w poblizu' - mowiac wprost nauczy sie jeden programista czy tam jeden admin jak taka Shared Library konfigurowac i deployowac, a potem uciekna do konkurencji i wtedy jest dobrze, jesli w ogole ktos w firmie jest swiadomy ze taka wiedza wyciekla, bo z reguly konczy sie to raczej jakims pozarem). Moim zdaniem trafniejszym obrazem dyskutowanych przez nas problemow jest analogia Samochod <-> Samolot. Samochod jest stosunkowo latwy w opanowaniu, tradycyjny. No ale jak gdzies dalej czlowiek jedzie to dluuugo i niewygodnie. Samolotem to w godzinke do Niemiec mozna doleciec i jaka wygoda. Ale z reguly to jednak troche kosztuje (nawet tanie linie z reguly trzeba zamawiac dluugo przed lotem, zeby byly tanie, i generalnie nigdy nie mozemy byc pewni, czy tanio bedzie:), i na lotnisku 3ba wczesnie byc, kontrole przechodzic itd. itp. No i polega czlowiek na pilocie, ze umie tym ustrojstwem sterowac (czy tez moze w wiekszym stopniu na komputerze pokladowym). A w samochod po prostu sie wsiada i jedzie. Najgorsze co mozna sobie zatem wymyslic (a niestety takie tendencje czesto mozna zaobserwowac w prawdziwych projektach) to kupowanie biletu na samolot zeby wyskoczyc do sklepu za rogiem po piwo.
Podsumowujac zatem, nie ujmuje wartosci wszelkim dobrom, jakie oferuja standardy JEE czy tez rozwiazania typu vendor-specific, jak opisane przez Ciebie Shared Library. Uwazam tylko, ze nalezy starannie sie zastanowic, zanim sie jakiekolwiek z nich uzyje. Najlepiej miec w reku niezbity dowod, ze rzeczywiscie przyczynia sie do rozwiazania ISTNIEJACYCH problemow, a nie do zwiekszenia stopnia kompleksowosci projektu. Nie uwazam rowniez, ze JSE jest sredniowieczem, a JEE high-endem. Trudno w ogole porownywac te 2 platformy, bo tak naprawde jedna jest rozszerzeniem drugiej i sluza one rozwiazaniu zupelnie innych problemow. JSE i zwiazane z nia koncepcje sa fundamentem, bez ktorego zadne 'high-endowe' technologie by nie istnialy.
Nizbyt zwiezle mi wyszly te 'najwazniejsze aspekty';)
Pozdrawiam,
Darek
Jacek Laskowski
> hmmm dyskusja zeszla troche na manowce w stosunku do oryginalnego posta i
> troche sie rozlegla zrobila (pewnie juz tylko ja i Waldek czytamy ten
> watek:), wiec porusze tylko najwazniejsze wg mnie aspekty.
...
> Nizbyt zwiezle mi wyszly te 'najwazniejsze aspekty';)
A ja wciąż cierpliwie czytam i uważam, że wciąż rozmawiacie o tym
samym - uproszczeniach, ale nie widzę w Was żadnej ochoty zrozumienia
drugiej strony. Było przez moment niewesoło (=niemerytorycznie, a
jedynie przerzucanie się g...), ale ostatecznie dużo napisane i pewnie
to odstraszy zainteresowanych dyskusją (bo im cierpliwości nie
starczy).
Nie widzę innego rozwiązania, jak tylko prezentacja problemu i
rozwiązania na spotkaniu WJUGa, a później ocena przez publikę. Jak to
brzmi? Jestem w stanie przedstawić oba tematy, ale wolałbym innych w
akcji (bo obawiam się zmęczenia materiału po stronie publiki :))
p.s. To również świetny materiał na filmik, nieprawdaż?
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://wszystkojawne.pl
p.s. Szukam speca/firmy od grafiki/CSS/HTML
Dariusz Kordonski
a ja uwazam ze dyskusja jak najbardziej merytoryczna (co najwyzej z duza doza prywatnych opinii kazdej ze stron) i nikt niczym w nikogo nie rzucal (przynajmniej nie zauwazylem w mojej wymianie zdan z Waldkiem):P
Mysle, ze nie bardzo tu widac temat na prezentacje, bo dyskusja byla bardzo rozlegla, wielotorowa i abstrakcyjna:) i czesto ocierajaca sie o prywatne opinie i gusta (=nikt nikogo nie przekona), a to nie jest dobry material do prezentowania. Ja sie zatem wylamuje, jak kiedys zrobie prezentacje na JUGu to na bardziej konkretny temat;)
Pozdrawiam,
Darek
Jacek Laskowski
> Mysle, ze nie bardzo tu widac temat na prezentacje, bo dyskusja byla bardzo
> rozlegla, wielotorowa i abstrakcyjna:) i czesto ocierajaca sie o prywatne
> opinie i gusta (=nikt nikogo nie przekona), a to nie jest dobry material do
> prezentowania. Ja sie zatem wylamuje, jak kiedys zrobie prezentacje na JUGu
> to na bardziej konkretny temat;)
Przykłady tematów na prezentacje z tego wątku:
1. Współdzielenie bibliotek (jar, ejb-jar) między aplikacjami EAR.
2. Użycie Shared Libraries w Oracle WebLogic Server
3. Użycie Shared Libraries w IBM WebSphere Application Server
4. Użycie OSGi do współdzielenia bibliotek na w/w wspomnianych
serwerach + GlassFish (potencjalnie)
5. Zestawienie ant/maven, aby współdzielić zależności między projektami
6. Wady i zalety w/w podejść (to jak praca licencjacka/inżynierska)
Mało? Ja naliczyłem 6 z 4. podzielonym na 3 podprezentacje, co daje 8
prezentacji i na pewno wykraczające 1h. Dla mnie to spełnienie marzeń,
gdyby dyskusja skończyła się nawet połową prezentacji jak wymieniłem
wyżej.
Chętni?
Dariusz Kordonski
Pozdr,
Darek
rysiek
Jezeli sie nie myle i dobrze pamietam to powinienes byc w stanie
rozwiazac ten problem przez uzycie archiwow SAR (Service ARchive).
Chyba nikt o nich nie wspominal w calej tej dyskusji (a przeczytalem
cala :P). Roznia sie one od EAR'ow tym, ze udostepniaja osadzone w
nich uslugi. Minusem jest to, ze jest to oczywiscie rozwiazanie
JBoss'a a nie spec. JEE. Jesli chodzi o samo uzycie to jest tu pewna
dowolnosc, albo tego EAR'a ktory udostepnia usluge przemianujesz na
SAR'a, albo sama usluge przeniesiesz do 3 archiwum i oba EARy powinny
moc z niego korzystac. Nie wiem, jak skomplikowana czy krytyczna jest
Twoja aplikacja, ale obstawiam, ze to rozwiazanie by Ci wystarczylo
bez potrzeby płacenia za Shared Library czy inwestowania czasu/
pieniędzy w OSGi.
Pozdr,
Rysiek
Waldek Kot
> Jezeli sie nie myle i dobrze pamietam to powinienes byc w stanie
> rozwiazac ten problem przez uzycie archiwow SAR (Service ARchive).
Cześć,
Rysiek, jesteś pewien, że to dobra rekomendacja dla problemu Daniela ?
Bo SAR'y nie zostały chyba do takich celów wymyślone, a raczej jako
mechanizm na dodawanie funkcjonalności do serwera aplikacyjnego (tu:
JBoss) ? Czyli raczej poziom niżej niż kod aplikacyjny ?
Tak jak odpisałem SZimano wcześniej, moja wypowiedź odnosiła się do
opinii Darka i dotyczyła możliwości (i sensowności) współdzielenia
kodu, który już jest w postaci EAR'ów.
> Chyba nikt o nich nie wspominal w calej tej dyskusji (a przeczytalem
> cala :P).
Tak jak odpisałem SZimano wcześniej, moja wypowiedź odnosiła się do
opinii Darka i dotyczyła możliwości (i sensowności) współdzielenia
kodu, który już jest w postaci EAR'ów.
> Minusem jest to, ze jest to oczywiscie rozwiazanie
> JBoss'a a nie spec. JEE.
> Jesli chodzi o samo uzycie to jest tu pewna
> dowolnosc, albo tego EAR'a ktory udostepnia usluge przemianujesz na
> SAR'a, albo sama usluge przeniesiesz do 3 archiwum i oba EARy powinny
> moc z niego korzystac. Nie wiem, jak skomplikowana czy krytyczna jest
> Twoja aplikacja, ale obstawiam, ze to rozwiazanie by Ci wystarczylo
> bez potrzeby płacenia za Shared Library czy inwestowania czasu/
> pieniędzy w OSGi.
Nie mam problemu z tym, że jest to rozwiązanie JBoss'a ! Napisałem, że
jestem zwolennikiem korzystania z tego co oferuje użytkowana
technologia (wbrew temu co - może błędnie - odczytuję między liniami,
myślę tak o KAŻDEJ technologii, w tym i JBoss'a), nawet jeśli jest to
specyficzne. Ale też uważam, że warto to robić inteligentnie. Jakąś
składową tego "inteligentnie" jest coś co (idąc trochę za Springiem)
można nazwać "nieinwazyjnością" danej technologii (non-intrusive).
Czyli między innymi także, na ile łatwo się z takiej technologii
wycofać. Wspomniany tu przez Ciebie SAR jako pomysł na współdzielenie
kodu _aplikacyjnego_ chyba na miano małoinwazyjnej technologii tu,
IMHO, raczej nie zasługuje:
- inny deployment niż pozostałych komponentów Java EE
- rozpakowanie takiego współdzielonego kodu z SAR'a i przepakowanie go
do czegoś innego proste nie będzie
- złożona modyfikacja kodu klienckiego (=korzystającego z tego
współdzielonego kodu) - chyba, że od początku kod ten jest "usługowy",
ale wtedy też trzeba będzie zapewnić, że to do czego przepakowujemy
(albo to do czego wracamy) też będzie zorientowane usługowo (nie żebym
podejście usługowe określał jako złe - ale trzeba sporo zainwestować
czasu wcześniej, żeby taka ewentualna modyfikacja technologii
usługowej była prosta). Gorzej (czytaj znacznie więcej zmian), jeśli
chcesz cofnąć się (znowu, to nie jest tu pejoratywne określenie) do
podejścia ze współdzieleniem kodu "poprzez classloader".
Nawet jeśli to do czego będzie powrót to OSGi, to jeszcze musi to być
"usługowa" część OSGi, nie ta "package'owa".
Notabene - bardzo słusznie, że dodałeś do tej dyskusji usługowy (w
sensie SOA) sposób współdzielenia funkcjonalności !
Oczywiście, inteligentnym skryptem budującym kod da się raz opakować
jako SAR (przy czym "zorientowania usługowego" się tym skryptem raczej
nie zrobi ;-)) innym razem jako JAR, czy Shared Library i zrobić wiele
innych rzeczy, ale po prostu jako mniej inwazyjne podejście postrzegam
raptem zmianę deployment'u już raz zbudowanego modułu niż powtórne
jego budowanie i składanie. Konkretnie: mamy już zbudowany moduł (WAR/
RAR/EAR/...) i chcemy, by z jego kodu mogły (łatwo) skorzystać inne.
Możemy po prostu wykonać redeployment tego modułu jako shared library
i do kodu modułu klienckiego dodać referencję do tej shared library.
Nie ma potrzeby rebuild'u całego EAR'a. Modyfikacja skryptów
budujących jest minimalna. Łatwo się wycofać, itd.
Popraw mnie też jeśli się mylę, ale bezpośrednio (bez modyfikacji) EAR
nie może być SAR'em ? Versus podejście typu Shared Library ma też
chyba inny cykl życia (nie do końca jest to biblioteka pasywnie
czekająca na to, aż ktoś ją wywoła. SAR, to raczej aktywnie
działający, "zgrany" z cyklem życia serwera aplikacyjnego) ?
Jeśli Darek określił Shared Library jako "potrzebującą
<<sztuczek>>" (z czym się nie zgodziłem), to podejście Shared Library
versus SAR jest IMHO dosyć radykalnie prostsze i wymagające radykalnie
mniejszego nakładu czasu. A czas to też pieniądz ;-)
Znowu, to nie zarzut do SAR, ale raczej coś co wynika z tego, że SAR
wygląda mi raczej jako sposób na dodawanie możliwości do kontenera
aplikacyjnego, niż dla zastosowań aplikacyjnych).
Prostota, nieinwazyjność, rozwiązywanie/minimalizowanie problemu
(zamiast przesuwać go na później/w inne miejsce) współdzielenia kodu
aplikacyjnego (w tym EAR'ów), to były słowa kluczowe tej wymiany
opinii.
Pozdrawiam,
Waldek Kot
rysiek
On 22 Gru, 23:18, Waldek Kot <waldek....@googlemail.com> wrote:
> On Dec 22, 9:10 pm, rysiek <ryszard.koz...@jboss.com> wrote:
>
> > Jezeli sie nie myle i dobrze pamietam to powinienes byc w stanie
> > rozwiazac ten problem przez uzycie archiwow SAR (Service ARchive).
> Rysiek, jesteś pewien, że to dobra rekomendacja dla problemu Daniela ?
> Bo SAR'y nie zostały chyba do takich celów wymyślone, a raczej jako
> mechanizm na dodawanie funkcjonalności do serwera aplikacyjnego (tu:
> JBoss) ? Czyli raczej poziom niżej niż kod aplikacyjny ?
Tak zostaly wymyslone dla samego serwera aplikacyjnego, ale jesli
powinny byly zostac zabronione to by zostaly, daja pewne dodatkowe
opcje i niektorzy je wykorzystuja, rowniez do budowy aplikacji.
> Tak jak odpisałem SZimano wcześniej, moja wypowiedź odnosiła się do
> opinii Darka i dotyczyła możliwości (i sensowności) współdzielenia
> kodu, który już jest w postaci EAR'ów.
Nie odnosilem sie do Twojej wypowiedzi, ale do pytania Daniela (kopia
jego wpisu byla pod moja odpowiedzia) bo sobie przypomnialem o tej
opcji.
> > Chyba nikt o nich nie wspominal w calej tej dyskusji (a przeczytalem
> > cala :P).
>
> Tak jak odpisałem SZimano wcześniej, moja wypowiedź odnosiła się do
> opinii Darka i dotyczyła możliwości (i sensowności) współdzielenia
> kodu, który już jest w postaci EAR'ów.
Co nie zmienia faktu, ze tak jak powiedzialem, nikt nie wspominal o
SARach wiec chcialem to zrobic i zobaczyc co inni na to.
> > Minusem jest to, ze jest to oczywiscie rozwiazanie
> > JBoss'a a nie spec. JEE.
> > Jesli chodzi o samo uzycie to jest tu pewna
> > dowolnosc, albo tego EAR'a ktory udostepnia usluge przemianujesz na
> > SAR'a, albo sama usluge przeniesiesz do 3 archiwum i oba EARy powinny
> > moc z niego korzystac. Nie wiem, jak skomplikowana czy krytyczna jest
> > Twoja aplikacja, ale obstawiam, ze to rozwiazanie by Ci wystarczylo
> > bez potrzeby płacenia za Shared Library czy inwestowania czasu/
> > pieniędzy w OSGi.
>
> Nie mam problemu z tym, że jest to rozwiązanie JBoss'a !
A czy ja Ci to zarzucam? Nawet nie odnosilem sie do Twojej
wypowiedzi.
> Napisałem, że
> jestem zwolennikiem korzystania z tego co oferuje użytkowana
> technologia (wbrew temu co - może błędnie - odczytuję między liniami,
> myślę tak o KAŻDEJ technologii, w tym i JBoss'a), nawet jeśli jest to
> specyficzne. Ale też uważam, że warto to robić inteligentnie. Jakąś
> składową tego "inteligentnie" jest coś co (idąc trochę za Springiem)
> można nazwać "nieinwazyjnością" danej technologii (non-intrusive).
> Czyli między innymi także, na ile łatwo się z takiej technologii
> wycofać.
Generalnie tak, aczkolwiek ujalbym to troche inaczej. Dla mnie chodzi
o to, aby koszt(czaso-pieniężny) na inwestycje w wykorzystanie
najlepszego rozwiazania nie byl wiekszy od kosztu ewentualnego
wycofania sie z jakiejs gorszej jesli jest ona tansza, jesli w ogole
jest tansza oczywiscie ;). Kwestia czy szukamy wyidealizowanego
podejscia czy myslimy o realnie "najlepszym", a to jest baaaardzo
wzgledna sprawa niestety.
> Wspomniany tu przez Ciebie SAR jako pomysł na współdzielenie
> kodu _aplikacyjnego_ chyba na miano małoinwazyjnej technologii tu,
> IMHO, raczej nie zasługuje:
> - inny deployment niż pozostałych komponentów Java EE
Nie widze w tym zarzutu poza tym, o ktorym wspomnialem, czyli ze nie
jest to JEE, a to dla mnie osobiscie maly minus bo i tak trudno sie
zmiescic w ramach JEE generalnie.
> - rozpakowanie takiego współdzielonego kodu z SAR'a i przepakowanie go
> do czegoś innego proste nie będzie
Rownie trudne jak przepakowanie go z EARa chyba.
> - złożona modyfikacja kodu klienckiego (=korzystającego z tego
> współdzielonego kodu) - chyba, że od początku kod ten jest "usługowy",
> ale wtedy też trzeba będzie zapewnić, że to do czego przepakowujemy
> (albo to do czego wracamy) też będzie zorientowane usługowo (nie żebym
> podejście usługowe określał jako złe - ale trzeba sporo zainwestować
> czasu wcześniej, żeby taka ewentualna modyfikacja technologii
> usługowej była prosta).
Tego nie kapuje, przeciez kod kliencki sie nie zmienia jesli wyrzucisz
tego bean'a do SARa.
> Gorzej (czytaj znacznie więcej zmian), jeśli
> chcesz cofnąć się (znowu, to nie jest tu pejoratywne określenie) do
> podejścia ze współdzieleniem kodu "poprzez classloader".
Znacznie wiecej zmian porownujac do, SL? Generalnie trzebaby zmienic
rozszerzenie z SAR na EAR i zastapic odpowiedni plik metadata, no a
potem skonfigurowac wspolny classloader czyli dodac wpis w kazdym
EAR'ze. Dla SLa byloby mniej o ten pierwszy krok, ale czy to znacznie
to bym nie powiedzial ;).
> Nawet jeśli to do czego będzie powrót to OSGi, to jeszcze musi to być
> "usługowa" część OSGi, nie ta "package'owa".
Ta, ale to powrot do problemu samej aplikacji i tego wspoldzielenia, a
to juz przedyskutowaliscie :).
> Notabene - bardzo słusznie, że dodałeś do tej dyskusji usługowy (w
> sensie SOA) sposób współdzielenia funkcjonalności !
No SOA o jednym beanie to tak troche gornolotnie, ale dla mnie jest to
serwis/usluga, ktora trzeba udostepnic w ten czy inny sposob. Stad tez
pomysl Service Archive.
> Oczywiście, inteligentnym skryptem budującym kod da się raz opakować
> jako SAR (przy czym "zorientowania usługowego" się tym skryptem raczej
> nie zrobi ;-)) innym razem jako JAR, czy Shared Library i zrobić wiele
> innych rzeczy, ale po prostu jako mniej inwazyjne podejście postrzegam
> raptem zmianę deployment'u już raz zbudowanego modułu niż powtórne
> jego budowanie i składanie. Konkretnie: mamy już zbudowany moduł (WAR/
> RAR/EAR/...) i chcemy, by z jego kodu mogły (łatwo) skorzystać inne.
> Możemy po prostu wykonać redeployment tego modułu jako shared library
> i do kodu modułu klienckiego dodać referencję do tej shared library.
> Nie ma potrzeby rebuild'u całego EAR'a. Modyfikacja skryptów
> budujących jest minimalna. Łatwo się wycofać, itd.
Tak, SL bardziej cool dla tego przypadku, ale ja sie odnosilem do
pierwszego postu i dla niego mimo wszystko wybralbym SARa lub Scoped
Repository.
>
> Popraw mnie też jeśli się mylę, ale bezpośrednio (bez modyfikacji) EAR
> nie może być SAR'em ?
Raczej nie, pewnie moznaby zaczarowac cos w konfiguracji deployerow,
ale to raczej nie "kulturalne" ;)
> Versus podejście typu Shared Library ma też
> chyba inny cykl życia (nie do końca jest to biblioteka pasywnie
> czekająca na to, aż ktoś ją wywoła. SAR, to raczej aktywnie
> działający, "zgrany" z cyklem życia serwera aplikacyjnego) ?
Tak, chyba. Tylko znowu, no JBoss nie ma SLa wiec nie ma co
porownywac.
>
> Jeśli Darek określił Shared Library jako "potrzebującą
> <<sztuczek>>" (z czym się nie zgodziłem), to podejście Shared Library
> versus SAR jest IMHO dosyć radykalnie prostsze i wymagające radykalnie
> mniejszego nakładu czasu. A czas to też pieniądz ;-)
Ale SLa w JBossie nie ma i jest chyba tylko w produkcie Oracle (nie
wiem czy sa inne implementacje?) a ten produkt kosztuje. Wiec to jest
pytanie czy taniej wyjdzie zainwestowac w Oracle'a i miec SLa czy w
wiecej czasu i uzyc SARow, czy OSGi czy Scoped Repository. Wszystko
zalezy od klasy aplikacji, budzetu i wielu innych aspektow.
> Znowu, to nie zarzut do SAR, ale raczej coś co wynika z tego, że SAR
> wygląda mi raczej jako sposób na dodawanie możliwości do kontenera
> aplikacyjnego, niż dla zastosowań aplikacyjnych).
No ja po prostu nie mam takiego odczucia, traktuje to jako added value
do JEE. Na przyklad JBoss Portal jest dostarczany jako sar
(przynajmniej wersja community). Tak swoja droga, to pytanie pewnie
oddzielna dyskusje, ale czy zdeployowana aplikacja nie staje sie
wlasnie rozszerzeniem i czescia serwera aplikacji a tym samym jak
najbardziej moze uzywac wszystkiego czego uzywa sam serwer aplikacji?
> Prostota, nieinwazyjność, rozwiązywanie/minimalizowanie problemu
> (zamiast przesuwać go na później/w inne miejsce) współdzielenia kodu
> aplikacyjnego (w tym EAR'ów), to były słowa kluczowe tej wymiany
> opinii.
To troche inna dyskusja po prostu.
Rysiek