ah. Ignore me then. Just use j.u.l please to reduce the external deps.
Rick McGuire wrote:
Geir Magnusson Jr. wrote:
Rick McGuire wrote:
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.
What I mean is, does the ORB log on the RI? I'd like to be able to
shut off logging for Harmony if so.
I believe it does. I know the IBM ORB does some very extensive logging,
so it's a similar situation. Right now, it's more of a problem that
Yoko not doing nearly enough logging.
Rick
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
