> I'm sorry if I scared you away from working on this. Not at all. I learnt a lot from this discussion and the link which you sent on the "LockFree HashMap" was invaluable. It was just that I wasn't sure on what needs to be done because of different types of logging frameworks and that I do not know enough to tell which logging framework is better. I was just waiting for a concrete decision on this topic and wanted to get this issue resolved so that I could start work on some documentation stuff. > > > > > On 7/30/07, Karan Malhi <[EMAIL PROTECTED]> wrote: > >> Sorry, > >> > >> I see what you mean by a lock-free hashmap. The code is available on > >> sourceforge . I am not sure about the licensing stuff for this code > >> and need to know how to go about bringing in the jar into OpenEJB. > >> > >> On 7/27/07, Karan Malhi <[EMAIL PROTECTED]> wrote: > >>> 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 > >> > >> > >> -- > >> Karan Singh Malhi > >> > > > > > > -- > > Karan Singh Malhi > >
-- Karan Singh Malhi
