+1

The rationale behind this from WildFly point of view is to be able to plug/unplug protocols by removing the physical bits (jar files).

I had a quick look at the commits and this looks fine (except that the interface should have a method getNames():String[] and get rid of the ProtocolType enum).

There is only an issue with the way services are loaded.

If you agree on this, I'll build on top of that in WildFly.

My idea is to extends the messaging subsystem by adding a "module" attribute to the acceptor resources. This module would correspond the name of a JBoss module that contains:

1. a given hornetq protocol jar (eg hornetq-amqp-protocol) with the META-INF to load the service

2. all the required dependencies (e.g. on hornetq-core, amqp protocol jars)

Then at runtime, I will load the Service using the ServiceLoader *using the JBoss Module* ClassLoader.

That means that I'd like to be in control of the ServiceLoader when setting up a HornetQServer and inject the ProtocolManagerFactory that I load.

This would imply to tweak your commits to:

* have a add(ProtocolManagerFactory) method to HornetQServer (or HornetQConfiguration) that I can use to set the service I have loaded

* This would also mean that the ServiceLoader need to occur outside of the RemotingServiceImpl (or have a flag in the config to disable it when we want to inject directly the ProtocolManagerFactory implementations)

a flag is fine (we will disable from WildFly and not expose it from our management model)

+1... Really nice...

It even makes it easier for users to send their own protocol if they want to