[java] system.setproperty xml apis vec implementacij naenkrat

Da premaknem offtopic temo iz link.

kopernik:

Mah, to nima veze z multi threadingom oz. se da vse dinamično izpeljati. Glede implementacij xml parserjev (in podvojenih packageov nasplošno) pa je potrebno razumeti classloading mehanizem dotičnega j2ee strežnika, saj so j2ee specifikacije v določenem delu nejasne, zato vrstni red nalaganja jarov včasih ni tak kot pričakujemo.

Dinamicno izpeljat? Za SSL sem sicer nasel dolocene resitve, kjer implementiras svoj SSLContext, samo je bil problem, ker axisu nisem mogel poturiti svoj SSLContext. Drugace pa vrstni red loadanja je eno. Drugo je, da smo v aplikaciji rabili dve razlicni implementaciji xml apija (xml-apis) istocasno, kjer bi moral pred uporabo nastaviti pravilno implementacijo preko javax.xml.parsers.DocumentBuilderFactory, ter potem popraviti nazaj, vendar je problem, ker to jasno ne deluje v multithreaded. Ali si mogoce mislil, da bi naredil wrapper za DocumentBuilderFactory in ga glede na Thread context potem ustrezno nastavljali? Mi smo trenutno to popravili tako, da smo povsod, kjer smo imeli dostop do kode, delali classe direkt in ne preko factoryijev (za xml, xslt in sax).

Ce imas kaksno resitev bi ti bil seveda hvalezen (kako poturiti axisu svoj sslcontext (upam da je default sslcontext tisti, ki cachira client certifikat) ali pa glede propertijev oz. factoryijev) :).

Jaz sem to razumel kot da potrebuješ drugo implementacijo xml parserja kot tisto, ki je v containarju privzeta (xercers). In ne kot to, kar praviš sedaj :

Ne, narobe sem se verjetno izrazil, ampak point je bil v tem, da se uporablja vec implementacij na enkrat. Default implementacijo smo lepo izbrali ob konfiguraciji war paketa. Verjetno je prislo do zmede, ko sem notri pisal se o multithreadingu (kjer se sicer ta problem pojavlja, ce se menja propertije on the fly, ker so pac globalni).

Zato sem govoril o vrstnem redu nalaganja classov. Istočasna uporaba različnih implementacij ne bi smela biti problem, razen seveda če določene knjižnice (axis) ni možno prepričati naj uporablja drugačen način dostopanja do parserja kot je default. Jaz sem v isti aplikaciji uporabljal dom4j, xerces in še nekaj tretjega. Saj ni nujno, da greš prek privzetih sistemskih nastavitev.

Axis je bil v zvezi z certifikati in webservicei. Sicer je pa tocno tako kakor si rekel. Dolocenih knjiznic, prav tako classe od jave ne mores prepricati da ti uporabljajo drug factory (za certifikate, jsse, xml, in se kaj bi se naslo). Oz je tako, da se po nivojih moznost nastavljanja izgubi. (SSLContext->HttpsConnection->URI->Axis ...).

Kar sem razumel kot to, da imaš probleme s client certifikatom pri več threadih (dostopanjem do le-tega), ko želiš zamenjati keystore - rešitev je preprosto tako, da ustaviš threade, zamenjaš keystore in nato threade sprostiš. Sedaj kaže, da imaš probleme z zamenjevanjem certifikata v različnih treadih istočasno glede na potrebe vzpostavljanja ssl povezav. Je to sploh smotrno ? Ali ti ne zadošča to, da v keystorih (pa naj bo to trust store ali identity store) nabiješ n certifikatov ? Saj bo java sama iz fingerprinta pri vzpostavljanju SSL povezave izbrala ustrezen entry v keystoru (sklepam da se istočasno povezuješ na različne strežnike, ki se jim moraš predstaviti z različnim certifikatom).

Sem kar vse dal pod quote. Problem je, ker java ne dojame, da sem zamenjal keystore, ter se vedno uporablja starega (nekje ga cachira). Ce bi tisto prej delovalo, in bi threade ustavil pade performanca streznika, ker so to soap klici na dolocene zunanje ponudnike web serviceov. In ce bo vmes zablokiran streznik bo kriza. V keystore mi ni uspelo dodati vecih pkcs12 certifikatov (keytool tega ne zna). Zato sem uporabljal pkcs12 keystoretype z enim certifikatom.

Problem se imel tudi pri tem, kako prepricam httpsconnection, da uporablja drugega kakor default security provider, pri cemer mora biti zaradi drugih externih knjiznic vrstni red teh tocno dolocen (mozilla-jss in sele nato internal java). Z mozilla-jss providerjem pa httpsconnection ne deluje.

V glavnem point vsega tega je bil, da mi gre na zivce trenutna implementacija njihovih providerjev. Problem pa je, ker v vecini knjiznic (prav tako doloceni deli v javi) ne mores nastaviti kateri provider hoces imeti za tocno doloceno instanco. Tukaj je moznih vec resitev. Propertiji vezani na thread (delno ok, dokler niso gnezdeni klici). Ali pa da se da nastimati za izbrani namespace drugacen property (ali pa provider). Ali pa da se vsem knjiznicam + java classom doda propertije, ter se jih propagira na vseh klasih, ki uporabljajo te classe. Sicer reseno imamo trenutno, da pac sami buildamo knjiznice in fixamo tam kjer se da, vendar pa je potem problem pri prehodih na nove verzije externih knjiznic.

Sej to niso edini problemi vezani na javo. Ok to ni direktno problem jave, ampak bolj implementacij. Recimo nekompatibilnost oracle jave, ter sun jave pri parsanju cisto osnovne zadeve kakor je timezone-a.

Super, tnx, bom probal ob priliki. Bouncycastle sem gledal takrat, ko sem rabil parsanje urljev do CRL list v certifikatih preko ASN.1, ki pa jih java seveda ne podpira. Bil je celo problem, ker java ni pustila dobiti X509 CRL distribution point extensiona, ceprav je bil v certifikatu. Tako da upam da bo java dobila kompletno podporo za CRLje (ne samo parsanje crl list). Vkljucno z cachiranjem kakor ima to poslihtano ms crypto api. In isto velja za firefoxov nss (baje bo v 2.12 rfc3280 kompliant crl).

Sej da ne bos mislil .NET ima podobne cvetke. Recimo ni mozno podpisati s SHA-512, ce certifikat nima exportable private kljuca (ker cryptoapi ne podpira SHA-512 in je samo v managed kodi).