diff --git a/doc/reference/src/messaging.xml b/doc/reference/src/messaging.xml index e3756e59..a23997d3 100644 --- a/doc/reference/src/messaging.xml +++ b/doc/reference/src/messaging.xml @@ -562,8 +562,9 @@ business object that is being sent or received via messaging and not be concerned with the details of how it is represented as a JMS message. There is also an XmlMessageConverter that converts - objects to an XML string and vice-versa for sending via a - TextMessage. + objects to an XML string and vice-versa for sending via a TextMessage. + Please refer to the API documentation and example application for more + information on configuring an XmlMessageConverter. The family of ConvertAndSend messages are similar to that of the Send method with the additional argument of type diff --git a/doc/reference/src/msmq-quickstart.xml b/doc/reference/src/msmq-quickstart.xml index cf79bfd3..a3c14d31 100644 --- a/doc/reference/src/msmq-quickstart.xml +++ b/doc/reference/src/msmq-quickstart.xml @@ -55,9 +55,18 @@ Messages sent from the server to the client will use the transactional queue .\Private$\response.joe.txqueue. The queue for messages that cannot be processed, so called 'poison messages' will be - sent to the queue .\Private$\dead.queue. You can create - these queues using the computer management administration console. Private - queues are used to simplify the application setup requirements. + sent to the queue .\Private$\dead.txqueue. You can + create these queues using the computer management administration console. + Private queues are used to simplify the application setup + requirements. + + + You must create the queues mentioned previously using standard + Windows Computer Management console to manage MSMQ. This article + covers the basics of creating the queus in the management console. + + Since MSMQ does not natively support the publish-subscribe messaging style as in other messaging systems, Apache MQ, IBM Websphere MQ, TIBCO diff --git a/doc/reference/src/objects.xml b/doc/reference/src/objects.xml index 35c7e81f..c49b20ca 100644 --- a/doc/reference/src/objects.xml +++ b/doc/reference/src/objects.xml @@ -402,7 +402,7 @@ It can be useful to have object definitions span multiple XML files. Often each individual XML configuration file represents a - logical layer or module in your architecture. + logical layer or module in your architecture. You can use the IApplicationContext constructor to load object definitions from all these XML fragments. @@ -611,7 +611,7 @@ IList userList = service.GetUserNames(); RegisterSingleton(..) and RegisterObjectDefinition(..). However, typical applications work soley with objects defined through metadata object - definitions. + definitions. Naming objects @@ -1822,7 +1822,7 @@ public class MixedIocObject An <object/> element inside the <constructor-arg/> or <property/> - element defines so called inner object. + element defines so called inner object. <object id="outer" type="..."> @@ -2769,7 +2769,7 @@ namespace Fiona.Apple described in the preceding section. The Spring framework implements this method injection by a dynamically generating a subclass overriding the method using the classes in the - System.Reflection.Emit namespace. + System.Reflection.Emit namespace. You can read more about the motivation for Method Injection in @@ -3288,24 +3288,26 @@ public class MyClassFactory Object Scopes - When you create a object definition what you are actually creating - is a recipe for creating actual instances of the class defined by that - object definition. The idea that a object definition is a recipe is - important, because it means that, just like a class, you can potentially - have many object instances created from a single recipe. + When you create an object definition, you create a + recipe for creating actual instances of the class + defined by that object definition. The idea that an object definition is a + recipe is important, because it means that, as with a class, you can + create many object instances from a single recipe. You can control not only the various dependencies and configuration values that are to be plugged into an object that is created from a - particular object definition, but also the scope of the objects created - from a particular object definition. This approach is very powerful and - gives you the flexibility to choose the scope of the objects you create - through configuration instead of having to 'bake in' the scope of an - object at the .NET class level. Objects can be defined to be deployed in - one of a number of scopes: out of the box, the Spring Framework supports - exactly five scopes (of which three are available only if you are using a - web-aware ApplicationContext). + particular object definition, but also the scope of + the objects created from a particular object definition. This approach + powerful and flexible in that you can choose the + scope of the objects you create through configuration instead of having to + bake in the scope of an object at the .NET class level. Ob jects can be + defined to be deployed in one of a number of scopes: out of the box, the + Spring Framework supports five scopes, three of which are available only + if you use a web-aware + IApplicationContext. - The scopes supported out of the box are listed below: + The following scopes supported. Support for user defined custom + scopes is planned for Spring .NET 2.0. Object Scopes @@ -3342,9 +3344,9 @@ public class MyClassFactory requestScopes a single object definition to the lifecycle of a - single HTTP request; that is each and every HTTP request will have - its own instance of an object created off the back of a single - object definition. Only valid in the context of a web-aware Spring + single HTTP request; that is, each and every HTTP request has its + own instance of an object created off the back of a single object + definition. Only valid in the context of a web-aware Spring ApplicationContext. @@ -3370,35 +3372,36 @@ public class MyClassFactory The singleton scope - When an object is a singleton, only one shared instance of the - object will be managed, and all requests for objects with an id or ids - matching that object definition will result in that one specific object + Singleton scoped objects have only one shared instance of an + object managed by the container. All request for objects with an id or + ids matching that object definition result in that one specific object instance being returned by the Spring container. To put it another way, when you define an object definition and it - is scoped as a singleton, then the Spring IoC container will create - exactly one instance of the object defined by that object definition. - This single instance will be stored in a cache of such singleton object, - and all subsequent requests and references for that named object will - result in the cached object being returned. + is scoped as a singleton, the Spring IoC container creates exactly one + instance of the object defined by that object definition. This single + instance is stored in a cache of such singleton object, and all + subsequent requests and references for that named object return the + cached object. - Please be aware that Spring's concept of a singleton object is - quite different from the Singleton pattern as defined in the seminal - Gang of Four (GoF) patterns book. The GoF Singleton hard codes the scope - of an object such that one and only one instance of a particular class - will ever be created per ApplicationDomain. The scope of the Spring - singleton is best described as per container and per object. This means - that if you define one object for a particular class in a single Spring - container, then the Spring container will create one and only one - instance of the class defined by that object definition. The singleton - scope is the default scope in Spring. To define an object as a singleton - in XML, you would write configuration like so: + Spring's concept of a singleton differns from the Singleton + pattern as defined in the Gang of Four (GoF) patterns book. The GoF + Singleton hard-codes the scope of an object such that one and + only one instance of a particular class is created per + ApplicationDomain. The scope of the Spring singleton is best described + as per container and per object. This means that if + you define one object for a particular class in a single Spring + container, then the Spring container creates one and only + one instance of the class defined by that object definition. + The singleton scope is the default scope in Spring. To define an object + as a singleton in XML, you would write, for example: <object id="accountService" type="MyApp.DefaultAccountService, MyApp"/> <!-- the following is equivalent, though redundant (singleton scope is the default) --> <object id="accountService" type="MyApp.DefaultAccountService, MyApp" singleton="true"/> + @@ -3406,74 +3409,85 @@ public class MyClassFactory The prototype scopeThe non-singleton, prototype scope of object deployment results in - the creation of a new object instance every time a request for that - specific object is made (that is, it is injected into another object or - it is requested via a programmatic GetObject() method call on the - container). As a rule of thumb, you should use the prototype scope for - all objects that are stateful, while the singleton scope should be used - for stateless objects. + the creation of a new object instance every time a + request for that specific object is made. That is, the object is + injected into another object or you request through a + GetObject() method call on the container. As a rule + use the prototype scope for all objects that are stateful and the + singleton scope for stateless objects. - To define an object as a prototype in XML, you would write - configuration like so: + The following examples defines an object as a prototype in + XML: - <object id="exampleObject" type="Examples.ExampleObject, ExamplesLibrary" singleton="false"/> + <object id="exampleObject" type="Examples.ExampleObject, ExamplesLibrary" scope="prototype"/> - There is one quite important thing to be aware of when deploying - an object in the prototype scope, in that the lifecycle of the object - changes slightly. Spring does not manage the complete lifecycle of a - prototype object: the container instantiates, configures, decorates and - otherwise assembles a prototype object, hands it to the client and then - has no further knowledge of that prototype instance. This means that - while initialization lifecycle callback methods - will be called on all objects regardless of scope, in the case of - prototypes, any configured destruction lifecycle - callbacks will not be called. It is the - responsibility of the client code to clean up prototype scoped objects - and release any expensive resources that the prototype object(s) are - holding onto. (One possible way to get the Spring container to release - resources used by singleton-scoped objects is through the use of a - custom object post processor which would hold a reference to the objects - that need to be cleaned up.) + + The <singleton/> attribute was + introduced Spring 1.0 as there were only two types of scopes, + singleton and prototype. The element singleton=true refers to + singleton scope and singleton=false refers to prototype scope. In + Spring 1.1 the additional web scopes were introduced along with the + new elment 'scope'. The scope element is the preferred element to + use. + - In some respects, you can think of the Spring containers role when - talking about a prototype-scoped object as somewhat of a replacement for - the C# 'new' operator. All lifecycle aspects past that point have to be - handled by the client. (The lifecycle of a object in the Spring - container is further described in the section entitled “Lifecycle - callbacks”.) + In contrast to the other scopes, Spring does not manage the + complete lifecycle of a prototype object: the container instantiates, + configures, decorates and otherwise assembles a prototype object, hands + it to the client, with no further record of that prototype instance. + Thus, although initialization lifecycle callback + methods are called on all objects regardless of scope, in the case of + prototypes, configured destruction lifecycle + callbacks are not called. The client code must + clean up prototype-scoped objects and release any expensive resources + that the prototype object(s) are holding. To get the Spring container to + release resources held by prototype-scoped objects, try using a custom + object post processor + which would hold a reference to the objects that need to be cleaned + up. + + In some respects, the Spring container's role in regard to a + prototype-scoped object is a replacement for the C# 'new' operator. All + lifecycle management past that point must be handled by the client. (For + details on the lifecycle of an object in the Spring container, see . - Singleton objecgts with prototype-object dependencies + Singleton objects with prototype-object dependencies - When using singleton-scoped objects that have dependencies on - objects that are scoped as prototypes, please be aware that dependencies - are resolved at instantiation time. This means that if you dependency - inject a prototype-scoped object into a singleton-scoped object, a brand - new prototype object will be instantiated and then dependency injected - into the singleton object... but that is all. That exact same prototype - instance will be the sole instance that is ever supplied to the - singleton-scoped object, which is fine if that is what you want. + When you use singleton-scoped objects with dependencies on + prototype objects, be aware that dependencies are resolved at + instantiation time. Thus if you dependency-inject a + prototype-scoped objects into a singleton-scoped object, a new prototype + bean is instantiated and then dependency-injected into the singleton + object. The prototype instance is the sole instance that is ever + supplied to the singleton-scoped object. - However, sometimes what you actually want is for the - singleton-scoped object to be able to acquire a brand new instance of - the prototype-scoped object again and again and again at runtime. In - that case it is no use just dependency injecting a prototype-scoped - object into your singleton object, because as explained above, that only - happens once when the Spring container is instantiating the singleton - object and resolving and injecting its dependencies. If you are in the - scenario where you need to get a brand new instance of a (prototype) - object again and again and again at runtime, you are referred to the - section entitled “Method Injection”. + However, suppose you want the singleton-scoped object to acquire a + new instance of the prototype-scoped object repeatedly at runtime. You + cannot dependency-inject a prototype-scoped object into your singleton + object, because that injection occurs only once, when the Spring + container is instantiating the singleton object and resolving and + injecting its dependencies. If you need a new instance of a prototype + object at runtime more than once, see . - The other scopes + Request, session and web application scopes - The other scopes, namely request, session, and application are for - use only in web-based applications. Please refer to the web documentation on object scopes for - more information. + The request, session and application + scopes are only available if you use a web-aware + Spring IApplicationContext + implementation, such as WebApplicationContext. If + you use these scopes with regular Spring IoC containers such as the + XmlApplicationContext, you will get an exception + complaining about an unknown object scope. + + Please refer to the web + documentation on object scopes for more information. @@ -3777,37 +3791,37 @@ public sealed class Font : MarshalByRefObject, ICloneable, ISerializable, IDispo Lifecycle interfaces - Spring.NET uses several marker interfaces to change the behaviour - of your object in the container, namely the Spring.NET specific - IInitializingObject interface and the standard - System.IDisposable interfaces. Implementing either of - the aforementioned interfaces will result in the container calling the + To interact with the container's management of the object + lifecycle, you can implement the Spring + InitializingObject and standard + System.IDisposable interfaces. The container calls AfterPropertiesSet() method for the former and the Dispose() method for the latter, thus allowing you to - do things upon the initialization and destruction of your - objects. + do things upon the initialization and destruction of your objects. You + can also achieve the same integration with the container without + coupling your objects to Spring interfaces though the use of + init-method and destroy-method + object definition metadata. Internally, Spring.NET uses implementations of the - IObjectPostProcessor interface to process any marker + IObjectPostProcessor interface to process any call interfaces it can find and call the appropriate methods. If you need - custom features or other lifecycle behavior Spring.NET doesn't offer + custom features or other lifecycle behavior Spring.NET does not offer out-of-the-box, you can implement an - IObjectPostProcessor yourself. More information about - this can be found in . + IObjectPostProcessor yourself. For more information + see. - All the different lifecycle marker interfaces are described - below. + IInitializingObject / <literal>init-method</literal> The Spring.Objects.Factory.IInitializingObject - interface gives you the ability to perform initialization work after - all the necessary properties on an object are set by the container. - The IInitializingObject interface specifies exactly - one method: + interface allows an object to perform initialization work after all + the necessary properties on an object are set by the container. The + IInitializingObject interface specifies a single + method: void AfterPropertiesSet(): called after all properties have been set by the container. This method @@ -3819,13 +3833,13 @@ public sealed class Font : MarshalByRefObject, ICloneable, ISerializable, IDispo - - Generally, the use of the - IInitializingObject can be avoided. The - Spring.Core library provides support for a - generic init-method, given to the object definition in the object - configuration store (be it XML, or a database, etc). - + It is recommended that you do not use the + IInitializingObject interface because it + unnecessarily coupules the code to Spring. Alternatively, specify an + POJO initialization method. In the case of XML-based configuration + metadata, you use the init-method attribute to + specify the name of the method that has a void no-argument signature. + For example, the following definition: <object id="exampleInitObject" type="Examples.ExampleObject" init-method="init"/> [C#] @@ -3835,7 +3849,8 @@ public class ExampleObject { // do some initialization work } -} Is exactly the same as... <object id="exampleInitObject" type="Examples.AnotherExampleObject"/> +}...is exactly the same as... <object id="exampleInitObject" type="Examples.AnotherExampleObject"/> [C#] public class AnotherExampleObject : IInitializingObject { @@ -3843,29 +3858,16 @@ public class AnotherExampleObject : IInitializingObject { // do some initialization work } -} but does not couple the code to Spring.NET. - - - When deploying an object in prototype mode, - the lifecycle of the object changes slightly. By definition, - Spring.NET cannot manage the complete lifecycle of a non-singleton / - prototype object, since after it is created, it - is given to the client and the container no longer keeps a reference - to the object. You can think of Spring.NET's role when talking about - a non-singleton ( prototype ) object as a - replacement for the new operator. Any lifecycle - aspects past that point have to be handled by the client. - +}... but does not couple the code to Spring.NET. IDisposable / <literal>destroy-method</literal> - The System.IDisposable interface provides you - with the ability to get a callback when an - IObjectFactory is destroyed. The - IDisposable interface specifies exactly one method: - + Implementing the System.IDisposable interface + allows an object to get a callback callback when the container + containing it is destroyed. The IDisposable + interface specifies a single method: void Dispose(): and is called on destruction of the container. This allows you to release any @@ -3873,18 +3875,19 @@ public class AnotherExampleObject : IInitializingObject connections). You can throw any Exception here... however, any such Exception will not stop the destruction of - the container - it will only get logged. + the container - it will only get logged.v - - Note: If you choose you can avoid having your class - implement IDisposable since the - Spring.Core library provides support for a - generic destroy-method, given to the object definition in the object - configuration store (be it XML, or a database, - etc). - + Since the IDisposable interface resides + in the core .NET library, it does not couple your class to Spring as + in the case with the IInitializingObject + interface. However, you may also specify a destruction method that is + not tied to the IDisposable interface. In the + case of XML-based configuration metadata, you use the + destroy-method attribute to specify the name of the + method that has a void no-argument signature. For example, the + following definition: <object id="exampleInitObject" type="Examples.ExampleObject" destroy-method="cleanup"/> [C#] @@ -3907,48 +3910,53 @@ public class AnotherExampleObject : IDisposable - Knowing who you are + IApplicationContextAware and IObjectNameAware - - IObjectFactoryAware + When an IApplicationContext creates a class + that implements the IApplicationContextAware + interface, the class is provided with a reference to that + IApplicationContext. - A class which implements the - Spring.Objects.Factory.IObjectFactoryAware - interface is provided with a reference to the - IObjectFactory that created it. The interface - specifies one (write-only) property: - - IObjectFactory ObjectFactory: the - property that will be set after the initialization - methods (AfterPropertiesSet and - the init-method). - - + public interface IApplicationContextAware { + IApplicationContext ApplicationContext { + set; + } +} - This allows objects to manipulate the - IObjectFactory that created them Programatically, - through the IObjectFactory interface, or by casting - the reference to a known subclass of this which exposes additional - functionality. Primarily this would consist of programmatic retrieval - of other objects. While there are cases when this capability is - useful, it should generally be avoided, since it couples the code to - Spring.NET, and does not follow the Inversion of Control style, where - collaborators are provided to objects as properties. - + Thus objects can manipulate programmatically the + IApplicationContext that created them, through + the IApplicationContext interface, or by casting + the reference to a known subclass of this interface, such as + IConfigurableApplicationContext, which exposes + additional functionality. One use would be the programmatic retrieval of + other objects. Sometimes this capability is useful; however, in general + you should avoid it, because it couples the code to Spring and does not + follow the Inversion of Control style, where collaborators are provided + to objects as properties. Other methods of the + IApplicationContext provide access to file + resources, publishing application events, and accessing a + IMessageSource. These additional features are + described in IObjectNameAware - The Spring.Objects.Factory.IObjectNameAware - interface gives you the ability to let the container set the name of - the object definition on the object instance itself. In those cases - where your object needs to know what its name is, implement this - interface. - - string ObjectName: the property that - will be set to let the object know what its name is. - - + When an IApplicationContext creates a + class that implements the + Spring.Objects.Factory.IObjectNameAware interface, + the class is provided with a reference to the name defined in its + associated object definition. + + public interface IObjectNameAware { + string ObjectName { + set; + } +} + + The callback is invoked after population of normal object + properties but before an initialization callback such as + IInitializingObject 's AfterPropertiesSet + method or a custom initalization method is invoked. @@ -3956,26 +3964,25 @@ public class AnotherExampleObject : IDisposable Object definition inheritance - An object definition potentially contains a large amount of - configuration information, including container specific information (i.e. - initialization method, static factory method name, etc.) and constructor - arguments and property values. A child object definition is an object - definition that inherits configuration data from a parent definition. It - is then able to override some values, or add others, as needed. Using - parent and child object definitions can potentially save a lot of typing. - Effectively, this is a form of templating. + An object definition can contain a lot of configuration information, + including constructor arguments, property values, and container-specific + information such as initialization method, static factory method name, and + so on. A child object definition inherits configuration data from a parent + definition. The child definition can override some values, or add others, + as needed. Using parent and child object definitions can save a lot of + typing. Effectively, this is a form of templating. - When working with an IObjectFactory - Programatically, child object definitions are represented by the - ChildObjectDefinition class. Most users will never work + If you work with an IApplicationContext interface programmatically, + child object definitions are represented by the + ChildObjectDefinition class. Most users do not work with them on this level, instead configuring object definitions - declaratively in something like the XmlObjectFactory. - In an XmlObjectFactory object definition, a child - object definition is indicated simply by using the parent attribute, - specifying the parent object definition as the value of this + declaratively in something like the + XmlApplicationContext. When you use XML-based + configuration metadata, you indicate a child object using the parent + attribute, specifying the parent object definition as the value of this attribute. - <object id="inheritedTestObject" type="Spring.Objects.TestObject, Spring.Core.Tests"> + <object id="inheritedTestObject" type="Spring.Objects.TestObject, Spring.Core.Tests" abstract="true"> <property name="name" value="parent"/> <property name="age" value="1"/> </object> @@ -3985,26 +3992,27 @@ public class AnotherExampleObject : IDisposable <!-- age will inherit value of 1 from parent --> </object> - A child object definition will use the object class from the parent + A child object definition uses the object class from the parent definition if none is specified, but can also override it. In the latter - case, the child object class must be compatible with the parent, i.e. it - must accept the parent's property values. + case, the child object class must be compatible with the parent, that is, + it must accept the parent's property values. - A child object definition will inherit constructor argument values, + A child object definition inherits constructor argument values, property values and method overrides from the parent, with the option to - add new values. If init method, destroy method and/or static factory - method are specified, they will override the corresponding parent + add new values. Any initialization method, destroy method and/or static + factory methods that you specify will override the corresponding parent settings. - The remaining settings will always be taken from the child + The remaining settings are always be taken from the child definition: depends on, autowire mode, dependency check, singleton, lazy init. - In the case where the parent definition does not specify a - class... - - <object id="inheritedTestObjectWithoutClass" abstract="true"> + The preceding example explicitly marks the parent object definition + as abstract using the abstract attribute. If the parent + definition does not specify a class, explicitly marking the parent object + definition as abstract is required, as follows:<object id="inheritedTestObjectWithoutClass" abstract="true"> <property name="name" value="parent"/> <property name="age" value="1"/> </object> @@ -4014,38 +4022,39 @@ public class AnotherExampleObject : IDisposable <!-- age will inherit value of 1 from parent --> </object> - ... the parent object cannot be instantiated on its own since it + The parent object cannot be instantiated on its own since it incomplete, and it is also explicitly marked as abstract. When a - definition is defined to be abstract like this, it is usable only as a - pure template object definition that will serve as a parent definition for - child definitions. Trying to use such an abstract parent object on its own - (by referring to it as a ref property of another object, or doing an - explicit GetObject() with the parent object id), - will result in an error. The container's internal + definition is abstract like this, it is usable only as a pure template + object definition that serves as a parent definition for child + definitions. Trying to use such an abstract parent object on its own, by + referring to it as a ref property of another object, or doing an explicit + GetObject() with the parent object id, returns an + error. The container's internal PreInstantiateSingletons method will completely ignore object definitions that are considered abstract. - Application contexts (but not simple object factories) will by - default pre-instantiate all singletons. Therefore it is important (at - least for singleton objects) that if you have a (parent) object - definition which you intend to use only as a template, and this - definition specifies a class, you must make sure to set the - abstract attribute to true , - otherwise the application context will actually (attempt to) - pre-instantiate the abstract object. + Application contexts pre-instantiate all singletons by default. + Therefore it is important (at least for singleton objects) that if you + have a (parent) object definition which you intend to use only as a + template, and this definition specifies a class, you must make sure to + set the abstract attribute to + true , otherwise the application context will + actually (attempt to) pre-instantiate the abstract object. - Interacting with the container + Container extension points The Spring container is essentially nothing more than an advanced - factory capable of maintaining a registry of different objects and their - dependencies. The IObjectFactory enables you to read - object definitions and access them using the object factory. When using - just the IObjectFactory you would create an instance of - one and then read in some object definitions in the XML format as follows: + factory capable of maintaining a registry of different + + objects and their dependencies. The + IObjectFactory enables you to read object definitions + and access them using the object factory. When using just the + IObjectFactory you would create an instance of one and + then read in some object definitions in the XML format as follows: [C#] IResource input = new FileSystemResource ("objects.xml"); XmlObjectFactory factory = new XmlObjectFactory(input); @@ -5869,11 +5878,12 @@ ctx.Subscribe( subscriber, typeof(MyEventPublisher) ); This IApplicationContext Event handling in the IApplicationContext is - provided through the IApplicationListener interface - that contains the single method void OnApplicationEvent( object - source, ApplicationEventArgs applicationEventArgs ). Classes - that implement the IApplicationListener interface are - automatically registered as a listener with the + provided through the IApplicationEventListener + interface that contains the single method void + HandleApplicationEvent( object source, ApplicationEventArgs + applicationEventArgs ). Classes that implement the + IApplicationEventListener interface are automatically + registered as a listener with the IApplicationContext. Publishing an event is done via the context's PublishEvent( ApplicationEventArgs eventArgs ) method. This implementation is based on the traditional @@ -5944,7 +5954,7 @@ ctx.Subscribe( subscriber, typeof(MyEventPublisher) ); This } } -public class BlackListNotifier : IApplicationListener +public class BlackListNotifier : IApplicationEventListener { // notification address @@ -5955,7 +5965,7 @@ public class BlackListNotifier : IApplicationListener set { this.notificationAddress = value; } } - public void OnApplicationEvent(ApplicationEvent evt) + public void HandleApplicationEvent(ApplicationEvent evt) { if (evt instanceof BlackListEvent) {