11 komentáře “Seriál: Modulární systémy ve Spring Frameworku

  1. Zpětný odkaz: Myšlenky dne otce Fura » Blog Archive » Hledáme parťáka do Forresta

  2. Pro NetBeans je to hracka stejne jako pro Eclipse a ve sve podstate pro jakykoliv kontejner, ktery s modularnosti aplikace pocita. Bohuzel to je problem v J2EE kontejnerech, kde se s necim podobnym nepocitalo. Tam je v podstate jedina moznost a to napsat si vlastni reseni a nebo pouzit nejake open source proprietarni jako OSGi.

  3. Classloadery aplikacniho serveru je prave onen problem, pokud me pamet neklame, tak v nejake specce je dokonce zakazano vytvaret si vlastni classloadery. Navic v kazdem aplikacnim serveru se chovani classloaderu lisi, takze se to musi specialne nastavit proprietarnimi deployment descriptory. Nam by OSGi poskytlo nekolik vlastnosti: moznost explicitne exportovat pouze urcitou cast API (slo by castecne dosahnout pomoci fasady), runtime reload/deploy modulu, oddeleni classpath jednotlivych modulu (rozdilne verze stejnych knihoven – potencialne). Neco z tech vlastnosti by slo zrejme naimplementovat svepomoci, ale proc to delat, kdy je tu OSGi. Spring OSGi nam do toho pasuje naramne, protoze vetsina aplikacnich modulu je managovana springovskym IoC kontejnerem.

    My jsme ve stadiu kdy vime, co bychom asi tak potrebovali a co by nam OSGi prineslo. Tedka analyzujeme jake by to melo dopady na deployment a strukturu aplikace a co by to vlastne znamenalo. Mozna budeme delat i nejaky prototyp pro overeni funkcnosti. Pokud budou nejake zajimave informace, tak se o ne rad podelim ;-).

  4. Ad jk: client side to je jiné kafe, tam si člověk může dovolit lecos ;). Ale my jedeme skoro výhradně server side …

  5. Skoro bych si tipnul, že tohle by mohlo umět to OSGi (usuzuji z fíčury „mít možnost provozovat různé verze modulů současně“). My nejdeme za hranice Spring frameworku a classloadery necháváme na pokoji ve stavu, v jakém nám je připraví cílový server. Ono vůbec, hraní si s classloadery je někdy spíše ke škodě – při deployi do J2EE serveru máte problém – classloading by tam měl být plně v režii serveru – podobně třeba jako správa threadů. Takže v tomhle ohledu bych byl stejně opatrný.

  6. Resim neco podobneho nad modularnim systemem v Netbeans. Podle dokumentace by to nemel byt problem, napred se vytvori jedna bean factory per classloader (modul) a ty se slozi do contextu.

  7. Me by zajimalo, jestli umite vyresit i to, aby kazdy modul mel vlastni class path (napr. stare nebo patchovane verze knihoven)?

  8. V podstatě jde jenom o jednoduché aplikování vlastností Springu. Nečekej od toho nic světoborného, ale zatím se nám to docela osvědčilo. Řeší to ty naše problémy a není to žádné velké hackování, a to je hlavní.

    Co ale v textu nebude je nasazení toho systému v prostředí EJB. To je pro mě trošku horká půda – nejsem moc velký odborník na EJB a už jsem si několikrát naběhl, to klidně přiznám. Při vývoji navíc EJB nepoužíváme, takže fakt ani praktické zkušenosti nemám. Nerad uváděl někoho v omyl nějakými mými neověřenými informacemi a proto se tomuhle tématu úplně vyhnu.

    BTW – ty už jsi nasadil OSGi ve Springu? Nějaké zkušenosti? Já se čísla verze 0.7 docela obávám pro nějaké vážnější nasazení na projektu.

  9. Resime neco podobneho a ja se prave klonim k pouziti OSGi. OSGi podle me nestoji na principu vsechno nebo nic, takze pokud ty „enterprise“ featury nepotrebujes, tak te je nikdo nenuti pouzivat. Ja mam z OSGi jediny problem, a to ze vidim pesimisticky jeho funkcnost v ruznych aplikacnich serverech a navic ve spolupraci s EJB. Kazdopadne jsi rad prectu o vasem reseni.