incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nolan, Edell" <>
Subject RE: Logging (again)
Date Thu, 02 Nov 2006 13:34:46 GMT

+1 for me too.

We did have this discussion around the vote to which logging mechanism
we would use. 
But I guess nobody got around to changing the core.

I will log this as a jira issue.


-----Original Message-----
From: Mosur Ravi, Balaji [] 
Sent: 02 November 2006 13:10
Subject: RE: Logging (again)

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

- Balaji

-----Original Message-----
From: Rick McGuire []
Sent: Thursday, November 02, 2006 6:56 AM
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

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.


View raw message