directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject [OSGi] Issues with i18n - Summary of IRC Conversations
Date Thu, 13 Jan 2011 18:42:33 GMT
Knowns
----------

The shared i18n module is a simple module with a single class and a
data files for mapping error codes into internationalized error
messages. This is used by the server to manage the various error codes
whether returning them with LDAP responses or writing messages to the
logs.

We store all the messages here regardless of whether or not they are:

    (1) generic messages that never change over time, or
    (2) very specific messages associated with a feature or
functionality that may change or be appended over time.

Virtually everything depends on the i18n module and it depends on
nothing but an external logging API.


Problem
-----------

In an OSGi environment, we're eventually going to turn various
facilities inside the server into OSGi bundles. We already agreed to
do this for shared for solving some of the refactoring issues we have
because of the Studio build.

When this is done in any project, ideally you want to be able to
update one module without having to trigger the update of other
modules. For example, the LDAP protocol bundle has a new extended
operation added bumping the version up from 1.3.8 to 1.4.0. The new
extended operation, introduces some new error codes specific to it's
function. This should not have to then require us to bump up the
version of the shared-i18n module to the next version to add these new
messages to the i18n data files.

This is not the worst of it though. Say if some way we only had to
update the LDAP protocol bundle, then things are great and even
micro-reboots, without requiring a full shutdown of the server will
work. The old 1.3.8 version is kept to complete outstanding requests
while all new requests are handled using the 1.4.0 version. When all
the previous requests are complete then the 1.3.8 version instance is
cleaned up. The update to version 1.4.0 occurs without downtime.
Beautiful !!!

Now the nice picture will turn into a nightmare if the i18n bundle
needs to be updated as well. Why? Well since almost everything depends
on it, this module will force a full restart of the server most
likely. Everything that depends on it will have to be restarted.
Effectively that's everything.


Solution
-----------

Some generic messages that obviously will never really change,
especially as new features are added like i.e. the messages for
certain LDAP error codes. If they do change they won't change because
we added an extra extended operation or control some new neat
interceptor.

What we need to do is store these relatively static messages in
shared-i18n, yet move out the message to specific functionality to
reside in their own bundles. So all it takes is an update to the
bundle to handle a change to these messages and micro-reboots are
possible.

Mechanism wise I don't have any idea yet but it should be simple.
Perhaps since every module logs pretty much then every module should
have it's own i18n class extending the base class in shared-i18n to
add its own error messages to the mix. Am just thinking out loud here.

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Mime
View raw message