wsdllocation jax from example ejemplo crear cliente java netbeans client jax-ws

java - jax - wsdllocation relative path



Cliente JAX-WS: ¿cuál es la ruta correcta para acceder al WSDL local? (5)

La mejor opción es usar jax-ws-catalog.xml

Cuando compila el archivo WSDL local, anula la ubicación WSDL y configúrelo como algo parecido

http://localhost/wsdl/SOAService.wsdl

No se preocupe, esto es solo un URI y no una URL, lo que significa que no tiene que tener el WSDL disponible en esa dirección.
Puede hacer esto pasando la opción wsdllocation al compilador wsdl a java.

Al hacerlo, cambiará su código proxy de

static { URL url = null; try { URL baseUrl; baseUrl = com.ibm.eci.soaservice.SOAService.class.getResource("."); url = new URL(baseUrl, "file:/C:/local/path/to/wsdl/SOAService.wsdl"); } catch (MalformedURLException e) { logger.warning("Failed to create URL for the wsdl Location: ''file:/C:/local/path/to/wsdl/SOAService.wsdl'', retrying as a local file"); logger.warning(e.getMessage()); } SOASERVICE_WSDL_LOCATION = url; }

a

static { URL url = null; try { URL baseUrl; baseUrl = com.ibm.eci.soaservice.SOAService.class.getResource("."); url = new URL(baseUrl, "http://localhost/wsdl/SOAService.wsdl"); } catch (MalformedURLException e) { logger.warning("Failed to create URL for the wsdl Location: ''http://localhost/wsdl/SOAService.wsdl'', retrying as a local file"); logger.warning(e.getMessage()); } SOASERVICE_WSDL_LOCATION = url; }

Archivo de aviso: // cambiado a http: // en el constructor de URL.

Ahora viene en jax-ws-catalog.xml. Sin jax-ws-catalog.xml, jax-ws intentará cargar el WSDL desde la ubicación

http://localhost/wsdl/SOAService.wsdl y fallará, ya que no habrá WSDL disponible.

Pero con jax-ws-catalog.xml puede redirigir jax-ws a un WSDL empaquetado localmente siempre que intente acceder al WSDL @

http://localhost/wsdl/SOAService.wsdl .

Aquí está jax-ws-catalog.xml

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system"> <system systemId="http://localhost/wsdl/SOAService.wsdl" uri="wsdl/SOAService.wsdl"/> </catalog>

Lo que estás haciendo es decirle a jax-ws que cuando necesite cargar WSDL de

http://localhost/wsdl/SOAService.wsdl , debe cargarlo desde la ruta local wsdl / SOAService.wsdl.

Ahora, ¿dónde debería poner wsdl / SOAService.wsdl y jax-ws-catalog.xml? Esa es la pregunta del millón, ¿no?
Debe estar en el directorio META-INF de su jar de aplicación.

algo así

ABCD.jar |__ META-INF |__ jax-ws-catalog.xml |__ wsdl |__ SOAService.wsdl

De esta forma, ni siquiera tiene que anular la URL en su cliente que accede al proxy. El WSDL se recoge desde su JAR, y evita tener que tener rutas de sistema de archivos codificadas en su código.

Más información en jax-ws-catalog.xml http://jax-ws.java.net/nonav/2.1.2m1/docs/catalog-support.html

Espero que ayude

El problema es que necesito crear un cliente de servicio web a partir de un archivo que me han proporcionado. He almacenado este archivo en el sistema de archivos local y, mientras mantengo el archivo WSDL en la carpeta correcta del sistema de archivos, todo está bien. Cuando lo despliego en un servidor o elimino el WSDL de la carpeta del sistema de archivos, el proxy no puede encontrar el WSDL y se produce un error. He buscado en la web y he encontrado las siguientes publicaciones, pero no he podido hacerlo funcionar:
JAX-WS Cargando WSDL desde el contenedor
http://www.java.net/forum/topic/glassfish/metro-and-jaxb/client-jar-cant-find-local-wsdl-0
http://blog.vinodsingh.com/2008/12/locally-packaged-wsdl.html

Estoy usando NetBeans 6.1 (esta es una aplicación heredada que debo actualizar con este nuevo cliente de servicio web). Debajo está la clase de proxy JAX-WS:

