Spise by me zajimalo porovnani s Axis2, ten ted momentalne pouzivame a nic 
extra (tedy, rozhodne mnohem lepsi nez Axis1). Hlavne me zklamalo ze 
nepodporuje keepalive (upozorneni pro naivni: neverte dokumentaci! pouzijte 
zdrojaky) a prace s JAXB2 obsahuje nekolik zavaznych pasti.
 
Rad bych upozornil hlavne na dve veci, mozna to nekdy nekomu pomuze:
 
1) Pokud schema pouziva ve vetsi mire dedicnost typu, davejte pozor pri 
vytvareni JAXBContext aby obsahoval opravdu vsechny tridy ktere se tam mohou 
vyskytout. Nestaci dat tam jen tridy parametru a vysledku dane sluzby - pokud 
totiz nejaky takovy parametr obsahuje tridu s potomky, uz nema moznost jak si 
najit dane potomky. Vysledkem pak je, ze pri serializaci do XML vytvori prave 
toho predka a veskere pridane elementy/atributy z potomka vynecha.
Docela by me zajimalo, zda s timto problemem Metro/CXF/neco jineho pocita nebo 
ne.
 
2) Pro reprezentaci casovych udaju se pouziva XMLGregorianCalendar. Jeho 
implementace ovsem nemusi byt vzdy Serializable (zdravime IBM), coz je docela 
problem pri pouziti EJB. Nastin reseni je opet u Koshukeho
  http://weblogs.java.net/blog/kohsuke/archive/2006/03/how_do_i_map_xs.html
ale castecne typy jako xsd:gYear, xsd:gMonth a podobne si clovek musi napsat 
sam.
 
 
Kamil "podlesh" Podlesak
 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jan Moravec
Sent: Tuesday, August 19, 2008 11:24 PM
To: 'Java'
Subject: RE: Monoliticke JARy (napr. Metro webservices-extra.jar)


Ten maly pocet JARu v Metro se mi taky libi. Az na ten moloch JAR naprosta 
spokojenost. Mluvim ted primarne o pouzitelnosti. Me zkusenosti s Metro vs CXF:
 
1) CXF je dost tezkotonazni bundle s mnoha zavislostmi (zvlaste mi vadi 
integrovany Spring) = neprehledne. V dusledku mi treba runtime CXF pri pokusu 
spustit klienta zacal startovat web-service (tj. serverovou cast) - a to 
nejspise jen diky tomu, ze nekde v classpath nalezl XML konfiguracni soubor te 
web-servicy - toto chovani me moc nenadchlo :( S Metrem zadny problem.
 
2) Metro podporuje JAXB2 binding, ktery pokladam za suverene 
nejlepsi/nejpouzitelnejsi Java<->XML produkt. Skoda, ze jsem propasl Koshukeho 
na CZJUGu... :(  CXF sice take JAXB2 binding podporuje, ale jeho wsdl2java 
vyhorel i na relativne jednoduchem WSDL, ktere Metro hrave zkousne (a 
predchudce CXF tedy XFire s nim take nemel problemy).
 
3) Jo jeste si vybavuji jednu vec. CXF ma command-linovy wsdl2java, ovsem 
prislusny Anti task uz nejak nedotahli, protoze podporuje jen asi 20% moznych 
parametru toho commandline nastroje. Metro - zadny problem, wsimport funguje v 
obou podobach stejne, navic podporuje XML catalogy (jsem nadsen).
 
Honza
 
-----Původní zpráva-----
Od: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] za uživatele Ladislav Thon
Odesláno: Tuesday, August 19, 2008 21:11
Komu: Java
Předmět: Re: Monoliticke JARy (napr. Metro webservices-extra.jar)






Prace s knihovnamy (resp. naprosta absence funkcni koncepce knihoven) je asi 
nejvetsi problem Javy jako platformy.


Naprostý souhlas, Global Assembly Cache a verzování jako základní součást 
platformy můžeme .NETistům jenom závidět.

S tím Metrem mne to teď pěkně zarazilo. Vybral jsem si ho mimo jiné kvůli 
malému množství JARů a triviální instalaci -- srov. třeba s CXF --, a teď se 
dozvím tohle. Při vývoji jsem zatím na nic nenarazil, takže už se těším na 
problémy při produkčním nasazení :-(

LT
 



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
>
>
>



Odpovedet emailem