> Pretoze pokial nedokaze buduca "referencna plaforma tomcat" podporovat > dynamic service model tak bude v porovnani s aplikacnymi servermi stale > tahat za kratsi koniec.
:-D a AS je proboha podporuje jak vzhledem k J2EE specce? Ekvivalent modularity jakou definuje OSGi nenabizi a problem pouzivat OSGi v ramci AS je toho dukazem a to i pres to, ze plno AS se rozhodlo jejich vlastni infrastrukturu prepsat od OSGi bundlu. > Predstava ze by enterprise aplikaciu mal tvorit jeden war mi pride ako > pokus o zart - uz len preto ze ked to cele zakreslim na "white board" a > bude to len jedna "krabica" , ukazem na to a poviem ze je to praca teamu > ludi za 6 mesiacov tak tomu nebude nikto verit :) Zert je zrejme tohle konstatovani, jak pozdeji priznavate . Jak souvisi architektura aplikace s jejim packagengem?! Takze kdyz neco navrhnu do deseti EJB modulu, pridam tri WARy a ktomu nejaky SAR tam mam enterprise aplikaci. > ale teraz vaznejsie .... ak dokazem u velkej aplikacie oddelit logiku do > viacerych (aj v ramci jedneho jvm kooperujucich) aplikacii tak neskorsia > rezia v uprave iba jednej z nich je podstatne jednoduchsia (aj z pohladu > testovania a predikcie spravania) ako konstruovat a dodavat nejaky "obludny > 100MB war file" - ak nas teda "sikovne" nenapadne presunut gro veci do > zdielanych kniznic a pri uprave pojde pre istotu dole cely server. ... Dobre oddeleni odpovednosti se dela na jine urovni nez je packaging aplikace. Takze cely ten odstavec je v podstate irelevantni.