@WebServiceClient(name = "SOAService", targetNamespace = "http://soaservice.eci.ibm.com/", wsdlLocation = "file:/C:/local/path/to/wsdl/SOAService.wsdl") public class SOAService extends Service { private final static URL SOASERVICE_WSDL_LOCATION; private final static Logger logger = Logger.getLogger(com.ibm.eci.soaservice.SOAService.class.getName()); static { URL url = null; try { URL baseUrl; baseUrl = com.ibm.eci.soaservice.SOAService.class.getResource("."); url = new URL(baseUrl, "file:/C:/local/path/to/wsdl/SOAService.wsdl"); } catch (MalformedURLException e) { logger.warning("Failed to create URL for the wsdl Location: ''file:/C:/local/path/to/wsdl/SOAService.wsdl'', retrying as a local file"); logger.warning(e.getMessage()); } SOASERVICE_WSDL_LOCATION = url; } public SOAService(URL wsdlLocation, QName serviceName) { super(wsdlLocation, serviceName); } public SOAService() { super(SOASERVICE_WSDL_LOCATION, new QName("http://soaservice.eci.ibm.com/", "SOAService")); } /** * @return * returns SOAServiceSoap */ @WebEndpoint(name = "SOAServiceSOAP") public SOAServiceSoap getSOAServiceSOAP() { return super.getPort(new QName("http://soaservice.eci.ibm.com/", "SOAServiceSOAP"), SOAServiceSoap.class); } /** * @param features * A list of {@link javax.xml.ws.WebServiceFeature} to configure on the proxy. Supported features not in the <code>features</code> parameter will have their default values. * @return * returns SOAServiceSoap */ @WebEndpoint(name = "SOAServiceSOAP") public SOAServiceSoap getSOAServiceSOAP(WebServiceFeature... features) { return super.getPort(new QName("http://soaservice.eci.ibm.com/", "SOAServiceSOAP"), SOAServiceSoap.class, features); } }


Este es mi código para usar el proxy:

WebServiceClient annotation = SOAService.class.getAnnotation(WebServiceClient.class); // trying to replicate proxy settings URL baseUrl = com.ibm.eci.soaservice.SOAService.class.getResource("");//note : proxy uses "." URL url = new URL(baseUrl, "/WEB-INF/wsdl/client/SOAService.wsdl"); //URL wsdlUrl = this.getClass().getResource("/META-INF/wsdl/SOAService.wsdl"); SOAService serviceObj = new SOAService(url, new QName(annotation.targetNamespace(), annotation.name())); proxy = serviceObj.getSOAServiceSOAP(); /* baseUrl; //classes/com/ibm/eci/soaservice //URL url = new URL(baseUrl, "../../../../wsdl/SOAService.wsdl"); proxy = new SOAService().getSOAServiceSOAP();*/ //updating service endpoint Map<String, Object> ctxt = ((BindingProvider)proxy ).getRequestContext(); ctxt.put(JAXWSProperties.HTTP_CLIENT_STREAMING_CHUNK_SIZE, 8192); ctxt.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, WebServiceUrl);

NetBeans puso una copia del WSDL en web-inf / wsdl / client / SOAService , por lo que no quiero agregarlo también a META-INF . Las clases de servicio están en WEB-INF / classes / com / ibm / eci / soaservice / y la variable baseurl contiene la ruta completa del sistema de archivos (c: / path / to / the / project ... / soaservice). El código anterior genera el error:

javax.xml.ws.WebServiceException: no se pudo acceder al WSDL en: file: /WEB-INF/wsdl/client/SOAService.wsdl. Error con: / WEB-INF / wsdl / client / SOAService.wsdl (no se puede encontrar la ruta)

Entonces, antes que nada, ¿debo actualizar la wsdllocation de la clase proxy? Entonces, ¿cómo le digo a la clase SOAService en WEB-INF / classes / com / ibm / eci / soaservice para buscar WSDL en / WEB-INF / wsdl / client / SOAService.wsdl?

EDITADO : Encontré este otro enlace - http://jianmingli.com/wp/?cat=41 , que dice que debe poner el WSDL en el classpath. Me da vergüenza preguntar: ¿cómo lo incluyo en el classpath de la aplicación web?

Muchas gracias por la respuesta de Bhaskar Karambelkar que explica en detalle y solucionó mi problema. Pero también me gustaría volver a formular la respuesta en tres sencillos pasos para alguien que tiene prisa por arreglar

  1. Haga su referencia de ubicación local wsdl como wsdlLocation= "http://localhost/wsdl/yourwsdlname.wsdl"
  2. Crea una carpeta META-INF justo debajo del src. Coloque sus archivos wsdl en una carpeta bajo META-INF, diga META-INF / wsdl

  3. Cree un archivo xml jax-ws-catalog.xml bajo META-INF como se muestra a continuación

    <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system"> <system systemId="http://localhost/wsdl/yourwsdlname.wsdl" uri="wsdl/yourwsdlname.wsdl" /> </catalog>

Ahora empaca tu jar. No más referencias al directorio local, todo está empaquetado y referenciado dentro de

Otro enfoque que hemos tomado con éxito es generar el código de proxy de cliente WS usando wsimport (desde Ant, como una tarea Ant) y especificar el atributo wsdlLocation.

