JAX-WS requiere que todas las clases que se transmiten tengan un contructor predeterminado (constructor no-arg). No entiendo ese requisito porque los clientes crean sus propias clases basadas en el WSDL. IMO este requisito tiene sentido solo para aquellas clases que se usan como parámetros de entrada del servicio web.¿Por qué se requiere un constructor predeterminado para los objetos exportados por una JAX-WS?
¿Alguien sabe cómo eludir ese requisito?
Cuando se utiliza JAX-WS está utilizando un JAXB aplicación para serializar los objetos de Java para XML .
Entonces, el 'problema' es cómo funciona JAXB.
Para utilizar JAXB , es necesario crear un JAXBContext pasándolo todas las clases que pueden ser movilizados/unmarshaled. Al crear el contexto, JAXB comprobará que todas las clases dadas tengan un constructor no-arg. Si al menos una de esas clases no tiene este tipo de constructor, el contexto no se creará.
¿Por qué JAXB hacer esto? Necesita este constructor no arg SOLAMENTE cuando se transforma de XML a Object (desmaterialización), pero el problema es que cuando se crea el contexto, JAXB no sabe lo que se quiere hacer (¡mariscal o unmarshal)!
Conclusión: JAXB aceptará solo las clases que pueda reunir Y anular. Más información here
Sabiendo esto, ¿qué ocurre en JAX-WS?
Cuando se declara una @WebMethod los parámetros se añadirán y valor de retorno clases a un contexto JAXB. Y es debido a esto que todas las clases relacionadas con la entrada y salida de un servicio web necesitan un constructor sin argumentos.
Conclusión: es culpa JAXB ;-)
Pero lo que si necesito utilizar una clase que no tiene un constructor sin argumentos?
Puede usar un XMLAdapter! Consulte this post para obtener más información ...
¿Alguien sabe cómo eludir ese requisito?
Sí - reescribir JAX-WS.
Probablemente esté usando un ctor y una reflexión predeterminados para rellenar objetos, porque no puede conocer fácilmente todos los caracteres posibles que alguien como usted podría escribir.
Esto es un inconveniente de utilizar el marco de trabajo de otra persona: tiene que seguir sus reglas.
clientes a crear sus propias clases basado en el WSDL
pensé que eso es lo que la biblioteca ayudó a los clientes hacen. No escribió el código para analizar e interpretar el WSDL, ¿verdad?
Los objetos no deben estar ocupados por JAX-WS en el lado del servidor. JAX-WS solo los transmite. – Stefan
Por lo tanto, parece que el problema es que JAXB no distingue entre las clases que tiene para clasificar o desmarcar. Si esta característica era compatible, entonces JAX-WS podría construir un JAXBContext correspondiente. Creo que sería una buena solicitud de características para una próxima especificación JAXB. – Stefan
Estoy totalmente de acuerdo con usted. En realidad, los chicos de MOXy (una implementación JAXB de EclipseLink) tienen un boleto abierto para agregar compatibilidad con constructores de varias arias: https://bugs.eclipse.org/bugs/show_bug.cgi?id=328951 – ggarciao