Client-side interceptors?

[jmesnil]

Looking at https://jira.jboss.org/jira/browse/HORNETQ-183, I noticed that interceptors can also by ran on the client-side by adding them to ClientSessionFactory.

Do we really want to add interceptors on the Core API (I thought they were only a server feature)?

If yes, I'll add tests and document them.
If no, I'll remove them from the API and replace their use in our test in FailoverTest.testCommitOccurredUnblockedAndResendNoDuplicates()

[clebert.suconic]

I also thought interceptors were server side. I thought this had been changed, so that's why I used that example this way.

[timfox]

Why are you so against having client side interceptors?

[clebert.suconic]

Just ignore that JIRA for now.

I'm setting the interceptor on the client when it should be set on the server.

I confused the usage. I will close the issue as not an issue.


My bad!

[jmesnil]

"timfox" wrote:
Why are you so against having client side interceptors?

I am not against them. If we decide we support client-side interceptors, I just want to make sure their use on the client-side is documented too...

[clebert.suconic]

Just one thought...

Shouldn't the interceptor on the client do the intercept before sending?


While I was trying to think as an user, I thought the common use case is to avoid Message sending. On the server, you could intercept the call and avoid it... on the client you could do the same.

On the current implement, the interceptor on the client could only avoid a message receive, but the server will think the message was delivered. That could break things.

Ok, I know the user has a chance to break stuff with interceptors anyway.. but I still think it would be more use if the interception on the client was done before sending. (That would mean.. interception is always client->server, never server->client).


That's IMHO. I just think we will eventually get this kind of question from users.