Hey Took me a while to read up on aspect oriented programming and the aop framework, it was the first time I was confronted with it. Went through the following links to learn (most of which are yours..). Am aware that the first link is outdated when it comes to syntax etc. http://www.onjava.com/pub/a/onjava/2003/05/28/aop_jboss.html?page=1 http://www.onjava.com/pub/a/onjava/2004/08/25/aoa.html?page=1 http://docs.jboss.org/aop/1.3/aspect-framework/reference/en/html/index.html http://docs.jboss.org/aop/1.3/aspect-framework/examples/examples.html I have a pretty good grasp of it now, as much as you can get without doing some actual development with it anyway. Does all this also mean that I have to throw out the model which I worked out thus far, or only that it is implemented in a different way? I'll lay out a bit more thoroughly how I thought about solving the problem before, as I do not clearly see yet how my old idea maps on the service+aspect, but am getting there. Most of it is repetition from before, but there are a few specific problems highlighted that I see with the change. The two basic parts of the model I had in mind is extending the container (by the in-between class) to hold and manage multiple implementations of one bean with a certain configuration, and routing the invocation through a dispatcher, which fires the invocation to the beanimplementation it is told to. The selecting of implementation is done by some classes/service instantiated per application, based on external context information for each client and a configuration file that maps context situations to application profiles, so it selects and changes the current implementation per client for each application. There exists one dispatcher for every client, and the client holds a reference to that dispatcher in its proxy, so no lookup of the configuration for that particular client needs to be done serverside (performance). Dispatchers would also be held and created for every client in the container. The deployment plan etc. would need to change of course, but that's a worry for after I get the plumbing of the container done, right now loading a file that describes the configurations and giving the other implementations of the bean is entirely meant to be done by new classes. This all means that stateless interactions aren't really stateless anymore and changing of implementations can be done in a 'safe' way, if no invocations/transactions are running. When I look at what you wrote, I see the aspect taking over the role of the dispatcher, and using a service to keep all the configurations for each client over all the applications? Since I'm not a seasoned JBOSS developper, I assume what you mean with a service is what is described in chapter 5 of the document: http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html_s... How I see it now, this represents a scaling problem in the real world, where you have a single instance/service keep all the routing information for every client of each reconfigurable application on your server. Maybe the service could make some routing-management instances per application, but in the end the aspect still needs to do a thorough lookup (->service->per application manager->clientID->which implementation for this bean) for each invocation, whereas the dispatcher would just have it's pool/cachereference changed and that's the end of it, invocations go to the right implementation. This is assuming I read your hints right, or did I miss anything? Maybe there's an easy solution. The next question is, where do I keep the other implementations if not in a specific container extension, or is there a way to expand it? I would like to have the beancontext/cache/pooling abilities if possible... But I can't really deploy every implementation to a different container since the original thesis proposition is supporting adaptation through a container extension, hence the reason why we proposed the requirement of having each beanimplementation have the same containerconfiguration. Also, org.jboss.ejb3.stateless.StatelessInstanceInterceptor (the current 'implementation selector' -as an example) will probably have to be removed from the interceptor stack and replaced by the new server aspect I assume. There isn't any specific order to the interceptors that will make or break the container currently in the ejb3-..-aop.xml file? I'm asking because, if I change the target of an invocation, will the next interceptor still be run... And uhm lastly, where do I 'deploy' any new server-side aspect :) Are there any docs on developing a service? Using all the links I found on google regarding developing on JBOSS EJB3 container, none of the eclipse configurations I found recognised the @service tag to start with. And a stupid one: assuming I have read up on everything I need to and have the right development tools/config, developing an aspect and service to do this and changing the necessary configurations, how much development time would I (only me) be looking at approximatly? A matter of days, weeks or months? :) Thanks for reading this far, just writing it down brought a lot of insights already. I'm hoping to make significant headway soon :D View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4018734#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...