Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?

[es] :: Java :: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?

Strane: 1 2

[ Pregleda: 6914 | Odgovora: 26 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

zmau
Dragan Jovanović
programer
Šabac

Član broj: 80834
Poruke: 290
212.200.123.*



+80 Profil

icon Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?29.01.2007. u 01:49 - pre 208 meseci
Odnosno, ima li on u momentu dok se izvršava neka njegova metoda ikakvu informaciju o klijentu koji je okinuo tu metodu, a da mu ona nije eksplicitno prosleđena kao argument ?
Često (praktično uvek) mi treba ta informacija (IP adresa radne stanice, ali i id usera ulogovanog u aplikaciju) unutar serverskih metoda a nimalo me ne veseli ideja da treba da dodajem još jedan argument (čini mi se bukvalno) svakoj metodi na app serveru.
Server je JBoss, a binovi su ejb3
it works on my machine
 
Odgovor na temu

dusanmiloradovic
Dusan Miloradovic
Abu Dabi

Član broj: 38080
Poruke: 45
*.emirates.net.ae.



Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?29.01.2007. u 07:29 - pre 208 meseci
Pogledaj interface EJBContext. Tu imas metodu getCallerPrincipal koja ti identifikuje ko je pozvao komponentu.
Da bi pristupio tom kontekstu, moras da koristis metod setSessionContext iz session beana. U tom metodu dodeli nekoj promenljivoj vrednost : npr
public void setSessionContext(SessionContext context) {
this.context = context;
}

u varijabli context ces imati EJBContext, pa zovi onda getCallerPrincipal

Dusan
 
Odgovor na temu

hyle
Perica Milošević
Belgrade

Član broj: 30030
Poruke: 150
*.ADSL.neobee.net.

Sajt: www.linkedin.com/in/peric..


+4 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?29.01.2007. u 20:30 - pre 208 meseci
Nemoj da dodaješ nove parametre u metode, to bi bio totalno pogrešan pristup. Mnogo bolji pristup je neka vrsta Dependency Injection-a. Pogledaj ovaj Fowlerov članak: Inversion of Control Containers and the Dependency Injection pattern, a nije loš ni članak Igora Spasića na srpskom jeziku na JavaSvetu: Inversion of Control (IoC).

Za JBoss je prirodno da iskoristiš kontekst koji bi bio popunjen svim informacijama potrebnim u trenutku izvršenja željene metode session bean-a.
Nisam ti dao konkretan odgovor ali se nadam da sam ti barem pomogao da kreneš u pravom smeru za rešavanje problema.
 
Odgovor na temu

zmau
Dragan Jovanović
programer
Šabac

Član broj: 80834
Poruke: 290
212.200.123.*



+80 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 02:37 - pre 208 meseci
@Dušan
Hvala na tragu. Čačkao sam dalje, ali ne uspevam da dobijem taj Principal objekat, nego metoda generiše IllegalStateException. Našao sam neke primere, i u svakom od njih jednostavno pozovu metodu i to šljaka, i ne pominju neke preduslove koje treba ispuniti a moj primer ih očigledno ne ispunjava. Pokušao sam i sa onim navodno jednostavnijim ann-om @EJB, ali onda mi pukne deploy, ne stignem ni da pokrenem metodu.
Najpametnije što sam iskopao o metodi getCallerPrincipal je ovo
<code> The Container throws the exception if the instance is not allowed to call this method. </code> :-(. Dalje ne kapiram ništa.

@Perica
Uf, Peco, pravo da ti kažem, ne vidim prostor za primenu holivudskog principa u ovom prozaičnom kontekstu. Ja zamišljam da nađem gotov snipet koji će mi vratiti jedan jednostavan podatak i nemam ideju gde tu ima lufta za viši koncept kao što je raspodela odgovornosti među klasama. Mada, kad rešim ovaj poziv metode pa pređem na šire rešavanje problema, možda mi se kaže samo.
it works on my machine
 
Odgovor na temu

hyle
Perica Milošević
Belgrade

Član broj: 30030
Poruke: 150
82.117.206.*

Sajt: www.linkedin.com/in/peric..


+4 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 09:58 - pre 208 meseci
Da ne filozofiramo mnogo...

Reci mi sledeće, odakle si mislio da šalješ te parametre (IP adresa radne stanice, id usera ulogovanog u aplikaciju)?
1) Klijenti direktno zovu metode session bean-ova pa si mislio da te informacije šalješ sa klijenta
2) Sve prolazi prvo kroz neku serversku metodu koja čuva te informacije o klijentima i ta metoda delegira pozive na odgovarajuće bean-ove?
3) Nešto treće

