Logging REST Exceptions with Spring

 

To enable logging for REST errors in Spring when using a ResponseEntityExceptionHandler just enable debug on ExceptionHandlerExceptionResolver

Without setting debug to true, your errors will still be handled perfectly but you will not receive any messages in your server logs about the handled error.

Of course, there’s also a complicated way to register an extended ExceptionHandlerExceptionResolver and set the warnLogCategory. But that is too much work when you can just enable debug logging to get a nice message like this:

DEBUG 15 Oct 2014 09:03:58,391 (AbstractHandlerExceptionResolver.java:134) - Resolving exception from handler [null]: org.springframework.web.bind.UnsatisfiedServletRequestParameterException: Parameter conditions "startDay" not met for actual request parameters:

And if you aren’t already using it, you can easily handle any REST exceptions from your Spring Controllers with a @ControllerAdvice annotated class that extends ResponseEntityExceptionHandler. Here is an example RestResponseEntityExceptionHandler that I use:

Cross-published on the Object Partners blog:  https://objectpartners.com/2014/10/21/logging-rest-exceptions-with-spring/

Pooling Web Service Connections in Grails

 

Apache Commons Pool is a great tool to easily configure an object pool on the JVM. Having a pool of created objects helps when you need to reuse connection objects that are expensive to create (LDAP, Web Service, etc).

While improving the performance of a Grails application, I noticed that 2 to 4 seconds were being consumed simply creating a connection to a specific JAX-WS Java Web Service that we used to retrieve Rules for building data grid columns. The perfect opportunity to install an object pool. Along the way I ran into some issues pooling the JAX-WS Port Proxy stub object, and I'll show you the simple work around here.

First, install the commons-pool2 jar dependency in BuildConfig.groovy

Next create a BasePooledObjectFactory that Apache Commons Pool will use to create an object to be placed in the pool. You'll need a create() method to build your object, and a wrap() method that wraps your object with a PooledObject implementation for stats and pool maintenance purposes. This code uses a legacy Java RuleServiceClientFactory to build the ruleService JAX-WS Port Proxy stub object, yours should probably inject a factory or service.

The factory is then wired into a GenericObjectPool in resources.groovy so we can easily inject the ConnectionPool into our Service objects. Here is where you can configure the pool properties.

See how the ruleConnectionPool is used in this sample GridService. The getGridRules() uses an available pooled WS Connection.

The PoolHelper.withCommonsPool is a convenience closure that I use to wrap the handling of the pool. This method handles invalidating and returning objects to the pool, much like how Groovy Sql methods will wrap the closing and transaction handling of a JDBC Connection. It frees up the GridService from knowing the API of Apache Commons Pool.

Finally, you may have noticed that the RuleServiceFactory is using a JaxwsPortProxy object to wrap the connection. Apache Pool2 requires each item in the pool to be unique via the equals method, but the JAX-WS port proxy object does not play well with this. So using a simple Groovy Proxy wrapper with UUID's to id the objects can get around the problem.

Hopefully this shows how easy it is to pool web service connections in Groovy. It should also be noted that all of this is pure Groovy besides the simple helpers that the Grails BuildConfig and resources.groovy files provide. So you can use this pattern in any Groovy/Java project even if Grails is not your current framework of choice.

Cross-published on the Object Partners blog: https://objectpartners.com/2014/06/11/pooling-web-service-connections-in-grails/

Simpler Stored Procedures with Groovy

 

(note: This feature has now been added to the Groovy language itself, see the SQL callWithRows and callWithAllRows methods!)

Using Groovy almost makes calling Stored Procedures an enjoyable process. More like a less painful adventure. But since many large enterprises have thousands of stored procedures lying around, at least we can make calling them and using them a bit simpler than the Java counterpart of registering inputs and outputs.

The Groovy Sql class has many features and we'll focus on two methods of interest for stored procedures: call() to handle output parameters, and rows() to handle ResultSet rows.

Calling an example GetACount stored proc on schema ABC with a lastName input and handling the output parameters is as simple as:

Calling a similar FindByFirst that copies the ResultSet rows into a List of GroovyRowResult objects is also straight forward:

Unfortunately the Sql class does not have a method to handle both output parameters AND a ResultSet in the same closure. GROOVY-3048 has been an open feature request since 2008. Until that feature is complete, I've created a simple SqlHelper class that adds a callWithRows() method.

First, showing how to use callWithRows() to get the rows and output parameters in a closure. Notice that callWithRows() returns the result of the closure to the original caller for you.

Now here is the source for SqlHelper.groovy. As an extension of Sql.groovy it can reuse many protected helper methods from the super class.

Hopefully this was helpful in showing multiple Groovy ways of dealing with the burden of calling Stored Procedures.

Cross-published on the Object Partners blog:  https://objectpartners.com/2014/01/24/simpler-stored-procedures-with-groovy/