Zdravim, Podobny problem jsem resil se stax-api.jar, take musime pri buildu pro WebSphere odmazavat javax/xml/namespace/*.class javax/xml/XMLConstants.class
Nejhorsi jsou ty hodiny a dny stravene hledanim, co vlastne kde prekazi... (nastesti vsechny ostatni problemy se daly vyresit odstranenim celeho jaru). Prace s knihovnamy (resp. naprosta absence funkcni koncepce knihoven) je asi nejvetsi problem Javy jako platformy. Kamil "podlesh" Podlesak > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Jan Moravec > Sent: Tuesday, August 19, 2008 2:22 PM > To: 'Java' > Subject: Monoliticke JARy (napr. Metro webservices-extra.jar) > > > Zdravim, > > Pochopil jste nekdo proc Sun (a urcite jsem to videl i u > jinych) distribuuje nektere sve produkty tak, ze vezme > nekolik knihoven, ty rozbali a udela z nich jeden obrovsky > monoliticky JAR? > > Priklad: Sun Metro WS stack > > To by se clovek opravdu strelil. Jednim z jeho runtime JARu > je webservices-extra.jar, ktery v sobe obsahuje Java Mail, > Java Activation, Java Annotations a kus Java Security. Bez > tohoto JARu Metro nejede, tudiz ho pribaluji k aplikaci. Proc > nejsou tyto dilci knihovny distribuovany jako oddelene JARy - > standardni activation.jar, mail.jar, annotations.jar + zminka > v Metro dokumentaci jaka verze ceho je pro beh potreba? Toto > zpusobuje to, ze neni snadne Metro nasadit v prostredi, ktere > jiz treba activation API a mail API poskytuje ze sveho > runtimu (v mem pripade JBoss AS). Resim tak, ze z Metra JARu > odmazavam prislusna API, abych se vyhnul kolizim s runtime > knihovnami AS, coz je neudrzitelne. > > Toto jde preci proti konceptu spravy zavislosti, kdy je > potreba z principu zavislosti oddelovat a ne slucovat. > > Asi placu na nespravnem hrobe :) Diky za pripadna osvetleni. > Honza > > >
