Axis2 jsem zkousel jen velmi letmo a take jsem tam narazil na problemy kolem
generovani JAXB2 bindingu (tusim u dedicnosti typu). Takze jsem se s Axis2
zahy rozloucil. Taky me u neho nenadchnul ten (pravda volitelny) deployment
model (proprietarni aar archivy).
ad 1) S JAXBContext nijak u ws manipulovat nemusim, serializace a
deserializace se deje pod poklickou toho ws stacku a tak by to melo IMO byt.
S JAXBContext bastlim jen pokud potrebuji rucne delat
serializace/deserializace. Koukam, ze s tema potomkama jsem na to taky
narazil :)
===
...
List<Class> boundClasses = new ArrayList<Class>( 2 );
boundClasses.add( AjaxResultType.class );
// due to some JAXB2 weirdness, it is necessary to add the concreate
result data class
// so that JAXB2 is able to handle it...
if ( result.getData() != null )
{
boundClasses.add( result.getData().getClass() );
}
JaxbHelper jaxb = JaxbHelper.newInstance( boundClasses );
===
Jinak ve svym WSDL pouzivam par abstraktnich+vydedenych typu (hlavne pro
navratove hodnoty ) a Metro s nimi pracuje dle ocekavani. Nezkoumal jsem jak
presne vyse uvedeny problem Metro interne resi, jsem rad ze to nemusim v
aplikaci resit :-)
ad 2) Jj, to je taky na JAXB2 sympaticke, ze podporuje moznost definovat
vlastni konvertory/formatery pro datove typy. Taky je u nej prijemna moznost
generovat pomoci xjc tzv. epoch soubor pro sdilene typy a pak tento soubor
vyuzivat u wsdl2java (wsimport u Metra) bez toho, ze by wsdl2java ty typy
pregenerovavalo opakovane pro kazde zpracovavane WSDL, ktere ty typy
vyuziva.
Honza
-----Původní zpráva-----
Od: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] za
uživatele Podlesak Kamil
Odesláno: Wednesday, August 20, 2008 10:17
Komu: Java
Předmět: RE: webservices, JAXB2
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
>
>
>
