Legyünk egészen precízek. A kérdéses körülbelül ilyen: "van egy kocsim, a gyártmánya Ford*, elromlott rajta valami, mi lehet a baja?".
A Java egy programozási nyelv. Írnak benne kismillió programot. Hogy nálad éppen melyik van, mit csinál, és miért nem csinálja azt, amit kellene neki, így messziről pontosan úgy nem tudjuk, mint a kocsidról nem tudjuk, hogy mi baja, ha elromlott.
Egyébként: a Java futtató része, amit csak úgy letöltögetsz a netről, hírhedten pocsék. Szóval, azért meglepetés nem nagyon van belőle. :-)
Leírjam még egyszer, nagyon lassan, hogy jobban megértsed? Parancsolj: annyiból, hogy 'java probléma keletkezett' nem lehet az égvilágon semmit megállapítani.
Azert ez a ceco, mert jnlp "sandbox"-ba kerul a kliens alkalmazasom, ami egy swinges vastagkliens. A fejlesztokornyezetben, minden rendben mukodik, azonban szeretnem a kodot Web Starttal terjeszteni, es itt jonnek a gondok.
A jar file-okat egy http basic auth-tal vedett weboldalrol lehet leszedni. Ilyenkor a javaws, mivel kap a szervertol egy 401-es hibakodot - mert ugye authentikalnia kell, ha hozza akar ferni a jar-okhoz - foldob egy ablakot, ahol a user megadhatja az azonositokat (un/pw).
Ezutan, minden a serverhez intezett http keres headerjebe kuldi ezeket az adatokat. Ez idaig nagyon szuper.
Ott van a gond, hogy az en alkalmazasom altal a servernek kuldott http keresek headerjebe is beleteszi ezt az Authorization: Basic "Base64KodoltUsernamePassword" . Sőt!
Folulirja az en alkalmazasom altal irt headert, mert en is http basic authentikacioval erem el a servert. Tehat en beleteszek egy name/value parost, a jnlp meg szepen felulirja. Na ez mar nagy gaz. Az gondoltam becsapom a javaws-t es a servletkontener altal adott hibakodot (401 es 403) kicserelem valami szabad kodra, pl 461 es 463. Ezt kodot elkapja az alkalmazasom, es megerti, hogy mit jelent, de a jnlp nem reagal ra, azaz nem ir bele a headerbe. Ehhez persze hozzatartozik, hogy kellett csinalni egy aldomaint, hogy az alkalmazasom, es a jar file-ok ne egy domainben legyenek, mert ha egy domianben vannak, akkor a jnlp mindenkeppen kuldi a sajat http basic bejegyzeset, mert arrol a domainrol mar kapott korabban egy 401-et, amikor le akarta tolteni az elso jar file-t.
Ez ugy muxik kb mint egy webbongeszoben. Azaz ha csak egyszer is visszakuld a szerver egy 401-es kodot, onnantol a jnlp mar mindig kuldi a headerben a un/pw parost. Azaz onnantol soha tobbet nem tud megfeleloen kommunikalni az alkalmazasom a serverrel, mert az arra a domainre iranyulo http keresek headerjet atirja a jnlp.
Igen, ez igy van le debuggoltam a dolgot, csak az a baj, hogy a response hoz nem ferek hozza. Ez a metodus paramkent a requestet, es a servlerContext-et kapja. Ha ebbol a metosbol elernem a response-t, az valszeg megoldas lenne. :(
közben az jutott eszembe, hogy átolvasva a container szintű autentikációt, az elbukott autentikációhoz be lehet konfigurálni egy url-t ahova a végrehajtás át lesz irányítva, nálunk is van ilyen landing page
feltételezem, hogy ennek az urlnek a helyére be lehetne rakni egy servletet, ami a hiba-ágon megfut és ott lehet piszkálni a headert
Van egy EE projec, benne egy web service, ebben a kontextusban tulajdonkeppen egy servlet. Szeretnem modositani a a response headerjet.
A nehezseg ott van, hogy a webkontener autentikal, es, hogy abban az esetben is kell a hozzaferes a response obj-hoz, ha elhasal a user az autentikacion. Ekkor a servlet filter (ahol modosithanam peldaul a response-t) nem ok, mert az meg sem hivodik a meghiusult autentikacio miatt.
Talaltam egy olyat, hogy ServletRequestListener. Ezzel elkaphatom a requestet, meg az autentikacio elott, tehat annak sikeressegetol fuggetlenul elerem a requestet. (sot az autentikacio utan is hozzaferek)
Nekem viszont a responsehoz kellene hozzaferes, mert annak e headerjebe kell irnom. Tud valaki megoldast erre?
az én esetemben jogos, mert nem ismertem eddig, illetve valszeg a jövőben sem fogom használni, mert a legtöbb helyről az jön le hogy a httpclient gyorsabb is, meg egyszerűbb programozni
httpclient-el szívtam tegnap/tegnapelőtt elég sokat, egy weboldalt szerettem volna HTTP POST request-el megpörgetni, hogy a nekem kellő keresési eredményeket tartalmazó html-t kapjam vissza (ami helyett rendre a kérdést tartalmazó formot kaptam vissza)
linuxon egy justniffer nevű programot használva sikerült elfognom hogy mégis mit küld ki a chrome:
a default-ok az osztály elején vannak felsorolva, és a megadása nélkül ezeket használja
lejjebb olvasva kiderült, hogy: setCharset() illetve a másik két értékre is létezik setXX függvény, és ezek fogadnak null-t, amikor nem ír a request part-ba Content-Type-ot, és Transfer encoding-ot sem
a setCharset() viszont nem a multipart requestbe ír paramétert, hanem magához a kódoláshoz használja fel, így az nem lehet null, ha null marad akkor NullPointerException-el elszáll a request meghívása (még a kliens oldalon)
hát, nekem a link nélkül semmit se mondott volna a név :)
(van pár focibuzi haverom, azok az angol másodosztály csapatainak a tagjait név szerint felsorolják 10 évre visszamenőleg, engem viszont teljesen hidegen hagy a dolog)
