Myšlenky dne otce Fura

Pokud mi někdo řekne, že moje aplikace má běžet v aplikačním serveru OC4J naskočí mi husí kůže. Tento reflex se mi už dostal do podvědomí kvůli řadě bezesných nocí řešením řady chyb ukrytých v kódu, ke kterým člověk nemá zdrojové kódy. Nedá se ovšem nic dělat, náš zákazník, náš pán. Opět jsem se tedy musel ponořit do zakalených vod bažiny OC4J.

Pozn.: Tento příspěvek byl psán ve velké depresi. Kdo nemáte rádi pesimistické články před víkendem, radši ani nepokračujte .

Na co jsem narazil tentokrát? Na špatnou práci OC4J s resourcy na classpath. Spring framework má příjemnou funkci, která umožňuje nalézt resoucy na základě patternu obsahujícího wildcard znaky. Např. výraz “classpath*:applicationContext.xml” vám na “normálních” aplikačních serverech najde na classpath všechny soubory s názvem “applicationContext.xml”, výraz “classpath:META-INF/spring/*” by vám zase měl najít všechny soubory ve složkách “META-INF/spring” všude na classpath.

Spring to dělá tak, že se pokusí nalézt resource s nejbližším specifikovaným umístěním (např. v druhém případě se zavolá něco ve smyslu classLoader.getResource(“META-INF/spring/”)). Pokud složka na classpath existuje vrátí se object URL ukazující na daný resource. Z toho URL si Spring zjišťuje reálné umístění – porovnává URL.getProtocol() se standardními protokoly (“jar”, “zip” apod.) a v případě že nalezne shodu, vytáhne seznam souborů přes abstrakci pro JAR archívy (JarURLConnection, JarFile, JarEntry). Pokud shodu nenalezne, předpokládá, že se jedná o zkompilované classy v rozbaleném stavu standardně na filesystému.

Uvedený přístup funguje – ne však na OC4J. V závislosti na verzi OC4J jakou používáte narazíte na různé chyby. Například ve verzi 10.1.2.X není možné nalézt resourcy na classpath, pokud se nejedná už o cílový soubor. Když dáte classLoader.getResource(“META-INF/spring/”), vrátí vám Oracle classloader null hodnotu, přestože složka na classpath přístupná je.

Verze 10.1.3.X už je na tom lépe, u složek vám URL vrátí, nicméně zde označí protokol jako “code-source”, takže opět Spring neví, jestli to je v JARu nebo rozbaleně na disku (chybu už jsem nahlásil viz. SPR-3793 – samozřejmě na Spring Framework, protože pochybuji, že z Oraclu nějaké vyjádření / opravu bez tučného bakšiše ve formě subscription dostanete).

Prostě to celé jen dokresluje moji dosavadní zkušenost s OC4J – chyby, chyby a zase jen další chyby. Díky proprietárnímu a uzavřenému kódu nic nezjistíte ani s tím nic neuděláte. Zlatý open source. Nevím jestli je to jen pocit, ale mám takový dojem, že otevřený kód vede k větší čistotě a menší chybovosti dané knihovny. Kdo by si chtěl utrhnout veřejně ostudu slátaným kódem bez automatických testů?! Nakonec si říkám – já snad radši ani nechci ty zdrojáky OC4J vidět.

Nějaké odkazy na závěr:

• podobné zoufalství ovšem s Tapestry na OC4J
• diskuse problému na Oracle fóru – bez odpovědi

Dodatek k 2.7.2007: Chyba OC4J 10.1.3.X bude již ve verzi Spring Frameworku 2.1 obejita. Do jednoho týdne Interface 21 upravil kód, aby se s probémem vypořádal. Takhle by to mělo fungovat . Mám rád Spring.

Ohodnoťte článek:

(4 hlasů, průměrně: 5.00 z 5)

 Loading ...

Článek byl odeslán 30.08.2007 v 8:55 a je zařazen do kategorie Java, Spring Framework. Reakce na tento článek můžete sledovat skrze RSS 2.0 feed. Můžete vložit reakci, nebo vložit odkaz na vaše stránky.