OpenCMS tapasztalatok

Jónak tűnik, a downloadot nem kell keresni, rögtön adja a documentation-t is, csak egy war file az egész. Be nyomom a webapps-ba, minden alapértelmezetten, de linux alatt kihal amikor az egyik properties file-t akarja írni (Import modules stáció), után azt mondja, hogy kész, de persze nem indul el, csak hasonló értelmű 500-as hibával meghal.

Átnyergeltem windows-ba, és lám, már 5 perce nyomja fel a modulokat.

Lehet hogy én nem adtam valami jogot neki? Nem tudom, de a tomcat ugyanazon useren fut, aki kicsomagolta az opencms-t.

Folyt köv.

ps: múltkor az infoGlue-val szívtam, ott már a firefox böngésző kompatibilitáson elvérzett a dolog linuxból. Java, platformfüggetlenség, stb...

Szószátyár SOAP

Már épp ittam a győzelmi pezsgőt, hogy mennyire faszán beillesztettem a SOAP-ot az appomba, amikor megmértem mennyi megy át a hálón, és lefagyott az arcomról a mosoly. Arról nem is beszélve, hogy amikor két objektum egy-egy osztályváltozójában ugyanarra a másik objektumra mutat a referencia, akkor SOAP után az két külön objektum lesz.

Kipróbáltam a hessian-t is, az remek bináris formátumban eregeti az adaokat és ráadásul a referenciák is megmaradnak. Kár, hogy a hessian kissé alul van dokumentálva. Például sehol se találom, hogy a POST kérést hogy kell felépítenem, hogy menézhessem mennyi adat megy át a hálón.

SMSlib

Anno Ericsson T65-ös telefonjaimkról egy fma nevű programmal mentettük le az smseket. Most ki akartam nyomtatni a szöveget a nyers fájlból. A delphi forrás kód alapján egy un. PDU formátumban van. Több probálkozás után végül az smslib lett a javás befutó, aki meg tudta olvasni a PDU stringeket nekem.

CIncomingMessage cmsg=  new CIncomingMessage(pda,i++);
System.out.println(cmsg.getText());

Ritkán, de egyes üzeneteket nem tud visszakódolni. Nem tudom azok mik lehettek.

Netbeans + https + WSDL

Xfire-t félretéve kínomban Netbeans-szel próbálkoztam. Nagyon kellemes meglepetés, mert nagyon jó Webservices támogatása van. New web service client és ott megadom a WSDL url-jét, és ő mindent legenerál. A kódban a a megfelelő helyen pedig jobb klikk és oda passzintja a lekérdező kódot. Tiszta hedon.

Persze ha ilyen jól megy minden kipróbáltam HTTPS-sel is. A WSDL beolvasáskor azonban elszállt csúnyán valami ilyesmivel:

java.rmi.RemoteException: HTTP transport error: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target; nested exception is:

Kis guglizás után kiderült, hogy a generált tomcat ssl tanúsítványt be kell importálni megbízhatóként egy keystore-ba, és azt megadni neki paraméterként. Netbeans eképpen indítva valahogy így:

cd /home/... keytool -genkey -alias tomcat -keyalg rsa keytool -export -alias tomcat -rfc -file tomcat.cer keytool -import -alias tomcat -file tomcat.cer -keystore truststore ./bin/netbeans -J-Djavax.net.ssl.trustStore=/home/.../truststore -J-Djavax.net.ssl.trustStorePassword=changeit

Persze utána a programot is ilyen JVM paraméterekkel kell indítani

-Djavax.net.ssl.trustStore=/home/...truststore -Djavax.net.ssl.trustStorePassword=changeit

Ezek után a végén még a xfire is működni fog.

Xfire + SSL

Az XFire egy elsőnek is nagyon tetszetős SOAP framework. Viszont a második célom rögtön az lenne, hogy SSL-en is működjön. A Tomcat-et a doku alapján pillanatok alapján rá lehet szorítani az SSL-re, de példaprogram ami HTTP-n működött, HTTPS-en sehogy se akar. Mély guglizás kezdődik.

Spring + JPF

Mai napi legnagyobb problémám, hogy a Spring frameworkot szeretném keresztezni valahogy a Java Plugin Frameworkkel. Valahogy úgy, hogy egy könyvtárba berakok egy modult és az beépüljön az egész oldalba.

Az, hogy ez nem JPF hekkelés lesz, hamar kiderült, ugyanis a JPF túlságosan standalone application specifikus. (Bár a honlap szerint hamarosan előállnak egy j2ee demóval is). Például egy boot plugin is kell hozzá, ami nekem nem lesz, vagy újra kell írnom a betöltő folyamatot, amihez meg nincs kedvem.

Első nekifutásra elég egyszerűen megy, hogy a Spring beans.xml-ét több könyvtárba szétdobjam, mert ant típusú /**/ mintákat is elfogad a web.xml-ben a dispatcher servlet init-paramban megadva.

Azt, hogy ezekben a könyvtárakban az osztályok is bekerüljenek a classpath-ba már keményebb dió volt. Előszőr a DispatcherServlet lecserlésén fáradoztam, de az sajnos egy harmadik gyerek, és még a második gyereknál bele van kódolva a class loader a kódba. Szerencsére azonban kiderült, hogy az XML értelmező contextClass szintén init-paramként megadható servleten és az XmlWebApplicationContext-et vidáman lecserélhetem egy öröklött osztálya, ami a konstruktorban létrehoz egy osztálbetöltőt és a setClassLoader-rel érvényt is szerez neki.

Kezdet.