Siema, pierwsze raz zakładam wątek w tym dziale, ale czy kojarzycie jak możnaby rozwiązać następujący problem:
help :D @jarekr000000 @scibi92 @Shalom
A to jakaś aplikacje JEE czy Spring?
Twoja apka potrzebuje twojego jara, a używa jara z serwera, który jest 'stary'. Wsadzenie do apki jara z serwera nic nie daje bo to twój jest ten 'lepszy', mógłbyś podmienić jar na serwerze na ten swój, ale nie rób tak :D
Ja w swoim projekcie używam guavy 23.0, na weblogicu, na który deployuje jest guava bodajże 12.0 i jakbym nic nie zrobił to ona będzie domyślnie użyta i dostanę tonę błędów. Dlatego mam takie coś:
Java <prefer-application-packages>
<package-name>com.google.*</package-name>
<package-name>org.jboss.logging.*</package-name>
</prefer-application-packages>
Nie napisałeś jakiego konkretnie używasz, ale na Websphere czy Jboss sa pewnie podobne możliwości.
Generalnie ciężko. Używaj wersji które masz z sewerem. Cudowanie z ustawianiem preferencji, jak powyżej, jest ryzykowne bo pewnie jakieś inne paczki od tego zalezą i nadal będą latać wyjątki że sygnatury nie pasują.
Na WebSphere masz możliwość skonfigurowania class loaderów i wskazania czy klasa ma być wyszukiwana w parent class loaderze czy w class loaderze aplikacji.
Dodatkowo jeśli na WS są zdeployowane biblioteki współdzielone, to aplikacja powinna być skojarzona z taką bibliotekę współdzieloną (o ile chcesz korzystać z tej wersji współdzielonej... )
@yarel: WebSphere 9, deploy polega na tym że wchodzę na consolę WS w chromie i idę do Enterprise aplication types -> install i wybieram mój war. Deploy sam w sobie jest owocny, ale później podczas próby startu owej aplikacji, są te błędy
To by trzeba rozważać przypadek po przypadku. Jaki jar, jakie błędy?
Dorzucasz liby mavenem?
To pewnie razem z twoim jarem dobierają się inne, które powodują konflikty.
Wtedy robisz exclusions, w najgorszym razie ręcznie wybierasz jara przez <system>/ path (straszny syf - dawno tak nie musiałem).
Czasem rozwiązanie to nawet podmiana jarów na serwerze (i jboss, i websphere ma koncept takich ext (shared) billiotek - względnie cywilizowany).
Tak ogólnie bez konkretu to jedyne co mogę poradzić to 1850 EURa za dzień + koszty transportu, przylatuje i rozwiązuję. Dzień raczej starczy w typowym projekcie. Chyba, że to dym na skraju JSF + Bean Validation - wtedy pewnie dwa dni :-)
Ktoś tam pewnie wybrał tego webshera i musiał raczej wiedzieć, że to płatne rozwiązanie. Płacisz albo krwią programistów, albo kasą dla konsulatantów - przeważnie w obu walutach.
jarekr000000 napisał(a):
To by trzeba rozważać przypadek po przypadku. Jaki jar, jakie błędy?
Dorzucasz liby mavenem?
To pewnie razem z twoim jarem dobierają się inne, które powodują konflikty.
Wtedy robisz exclusions, w najgorszym razie ręcznie wybierasz jara przez<system>/ path (straszny syf - dawno tak nie musiałem).Czasem rozwiązanie to nawet podmiana jarów na serwerze (i jboss, i websphere ma koncept takich ext (shared) billiotek - względnie cywilizowany).
Tak ogólnie bez konkretu to jedyne co mogę poradzić to 1850 EURa za dzień + koszty transportu, przylatuje i rozwiązuję. Dzień raczej starczy w typowym projekcie. Chyba, że to dym na skraju JSF + Bean Validation - wtedy pewnie dwa dni :-)
Ktoś tam pewnie wybrał tego webshera i musiał raczej wiedzieć, że to płatne rozwiązanie. Płacisz albo krwią programistów, albo kasą dla konsulatantów - przeważnie w obu walutach.
EDIT:
jar to apache lang3, błąd jest java.lang.NoSuchMethodError: org/apache/commons/lang3/StringUtils.removePattern
Jeszcze nie napisałeś skąd to leci, kto wywołuje. W sumie ważne.
Ale pierwszy hint - musisz mieć wersję co najmniej 3.2, żeby ta metoda była.
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.2.1</version>
</dependency>
System. Problem też jest taki, że jeśli chodzi o jara, który potrzebuje tej minimum 3.2 wersji, to nie mogę jego wersji obniżyć, bo coś tam było ustalone :D
parent last powinno zalatwić. Normalnie to sprawdzam jeszcze na debugu z jakiego classloadera faktycznie klasa pochodzi - Class.forName('....tu moja klasa').getClassloader() - coby potwierdzić skąd się gówienko bierze.
jar masz gdzie.
A czy rozwiązaniem problemu nie jest EAR i zdefiniowanie pod niego bibliotek? Coś mi chodzi po głowie, że takie rzeczy były w dokumentacji WebLogica, więc pewnie na WAS-ie też są.
@jarekr000000: Ogólnie to sprawę komplikuje fakt, że war który chcę zdeployować, nie jest napisany przeze mnie... to jest war pewnej third party biblioteki, które w sobie ma oczywiście jakieś tam liby i wśród nich są jary commons lang3 i commons lang. Co gorsze, najstarsza wersja tej third party biblioteki, wciąż zawiera commons lang3 w wersji powyżej 3.1
Hmm niczego takiego @jarekr000000 w WARzie nie znalazłem, ale w logach widzę że
Parent: com.ibm.ws.classloader.CompoundClassLoader@...
Delegation Mode: PARENT_FIRST
Czyli mimo że w konsoli WASa zmieniłem dla tejże aplikacji z parent first na parent last, to właśnie jakby nie zadziałało ustawienie tego (cały server też restartowałem)
EDIT:
Elegancko, haha :D Do tej pory zmieniałem na PARENT_LAST z poziomu aplikacji, teraz zmieniłem z poziomu modułu (jeden poziom niżej) i chyba widzi, bo już są inne błędy :)
javax.servlet.ServletContainerInitializer: Provider org.apache.logging.log4j.web.Log4jServletContainerInitializer not a subtype
Ale ważne że krok naprzód. Mega się cieszę!!!
EDIT2:
Na http://www-01.ibm.com/support/docview.wss?uid=swg1PI67363 niby piszą że trzeba kolejnej wersji WASa... ale nie jestem pewien czy czegoś innego nie wystarczy zrobić
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.