Böszörményi Péter <tsilvelbmz@gmail.com>

Re: [Java lista] Re: j2ee fejlesztes csapatban + XP

Huh, hat hazudnek, ha azt mondanam, hogy minden teljesen tiszta. :) 
Latom, meg messze van az, hogy elmondhassam: na, van mar valami 
ralatasom a dolgokra. Itt jon egy - talan sokszor elhangozz - kerdes. 
Merre es hogyan erdemes tovabb menni? Nincsen szinte semmi tapasztalatom 
  ezen a teruleten, de mindenkeppen meg szeretnem ismerni oket (mar csak 
azert is, h ertsem, hogy mit beszelnek korulottem). Van-e esetleg valami 
ajanlott utvonal, amit kovetve erdemes megismerkedni a kulonbozo 
lehetosegekkel, es hogy melyikhez mikor kell nyulni?

javalist@javasite.bme.hu wrote:
> Hat, hogyismondjam... :)
> 
> [ebben a diskurzusban maradok a Spring mellett, de az ervek 99%-a 
> ervenyes barmely mas pehelykonnyu IoC container-re]
> IoC := Inversion of Control
> http://www.martinfowler.com/articles/injection.html
> 
> Eloszor is le kell tisztazni, hogy a modern "alternativ" keretrendszerek 
> (a la Spring es tsa) NEM ZARJAK ki a J2EE-t. Tehat a kerdes nem az hogy 
> J2EE VAGY SPRING, hanem "hardcore" J2EE (kovetve a Sun blueprints 
> doksijait) vagy "modern" felfogasu J2EE. Elvegre mindegyik IoC container 
> pont a J2EE problematikat celozza meg! Tovabba, azzal hogy pl, Spring-et 
> hasznalsz az alkalmazasodban, az semmikeppen sem lesz "kevesbe" J2EE 
> alkamazas mint egy "hardcore" J2EE alkalmazas, semmi J2EE altal kinalt 
> funkcionalitast nem veszitesz, sot!
> 
> Kello pelda erre a (sokat szidott) magyarorszag.hu 
> <http://magyarorszag.hu> auth szervere. Tudomasom szerint az valojaban 
> egy Spring-be agyazott alkalmazas (!), kello J2EE "front-end"-be 
> burkolva, "kivulrol" egy szabvanyos JBoss-ra telepitett EAR. De a 
> "felszinen" huzodo WS szolgaltatasok csak "proxy"-k a Spring 
> containerben levo POJO (100% J2SE) osztalyok felett! A 
> tranzakcionalitast is pl. a Spring adta (mert ilyet is tud, J2SE 
> osztalyok felett AOP segitsegevel AppServer nelkul!).
> 
> Tudni kell, hogy a Spring (es a tarsai) valojaban a J2EE "stack"-bol 
> foleg az Entity Bean-ek es a Stateful Session Bean-ek ellen 
> harcol/szurkol. Igen, megjelent az EJB3.0, es kb. azt tudja amit a 
> Spring es holdudvara tudta 2 evvel ezelott, DE az EJB 3.0 container maga 
> utan huzza a "hatalmas farkat", a pre3.0 J2EE kompatibilitas miatt! 
> Kinek kell ez az extra teher, a lagymatag, lusta es lassu es fokent 
> kenyes containerek? Te magad peldaloztal az Oracle iAS-sal.... A 
> MessageDrivenBean es a StatelessSessionBean viszont "jo fiuk" a Spring 
> szellemeben is....
> 
> Tehat pislogni igenis erdemes az "alternativ megoldasok" irant is. Es ne 
> feledd: a vagy nem kizaro-vagy.
> 
> ~t~
> 
> 
> On 8/23/06, * javalist@javasite.bme.hu 
> <mailto:javalist@javasite.bme.hu>* <javalist@javasite.bme.hu 
> <mailto:javalist@javasite.bme.hu>> wrote:
> 
>     *** Felado: Böszörményi Péter <zmblevlist@gmail.com
>     <mailto:zmblevlist@gmail.com>> ***
> 
>     Szoval - ha jol ertettem - ha az ember j2ee fele hajaz (EJB + tsa),
>     akkor - mondjuk - sajat gepen futt egy egszerubb appserver, ott
>     csinalgatja a dolgait a fejleszto, egy masik szerveren a fejlesztok
>     altal keszitott kodhalmazt osszevasaljak egy programma, teszt, stb.
>     Masik ut lehet - ahogyan te hivtad - a "tavasz szel" utja. Ebben az
>     esetben nincsenek nagy bohom appserverek, max egy servlet container,
>     oszt jonapot, minden megy a jol be valt utakon.
>     Az ember teljesen el tud a sok keretrendszerben. Itt merul fel az a
>     kerdes: merre fele erdemes pislgogni? J2ee irany, vagy valami harmadik
>     fel altal csinalt rendszer (pl. springs)? Bar, itt mindenki ugyis a
>     sajat kedvencere fog szavazni. :)
> 
>