jaxb - default vytvaranie instancii complexType
Ahoj. Zapasim s jaxb. Mam nasledovne xsd: xsd:element name=config xsd:complexType xsd:sequence xsd:element name=tst type=tns:test_ct nillable=true / /xsd:sequence /xsd:complexType /xsd:element xsd:complexType name=test_ct xsd:sequence xsd:element name=a type=xsd:string nillable=true/ /xsd:sequence /xsd:complexType ... z ktoreho vznika class-a Config. Problem je, ze v nasledovnom kode: Config c = new Config(); c.getTst().setA(a); dostavam null exception, pretoze getTst() vrati null. Da sa nejak jaxb donutit, aby defaultne vytvoril instanciu typu test_ct? Dik -- Dusan ... tykajte mi
OffTopic: SVN dotaz
Ahoj, mám dotaz k větvení a mergeování v SVN. Mám projekt Projekt/trunk, vytvořím si větev pomocí svn copy, například Projekt/branches/krtek. Switchnu se a normálně pracuju. A teď - Book of SVN doporučuje sem tam provést merge s hlavní větví (promítnout změny z hlavní větve) pomocí [code] svn merge svn://svn.krtek.cz/Projekt/trunk [/code] Merge proběhne úspěšně, na výstupu jsou pouze soubory, které se měnily - ať už v mojí nebo v hlavní větvi. Následující svn status, ale ukáže M u velkého množství souborů, které se neměnily ani v mojí, ani v hlavní větvi. Pokud zkusím svn diff, dozvím se, že se soubory liší v mergeinfo: [code] Property changes on: module_xx/src/main/database ___ Modified: svn:mergeinfo Merged /Projekt/trunk/module_xx/src/main/database:r8268-8308 [/code] Takže potom commituju místo pár změn desítky souborů - tím pádem se dost bojím vrátit tu větev do trunku pomocí svn merge --reintegrate (opět Book of SVN). A teď dotaz - je to normální? Stává se vám to taky? Díkes, L.
Re: Verzovanie webových služieb
Ahoj. Tiez nie som v tejto veci profik, ale skusim dat par postrehov. 1. zmena struktury v db, alebo cokolvek v podvozku Pokial oddelis podvozok od webservice ( napr. pomocou ejb ), tak zmena sql dotazov bude nutna len v tom danom ejb. Webservicy sa o zmene nemusia vobec dozvediet. Toto sa da tusim naklikat v netbeans, je to webservice from existing java bean, alebo take daco. Vyhodou je, ze ten podvozok mozes za behu servera menit bez zastavenia sluzieb. 2. Zmena API danej webservice ... znamena, ze sa jedna o uplne novu webservice. Imho jedina moznost ako prevadzkovat ws so starym a novym api su 2 samostatne ws. Ja osobne to robim tak, ze cislo verzie ws je sucastou url. Neviem, ako inak a ci vobec by sa to dalo obist. Ciste teoreticky ma napada nejaka specialna http proxy, ktora by zo soap message urcila, o akeho klienta sa jedna a nasledne transparentne presmerovala request na ws spravnej verzie. To je ale z rise rozpravok, takze s5 na zem. 3. Zmena API podvozku Ak potrebujes zmenit API pod tou ws, vsetko zavisi na tom, o aku zmenu pojde. Niekedy nebudes musiet do ws vobec hrabat a pokial aj ano, zmenis nanajvys par riadkov. Urcite existuju este nejake sofistikovanejsie sposoby, dal som len hruby nacrt, povolanejsi nech sa vyjadria. Čo všetko bude treba verzovať 1.zdrojový kód - používame SVN, takže jednotlivé verzie by sa riešili formou vetiev. 2.WSDL 3.XSD Wsdl aj xsd mozu byt v svn, nie? -- Dusan ... tykajte mi
Re: jaxb - default vytvaranie instancii complexType
Resp. opytam sa inak: Vytvaram spravne instanciu Config() pomocou operatora new? Pohladom do kodu vidim, ze vygenerovane classy neobsahuju ziaden kod, len deklaracie a kopu @XmlElement, takze imho by som mal pouzit jaxb, ale neviem ako. Ahoj. Zapasim s jaxb. Mam nasledovne xsd: xsd:element name=config xsd:complexType xsd:sequence xsd:element name=tst type=tns:test_ct nillable=true / /xsd:sequence /xsd:complexType /xsd:element xsd:complexType name=test_ct xsd:sequence xsd:element name=a type=xsd:string nillable=true/ /xsd:sequence /xsd:complexType ... z ktoreho vznika class-a Config. Problem je, ze v nasledovnom kode: Config c = new Config(); c.getTst().setA(a); dostavam null exception, pretoze getTst() vrati null. Da sa nejak jaxb donutit, aby defaultne vytvoril instanciu typu test_ct? Dik -- Dusan ... tykajte mi
Re: OffTopic: SVN dotaz
Zdravím, To mergeinfo obsahuje právě informaci o tom, že došlo k merge. Při zpětném merge do trunku s tím pracuje a tyto změny (které již v trunku samozřejmě jsou) ignoruje. Samozřejmě by stačilo aby ten mergeinfo byl nastaven jen na jediném místě (kořenovém adresáři). Že to cpe všude možně a pak vznikají obludně vypadající logy, to je jen jeden z problémů které celý tento nepříliš podařený experiment má. Kamil Podlešák 2009/11/11 Lukáš Marek lukas.ma...@cleverlance.com: Ahoj, mám dotaz k větvení a mergeování v SVN. Mám projekt Projekt/trunk, vytvořím si větev pomocí svn copy, například Projekt/branches/krtek. Switchnu se a normálně pracuju. A teď - Book of SVN doporučuje sem tam provést merge s hlavní větví (promítnout změny z hlavní větve) pomocí [code] svn merge svn://svn.krtek.cz/Projekt/trunk [/code] Merge proběhne úspěšně, na výstupu jsou pouze soubory, které se měnily - ať už v mojí nebo v hlavní větvi. Následující svn status, ale ukáže M u velkého množství souborů, které se neměnily ani v mojí, ani v hlavní větvi. Pokud zkusím svn diff, dozvím se, že se soubory liší v mergeinfo: [code] Property changes on: module_xx/src/main/database ___ Modified: svn:mergeinfo Merged /Projekt/trunk/module_xx/src/main/database:r8268-8308 [/code] Takže potom commituju místo pár změn desítky souborů - tím pádem se dost bojím vrátit tu větev do trunku pomocí svn merge --reintegrate (opět Book of SVN). A teď dotaz - je to normální? Stává se vám to taky? Díkes, L.
Re: jaxb - default vytvaranie instancii complexType
A co by měly obsahovat za kód? Vytváření přes new je samozřejmě správně. Co se týká defaultní hodnoty, myslím že to nejde. Kamil Podlešák 2009/11/11 Dusan Zatkovsky msk.c...@gmail.com: Resp. opytam sa inak: Vytvaram spravne instanciu Config() pomocou operatora new? Pohladom do kodu vidim, ze vygenerovane classy neobsahuju ziaden kod, len deklaracie a kopu @XmlElement, takze imho by som mal pouzit jaxb, ale neviem ako. Ahoj. Zapasim s jaxb. Mam nasledovne xsd: xsd:element name=config xsd:complexType xsd:sequence xsd:element name=tst type=tns:test_ct nillable=true / /xsd:sequence /xsd:complexType /xsd:element xsd:complexType name=test_ct xsd:sequence xsd:element name=a type=xsd:string nillable=true/ /xsd:sequence /xsd:complexType ... z ktoreho vznika class-a Config. Problem je, ze v nasledovnom kode: Config c = new Config(); c.getTst().setA(a); dostavam null exception, pretoze getTst() vrati null. Da sa nejak jaxb donutit, aby defaultne vytvoril instanciu typu test_ct? Dik -- Dusan ... tykajte mi
Re: Verzovanie webových služieb
Zdravim, zaujimava publikacia na danu temu je: Thomas Erl - Web Service Contract Design and Versioning for SOA http://www.amazon.com/Web-Service-Contract-Design-Versioning/dp/013613517X/ref=sr_1_2?ie=UTF8s=booksqid=1257957547sr=1-2 vseobecne postupy a patterny ktore su tam uvedene sa zhoduju s tym co chcete riesit aj vy. Michal Lašák wrote / napísal(a): Zdravím konferenciu! Píšem diplomovú prácu, ktorej téma je zhodná s názvom predmetu tejto správy, teda Verzovanie webových služieb. Pravdupovediac, mám s daným problémom minimum praktických skúseností. Práve preto by som chcel poprosiť vás, odborníkov, o zopár cenných informácií. K riešeniu tejto problematiky ma viedla situácia vo firme, v ktorej pracujem. Budujeme webové služby, ktoré majú za cieľ sprostredkovať komunikáciu medzi informačným systémom (IS) a eshopmi. Platforma, na ktorej WS budujeme, je Java a ako aplikačný server nám slúži JBoss. Teraz k samotnému problému. Pri výmene verzie IS sa často mení DB štruktúra, preto musíme na dané zmeny reagovať upravením zdrojového kódu webovej služby (úprava SQL dotazov, prepared statementov...). Ďalší typ zmien je úprava stávajúcich algoritmov vo WS, prípadne nová funkcionalita. V jednom momente existuje viacero klientov s rôznymi verziami IS. Webová služba momentálne beží na aplikačnom serveri len ako 1 WAR inštancia (väčšina klientov totižto hosťuje priamo vo firme) a WS pracuje vlastne ako centrálny článok pre všetky eshopy (líšia sa len data sourcom, na ktorý sa WS pripája). Preto som chcel nájsť čo najlepší spôsob, ako začať WS verzovať, aby som čo najjednoduchšie vedel udržovať jej zdrojový kód (ideálny stav by bola stále jedna a jediná inštancia WS bežiaca v aplikačnom serveri - čo som zistil, že bude NEMOŽNÉ) a aplikácie by bežali bez problémov u každého z klientov (resp. s minimom zmien nutných na strane zákazníka). Začal som teda bližšie pátrať na internete. Dosť ma prekvapil fakt, že žiadne oficiálne stanovisko k verzovaniu WS neexistuje, našiel som len best-practices. Dospel som zatiaľ k nasledovným bodom: Čo všetko bude treba verzovať 1.zdrojový kód - používame SVN, takže jednotlivé verzie by sa riešili formou vetiev. 2.WSDL 3.XSD Deployment z hľadiska zdrojákov a riešenie problémov s class loadingom 1.Každá verzia do zvláštneho EAR súboru 2.Jeden EAR s viacerými WAR súbormi (1 WAR = 1 verzia) - každá verzia by musela mať vlastný class loader 3.Premenovanie packagov v Jave pri vzniku novej verzie (de-facto nová služba s novými triedami) - automaticky zavrhujem 4.Použitie špecializovaných riešení, napr. OSGI - obtiažnosť? oplatí sa? -- mám s tým nulové skúsenosti Kedy sa budú vytvárať nové verzie = pri každej zmene, ktorá môže mať dopad na konzumenta služby = major changes = odstránenie operácie, premenovanie operácie, zmena parametrov operácie (dátový typ, poradie), zmena komplexného dátového typu v XSD = pozor na implementačné zmeny, ktoré zvonka nevidíme: validácie vstupu/výstupu, security credentials, porušenie SLA (napr. náročnejším algoritmom sa zväčší doba vykonania) Nasadzovanie WS + volanie služieb zo strany konzumenta - nasadzovať všetko na jeden endpoint alebo použiť pravidlo nová verzia = nový endpoint - priamy prístup k endpointom alebo použitie routera, ktorý bude smerovať požiadavky podľa identifikátora (IP, parameter verzie v URL...) - použitie UDDI registra Apache jUDDI Zaujímalo by ma, či máte skúsenosti s niektorými zo spomínaných bodov. Budem veľmi vďačný za akékoľvek informácie, s ktorými sa podelíte. Ďakujem za ochotu. S pozdravom --ml Michal Lašák __ Informacia od ESET Smart Security, verzia databazy 4592 (20091110) __ Tuto spravu preveril ESET Smart Security. http://www.eset.sk
RE: jaxb - default vytvaranie instancii complexType
Vytvaram spravne instanciu Config() pomocou operatora new?
Ano, tak je to v java zvykem.
Ale s JAXB to nema vubec nic spolecneho.
Pohladom do kodu vidim, ze vygenerovane classy neobsahuju ziaden kod,
len
deklaracie a kopu @XmlElement, takze imho by som mal pouzit jaxb, ale
neviem
ako.
To je v poradku, ty anotace jsou pouzity az pri vlastnim nacitani/ukladani XML
dokumentu.
Problem je, ze v nasledovnom kode:
Config c = new Config();
c.getTst().setA(a);
dostavam null exception, pretoze getTst() vrati null.
Asi jste si to v konstruktoru Config() nezaridil, aby metoda getTst() inicialne
nevracela null.
Chtel jste si nejakou javovskou instanci zapsat do XML?
Pak si ji musite nejak spravne vytvorit.
Config c = new Config();
je spravny, avsak asi prilis maly krok.
Dale pripojuji prvni pomoc pro praci s JAXB:
Zápis do XML provedeme takto (řekněme, že v data máme
instanci Struktura):
JAXBContext context = JAXBContext.newInstance(Struktura.class);
context.createMarshaller().marshal(data, System.out);
Zapíše se komplet celá struktura i s vnořenými třídami.
Komu by se nelíbilo XML na jednom řádku, může si výstup vylepšit:
JAXBContext context = JAXBContext.newInstance(Struktura.class);
Marshaller marshaller = context.createMarshaller();
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT,
true);
marshaller.marshal(data, System.out);
Načtení z XML je rovněž velmi velmi jednoduché:
JAXBContext context = JAXBContext.newInstance(Struktura.class);
Struktura data =
(Struktura)context.createUnmarshaller().unmarshal(new
FileInputStream(test.xml));
Takto ale načteme bez kontroly, že XML odpovídá danému schématu (XSD).
Co je však paráda, tak že XSD zvládneme vygenerovat i z daného POJO:
JAXBContext context = JAXBContext.newInstance(Struktura.class);
final ListDOMResult results = new ArrayListDOMResult();
context.generateSchema(
new SchemaOutputResolver() {
@Override
public Result createOutput(String ns, String file) throws
IOException {
DOMResult result = new DOMResult();
result.setSystemId(file);
results.add(result);
return result;
}
});
DOMResult domResult = results.get(0);
Document doc = (Document) domResult.getNode();
OutputFormat format = new OutputFormat(doc);
format.setIndenting(true);
XMLSerializer serializer = new XMLSerializer(new
FileOutputStream(test.xsd), format);
serializer.serialize(doc);
A dané XSD pak můžeme při načítání použít třeba takto:
JAXBContext context = JAXBContext.newInstance(Struktura.class);
Unmarshaller unmarshaller = context.createUnmarshaller();
SchemaFactory schemaFactory =
SchemaFactory.newInstance(http://www.w3.org/2001/XMLSchema;);
Schema schema = schemaFactory.newSchema(new File(test.xsd));
unmarshaller.setSchema(schema);
Struktura data =
(Struktura)context.createUnmarshaller().unmarshal(new
FileInputStream(test.xml));
Snad Vam to pomuze.
M.
RE: Verzovanie webových služieb
Zdravim, dakujem za tip. Tato publikacia je uz momentalne objednana mojou veducou DP, takze som velmi rad, ze mi pomoze. --ml From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf Of Richard Holly Sent: Wednesday, November 11, 2009 5:43 PM To: Java Subject: Re: Verzovanie webových služieb Zdravim, zaujimava publikacia na danu temu je: Thomas Erl - Web Service Contract Design and Versioning for SOA http://www.amazon.com/Web-Service-Contract-Design-Versioning/dp/013613517X/r ef=sr_1_2?ie=UTF8 http://www.amazon.com/Web-Service-Contract-Design-Versioning/dp/013613517X/ ref=sr_1_2?ie=UTF8s=booksqid=1257957547sr=1-2 s=booksqid=1257957547sr=1-2 vseobecne postupy a patterny ktore su tam uvedene sa zhoduju s tym co chcete riesit aj vy.
Re: Verzovanie webových služieb
Hmmm. Dobrý námět na qalitní blog-post, třeba mne to donutí zase otevřít ORESTování... Zkusím být teďka stručný: verzování ve světě WebServis, o kterém mluvíš, je třeba rozlišit do několika kategorií podle způsobu řešení a čeho tím chceme dosáhnout: a) jsme na konferenci o Javě, takže začnu tady: typické řešení verzování v Javě ala RMI, tedy s přístupem class-WSDL. Kdo chce danou věc řešit na bázi Mám třídu, doplním anotace, udělám instanci a vypublikuji, jediné řešení je KOMPLETNÍ oddělení classloaderů - nemusí jít pouze o konkrétní třídu, ale může se změnit verze knihovny,... Takže přímočaré řešení je rozstřílet do WARů, každé vlastní endpoint. Prostě EJB jak vyšité. verzí ze světa WS je hafo zkusím je letmo načrtnout. Nejdřív je nutné si zodpovědět PROČ vlastně řešímě novou verzi plus pár dalších otázek a 1) mění se jenom pajšl a to drobně - pak není nutné dávat světu vědět, že se něco změnilo - prostě jenom nahradíme starou implementaci tou novou 2) měníme výrazně vlastní chování - mění se chování při stejných datech, nebo je změna pouze pro nová? Aneb stačí zpětná kompatibilita či nikolivěk? 3) měníme datové schema - mění se výrazně schéma a mohlo by tedy znemožnit starším klientům v používání nové verze, nebo se jedná jen o rozšíření a opět stačí pouze zpětná kompatibilita? 4) Budou novou verzi využívat pouze nové verze klientů, nebo i ti stávající? Teď něco o teorii, konkrétně o pojmu Kontrakt - klíčový termín pro verzování. Na něm totiž závisí řešení (jeho qalita). Pod kontraktem rozumíme: A) způsob, jakým klient zjišťuje cíl zprávy, kterou chce odeslat a na kterou očekává odpověď - možností je několik - natvrdo URL endpointu, přístup přes registry (typicku UDDI), broker, cíl je v obsahu zprávy (třeba WS-Addressing) B) těsnost vazby na data - jedná spíše o JAX-RCP, DocLit, nebo RESTový message bus? C) sémantická závislost - vyžaduje klient naprosto přesné chování WebServisy či nikolivěk? a teď k těm řešením, nebo vlastně doporučením: b) maximálně zastřít verzi před klientem. Tedy navrhnout celou architekturu tak, aby klienti i WebServisy byly co nejvíce autonomní a nevyžadovali přesné chování druhých stran; co nejvíce rozhodovací logiky přenést na příjemce zprávy; napsat každou servisu tak, aby si dokázala poradit se změnami schématu a rozšířením logiky To znamená stabilní endpointy ve stabilních volných kontraktech. c) dalším zastíracím manévrem je před různé verze implementací předřadit brokera - tedy WebServisu, která akceptuje různé formáty dat v různých požadavcích a sama se rozhoduje, kdo bude zavolán. Díky tomu, že logika správy různých verzí by se měla řešit samoregistrováním se WebServis, nikoli zakódovávat do zdrojáku, je vhodné tento broker implementovat jako Registry nebo se k ní připojovat. Vhodným kandidátem k použití se jeví UDDI nebo něco trošičku více sofistikovaného (jako například HP SOA Center https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=btocp=1-11-130-27_4000_100__ [ano, přihřívám si vlastní polívčičku, já vím, ale když na tomto produktu jsem se podílel nejen vývojářsky, ale i malinko architektonicky... :-)] ) d) když už je třeba verzovat i směrem ke klientům, tak bych se držel starého osvědčeného BuzzWordu Provisioning. Poskytnout klientům možnost říct si, co chtějí. Velmi se mi líbí, jak tento problém vyřešili ve specce UDDI - jedno jediné WSDL, které includuje namespacem oddělené verze. Ve spojení s registry je to správné použití. Když už tedy zveřejňujeme verze ven, umožněme klientovi, aby si mohl vybrat. Je tedy třeba onu informaci o verzi nějak dohledatelně vypublikovat. A to buď ve formě metadat držených v nějaké registry, nebo ve formě množiny WSRF endpointů, kde si každý endpoint ve svých atributech verzi propaguje. Udržovat znalost o verzích na úrovni znalosti endpointů není verzování, ale pasqil. e) z déčka přímo vyplývá způsob verzování datové struktury - namespace f) je také si potřeba uvědomit, zda nová verze už není jinou servisou se společnou implementační částí. Dost často to tak totiž je. Ano, toto velmi zavání problémy s udržováním obrovského množství WebServis. Jenomže když je špatně navržený kontrakt, dost často ani jiná možnost není - jednou jsem viděl košatý acyklický graf verzí téže WebServisy. Různé větvení a spojování verzí bylo pímo k zblití. A přitom to šlo jednoduše rozdělit do několika málo různých WebServis, které pod sebou využívaly opět několik málo sdílených ... Fuj, to jsem se rozkecal, už raději skončím a zkusím to, až bude čas, sesumírovat si a někde to shrnout. Oto 'tapik' Buchta 2009/11/10 Michal Lašák mla...@gmail.com: Zdravím konferenciu! Píšem diplomovú prácu, ktorej téma je zhodná s názvom predmetu tejto správy, teda Verzovanie webových služieb. Pravdupovediac, mám s daným problémom minimum praktických skúseností. Práve preto by som chcel poprosiť vás, odborníkov, o zopár cenných informácií. K riešeniu tejto problematiky ma viedla situácia vo firme, v ktorej pracujem. Budujeme
RE: Verzovanie webových služieb
Zdravim. 1.zmena struktury v db, alebo cokolvek v podvozku Pokial oddelis podvozok od webservice ( napr. pomocou ejb ), tak zmena sql dotazov bude nutna len v tom danom ejb. Webservicy sa o zmene nemusia vobec dozvediet. Toto sa da tusim naklikat v netbeans, je to webservice from existing java bean, alebo take daco. Vyhodou je, ze ten podvozok mozes za behu servera menit bez zastavenia sluzieb. Ano, dakujem za dobry postreh. Problemom ostava to, ze problem verzovania posuniem z WS casti do EJB casti. Dalsie instacie WS so zhodnym API budem musiet potom bundlovat spolu s roznymi verziami EJB (predpokladam, ze asi ako EAR aplikaciu). Nie je mi celkom zrejme, ako by sa to dalo upgradnut bez zastavenia sluzieb (ak teda nedeployujem novy EAR, ale chcel by som napr. upgradnut cisto len EJB). Mohol by si mi to prosim trosku upresnit? Asi som ta spravne nepochopil. 2.Zmena API danej webservice ... znamena, ze sa jedna o uplne novu webservice. Imho jedina moznost ako prevadzkovat ws so starym a novym api su 2 samostatne ws. Ja osobne to robim tak, ze cislo verzie ws je sucastou url. Neviem, ako inak a ci vobec by sa to dalo obist. Ciste teoreticky ma napada nejaka specialna http proxy, ktora by zo soap message urcila, o akeho klienta sa jedna a nasledne transparentne presmerovala request na ws spravnej verzie. To je ale z rise rozpravok, takze s5 na zem. Ano, zmena URL sa mi zda ako najjednoduchsie riesenie. Co som nasiel na internete, tak pomocou by mohlo zevraj UDDI, pripadne existuju asi nejake komercne riesenia (nasiel som nieco specialne od Oraclu co robi prave routing a dokonca vytvara aj adapter medzi roznymi verziami sluzieb). Momentalne mam postavene provizorne riesenie na baze, ze klient posle svoj identifikator a my interne mame v DB ulozene, na akej verzii bezi a podla toho sa zariadime. 3.Zmena API podvozku Ak potrebujes zmenit API pod tou ws, vsetko zavisi na tom, o aku zmenu pojde. Niekedy nebudes musiet do ws vobec hrabat a pokial aj ano, zmenis nanajvys par riadkov. Mna budu trapit hlavne zmeny, ktore budu suvisiet s WS a ich dopad na konzumentov. Cize co najmenej zasahov do volani sluzieb zo strany klienta atp. --ml
Re: jaxb - default vytvaranie instancii complexType
Mozno by si mohol postupovat opacne. Namiesto schemy zacnes pisat POJO objekty s JAXB anotaciami. V konstruktore triedy Config si sam zadefinujes new Tst() a mas po probleme. Ak schemu potrebujes kvoli validacii XML-iek, mozes si ju vygenerovat z POJO objektov (ako uviedol pan Polak). Radka --- On Wed, 11/11/09, Dusan Zatkovsky msk.c...@gmail.com wrote: From: Dusan Zatkovsky msk.c...@gmail.com Subject: jaxb - default vytvaranie instancii complexType To: konference@java.cz Date: Wednesday, November 11, 2009, 2:57 PM Ahoj. Zapasim s jaxb. Mam nasledovne xsd: xsd:element name=config xsd:complexType xsd:sequence xsd:element name=tst type=tns:test_ct nillable=true / /xsd:sequence /xsd:complexType /xsd:element xsd:complexType name=test_ct xsd:sequence xsd:element name=a type=xsd:string nillable=true/ /xsd:sequence /xsd:complexType ... z ktoreho vznika class-a Config. Problem je, ze v nasledovnom kode: Config c = new Config(); c.getTst().setA(a); dostavam null exception, pretoze getTst() vrati null. Da sa nejak jaxb donutit, aby defaultne vytvoril instanciu typu test_ct? Dik -- Dusan ... tykajte mi
