• 25/06/2008 18:49
• 

• Git! 0

  Kit! 0

Witam,
Czy jest jednoznacznie zdefiniowane co sie dzieje jesli mam kilka identycznych klas (zakladamy ze to sa dokladnie te same wersje, skompilowane z tego samego source, chociaz niekoniecznie z identycznymi opcjami typu -target czy -g) w dwoch roznych jarach w classpathu?
Rozumiem ze to zalezy po prostu od kolejnosci jarow, bierze z pierwszego, tak?
A co z/ WEB-INF/lib? pewnie tez z pierwszego, ale nie ma gwarancji jak konstruowany jest classpath, prawdopodobnie alfabetycznie, ale niekoniecznie, tak?

Pozdrawiam, L

• 25/06/2008 20:56
• 

• Git! 0

  Kit! 0

1. Kto pierwszy ten lepszy. Po załadowaniu klasy kolejne jej kopie niezależnie od wersji są ignorowane. Jest to źródło problemów w np. JBossie, na którym stoja dwie instancje tej samej aplikacji.

2. Zapoznaj się z mechanizmem Endorsed, który pozwala na przeładowanie klasy.

3. Poczytaj też o OSGi, które to potrafi wyczyniać cuda z klasami i ich ładowaniem.

• 25/06/2008 22:07
• 

• Git! 0

  Kit! 0

Inaczej - czy jest gdzies oficjalnie, w specyfikacji, zagwarantowane ze jesli ten sam classloader widzi dwie kopie tej samej klasy, niekoniecznie identyczne ale w 100% kompatybilne, od publicznego api do szczegolow serializacji, to nie moga wystapic zadne problemy?

To ze to normalnie dziala, wiem, ale stare double checked locking na typowym desktopie tez przewaznie dzialalo bezproblemowo, chyba ze akurat byla pelnia ksiezyca trzynastego w piatek w rok przestepny.

• 25/06/2008 22:47
• 

• Git! 0

  Kit! 0

Nie. Jeżeli masz dwie kopie tej samej klasy to problemy najprawdopodobniej wystąpią. Punktami zapalnymi są tu pola z modyfikatorem static. Ponieważ będą one wspólne dla wszystkich odwołujących się do nich klas.

• 30/06/2008 19:04
• 

• Git! 0

  Kit! 0

>Koziołek [brat Javowiec] napisał
>1. Kto pierwszy ten lepszy. Po załadowaniu klasy kolejne
>jej kopie niezależnie od wersji są ignorowane. Jest to
>źródło problemów w np. JBossie, na którym stoja dwie
>instancje tej samej aplikacji.
>

http://wiki.jboss.org/wiki/ClassLoa...

• 02/07/2008 01:06
• 

• Git! 0

  Kit! 0

wszystko też zależy od wartwy/kontenera. O ile pamiętam z dokumentacji, to w GF defaultowo każdy deployment (ear/war/jar) ma własny classloader (ewentualnie względem siebie odpowiednio w hierarchi), każdy kontener (ejb/web), a nawet -- kontener serwletów ma classloader niezależny od JaSPera (!). Classloadery są oczywiście delegowane w drzewie. W domyślnych ustawieniach wspólne są jedynie jary z liba (i niektórych podkatalogów).

• 02/07/2008 01:44
• 

• Git! 0

  Kit! 0

Pozwole sobie zaznaczyc ze chodzilo mi dokladnie o sytuacje z _jednym_ classloaderem.

Czyli np. dwa jary w/ WEB-INF/lib, a.jar zawiera klasy a.A i x.X, b.jar zawiera b.B i x.X, przy czym wiadomo ze obie kopie x.X byly kompilowane z tych samych zrodel i tej samej wersji.

• 02/07/2008 02:06
• 

• Git! 0

  Kit! 0

>Koziołek [brat Javowiec] napisał
>1. Kto pierwszy ten lepszy. Po załadowaniu klasy kolejne
>jej kopie niezależnie od wersji są ignorowane. Jest to
>źródło problemów w np. JBossie, na którym stoja dwie
>instancje tej samej aplikacji.

Jestem prawie pewien, że specyfikacja JVM nic na ten temat nie mówi -- zachowanie zależy jedynie od implementacji classloadera. Być może jest coś o tym w specyfikacji Java Servlet, ale jeśli nie ma, to należy rozumieć, że zachowanie jest zależne jedynie od implementacji kontenera (i tak podejrzewam, że jest).

• 02/07/2008 02:19
• 

• Git! 0

  Kit! 0

Specyfikacja Servlet 2.4 w punkcie 9.7.2 mówi jedynie o tym, że jary z web/lib nie mogą podmieniać klas z pakietów java.* oraz javax.*, a także, że jary z web/lib mają priorytet w stosunku do tych widzianych przez kontener -- czyli np. implementacja JSF zawarta w web/lib powinna mieć priorytet nad tą, umieszczoną w kontenerze.

Tak więc -- nie ma gwarancji która klasa z którego jara będzie widziana.