ished with RMI handle/trap API on the server. Code that is in the same JVM as the FMS can use the TrapAPI handle. 12.8 Customizing Event Processing FMS allows users and developers to customise event processing based on the type of events generated for a network or device that is to be managed. For example, to man- age a network of bridges, knowledge of the events generated can be used to configure parsers and filters that make it easier to track problems with these particular bridges. User- and developer-configured parsers and filters form an important part of the flow of an event through a system, which is shown in Figure 12.5. When traps are received by the event manager, they are passed through trap filters. Users can configure matching criteria for trap filters. As with any trap filter, a user- written trap filter could: generate a fault management event as its output generate the received trap without change drop the trap by returning null. The next step is notification to Trap Observers. If the received trap has not been dropped by any trap filter, then registered trap observers will be informed of the trap. The next step is trap parsing, which should be configured to generate useful and appropriate event information from the trap received. For example, a trap parser could be configured to set the message of Event generated simply to be the same as that of the received trap message. Whereas the output of a trap parser is an event object, events can be generated by inputs other than traps, such as events gen- erated during discovery, status polling, data collection when FMS is integrated with other NMSs or OSSs and events generated by users via the event API. Events are then passed through a series of event parsers, which may be config- ured by users for further refinement of input events. An important role of event parsers is in identifying the affected element or failure object. For example, a "link down" trap may have a router and its interface as the failure object. Using the trap and event parsers appro