Geir Magnusson Jr. wrote:
/me wonders what that will do to Harmony....
I was wondering the same thing. On Geronimo, I *think* it will work as
currently done because the core jar in not placed in endorsed.dirs, so
the commons logging classes should be loadable by the core classes.
However, this really looks like a problem to me.
Rick
Rick McGuire wrote:
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
