Walking forward or backward on demand would lead to a conflict like
above, because what if because of an if condition or something
SomeCoreClass is used first and its message is cached, at that
point
StatelessContainer will show the wrong message.
With unrolling upfront, the question is where do we stop
looking. Does
the first key found win or the last key found win if there were
duplicates in different Messages.properties. In either case, if
a key
wins, it might cause the same problem I described above.
Overriding should not be allowed. Key names should be unique and we
should encourage to keep them unique, this will reduce the work we
will have to do to keep track of overriding rules etc. The rule
could
be simple, first look in the parent, if not look in the child or
the
reverse look in same package, then look in parent.
What I would suggest is also writing a TestCase which would
search all
Messages.properties and fail on finding a duplicate key. This
way if
anybody added a key and ran the build, they would be able to
immediately catch a duplicate key . The point I am trying to
make is
to enforce a little rule to not allow naming duplicate keys , which
means overriding of keys would not be permitted. I think this will
save tons of time for newcomers who might accidentally add a key
and
then ponder over the output for hours as to why they are not
getting
the correct message (just because some other key somewhere
overrode it
because it was found first and cached). This will also be
effective in
terms of performance and caching.
Another option is that if we do want to allow duplicates,
because lets
say I dont want to think about where other keys were declared
and what
were their names, i.e. a key belongs to a package kind of scenario,
the cache should namespace the keys with the package name.
So for example, org/apache/openejb/Messages.properties has a
classNotFound key, then after namespacing, the "real key" would be
org.apache.openejb.classNotFound. This is another way we can avoid
conflicts in the cache. But we should look for a key in the same
package first.
But in this scenario we will have to make the "decision " in the
cache
itself. Lets say for example,
A org/apache/openejb/Messages.properties , classNotFound= Msg A
B org/apache/openejb/core/Messages.properties
org.apache.openejb.core.SomeCoreClass references classNotFound.
Since
there is not classNotFound in its Messages.properties, it looks
it up
in the parent i.e. org.apache.openejb. This is where it finds
the key
and stores it in the cache as org.apache.openejb.classNotFound.
and so
on.
So if SomeCoreClass references classNotFound, the cache should be
searched for org.apache.openejb.core.classNotFound, then it
should be
searched for org.apache.openejb.classNotFound.
To me caching everything upfront looks like a good option
If we are searching on demand, then when we search a properties
file,
we should cache all the properties instead of finding a property
and
just caching that property. This will make sure we dont hit the
same
properties file twice.
On 6/21/07, David Blevins <[EMAIL PROTECTED]> wrote:
There have been a couple things I thought would be neat
additions for
the i18n side of our logging code. Basically, inheritance.
Say you have the following Messages.properties files in the
classpath.
A org/apache/openejb/Messages.properties
B org/apache/openejb/core/Messages.properties
C org/apache/openejb/core/stateless/Messages.properties
Then you have a class such as
org.apache.openejb.core.stateless.StatelessContainer (note the
package)
If that class referenced a message key "classNotFound" for
example,
the i18n code would look for the message first in
Messages.properties
C, then B, then A and so on until it found the required message.
This would allow better reuse of messages, more flexibility in
where
we put the Message.properties properties files, as well as the
added
bonus in that we no longer need to pass in the location of
where our
Message.properties file is like we do now -- we'd just use the
class'
package name.
The trick would be performance. On that regard we could unroll
upfront and do no backwards walking during actual usage or we
could
backwards walk on demand and cache for future lookups. Maybe some
other clever tricks we could do.
Thoughts?
-David
--
Karan Malhi
