Hi,
I have been thinking about how we should handle notification of exceptions
and events in the kernel and this relates to i18n. First i18n.
There is a number of ways of doing it. A standard way in the java world is
to associate each message with a pair. The pair being the name of bundle
and name of message in bundle. So you would have "kernel.state", "startup"
as one message and for english it may extract out a string "Entry %s has
started up". This is stored in separate text files.
The other approach is to use numeric values ie event 53124 is "Entry %s has
started up" and these may be held in a constants interface.
Approach 1 is very good for small systems and is very extensible. It is
however very difficult to validate it - you end up having to virtually run
through the code to see if the bundle/message pair actually exists for any
particular language.
Approach 2 is much easier to validate but is much harder to extend. It
scales to massive architectures and many languages.
Votes/Opinions on either one ?
The next issue is how to deal with logging/notification/exception. I looked
at a few architectures and the best of them followed an Aspect Orientated
Programming approach. They had interface to listeners for each slice
through the system. So in the end you may have a collection of interfaces
such as
ApplicationErrorHandler
KernelErrorHandler
BlockErrorHandler
KernelStatusListener
ApplicationStatusListener
BlockStatusListener
These can be as fine grain or as coarse as is deemed necessary. Now where
we previously had
try
{
}
catch( final Exception e )
{
final String message = ...;
getLogger().warn( message, e );
throw new MyException( message, e );
}
it would now be either
try
{
}
catch( final Exception e )
{
m_errorListener.errorDoingX( ..., e );
}
or
try
{
}
catch( final Exception e )
{
m_errorListener.errorDoingX( ..., e );
throw e;
}
The second form would force errors to be propogated while the first would
allow the actual handler to decide the policy. This may be useful if you
wanted to plough ahead with kernel running even though an application
failed etc. Policy when responding to such execptions is taken from Fedes
wishes and is similar to SAX model and discussed Ant model.
A lot of the logging throughout the kernel/application would also be
replaced my calling into event listeners. ie instead of
getLogger().info( "Entry " + name + " did something " );
It would be
m_eventListener.somethingOccuredTo( name );
It would be inside each of these listeners/handlers that the events would
use a i18n scheme outlined above.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
