How to access Session information on service layer?

Question

Is there a way I can share Http/Wicket Session information to the service layer without introducing servlet api/Wicket dependency?

I'll provide some context to why am I asking this question, just in case I'm missing something and asking the wrong question.

I've got several entities that have groups of attributes that can be validatable. Being validatable means there are fields indicating the validation value, the user who made the validation and the date it was validated in. This is how these entities are modelled:

@Embeddable
public class ValidationBean<T> implements Serializable {
    private T validated;
    private String user;
    private Date date;

    // Constructors, getters, setters ahead. 
    // ...
}

@Entity
@Table(name="SOME_TABLE")
public class SomeEntity implements Serializable, SomeInterface {
    // Some attributes which conform validation group 1
    public String attribute11;
    public String attribute12;
    public String attribute13;
    private ValidationBean<Integer> validationBean1 = new ValidationBean<Integer>();

    // Some attributes which conform validation group 2
    public String attribute21;
    private ValidationBean<String> validationBean2 = new ValidationBean<Integer>();

    // Constructors, various attribute getters with JPA annotations
    // ...

    @Embedded
    @AttributeOverrides(/*various overrides, each entity/validation group has its own validation column names...*/)
    public ValidationBean<Integer> getValidationBean1() { return validationBean1; }

    @Embedded
    @AttributeOverrides(/*various overrides, each entity/validation group has its own validation column names...*/)
    public ValidationBean<Integer> getValidationBean2() { return validationBean2; }
}

ValidationBean's user and date fields are automatically modified in the presentation layer when a change in the validated field is detected.

All of this is working correctly. Now, I'm trying to find an elegant & general solution that integrates with the current modelling to the following requirement: When any of the attributes in a validation group gets its value changed, and the related ValidationBean.validated doesn't change, user and date must also be modified with the current user's id and the current date.

There are, as I see it, two alternatives; putting that logic in the presentation layer, or in business/service layer

• Putting it in the presentation layer would have an efficieny advantage. Entities are stored in session so that the DB doesn't have to be queried again to check for field changes. But unfortunately, some entities have some of their fields ajax-updated and it would be hard to tell if the entity really changed. Apart from not being the presentation layer's responsability to fulfill this requirement.

• Putting it in the service layer seems the best alternative, and I've already found a possible way to handle this properly. I've come up with @PreUpdate. It would be easy to implement a @PreUpdate method on the @Entities to compare the values in DB with the values about to be updated, and modify the related ValidationBeans accordingly. The problem here, and I suppose it's a common problem, is that in the business layer, I don't have where to get the user id from. The current user Id is stored in the Session, which belongs to the presentation layer.

So, any tips, comments, recommendations on how can I share http session information to the service layer (not necessarily Wicket-specific), or even alternatives to fulfill this requirement will be welcome.

UDPATE : Following gkamal's suggestion, I'll try to integrate spring-security in the less intrusive way I can, just to take advantage of SecurityContext. I'd also appreciate tips on this matter.

Answer 1

The common approach used to solve this is to introduce a SecurityContext class that holds the details of the current user as a static thread local variable. The variable is initialized (from the httpsession) by the security filter or some other filter and cleared after the request processing is complete. The SecurityContext class will itself be part of the business layer which provides a set / get methods and hence doesn't have any web layer dependency.