Thinking about his more + reading existing jboss-dev ml entries, I think we need much more transparent "On_Demand" integration. e.g. if some service wants to be an entry point of "igniting" On_Demand beans it needs to implement certain MC On_Demand mechanism | ControllerContext context = controller.getContext(name, null); | if (context == null) | throw new IllegalArgumentException("No such context: " + name); | | controller.enableOnDemand(context); | controller.change(context, ControllerState.INSTALLED); | | if (ControllerState.INSTALLED.equals(context.getState()) == false) | throw new IllegalArgumentException("Couldn't fully install service: " + context); | | delegate = (SomeBean)context.getTarget(); | And this is _very_ invasive. A natural solution is probably the usage of AOP aspects. We should be able to describe the service's need for such On_Demand beans via ctor, method or field interceptor. e.g. | @OnDemand(beans = {"TransactionManager", "ThreadPool"}) | public void someMethod(int x) | { | ... | } | Having only such beans array value is probably too static, we would want to introduce much more dynamic behavior. e.g. @OnDemand(factory = SomeDynamicOnDemandFactory.class) Or grabbing some info out of the invoked Member itself. Then these AOP aspect would hide the MC mechanism, with the user only having to annotate his bean, either in xml or directly on the class. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228702#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...