Bitno je ko poseduje potrebne informacije da bi znao koji je pravi način da te informacije stignu do session bean-ova. Ako si mislio da te informacije dobijaš od klijenta onda ti je sa stanovišta sigurnosti to rešenje jako loše.
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.antegra.com.



+13 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 13:19 - pre 208 meseci
Moram da priznam da ni meni nije jasno sta je Perica hteo da kaze sa IOC-om i ostalim stvarima, mislim sve je to lepo, ali cini mi se da covek nije to pitao..

Nisam znao za ovo sa getCallerPrincipal, ali ako to moze to je super. Ako direktno iz klijenta (web app, na primer), pozivas EJB, onda bi verovatno radio pomenuti getCallerPrincipal tj. dobio bi prave info. Ukoliko imas prvo kontakt sa nekim drugim EJBom onda bi on pomocu getCallerPrincipal mogao da iscupa podatke, ali bi onda verovatno morao da ih prosledi kao argument tom drugom EJBu, pa opet nisi dobio ono sto si hteo, a mozda i jesi ako ti je cilj bio da klijent ne brine o tome, odnosno ako neces da zavisis od klijenta.

Btw, dependency injection (@EJB) meni sasvim fino radi (na OC4J), ali ne znam zasto to koristis, zar tebi ne treba SessionContext?

Btw, ajde daj malo vise podataka o arhitekturi i baci koje parce koda i deskriptora, da ne nabadamo..
 
Odgovor na temu

hyle
Perica Milošević
Belgrade

Član broj: 30030
Poruke: 150
82.117.206.*

Sajt: www.linkedin.com/in/peric..


+4 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 14:03 - pre 208 meseci
Ma filozofiram mnogo, čovek pita konkretno a ja ke*am nešto...

Poenta je bila da takve stvari ne treba slati kroz parametre metoda već te informacije moraju biti negde spremne (injectovane) i da stoje na raspolaganje session bean-ovima. To je koliko znam neka vrsta dependency injectiona...

Kada bude poslao neko parče koda dobiće sigurno i upotrebljive odgovore.
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
*.antegra.com.



+13 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 15:08 - pre 208 meseci
Hm, pa posle logina na web aplikaciju se verovatno negde cuvaju informacije o useru, neki backing bean ili nesto slicno.

E sad, nije mi poznato da middleware moze da ide ka prezentacionom sloju, pa ne vidim nacin da middleware zna nesto o tome ako mu se ne prosledi, hm..
 
Odgovor na temu

zmau
Dragan Jovanović
programer
Šabac

Član broj: 80834
Poruke: 290
212.200.123.*



+80 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 16:43 - pre 208 meseci
Nisam vas smarao kodom zato što se nadam da nema potrebe jer sam na tragu generalnog rešenja.
Juče sam našao knjigu masteringEJB3 i tamo našao sledeću priču :
Citat:

The other programmatic security method, getCallerPrincipal(), retrieves the current caller’s security principal. You can use that principal for
many purposes, such as retrieving the caller’s distinguished name from it to use this name in a database query. This might be handy if you’re storing your security information in a database. Here is sample code that uses getCallerPrincipal():

import java.security.Principal;

...
@Stateless
public class EmployeeManagementBean {

@EJB private SessionContext ctx; /* @Vanja Evo odakle @EJB! Slabo kapiram ove anotacije pa koristim tehniku nabadanja na osnovu primera. */
...
public void modifyEmployee() {
Principal id = ctx.getCallerPrincipal();
String name = id.getName();
// Query a database based on the name
// to determine if the user is authorized
}
}


