Hi Simon,
I believe both the DefaultMonitorImpl and DefaultLoggingMonitorImpl would
need this change in them and also believe that any new monitor
implementation should follow the same.
The reason why I feel so is that, our aim of blocking the exception from
the code is to collect as many user-input errors from various processors.
And at the later stage our runtime should have a provision to take a
revision on these reported issues from the monitor and decide if the furthur
processing can be carried out or not.
Currently I have made the changes in both the modules, please let me know
your thoughts on this.
+1 for the change in module name as monitor-cache.
Also I noticed that, when a warning/error message is thrown from the
monitor, for most of the instance it does not show the sourceClassName where
it originated from. Hence I believe a change is also required in the way we
log.... something like this.
problemLogger.logp(Level.SEVERE, problem.getSourceClassName(),
null, problem.getMessageId(),
problem.getMessageParams());
Please let me know your thoughts on this. Thanks.
On 6/6/08, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> 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
>
--
Thanks & Regards,
Ramkumar Ramalingam
