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

• Szmeby tag

  #6897

  #6895 Lortech

  2015-02-24 13:13:13

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Szmeby

  tag

  #6895 Lortech

  #6895 Lortech

  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.

  "Amúgy hol vannak a resteasy lib-ek? WEB-INF/lib-ben van mindkét war-ban ugyanaz a verzió?"
  Igen, mindkér war WEB-INF/lib könytárában vannak a jarok. Ugyanaz a verzió, bár szerintem ez már nem sokat számít.

  "Én a "-verbose:class" -t is megnézném, hátha valami összefüggés kiolvasható belőle."
  Jaja, tegnap már mentem vele egy kört, de elég nagyok ezek a warok, hogy az eclipse console 2 war esetén is kifusson a maxra húzott pufferből.

  Köszönöm mindenkinek a tippeket, még szenvedek vele egy kicsit.
  Legrosszabb esetben majd futnak külön jettyben.

  Érdekességképpen:
  Thread.currentThread().getContextClassLoader()
  /* WebAppClassLoader=webapp2 */
  
  org.jboss.resteasy.specimpl.ResteasyUriBuilder.class.getClassLoader()
  /* WebAppClassLoader=webapp2 */
  javax.ws.rs.core.UriBuilder.fromUri(absoluteUri).getClass().getClassLoader()
  /* WebAppClassLoader=webapp1 */
  
  javax.ws.rs.core.UriBuilder.class.getClassLoader()
  /* sun.misc.Launcher$AppClassLoader@74f2ff9b */
  javax.ws.rs.ext.RuntimeDelegate.class.getClassLoader()
  /* sun.misc.Launcher$AppClassLoader@74f2ff9b */
  javax.ws.rs.ext.RuntimeDelegate.getInstance().getClass().getClassLoader()
  /* WebAppClassLoader=webapp1 */

  org.jboss.resteasy.core.ThreadLocalResteasyProviderFactory (ami egy RuntimeDelegate) rendelkezik egy "org.jboss.resteasy.spi.ResteasyProviderFactory defaultFactory" field-del (ami szintén egy RuntimeDelegate). Bár threadlocal az osztály neve, de azt a funkcióját épp nem használja semmire, hanem a defaultFactory-val dolgozik, amihez a webapp1 anno már készített egy példányt. Ezen a példányon keresztül gyűrűzik be a rossz classloader a másik webapp-ba.

  Az UriBuilder mélyén minden a webapp1 classloaderével készült.
  org.jboss.resteasy.specimpl.ResteasyUriBuilder.class.getClassLoader()
  /* WebAppClassLoader=webapp1 */
  new org.jboss.resteasy.specimpl.ResteasyUriBuilder().getClass().getClassLoader()
  /* WebAppClassLoader=webapp1 */

  Feltételezem, úgy lenne ez szép, ha a közös libek közös classloaderrel töltődnének be (külön webapp-ban?), csak hát erős a gyanúm, hogy a sok war libjei más-más közös részhalmazzal rendelkeznek.
  Vaaagy, kicsomagolom a warokat egy helyre, és minden fusson a system classloaderrel.
  Ez már nagyon hekkes lenne.

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