I was hoping that you guys will be able to help me with a conundrum that I am currently facing.I am currently working on an existing web application project where one of the requirements is that we have to centralise logging. The application is a layered application consisting of the client layer (i.e. the views), service layer, business layer and DAO layer.
Currently, logging in the application is handled by controller methods where each controller method that needs to have some information logged, manually logs the data by calling a logging function. Requests handled by these controller methods come from many different client sources including mobile devices (such as phones), web browsers, web services etc. Currently, all the data that needs to be logged is captured in a general purpose object which is passed to a logging method to persist these properties to a DB table.
The problem is that this general purpose object is exactly that, a general purpose object. Its used for many other tasks including logging, searching and many other tasks. When this general purpose object is used for logging, with the exception of a couple of attributes, most of the the attributes which are used to populate the general purpose object (in the case of logging) come from the request i.e. (a HttpServletRequest object). As a result of the versatility of this object, there is a potential for this general purpose object to get misused. Hence, we want to get rid of this general purpose object and create specialised objects for specialised tasks.In the case of logging, we have decided to create a logging object that we will use persist the data we need to have logged. We will be using Spring AOP effect the logging
The conundrum is this
1)Should we be using the controller to set the properties on the new specialised logging object that we want to log and then using an AOP advice, retrieve the log object for persistence once a controller method has finished executing
OR
2)should we set the properties on the new log object in an AOP advice using attributes that we have placed in a request object (i.e. HttpServletRequest object)?
My issue with option 1 is that the controller becomes aware of the logging and also, according to good design principles, a controller is only supposed to delegate tasks to business and services layers to perform such tasks. Option 1 will mean that the controller is doing more than just delegating tasks i.e. it will be building log objects
My issue with option 2 is that it couples my logging object closely with the request object (i.e. HttpServletRequest object) and hence I am wondering whether there are any potential with that approach.
Any sort of suggestions, advice and critique will be welcome. Also, if anyone has had to deal with a similar situation, I want to hear how they went about addressing the issue.
Thank you all in advance.
I’d add logging to the service layer, expressed as interfaces, using aspects.
You can use HTTP filters or aspects to log from the controller layer.
You can apply AOP in multiple layers as needed.