On Fri, Jun 6, 2008 at 1:35 PM, Ramkumar R <[EMAIL PROTECTED]> wrote:

> Hi Simon,
> After disabling most of the exceptions, now i face a problem in the itest
> validations as we generally check for the last reported problem to verify
> the results. Now due to disabled exception the processing continues furthur
> and more problems are reported even after the one we are expecting.
>
> Hence the getLastLoggedProblem method in the monitor does not help us
> anymore.
>
> I have now introduced a HashMap in the monitor to cache all the problem
> reported, so that we could analyze them and see if the expected errors are
> reported. Here is the piece of code that is being added in the monitor now.
>
> // Cache all the problem reported to monitor for furthur analysis
> private Map<String, Problem> problemCache = new HashMap<String, Problem>();
>
> public boolean isMessageLogged(String messageId) {
>   if (problemCache.containsKey(messageId)) return true;
>   else return false;
> }
>
> Like to know your thoughts on it. Thanks.
> On 6/6/08, Ramkumar R <[EMAIL PROTECTED]> wrote:
> >
> > On 6/5/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> >>
> >> >
> >> > Here the processor would never throw ContributionReadException, when
> the
> >> > exceptions are blocked as most of the ContributionReadException are of
> >> > type1, 2 or 3.
> >>
> >>
> >> Do you mean type  2, 3 & 4 here. I still expect us to throw type 1
> >> exceptions.
> >>
> > Hi Simon,
> > You are right, i meant it to be type 2, 3 & 4 exceptions here. Sorry for
> > the typo error.
> >
> > --
> > Thanks & Regards,
> > Ramkumar Ramalingam
> >
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam


Hi Ram

Sounds like a good idea. Was this added to DefaultMonitorImpl or
DefaultLoggingMonitorImpl?

Now that we have a default monitor that logs messages and is used if no
extension monitor is provided the name of the monitor-logging module looks
out of place. I'd like to rename that to be something like monitor-caching
or something similar so that your new map can go there. If people don't want
to store up monitor messages they can just drop out  that module and either
fall back to the default implementation or provide their own. Does that
sound sensible?

If so feel free to go ahead and make the code changes. If you create a new
monitor module with a suitable name I'll add the new one and delete the old
one. Don't worry about doing a patch for the rename as I imagine that could
get tricky.

Simon

Reply via email to