Weblogic vs. Glassfish

hat en (most a Sunos mivolttol eltekintve) csak szivtam JBossal. ennek ellenere jofej emberek dolgoznak ott, volt akivel leveleztem, meg volt aki segitett debuggolni java kodot. :)

Ami en tapasztaltam, hogy a Jboss-hoz, es WebSphere-hez kepest nem olyan kiforrott, latszik, hogy meg az elejen vannak a fejlesztesnek, kell meg 1-2 ev. Kicsi projectekre jo, de arra jo a jboss is, es azt el kell ismerni, hogy a webcontainere piszok gyors es jo, latszik hogy mind implementacioban, mind tervezesben jobb mint a tobbi. Egyebkent a Jbossnak is szep a kodja, most javitottam benne egy ket dolgot, es jol tervezett es atlathato, ami nem mondhato el a a WebSphere-rol(Jad).

ismerem, koszi. :)

szemelyes velemeny: openjpa, axis, cxf tok felesleges. a sunos RI sokkal jobb minosegu, igy ezek olyan +sokadig megvalositasok. a jetty jo dolog, de minek, mikor ott a grizzly :).

azt pedig, hogy mikrokernel, es azt toltjuk be amit akarunk, mar a gfv3 is tudja/ni fogja. [apache felix az OSGi -os moka, meg van egy masik aminek nem jut eszembe a neve, ami a konkret mikrokernel impl]

Jeez, mond azt, hogy ismered a wicket-et, és ahhoz képest mit akarsz a keretrendszerbe rakni? :)

Wicket + Spring + Jetty. Fejlesztésre ütős kombináció, deploymentre már inkább glassfish, bár van aki a jetty-re is esküszik...

"egy altalanos celu DI fw. semmi mas."

Van, hogy az bőven elég.

"(amikor mar ugyis tranzakciokat akarsz, replikalt sessionokkel, sok gepen elosztva, akkor...)"

Na és pont ez lesz az a pont, ahol a Glassfish ugrik a kalapba, hacsak nem kezded el sima web container-nek használni és minden mást kézzel megoldani. Kézzel megoldani - pl. Spring-gel, alkalmazásszinten:).

Mondom ezt úgy, hogy én még mindig nem vagyok egy nagy Spring fan.

Guice: tudom, de ahogy Joel is írta: néha tökéletesen elég az is
Spring: tudom :)

jo, csak mondom, hogy ha valakinek van erre penze, lehet venni supportot, ha meg nincs, akkor ingyen is lehet hasznalni, max elbukod a friss patcheket, meg a sunsolveos eszkalaciot.

Micsoda kikövetelése a kommentelésnek... Az update-elt véleményem az, hogy adott alkalmazáshoz mérni kell, aztán ami jobb, használni. Amióta meg profiler-t is írunk, azóta pláne azt mondom, hogy mindent mérni :)
(5 évvel ezelőtt amúgy nem hiszem hogy mértem volna ilyesmit, bár akkor fejlesztettem JBossra, de Glassfish-sel csak később kezdtem el játszani...)

Mostanában appservert nem mértem, megszokásból van glassfish + fejlesztéshez Jetty (gyorsabb a roundtrip). Tavaly a Wicket-re néztem vs. Freemarker + Spring MVC vs Stripes vs pure Servlet + JSP teljesítményt, de mivel nem dokumentáltuk, már nem emlékszem a pontos arányokra. A Freemarker jobb volt mindegyiknél, de a Wicket sem volt annyira rosszabb, hogy végül nálunk most az a preferált saját fejlesztésre + Spring + non-rdbms, de ez utóbbi még under construction (cserébe múltkor kihoztunk belőle 1000+ TPS-t). Aztán ügyfélnél meg jön ami jön...

Kicsit még magyarázok, mert egyébként ez fontos, és én sem fogom elárulni, hogy hány év JPA használat után világosodtam meg.

Szóval, JPA alapja a PersistenceContext. Amikor valahogyan nyitsz egy új EntityManager-t, akkor azzal létrejön egy ilyen. Ha az EM-től lekérsz egy objektumot (find, query) akkor az az objektum kapcsolódni fog egy nyitott PersistenceContexthez.

