View Full Version : How to Unregister publishers and subcribers from the IApplicationContext
Garfield
05-09-2007, 04:51 PM
I use
ctx.PublishEvents(publisher);
and
ctx.Subscribe(subscriber, typeof (MyEventPublisher));
to register some publishers and subscribers, now I want to Remove some subscribers from the instance of IApplicationContext, how can I do? Thanks.
Mark Pollack
05-09-2007, 05:06 PM
Hi Garfield,
There isn't an unsubscribe feature. That said, I am planning a major overhaul of the IEventRegistry before the M1 release. I've added this point to the JIRA issue (http://opensource.atlassian.com/projects/spring/browse/SPRNET-547).
Cheers,
Mark
Garfield
05-10-2007, 05:46 AM
Thanks for the reply.
But I want to clean all the publishers or the subcribers in the running time. Is there Any other way for this requirement in spring.net preview3?
Regards.
Mark Pollack
05-10-2007, 02:48 PM
Hi,
The interface for IEventRegistry doesn't contain any methods for this funtionality but you can 'plug-in' your own implementation of IEventRegistry by defining an object with the name 'eventRegistry'. This constant value is defined in AbstractApplicationContext.EventRegistryObjectName .
You could investigate subclassing the current implementation, Spring.Objects.Events.Support.EventRegistry, and add an additional method that can work on the list of publishers. In your code where you would like to remove all the event wiring, get a reference to IEventRegistry, possibly by implementing the IEventRegistryAware interface for a spring managed object, and downcast to you new custom type.
That is all I can think of at the moment in terms of a work around.
Cheers,
Mark
rschneider
06-13-2008, 12:55 PM
I'm very interested in making changes to IEventRegistry. I've read the JIRA log and agree with the issues.
My first required change is to allow any order of calling the publish/subscribe methods. This would involve maintaining a list of subscribers and "autowiring" any subscriber when a new publisher is added.
Also, I need to worry about publishers and subscribers going out-of-scope, i.e. being disposed of. I was thinking that if the publisher/subscriber implements IComponent, then we can listen for a Disposed event and then remove the publisher/subscriber from our lists.
I'm happy to either (1) make these changes off-line as another EventRegistry class and then ship it and unit tests to the team or (2) become a team member and make the changes directly into source repository.
Cheers,
Richard
Mark Pollack
06-13-2008, 04:05 PM
Hi Richard,
Thanks for the offer, it is very much appreciated! I was actually thinking to get rid of IEventRegistry for the next release and start to introduce features around pub/sub that are in the Spring Integration (http://springframework.org/spring-integration) project. I think the programming model there is much nicer and it will really lend itself quite naturally to use in EAI like scenarios. The pre-requisite for that is to get attribute driven dependency injection working as well as 'assembly-scanning', stuff that is high priority for the next release. Perhaps you can take a look and give me your feedback on this approach?
Cheers,
Mark
rschneider
06-14-2008, 03:02 AM
Hi Mark,
Yes the Spring Itegration project looks good and if it was available I would use it now. However, currently I am just looking for an application-wide loosely-coupled eventing system. I really do not have the time to implement a full module.
Besides adding the previous enhancement I would also like to use an attribute based approach using the following: [Eventing] [AutoPublish] [AutoSubscribe] [Publish] and [Subscribe]. The EventingAttribute is class wide and informs the container that the class participates in the eventing system. The PublishAttribute is associated with an event and the SubscribeAttribute is associated with a "listener" method. The AutoPublish is associated with a class and specifies that all events in the class are automagically registered.
Also, there should be a way to configure the above attribute via XML, so that the source code does not have to change to participate in the eventing system.
To maintain backwards compatibility an IEventRegistry2 is defined as:
interface IEventRegistry2 : IEventRegistry
{
void RegisterPublisher (object publisher, Type eventType);
void UnregisterPublisher(object publisher);
void UnregisterSubscriber(object subscriber);
}
ssharrison
09-24-2008, 09:52 PM
Hi Richard,
Did you get anywhere with your plan on improving the EventRegistry? I completely agree with your suggestions and would love to use that functionality. Mark, I know you prefer to go with Spring Integration but that is still a ways off right?
thanks,
Scott
adoehring
10-13-2008, 07:31 AM
Hi Mark,
is there already someone working on the Spring integration .NET project ? Could you give me a link to your proposals ? I think about starting with this project.
Cheers
Andreas
Mark Pollack
10-13-2008, 03:08 PM
Hi,
Thanks for you input, I'm glad to year that you think the way to go with with Spring Integration for .NET. Spring Integration is technology that is near and dear to my heart, as geeky as that sounds, so I'm quite keen to see a port done. There is a formal spot for contributing, it is called the Spring Extensions project. Email me at mark dot pollack at springsource dot com and we can talk further about this.
Cheers,
Mark
vBulletin® v3.7.3, Copyright ©2000-2009, Jelsoft Enterprises Ltd.