I to je tačno ono što meni treba i deluje strašno jednostavno. Samo što kod mene ne radi. A probao sam i da sessionContext anotiram kao @Resource.
Mislim da se moj problem svodi upravo na teranje ovoga da proradi.



A ako ste raspoloženi da posmatramo problem u kontekstu mog projekta, ja sam naravno za.
Evo ovako.
Klijent je debela šarena swing aplikacija. Na JBossu je nekoliko session bean-ova, ali i nekoliko statičkih metoda. Poenta mi je ustvari u tim statičkim metodama (njih naravno koriste binovi) koje beleže u log tabelu u bazi šta se zanimljivo događa u programu. Recimo, svaku poruku o grešci (otprilike isto ono što i jboss beleži u svom logu). Ali i svaki insert/update/delete nad bazom i još po nešto. Uz svaku od tih poruka pamtim između ostalog id ulogovanog usera i id radne stanice sa koje je pokrenuta akcija (to je u principu ip adresa). Te statičke metode opet interno koriste klasu koja okida upite nad bazom i koju sam implementirao kao session bean.

Jedan uobičajen scenario je ovakav : klijentski objekat instancira session bean, napuni ga podacima i okine njegovu metodu koja piše u bazu (prva metoda u primeru kooda). Ta metoda generiše sql skript, instancira session bean koji ume da razgovara s bazom (zovem ga DatabaseBean) i prosledi mu skript. Ovaj objekat onda okine skript (recimo neki update) nad bazom, a zatim pozove statičku metodu koja treba da upiše 1 zapis u log tabelu u bazi. Ta statička metoda opet interno instancira jedan DatabaseBean (što i nije bitno za ovu priču), izgeneriše skript (za detalje vidi sors) i insertuje ga u tu log tabelu. E, među kolonama log tabele je i kolona userId u koju ja hoću da upišem koji korisnik je okinuo celu akciju. Evo kooda :
Code:

// Klasa RecordBrokerBean, predstavlja generički domenski objekat i implementirana je kao session bean.
    public void update() throws IdNotFoundException, SQLException {
        String script = updateScr();
        if (script != null) 
            try {
                baza.execSQL(script); // baza je tipa DatabaseBean, a telo metode je ispod
            }
            catch (SQLException e) {
                UtilSrv.printErr("neuspeo update (" + tableName + ")", e);
            }
        else throw new IdNotFoundException();
    }

// Klasa DatabaseBean, wrapper oko Connection interfacea
    public int execSQL(String command) throws SQLException {
        int ret = 0;
        try {
            con = dsMedi.getConnection();
            Statement s = con.createStatement();
            
            long t0 = System.currentTimeMillis(); 
            ret = s.executeUpdate(command);
            long t1 = System.currentTimeMillis();
            UtilSrv.printInfo(command, t1-t0); // metoda koja piše u log da je okinut upit, telo je ispod
        } catch (SQLException e) {
            throw e;
        } finally {
            vratiConn();
        }
        return ret;
    }
    
// Klasa UtilSrv - zbirka statičkih metoda opšte namene. Diplojuje se na server kao obična klasa (nema nijednu ejb anotaciju).
    public static void printInfo(String poruka, long trajanje){
        try {
            DatabaseBean db = new DatabaseBean();
            String stanica = getProp("radna stanica"); // ************
            String user = getProp("user");     // *************
            String logScript = String.format(
                    "insert into log (vreme, stanica, userId, tip, poruka, trajanje) \n values(now(), \"%s\", \"%s\", 'i', \"%s\", %d)", 
                    stanica, user, poruka.replace("\"", "\\\""), trajanje);
            db.execSQLINePisiULog(logScript);
        }
        catch (SQLException e) {
            printErrToFile("neuspeo upis skripta '" + poruka + "' u log u bazi : " + e);
        }
    }

Za sada držim informacije o useru i radnoj stanici u statičkoj Properties mapi na serveru (čita ih metoda getProp), što je naravno besmisleno za više od jednog korisnika i to upravo pokušavam da odradim kako valja.