Egy PersistenceContext alapesetben akkor záródik, ha vége van egy tranzakciónak. Ez lehet egy EJB Session Bean megfelelően annotált metódusából való kilépéskor, vagy akár explicit commit() esetén, tökmindegy. Amikor a PC záródik, akkor a hozzá kapcsolódó perzisztens objektumok minden változása elmentődik. Amíg a PC nyitva van, az "attached" állapotú objektumokkal bármit csinálhatsz merge vagy persist nélkül -> az is mind bele fog íródni az adatbázisba.

Tehát, kódilag:

@TransactionAttribute(REQUIRED)
public void doSomething() {
EntityManager em = ....;

Person user = em.find(Person.class, 1);
user.setName("Kovács Józsi");
}

Ez így, minden merge nélkül szépen átírja az 1-es id-jű user nevét.

Mikor kell merge? Akkor, ha detached állapotú objektumban lévő változásokat akarsz beírni az adatbázisba. Mikor detached egy objektum? Akkor, ha az a PersistenceContext, amitől alapesetben elkérted, már bezárult. Mikor zárodik egy EntityManager? Például minden tranzakció végén (ha nem extended).

@TransactionAttribute(REQUIRED)
public Person doSomething(Person user) {
EntityManager em = ....;
Person saved = em.merge(user)
return saved;
}

Fontos, hogy a JPA api merge metódusa új objektumot ad vissza -> nem az átadott objektumot teszi a PersistenceContext részévé, hanem egy új referenciát kapsz egy már attached állapotú objektumra.

Az a tapasztalatom, hogy a JPA-t nagyon sokan használják úgy, hogy a fentiekkel nincsenek tisztában -> nem látják át, hogy mi is az az EntityManager, mennyiben több, mint egy wrapper a JDBC fölé.

Nem vitatkozni akarok, értem amit mondtok és el is fogadom, hogy így van, de itt nem autogenerated id-kről van szó. Máshol használunk mi is autogenerated id-ket, de itt Objektum szinten már minden (az id-is) ki van töltve csak egymásra hivatkoznak.

class A{
Long id;
String name;
}

class B{
Long id;
Long aID; // A-ra mutató ID, direkt nincs collectionre mappelve
}

Az adatbázisban A és B tábla között foreign key van.

A a = new A(); a.id=123l; a.name = "Elso";

B b = new B(); b.id=1l; b.aId=123l;

em.persist(a);
em.persist(b);
.
.

Amikor a függvénynek vége, adatbázis szinten a foreign key exceptiont dob. Gondolom az a baj, hogy nem olyan sorrendben mennek ki az insertek mint ahogy én azt megadtam. Ehhez persze az enity managernek joga van, csak leírtam, hogy más ne szívjon ezzel ha hasonló eset van.

A glassfish verziója:
Sun GlassFish Enterprise Server v2.1 (9.1.1) (build b60e-fcs)

10-ből 5 ször jó, 5 ször meg nem. Az alkalmazás ear-ban van, abban ejb és war.
Most hirtelen persze nem tudom reprodukálni. Hiba esetén az a jelenség, hogy az ear deployol, az admin felületen ott is vannak a ws-ek, de ha hívni akarja a kliens (java és C++ gsoap) akkor olyan hibát dob, mintha nem is lenne deployolva ilyen web service. Ha utána bárki lekérdezi a wsdl-t, egyből megy a hívás. Ha találkozom vele, küldöm az exceptiont.

Websphere = Web's fear.

Wow. Akkor itt eleg csak a listen portot atirni 80-ra es kesz a GF alapu webserver name-based virtualhostinggal?
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Az az igazan szar, amikor ot-tiz percig keresgetni kell, hogy a kollega eppen hol es miert ott definialta az uj queue-t, es hogy milyen parametereket lehetne meg beallitani. Ha egyertelmu lenne, hogy mit hova kell tenni kotelezoen, akkor nagyjabol okenak ereznem.

(Erdekes amugy, nalunk a JBosson nevelkedett emberek mennyire XML-baratok, bar ez johet onnan is, hogy meg boven pre-EJB3 meg pre-Java5 idokbol szarmaznak. A generics se musthave nekik, ha viszont van, akkor *minden* legyen elarasztva lehetoleg egynel tobb tipusparameterrel. De legalabb jol fizetnek.)

A permgenes hiba majdnem mindenhol elojon, de nem ennyiszer :)

Pont annyi XML van JBoss-ban, mint GF alatt... csak GF esetén egy darab XML, JBoss esetén több kisebb... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD