river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: Integrity.NO constraint results in selection of X500Provider instances
Date Thu, 29 Mar 2007 11:22:01 GMT
Mark Brouwer wrote:

> I will go through a the JTSK code and see the usage of FAILED myself, as
> well as some other pieces of code as I think most of the times I used it
> as specified for Levels.FAILED. But as I have other obligation I won't
> be able to get back to this today.

Bob,

I think the usage of FAILED is indeed consistent throughout the JTSK
code with the logging principals posted. Going through a lot of my
own code it turns out my usage has been pretty consistent with the
principals too. The principals were also made available during the Davis
project on the jini.org website and I've used them as well for Jini
based systems but I must admit since a few years I haven't looked into them.

I looked into how the callers of Discovery instances dealt with these
exceptions: in general one can say that failures for multicast discovery
are logged at the HANDLED level, while failures for unicast discovery is
logged at the INFO level, although I've seen deviations (e.g.
UnsupportedConstraintException at HANDLED and other IOExceptions at INFO).

Can you, or somebody else, explain why this sharp distinction has been made.

I have a hunch, but given the fact that when none of the multicast
providers succeed in general you have a nasty enough situation too for
which you might have wanted some logging at INFO level. At the other
hand lately I've seen enough unicast discovery failures logged at INFO
level of which I already know that I will get plenty of support
questions when these get into log files as customers hate to see
stacktraces in log files even when there is a logical explanation for
them to be there. I've had to filter in the past messages at INFO level
and to direct these to a special log file just to give people a
comfortable feeling about how the system was functioning while still
giving the ISV the ability to analyze certain problems.
-- 
Mark


Mime
View raw message