[JBoss JIRA] Created: (JBWS-2277) When publishing WS using an existing WSDL file from wsdlLocation, file:// <soap:address> bindings are not converted to http://
by Alexandros Karypidis (JIRA)
When publishing WS using an existing WSDL file from wsdlLocation, file:// <soap:address> bindings are not converted to http://
------------------------------------------------------------------------------------------------------------------------------
Key: JBWS-2277
URL: https://jira.jboss.org/jira/browse/JBWS-2277
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jbossws-native-3.0.2
Environment: I am using Sun's JDK 1.5.0_15, JBoss 4.2.3 with JBossWS-Native-3.0.2 on a x86-32 Intel PC with Windows XP.
Reporter: Alexandros Karypidis
Priority: Trivial
Attachments: fileURLBindingBug.zip
When using "wsdLocation" in @WebService, JBoss reads the WSDL file you provided and does the following:
1) if the <soap:address> tag in the WSDL file has a "file://..." URL in it,
it does NOT replace it with the actual address where your web service
endpoint was bound.
2) if the <soap:address> tag in the WSDL file has an "http://..." URL in it,
it replaces it with the actual address where your web service
endpoint was bound.
The WSDL published by JBoss should use http/https as appropriate.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (JBWS-2254) SchemaValidation exception when referencing independent schema in wsdl
by Bob Bucy (JIRA)
SchemaValidation exception when referencing independent schema in wsdl
----------------------------------------------------------------------
Key: JBWS-2254
URL: http://jira.jboss.com/jira/browse/JBWS-2254
Project: JBoss Web Services
Issue Type: Quality Risk
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.1
Environment: JBoss Server: JBoss_4_2_2_GA with jbossws-3.0.1-native-2.0.4.GA and JBoss Messaging 1.4.0.SP3 replacing JBossMQ.
OS/JVM: Sun JVM build 1.5.0_15-b04, Windows XP Service Pack 2
Reporter: Bob Bucy
The following exception takes place on the server when executing webservice with "@SchemaValidation" annotation. Exception does not occur when "@SchemaValidation" is disabled (e.g. able to execute service successfully, client able to run wsconsume, able to access ?WSDL, etc.). A sample application is attached which demonstrates the issue. The webservice being executed (e.g. WSTest.wsdl) does reference another schema (e.g. WSTest.xsd) that defines the input and output arguments to the webservice. Both the WSTest.wsdl and WSTest.xsd schemas are located in the WEB-INF\wsdl directory.
2008-07-10 13:36:26,224 WARN [org.jboss.ws.extensions.validation.StrictlyValidErrorHandler] org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'WSTest.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
2008-07-10 13:36:26,224 ERROR [org.jboss.ws.extensions.validation.StrictlyValidErrorHandler] org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'wsdoc:WSReq' to a(n) 'element declaration' component.
2008-07-10 13:36:26,224 DEBUG [org.jboss.ws.core.jaxws.handler.MessageContextJAXWS] Begin response processing
2008-07-10 13:36:26,224 DEBUG [org.jboss.ws.core.soap.MessageContextAssociation] popMessageContext: org.jboss.ws.core.jaxws.handler.SOAPMessageContextJAXWS@de4588 (Thread http-127.0.0.1-8080-2)
2008-07-10 13:36:26,224 DEBUG [org.jboss.ws.core.soap.MessageContextAssociation] pushMessageContext: org.jboss.ws.core.jaxws.handler.SOAPMessageContextJAXWS@15d7792 (Thread http-127.0.0.1-8080-2)
2008-07-10 13:36:26,240 ERROR [org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.WSException: org.xml.sax.SAXException: src-resolve: Cannot resolve the name 'wsdoc:WSReq' to a(n) 'element declaration' component.
at org.jboss.ws.WSException.rethrow(WSException.java:68)
at org.jboss.ws.core.soap.SOAPBodyElementDoc.validatePayload(SOAPBodyElementDoc.java:130)
at org.jboss.ws.core.soap.SOAPBodyElementDoc.transitionTo(SOAPBodyElementDoc.java:82)
at org.jboss.ws.core.soap.SOAPContentElement.getObjectValue(SOAPContentElement.java:173)
at org.jboss.ws.core.EndpointInvocation.transformPayloadValue(EndpointInvocation.java:263)
at org.jboss.ws.core.EndpointInvocation.getRequestParamValue(EndpointInvocation.java:115)
at org.jboss.ws.core.EndpointInvocation.getRequestPayload(EndpointInvocation.java:135)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (JBWS-3162) Add javaee_web_services_metadata_handler_2_0.xsd to jbossws-entities.properties
by Robert Dale (JIRA)
Add javaee_web_services_metadata_handler_2_0.xsd to jbossws-entities.properties
-------------------------------------------------------------------------------
Key: JBWS-3162
URL: https://jira.jboss.org/browse/JBWS-3162
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.4.1
Reporter: Robert Dale
This is for JBEPP-400 . I believe this change belongs here rather than have EPP use a catalog.
META-INF/jbossws-entities.properties:
http\://java.sun.com/xml/ns/javaee/javaee_web_services_metadata_handler_2_0.xsd=schema/javaee_web_services_metadata_handler_2_0.xsd
schema/javaee_web_services_metadata_handler_2_0.xsd (from http://java.sun.com/xml/ns/javaee/javaee_web_services_metadata_handler_2_...):
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://java.sun.com/xml/ns/javaee"
xmlns:javaee="http://java.sun.com/xml/ns/javaee"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="2.0">
<xsd:annotation>
<xsd:documentation>
javaee_web_services_metadata_handler.xsd v2.0.1 11/09/2007
</xsd:documentation>
</xsd:annotation>
<xsd:annotation>
<xsd:documentation>
Copyright 2004-2007 BEA Systems, Inc.
</xsd:documentation>
</xsd:annotation>
<xsd:include schemaLocation="javaee_5.xsd"/>
<xsd:element name="handler-chains"
type="javaee:service-ref_handler-chainsType">
<xsd:annotation>
<xsd:documentation>
The handler-chains element is the root element for defining
handlerchains.
The Web Services Metadata for the Java Platform (JSR-181), Version 2.0
specification defines the @javax.jws.HandlerChain annotation
that refers to an XML descriptor conforming to this schema.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:schema>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (JBWS-3011) Make the default JAX-WS Client and Endpoint Configuration configurable
by David Boeren (JIRA)
Make the default JAX-WS Client and Endpoint Configuration configurable
----------------------------------------------------------------------
Key: JBWS-3011
URL: https://jira.jboss.org/jira/browse/JBWS-3011
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.3.0.CR2
Reporter: David Boeren
Priority: Minor
I would like to have a possibility to configure the default JAX-WS Client and Endpoint Configuration. Currently the "Standard Client" (in file "standard-jaxws-client-config.xml") and "Standard Endpoint" (in file "standard-jaxws-endpoint-config.xml") are hardcoded in the interface org.jboss.ws.metadata.config.ConfigurationProvider as default configurations.
If a common enterprise specific configuration is in available then it would be nice to have the possibility to set it by default. Currently, every endpoint or client must define the annotation @EndpointConfig and @HandlerChain respectively.
A possibility would be to have two system properties to define the default configuration name for clients and endpoints for a JBoss server. I think from a JBoss/JBossWS perspective it makes sense to name them something like jbossws.jaxws.default.endpoint.config and jbossws.jaxws.default.client.config
By-the-way: It probably make also sense to make the default configuration filename configurable. The filename is more or less at the same place in the code. The solution could look similar as described for configuration name. However, configurable default filenames is not a requirement for me.
As a test, I have patched three classes in my JBoss in order to have a possibility to set the default configuration by system property.
For client configuration:
- org.jboss.ws.metadata.umdm.ClientEndpointMetaData
- org.jboss.ws.tools.metadata.ToolsEndpointMetaData
For endpoint configuration:
- org.jboss.ws.metadata.umdm.ServerEndpointMetaData
For example, I have only replaced the line
String configName = ConfigurationProvider.DEFAULT_ENDPOINT_CONFIG_NAME;
with the following
String configName = System.getProperty("jbossws.jaxws.default.endpoint.config", "AXA Standard Endpoint");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (JBWS-3165) Add support for jax-ws xml catalog to be spec-compliant
by Robert Dale (JIRA)
Add support for jax-ws xml catalog to be spec-compliant
-------------------------------------------------------
Key: JBWS-3165
URL: https://jira.jboss.org/browse/JBWS-3165
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Robert Dale
<ropalka> rdale, OK, JAXWS 2.2 - section 4.4
<ropalka> ---
<ropalka> The catalog is assembled by taking into account all accessible resources whose name is META-INF/jax-
<ropalka> -ws-catalog.xml. Each resource MUST be a valid entity catalog according to the XML Catalogs 1.1
<ropalka> specification. When running on the Java SE platform, the current context class loader MUST be used to
<ropalka> retrieve all the resources with the specified name. Relative URIs inside a catalog file are relative to the
<ropalka> location of the catalog that contains them.
<ropalka> ---
<ropalka> rdale, AFAIK Native doesn't support it. It uses proprietary jbossws-entities.properties approach
<ropalka> rdale, CXF should support it.
<ropalka> rdale, Do U use JBossWS Native or JBossWS CXF?
<darran> ropalka, CXF does, we are using it in SOA-P 5.1
<ropalka> rdale, I confirm JBossWS Native doesn't support it (although this is required by JAX-WS spec). The reason is this is not tested in TCK6 (certification suites) and we didn't have feature request to implement it yet.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (JBWS-3281) Create a migration guide to JBossWS 4.0 / AS 7 integration
by Alessio Soldano (JIRA)
Create a migration guide to JBossWS 4.0 / AS 7 integration
----------------------------------------------------------
Key: JBWS-3281
URL: https://issues.jboss.org/browse/JBWS-3281
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-native, productization
Reporter: Alessio Soldano
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
A migration guide from JBossWS 3.4.x to JBossWS 4.0 (and in particular to AS7 w/ JBossWS 4) should be included in the release documentation.
At the moment the topic to be covered should be:
- consequences for users due to changes in classloading (see JBossWS AS7 FAQ)
- changes in API (new jbossws-api library, package refactorings, etc.)
- changes in WS-* configuration
- changes due to libraries upgrades (mainly due to dependencies coming from Apache CXF 2.4 upgrade)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years