David,
I did implement using ConcurrentHashMap and a Memoizer. You had suggested a LockFreeHashMap in an earlier mail also. The way I did it is that once a ResourceBundle is computed, it is cached and the same ResourceBundle is never computed again. Also, if a key is not found in a properties file of a sub-package, it is looked up in the parent package and so on. On 7/27/07, David Jencks <[EMAIL PROTECTED]> wrote: > > > On Jul 27, 2007, at 4:20 PM, Karan Malhi wrote: > > > So I have re-written logging using java.util.Logging. > > Is there general agreement this is a good idea? I have yet to talk > in person to anyone who likes java.util.Logging. > > > There are some issues > > which are blockers right now > > 1. The logging levels are different between log4j and > > java.util.logging. Can > > anybody suggest how these should be mapped > > 2. Most of the logging being done right now is not using > > Messages.propertiesfile (i18n) . What i wrote, solely assumes that one > > is using the keys from > > Messages.properties. How do we want to do this, should all logging > > be done > > through Messages.properties or should one be allowed to log > > messages without > > Messages.properties. I would prefer to go through > > Messages.properties, I > > need to know your opinion. This is lots of work for me if we go > > through > > Messages.properties (and probably we can share it so that we can > > clean up > > logging faster), and I want to make sure that once we decide upon > > it, we > > stick to it. This way the logging framework itself will force the > > user to > > use Messages.properties. > > > > On 6/24/07, Karan Malhi <[EMAIL PROTECTED]> wrote: > >> > >>> So, lets say you're in package a.b.c, and call log.info(key1). > >>> If this > >> turns into > >>> log(a.b.c.key1) no matter whether the key1 was actually found in > >>> the > >>> message.properties file for package a, package a.b, or package > >>> a.b.c, > >>> I don't think there will be any collisions. > >> Correct. The second part of my email talks about "namespacing" which > >> is kind of on the same lines as what you are saying here . > >> > >>> I guess these can be combined to some extent -- precomputing all the > >>> "specified virtual keys" and then adding more as they are used. > >> What does adding more as they are used means?. Would'nt all keys be > >> "specified virtual keys" and be precomputed? I assume by pre- > >> computing > >> you mean "go through every messages.properties and cache the keys" > >> > >>> This could be a good use for the lock-free hash map :-) > >> and that would be the java.util.concurrent.ConcurrentHashMap, > >> correct? > > no, that one has plenty of locking. I was thinking of the one > described at javaone... > http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf > > thanks > david jencks > > >> > >>> thanks > >>> david jencks > >>>> > >>>> 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 > >>> > >>> > >> > >> > >> -- > >> Karan Malhi > >> > > > > > > > > -- > > Karan Singh Malhi > > -- Karan Singh Malhi
