Java JAXB anomália

Java

Sziasztok!

Találkoztam egy olyan csodával, amit nem tudok mire vélni.

http://hup.pastebin.com/m401671df Ez van egy osztályom megvalósításában.

http://hup.pastebin.com/m5ee50d12 Ez meg egy másikban.

Az első esetben a getProblem() null-al ter vissza, a masodik esetben pedig betoltodik a megfelelo objektum.

Mint latszik, direkt be van egetve a file helye es a schema helye is, a kod a Logger es a System.out.println kivetelevel meg is egyezik.

No itt mi van?

  • 1427 megtekintés

( uid_13349 | 2009. 05. 29., p – 12:22 )

Na neee, ilyen állat nincs! Ha a Logger.log-ot lecseréled System.out-ra uez lesz? (Látom, h majdnem tök azonos a két kód, de mégis: pontosan uazt a kódot átírva is uez lesz az eredmény?

Más: debug a két kódban?

Szia!

Természetesen uez lesz az eredmény.

A logger a következő vjában:

public static void log(String logString) {
Throwable t = new Throwable();
System.out.println(t.getStackTrace()[1].getClassName() + "[" + t.getStackTrace()[1].getLineNumber() + "]:" + logString);
}

Azaz csak arra jó, h kiírja, h melyik class melyik sorában dobtam ki a konzolra a stringet.

( asch v | 2009. 05. 29., p – 13:56 )

Az ilyen misztikus dolgoknál általában a classloaderek zavarnak be. Elképzelhető, hogy mondjuk a loggerből egy másik verzió töltődik be és ez bezavar a JAXB implementációnak, de mondjuk véletlenül egy szó nélkül elnyelt exceptiön formájában.

Az ilyen enterprise irányból jövő dolgok tele vannak név szerinti osztálybetöltéssel és egyéb minőségromboló nyalánkságokkal.

A JAXB annyira enterprise, hogy a Java 6 SE-nek resze.

Az egyik kod egy Eclipse RCP alkalmazasbol van, a masik az egy sima public static main()-en belul fut....

A Loggerbol nem tud betoltodni mas verzio, csak az az egy, ami van, de mint irtam, az csak egy konnyites , igazabol a Thread.currentThread.getStrackTrace()...stb hivasok allando kiirasanak elkerulese miatt van.

Jól értem, különböző környezetben fut a két kód?
Mondjuk ez más jellegű ügy, de talán valami analógiára mégis jó: nemrég jártam úgy, h uazt a kódot futtatuk két különböző gépen uavval az alkalmazással. Az egyik helyen elhasalt jó mélyen a JAXB implementációban. Kiderült, h az egyik helyen egy kicsit régebbi java futott (u7 vs. u10), amiben a JAXB egy belső inicializációs lépése hibás volt.
Szóval a kétféle kódot futtató java verziók pontosan uolyanok?

Igen, a java implementacioja teljesen ugyanaz, teljesen ugyanazok a betoltott osztalyok is. A ketfele kod egyfele java segitsegevel fut. Meg ket kulon geprol sincs szo, ez az en gepem, ket kulon fejlesztett es futtatott Java progival.

A legjobb, hogy a nem mukodo kod reggel meg mukodott. Semmit nem valtoztattam rajta. Ugyanugy, az RCP app is elhall IllegalStateExcetionnel. Egyik futtatasrol a masikra.

RCP esetén minden bundle külön osztálybetöltővel töltődik be, a függőségek szigorú fába vannak rendezve. Sima alkalmazás indításnál egyetlen nagy olvasztótégely az osztálybetöltő. Hiába ugyanaz a program, ha teljesen más környezetben fut.

Persze rendes design esetén ez persze nem jelent problémát, de egyáltalán nem biztos hogy a JAXB implementáció esetén rendes design-ról beszélhetünk. Igaz, hogy már Java SE, de EE _felől jött_. És ott gyanakodni kell a minőségre. Az "alap Java" esetén tényleg az van hogy remek dokumentáció van és elvárás szerinti működés. Majdnem mint a matematika. A probléma csak az, hogy nem lehet megmondani, hogy mi az "alap Java" :-).

Persze nem csak a classloader lehet a probléma. Általában ami misztikus ott általában erre lehet gyanakodni. Másik slágertéma a szálkezelés, ott sem árt körülnézni, az IllagalStateException utalhat ilyenre.

Szia,

mint ahogy asch is irta, ez a hibajelenseg siman szarmazhat az osgi classloader mukodesebol (esetleg, le lehetne tesztelni egy-ket classloader breakpoint beszurasaval).

Ajanlom figyelmedbe ezt a bejegyzest: http://www.dynamicjava.org/projects/jsr-api/jaxb-osgi

Ha sikerul megoldani a problemat, azert jelezz vissza :)

--
Happy