> 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