Arjen Poutsma opened SWS-21 and commented

XStream (http://xstream.codehaus.org) would make a nice addition to the OXM library.

Note that XStream is an XML serialization library, not a data binding library. Therefore, it has limited namespaces support. As such, it is rather unsuitable for usage within Web services, but very useful for XML serialization purposes.

No further details from SWS-21

Arjen Poutsma opened SWS-17 and commented

Currently, the only implementation of the SoapMessage interface is SaajSoapMessage. SAAJ uses an DOM underneath, which is not very efficient when handling larger messages. A Streaming model, using StAX, is much more suitable for these larger messages.

We should provide such a streaming message model. It should be configurable whether the message payload should be cached or not. When cached, the message payload can be read multiple times. When it is not cached, it can only be read once. It should always be possible to read the message headers multiple times, since headers are required for interceptor handling.

No further details from SWS-17

Arjen Poutsma opened SWS-37 and commented

When running any spring-ws app on BEA Weblogic 8.1, the following exception is thrown:

javax.xml.soap.SOAPException: There should be only one Content-Type MimeHeader.

Apparently, Weblogic returns the Content-Header as part of the headers retrieved by getHeaderNames(). We should check for this.

Affects: 0.9, 0.9.1, 1.0 M1

Arjen Poutsma opened SWS-36 and commented

The current implementation of the JibxMarshaller does not work with DOM, nor SAX.

The new 1.1 version of Jibx might have fixed this. This should be investigated.

If 1.1 does not fix it, we can convert incoming DOM documents to streams, and unmarshal from those. This conversion behavior will probably be an option on the JibxMarshaller, because it can decrease performance, and not all users will want that.

Affects: 0.9, 0.9.1, 1.0 M1

1 votes, 1 watchers

Arjen Poutsma opened SWS-7 and commented

The SoapMessage interface currently lacks a way to get and add attachments. This should be added.

A workaround for getting the attachments in the 0.9 preview: you could cast the SoapMessage object to a SaajSoapMessage, and get the attachments from there.

Note that this issue is specifically concerned with SOAP with Attachments (SwA) support. It does not cover MTOM and DIME.

Affects: 0.9

Arjen Poutsma opened SWS-26 and commented

Ingo Siebert has provided a nice easy sample, which shows the core functionality of spring-ws. We should add it to the distribution.

Attachments:

• SpringWS-Echo.zip (12.07 kB)

Shannon Kendrick opened SWS-33 and commented

The class org.springframework.oxm.castor.CastorMarshaller is unable to unmarshal XML to Java unless a mapping file is used. Typically a mapping file is NOT used with Castor when using Castor-generated Java classes (generated from an XML schema).

The method org.exolab.castor.xml.Unmarshaller.unmarshal(Class clazz) should be used when the class type is specified.

Affects: 1.0 M1

Routis Haralampos opened SWS-23 and commented

The method setSchema(Resource) of Jaxb2Marshaller does not permit the creation of Schema object from multime XML schemas. Thus, the Jaxb2Marshaller cannot validate XMLs that are defined using multiple XML schemas.

For details please refer to: http://forum.springframework.org/showthread.php?t=24637

Affects: 0.9.1

Francesc Xavier Magdaleno opened SWS-34 and commented

Hey,

I am currently using your framework, but have notice in the class org.springframework.oxm.xstream.XStreamMarshaller the creation of com.thoughtworks.xstream.XStream can not be injected. In some cases could be funny to perform a customization of this object (probably when you are working with attributes or when you would like tio modify the driver)
and the introduction of a setXStream(XStream xstream) could help us!! nevertheless, congratulations for your work!!

thanks a lot!!!

Francesc Xavier

Affects: 1.0 M1

Attachments:

• xstream-with-attributes.rar (23.48 kB)

Alef Arendsen opened SWS-3 and commented

If building from build-spring-ws, core is built before oxm. It should be the other way around!

No further details from SWS-3

Alef Arendsen opened SWS-2 and commented

The sample needs a client. We should create a C# client for the airline sample.

No further details from SWS-2

Francesc Xavier Magdaleno opened SWS-40 and commented

Hey,

I have notice that you have done a validation framework. In the projects that i have been involved using xmlbeans, we always validate the xml parsed using the validate method passing a xmloptions with a list in order to retrieve the xml errors of validation. it could be possible to have a implementation for xmlbeans with this feature???

thanks a lot and congratulations for your framework!!!

Francesc

Affects: 1.0 M1

Ingo opened SWS-44 and commented

I have more than one schema which PayloadValidatingInterceptor should use.
The JAXB marshaller have an schemas element, something similar would be nice for the PayloadValidatingInterceptor.

Affects: 1.0 M2

Arjen Poutsma opened SWS-18 and commented

Provide a PayloadEndpoint implementation that resembles the CommandController in Spring-MVC. With this endpoint, it should be possible to populate a Java Bean with information from the incoming message. The population can take many forms. For instance, by providing a map with property names as keys, and XPath expressions as values. As a message comes in, the XPath expressions will be evaluated, and bound to the bean.

We should use the standard Spring Binding and Validation framework as part of this.

Issue Links:

• #178 XPath abstraction
  ("depends on")

Justin C. van Vorst opened SWS-48 and commented

References to src/etc/resources/... should instead read src/main/resources/...

Affects: 1.0 M1

Arjen Poutsma opened SWS-19 and commented

While developing Web service, XPath expression are quite valuable.

For compatibility reasons, we cannot directly depend on the XPath API introduced in JAXP 1.3. Instead, we need to create an XPath abstraction that wraps JAXP 1.3, and other XPath APIs.

Issue Links:

• #177 Command Endpoint
  ("is depended on by")

Arjen Poutsma opened SWS-29 and commented

To convert XML messages from one format to another, it should be nice to have a transforming interceptor. This is especially useful when dealing with multiple version of a Web service: you can transform the older message format to the new format.

The interceptor could be based on XSLT, with one stylesheet for the request, and one for the response.

No further details from SWS-29

Arjen Poutsma opened SWS-30 and commented

The C# client should also have WS-Security support. We will use Microsoft WSE to do so. Unfortunately, this means that it does not run on Mono any more.

Affects: 1.0 M1

Arjen Poutsma opened SWS-27 and commented

It appears SAAJ 1.3 has been released at https://saaj.dev.java.net/. It includes SOAP 1.2 and MTOM support.

We should upgrade to SAAJ 1.3, but not create any hardcoded depencies on it . This will probably require writing a SaajVersion class, just like JaxpVersion in xml and JdkVersion in spring core.

Affects: 1.0 M1

Issue Links:

• #191 SaajSoapMessage does not work if content type includes parameters
  ("depends on")

Arjen Poutsma opened SWS-43 and commented

From the forum http://forum.springframework.org/showpost.php?p=67520&postcount=8

"in PayloadValidatingInterceptor, the validation error string and the validation detail element qname should be optional properties, not fixed strings. I might have an existing convention for error names, or I might not want to expose implementation details."

I will make the validation error string a settable property, and add a boolean property to disable the validation detail elements.

Affects: 1.0 M1

Arjen Poutsma opened SWS-25 and commented

We should add a payload endpoint that is based on XOM.

No further details from SWS-25

Arjen Poutsma opened SWS-47 and commented

One disadvantage of writing your WSDLs yourself is that you don't have dynamic address locations anymore. Sometimes, it is needed to transform the address given in the WSDL document to one that matches the current url of the war.

Basically, this feature would allow people to use a relative paths in their wsdl description (such as /services/myservice). When a request comes in, the full context path is prepended to this relative url (resulting in something like http://example.com:8080/context/services/myservice).

1 votes, 1 watchers

Ingo opened SWS-35 and commented

I've created a web service and i get a validation error in the log file.

DEBUG webservice.CreateDataTypesRequestEndpoint - Marshalling [javax.xml.bind.JAXBElement@1873ad9] to response payload
ERROR endpoint.PayloadValidatingInterceptor - XML validation error on response: UndeclaredPrefix: Cannot resolve 'ns2:AddressDataType' as a QName: the prefix 'ns2' is not declared.
ERROR endpoint.PayloadValidatingInterceptor - XML validation error on response: cvc-elt.4.1: The value 'ns2:AddressDataType' of attribute 'http://www.w3.org/2001/XMLSchema-instance,type' of element 'ns2:casDataType' is not a valid QName.
ERROR endpoint.PayloadValidatingInterceptor - XML validation error on response: UndeclaredPrefix: Cannot resolve 'ns2:AddressDataType' as a QName: the prefix 'ns2' is not declared.
ERROR endpoint.PayloadValidatingInterceptor - XML validation error on response: cvc-attribute.3: The value 'ns2:AddressDataType' of attribute 'xsi:type' on element 'ns2:casDataType' is not valid with respect to its type, 'QName'.
ERROR endpoint.PayloadValidatingInterceptor - XML validation error on response: cvc-complex-type.2.4.d: Invalid content was found starting with element 'ns2:firstName'. No child element is expected at this point.

The following code is my SOAP response:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header />
SOAP-ENV:Body
<ns2:createDataTypesResponse xmlns:ns2="http://springws.cas.de">
<ns2:casDataType
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:AddressDataType">
ns2:key123</ns2:key>
ns2:firstNameFritz</ns2:firstName>
ns2:lastNameMeier</ns2:lastName>
</ns2:casDataType>
</ns2:createDataTypesResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

My XSD looks like this:

<?xml version="1.0" encoding="UTF-8"?>

<schema
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="qualified"
targetNamespace="http://springws.cas.de"
xmlns:tns="http://springws.cas.de" >

<complexType name="CasDataType" >
	<sequence>
		<element name="key"		type="long"		nillable="false" minOccurs="1" maxOccurs="1"/>
	</sequence>
</complexType>

<complexType name="AddressDataType">
	<complexContent>
		<extension base="tns:CasDataType">
			<sequence>
				<element name="firstName"	nillable="true" minOccurs="0" type="string"/>
				<element name="lastName"	nillable="true" minOccurs="0" type="string"/>
			</sequence>
		</extension>
	</complexContent>
</complexType>

<complexType name="ArrayOfCasDataTypes">
	<sequence>
		<element name="casDataType" 		type="tns:CasDataType"	nillable="false" minOccurs="1" maxOccurs="unbounded"/>
	</sequence>
</complexType>

<element name="createDataTypesRequest"  type="tns:ArrayOfCasDataTypes"/>

<element name="createDataTypesResponse" type="tns:ArrayOfCasDataTypes"/>

</schema>
This code says that my xml is valid:
SchemaFactory factory = SchemaFactory.newInstance(XMLConstants. W3C_XML_SCHEMA_NS_URI);
Schema schema = factory.newSchema(new File("schema.xsd"));
Validator validator = schema.newValidator();
validator.validate(new StreamSource(new File("payload.xml")));

Affects: 1.0 M1

Christian Dupuis opened SWS-42 and commented

While sending a SOAP Attachment with the reponse using Spring-WS, the response does not include the required 'multipart/related' and 'boundary' mime headers.

I've added an attachment in my MessageEndpoint with the following line of code:

((SoapMessage) messageContext.getResponse())
.addAttachment(new File("fileName"))

The resulting SOAP response message looks like the following:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: type="text/xml"; charset=utf-8
Transfer-Encoding: chunked
Date: Mon, 03 Jul 2006 22:19:11 GMT

2000
------=_Part_2_5156525.1151965151925
Content-Type: text/xml

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">SOAP-ENV:Header/SOAP-ENV:Body<GetFlightsResponse xmlns="http://www.springframework.org/spring-ws/samples/airline/schemas">\<number>KL1653</number><departureTime>2006-01-31T10:05:00+01:00</departureTime><from><code>AMS</code><name>Schiphol Airport</name><city>Amsterdam</city></from><arrivalTime>2006-01-31T12:25:00+01:00</arrivalTime><to><code>VCE</code><name>Marco Polo Airport</name><city>Venice</city></to><serviceClass>economy</serviceClass></flight></GetFlightsResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
------=_Part_2_5156525.1151965151925
Content-Type: application/octet-stream

foo bar
------=_Part_2_5156525.1151965151925--

Within the MessageHandlerAdapter.handle method the Content-Type of the underlying SOAP message needs to be taken into considaration. I added some proof-of-concept code into the handle method and the attachment support works:

if (responseMessage instanceof SaajSoapMessage) {
MimeHeaders headers = ((SaajSoapMessage) responseMessage).getSaajMessage().getMimeHeaders();
String[] contentTypeArray = headers.getHeader("Content-Type");
contentType = contentTypeArray[0];
}
else {
contentType = soapMessage.getVersion().getContentType();
}

The resulting SOAP message contains the 'multipart/related' and the 'bounday' header:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: multipart/related; type="text/xml";
boundary="----=_Part_2_5156525.1151965151925";charset=utf-8
Transfer-Encoding: chunked
Date: Mon, 03 Jul 2006 22:19:11 GMT

2000
------=_Part_2_5156525.1151965151925
Content-Type: text/xml

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">SOAP-ENV:Header/SOAP-ENV:Body<GetFlightsResponse xmlns="http://www.springframework.org/spring-ws/samples/airline/schemas">\<number>KL1653</number><departureTime>2006-01-31T10:05:00+01:00</departureTime><from><code>AMS</code><name>Schiphol Airport</name><city>Amsterdam</city></from><arrivalTime>2006-01-31T12:25:00+01:00</arrivalTime><to><code>VCE</code><name>Marco Polo Airport</name><city>Venice</city></to><serviceClass>economy</serviceClass></flight></GetFlightsResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
------=_Part_2_5156525.1151965151925
Content-Type: application/octet-stream

foo bar
------=_Part_2_5156525.1151965151925--

Affects: 1.0 M1

Arjen Poutsma opened SWS-5 and commented

Currently, Spring-WS is dependent on JAXP 1.3 (for instance, in the PayloadValidatingInterceptor, which uses a javax.xml.validation.Validator)

This dependency can be resolved by either using JDK 1.5, or by using the Endorsed Standards Override Mechanism to override the JAXP version of your JDK. More information about this override mechanism can be found here:

http://xerces.apache.org/xerces2-j/faq-general.html#faq-4
http://java.sun.com/j2se/1.4/docs/guide/standards/

The solution mentioned above is just a workaround: we should abstract away from this dependency.

Affects: 0.9

Arjen Poutsma opened SWS-46 and commented

See http://forum.springframework.org/showpost.php?p=67520&postcount=8:

The validation schema could be improved.

• Use the resource's URL as a system ID, if available.
• The Jaxp10Validator should not rely on a File being present, but use the available inputstream instead.

Affects: 1.0 M1

Arjen Poutsma opened SWS-8 and commented

Currently, the JaxbMarshaller requires a JAXBContext to operate, which can be configured using a JaxbContextFactoryBean. Likewise, the JibxMarshaller requires a IBindingFactory, configurable via the JibxBindingFactoryBean.

It would be much easier, and take less XML-config, to remove these two depencencies (JAXBContext & IBindingFactory), and move the functionality to the marshallers themselves. This would mean that the JaxbMarshaller would have a string contextPath property instead of a JAXBContext, and the JibxMarshaller would take a target class.

Affects: 0.9

Arjen Poutsma opened SWS-9 and commented

javax.xml.transform.Transformer is not thread safe: hence for each request, a separate instance must be created.

Throughout spring-ws-core, a number of Transformers are created (mostly in afterPropertiesSet()), and used. Instead, we must create a TransformerFactory, and a new Transformer per request.

Affects: 0.9

Arjen Poutsma opened SWS-10 and commented

From springframework--developer:

[email protected] writes:

I try to do a client in axis java and use your simple example airline but with xmlbeans mapper unfortunately it failed

look my request :

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:env="http://schemas.xmlsoap.org/soap/envelop/">
soapenv:Body
<air:GetFlightsRequest xmlns:air="http://www.springframework.org/spring-ws/samples/airline">
air:flightNumberKL1653</air:flightNumber>
air:startOfPeriod2006-02-02</air:startOfPeriod>
air:endOfPeriod2006-01-31</air:endOfPeriod>
</air:GetFlightsRequest>
</soapenv:Body>
</soapenv:Envelope>

if i make a new request like this :

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:env="http://schemas.xmlsoap.org/soap/envelop/">
soapenv:Body<air:GetFlightsRequest xmlns:air="http://www.springframework.org/spring-ws/samples/airline">
air:flightNumberKL1653</air:flightNumber>
air:startOfPeriod2006-02-02</air:startOfPeriod>
air:endOfPeriod2006-01-31</air:endOfPeriod>
</air:GetFlightsRequest>
</soapenv:Body>
</soapenv:Envelope>

it works, so you need to remove the white space between soapenv:Body and the body message. If you don't do that you will have the error:

java.lang.ClassCastException: com.sun.xml.messaging.saaj.soap.impl.TextImpl
at org.springframework.ws.soap.saaj.SaajMessageHelper.getPayloadElement(
SaajMessageHelper.java:81)

so look at the code source where is the problem:
package org.springframework.ws.soap.saaj;

public Element getPayloadElement() throws SOAPException {
SOAPBody body = message.getSOAPBody();
return (Element) body.getFirstChild();
}

The cast Element is not good.I think it needs to be modify

Affects: 0.9

Arjen Poutsma opened SWS-12 and commented

We should add a payload endpoint that is based on JDOM.

Affects: 0.9

Arjen Poutsma opened SWS-41 and commented

Add the attached Echo client to the samples.

Attachments:

• EchoClient.java (3.55 kB)

Arjen Poutsma opened SWS-20 and commented

Similar to Spring-MVCs MultiActionHandler, we should add a MultiActionEndpoint in Spring-WS. Such an endpoint would allow for POJO service classes, where incoming message request are mapped to methods using various mechanisms (for instance the SOAP action header, similar to .NET).

At the very least, the MultiActionEndpoint should support methods with the following signatures:

void method(MessageContext context), and

Source method(Source source);

A third option would be add support for marshalling, thus allowing any sort of method signature (as long as the parameters and return value are supported by the marshaller used). The Marshaller/Unmarshaller to be used for this option should be configured in the app context.

Referenced from: commits 68347ec

1 votes, 2 watchers

Arjen Poutsma opened SWS-49 and commented

The Axis 1.4 SAAJ implementation (axis-saaj.jar) does not set the Content-Type header, while the reference implementation does. We should check whether this header is set, since most SOAP clients depend on it.

See also http://forum.springframework.org/showthread.php?t=28083

No further details from SWS-49

Luke Hamaty opened SWS-32 and commented

org.springframework.ws.soap.saaj.SaajSoapMessage#getVersion() inpects the Content-Type header to determine the SOAP version, but it is using a simple String equals that does not recognize parameters on the content type. (See http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7). As a result, getVersion throws an exception if the Content-Type includes an encoding e.g.:
Content-Type: text/xml;charset=UTF-8

My corrected version of the function:
public SoapVersion getVersion() {
String[] contentTypes = saajMessage.getSOAPPart().getMimeHeader(CONTENT_TYPE_HEADER);
if (ObjectUtils.isEmpty(contentTypes)) {
throw new SaajSoapMessageException("Could not read '" + CONTENT_TYPE_HEADER + "' header from message");
}

    // Ignore parameters in content type (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7)
    int i = contentTypes[0].indexOf(';');
    if (i >= 0) {
    	contentTypes[0] = contentTypes[0].substring(0, i);
    }
    
    
    if (SoapVersion.SOAP_11.getContentType().equals(contentTypes[0])) {
        return SoapVersion.SOAP_11;
    }
    else if (SoapVersion.SOAP_12.getContentType().equals(contentTypes[0])) {
        return SoapVersion.SOAP_12;
    }
    else {
        throw new SaajSoapMessageException("Unknown content type [" + contentTypes[0] + "]");
    }
}

Affects: 1.0 M1

Issue Links:

• #187 Upgrade to SAAJ 1.3
  ("is depended on by")

Alef Arendsen opened SWS-4 and commented

Source code in not in CVS yet. Codebase should be moved to public CVS.

No further details from SWS-4

Arjen Poutsma opened SWS-13 and commented

Currently, the SoapEndpointInvocationChain and AbstractSoapEndpointMapping use a default role that is SOAP 1.1 specific.

Instead, we should obtain the default role from the incoming SoapMessager, which contains the SOAP version.

Affects: 0.9

Arjen Poutsma opened SWS-14 and commented

WS-Security support is one the most requested features for Spring-WS. While implementing this new feature, we should focus on the features included in WS-I's Basic Security profile.

Since Spring already has an excellent security framework in the form of Acegi, it seems best to leverage it. Furthermore, we can probably use Apache's WSS4J framework to handle the message.

Some links:
SOAP Message Security 1.0 Specification: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
Username Token profile V1.0: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
X.509 Token Profile V1.0: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf
WS-I Basic Security Profile: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html
Apache's WSS4J: http://ws.apache.org/wss4j/

No further details from SWS-14

Bruno Cornouiller opened SWS-53 and commented

It is now impossible to set a Content-Id to a SOAP attachment with Spring-WS.

The methods to improve are (org.springframework.ws.soap.SoapMessage) :

• Attachment addAttachment(File file) throws AttachmentException;
• Attachment addAttachment(InputStreamSource inputStreamSource, String contentType);

They will be replace (I think) by :

• Attachment addAttachment(String contentId, File file) throws AttachmentException;
• Attachment addAttachment(String contentId, InputStreamSource inputStreamSource, String contentType);

Thanks for this improvment.

Affects: 1.0 M2

Tareq Abedrabbo opened SWS-51 and commented

in AbstractValidatingInterceptor, line 307:
detailElement.addText(errors[0].getMessage());
causes the first error message to be repeated. It should be:
detailElement.addText(errors[i].getMessage());
(the "0" at the 47th position should be changed to "i")

Affects: 1.0 M2

Wayne L. Smith opened SWS-52 and commented

It is not possible to perform ACEGI certificate-based processing in Spring-WS (1.0 M2) when the certificate is not embedded in the header of the SOAP message.

When a certificate is embedded in a message, only CertificateValidationCallbacks are passed to the callback handlers. When a certificate is not embedded in the message (i.e., IssuerSerial reference), only SignatureVerificationKeyCallbacks are passed to the handlers. The KeyStoreCallbackHandler understands this one, and it does its job just fine: the certificate is found if already known to the server. The problem is that the ACEGI handler (AcegiCertificateValidationCallbackHandler) is not invoked, since it only understands the CertificateValidationCallback. So there is no way to configure the ACEGI security context unless the certificate is embedded in the message.

Possible solutions:

• Modify AcegiCertificateValidationCallbackHandler to also process SignatureVerificationKeyCallback
• Create and use a new handler to perform ACEGI processing that accepts SignatureVerificationKeyCallback
• Somehow cause XWSS to fire off a CertificateValidationCallback when the certificate is IssuerSerial

Affects: 1.0 M2

Issue Links:

• #384 If no BinarySecurityToken, i.e. IssuerSerial, no CertificateValidationCallback triggered for cert authentication by Acegi/JAAS - only signature check callback
  ("is duplicated by")

Arjen Poutsma opened SWS-16 and commented

The features of marshallers should be made accessible.

For instance, there should be a way to set properties on the JaxbMarshaller, and to configure an XMLBeans XmlOptions in a Spring context, which can then be specified to the XmlBeansMarshaller. Since XmlOptions does not follow the JavaBeans contract, we will probably have to create some sort of XmlOptionsFactoryBean.

Affects: 0.9

Arjen Poutsma opened SWS-31 and commented

From the forum (http://forum.springframework.org/showthread.php?t=25854):

The org.springframework.ws.transport.http.MessageHandlerAdapter relies on J2EE 1.4 (Servlet 2.4) functionality. When using it under J2EE 1.3, the following exception occurs:

org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse: method setCharacterEncoding(Ljava/lang/String;)V not found
java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse: method setCharacterEncoding(Ljava/lang/String;)V not found

This should be fixed.

Affects: 1.0 M1

1 votes, 1 watchers

Arjen Poutsma opened SWS-38 and commented

From the forum:

i want to use Stax based parsing of my soap messages. So i changed the messageContextFactory to AxiomSoapMessageContextFactory and derived my endpoint class from AbstractStaxEventPayloadEndpoint.
My implementation of invokeInternal just contains logging code at the moment. When i run a webservice call from a client i get the following exception:

2006-06-28 15:05:51,273 WARN [org.springframework.ws.soap.SoapMessageDispatcher] - <Endpoint invocation resulted in exception - responding with SOAP Fault>
javax.xml.stream.XMLStreamException: Can only create STaX reader for a SAXSource if Reader or InputStream exposed via getSource(); can not use other sources (like embedded SAX readers)
at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxIn putFactory.java:729)
at com.ctc.wstx.stax.WstxInputFactory.createXMLEventR eader(WstxInputFactory.java:276)
at org.springframework.ws.endpoint.AbstractStaxEventP ayloadEndpoint.invoke(AbstractStaxEventPayloadEndp oint.java:66)
at org.springframework.ws.endpoint.MessageEndpointAda pter.invoke(MessageEndpointAdapter.java:32)
at org.springframework.ws.MessageDispatcher.dispatch( MessageDispatcher.java:247)
at org.springframework.ws.MessageDispatcher.invoke(Me ssageDispatcher.java:209)
at org.springframework.ws.transport.http.MessageHandl erAdapter.handle(MessageHandlerAdapter.java:57)
at org.springframework.web.servlet.DispatcherServlet. doDispatch(DispatcherServlet.java:723)
...

This is due to the fact that the AbstractStaxPayload doesn't check whether is has been passed a StaxSource. Should be easy to fix.

Affects: 1.0 M1

Arjen Poutsma opened SWS-11 and commented

AbstractMarshaller handles SAXSources by taking the InputSource out of it, and reading that like a regular stream. This is incorrect behavior.

Instead, we should take the XMLReader and InputSource provided by the SAXSource, get a ContentHandler from the marshalling framework, and use the reader to parse the inputsource with the contenthandler.

Affects: 0.9

Arjen Poutsma opened SWS-6 and commented

The current release lacks reference documentation. This needs to be added before we do a 1.0 release.

Affects: 0.9, 0.9.1, 1.0 M1, 1.0 M2, 1.0 M3

Steven Devijver opened SWS-45 and commented

Affects: 1.0 M1

Routis Haralampos opened SWS-22 and commented

When the method setValidation(boolean) of JaxbMarshaller is called it always throws an UnsupportedOperationException, due the fact that the JAXB has deprecated the similar method of java.xml.bind.Unmarshaller and the Sun's JAXB implementation throws that exception.

The problem is that the setValidation(boolean) method of JaxbMarshaller is being called in afterPropertiesSer() method, so the JaxbMarshaller cannot be instatiated by spring.

Affects: 0.9.1

Arjen Poutsma opened SWS-28 and commented

We want to try maven2 for the spring projects, and spring-ws is going to be the first to try it. This should make it easier for people to get correct poms, which is a popular request.

As part of the migration, we will probably further modularize the projects. For instance, we will split spring-oxm into spring-jaxb1, spring-jaxb2, spring-castor-xml, spring-jibx, etc. The benefit of this is that you only download the dependencies you need.

No further details from SWS-28

Arjen Poutsma opened SWS-50 and commented

It would be nice if Spring-WS did not only support SOAP, but also Plain Old XML messages. These are messages that do not contain a SOAP envelope, only a payload. The architecture is already adapter for this (i.e. most classes are SOAP-agnostic).

Note that POX is not the same as REST. In my opinion, REST applications can be made best with existing MVC-frameworks like Spring-MVC. Adding support for it would have no benefit (though the O/X mapping abstractions can be very useful in REST-solutions as well).

No further details from SWS-50

Alef Arendsen opened SWS-1 and commented

Include postgres schema, database driver

Referenced from: commits 66ea015