JAX-WS richiede che tutte le classi trasmesse abbiano un contructor predefinito (costruttore no-arg). Non capisco questo requisito perché i clienti creano le proprie classi basate sul WSDL. IMO questo requisito ha senso solo per quelle classi che vengono utilizzate come parametri di input del servizio Web.Perché è richiesto un costruttore predefinito per oggetti esportati da un JAX-WS?
Qualcuno sa come aggirare questo requisito?
Quando si utilizza JAX-WS si utilizza un JAXB implementazione di serializzare gli oggetti Java per XML.
Quindi, il "problema" è come funziona JAXB.
Per utilizzare JAXB , è necessario creare un JAXBContext passaggio di esso tutte le classi che possono essere marshalling/eseguito l'unmarshalling. Quando si crea il contesto, JAXB verificherà che tutte le classi fornite abbiano un costruttore no-arg. Se almeno una di queste classi non ha questo tipo di costruttore, il contesto non verrà creato.
Perché JAXB fare questo? Ha bisogno di questo costruttore no-AR SOLO quando si trasforma da XML a Object (unmarshalling), ma il problema è quando si crea il contesto, JAXB non sa cosa si vuole fare (marshall o unmarshal)!
Conclusione: JAXB accetta solo le classi che può effettuare il marshalling e unmarshal. Maggiori informazioni here
Sapendo questo, cosa succede in JAX-WS?
quando si dichiara una @WebMethod i parametri saranno aggiunti e valore di ritorno classi ad un contesto JAXB. Ed è per questo che tutte le classi relative a un input e output di un servizio web hanno bisogno di un costruttore no-arg.
Conclusione: è colpa JAXB ;-)
Ma cosa succede se ho bisogno di usare una classe che non dispone di un costruttore no-arg?
È possibile utilizzare un Adattatore ! Controllare this post per ulteriori informazioni ...
Qualcuno sa come aggirare questo requisito?
Sì, riscrivi JAX-WS.
Probabilmente sta usando un ctor e una riflessione predefiniti per popolare gli oggetti, perché non può facilmente sapere su tutti i possibili operatori che qualcuno come te potrebbe scrivere.
Questo è uno svantaggio di usare il framework di qualcun altro: devi giocare secondo le loro regole.
clienti di creare le proprie classi sulla base del WSDL
ho pensato che è quello che la biblioteca ha aiutato i clienti fanno. Non hai scritto il codice per analizzare e interpretare il WSDL, vero?
Gli oggetti non devono essere popolati da JAX-WS sul lato server. JAX-WS li trasmette solo. – Stefan
Quindi il problema sembra essere che JAXB non distingue tra classi che deve eseguire il marshalling o unmarshal. Se questa funzione è supportata, JAX-WS potrebbe creare un JAXBContext corrispondente. Penso che farebbe una bella richiesta di funzionalità per una prossima specifica JAXB. – Stefan
Sono assolutamente d'accordo con te. In realtà i ragazzi di MOXy (un'implementazione JAXB di EclipseLink) hanno un ticket aperto per aggiungere il supporto per costruttori multi-arg: https://bugs.eclipse.org/bugs/show_bug.cgi?id=328951 – ggarciao