incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <>
Subject Re: Logging (again)
Date Thu, 02 Nov 2006 13:21:45 GMT
+1 from me.

SY, Alexey

2006/11/2, Mosur Ravi, Balaji <>:
> Hi rick,
> I think we just need to worry about the core code... The bindings &
> tools use the celtix logging utils which is just a wrapper using the
> java.util.logging classes...
> I completely agree that the core code logging definitely needs to be
> reworked...
> - Balaji
> -----Original Message-----
> From: Rick McGuire []
> Sent: Thursday, November 02, 2006 6:56 AM
> To:
> Subject: Logging (again)
> Was the logging infrastructure never implemented?  I was looking at the
> problem Dain reported, and decided a few log entries might be nice in
> this area.  When I went looking for examples of logging in the Yoko
> code, I found some things that are likely to be problems.  There are
> currently multiple methods of logging implemented in the Yoko code:
>   1. In the bindings code, java.util.logging is used, but in
>      conjunction with some celtix logging utils.
>   2. In the core code, there is a simple logging interface implemented
>      with the ORB that just does System.out.println().  Other places
>      use commons logging.
>   3. The rmi code is using java.util.logging alone.
>   4. The tools code is using java.util.logging + the celtix logging
> utils.
> When we had the vote on this issue earlier, I believe it was decided we
> should be using java.util.logging to avoid having the dependencies on
> the other projects.  It looks like the rmi code is the only one that is
> implemented that way.  I'm probably the most disturbed by the use of
> commons logging in the core code.  Implemented this way, there are
> failures lurking with the recommended method of using the Yoko ORB of
> putting the spec and core jars on either bootstrap classpath or the
> endorsed dirs classpath.  Without pulling in the commons logging jar
> too, there will be some failures occurring because those classes using
> commons logging won't be able to resolve the classes.
> For now, I think this is what needs to be done:
>   1. Rework the home grown logging implementation used in core to use
>      java.util.logging in the implementation logic.
>   2. The core code using commons logging needs to be converted over to
>      standard java.util.logging.
> Rick

View raw message