Event system

Producing and sending an event is simple enough. But why should I go
through the dynamic proxy, with an EventProducer interface and event
model, instead of simply produce and send the event? This is the part
that makes producing and sending a new type of event difficult to
understand for me.

Simon

--
Simon Pepping
home page: http://www.leverkruid.eu

[Jeremias Maerki-2]

http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback is from the
design phase and lists the reasons:
- type safety
- check mechanism to detect missing translations
- check mechanism to make sure all necessary parameters are really dealt
with, especially when calling the same event from multiple places.

I concede that overall the whole thing might look complex, but the end
result makes for quite clean code on the message production side.

Adding a new event isn't a big deal at all:
1. Add a new method to the EventProducer interface
2. Run the "resourcegen" task to update the model and translations
3. Fill in the translation

I believe the whole thing worked out quite nicely. Only recently did I
have a chance to make use of the event subsystem on a project where I
needed to detect certain layout problems. That was easily done and works
nicely. I sometimes think this whole mechanism would even warrant it own
Apache Commons subproject.

Design discussions:
http://markmail.org/thread/bkfrub4334pcmrjd

HTH

On 22.10.2009 21:12:38 Simon Pepping wrote:

> Producing and sending an event is simple enough. But why should I go
> through the dynamic proxy, with an EventProducer interface and event
> model, instead of simply produce and send the event? This is the part
> that makes producing and sending a new type of event difficult to
> understand for me.
>
> Simon
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu

Jeremias Maerki

[Vincent Hennebert-2]

Hi,

Jeremias Maerki wrote:

> http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback is from the
> design phase and lists the reasons:
> - type safety
> - check mechanism to detect missing translations
> - check mechanism to make sure all necessary parameters are really dealt
> with, especially when calling the same event from multiple places.
>
> I concede that overall the whole thing might look complex, but the end
> result makes for quite clean code on the message production side.
>
> Adding a new event isn't a big deal at all:
> 1. Add a new method to the EventProducer interface
> 2. Run the "resourcegen" task to update the model and translations
> 3. Fill in the translation
>
> I believe the whole thing worked out quite nicely. Only recently did I
> have a chance to make use of the event subsystem on a project where I
> needed to detect certain layout problems. That was easily done and works
> nicely. I sometimes think this whole mechanism would even warrant it own
> Apache Commons subproject.
>
> Design discussions:
> http://markmail.org/thread/bkfrub4334pcmrjd

There is a fundamental flaw in the current design IMO: it’s not well
integrated with Java’s exception-handling mechanism. It’s not the job of
the event broadcaster to throw the exception, it’s the job of the client
code, using the normal exception mechanism. And it’s up to some
higher-level object to catch the exception (or not), route it to the
event notification system, and stop the application with an error code.

All that needs to be ensured is that a localized message can be
associated to the exception. Wether the exception should be an unchecked
exception or not is a design decision pertaining to the client code.
Also, whether there should be a dedicated severity level (fatal) for
exceptions is IMO debatable. I’d say that it’s not needed. The fact that
the application stops or not should be clear enough.

At the time of that discussion that was not entirely clear to me yet.


Vincent