When handling RESTEasy exceptions, it is typically very straightforward to perform custom exception handling (in this case, the intent is to handle marshalling issues when receiving an HTTP request):
#Provider
class MissingKotlinParameterExceptionHandler : ExceptionMapper<MissingKotlinParameterException> {
override fun toResponse(exception: MissingKotlinParameterException?): Response {
println("my MissingKotlinParameterException mapper")
return Response.serverError().build()
}
}
The particular challenge I'm experiencing, however, is when the same exception is thrown from different endpoints. For example, having /service1/foo and /service2/bar, due to architect specifications, return completely separate error payloads. Is it possible to separate the implementations based on some sort of configuration, or package structure?
You can inject the resource info into the ExceptionMapper class using:
#Context ResourceInfo info; // this is the java version
Then in the toResponse use that field in order to determine the resource method that serviced the request.
Related
I'm puzzled on how would I be able to fetch the current request handler (org.glassfish.jersey.server.internal.process.Endpoint) in an ExceptionMapper... Take a look at following code...
public class ValidationExceptionMapper implements ExceptionMapper<ValidationException> {
#Override
public Response toResponse(ValidationException exception) {
// Here I would like to know which endpoint triggered this exception...
}
}
Handling of the exceptions would be based on what kind of annotations were present on the input data that failed validations.
Jersey's Endpoint seems to have all the information that I might need. I would prefer to use any option that JAX-RS conforms to. But at this point, I'm ready to look for any alternatives.
Note: I did look at ConstraintViolation.getRootBean()... It points out at the resource rather than at the method that gets invoked... I'm interested in fetching the endpoint rather than just the resource.
Thanks in advance!
I am using Jersey Test to test Rest service DELETE method:
#DELETE
#Path("/myPath")
#Consumes(MediaType.APPLICATION_JSON)
#Produces(MediaType.APPLICATION_JSON)
public MyResponse myMethod(MyRequest myRequest) {
I have tried the example below and other methods:
Entity<MyRequest> requestEntity = Entity.entity(new MyRequest(arg1, arg2), MediaType.APPLICATION_JSON);
target(MY_URI).request(MediaType.APPLICATION_JSON).method("DELETE", requestEntity)
and
target(MY_URI).request(MediaType.APPLICATION_JSON).build("DELETE", requestEntity).invoke();
But it does not work.
How to make Http Delete in Jersey test?
According to the HTTP specification
If a DELETE request includes an entity body, the body is ignored
Though a lot servers still support the entity body, I guess because of this Jersey considers the body as breaking HTTP Compliance. Jersey validates compliance with client requests. To get around this validation, you can set the client property
ClientProperties.SUPPRESS_HTTP_COMPLIANCE_VALIDATION
If true, the strict validation of HTTP specification compliance will be suppressed.
By default, Jersey client runtime performs certain HTTP compliance checks (such as which HTTP methods can facilitate non-empty request entities etc.) in order to fail fast with an exception when user tries to establish a communication non-compliant with HTTP specification. Users who need to override these compliance checks and avoid the exceptions being thrown by Jersey client runtime for some reason, can set this property to true. As a result, the compliance issues will be merely reported in a log and no exceptions will be thrown.
Note that the property suppresses the Jersey layer exceptions. Chances are that the non-compliant behavior will cause different set of exceptions being raised in the underlying I/O connector layer.
This property can be configured in a client runtime configuration or directly on an individual request. In case of conflict, request-specific property value takes precedence over value configured in the runtime configuration.
The default value is false.
To configure it in JerseyTest, you can do
#Override
public void configureClient(ClientConfig config) {
config.property(ClientProperties.SUPPRESS_HTTP_COMPLIANCE_VALIDATION, true);
}
Assuming you are making your requests by calling the target(..) method of the JerseyTest, the above configuration will be for all request. If you just want to remove the validation for certain requests, you can also set the property on the WebTarget and not do the above configuration.
target(...).property(...).request()...
EDIT
Another thing I might mention is that Grizzly is one of the servers that doesn't support the entity, unless configured. I'm not quite sure though how to configure that in JerseyTest. So if you are using the Grizzly test provider, it may not even work on the server side.
If this is the case, you try to use the in-memory test provider, or use the jetty provider
EDIT Grizzly Configuration
Edit provided by Emanuele Lombardi
You can configure the Grizzly test provider by using the following snippet:
#Override
protected TestContainerFactory getTestContainerFactory() throws TestContainerException {
return new TestContainerFactory() {
private final GrizzlyTestContainerFactory grizzlyTestContainerFactory = new GrizzlyTestContainerFactory();
#Override
public TestContainer create(URI baseUri, DeploymentContext deploymentContext) {
TestContainer testContainer = grizzlyTestContainerFactory.create(baseUri, deploymentContext);
try {
HttpServer server = (HttpServer) FieldUtils.readDeclaredField(testContainer, "server", true);
server.getServerConfiguration().setAllowPayloadForUndefinedHttpMethods(true);
} catch (IllegalAccessException e) {
fail(e.getMessage());
}
return testContainer;
}
};
}
The below method should be invoked before the GrizzlyServer starts.
server.getServerConfiguration().setAllowPayloadForUndefinedHttpMethods(true);
The server instance is retrieved using reflection (in this example through org.apache.commons.lang3.reflect.FieldUtils#readDeclaredField).
This code works until the server field name is not changed into GrizzlyTestContainerFactory#GrizzlyTestContainer, but seems a reasonable approach to me, at least in a unit test.
I am using JAXRS to communicate between two application using http request.
During implementation I had an argue with my college, who said I can't use the same resource (org.apache.wink.client.Resource) for different request, as it can cause collision.
I argue that such thing can't happen, and by using the same resource for all requests, I am improving performance.
Bellow is a code snippet, please help to resolve our dispute
public class jaxrsDeliveryService{
private Resource queryResource;
public void init(){
servletPath = url + REMOVE_COUNT_SUFFIX_URL;
queryResource = restClient.resource(servletPath);
queryResource.contentType(APPLICATION_XML).accept(APPLICATION_XML);`
}
public QueryResponse getqueryResult(QueryInfoRequest qir){
ClientResponse response = resource.put(qir);
return response.getEntity(QueryResponse.class);
}
}
Resource is an interface that says nothing about thread-safety. Thus, we should assume that its implementation may be unsafe. If you want to make your class thread-safe you 1) should not use the same Resource, or 2) put its use into synchronized block.
If you don't worry about thread safety, reuse the resource. You will gain a little performance.
I have a Windows Service Application
in which i create WCF services in it.
One of the services is data
services: add, delete,
read , updatte data via
WCF.
WCF use NHibernate for data manipulation
So my guestions are:
Any advice (best practice) for session management for Hibernate using with WCF?
Anybody knows anything about
WcfOperationSessionContext (hibernate 3.0) class?
how to use it with WCF?
Well to make it concrete :
Suppose that i have WCF Service called DataServices
class WCFDataService .....
{
void SaveMyEntity(MyEntity entity)
{
.....................?? // How to do? Best Way
// Should i take one session and use it all times
// Should i take session and dipsose when operation finished then get
//new session for new operations?
// If many clients call my WCF service function at the same time?
// what may go wrong?
// etc....
}
}
And I need a NHibernateServiceProvider class
class NHibernateServiceProvider ....
{
// How to get Session ?? Best way
ISession GetCurrentSession(){.... }
DisposeSession(){ ....}
}
Best Wishes
PS: I have read similiar entries here and other web pages. But can not see "concrete" answers.
The WcfOperationSessionContext, similar to ThreadStaticSessionContext and WebRequestSessionContext is an implementation for a session context. The session context is used to bind (associate) a ISession instance to a particular context.
The session in the current context can be retrieved by calling ISessionFactory.GetCurrentSession().
You can find more information about session context here.
The WcfOperationSessionContext represents a context that spans for the entire duration of a WCF operation. You still need to handle the binding of the session in the begining of the operation and the unbinding/commiting/disposal of the session at the end of the operation.
To get access to the begin/end actions in the wcf pipeline you need to implement a IDispatchMessageInspector. You can see a sample here.
Also regarding WCF integration: if you use ThreadStatic session context it will appear to work on development, but you will hit the wall in production when various components (ex: authorization, authentication ) from the wcf pipeline are executed on different threads.
As for best practices you almost nailed it: Use WcfOperationSessionContext to store the current session and the IDispatchMessageInspector to begin/complete your unit of work.
EDIT - to address the details you added:
If you configured WcfOperationSessionContext and do the binding/unbinding as i explained above, all you have to do to is inject the ISessionFactory into your service and just use factory.GetCurrentSession(). I'll post a sample prj if time permits.
Here is the sample project
The model we use for managing NHibernate sessions with WCF is as follows:
1) We have our own ServiceHost class that inherits from System.ServiceModel.ServiceHost which also implements ICallContextInitializer. We add the service host instance to each of the operations in our service as follows:
protected override void InitializeRuntime()
{
base.InitializeRuntime();
foreach (ChannelDispatcher cd in this.ChannelDispatchers)
{
foreach (EndpointDispatcher ed in cd.Endpoints)
{
foreach (DispatchOperation op in ed.DispatchRuntime.Operations)
{
op.CallContextInitializers.Add(this);
}
}
}
}
public void AfterInvoke(object correlationState)
{
// We don't do anything after the invoke
}
public object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message)
{
OperationContext.Current.Extensions.Add(new SessionOperationContext());
return null;
}
The BeforeInvoke simply makes sure that the OperationContext for each WCF call has it's own session. We have found problems with IDispatchMessageInspector where the session is not available during response serialisation - a problem if you use lazy loading.
2) Our SessionOperationContext will then be called to attach itself and we use the OperationCompleted event to remove ourselves. This way we can be sure the session will be available for response serialisation.
public class SessionOperationContext : IExtension<OperationContext>
{
public ISession Session { get; private set; }
public static SessionOperationContext Current
{
get
{
OperationContext oc = OperationContext.Current;
if (oc == null) throw new InvalidOperationException("Must be in an operation context.");
return oc.Extensions.Find<SessionOperationContext>();
}
}
public void Attach(OperationContext owner)
{
// Create the session and do anything else you required
this.Session = ... // Whatever instantiation method you use
// Hook into the OperationCompleted event which will be raised
// after the operation has completed and the response serialised.
owner.OperationCompleted += new EventHandler(OperationCompleted);
}
void OperationCompleted(object sender, EventArgs e)
{
// Tell WCF this extension is done
((OperationContext)sender).Extensions.Remove(this);
}
public void Detach(OperationContext owner)
{
// Close our session, do any cleanup, even auto commit
// transactions if required.
this.Session.Dispose();
this.Session = null;
}
}
We've used the above pattern successfully in high-load applications and it seems to work well.
In summary this is similar to what the new WcfOperationSessionContext does (it wasn't around when we figured out the pattern above;-)) but also overcomes issues surrounding lazy loading.
Regarding the additional questions asked: If you use the model outlined above you would simply do the following:
void SaveMyEntity(MyEntity entity)
{
SessionOperationContext.Current.Session.Save(entity);
}
You are guaranteed that the session is always there and that it will be disposed once the WCF operation is completed. You can use transactions if required in the normal way.
Here is a post describing, in detail, all the steps for registering and using the WcfOperationSessionContext. It also includes instructions for using it with the agatha-rrsl project.
Ok, after few days of reading internet posts etc. all approaches shown in the internets seems to be wrong. When we are using UnitOfWork pattern with NH 3^ with nhibernate transaction this all aprochaes are producing exceptions. To test it and proof that we need to create test enviroment with MSMQ transaction queue, special interface with OneWay operation contract with transaction required set on it. This approach should works like this:
1. We put transactionally message in queue.
2. Service is getting transactionally messege from queue.
3. Everything works queue is empty.
In some cases not so obious with internet approaches this does not work properly. So here are expamples which we tested that are wrong and why:
Fabio Maulo approach: Use ICallContextInitializer - open NH session/transaction on BeforeCall, after that WCF is executing service method, on AfterCall in context initializer we call session.Flush + transaction.commit. Automaticly session will be saved when transaction scope will commit operation. In situation when on calling transaction.Complete exception will be thrown WCF service will shutdown! Question can be ok, so take transaction.Complete in try/catch clausule - great! - NO wrong! Then transaction scope will commit transaction and message will be taken from queue but data will not be saved !
Another approach is to use IDispatchMessageInspector - yesterday I thought this is best approach. Here we need to open session/transaction in method AfterReceiveRequest, after WCF invoke service operation on message dispatcher inspector BeforeSendReply is called. In this method we have info about [reply] which in OneWay operation is null, but filled with fault information if it occured on invoking service method. Great I thought - this is this ! but NOT! Problem is that at this point in WCF processing pipe we have no transaction ! So if transaction.Complete throw error or session.Flush will throw it we will have not data saved in database and message will not come back to queue what is wrong.
What is the solution?
IOperationInvoker and only this!
You need to implement this interface as a decorator pattern on default invoker. In method Invoke before call we are openning session/transaction open then we call invoke default invoker and after that call transaction.complete in finally clausule we call session.flush. What types of problem this solves:
1. We have transaction scope on this level so when complete throws exception message will go back to queue and WCF will not shutdown.
2. When invocation will throw exception transaction.complete will not be called what will not change database state
I hope this will clear everyones missinformation.
In some free time I will try to write some example.
I have a WCF service deployed on two or more remote machines and there is a desktop based application that is used by the client to access any wcf service.
The WCF service is connected to SQL server 2005 to read and write data.
This is an intranet scenario in which the client should be on same domain.
Now there can be scenarios where the wcf service throws exceptions:
Invalid URL
WCF service is down
SQL server 2005 is not running
Client is not on the same domain
Authentication fails
Authorization fails
and many other exceptions.
For every exception I have to perform some action or update a status bar, depending on the exception. For example if authorization fails I have to prompt the user to re-enter their credentials.
Please suggest the best design approach to handle this.
You can definitely catch and handle all exceptions that happen on your service class and turn them into a FaultException or FaultException exception.
That way, you won't "fault" (or tear down) the communications channel between your client and server.
Even better approach would be to implement the IErrorHandler interface on your service class that provides a way to globally catch all exceptions as they happen and provide a FaultException instead, that's SOAP compliant.
You can even turn your IErrorHandler into a configurable behavior that can be turned on or off in config.
See these articles and blog posts for more details:
Rory Primrose: Implementing IErrorHandler
Useful WCF behaviors: IErrorHandler
Create a custom fault class that is marked with the DataContract attribute
Mark the method on the service contract interface with FaultContract. Ie. [FaultContract(typeof(CustomFault))]
In your service method, catch any applicable internal exceptions and throw a FaultException<CustomFault>. Alternatively, as marc_s mentioned, you can use IErrorHandler to map the exception to the fault.
Personally, I create a base Fault class that has a Reason property and I extend all custom faults from this class. When I want to throw the fault, I call:
throw Fault.Create<CustomFault>(new CustomFault("Boo hoo"));
It's also worth noting that I version my fault classes (including the common Fault class) along with all my other services. This is only a concern if service versioning is a concern, though.
Here's the basic Fault class (I've removed argument validation for brevity):
[DataContract(Namespace = XmlVersionNamespace.FaultNamespace)]
public abstract class Fault
{
internal FaultReason Reason { get; set; }
protected Fault(string reasonText)
{
Reason = new FaultReason(new FaultReasonText(reasonText, CultureInfo.CurrentUICulture));
}
public override string ToString()
{
return Reason.ToString();
}
internal static FaultException<TDetail> Create<TDetail>(TDetail fault) where TDetail : Fault
{
return new FaultException<TDetail>(fault, fault.Reason);
}
}
You can design the specific Fault Data Contracts for each of the exception scenario in your WCF service so that you can handle the fault/exception at client side respectively.
try
{
// Actions
}
catch (Exception ex)
{
// Log the exception
// Throw Fault Exception back to client
FaultException fe = new FaultException(ex.Message, new FaultCode("Your fault code"));
//throw fault exception back to WCF client
throw fe;
}