Dakle, idealno bi bilo da na serveru imam statičku promenljivu u kojoj piše userId i da mogu da joj pristupim kad god hoću. Naravno ne mora to da bude bukvalno id polje iz moje tabele user, konverziju je bar lako odraditi.

Lošije, ali i dalje zadovoljavajuće rešenje je da session bean čije je metoda (u ovom primeru RecordBrokerBean) direktno pozvana sazna ko ga je pozvao, pa da tu informaciju prosledi gde treba.


it works on my machine
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
212.200.221.*



+13 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 20:13 - pre 208 meseci
E vidis - to u knjizi je ocigledno greska, treba ovako:

Code:

@Resource SessionContext ctx;


Rekao si da si vec tako probao, ali ajde probaj jos jednom i ako ne uspe javi tacno koju gresku dobijas, pa da vidimo da li je null pointer exception (to bi znacilo da nije uspelo inDZektovanje) ili je nesto drugo.

Dakle, @Resource anotacija sluzi da ubrizgas druge resurse, kao sto je na primer ovaj ctx ili recimo TimerService ili nesto slicno.

@EJB anotacija ti sluzi da dobijes referencu na drugi EJB, da ne moras da radis JNDI lookup-e.

I jedna preporuka - ulozi vreme u citanje knjiga koliko god da si u frci sa deadlineom - isplatice se na kraju, to ti kazem iz licnog iskustva ;)

Ajde dok ja citam ostatak tvoje poruke, ti probaj ovo pa nam javni..

V
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
212.200.221.*



+13 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 20:19 - pre 208 meseci
Evo, probaj na primer ovo:

Code:

@Stateless(name="SessionEJB")
public class SessionEJBBean implements SessionEJB, SessionEJBLocal {
    
    @Resource SessionContext ctx;
    
    public SessionEJBBean() {}
    
    public String radi() {
        return ctx.getCallerPrincipal().getName();
    }
    
}


I evo ti klijent:

Code:

public class SessionEJBClient {
    public static void main(String [] args) {
        try {
            final Context context = getInitialContext();
            SessionEJB sessionEJB = (SessionEJB)context.lookup("SessionEJB");
            System.out.println( sessionEJB.radi(  ) );
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

    private static Context getInitialContext() throws NamingException {
        return new InitialContext();
    }
}
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
212.200.221.*



+13 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 20:33 - pre 208 meseci
Uf uf uf, vidi, ovo ti je opaka greska:

Code:

DatabaseBean db = new DatabaseBean();


Upamti, SessionBean-ove NE INSTANCIRAS TI!!! Oko svega toga i jeste ova prica - ti radis samo sa biznis interfejsima, nemas pojma sta je iza! I sto je najlepse, klijentu je na taj nacin potreban samo tanki interfejs, a ne ceo kod bean-a. Zato se i koristi injekcija!

O tome brine kontejner! Ukoliko ti treba referenca na neki EJB iz nekog EJB-a, onda to radis ovako:

Na primer BeanA kome treba BeanB
Code:

@EJB
BeanB bb;


, gde je BeanB biznis interfejs, a ne sama implementacija bean-a!

Ako neces ovako, imas i drugi, stariji, nacin preko JNDI, a njega mozes da koristis odakle god oces, znaci i iz ejb-a i iz web aplikacije i iz swinga, odakle oces:

Code:

BeanB = (BeanB)context.lookup("BeanB");


Nesto slicno si video u kodu koji sam ti dao u prethodnoj poruci.

Znaci, da ponovimo - kontejner je taj koji vodi brigu o broju instanci u pool-u i tako tim stvarima.

Kontejner je tu za tebe da ga iskoristis tj. da iskoristis tzv. middleware services. Prouci malo kontejner sa kojim radis.

Btw, izlistaj knjigu Mastering EJB 3.0 od Wiley, verujem da ce ti se otvoriti oci posle toga ;)

V

[Ovu poruku je menjao Vanja Petreski dana 30.01.2007. u 21:44 GMT+1]

[Ovu poruku je menjao Vanja Petreski dana 30.01.2007. u 21:45 GMT+1]
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
212.200.221.*



+13 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 20:38 - pre 208 meseci
Btw, kolko sam na brzinu video, mislim da ce dependency injection moci da se koristi i iz prezenentacionog sloja pocevsi od servleta 2.5.

Na zalost, ja trenutno radim sa 2.4 pa ne mogu da prenesem ta iskustva, ali to je svakako cool.

I jos nesto, da probam da ti jos malo zakomplikujem zivot :D Naime, kad si vec usao u pricu sa EJB 3.0, zasto ne das sansu JPA, umesto da se zezas sa JDBC-om ;) Na taj nacin ces nauciti nesto novo (veoma popularno), a i kod ce ti biti portabilan (sutra mozda pozelis da promenis DB sloj)

