Sign up ×

I have a web application developped in Java 1.5 with Spring framework. Application contains "dashboards" which are simple pages where a bunch of information are regrouped and where user can modify some status. Managers want me to add a logging system in database for three of theses dashboards. Each dashboard has different information but the log should be traced by date and user's login.

What I'd like to do is to implement the Strategy pattern kind of like this :

interface DashboardLog {
   void createLog(String login, Date now);

// Implementation for one dashboard
class PrintDashboardLog implements DashboardLog {
  Integer docId;
  String status;

  void createLog(String login, Date now){
    // Some code

class DashboardsManager {
  DashboardLog logger;
  String login;
  Date now;

  void createLog(){

class UpdateDocAction{
   DashboardsManager dbManager;

   void updateSomeField(){
      // Some action
      // Now it's time to log
      dbManagers.setLogger = new PrintDashboardLog(docId, status);

Appcontext.xml :

<bean id="dashboardManagers" class="...DashboardManagers" />

In this solution I'm therefore not using dependency injection. Is it "correct" (good practice, performance, ...) to do it this way ? Is there a better way where I could use DI ?

Note :I did not write basic stuff like constructors and getter/setter.

share|improve this question
Consider passing only userId and having the date set by the database. That limits the chances of "programmer schenanigans". –  DwB Dec 29 '10 at 18:04

3 Answers 3

up vote 1 down vote accepted

While it is perfectly "correct" to employ the strategy pattern as you have, but considering the fact that you're using Spring - it would be better to employ the Dependency Injection mechanism provided by the Spring framework - might as well put to use what your framework has to offer as one of its core strengths.

share|improve this answer
that's why I am questionning myself about the correctness of the thing even though I think the strategy pattern would perfectly match my needs –  Anth0 Dec 29 '10 at 11:00
weelll - i don't see any issues as far as 'correctness' is involved, whether you choose or choose not to use Spring's DI capability. If it's performance or logic you're not sure about, then there's really no harm in your approach. it's fine. i'm assuming you're at least making use of Spring MVC's features, because otherwise you should be asking whether you should even use Spring. –  anirvan Dec 29 '10 at 11:17

Your solution will create a new instance of PrintDashboardLog for each call to updateSomeField(). This might take up unnecessary time/memory/GC-effort. Also, from a design perspective it makes sense if there is one DashboardLog for each Dashboard, not a new one for each call.

I think it may be a good idea to use aspects for which Logging is one of the exemplary usecases. Something like:

<beans xmlns=""

    <bean id="loggingAspect" class="com.yourcompany.yourapplication.aspects.DashboardLogAspect" />

        <aop:include name="loggingAspect" />


package com.yourcompany.yourapplication.aspects;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;

public class DashboardLogAspect {

    @Around("execution(* com.yourcompany.yourapplication..*Action+.*(..)) && target(target)")
    public Object logActionCall(ProceedingJoinPoint pjp, Object target) throws Throwable {

        long before = System.nanoTime();

        Object returnValue = pjp.proceed();

        long after = System.nanoTime();
        long durationNs = after - before;

        String logMsg = target.getClass() + "." + pjp.getSignature().toShortString() + " (" + durationNs + " ns)";

        // TODO: store the log message in your database

        return returnValue;

This logs all calls to application classes with a name ending in 'Action'. It also adds the time each call took to complete. You might want to tweak the Around advice for a specific method name pattern as well. See the AspectJ programming guide

share|improve this answer

If each "dashboard" is has a controller, why not call the logging from the controller.

public interface DashboardLog
    void createLog(...);

public class DashboardUno
implements DashboardLog
    public void createLog(...)
    { ... }

public class BlahController
    @RequestMapping(value = "/xxx")
    public String someMeaningfulName(...)
        DashboardUno elEsUno;
        ... get the dashboard object ...
share|improve this answer

Your Answer


