I really like the idea of using the binding annotations for service handlers...that makes them just like interceptor bindings, so that should be easier for people to understand in the long run.

If we used the binding approach it would also open up the possibility of a chain of servicehandlers. Not sure how ordering would work though.

For ordering, I'd use the same approach as with interceptors, you order them in XML (via Seam Config). Unlike interceptors, though, I like the idea of enabling them by default and only if you order them, do you control them enabled or not (empty element disables all).

<service-handlers>
<class>...</class>
</service-handlers>

I would suggest we just do what interceptors do here. I know that the interceptors enabling/ordering problem is a major one, however given that we intend to fix this in CDI 1.1, anything we do here will likely have to be aligned to that later on. IOW consistency is most important here.

Got it, makes sense.

What's interesting is that CDI made a point about introducing a new type of interceptor, a decorator. We'll, thanks to you guys, we've got a second type that was previously missing

The service handler should get "bound" to the type using the same strategy as is used for interceptor binding.

Binding type:

@Target({ METHOD, TYPE })

@Retention(RetentionPolicy.RUNTIME)

@ServiceHandlerBindingType

public @interface EchoService {}

Invocation handler:

@ServiceHandlerBindingType

@EchoService

public class EchoServiceHandler {

    @AroundInvoke

    public Object invoke(InvocationContext ctx) {

        return ctx.getMethod().getName().toString();

    }

}

Usage:

@EchoService

public interface HelloWorld {

   String helloWorld();

}