[Ovu poruku je menjao Vanja Petreski dana 30.01.2007. u 21:53 GMT+1]

[Ovu poruku je menjao Vanja Petreski dana 30.01.2007. u 21:54 GMT+1]
 
Odgovor na temu

zmau
Dragan Jovanović
programer
Šabac

Član broj: 80834
Poruke: 290
212.200.123.*



+80 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 21:27 - pre 208 meseci
Evo probao sam opet sa ovim tvojim sorsom. (Doduše uz malu izmenu, nije mi šljakalo sa aliasom name="SessionEJB", pa sam lukapovao string "SessionEJBBean/remote", al pretpostavljam da to nema veze sa ovom pričom.)
Elem, ponovo dobijam java.lang.IllegalStateException. Evo stack trace-a iz klijentske konzole :

javax.ejb.EJBException: java.lang.IllegalStateException
at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69)
... (ovo dalje nas pretpostavljam ne zanima)
...
Caused by: java.lang.IllegalStateException
at org.jboss.ejb3.BaseSessionContext.getCallerPrincipal(BaseSessionContext.java:168)
at com.tagws.core.dbbroker.SessionEJBBean.radi(SessionEJBBean.java:15)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:109)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:192)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:219)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:107)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:660)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:513)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:290)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:344)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:202)
at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:183)
at org.jboss.remoting.Client.invoke(Client.java:444)
at org.jboss.remoting.Client.invoke(Client.java:407)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:41)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:88)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:88)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:40)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:88)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:88)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
at $Proxy0.radi(Unknown Source)
at GenTester.main(GenTester.java:14)

DetailMessage tog exceptiona je null :-(.
Kao što rekoh juče, o metodi getCallerPrincipal sam iskopao samo da The Container throws the exception if the instance is not allowed to call this method.

Operator new koristim unutar servera zato što nemam potrebu za lookupom, a verujem da je ovako brže. Tu @EJB anotaciju sam prvi put video juče i možda ću je i koristiti umesto new. A i dalje ne kapiram da je greška konstruisati ejb kao da je običan pojo kad ga koristiš u lokalu (unutar servera). Al to je već neka druga priča.

it works on my machine
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
212.200.221.*



+13 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 21:55 - pre 208 meseci
Ok, ja sam ti rekao, a ti vidi da li ces da radis kako treba ili ne :)

Samo jedno glupo pitanje, da li si "expose-ovao" metodu u local/remote interfejsima?
 
Odgovor na temu

zmau
Dragan Jovanović
programer
Šabac

Član broj: 80834
Poruke: 290
212.200.123.*



+80 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 22:38 - pre 208 meseci
Koju metodu ?
Za svaki session bean imam po remote interface i preko tih interfejsa im pristupaju klijentski objekti. A lokalne interfejse nisam pravio, nego serverski objekti pristupaju jedan drugom ovako kako si video, znači kao da nisu binovi. Stvarno, je l se ispostavi u nekoj situaciji da takvo rešenje ne valja zbog nečeg konkretnog ?
it works on my machine
 
Odgovor na temu

anon315

Član broj: 315
Poruke: 1657
212.200.221.*



