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
