So I have re-written logging using 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? > > > 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