<wsimport debug="true" keep="true" verbose="false" target="2.1" sourcedestdir="${generated.client}" wsdl="${src}${wsdl.file}" wsdlLocation="${wsdl.file}"> </wsimport>

Como ejecutamos esto para un proyecto con múltiples WSDL, la secuencia de comandos resuelve dinámicamente el valor $ (wsdl.file) que está configurado para ser /META-INF/wsdl/YourWebServiceName.wsdl relativo a la ubicación de JavaSource (o / src, dependiendo de cómo haya configurado su proyecto). Durante el proceso de compilación, los archivos WSDL y XSD se copian a esta ubicación y se empacan en el archivo JAR (similar a la solución descrita anteriormente por Bhasakar)

MyApp.jar |__META-INF |__wsdl |__YourWebServiceName.wsdl |__YourWebServiceName_schema1.xsd |__YourWebServiceName_schmea2.xsd

Nota: asegúrese de que los archivos WSDL utilicen refrerencias relativas a cualquier XSD importado y no a las URL de http:

<types> <xsd:schema> <xsd:import namespace="http://valueobject.common.services.xyz.com/" schemaLocation="YourWebService_schema1.xsd"/> </xsd:schema> <xsd:schema> <xsd:import namespace="http://exceptions.util.xyz.com/" schemaLocation="YourWebService_schema2.xsd"/> </xsd:schema> </types>

En el código generado , encontramos esto:

/** * This class was generated by the JAX-WS RI. * JAX-WS RI 2.2-b05- * Generated source version: 2.1 * */ @WebServiceClient(name = "YourService", targetNamespace = "http://test.webservice.services.xyz.com/", wsdlLocation = "/META-INF/wsdl/YourService.wsdl") public class YourService_Service extends Service { private final static URL YOURWEBSERVICE_WSDL_LOCATION; private final static WebServiceException YOURWEBSERVICE_EXCEPTION; private final static QName YOURWEBSERVICE_QNAME = new QName("http://test.webservice.services.xyz.com/", "YourService"); static { YOURWEBSERVICE_WSDL_LOCATION = com.xyz.services.webservice.test.YourService_Service.class.getResource("/META-INF/wsdl/YourService.wsdl"); WebServiceException e = null; if (YOURWEBSERVICE_WSDL_LOCATION == null) { e = new WebServiceException("Cannot find ''/META-INF/wsdl/YourService.wsdl'' wsdl. Place the resource correctly in the classpath."); } YOURWEBSERVICE_EXCEPTION = e; } public YourService_Service() { super(__getWsdlLocation(), YOURWEBSERVICE_QNAME); } public YourService_Service(URL wsdlLocation, QName serviceName) { super(wsdlLocation, serviceName); } /** * * @return * returns YourService */ @WebEndpoint(name = "YourServicePort") public YourService getYourServicePort() { return super.getPort(new QName("http://test.webservice.services.xyz.com/", "YourServicePort"), YourService.class); } /** * * @param features * A list of {@link javax.xml.ws.WebServiceFeature} to configure on the proxy. Supported features not in the <code>features</code> parameter will have their default values. * @return * returns YourService */ @WebEndpoint(name = "YourServicePort") public YourService getYourServicePort(WebServiceFeature... features) { return super.getPort(new QName("http://test.webservice.services.xyz.com/", "YourServicePort"), YourService.class, features); } private static URL __getWsdlLocation() { if (YOURWEBSERVICE_EXCEPTION!= null) { throw YOURWEBSERVICE_EXCEPTION; } return YOURWEBSERVICE_WSDL_LOCATION; } }

Quizás esto también ayude. Es solo un enfoque diferente que no utiliza el enfoque de "catálogo".

Tenía exactamente el mismo problema que se describe aquí. Independientemente de lo que hice, siguiendo los ejemplos anteriores, para cambiar la ubicación de mi archivo WSDL (en nuestro caso desde un servidor web), todavía estaba haciendo referencia a la ubicación original incrustada en el árbol de código fuente del proceso del servidor.

Después de MUCHAS horas tratando de depurar esto, noté que la excepción siempre se lanzaba desde la misma línea (en mi caso 41). Finalmente, esta mañana, decidí simplemente enviar mi código de cliente de origen a nuestro socio comercial para que al menos puedan entender cómo se ve el código, pero tal vez construir el suyo propio. Para mi sorpresa y horror , encontré un montón de archivos de clase mezclados con mis archivos .java dentro del árbol fuente de mi cliente. ¡Qué extraño! Sospecho que estos fueron un subproducto de la herramienta de creación de clientes JAX-WS.

Una vez que eliminé esos archivos .class tontos y realicé una limpieza completa y reconstrucción del código del cliente, ¡todo funciona perfectamente! Redonculous !!

YMMV, Andrew