+13 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 22:52 - pre 208 meseci
Pa metodu radi. Ali ocigledno jesi, po tome sta pricas.

Ajmo ovako, evo ti remote i local interfejsi (redom), za gornji primer koji sam ti dao i koji verovao ili ne kod mene radi:

Code:

@Remote
public interface SessionEJB {
    String radi();
}


Code:

@Local
public interface SessionEJBLocal {
    String radi();
}


Inace, nema potrebe da koristis remote interfejse ukoliko se ejb modulima pristupa sa iste masine, jer na taj nacin degradiras performanse. Ako imas remote IIOP pozive onda koristi remote interfejse. Mozes i oba za slucaj da imas obe vrsta poziva (bas onako kako sam ti napisao).

Pa, postoji nesto sto se zove zivotni ciklus bean-a i nesto sto se zovu callback metode i postoje razno-razna podesavanja beana preko anotacija ili deskriptora. I o svemu tome brine kontejner. I sad ti hoces sve to da preskocis. E pa onda ti ne bi ni trebao kontejner :))) Iscitaj malo o tome da ti ja sad ne bi prepricavao pricu i pravio se pametan.
 
Odgovor na temu

zmau
Dragan Jovanović
programer
Šabac

Član broj: 80834
Poruke: 290
212.200.123.*



+80 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?30.01.2007. u 23:48 - pre 208 meseci
Citat:
Pa metodu radi.

A. Nisam ukapirao da si se vratio na temu o exceptionu :-).

Naravno da jesam. Remote interface mi izgleda isto kao kod tebe. Lokalni sam u startu napravio prazan, sad sam i u njega stavio metodu radi, ali rezultat je naravno isti.

Nego, nešto razmišljam, ne znam kakva je moja jboss konfiguracija. Davno sam ga instalirao, ali verujem da nije full. Možda mi fali neki servis koji je potreban u ovoj situaciji . Videću da noćas reinstaliram jboss.
it works on my machine
 
Odgovor na temu

dusanmiloradovic
Dusan Miloradovic
Abu Dabi

Član broj: 38080
Poruke: 45
*.emirates.net.ae.



Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?31.01.2007. u 08:45 - pre 208 meseci
Pozdrav,
nisam shvatio da je u pitanju Swing aplikacija, zato i ne radi. Kako se ti uopste identifikujes kao korisnik?

Da je u pitanju standardna J2EE autentifikacija, posle autentifikacije bi ti se napravio kontekst koji bi se cuvao u kontejneru,
i kad god bi se iz servlet sloja obratio EJB sloju, kotejner bi te automatski prepoznao i dodelio ti kontekst, koji bi mogao
da procitas na nacin koji sam ti poslao.
Posto ti ne pravis standardnu aplikaciju, moraces nekako da izvrsis autentifikaciju na JBoss. Ovo je specificno za svaki EJB container, moraces da proucis dokumentaciju za JBoss, puno srece sa tim , nije bas najrazumljivija.
Evo linka pa citaj:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ClientLoginModule

Dusan
 
Odgovor na temu

hyle
Perica Milošević
Belgrade

Član broj: 30030
Poruke: 150
82.117.206.*

Sajt: www.linkedin.com/in/peric..


+4 Profil

icon Re: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?31.01.2007. u 10:43 - pre 208 meseci
Pogledaj prvo neku knjigu za EJB3, prođi neki tutorial u kome ćeš pozivati session bean-ove remote i lokalno. Pogledaj malo kako se radi sa entity bean-ovima jer u ovom primeru koji si naveo nisi koristio praktično ništa od JBoss servisa. Ovako ti niko ne može reći da li ti nešto ne radi zbog toga što "manuelno" instanciraš bean-ove ili zbog toga što fali nešto u konfiguraciji.

