Lenne egy (egyelőre) teoretikus kérdésem a hozzáértő szakmai közösségnek, amire szívesen látnék szakmailag adekvát válaszokat, ha valaki esetleg tudja és képben van ilyen témakörben.
Az állapot leírása:
Van egy A ear, amiben egyetlen ejb modul van. Van egy ettől független B ear, amiben egyetlen war modul van.
Az ejb modulban egyetlen, csak lokális interfésszel rendelkező stateless session bean van.
A fenti állapot esetén értelmezendő kérdés:
Megoldható-e, hogy a B ear-ban levő war felhasználhassa ezt az A ear-ban levő lokális interfészes EJB-t?
Ha igen, akkor mi lehet ennek a megfelelő módja/technikája, ha nem, akkor miért nem. Akár google hivatkozás formájában, akár kommentben kifejtve.
A fenti állapot értelmezési kontextusa:
Java 1.6, EJB3, annotációk, WebLogic 10.3.2
- 1861 megtekintés
Hozzászólások
ha nem ertettem felre a kerdest, akkor ez pont ez a problema/kerdes. a valasz itt az, hogy csinalj neki remote interfeszt.
- A hozzászóláshoz be kell jelentkezni
Na igen, remote-tal piece of cake és ez most nem csak elméletileg, hanem gyakorlatilag is értem. :)
Van nekem is egy olyan sejtésem, hogy local-lal nem vagy nem egyszerűen megvalósítható, de hátha van valaki, aki tud valami spéci trükköt/tippet vagy valami kifejezetten WebLogic specifikus xml varázslatot, ami fenemód leegyszerűsíti a feladat megoldását.
Elvileg az egy kikötés, hogy local interfész lehet csak. Ami még nem is lenne akkora probléma, ha egy ear-ban üldögélnének. De így, hogy külön ear-ban vannak, így azért már egy fokkal szerintem trükkösebb. A JVM-et mondjuk tekintsük közösnek.
- A hozzászóláshoz be kell jelentkezni
a fenti linken irjak, hogy a weblogic majd kioptimizalja. el tudom kepzelni amilyen galadok, hogy belul lokalis kereskent oldja meg.
- A hozzászóláshoz be kell jelentkezni
Az a WebSphere, nekem meg WebLogic lenne. :)
- A hozzászóláshoz be kell jelentkezni
Csak kivancsisag: miert nem fernek ezek bele egy ear-ba?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Tekintsük a feladat szempontjából egy kiinduló kérésnek.
Azt persze nem állítom, hogy a kiinduló kérés szakmailag alátámasztott, ezért tettem oda, hogy teoretikus. :)
- A hozzászóláshoz be kell jelentkezni
Elolvastam a komplett szalat. Valami problema biztos, hogy van a specifikacioval, mert ket, egymassal ossze nem fero dolgot szeretnel elerni.
Amennyire en latom, vagy egymasba csomagolod a ket ear-t, es akkor lesz local eleresed, vagy kulon csomagolod, es akkor kell remote interfesz. A ketto egyutt nem megy.
Meg ha meg is lehet csinalni, akkor se lennek annak a helyeben, aki ezt hosszu tavon karbantartja, elobb vagy utobb ugyanis mindenkeppen meg kell csinalni rendesen a projektet, meghozza pont akkor, amikor nem varjatok. Az ugyfel donthet ugy, hogy neki a jelenlegi alkalmazasszerver ellenszenves, mert mondjuk a JBoss neveben benne van a "boss" es a cegnek csak o lehet a fonoke, tehat dobjuk ki. Akkor ott alltok megfurodve, hogy lehet a cuccot ujrafejleszteni.
En azt mondom, inkabb verjetek at a specifikacion, hogy feleljen meg a cucc az EE szabvanynak, mint a sajat jovobeni eleteteket nehezitsetek meg. Bar, ha ti nem vadaszni jartok az erdobe.... am legyen.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Nem is állítottam, hogy nincs probléma a speckóval (egyébként én is így gondolnám lásd, de szándékosan nem írtam le nyitáskor, hogy ne befolyásoljak senkit a végeredményt illetően), egyelőre csak a kérésnek megfelelő lehetséges megoldásokat vizsgálom. Ezért is elméleti az egész, egyetlen bitet sem írok le, míg elméletben nem "működőképes".
De megpróbálom matekra fordítani a feladatot. Van egy egyenlet, amit meg kell oldani a valós számok halmazán. Előfordulhat azonban, hogy a valós számok halmazán nincs értelmezhető megoldás, mert mondjuk csak komplex gyökök vannak. Erre nekem annyit kell válaszolni a feladat kiírójának, hogy a valós számok halmazás nincs megoldás. De! Ha bővítené az értelmezési tartományt, akkor eredményre juthatnánk. Majd ő ebből eldönti, hogy mit csinál. Marad a megoldhatatlanságnál a valós számok halmazán (=dobja az fejlesztést) vagy kéri a komplexes megvalósítást (=remote vagy közös ear).
Ez már nem tartozik a szálhoz, de válaszolnék rá:
Az egyik:
cegnek csak o lehet a fonoke, tehat dobjuk ki. Akkor ott alltok megfurodve, hogy lehet a cuccot ujrafejleszteni.
Ezzel semmi gond nincs, nyilván ha speciálisan egyedi igényei vannak, akkor nem kell meglepődni, hogy az nem mozgatható mindenhová szabadon. A módosítási költségeket meg állnia kell valakinek. Ekkor majd megint dönthet úgy, hogy jó neki a JBoss, legyen ő a CIO akkor vagy pedig kifizeti a kért módosításokat.
A másik:
Bar, ha ti nem vadaszni jartok az erdobe.... am legyen.
A megrendelőnek szíve joga eldönteni, hogy mire szeretné költeni a pénzét. Nyilván nekünk annyiban áll a felelősségünk, hogy tájékoztassuk arról, hogy a kért megoldás technológiailag nem megvalósítható és akkor itt javaslunk (szabványos) alternatívákat a megoldásra vagy arról tájékoztatjuk, hogy a megoldás speciálisan egyedi, így nem biztosítható, hogy minden szabványos környezetben működőképes marad. Onnantól pedig az ő felelőssége mérlegelni a kockázatokat.
- A hozzászóláshoz be kell jelentkezni
A megrendelőnek szíve joga eldönteni, hogy mire szeretné költeni a pénzét. Nyilván nekünk annyiban áll a felelősségünk, hogy tájékoztassuk arról, hogy a kért megoldás technológiailag nem megvalósítható és akkor itt javaslunk (szabványos) alternatívákat a megoldásra vagy arról tájékoztatjuk, hogy a megoldás speciálisan egyedi, így nem biztosítható, hogy minden szabványos környezetben működőképes marad. Onnantól pedig az ő felelőssége mérlegelni a kockázatokat.
...és a fekete billentyűk hangosabbak... :)
http://www.themadmusicarchive.com/song_details.aspx?SongID=12957
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Kimaradhattam valamiből, mert ezt most nem fogom, bocs.
- A hozzászóláshoz be kell jelentkezni
Ezek szerint nem ismered a sztorit... :)
Egy Dudley Moore és Peter Cook jelenet, rövidítve szokott előfordulni magyarul:
- Jó napot, szeretnék megtanulni zongorázni!
- Jó napot kívánok! Tanult valaha zongorázni?
- Még nem, de azt már tudom, hogy a fekete billentyűk hangosabbak.
- A fekete billentyűk nem hangosabbak, hanem...
- Nagyon gazdag vagyok, nincs lehetetlen! Jövő héten már szeretnék zongorázni, mennyiért tart egy órát?
- Tízezer forintért, de kérem értse meg, hogy az ön kérését nem lehet...
- Ne akarja megmondani, hogy mi lehetséges! Fizetek magának húszezret óránként.
- A jövő hétig talán menni fog a Boci-boci-tarka...
- Ön nem értett meg engem. Na jó, fizetek ötvenezret óránként.
- Nem lehet megcsinálni! A fekete billentyűk pedig nem...
- Legyen százezer óránként!
- Akkor kezdjük! Mint tudja már, a fekete billentyűk hangosabbak...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Ha ugyanabba a jvmbe futnak, akkor lokálisan elérheted a B-ből A beanjeit, a feltétel csak annyi, hogy az A lokális interfészei a B classpathján legyenek. Remote hívásra különbözű jvmek esetén van szükség.
- A hozzászóláshoz be kell jelentkezni
az A lokális interfészei a B classpathján legyenek
Tehát akkor mondjuk bemásolom az A earban levő ejb lokális interfészeit a B earban levő war WEB-INF classes könyvtárába?
De utána hogy megy a lookup?
- A hozzászóláshoz be kell jelentkezni
Servletben @EJB segítségével függőséginyektálással szerzel referenciát, egyébként meg jndi lookuppal, de az EE6 előtt appszerverenként eltérő :(
- A hozzászóláshoz be kell jelentkezni
Attól félek, hogy valószínüleg nem fog menni, bár én nem vagyok weblogic szakértő, csak Jboss és Websphere, de elméletileg a J2EE szabvány szerint az EAR-ok, külön classloadeben futnak egymástól elszeparáltan, mivel külön classloaderben futnak ugyanaz a class nem egyezik meg a két EAR-ban, mivel más classloader töltötte be, tehát nagy valószínűséggel classcastexceptiont fog kapni híváskor. Ezért van az hogy remote kell hívni, mert a serializáció áthidalja a classloader problémát, az appserverek a hálózati kommunikációt ilyenkor kioptmalizálják. A JBossban ez nem probléma, mert ott egy classloader(RepositoryClassloader) töli be az osztályokat.
- A hozzászóláshoz be kell jelentkezni
Megoldás lehet, hogy az intefészeket külön jar-ba teszed, ami mindkét projekt classpathján van rajta, Jboss alatt tuti működik, Weblogiccal nincs tapasztalatom :(
- A hozzászóláshoz be kell jelentkezni
Jboss alatt ez nem problema a kozos classloader miatt, Weblogicnal csak valami EAR-nal magasabb szintu classloader lehetne jo, de szerintem az mar nagy ganyolas, egy egyszeru dologra.
- A hozzászóláshoz be kell jelentkezni
Az ilyen gányolás alapvetően nem-et jelent nálam a megvalósíthatóságra az adott feltételek mellett, főleg ha a remote gánymentes megoldás, amihez a kiindulási feltételt kell vagy úgy átszabni, hogy remote használható és akkor maradhatnak külön ear-ban vagy úgy, hogy az ejb összeköltözik a war-ral egy ear-ba és akkor használható a local.
- A hozzászóláshoz be kell jelentkezni
Alkalmazás szervertől is függ, illetve classloader beállításoktól is erősen függ, szóval ki kell próbálni.
Nem ismerem a WebLogic működését, de például egy alap JBoss esetén gond nélkül megy war-ból egy EJB hívása local interfészen át, de ha az EAR-ban beállításra kerül az egyedi classloader, akkor nem fog menni.
A hívás az injection mellőzésével tud történni, a klasszikus módon:
InitialContext ic = new InitialContext();
LocalEJBInterface ejb = (LocalEJBInterface) ic.lookup("ejbneve");
Feltéve, hogy megy... mert vannak alkalmazásszerverek, amelyek nem teszik fel a JNDI-re a Local interfészeket. Szóval ki kell próbálni. :)
Alternatív megoldás lehet az interfész helyett az EJB egyidejű Local és Remote felannotálása, az alábbi példa JBoss 5.1 esetén biztos működik:
@Local(value = hu.javaforum.services.bf.AdClickServiceBFLocal.class)
@Remote(value = hu.javaforum.services.bf.AdClickServiceBFRemote.class)
@Stateless(mappedName = "hu.javaforum.services.bf.AdClickServiceBFRemote")
@LocalBinding(jndiBinding = "hu.javaforum.services.bf.AdClickServiceBFLocal")
@RemoteBinding(jndiBinding = "hu.javaforum.services.bf.AdClickServiceBFRemote")
public class AdClickServiceBF implements AdClickServiceBFRemote, AdClickServiceBFLocal
Szóval a lehetőségek tárháza igen bő... csak ki kell próbálni... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
mert vannak alkalmazásszerverek, amelyek nem teszik fel a JNDI-re a Local interfészeket
Legjobb tudomásom szerint a WebLogic pont ilyen.
Ha jól sejtem, akkor ez a @LocalBinding annotáció JBoss specifikus.
A remote annotálás egyelőre kizártként kezelendő. Ezek a peremfeltételek. Később persze kiderülhet, hogy alapvetően rosszul lettek megállapítva és ilyen feltételek mellett nincs megfelelő megoldás. :)
A tárház lehet, hogy bő, de ha leszűkítem azzal a megkötéssel, hogy ha specifikusság, akkor az csak és kizárólag WebLogic lehet, akkor máris töredékére esik vissza.
- A hozzászóláshoz be kell jelentkezni
Legjobb tudomásom szerint a WebLogic pont ilyen.
Akkor itt bukott a dolog. :)
Ha jól sejtem, akkor ez a @LocalBinding annotáció JBoss specifikus.
Igen, s azért kell, mert a JBoss nem használja fel a Stateless annotáció "mappedName" paraméterét, ha nem adom meg a LocalBinding annotációval, akkor a projektnév/ejbnév/local néven teszi rá a JNDI-ra, és akkor nem tudom egyszerű és automatikus módon elérni:
EJBLocal ejb = (EJBLocal) ic.lookup(EJBLocal.getClass().getName());
A remote annotálás egyelőre kizártként kezelendő. Ezek a peremfeltételek. Később persze kiderülhet, hogy alapvetően rosszul lettek megállapítva és ilyen feltételek mellett nincs megfelelő megoldás. :)
Szerintem nem fog menni, szóval nem lesz megoldás. :(
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Akkor itt bukott a dolog. :)
Ettől függetlenül nem kizárt, hogy azért valamilyen módon elérhető.
Volt is egy tipp feljebb, hogy hogyan lehetne, de ott még merültek fel kérdések bennem, de mondhatnám úgy is, hogy az ötlettel még nem állt bennem össze a kép, sőt, csak még több kérdésem lett.
Igen, s azért kell, mert a JBoss nem használja
Az okés, de nem hiszem, hogy használhatok JBoss specifikus annotációt WebLogic alatt. :)
Szerintem nem fog menni, szóval nem lesz megoldás. :(
Én ezt a "megoldást" sem zártam ki egyáltalán, csak utolsó utáninak tartogatom, de persze addig is kíváncsi vagyok a közösség véleményére és tapasztalatára.
- A hozzászóláshoz be kell jelentkezni
Csak erdeklodes szintjen miert felsz a remote interface-tol? Ez a legegyszerubb szabvanyos megoldas, a tobbi csak ganyolas.
- A hozzászóláshoz be kell jelentkezni
Én nem félek egyáltalán. Jelenleg elvárás. Természetesen ha nem megoldható, akkor majd változik az elvárás, de nem én szabtam a kiindulási feltételeket.
- A hozzászóláshoz be kell jelentkezni