Keresés

Új hozzászólás Aktív témák

  • Lortech

    addikt

    válasz Szmeby #6891 üzenetére

    Nincs általános válasz, normálisan nem kéne ilyen probléma legyen két war között. A frameworköknek és konténereknek kéne megoldani, hogy ilyen ne legyen, mégis gyakran előfordulnak ehhez hasonló érdekességek.
    A RuntimeDelegate lehet speciális, mivel javax-es package-ben van, és elképzelhető, hogy ezt a jetty a system classloaderrel tölti. Valami közös szülő classloadernek lennie kéne a két alkalmazás között, ami okozza a problémát, másként érvényesülne az, hogy a szóban forgó osztályok a war-ok WEB-INF/lib WEB-INF/classes-eiből töltenek, mivel ez prioritást élvez, és a két "különböző" verzió nem akadna össze.

    Meg egyáltalán... nem a thread contextclassloaderét kellene használnia egy objektum legyártásakor? Vagy ilyenkor a legyártást végző osztály classloaderét örökli az új objektum? Ezekszerint az utóbbi.

    Utóbbi. A createUriBuilder működhetne úgy is, hogy a thread context classloaderrel tölt be egy implementációt, de a bemásolt kód nem ezt teszi (az se biztos, hogy ez a sor indukálja a class betöltését).

    Amúgy hol vannak a resteasy lib-ek? WEB-INF/lib-ben van mindkét war-ban ugyanaz a verzió?
    Én a "-verbose:class" -t is megnézném, hátha valami összefüggés kiolvasható belőle.

  • floatr

    veterán

    válasz Szmeby #6891 üzenetére

    JBoss tud olyant, hogy egy közös war-ba lehet telepíteni a közösen használt libeket. Mondjuk az sem sokkal jobb megoldás, de kicsit furcsállom ezt a classloader összeakadást. Most nézem, hogy maven plugin is van arra, hogy egy konkrét war-ból kimásolja a libeket az újba jettyhez.

    Én mondjuk tutira kitesztelném ezt a dolgot egy saját jarba forgatott singletonnal, ami logol mindent, ami az életciklusával kapcsolatos.

Új hozzászólás Aktív témák

Hirdetés