Što se konkretnog problema tiče, nejasno mi je na koji način regulišeš prava pristupa serveru? Šta se dešava prilikom pokretanja klijentske aplikacije, pretpostavljam da prikažeš neki login dijalog ali ne znam šta uradiš sa tim informacijama koje korisnik ukuca i na koji način proveravaš da li on ima pravo da izvršava neke metode session beanova?
JBoss ti omogućava da definišeš prava pristupa pojedinim metodama sistemom user-role. Korisnici imaju Role u sistemu, Role imaju prava da izvršavaju pojedine akcije u sistemu. Mislim da ti upotreba getCallerPrincipal() ne radi zbog toga što nisi ispravno konfigurisao security tako da ta informacija nije ni prisutna u kontekstu kada poziv dođe do session bean-a. Ne znam kako bi uradio konfiguraciju korišćenjem anotacija, ukoliko je konfiguracija u xml obliku onda se u ejb-jar.xml dodaje nešto ovako:
Code:

<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC
   "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN"
   "http://java.sun.com/dtd/ejb-jar_2_0.dtd">

<ejb-jar>
   <display-name>Naziv aplikacije</display-name>
   <enterprise-beans>

      <session>
         <display-name>Neki session bean</display-name>
         <ejb-name>Proba</ejb-name>
         <home>org.elitesecurity.interface.ProbaHome</home>
         <remote>org.elitesecurity.interface.Proba</remote>
         <ejb-class>org.elitesecurity.implementation.ProbaBean</ejb-class>
         <session-type>Stateful</session-type>
         <transaction-type>Container</transaction-type>
         <!-- Dalja konfiguracija session beana -->
      </session>

      <!--
       Ovde konfigurišeš ostale beanove (session, entity, message driven)         
      <session>
      </session>

      <entity>
      </entity>

      <message-driven>
      </message-driven>
      -->

   </enterprise-beans>

   <assembly-descriptor>
      <security-role>
         <description>Korisnik koji ima pravo da koristi moj session bean</description>
         <role-name>AutorizovaniKorisnik</role-name>
      </security-role>

      <method-permission>
         <role-name>AutorizovaniKorisnik</role-name>
         <method>
            <ejb-name>Proba</ejb-name>
            <method-name>*</method-name>
         </method>
      </method-permission>

      <container-transaction>
         <method>
            <ejb-name>Proba</ejb-name>
            <method-name>*</method-name>
         </method>
         <trans-attribute>Required</trans-attribute>
      </container-transaction>
   </assembly-descriptor>

</ejb-jar> 


Pored ovoga na serverskoj strani moraš konfigurisati na koji način server pronalazi spisak svih korisnika i njima dodeljenih rola. Tu ti na raspolaganju stoje razne metode. Na primer ukoliko na serveru u fajlovima user.properties i roles.properties navedeš sve korisnike i njihove role onda ćeš koristiti UsersRolesLoginModule. Ako ti se korisnici i role nalaze u bazi onda ćeš koristiti DatabaseServerLoginModule. Istu stvar možeš rešiti i korišćenjem ldap-a (to sigurno nećeš ) ali bi onda koristio LdapLoginModule.

Da bi ti sve to radilo onda mora i klijent da se ispravno predstavi serveru. Tu se koristi LoginContext. Morao bi da implemetiraš CallbackHandler koji bi sadržao username i password koje je korisnik ukucao. Taj callback handler bi ubacio u LoginContext i pozvao login(). Kasnije normalno pozivaš metode session bean-ova a u login kontekstu se nalaze potrebne informacije.


Nevezano za security, postoji jedna lepa stvar u JBoss koja se zove Interceptor. Implementacija JBoss-a je bazirana na AOP-u i tim Interceptorima, a dobra stvar je što možeš da definišeš i svoje custom Interceptore koji su u stanju da "presretnu" bilo koju akciju na serveru i odrade neki svoj deo koda. Upravo to bi mogao da iskoristiš da se automatski radi insert u onu tvoju tabelu Log. Bez problema bi mogao da izvedeš da se bilo koji poziv metode session bean (ili neki rad sa entity bean-om) automatski beleži u tabeli Log.
 
Odgovor na temu

[es] :: Java :: Da li postoji mogućnost da ejb objekat bude svestan klijenta koji ga je pozvao ?

Strane: 1 2

[ Pregleda: 6914 | Odgovora: 26 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.