The current support for Binding RRB created a new SPI (ServiceBindingProviderRRB) which delegate the configuration and injection of the wireFormat and operationSelector interceptor to the binding. With the current design, it becomes somewhat difficult to plug new wireFormat/operationSelector types, as the binding implementation need to somewhat know ahead of time which interceptor to add. Also, checking the current implementation for Binding.JMS, this seems to not be a problem, as all the possible wireFormat/operationSelector types are all defined/implemented inside the JMS Binding modules.
Is there any specific reason to use this approach, compared to what we have for Policies and other interceptors (e.g Policy) where the interceptors get added based on their Phase (see RuntimeWireImpl) (and btw, it looks like we already have specific phases for wire formats and operation selectors) ? I'll give it a try and try to add the same design we are using for Policies to plug the jsonrpc wireFormat/operationSelector type to the new HTTP Binding; and for now, this would probably not affect the current implementation of JMS Binding. Thoughts ? -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/
