Sort of.. :) The current approach uses Interceptors, but this means it can only be used with a CommandService implementation. Of course, there might be users who just want to use a StatefulKnowledgeSession (and not use persistence, for example) -- and don't even want to use a CommandService wrapper around the StatefulKnowledgeSession.   

So I experimented with a Proxy/InvocationHandler class that would provide a proxy around the StatefulKnowledgeSession: essentially, proxy classes are basically Java "Interceptor" classes, so the rest of the mechanisms work as well. 

At this point, I think it's probably a better idea to instead simply provide a CommandService implementation of the StatefulKnowledgeSession that users can use. Proxy/InvocationHandler code is fun to play around with, but a (non-persistent) CommandService implementation of the StatefulKnowledgeSession would fit better with the existing architecture of drools/jbpm. I get the feeling that a lot of us feel that the Command pattern is a good idea. :)