| By Chris Muir | Article Rating: |
|
| May 4, 2009 08:56 PM EDT | Reads: |
3,136 |
A few days ago I blogged about suppressing the SOAP fault detail Java stack trace on WebLogic Server when using the JAX-WS @SchemaValidation annotation for your web services.
One of the problems with the @SchemaValidation annotation is dependent on the error in your incoming SOAP payload, you may get all sorts of potential errors returned in a SOAP fault. In some cases it might be useful or a requirement that a generic SOAP fault message be sent back in this case. How to do this?
As usual I'm documenting my research and solution here for my own purposes, but hopefully helpful to others. Your mileage may vary.
Consider the following JAX-WS endpoint:
@WebService
@SchemaValidation
public class WebServiceClass {
@WebMethod
public MyResponse lodgeReport(@WebParam MyRequest request)
throws GenericSoapFault {
// do some stuff
}
}
(I've clipped a lot of the detail from above to focus on the specifics)
Notice the @SchemaValidation annotation. By default this will enforce that the incoming SOAP payload conforms to the XML schema for the operation. For instance an invalid payload may throw the following error:
S:Receiver
org.xml.sax.SAXParseException: cvc-datatype-valid.1.2.1: '?' is not a valid value for 'dateTime'.
Note the reason/text part of the SOAP fault may be virtually any SAXParseException error message depending on the error discovered in the incoming SOAP payload.
We can however override the @SchemaValidation annotation to specify the actual error handler. We change the endpoint code as such:
@WebService
@SchemaValidation(handler = SchemaValidationErrorHandler.class)
public class WebServiceClass {
@WebMethod
public MyResponse lodgeReport(@WebParam MyRequest request)
throws GenericSoapFault {
// do some stuff
}
}
Note the handler attribute specifying the SchemaValidationErrorHandler class for the @SchemaValidation annotation. In turn the SchemaValidationErrorHandler is implemented as follows:
import com.sun.xml.ws.developer.ValidationErrorHandler;
import org.xml.sax.SAXParseException;
public class SchemaValidationErrorHandler extends ValidationErrorHandler {
public void warning(SAXParseException exception) { }
public void error(SAXParseException exception) { }
public void fatalError(SAXParseException exception) { }
}
Any warning, error or fatal error for the @SchemaValidation will now be passed through to the methods above. Remembering our goal to supplement a custom error message for any of the errors above (well, maybe not warning, we'll ignore warnings), we'd like to return our own SOAP fault. Unfortunately we can't do that from the handler, we need to pass the error back to the endpoint method. This is done by using the com.sun.xml.ws.api.message.Packet that is available from the ValidationErrorHandler super class. In essence we can change our handler class as follows:
public class SchemaValidationErrorHandler extends ValidationErrorHandler {
public static final String WARNING = "SchemaValidationWarning";
public static final String ERROR = "SchemaValidationError";
public static final String FATAL_ERROR = "SchemaValidationFatalError";
public void warning(SAXParseException exception) {
packet.invocationProperties.put(WARNING, exception);
}
public void error(SAXParseException exception) {
packet.invocationProperties.put(ERROR, exception);
}
public void fatalError(SAXParseException exception) {
packet.invocationProperties.put(FATAL_ERROR, exception);
}
}
I can't for the life of me find the JavaDoc for the Packet class, but what I believe it does is wrap the overall web service message context, and we can drop properties into the packet to be retrieved elsewhere by our JAX-WS solution , specifically our end point.
Returning to the JAX-WS endpoint we need to inject the web service message context, and then we can retrieve each of the individual errors from the SchemaValidationErrorHandler above:
@WebService
@SchemaValidation(handler = SchemaValidationErrorHandler.class)
public class WebServiceClass {
@Resource
WebServiceContext wsContext;
@WebMethod
public MyResponse lodgeReport(@WebParam MyRequest request)
throws GenericSoapFault {
MessageContext messageContext = wsContext.getMessageContext();
// We'll ignore warnings
// SAXParseException warningException = (SAXParseException)messageContext.get(SchemaValidationErrorHandler.WARNING);
SAXParseException errorException = (SAXParseException)messageContext.get(SchemaValidationErrorHandler.ERROR);
SAXParseException fatalErrorException = (SAXParseException)messageContext.get(SchemaValidationErrorHandler.FATAL_ERROR);
String errorMessage = null;
if (errorException != null)
errorMessage = errorException.getMessage();
else if (fatalErrorException != null)
errorMessage = fatalErrorException.getMessage();
if (errorMessage != null)
throw new GenericSoapFault(errorMessage);
// Otherwise process the request
}
}
Note the @Resource annotation in the class injecting the web service context, then within our endpoint method fetching the MessageContext from the wsContext, which gives us the ability to retrieve the properties we inserted in the SchemaValidationErrorHandler class.
As per the solution above, instead of just checking if the errorMessage is null and passing that to the GenericSoapFault, you could instead replace the SAXParseException with a more generic error message.
Read the original blog entry...
Published May 4, 2009 Reads 3,136
Copyright © 2009 Ulitzer, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Chris Muir
Chris Muir, an Oracle ACE Director, senior developer and trainer, and frequent blogger at http://one-size-doesnt-fit-all.blogspot.com, has been hacking away as an Oracle consultant with Australia's SAGE Computing Services for too many years. Taking a pragmatic approach to all things Oracle, Chris has more recently earned battle scars with JDeveloper, Apex, OID and web services, and has some very old war-wounds from a dark and dim past with Forms, Reports and even Designer 100% generation. He is a frequent presenter and contributor to the local Australian Oracle User Group scene, as well as a contributor to international user group magazines such as the IOUG and UKOUG.
- Apple and Emotional Discussions Around Adobe Flash Player
- How to Safely Publish Internal Services to the Outside World
- Running the Vordel XML Gateway on Sun Solaris
- Scaling AJAX Applications Is More About Architecture than Apache
- A10 Networks' Cloud Computing and Virtualization Roadmap
- SOA Software Expands European Operation
- Rhomobile Announces Update for Rhodes
- Layer 7 (Protocol) versus Layer 7 (Application)
- Metadata and Tagging
- Intel Intros Storage Atoms
- Configure an External List with BCS in SharePoint Foundation 2010
- Macworld 2010 Exhibitor Profiles
- How to Secure REST and JSON
- The Guillotine Effect of Cloud Computing
- Apple and Emotional Discussions Around Adobe Flash Player
- The Apache Software Foundation Announces Apache Pivot as Top-Level Project
- JSON Schema Validation for RESTful Web Services
- Cloud Reliability Will Be Bigger than Cloud Security for 2010-11
- Does Cloud Computing Exacerbate Security and File Transfer Issues?
- Running the Vordel XML Gateway on Oracle VM
- The Importance of Threat Protection for RESTful Web Services
- How to Safely Publish Internal Services to the Outside World
- Intel Q4 Hysterically Good
- Feature Versioning and Upgrades in SharePoint 2010
- Ellison at JavaOne: Myths About JavaFX, Android, and J2ME
- SOA Product Review: Intel XML Software Suite 1.1
- Sun Microsystems Releases NetBeans IDE 6.8
- How to Secure REST and JSON
- AJAX Over XMPP: Google Jumps into the Cloud Wave
- Intel to Debut New Version of XML Software Suite at SYS-CON's SOA World Conference & Expo, November 19-21, San Jose, CA
- JAX-WS: A @SchemaValidation Custom Handler to Alter Framework SOAP Faults
- Minimize XML Performance Challenges and Boost Productivity
- EC Wrong, Wrong, Wrong – and Sloppy to Boot: Intel
- Layer 7 Brings Governance Into the Cloud
- Embarcadero Extends Upcoming Delphi 2010 Release with Firebird SQL
- The Guillotine Effect of Cloud Computing



























Ulitzer content is offered under Creative Commons "Attribution Non-Commercial No Derivatives" License.
For any reuse or distribution, you must make clear to others the license terms of this work.
The best way to do this is with a link to this web page.
Any of the above conditions can be waived if you get written permission from Ulitzer, Inc., the copyright holder.
Nothing in this license impairs or restricts the author's moral rights.