How to have own attributes in MethodInvocation?

[sven.bauer]

Is there a way to enhance the MethodInvocation class by own attributes?
Background is, that I need to propagate additional information with my MethodInvocation along the interceptor chain (e.g. some sort of SecurityContext). However, the invocation object is an unknown subclass of MethodInvocation and is instantiated by the Spring-Container, so I cannot directly use an own implementation of this interface which contains the additional attributes... Is there any convenient hook...?

Thanks,

Sven

[Alef Arendsen]

I'd rather use a ThreadLocal to propagate additional information. This way, you explicitly model the relation and you can see where the contextual information is used.

regards,
Alef

[Ben Alex]

Is there any convenient hook...?

As it's security-related, take a look at Acegi Security. It provides a ContextHolder (a ThreadLocal) and manages storage of its contents between subsequent web requests.

[sven.bauer]

I'd rather use a ThreadLocal to propagate additional information.

The reason why I want to extend the invocation object is to be able to pass some information in a cross-cutting manner, even with SLSB-calls. In this case, ThreadLocal does not seem to be the best way because it simply ends at process boundaries. It would be more convenient to simply forward the invocation object via an invoke()-call on the SLSB...

Additionally, although I like ThreadLocals very much, it is still a means of using sort of "global variables" and therefore should only be used when really "global" information (global to the thread) is affected...

However, I don't mind using it, if there is no other solution...

Sven

[vivo]

This way, you explicitly model the relation and you can see where the contextual information is used.

I am sorry, I do not understand the argument.

How is the relationship (between which entities) modeled more explicit?

And why am I able to better see where the contextual information is used? If I could enhance Invocation (or create my own implementation), I could see where the information is used as well as when using ThreadLocal.

ThreadLocal introduces a kind of global variables, which I try to avoid where possible.

[Alef Arendsen]

Creating the context pattern is easy when wrapping a ThreadLocal in a bean and wiring up the bean wherever you need it. That's what I meant with seeing where the ThreadLocal is used.

Yes, the danger of using a ThreadLocal is that you're creating global variables, but that's only the case when using them in a static fashion.

Think of something like this:



// somewhat like the contextholder Acegi uses
public void Context {
private ThreadLocal tl = new ThreadLocal();
public void setContextObject(ContextObject o) {
this.tl.set(o);
}

public void reset() {
this.tl.set(null);
}
}

public class BusinessObject {
private Context context;
public void setContext(Context c) { .. }
}

<bean class="BusinessObject">
<property name="context"><ref bean="context"/></property>
</bean>

<bean id="context" class="Context"/>


This way, you (have to) wire up the context whereever you need it and it's clear that the business object is using it.

regards,
Alef

[sven.bauer]

Creating the context pattern is easy when wrapping a ThreadLocal in a bean and wiring up the bean wherever you need it.

Thanks Alef,

that's a great way of managing ThreadLocals!

However, my original intent was to make a remote call at the end of my interceptor chain and pass the invocation object as an argument. This sort of extends my interceptor chain to another process, which gives me the ability to pass context-parameters to an EJB (SLSB) - if I could add them to my invocation object!

Cheers,
Sven

[Rod Johnson]

See also http://forum.springframework.org/showthread.php?p=45222#post45222. Since 1.2.6 there is a metadata map on Spring AOP's ReflectiveMethodInvocation.

Rgds
Rod