Warning: I wander all over in this post as I think things through. :-) "emuckenhuber" wrote : Additionally you should combine deployer and runtime services into one consistent profile description (incl. the acceptor). | | This would also mean that e.g. acceptor.start() will be called before even looking at the user deploy folder. I think the deployment of an "acceptor" can be part of the deployment of the stuff in the deploy folder; e.g. its an element in what gets deployed as part of a war. It's not a general part of the web server that exists independent of a war. For example, to handle a similar problem (url]https://jira.jboss.org/jira/browse/JBAS-6534[/url]) deployment of a clustered war includes installing a Tomcat Valve. I'm starting to experiment with a similar thing as the implementation of an "acceptor" for the web container. When the acceptor gets called to execute it's graceful shutdown logic is a different thing from how it gets deployed. The call of course needs to happen very early in the shutdown process. "emuckenhuber" wrote : Doing a brief research - in the TomcatService there is a handleNotification, which actually starts and stops the connectors. So the question is if the acceptor interface should also specify a contract for this. Otherwise we could end up opening ports without any user application installed, as this is something MC also does not know about. Interesting question. The way the TC Connector gets started/shutdown is pretty ad-hoc. I talk above about a "war-scoped acceptor", which may be necessary. But maybe I'm wrong and it can all be done with a single acceptor associated with the connector. As I experiment I'll try and see how that can fit. anonymous wrote : That's why i was asking if we need something like a 'acceptor' deployment phase - which is deployed last and undeployed first. So that you can just write your usual MC bean deployment thingy. In the end this is also not something ProfileService knows about, but it controls when deployments are deployed. | It most probably makes more sense to move the responsibility to the "central management bean" and the acceptor interface - where you basically have to decouple the acceptor from the MC lifecycle, or so ? Do deployment phases fit with the shortish-term vision for the profile service? IIRC when I looked at this before, the order in which sub-profiles got deployed was based on the order in which they are specified in the xml; i.e. no real deployment phases any more. If there are deployment phases, is it this "central management bean" that gets deployed in the last deployment phase? Acceptors are deployed with the runtime services; get injected into central management bean when it deploys last. In start(), which is now the last thing, it activates the acceptors. In stop() it tells the acceptors to do their graceful shutdown stuff. Without deployment phases that can still work; the "central management bean" is just part of the last sub-profile in the list. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268653#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...