I have a ExceptionMapper that I have written for one of my REST resource. I also have a Spring AOP aspect defined for the same resource. Now the problem is ExceptionMapper is not invoked if a REST resource throws an exception. I know this is because of the AOP-proxy objects. (If I remove the aspect it works.) Is there anyway I can make both the ExceptionMapper and the aspect to work.
Related
Recently I was wondering which class should I inherit in Kotlin if I want to create app-specific exception.
I noticed that I can inherit both: Kotlin's own Exception type and java.util.Exception.
So, I was looking for the answers: Exception or java.lang.Exception and Exception or RuntimeException (since Kotlin does not have checked exceptions, what is the difference)? Regarding second question: I feel like it is still better to use RuntimeException if Kotlin code can be invoked from Java in future (please correct me if I am wrong).
Regarding Exception I discovered that Kotlin's version is nothing more than the typealias on original Java Exception:
#SinceKotlin("1.1") public actual typealias Exception = java.lang.Exception
What is the purpose of having this typealias? The only advantage I see is you do not have to import java.lang.Exception, which makes your source code one-line-cleaner. Wondering if there is other motivation behind such typealiasing?
I typically extend from RuntimeException for the same reason you stated yourself, that there are no checked exceptions in kotlin, but either is fine.
The reason that there is a typealias of the java.lang.Exception within the kotlin-stdlib is to decouple your kotlin code from the java runtime/platform. This is because Jetbrains target other runtimes/platform. The aim is so that in theory you should be able to compile or transpile the same kotlin code to different platforms with minimal effort.
The dropwizard manual suggests to implement a javax.ws.rs.ext.ExceptionMapper in order to have more control of the generated responses for error cases. However, it does not tell me which maven dependency to use. The central maven repository yields dozens of result pages for this class. So which artifact should I choose?
The ExceptionMapper interface should already be pulled in when you reference dropwizard-core. You shouldn't need to add any other dependencies.
dropwizard-core depends on dropwizard-jersey which depends on jersey-server which depends on jersey-common which depends on javax.ws.rs-api which has the ExceptionMapper interface.
A little background relevant to my problem:- I'm learning to use SignalR, which is a client-server RPC framework. On the server-side you write one or more "hub" classes which expose methods that can be called remotely, a bit like a web service. When a message arrives, SignalR instantiates the appropriate hub class to handle that message, but for this to work hub classes must have a parameterless constructor.
In the real world, a hub class is likely to need dependencies. Fortunately SignalR lets you replace its default "dependency resolver", which I've done. There are numerous (almost identical) samples of SignalR Castle Windsor resolvers (e.g. here), but they all rely on calling the Windsor container's Resolve() method. My understanding of Windsor is that you must "release what you explicitly resolve", but I can't see where I could achieve this.
Note that the hubs are registered as transients, while dependencies may be a mixture of transients and singletons.
I thought about releasing a hub's dependencies in its Dispose() method, but this feels wrong - the hub would need access to the Windsor container; also the hub needs to know which dependencies are transient, and only attempt to release those.
Any thoughts?
IMHO you are bitten by the fact that the signal R dependency resolver fails to implement a Destroy method for releasing the hubs.
I agree that implementing the release of the components in the Hub's dispose method would get rather ugly. To release the hub from windsor the hub would need to call release on the container which in turn would then call the dispose again on the hub.
I think you're best bet would be to create an windsor interceptor for the hub, which will intercept the dispose call on the hub. This way only the interceptor needs to know about the container and you should be able to dispose you component.
You might need some logic in your interceptor to determine whether dispose is called from SignalR or from then windsor container. (ie if called from SignalR call Windsor release, otherwise proceed). You might do this by using e.g Thread local storage.
I'm about to embark on a new project using Windsor, but I've been wondering about running into scenarios where a Class A might need to instantiate Class B, but it's not feasible or possible for Windsor to inject an instance of Class B into it. I'm struggling to think of a scenario, but here goes:
Say I have a business entity "Customer" that gets passed to a WCF service. This class has an Ent.Lib self-validation method, which in turn uses a helper class "CustomerValidator". The Customer object received by the service has been deserialized by WCF, so Windsor plays no part in its instantiation, so I can't inject any dependencies. Nor can I pass my CustomerValidator to the self-validation method as it must follow a particular signature for Ent.Lib. So how could I instantiate the CustomerValidator within this class/method? I still want to utilise Windsor rather than simply doing a "var cv = new CustomerValidator();".
It's not a great example as it could be solved in different ways, e.g. passing the Customer object to a validation method rather than having the validation method in the Customer class, but it offers a possible scenario for discussion.
I could expose my WindsorContainer as a public singleton, accessible by any code that needs it, but that seems to be frowned upon. Any other suggestions?
should I reference the container from other classes?
No. By referencing the container, you add complicated and unnecessary dependency to your class which will complicate testing and increase complexity.
The Customer object received by the service has been deserialized by WCF, so Windsor plays no part in its instantiation, so I can't inject any dependencies.
I think this is the direction you should go, try to explore if there really isn't any way to take control of deserialization so you can inject dependencies.
If that fails, consider using http://commonservicelocator.codeplex.com/. Its Microsoft's service location implementation with Windsor adapter available. It's basically the same pattern as if you referenced the container but you don't introduce dependency on specific container implementation. Also I think it will be easier to mock for testing.
The handlers I implemented override SimpleChannelHandler messageReceived, channelConnected and exceptionCaught methods.
Throwing a base Exception type means PMD complains "Signature Declare Throws Exception".
What is the best way to handle Netty exceptions so as not the throw base Exception types?
My guess is to remove the "throws Exception" from all my handlers. Then any exception that occurs will eventually get propagated up to the exceptionCaught() method in the last upstream/downstream Handler in the pipeline. Is this a correct assumption?
Although I happen to agree with PMD on this, the object model of Netty is different and uses a raw Exception. If you are programming against the Netty API, it would probably be better (for consistency, readability, etc.) to follow their model.
Don't let a static analysis tool be the deciding factor on your code. Sometimes there are exceptions (nice pun, not intended)