move protocol managers into their own module.

[ataylor]

As part of Wildfly Integration (and product) they need to be able to remove protocols by just removing the modules or jars. currently HornetQ protocol managers are instantiated directly in the remoting service code meaning this cant be done.

one way to fix this would be to use ServiceLoaders, I have some commits here showing how this would be done, https://github.com/andytaylor/hornetq/compare/hornetq:master...master, basically each protocol is its own module/jar and is made available via a file in META-INF/services. The remoting service can then just iterate these and add them to the map, see RemotingServiceImpl.java. This means that the protocol and associated dependencies can just be removed if not needed in Wildfly (or standalone HornetQ) and also new protocols can be dropped in. Ive tested this with Standalone, embedded, the maven tests and running a test in Intellij (can someone try eclipse) and all works well.

The alternative to this would be to just add an addProtocolManager to HornetQServer but this means that we would have to change all the beans files to inject them, and change all the tests that rely on stomp or amqp. Also We would need this exact code in Wildfly anyway so I thought It may be better in our codebase.

Thoughts?

[jmesnil]

+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)

[ataylor]

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)

I think a flag may be best, using our own ServiceLoader allows us to not have to inject them for tests, examples, all the configs etc etc, or would you prefer a spi to implement rather than a flag?

[jmesnil]

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

[clebert.suconic]

+1... Really nice...

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