Async message – Java – Fórum – Programujte.com

prijimam spravu v async threade a potrebujem aby klient mohol do tohto threadu poslat metodu z jeho class ktora bude volana po prijati spravy ... aktualne to mam cez interface a po prijati spravy sa vykona metoda z interface ale potrebujem aby klient mohol pouzit vlastne (aktualne) premenne ... napada ma len nejaka factory metoda ktora bude vracat static premenne ... da sa to nejak krajsie zabalit pre klienta?

Z tvého popisu netuším o čem mluvíš? Mluvíš o EE JMS neboť tam je synchronní a asynchroní zpracování zprá.? Flowy, všiml jsem si toho párkrát, zadáš si tu zadání, na které ti nikdo neodpoví neboť jej podle mě nikdo nechápe, ty si jej nakonec sám vyřešíš a opět jej ústně popíšeš. Z tvého zadání nelze pochopit koncept řešení, je to příliš málo informací.

PS. jako kdyby tu byl problém zvěřejnit ořezané klíčové části zdrojáku. S takovým to zadání ti nelze pomoci.

kod si napisat viem ... rozmyslam nad principom ako to bude fungovat ... v zasade je jedno v akom prostredi vymyslis riesenie pretoze mi staci sposob ako to bude fungovat

na jednej strane mam kniznicu ktora asynchronne zachytava spravy ... ked spravu zachyti tak by mala o tom dat vediet samotnemu programu ... otazka je ako to spravit aby ten program mohol passnut do kniznice nejaku vlastnu metodu (dalo by sa spravit cez lambda alebo len interfacom) ale tak aby tato metoda mala vzdy pristup k zdrojom v programe ... myslim ze jpa to riesi tak ze ma singletona nejaku factory ktora poskytuje vzdy aktualnu session ale taketo riesenie sa mi zda moc narocne na program ... radsej by som nieco viac zabalene do kniznice

~~ ked spravu zachyti tak by mala o tom dat vediet samotnemu programu

Ale to právě nejde. Pokud chápu správně EJB,RMI apod.. pak vždycky iniciativa vznika z dotazu klienta. Ze strany serveru nelze dát vědět že se něco stalo. ( lze to řešit nekonečným cyklem s opakujícím se dotazem na klientovy)

V tomto případě spíž klient(např. desktop v síti) by měl být koncepčně navržen tak, jako pouze klient v samostatném vláknu měl mít spuštěné asynchronní připojení(např. přes JMS) přihlašující se na aplikační server  a pokud na serveru vznikne zpráva pak vlákno na klientu to okamžitě zjistí protože je stále spuštěné a zaregistrované na tom serveru a provede to co na klientovy potřebuješ.

Těd je otázka jestli si rozumíme a chápeme se.   Fakt nevím jaké zprávy(např. objekt Message z JMS) máš na mysli, jakou technologii ta knižnice využívá atd..

#4 NotBeginner
pripajam sa na irc a mam spraveny thread ktory ma loop cakajuci na spravu ... chcem tam dat pattern listenera ale potrebujem aby ten listener dokazal pracovat aj s vlastnym kontextom

Konečně to z tebe trochu vypadlo. Jde o to že dané řešení pokud by se nejednalo o irc existuje v EE jako Java Message Server ( JMS), proto jsem o tom stále mluvil. Tam je to celé vyřešené a člověk pracuje s objektem typu :

http://docs.oracle.com/javaee/6/api/javax/jms/Message.html

Taktéž když mluvíš o kontextu, radši mluv o obsahu protože objekt Context k načteni JNDI existuje taky a taky se používá u JMS, pokud nevyužívám DI.

http://docs.oracle.com/javase/7/docs/api/javax/naming/Context.html

Ale ty tím pádem pravděpodobně musíš použít architekturu klient-server a provádíš připojení přes Socket. A pokud používáš socket pak v čem je problém? Prostě jej necháš v nekonečném cyklu. On stejně čeká a nevytěžuje procesor a pokud dorazí nejspíž String(neboť se jedná asi o klienta něčeho jako ICQ) tak je vypíšeš.

No a pokud ty potřebuješ v tom samotném vláknu které listeneruje ten socket zavolat nějakou metodu z ostaních tříd tak proč do konstruktoru vlákna při vzniku toho vlákna nedáš referenci na hlavní objekt či jiný objekt který s tou metodou disponuje.  Protože pak dané vlákno přeci má ten objekt k dispozi během svého běhu.

Tedy jak říkám pokud to chápu správně.

diki, spravil som si interface InMessage (listener) ktory je parsovany zo socketu ... nenapadlo ma ze implementacia si moze dat vlastny konstruktor a tymto tam injektovat vlastne objekty (sice musia byt threadsafe ale to by nemal byt problem)