You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Karan Malhi <ka...@gmail.com> on 2007/07/28 01:20:07 UTC
Re: i18n and logging
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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
Ok, got it. Will use it to update the logging documentation this week.
On 8/5/07, David Blevins <da...@visi.com> wrote:
>
> On Aug 4, 2007, at 4:00 PM, Karan Malhi wrote:
>
> > We could javadoc the heck out of each
> >> category and then include the source file in a page on the website
> >> via the snippet plugin.
> > Very cool. I don't know anything about the snippet plugin. Looks like
> > something pretty useful , can you share some more info about this
> > plugin and its usage.
>
> We're using it in our examples .... Woops, we haven't updated them
> since our repo moved :D Ok, fixing that.
>
> Alright, check out the source on this wiki page:
> http://cwiki.apache.org/confluence/display/OPENEJB/Calculator+Session
> +Stateless+Bean+Example
>
> -David
>
>
> >
> >>
> >> -David
> >>
> >>
> >>>
> >>> On 8/1/07, Karan Malhi <ka...@gmail.com> wrote:
> >>>>> But I suppose if we had each logger return the formatted
> >>>>> message it
> >>>>> could still be fine, such as:
> >>>>>
> >>>>> String msg = logger.fatal("config.noContainerFound",
> >>>>> d.getContainerId(), d.getEjbName());
> >>>>> throw new OpenEJBException(msg);
> >>>>>
> >>>> This is a nice idea !! .
> >>>>
> >>>> --
> >>>> Karan Singh Malhi
> >>>>
> >>>
> >>>
> >>> --
> >>> Karan Singh Malhi
> >>>
> >>
> >>
> >
> >
> > --
> > Karan Singh Malhi
> >
>
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 4, 2007, at 4:00 PM, Karan Malhi wrote:
> We could javadoc the heck out of each
>> category and then include the source file in a page on the website
>> via the snippet plugin.
> Very cool. I don't know anything about the snippet plugin. Looks like
> something pretty useful , can you share some more info about this
> plugin and its usage.
We're using it in our examples .... Woops, we haven't updated them
since our repo moved :D Ok, fixing that.
Alright, check out the source on this wiki page:
http://cwiki.apache.org/confluence/display/OPENEJB/Calculator+Session
+Stateless+Bean+Example
-David
>
>>
>> -David
>>
>>
>>>
>>> On 8/1/07, Karan Malhi <ka...@gmail.com> wrote:
>>>>> But I suppose if we had each logger return the formatted
>>>>> message it
>>>>> could still be fine, such as:
>>>>>
>>>>> String msg = logger.fatal("config.noContainerFound",
>>>>> d.getContainerId(), d.getEjbName());
>>>>> throw new OpenEJBException(msg);
>>>>>
>>>> This is a nice idea !! .
>>>>
>>>> --
>>>> Karan Singh Malhi
>>>>
>>>
>>>
>>> --
>>> Karan Singh Malhi
>>>
>>
>>
>
>
> --
> Karan Singh Malhi
>
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
We could javadoc the heck out of each
> category and then include the source file in a page on the website
> via the snippet plugin.
Very cool. I don't know anything about the snippet plugin. Looks like
something pretty useful , can you share some more info about this
plugin and its usage.
>
> -David
>
>
> >
> > On 8/1/07, Karan Malhi <ka...@gmail.com> wrote:
> >>> But I suppose if we had each logger return the formatted message it
> >>> could still be fine, such as:
> >>>
> >>> String msg = logger.fatal("config.noContainerFound",
> >>> d.getContainerId(), d.getEjbName());
> >>> throw new OpenEJBException(msg);
> >>>
> >> This is a nice idea !! .
> >>
> >> --
> >> Karan Singh Malhi
> >>
> >
> >
> > --
> > Karan Singh Malhi
> >
>
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 3, 2007, at 8:26 PM, Karan Malhi wrote:
> If the logger names could be extracted to constants in an interface,
> then it will be easier to make changes to logger names and will also
> lead to lesser errors , because logger names are case sensitive
>
> So for example, instead of obtaining a logger like
>
> public static final Logger logger =
> Logger.getInstance("OpenEJB.startup",
> Assembler.class.getPackage().getName());
>
> We could do something like
>
> public static final Logger logger =
> Logger.getInstance(LogCategory.OPENEJB_STARTUP,
> Assembler.class.getPackage().getName());
>
> In fact, with static import it will just be
>
> public static final Logger logger =
> Logger.getInstance(OPENEJB_STARTUP,
> Assembler.class.getPackage().getName());
>
> LogCategory would contain the names of all loggers used in openejb.
> Since there are just a few loggers, they could be defined within the
> Logger class itself.
>
> Any thoughts on this one?
I really like the idea. We could javadoc the heck out of each
category and then include the source file in a page on the website
via the snippet plugin.
-David
>
> On 8/1/07, Karan Malhi <ka...@gmail.com> wrote:
>>> But I suppose if we had each logger return the formatted message it
>>> could still be fine, such as:
>>>
>>> String msg = logger.fatal("config.noContainerFound",
>>> d.getContainerId(), d.getEjbName());
>>> throw new OpenEJBException(msg);
>>>
>> This is a nice idea !! .
>>
>> --
>> Karan Singh Malhi
>>
>
>
> --
> Karan Singh Malhi
>
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
Yes,
I remember posting multiple patches for a couple of issues when I
joined this project ;).
On 8/21/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 8/21/07, Karan Malhi <ka...@gmail.com> wrote:
> > https://issues.apache.org/jira/browse/OPENEJB-667
>
> Done (I was worried there might've been more than one attachement, but
> luckily it was not a case).
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 8/21/07, Karan Malhi <ka...@gmail.com> wrote:
> https://issues.apache.org/jira/browse/OPENEJB-667
Done (I was worried there might've been more than one attachement, but
luckily it was not a case).
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
> Here i manage to add "startup" but don't explicitly say only on
> startup.
That clears up the confusion
> Our release is going to be awesome.
When is the release expected?
> Hey, did you see a user created an faq wiki page that basically says
> "document this", no doubt he saw one of the ones you added and took
> the liberty to do the same. Very excellent!
Yes , I saw that. Exciting!!
> > Option 3 is comparatively the easiest and the quickest to implement ,
> > because I can simply update Log4jConfigUtils with the logic you
> > provided in your email. Actually, I am most probably going to get rid
> > of the Logger.init() , Logger.initialize() and Log4jConfigUtils, so
> > that the only interaction with the Logger is through the getInstance
> > and the log methods (info, error etc)
>
> That sound fine to me. I don't know how that code got so bulky.
> You've trimmed it down some already. After this last fix it's
> finally going to be lean and mean like it should be.
I will start working on option 3 once my previous patch is committed.
Then i can check it out and modify the Logger.
>
> -David
>
>
>
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 8, 2007, at 3:45 AM, Karan Malhi wrote:
>> We'll probably need some logic like:
>>
>> - if conf/logging.properties exists, use it
>> - if conf/ directory exists, install logging.properties and use it
>> - else assume embedded and use embedded.logging.properties
>>
>> I suppose the easiest way to pull that off is to slurp in the
>> ConfUtils.getConfResource method and modify the algorithm.
>
[...]
> To obtain the effect of magical creation of the logging.properties
> file on rename or deletion, we would need to constantly poll for this
> file (something similar to what we discussed with hotdeploy and the
> DirectoryMonitor you wrote for that). I could not find that code
> depicting this behaviour in OpenEJB for Logging.
Sorry, your option 3 is what i meant -- on startup when we read the
config files.
I'm attempting to document some of these behaviors here:
http://svn.apache.org/repos/asf/openejb/trunk/openejb3/assembly/
openejb-standalone/src/main/conf/README.txt
Here i manage to add "startup" but don't explicitly say only on
startup. I'll fix that. Love getting this stuff documented and even
refined. Our release is going to be awesome.
Hey, did you see a user created an faq wiki page that basically says
"document this", no doubt he saw one of the ones you added and took
the liberty to do the same. Very excellent!
http://cwiki.apache.org/confluence/display/OPENEJB/faq_openejb-
jar.html
> 3. Don't worry about 1 and 2 above and go with the strategy that if
> the user changes or deletes this file, or if the file is absent in the
> first place, then **on restart of the server**, the file magically
> re-appears. Option 1 and 2 go with the assumption that user **does not
> restart the server** .
>
> Option 3 is comparatively the easiest and the quickest to implement ,
> because I can simply update Log4jConfigUtils with the logic you
> provided in your email. Actually, I am most probably going to get rid
> of the Logger.init() , Logger.initialize() and Log4jConfigUtils, so
> that the only interaction with the Logger is through the getInstance
> and the log methods (info, error etc)
That sound fine to me. I don't know how that code got so bulky.
You've trimmed it down some already. After this last fix it's
finally going to be lean and mean like it should be.
-David
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
> We'll probably need some logic like:
>
> - if conf/logging.properties exists, use it
> - if conf/ directory exists, install logging.properties and use it
> - else assume embedded and use embedded.logging.properties
>
> I suppose the easiest way to pull that off is to slurp in the
> ConfUtils.getConfResource method and modify the algorithm.
Thanks David, this really helps.
I have also thinking about it a little bit, did'nt devote too much
time. Having read some of your past posts on how the
logging.properties file is magically recreated when a user deletes it
or renames it has been kind of a blocker. Here is the reason:
To obtain the effect of magical creation of the logging.properties
file on rename or deletion, we would need to constantly poll for this
file (something similar to what we discussed with hotdeploy and the
DirectoryMonitor you wrote for that). I could not find that code
depicting this behaviour in OpenEJB for Logging. Part of the reason is
that i never really spent too much time digging into the code for
this.
Assuming the code was not in there, I considered some options:
1. Each time we obtain a Logger we check for the presence of this file
in the conf directory and make sure it has not changed . This will be
too expensive
2. Register Logging as a service started off by a separate thread,
this would then poll to check if the conf/logging.properties file
a. has changed , OR
b.has been deleted
If any of the above is true, reconfigure LogManager and also
clean up the Loggers cache to change Log Levels and appenders for
various Loggers already in cache. We could set a system property for
the poll interval and allow the user to configure it, or just hard
code the default.
3. Don't worry about 1 and 2 above and go with the strategy that if
the user changes or deletes this file, or if the file is absent in the
first place, then **on restart of the server**, the file magically
re-appears. Option 1 and 2 go with the assumption that user **does not
restart the server** .
Option 3 is comparatively the easiest and the quickest to implement ,
because I can simply update Log4jConfigUtils with the logic you
provided in your email. Actually, I am most probably going to get rid
of the Logger.init() , Logger.initialize() and Log4jConfigUtils, so
that the only interaction with the Logger is through the getInstance
and the log methods (info, error etc)
On 8/8/07, David Blevins <da...@visi.com> wrote:
> On Aug 4, 2007, at 10:33 PM, David Blevins wrote:
> > Just a note, seems in the standalone server most the log messages
> > wind up in system.out and not in the logs/openejb.log file. It's
> > totally cool if we have one log setup for embedded stuff (maven
> > building, etc.) and a different one for the standalone server.
>
> I applied OPENEJB-626, so we have great logging behavior for the
> embedded scenario. We still need to get a new logging setup for the
> standalone server -- they're still using the same log config.
>
>
> Fyi, to check out the server logging you can build with assemblies on
> and use the quick little 'try.sh' script that simply unpacks and
> starts the server to save some typing.
>
> $ mvn clean install -Dassemble
> $ ./assembly/openejb-standalone/try.sh
>
>
> -David
>
>
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
https://issues.apache.org/jira/browse/OPENEJB-667
Thanks !!
On 8/21/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 8/21/07, Karan Malhi <ka...@gmail.com> wrote:
>
> > Is there a way where I can get rid of my previous patch from the issue?
>
> Yes, there is. Let us know what the patch you're at and it will be wiped out.
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 8/21/07, Karan Malhi <ka...@gmail.com> wrote:
> Is there a way where I can get rid of my previous patch from the issue?
Yes, there is. Let us know what the patch you're at and it will be wiped out.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
Yes,
Makes perfect sense. Please do not apply the patch which I submitted
earlier for OPENEJB-667. I will make the above suggested changes
(because this might also require a change in pom.xml -- I hope not)
and submit a new patch.
Is there a way where I can get rid of my previous patch from the issue?
Thanks!!
On 8/20/07, David Blevins <da...@visi.com> wrote:
>
> On Aug 20, 2007, at 12:54 PM, Karan Malhi wrote:
>
> >> We'll probably need some logic like:
> >>
> >> - if conf/logging.properties exists, use it
> >> - if conf/ directory exists, install logging.properties and use it
> >> - else assume embedded and use embedded.logging.properties
> >
> > I did not use the embedded.logging.properties file because that file
> > writes all logging using ConsoleAppender's. So, I hard-coded the
> > configuration file in the Logger itself to write to
> > RollingFileAppender's. ConsoleAppenders are necessary for maven
> > builds, but I am still not comfortable with hard-coding the logging
> > configuration.
> > Could we probably have another file like build.logging.properties
> > which could be used by maven but not shipped in the final jar? This
> > way we can change embedded.logging.properties to write to the
> > RollingFileAppenders and the build.logging.properties could be used by
> > maven to write to the ConsoleAppender.
> >
> > If we make the above change, then I could use ConfUtils.getResource to
> > get the embedded.logging.properties file and use it to generate the
> > defaults if the logging.properties is absent from the conf directory.
> >
> > Let me know what you think?
>
> We should just go with logging.properties for the one that will be
> squirted into conf/ directory for the standalone server. For
> anything embedded (could be more than just tests) we should stick
> with embedded.logging.properties.
>
> Both logging.properties and embedded.logging.properties would be text
> files packed in the openejb-core.jar. Then we would follow the
> proposed algorithm:
>
> - if conf/logging.properties exists, use it
> - if conf/ directory exists, install openejb-core.jar!/
> logging.properties to conf/logging.properties and use it.
> - else assume embedded and use openejb-core.jar!/
> embedded.logging.properties
>
> The logging.properties would be setup with file appenders similar to
> the way the default.logging.properties was.
>
> That make sense?
>
> -David
>
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 20, 2007, at 12:54 PM, Karan Malhi wrote:
>> We'll probably need some logic like:
>>
>> - if conf/logging.properties exists, use it
>> - if conf/ directory exists, install logging.properties and use it
>> - else assume embedded and use embedded.logging.properties
>
> I did not use the embedded.logging.properties file because that file
> writes all logging using ConsoleAppender's. So, I hard-coded the
> configuration file in the Logger itself to write to
> RollingFileAppender's. ConsoleAppenders are necessary for maven
> builds, but I am still not comfortable with hard-coding the logging
> configuration.
> Could we probably have another file like build.logging.properties
> which could be used by maven but not shipped in the final jar? This
> way we can change embedded.logging.properties to write to the
> RollingFileAppenders and the build.logging.properties could be used by
> maven to write to the ConsoleAppender.
>
> If we make the above change, then I could use ConfUtils.getResource to
> get the embedded.logging.properties file and use it to generate the
> defaults if the logging.properties is absent from the conf directory.
>
> Let me know what you think?
We should just go with logging.properties for the one that will be
squirted into conf/ directory for the standalone server. For
anything embedded (could be more than just tests) we should stick
with embedded.logging.properties.
Both logging.properties and embedded.logging.properties would be text
files packed in the openejb-core.jar. Then we would follow the
proposed algorithm:
- if conf/logging.properties exists, use it
- if conf/ directory exists, install openejb-core.jar!/
logging.properties to conf/logging.properties and use it.
- else assume embedded and use openejb-core.jar!/
embedded.logging.properties
The logging.properties would be setup with file appenders similar to
the way the default.logging.properties was.
That make sense?
-David
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
> We'll probably need some logic like:
>
> - if conf/logging.properties exists, use it
> - if conf/ directory exists, install logging.properties and use it
> - else assume embedded and use embedded.logging.properties
I did not use the embedded.logging.properties file because that file
writes all logging using ConsoleAppender's. So, I hard-coded the
configuration file in the Logger itself to write to
RollingFileAppender's. ConsoleAppenders are necessary for maven
builds, but I am still not comfortable with hard-coding the logging
configuration.
Could we probably have another file like build.logging.properties
which could be used by maven but not shipped in the final jar? This
way we can change embedded.logging.properties to write to the
RollingFileAppenders and the build.logging.properties could be used by
maven to write to the ConsoleAppender.
If we make the above change, then I could use ConfUtils.getResource to
get the embedded.logging.properties file and use it to generate the
defaults if the logging.properties is absent from the conf directory.
Let me know what you think?
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 4, 2007, at 10:33 PM, David Blevins wrote:
> Just a note, seems in the standalone server most the log messages
> wind up in system.out and not in the logs/openejb.log file. It's
> totally cool if we have one log setup for embedded stuff (maven
> building, etc.) and a different one for the standalone server.
I applied OPENEJB-626, so we have great logging behavior for the
embedded scenario. We still need to get a new logging setup for the
standalone server -- they're still using the same log config.
We'll probably need some logic like:
- if conf/logging.properties exists, use it
- if conf/ directory exists, install logging.properties and use it
- else assume embedded and use embedded.logging.properties
I suppose the easiest way to pull that off is to slurp in the
ConfUtils.getConfResource method and modify the algorithm.
Fyi, to check out the server logging you can build with assemblies on
and use the quick little 'try.sh' script that simply unpacks and
starts the server to save some typing.
$ mvn clean install -Dassemble
$ ./assembly/openejb-standalone/try.sh
-David
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
> We should just go with logging.properties for the one that will be
> squirted into conf/ directory for the standalone server. For
> anything embedded (could be more than just tests) we could just go
> simple and call it embedded.logging.properties.
I'll make the changes
>
> For the embedded one, we'd just have everything go to system.out
I agree, no need for a RollingFileAppender for the embedded version
> we can yank the time/date stamp from the log messages.
Removing the other appenders will fix this problem automatically, the
ConsoleAppender is using a SimpleLayout , which does not print the
date/time stamp
>
> -David
>
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 5, 2007, at 11:08 PM, Karan Malhi wrote:
>> we might even be able to
>> setup the root "OpenEJB" category as additivity=false as it is now we
>> could actually turn additivity back on on all the subcategories.
>>
>> What do you think?
> I agree,OpenEJB category should control all appenders. Will fix it and
> submit a patch.
> Also, I remember reading in one of your emails that you wanted to get
> rid of the .conf files . This is a good opportunity to rename
> default.logging.conf . Since you also floated the idea of having
> separate logging configuration for testing using Maven, and the
> OpenEJB server, I was thinking of giving names like
> TestLogging.properties and OpenEJBLogging.properties for the Maven
> testing and EJB Server logging files. Maybe we could use some better
> names if anybody has any suggestions.
We should just go with logging.properties for the one that will be
squirted into conf/ directory for the standalone server. For
anything embedded (could be more than just tests) we could just go
simple and call it embedded.logging.properties.
For the embedded one, we'd just have everything go to system.out and
we can yank the time/date stamp from the log messages.
-David
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 8, 2007, at 4:03 AM, Karan Malhi wrote:
> I have added documentationi to use LogCategory createChild()
>>> method sparingly as this could again cause anyone to create a logger
>>> like
>>>
>>> Logger logger = Logger.getInstance
>>> (LogCategory.OPENEJB,"org.apache.openejb");
>>> Logger logger2 = logger.getInstance("someChild");
>
> Actually, I was thinking the following for this:
> 1. Change the visibility of LogCategory.createChild to package Level ,
> this will ensure that LogCategory is immutable outside the o.a.o.util
> package.
> 2. Users would be forced to use Logger class' getLogger(String child)
> to obtain a "derived Logger"
> 3. Log the getLogger(String child) method itself and store the log
> messages in a logger.logs file or a .logs file (which would be
> hidden). Thus we could log each such logger which was a derived Logger
> (dynamically created instead of using the LogCategory enum). The
> benefit would be that we have a record of all the derived loggers in a
> file , which will help us troubleshoot for any logging issues . This
> .logs file is the "actual diff" (the "diff" utitlity I was talking
> about) . Here is what could be added to the getLogger(String child)
> method
>
> public Logger getLogger(String child){
> Logger child = // create child logger here;
> this.debug("Created Logger "+ child.logCategory.getName(),
> this.baseName);
> }
Sounds great to me!
-David
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
Here is what could be added to the getLogger(String child)
> method
>
> public Logger getLogger(String child){
> Logger child = // create child logger here;
> this.debug("Created Logger "+ child.logCategory.getName(), this.baseName);
> }
>
Oops!! the code should be:
public Logger getLogger(String child){
Logger child = // create child logger here;
Logger logger = Logger.getInstance(LogCategory.OPENEJB,
Logger.class).getLogger("logger");
logger.debug("Created Logger "+ child.logCategory.getName(),
this.baseName);
...
...
return child;
}
--
Karan Singh Malhi
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
I have added documentationi to use LogCategory createChild()
> > method sparingly as this could again cause anyone to create a logger
> > like
> >
> > Logger logger = Logger.getInstance
> > (LogCategory.OPENEJB,"org.apache.openejb");
> > Logger logger2 = logger.getInstance("someChild");
Actually, I was thinking the following for this:
1. Change the visibility of LogCategory.createChild to package Level ,
this will ensure that LogCategory is immutable outside the o.a.o.util
package.
2. Users would be forced to use Logger class' getLogger(String child)
to obtain a "derived Logger"
3. Log the getLogger(String child) method itself and store the log
messages in a logger.logs file or a .logs file (which would be
hidden). Thus we could log each such logger which was a derived Logger
(dynamically created instead of using the LogCategory enum). The
benefit would be that we have a record of all the derived loggers in a
file , which will help us troubleshoot for any logging issues . This
.logs file is the "actual diff" (the "diff" utitlity I was talking
about) . Here is what could be added to the getLogger(String child)
method
public Logger getLogger(String child){
Logger child = // create child logger here;
this.debug("Created Logger "+ child.logCategory.getName(), this.baseName);
}
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 8, 2007, at 4:28 AM, Karan Malhi wrote:
>> You're really cooking, Karan.
>
> Well, I better cook well because I am going to eat my own food :) . I
> am actually enjoying spicing it up will cool stuff, I guess because I
> love spicy food :). Sometimes i wonder what attracted me to the
> OpenEJB project, I guess its the logo :)
There's actually a story behind that pepper. Back when the project
was started, Richard had the idea that we could title each major
release with a pepper starting low with Cayenne and eventually ending
hot with Habanero. So we used a pepper for our logo and started work
on "Cayenne". Unfortunately, some of our other ideas (like only
having an Reference Implementation for our server layer as to not
scare possible vendors that would integrate our embeddible container)
weren't so great and we never really connected with users and
therefore never became a release/community driven project. At least
not for the first two years of our existence until we moved to
Sourceforge and started work on our embedded testing, server layer,
and tomcat integration.
> On a serious note, you are being of a great great help to me.
> Sometimes I wonder how you do it, because you pretty much respond to
> all of my long , verbose emails
Heh. Well after Aaron Mulder, everyone else is cake ;)
-David
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
> You're really cooking, Karan.
Well, I better cook well because I am going to eat my own food :) . I
am actually enjoying spicing it up will cool stuff, I guess because I
love spicy food :). Sometimes i wonder what attracted me to the
OpenEJB project, I guess its the logo :)
On a serious note, you are being of a great great help to me.
Sometimes I wonder how you do it, because you pretty much respond to
all of my long , verbose emails.
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 7, 2007, at 9:10 PM, Karan Malhi wrote:
> Submitted the patch. It is OPENEJB-627 . Discovered some more Loggers
> :) . I have added documentationi to use LogCategory createChild()
> method sparingly as this could again cause anyone to create a logger
> like
>
> Logger logger = Logger.getInstance
> (LogCategory.OPENEJB,"org.apache.openejb");
> Logger logger2 = logger.getInstance("someChild");
>
> But, I think it is a good addition, as you will see in the patch, it
> was used immediately.
Excellent! I'll check it out now!
You're really cooking, Karan.
-David
> On 8/7/07, David Blevins <da...@visi.com> wrote:
>>
>> On Aug 7, 2007, at 4:47 PM, Karan Malhi wrote:
>>
>>>> Crazy. I had a similar thought (just using enums)
>>> Thats funny, when I was thinking about this, I originally started
>>> thinking with enums.
>>
>> :)
>>
>>>> So I can see some appeal to the idea. I guess if we used old
>>>> school
>>>> enums as you propose we could make it work. We just need some nice
>>>> way to create the "sub categories". Maybe we could tuck the
>>>> creation
>>>> of the non static final (the dynamically created) LogCategories
>>>> away
>>>> as in..
>>>>
>>>> // Standard setup part
>>>> private static final Logger log = Logger.getInstance
>>>> (LogCategory.OPENEJB_DEPLOY, Foo.class);
>>>>
>>>> // Now later i need to do something app specific
>>>> Logger appLog = log.getLogger("mySuperApp");
>>>>
>>>> -- - - -- - - - - - -
>>>>
>>>> Under the covers it might just be something like:
>>>>
>>>> return Logger.getInstance(this.logCategory.createChild
>>>> ("mySuperApp", this.packageName);
>>>
>>> Very cool, I was thinking how to do it, the above seems a very
>>> elegant
>>> solution. I was just thinking about the following where we pass in a
>>> string.
>>>
>>> Logger appLog = log.getLogger("mySuperApp");
>>>
>>> Is it possible to pass in some sort of custom object, like a
>>> ModuleId
>>> object or something.
>>> So, the above could look like
>>>
>>> Logger appLog = log.getLogger(ModuleId.get("mySuperApp"));
>>>
>>> And ModuleId could be something like
>>>
>>> public final class ModuleId {
>>> private String name;
>>> private ModuleId(String name){ this.name = name;}
>>> public ModuleId get(String name){return new ModuleId(name);}
>>> }
>>>
>>> I know that the above is probably slightly more convoluted than
>>> using
>>> a String, but I was thinking that a custom object would keep the
>>> Logging API "strict,tight and unambiguous".
>>
>> I think we have it right where we want it. Tight enough that no
>> logger can be created not under "OpenEJB." but with enough wiggle
>> room for future creativity -- whatever that may be.
>>
>> -David
>>
>>
>>
>>
>
>
> --
> Karan Singh Malhi
>
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
Submitted the patch. It is OPENEJB-627 . Discovered some more Loggers
:) . I have added documentationi to use LogCategory createChild()
method sparingly as this could again cause anyone to create a logger
like
Logger logger = Logger.getInstance(LogCategory.OPENEJB,"org.apache.openejb");
Logger logger2 = logger.getInstance("someChild");
But, I think it is a good addition, as you will see in the patch, it
was used immediately.
On 8/7/07, David Blevins <da...@visi.com> wrote:
>
> On Aug 7, 2007, at 4:47 PM, Karan Malhi wrote:
>
> >> Crazy. I had a similar thought (just using enums)
> > Thats funny, when I was thinking about this, I originally started
> > thinking with enums.
>
> :)
>
> >> So I can see some appeal to the idea. I guess if we used old school
> >> enums as you propose we could make it work. We just need some nice
> >> way to create the "sub categories". Maybe we could tuck the creation
> >> of the non static final (the dynamically created) LogCategories away
> >> as in..
> >>
> >> // Standard setup part
> >> private static final Logger log = Logger.getInstance
> >> (LogCategory.OPENEJB_DEPLOY, Foo.class);
> >>
> >> // Now later i need to do something app specific
> >> Logger appLog = log.getLogger("mySuperApp");
> >>
> >> -- - - -- - - - - - -
> >>
> >> Under the covers it might just be something like:
> >>
> >> return Logger.getInstance(this.logCategory.createChild
> >> ("mySuperApp", this.packageName);
> >
> > Very cool, I was thinking how to do it, the above seems a very elegant
> > solution. I was just thinking about the following where we pass in a
> > string.
> >
> > Logger appLog = log.getLogger("mySuperApp");
> >
> > Is it possible to pass in some sort of custom object, like a ModuleId
> > object or something.
> > So, the above could look like
> >
> > Logger appLog = log.getLogger(ModuleId.get("mySuperApp"));
> >
> > And ModuleId could be something like
> >
> > public final class ModuleId {
> > private String name;
> > private ModuleId(String name){ this.name = name;}
> > public ModuleId get(String name){return new ModuleId(name);}
> > }
> >
> > I know that the above is probably slightly more convoluted than using
> > a String, but I was thinking that a custom object would keep the
> > Logging API "strict,tight and unambiguous".
>
> I think we have it right where we want it. Tight enough that no
> logger can be created not under "OpenEJB." but with enough wiggle
> room for future creativity -- whatever that may be.
>
> -David
>
>
>
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 7, 2007, at 4:47 PM, Karan Malhi wrote:
>> Crazy. I had a similar thought (just using enums)
> Thats funny, when I was thinking about this, I originally started
> thinking with enums.
:)
>> So I can see some appeal to the idea. I guess if we used old school
>> enums as you propose we could make it work. We just need some nice
>> way to create the "sub categories". Maybe we could tuck the creation
>> of the non static final (the dynamically created) LogCategories away
>> as in..
>>
>> // Standard setup part
>> private static final Logger log = Logger.getInstance
>> (LogCategory.OPENEJB_DEPLOY, Foo.class);
>>
>> // Now later i need to do something app specific
>> Logger appLog = log.getLogger("mySuperApp");
>>
>> -- - - -- - - - - - -
>>
>> Under the covers it might just be something like:
>>
>> return Logger.getInstance(this.logCategory.createChild
>> ("mySuperApp", this.packageName);
>
> Very cool, I was thinking how to do it, the above seems a very elegant
> solution. I was just thinking about the following where we pass in a
> string.
>
> Logger appLog = log.getLogger("mySuperApp");
>
> Is it possible to pass in some sort of custom object, like a ModuleId
> object or something.
> So, the above could look like
>
> Logger appLog = log.getLogger(ModuleId.get("mySuperApp"));
>
> And ModuleId could be something like
>
> public final class ModuleId {
> private String name;
> private ModuleId(String name){ this.name = name;}
> public ModuleId get(String name){return new ModuleId(name);}
> }
>
> I know that the above is probably slightly more convoluted than using
> a String, but I was thinking that a custom object would keep the
> Logging API "strict,tight and unambiguous".
I think we have it right where we want it. Tight enough that no
logger can be created not under "OpenEJB." but with enough wiggle
room for future creativity -- whatever that may be.
-David
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
> Crazy. I had a similar thought (just using enums)
Thats funny, when I was thinking about this, I originally started
thinking with enums.
> So I can see some appeal to the idea. I guess if we used old school
> enums as you propose we could make it work. We just need some nice
> way to create the "sub categories". Maybe we could tuck the creation
> of the non static final (the dynamically created) LogCategories away
> as in..
>
> // Standard setup part
> private static final Logger log = Logger.getInstance
> (LogCategory.OPENEJB_DEPLOY, Foo.class);
>
> // Now later i need to do something app specific
> Logger appLog = log.getLogger("mySuperApp");
>
> -- - - -- - - - - - -
>
> Under the covers it might just be something like:
>
> return Logger.getInstance(this.logCategory.createChild
> ("mySuperApp", this.packageName);
Very cool, I was thinking how to do it, the above seems a very elegant
solution. I was just thinking about the following where we pass in a
string.
Logger appLog = log.getLogger("mySuperApp");
Is it possible to pass in some sort of custom object, like a ModuleId
object or something.
So, the above could look like
Logger appLog = log.getLogger(ModuleId.get("mySuperApp"));
And ModuleId could be something like
public final class ModuleId {
private String name;
private ModuleId(String name){ this.name = name;}
public ModuleId get(String name){return new ModuleId(name);}
}
I know that the above is probably slightly more convoluted than using
a String, but I was thinking that a custom object would keep the
Logging API "strict,tight and unambiguous".
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Aug 7, 2007, at 2:31 PM, Karan Malhi wrote:
> Here is another thought:
>
> The current getInstance method of Logger has the following signature:
> Logger getInstance(String name, String baseName)
> Logger getInstance(String name, Class clazz)
>
> If one had to obtain a Logger, it is still to easy to do something
> like
>
> Logger logger = Logger.getInstance("abc","org.apache.openejb");
>
> i.e. it is still easy to bypass the LogCategory totally. Over time,
> this might lead to a problem in that we might again end up in a
> situation where we have loggers which are lost in code and are not
> defined in log4j.configuration because nobody knows about their
> existence. I mean, you can still go and add a Category to LogCategory
> and not update log4j configuration, but this way atleast we have
> tighter control over where to look for all Categories and then update
> log4j if required.
>
> I am thinking to refactor the Logger and LogCategory as below:
>
> Logger getInstance(LogCategory category, String baseName)
> Logger getInstance(LogCategory category, Class clazz)
>
> public final class LogCategory {
> private String name;
> public static final LogCategory OPENEJB = new LogCategory
> ("OpenEJB");
> public static final LogCategory OPENEJB_STARTUP =
> new LogCategory (OPENEJB.name + ".startup");
> ...
> ...
> private LogCategory(String name){ this.name = name;}
> public String getName(){return this.name;}
> }
>
> What this also gives us is an ability to add methods, for lets say,
> generating LogCategories, given a deploymentId (David blevins idea
> about loggers with deploymentId as a suffix)
Crazy. I had a similar thought (just using enums) when I posted the
idea about the loggers with app-specific suffixes. I was typing it
up and then the older thought about wanting to have the app's
moduleId in the category came to me and the two seemed mutually
exclusive (at least with enums they would have been).
So I can see some appeal to the idea. I guess if we used old school
enums as you propose we could make it work. We just need some nice
way to create the "sub categories". Maybe we could tuck the creation
of the non static final (the dynamically created) LogCategories away
as in..
// Standard setup part
private static final Logger log = Logger.getInstance
(LogCategory.OPENEJB_DEPLOY, Foo.class);
// Now later i need to do something app specific
Logger appLog = log.getLogger("mySuperApp");
-- - - -- - - - - - -
Under the covers it might just be something like:
return Logger.getInstance(this.logCategory.createChild
("mySuperApp", this.packageName);
>
> I was also thinking about some kind of a "diff" feature, where if a
> user wanted, the user could check what Logger Categories are being
> used (we can pull them out from the Loggers cache) and what Logger
> Categories are defined in the log4j configuration file. The "diff"
> feature will simply spit out the Loggers which are not defined in the
> log4j configuration file. Since not all Logger Categories need to be
> defined in log4j configuration because the level and appenders can be
> inherited from parent Loggers, the "diff" tool could be useful in
> troubleshooting any logging issues. So where would we put this "diff"
> feature? I was thinking , it could be a part of WebAdmin.
>
We could definitely put something there. I'd have to get the
webadmin working again, but we're pretty close.
-David
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
Here is another thought:
The current getInstance method of Logger has the following signature:
Logger getInstance(String name, String baseName)
Logger getInstance(String name, Class clazz)
If one had to obtain a Logger, it is still to easy to do something like
Logger logger = Logger.getInstance("abc","org.apache.openejb");
i.e. it is still easy to bypass the LogCategory totally. Over time,
this might lead to a problem in that we might again end up in a
situation where we have loggers which are lost in code and are not
defined in log4j.configuration because nobody knows about their
existence. I mean, you can still go and add a Category to LogCategory
and not update log4j configuration, but this way atleast we have
tighter control over where to look for all Categories and then update
log4j if required.
I am thinking to refactor the Logger and LogCategory as below:
Logger getInstance(LogCategory category, String baseName)
Logger getInstance(LogCategory category, Class clazz)
public final class LogCategory {
private String name;
public static final LogCategory OPENEJB = new LogCategory("OpenEJB");
public static final LogCategory OPENEJB_STARTUP =
new LogCategory (OPENEJB.name + ".startup");
...
...
private LogCategory(String name){ this.name = name;}
public String getName(){return this.name;}
}
What this also gives us is an ability to add methods, for lets say,
generating LogCategories, given a deploymentId (David blevins idea
about loggers with deploymentId as a suffix)
I was also thinking about some kind of a "diff" feature, where if a
user wanted, the user could check what Logger Categories are being
used (we can pull them out from the Loggers cache) and what Logger
Categories are defined in the log4j configuration file. The "diff"
feature will simply spit out the Loggers which are not defined in the
log4j configuration file. Since not all Logger Categories need to be
defined in log4j configuration because the level and appenders can be
inherited from parent Loggers, the "diff" tool could be useful in
troubleshooting any logging issues. So where would we put this "diff"
feature? I was thinking , it could be a part of WebAdmin.
What do you guys think about the above?
--
Karan Singh Malhi
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
> We should probably use OpenEJB.deploy instead of
> OpenEJB.startup.config or OpenEJB.startup for all things related to
> deployment of an ear/ejb/client.
+1
>
> Not only that but I was thinking we could tack the moduleId of the
> app onto the "OpenEJB.deploy" string like such as
> "OpenEJB.deploy.mySuperEjbs" (any .jar or .ear extentions would be
> removed), then people would 1) see the app name in the log messages
> and 2) have the option to tweak log levels on individual apps.
Beautiful, this would be awesome !!
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
A thought on some of our category names....
We should probably use OpenEJB.deploy instead of
OpenEJB.startup.config or OpenEJB.startup for all things related to
deployment of an ear/ejb/client.
Not only that but I was thinking we could tack the moduleId of the
app onto the "OpenEJB.deploy" string like such as
"OpenEJB.deploy.mySuperEjbs" (any .jar or .ear extentions would be
removed), then people would 1) see the app name in the log messages
and 2) have the option to tweak log levels on individual apps.
Thoughts?
-David
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
>we might even be able to
> setup the root "OpenEJB" category as additivity=false as it is now we
> could actually turn additivity back on on all the subcategories.
>
> What do you think?
I agree,OpenEJB category should control all appenders. Will fix it and
submit a patch.
Also, I remember reading in one of your emails that you wanted to get
rid of the .conf files . This is a good opportunity to rename
default.logging.conf . Since you also floated the idea of having
separate logging configuration for testing using Maven, and the
OpenEJB server, I was thinking of giving names like
TestLogging.properties and OpenEJBLogging.properties for the Maven
testing and EJB Server logging files. Maybe we could use some better
names if anybody has any suggestions.
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
Moving the discussion back over to this thread (cleaner archives and
all that).
On Aug 5, 2007, at 2:39 PM, Karan Malhi wrote:
> Also, if you can review the Logger Categories, that would be nice.
> Some categories do not start with OpenEJB, and I was not sure about
> the reason behind it.
>
> One more thing i realized after refactoring this stuff is how easy it
> is now to configure log4j. We just have to look into the LogCategory
> interface and then make sure that the default.logging.conf is not
> missing any Logger Category (which it is right now, but can now be
> easily fixed). No need to search through code any more . :)
Exactly, I was just going to bring that up. I didn't even know we
had so many logging categories not prefixed with "OpenEJB". If we
did that and updated the logging config, we might even be able to
setup the root "OpenEJB" category as additivity=false as it is now we
could actually turn additivity back on on all the subcategories.
What do you think?
-David
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
If the logger names could be extracted to constants in an interface,
then it will be easier to make changes to logger names and will also
lead to lesser errors , because logger names are case sensitive
So for example, instead of obtaining a logger like
public static final Logger logger =
Logger.getInstance("OpenEJB.startup",
Assembler.class.getPackage().getName());
We could do something like
public static final Logger logger =
Logger.getInstance(LogCategory.OPENEJB_STARTUP,
Assembler.class.getPackage().getName());
In fact, with static import it will just be
public static final Logger logger =
Logger.getInstance(OPENEJB_STARTUP,
Assembler.class.getPackage().getName());
LogCategory would contain the names of all loggers used in openejb.
Since there are just a few loggers, they could be defined within the
Logger class itself.
Any thoughts on this one?
On 8/1/07, Karan Malhi <ka...@gmail.com> wrote:
> > But I suppose if we had each logger return the formatted message it
> > could still be fine, such as:
> >
> > String msg = logger.fatal("config.noContainerFound",
> > d.getContainerId(), d.getEjbName());
> > throw new OpenEJBException(msg);
> >
> This is a nice idea !! .
>
> --
> Karan Singh Malhi
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
> But I suppose if we had each logger return the formatted message it
> could still be fine, such as:
>
> String msg = logger.fatal("config.noContainerFound",
> d.getContainerId(), d.getEjbName());
> throw new OpenEJBException(msg);
>
This is a nice idea !! .
--
Karan Singh Malhi
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
I hope I have understood what you meant by a monitor approach instead
of direct logging. If I am on the wrong track here, please correct me.
My understanding of a monitor approach is that each component in the
application is given a Monitor Impl, using Dependency Injection
mechanism. The component uses the monitor internally, and we could
plugin a Logging implementation or some other implementation, lets
say, notifying some listeners etc. etc.
If the above is correct, then LogCategory might still be useful. So
for example, if i had
public interface OpenEJBStartupMonitor{
public void onContainerCreate();
.....
}
public class LoggingOpenEJBStartupMonitor implements OpenEJBStartupMonitor{
public static final String NAME="OpenEJB.startup";
public void onContainerCreate(){
o.a.o.util.Logger.getInstance(NAME,"baseName").info("some info");
}
}
================================================
If we went with the LogCategory thing above, then the Monitor could be
implemented as:
public class LoggingOpenEJBStartupMonitor implements OpenEJBStartupMonitor{
public static final String NAME=LogCategory.OPENEJB_STARTUP;
public void onContainerCreate(){
o.a.o.util.Logger.getInstance(NAME,"baseName").info("some info");
}
}
================================================
On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>
> On Aug 1, 2007, at 3:50 PM, David Blevins wrote:
>
> >
> > On Jul 31, 2007, at 7:23 PM, Karan Malhi wrote:
> >
> >>> 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.
> >
> > Well, we'll need to support log4j for Geronimo anyway, so we could
> > keep going with that for now. As long as we keep it hidden under
> > the Logger class we can always abstract it out later and support
> > both java.util.logging and log4j. But one change at a time, no
> > need to make this too big to solve now. The it'll be great to get
> > the hierarchical logging stuff in regardless of who is doing the
> > actual logging.
> >
> > On the note about making the logging code always do the i18n stuff
> > and assume you're passing in a message key and array of details,
> > that could work. There are a few places in the code where we need
> > to log something and throw an exception and have been doing stuff
> > like this:
> >
> > String msg = messages.format("config.noContainerFound",
> > d.getContainerId(), d.getEjbName());
> > logger.fatal(msg);
> > throw new OpenEJBException(msg);
> >
> > But I suppose if we had each logger return the formatted message it
> > could still be fine, such as:
> >
> > String msg = logger.fatal("config.noContainerFound",
> > d.getContainerId(), d.getEjbName());
> > throw new OpenEJBException(msg);
> >
> > Maybe even throw a method on the Logger to get the Messages
> > instance out so people could still use it to construct error
> > messages that aren't logged.
>
> Just in case you ever want to move to monitors instead of direct
> logging you might want to think about if and how this approach would
> work with monitors. I haven't thought about it yet myself, it might
> work great.
>
> thanks
> david jencks
>
> >
> > -David
> >
>
>
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Jencks <da...@yahoo.com>.
On Aug 1, 2007, at 3:50 PM, David Blevins wrote:
>
> On Jul 31, 2007, at 7:23 PM, Karan Malhi wrote:
>
>>> 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.
>
> Well, we'll need to support log4j for Geronimo anyway, so we could
> keep going with that for now. As long as we keep it hidden under
> the Logger class we can always abstract it out later and support
> both java.util.logging and log4j. But one change at a time, no
> need to make this too big to solve now. The it'll be great to get
> the hierarchical logging stuff in regardless of who is doing the
> actual logging.
>
> On the note about making the logging code always do the i18n stuff
> and assume you're passing in a message key and array of details,
> that could work. There are a few places in the code where we need
> to log something and throw an exception and have been doing stuff
> like this:
>
> String msg = messages.format("config.noContainerFound",
> d.getContainerId(), d.getEjbName());
> logger.fatal(msg);
> throw new OpenEJBException(msg);
>
> But I suppose if we had each logger return the formatted message it
> could still be fine, such as:
>
> String msg = logger.fatal("config.noContainerFound",
> d.getContainerId(), d.getEjbName());
> throw new OpenEJBException(msg);
>
> Maybe even throw a method on the Logger to get the Messages
> instance out so people could still use it to construct error
> messages that aren't logged.
Just in case you ever want to move to monitors instead of direct
logging you might want to think about if and how this approach would
work with monitors. I haven't thought about it yet myself, it might
work great.
thanks
david jencks
>
> -David
>
Re: i18n and logging
Posted by David Blevins <da...@visi.com>.
On Jul 31, 2007, at 7:23 PM, Karan Malhi wrote:
>> 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.
Well, we'll need to support log4j for Geronimo anyway, so we could
keep going with that for now. As long as we keep it hidden under the
Logger class we can always abstract it out later and support both
java.util.logging and log4j. But one change at a time, no need to
make this too big to solve now. The it'll be great to get the
hierarchical logging stuff in regardless of who is doing the actual
logging.
On the note about making the logging code always do the i18n stuff
and assume you're passing in a message key and array of details, that
could work. There are a few places in the code where we need to log
something and throw an exception and have been doing stuff like this:
String msg = messages.format("config.noContainerFound",
d.getContainerId(), d.getEjbName());
logger.fatal(msg);
throw new OpenEJBException(msg);
But I suppose if we had each logger return the formatted message it
could still be fine, such as:
String msg = logger.fatal("config.noContainerFound",
d.getContainerId(), d.getEjbName());
throw new OpenEJBException(msg);
Maybe even throw a method on the Logger to get the Messages instance
out so people could still use it to construct error messages that
aren't logged.
-David
>>
>>>
>>> On 7/30/07, Karan Malhi <ka...@gmail.com> 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 <ka...@gmail.com> 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 <da...@yahoo.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
>
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
> 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 <ka...@gmail.com> 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 <ka...@gmail.com> 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 <da...@yahoo.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: i18n and logging
Posted by David Jencks <da...@yahoo.com>.
On Jul 31, 2007, at 9:31 AM, Karan Malhi wrote:
> Looked into the Lock Free HashMap implementation, it uses
> sun.misc.UnSafe . Does anybody mind adding a dependency to sun.*
> classes?
yes :-( I'm afraid I got too excited about this after seeing a talk
on it at javaone, I don't think its appropriate to use in production
yet.
>
> 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.
I'm sorry if I scared you away from working on this. I think the
nested logging work is a really good idea whatever logging back end
is used. Very often which logging framework to use turns into a
religous war and I hope I didn't start one here. I haven't
actually looked into the details of any of the "logging adapters" but
I see:
-most projects seems to use a logging adapter rather than a logging
solution directly
-quite a few projects complaining about commons-logging
-quite a few projects switching to slf4j
-some complaints about java.util.logging compared to log4j.
thanks
david jencks
>
> On 7/30/07, Karan Malhi <ka...@gmail.com> 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 <ka...@gmail.com> 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 <da...@yahoo.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
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 <ka...@gmail.com> 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 <ka...@gmail.com> 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 <da...@yahoo.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
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 <ka...@gmail.com> 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 <da...@yahoo.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
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 <da...@yahoo.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: i18n and logging
Posted by Karan Malhi <ka...@gmail.com>.
> Is there general agreement this is a good idea? I have yet to talk
> in person to anyone who likes java.util.Logging.
The reason why java.util.Logging was chosen is to remove the
dependency on log4j. Is there a specific reason why people don't like
java.util.Logging?
--
Karan Singh Malhi
Re: i18n and logging
Posted by David Jencks <da...@yahoo.com>.
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 <ka...@gmail.com> 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 <da...@visi.com> 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