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
Hi Ram
On Mon, Jun 9, 2008 at 12:01 PM, Ramkumar R [EMAIL PROTECTED] wrote:
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
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,
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
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
Hi
More comments in line
Simon
Hi Simon,
Initially our idea was to disable most of the exception throws from the
processors and log the warnings/exception via the monitors. Lets say we
might still leave some exceptions to be thrown like the type1 exceptions,
in
such cases me might
Hi
Some comments in line
Simon
On Mon, Jun 2, 2008 at 12:30 PM, Mike Edwards
[EMAIL PROTECTED] wrote:
Folks,
Thinking about this further, we should I think come up with a common and
consistent model for the handling of problems found during model processing.
Let me make a proposal
On 6/3/08, Simon Laws [EMAIL PROTECTED] wrote:
How do we define the processor code? Here are a couple of examples.
From stax artifact processor.
M read(XMLStreamReader reader) throws ContributionReadException,
XMLStreamException;
From composite builder
void build(Composite composite)
Folks,
Thinking about this further, we should I think come up with a common and consistent model for the
handling of problems found during model processing.
Let me make a proposal or two that folk can throw rocks at if they please:
- Model processor code should NEVER throw an exception that
On Wed, May 28, 2008 at 12:08 PM, Ramkumar R [EMAIL PROTECTED] wrote:
Hi Simon,
After introducing the monitors in various part of the code. Now I am
trying
to remove the exception that are being thrown from these modules. As a
first
step we are removing the exceptions that are safe to
Hi Simon,
Thanks for summarizing. You are right, currently i am working on to disable
type 3 4 exceptions to allow the runtime to catch the maximum number of
user-input errors that can be reported in one-go. I don't see much issue in
disabling such exceptions as they are mostly harmless for the
Hi Simon,
After introducing the monitors in various part of the code. Now I am trying
to remove the exception that are being thrown from these modules. As a first
step we are removing the exceptions that are safe to remove, by leaving the
critical exceptions like
a) IOException
b)
Hi Simon,
I like to apologize for the inconvenience caused due to the huge patch file
for TUSCANY-2329 and for the .pom missed out in the patch.
The remaining itests for the validation messages are now available with
TUSCANY-2338 along with the fix required for the test failure in
On Tue, May 20, 2008 at 11:19 AM, Ramkumar R [EMAIL PROTECTED] wrote:
Thanks Simon, itests for these validation messages are now available with
TUSCANY-2329.
On 5/19/08, Simon Laws [EMAIL PROTECTED] wrote:
I've just checked in Ram's patch to convert validation messages (i.e.
those
On Wed, May 21, 2008 at 10:06 AM, Simon Laws [EMAIL PROTECTED]
wrote:
On Tue, May 20, 2008 at 11:19 AM, Ramkumar R [EMAIL PROTECTED]
wrote:
Thanks Simon, itests for these validation messages are now available with
TUSCANY-2329.
On 5/19/08, Simon Laws [EMAIL PROTECTED] wrote:
I've
Thanks Simon, itests for these validation messages are now available with
TUSCANY-2329.
On 5/19/08, Simon Laws [EMAIL PROTECTED] wrote:
I've just checked in Ram's patch to convert validation messages (i.e. those
messages indicating that the user have provided invalid input of some form)
to
I've just checked in Ram's patch to convert validation messages (i.e. those
messages indicating that the user have provided invalid input of some form)
to resource bundles and pass them through the Monitor. We need to take
account of this change as we change or add code to do with validation.
17 matches
Mail list logo
