I believe there are three possible solutions:
for a description of the plugins please have a look at:
Solution a) is probably the cleanest and better performing. It would
imply some modifications to the interface itself (I_AccessFilter) from
boolean match(SessionInfo, SessionInfo, MsgUnit, Query) to
MsgUnit match(SessionInfo, SessionInfo, MsgUnit, Query)
Here the return value would be
- the message as you want to give it back to the subscriber,
- null if nothing has to be updated or
- the same reference as MsgUnit if it has to be sent without modification.
This solution would also need some (relatively simple) changes to the core.
Solution b) can be implemented without any modification but its
implementation could be a little complex since the only example
available is quite specific and not that simple (see the dispatch plugin).
Solution c) can be implemented right the way and is easy to implement.
Just make an own implementation of the I_MessageSecurityInterceptor (and
implement the exportMessage method). This is probably the easiest and
fastest way to do it (probably just some hours) but it would be kind of
a hack since you use the security plugin for purposes which are not
I said alternative a) is better performing because it modifies the
message before putting it into the callback queue (b and c would do it
after the queue). Since the dispatcher framework would put the message
into the queue again in case of delivery failure, then for b) and c) you
would modify the content before each trial while a) would do it only once.
Please let us know if you opted for solution a) since we would need to
prepare the core for the changes.
Michael Atighetchi wrote:
is it possible to write a plugin for changing the behavior of a
xmlblaster server after it has matched publications with subscriptions?
I'm in need for this, as I'd like to only send a selective part of
the initially published information to the subscribers, and hence
would like to do post-matching filtering (would be a nice complement
to the PublishFilter plugin, which does pre-matching filtering).
If it's not high on anyones priority list, I might consider
implementing this myself and integrating it into the latest cvs
tree. Any opinions on the prefered design ?