Hi Jim, CC-ing ws dev list, as this is possibly of wider interest. On 05/21/2013 09:29 AM, Jim Ma wrote: I've been thinking a bit about this proposal; the way I would possibly see it implemented is in having a new implementation of the existing EndpointRegistry SPI interface that internally relies on the container services (through ServiceContainer). That would be created in the existing EndpointRegistryService instead of the default impl that's created now (we'd also need a managed version of it btw, implementing ManagedEndpointRegistry). There's no need for a new abstraction interface, given we already have the EndpointRegistry one (the interface is fine and keeping it would allow us to avoid touching the stack). If we did this new impl, we'd not need to explicitly register/unregister endpoints in the registry in start/stop methods of EndpointService. So far so good. The problem is that in change of saving the memory of a map instance, with the new impl we need to process the whole set of AS services each time and filter out the WS endpoints ones through name matching, which is possibly not very good performance-wise. Moreover, we actually lose control over the actual time an endpoint is registered/unregistered and is hence available/unavailable for invocation. So we have pros and cons, I'd say this needs to be properly evaluated... The problem I see now is that cxf management is jmx / managed bean based, and I think I remember the AS might run without the mbean server on. To be better analysed, also considering that the stats needs to be available through the Endpoint (they're exposed in the AS managemen, see org.jboss.as.webservices.dmr.WSEndpointMetrics). This said, speaking of cleanups, there's actually something I thought about I'd love to simply and just remembered while looking at your registry proposal. That's the jbossws SPI resolution mechanism. Currently we have a double resolution, so e.g. to get Foo we do: SPIProvider spiProvider = SPIProviderResolver.getInstance().getProvider(); Foo foo = spiProvider.getSPI(Foo.class); or (when a specific classloader is to be used): SPIProvider spiProvider = SPIProviderResolver.getInstance(classLoader).getProvider(); Foo foo = spiProvider.getSPI(Foo.class, classLoader); both SPIProviderResolver#getInstance and SPIProvider#getSPI internally rely on the jbossws ServiceLoader, which goes through the usual 3 resolution mechanism (service loader, propfile and sysprop). Moreover, the default SPIResolver impl in jbws-common (which is what is actually always used) allows using default values if nothing is found. I'd like to simplify this; we could remove the SPIProviderResolver indirection level by having a singleton in SPIProvider returned by a static getInstance() and resolved once using the jbossws-spi classloader. No need to try resolve the resolver each time; no need for such a verbose api. Something like: public abstract class SPIProvider { private static SPIProvider me; public static SPIProvider getInstance() { if (me == null) { me = SPIProviderResolver.getInstance().getProvider(); } return me; } public <T> T getSPI(Class<T> spiType) { return getSPI(spiType, SecurityActions.getContextClassLoader()); } public abstract <T> T getSPI(Class<T> spiType, ClassLoader loader); } and the use it as follows: Foo foo = SPIProvider.getInstance().getSPI(Foo.class, classLoader); WDYT? Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss