> I also share this problem, because if you want to efficiently implement
> message filtering you need to do it in the broker side.
>
> I am not sure that making the full Dispatcher pluggable is a good idea,
> because the code is too complex and also
> it really depends on the internals of the Broker.
>
> If we make this pluggable that we must define a limited private but
> "stable" API.
>
> My suggestion is to define particular needs and then add features to make
> pluggable single specific parts
> of the dispatcher.
>
> For instance I would add some support for "Message filtering", leaving the
> implementation of the "filter" to a plugin.
> This way you could implement filtering using JMS rules, or using other
> metadata or security related information
>
> Regards
>
> Enrico
>
Hi, Enrico:
Thank you for your feedback.
We now have this method AbstractBaseDispatcher#filterEntriesForConsumer
I think we can plug-in this method. Do you think this is okay?
Provider：
```
public interface EntriesFilterProvider {
// Use `EntriesFilterProvider` to create `EntriesFilter`
EntriesFilter createEntriesFilter(Subscription subscription);
static EntriesFilterProvider
createEntriesFilterProvider(ServiceConfiguration serviceConfiguration)
{
// According to `EntriesFilterProviderClassName`, create
Provider through reflection
}
}
```
Add an interface for filtering：
public interface EntriesFilter {
filterEntriesForConsumer(Optional<EntryWrapper[]> entryWrapper, int
entryWrapperOffset,
List<Entry> entries, EntryBatchSizes batchSizes, SendMessageInfo
sendMessageInfo,
EntryBatchIndexesAcks indexesAcks, ManagedCursor cursor, boolean
isReplayRead)
}
Regards
Lin
