Looked into the Lock Free HashMap implementation, it uses sun.misc.UnSafe . Does anybody mind adding a dependency to sun.* classes?
Also, I am not sure what logging framework is to be used. According to David Jencks, its not something which is popular, according to some previous discussions we had on the list, we wanted to move away from log4j. I am just going to leave this issue for the moment till the above things are resolved. If anybody wants to take over this issue from me, please feel free . It is hard for me to take decisions and I would rather somebody with commit rights work on this to get the logging issues resolved. 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
