You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/05/29 09:42:26 UTC
Validation Exceptions was: Re: TUSCANY-2277 & validation messages
On Wed, May 28, 2008 at 12:08 PM, Ramkumar R <ra...@gmail.com> 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 remove, by leaving the
> critical exceptions like
> a) IOException
> b) XMLStreamException
> c) PriviledegedActionException
> d) and ParseConfigurationExceptions
>
> For the above said exceptions, we need some discussion as how to handle
> them.
>
> I have now raised TUSCANY-2347 to address this issue by leaving the above
> exceptions to still throw.
>
>
snip..
Hi Ram, I want to summarize the process here and make sure we are all on the
same page. From previous ML discussions we are looking at the case where a
user provides a contribution and we want the Tuscany runtime to have the
flexibility to report as many validation exceptions as it can up front
rather than just reporting the first one.
So far the validation code has been changed so that..
A - error and warning messages have been associated with a unique ID and
have been moved into resource bundles
B - the monitor has been flowed down into the various processing objects
C - validation errors or warnings are now logged to the monitor using the
unique message ID
This leaves the validation code still throwing exceptions all over the
place. These exceptions are a mixture of things.
1 - Fundamental exceptions, such as IOException, that mean that any
subsequent processing would cause problems
2 - Validation exceptions that mean that subsequent processing would cause
problems
3 - Validation exceptions that mean that subsequent processing can continue
allowing further validation exceptions to be captured. There are probably
several levels of this, e.g. stop processing the current component but other
components can be validated.
4 - Validation exceptions that are really warnings
IIUC you are disabling type 3 and 4 exceptions to allow a greater range of
validation exceptions to be reported before validation processing stops.
What happens with type 1 and 2 exceptions. I assume that validation
processing stops after one of these exceptions. Have you had any thoughts
about how better to categorize and deal with them since your previous post?
Regards
Simon
Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages
Posted by Simon Laws <si...@googlemail.com>.
Hi Ram
On Mon, Jun 9, 2008 at 12:01 PM, Ramkumar R <ra...@gmail.com> 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 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.
Maybe our default should just set a flag if an error is ever reported while
the caching monitor saves all the errors/warnings.
boolean isErrorLogged();
>
>
> +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());
>
>
+1
> Please let me know your thoughts on this. Thanks.
>
>
Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages
Posted by Ramkumar R <ra...@gmail.com>.
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 <si...@googlemail.com> wrote:
>
> On Fri, Jun 6, 2008 at 1:35 PM, Ramkumar R <ra...@gmail.com> 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 <ra...@gmail.com> wrote:
> > >
> > > On 6/5/08, Simon Laws <si...@googlemail.com> 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
Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jun 6, 2008 at 1:35 PM, Ramkumar R <ra...@gmail.com> 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 <ra...@gmail.com> wrote:
> >
> > On 6/5/08, Simon Laws <si...@googlemail.com> 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
Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages
Posted by Ramkumar R <ra...@gmail.com>.
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 <ra...@gmail.com> wrote:
>
> On 6/5/08, Simon Laws <si...@googlemail.com> 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
Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages
Posted by Ramkumar R <ra...@gmail.com>.
On 6/5/08, Simon Laws <si...@googlemail.com> 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
Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages
Posted by Simon Laws <si...@googlemail.com>.
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 end up only throwing IOExceptions /
> XMLStreamExceptions.
>
> From stax artifact processor.
> M read(XMLStreamReader reader) throws ContributionReadException,
> XMLStreamException;
>
> 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.
>
>
> Do you believe we should maintain the current API in such cases?
>
>
>
I would leave the interface as is for the time being while we work through
the various exceptions. To see if there are any we can't deal with.
Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages
Posted by Ramkumar R <ra...@gmail.com>.
>
> On 6/3/08, Simon Laws <si...@googlemail.com> 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) throws CompositeBuilderException;
>
> I like the idea of saying NEVER throw an exception but this has to be
> restricted to well defined processing steps, e.g. those that and extension
> writer would author (Read, Write, Resolve). As an alternative and in order
> to maintain the current API such exceptions could be captured in the
> ExtensibleStAXArtifactProcessor.
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 end up only throwing IOExceptions / XMLStreamExceptions.
>From stax artifact processor.
M read(XMLStreamReader reader) throws ContributionReadException,
XMLStreamException;
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 believe we should maintain the current API in such cases?
--
Thanks & Regards,
Ramkumar Ramalingam
Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages
Posted by Simon Laws <si...@googlemail.com>.
Hi
Some comments in line....
Simon
On Mon, Jun 2, 2008 at 12:30 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> 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 or two that folk can throw rocks at if they please:
>
> - Model processor code should NEVER throw an exception that escapes the
> processor code (clearly this would exclude the common JVM nasties like
> running out of memory) - doesn't matter what type of exception (1, 2, 3, 4
> in the previous discussions...)
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) throws CompositeBuilderException;
I like the idea of saying NEVER throw an exception but this has to be
restricted to well defined processing steps, e.g. those that and extension
writer would author (Read, Write, Resolve). As an alternative and in order
to maintain the current API such exceptions could be captured in the
ExtensibleStAXArtifactProcessor.
>
> - Throwing exceptions within the scope of the model processor is fine - it
> is just that they must all get caught at the boundary of the code.
>
> - Reporting monitor type messages for the problems found (or perhaps also
> for the cases of success too!) should be routine
>
+1
>
> - When problem(s) are encountered, the model processor MUST
>
> a) Return a model object
+1
>
> b) Mark that model object as "unresolved" - this should ensure that no-one
> tries to instantiate it
Without some detailed investigation I can't say if some subsequent
resolution phase will treat the unresolved flag correctly. I would hope that
the read phase creates errors where appropriate and, subsequent to the read
phase the monitor is analysed to see if any errors have been reported.
Resolution would generally be prevented if this is the case.
>
> c) If any of the code DOES try to instantiate some unresolved model object,
> we need to go fix that code
>
+1
>
>
> We need to think hard about where particular errors should get logged
> though. Some errors will belong in the composite model object - eg a <
> binding.ws/> element turning up immediately under the <composite/>
> element. Others belong in some specific component implementation model
> object or binding object....
>
Agreed, problems should be reported in the context of the model object
within which they are being processed.
>
> Yours, Mike.
>
> snip....
Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages
Posted by Mike Edwards <mi...@gmail.com>.
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 escapes the processor code (clearly this
would exclude the common JVM nasties like running out of memory) - doesn't matter what type of
exception (1, 2, 3, 4 in the previous discussions...)
- Throwing exceptions within the scope of the model processor is fine - it is just that they must
all get caught at the boundary of the code.
- Reporting monitor type messages for the problems found (or perhaps also for the cases of success
too!) should be routine
- When problem(s) are encountered, the model processor MUST
a) Return a model object
b) Mark that model object as "unresolved" - this should ensure that no-one tries to instantiate it
c) If any of the code DOES try to instantiate some unresolved model object, we need to go fix that code
We need to think hard about where particular errors should get logged though. Some errors will
belong in the composite model object - eg a <binding.ws/> element turning up immediately under the
<composite/> element. Others belong in some specific component implementation model object or
binding object....
Yours, Mike.
Ramkumar R wrote:
> 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 furthur
> processing code. Here is an example from
> binding.jms/JMSBindingProcessor.java parseResponseActivationSpec method for
> the same.....
>
> String name = reader.getAttributeValue(null, "name");
> if (name != null && name.length() > 0) {
> jmsBinding.setResponseActivationSpecName(name);
> warning("DoesntProcessResponseActivationSpec", jmsBinding);
> //System.err.println("JMS Binding doesn't process response activationSpec
> yet");
> } else {
> warning("MissingResponseActivationSpec", reader);
> //throw new RuntimeException("missing response ActivationSpec name");
> }
>
> Here we are sure that we are not yet processing the response activationSpec,
> so we have now converted the RuntimeException as a warning message when the
> name attribute is missing for the response activationSpec.
>
> Talking about type 2 exceptions, i should say that i did some investigation
> and tried to disable them basically by two ways.....
> a) In the processor read method, we return null after disabling the
> exception if the processor ends up with type 2 exceptions.
> b) In the processor resolve method, we simply return the method by saying
> that we have not yet resolved the model by setting the isUnresolved=true.
>
> I believe disabling type 2 exceptions need a careful dealing by having an
> itest and make sure that we are not missing anything, that could lead to
> furthur problems.
>
> *NOTE:* For all the type 2 exceptions that are blocked, I believe we need to
> make sure that the runtime should investigate the monitor messages after
> reading and resolving the contribution and make sure that things are safe to
> proceed furthur for building the composite.
>
> Talking about type 1 exceptions, I believe we are still throwing the
> exceptions as it is and this would the right approach to do so. Not sure if
> there could be any good ways to disable them. Please let me know if any one
> has thoughts on this.
>
> Any comments/suggestions would help to improve the way we are trying to
> handle this. Thanks.
> On 5/29/08, Simon Laws <si...@googlemail.com> wrote:
>> On Wed, May 28, 2008 at 12:08 PM, Ramkumar R <ra...@gmail.com>
>> 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 remove, by leaving
>> the
>>> critical exceptions like
>>> a) IOException
>>> b) XMLStreamException
>>> c) PriviledegedActionException
>>> d) and ParseConfigurationExceptions
>>>
>>> For the above said exceptions, we need some discussion as how to handle
>>> them.
>>>
>>> I have now raised TUSCANY-2347 to address this issue by leaving the above
>>> exceptions to still throw.
>>>
>>>
>> snip..
>>
>> Hi Ram, I want to summarize the process here and make sure we are all on
>> the
>> same page. From previous ML discussions we are looking at the case where a
>> user provides a contribution and we want the Tuscany runtime to have the
>> flexibility to report as many validation exceptions as it can up front
>> rather than just reporting the first one.
>>
>> So far the validation code has been changed so that..
>>
>> A - error and warning messages have been associated with a unique ID and
>> have been moved into resource bundles
>> B - the monitor has been flowed down into the various processing objects
>> C - validation errors or warnings are now logged to the monitor using the
>> unique message ID
>>
>> This leaves the validation code still throwing exceptions all over the
>> place. These exceptions are a mixture of things.
>>
>> 1 - Fundamental exceptions, such as IOException, that mean that any
>> subsequent processing would cause problems
>> 2 - Validation exceptions that mean that subsequent processing would cause
>> problems
>> 3 - Validation exceptions that mean that subsequent processing can continue
>> allowing further validation exceptions to be captured. There are probably
>> several levels of this, e.g. stop processing the current component but
>> other
>> components can be validated.
>> 4 - Validation exceptions that are really warnings
>>
>> IIUC you are disabling type 3 and 4 exceptions to allow a greater range of
>> validation exceptions to be reported before validation processing stops.
>>
>> What happens with type 1 and 2 exceptions. I assume that validation
>> processing stops after one of these exceptions. Have you had any thoughts
>> about how better to categorize and deal with them since your previous
>> post?
>>
>>
>> Regards
>>
>> Simon
Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages
Posted by Ramkumar R <ra...@gmail.com>.
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 furthur
processing code. Here is an example from
binding.jms/JMSBindingProcessor.java parseResponseActivationSpec method for
the same.....
String name = reader.getAttributeValue(null, "name");
if (name != null && name.length() > 0) {
jmsBinding.setResponseActivationSpecName(name);
warning("DoesntProcessResponseActivationSpec", jmsBinding);
//System.err.println("JMS Binding doesn't process response activationSpec
yet");
} else {
warning("MissingResponseActivationSpec", reader);
//throw new RuntimeException("missing response ActivationSpec name");
}
Here we are sure that we are not yet processing the response activationSpec,
so we have now converted the RuntimeException as a warning message when the
name attribute is missing for the response activationSpec.
Talking about type 2 exceptions, i should say that i did some investigation
and tried to disable them basically by two ways.....
a) In the processor read method, we return null after disabling the
exception if the processor ends up with type 2 exceptions.
b) In the processor resolve method, we simply return the method by saying
that we have not yet resolved the model by setting the isUnresolved=true.
I believe disabling type 2 exceptions need a careful dealing by having an
itest and make sure that we are not missing anything, that could lead to
furthur problems.
*NOTE:* For all the type 2 exceptions that are blocked, I believe we need to
make sure that the runtime should investigate the monitor messages after
reading and resolving the contribution and make sure that things are safe to
proceed furthur for building the composite.
Talking about type 1 exceptions, I believe we are still throwing the
exceptions as it is and this would the right approach to do so. Not sure if
there could be any good ways to disable them. Please let me know if any one
has thoughts on this.
Any comments/suggestions would help to improve the way we are trying to
handle this. Thanks.
On 5/29/08, Simon Laws <si...@googlemail.com> wrote:
>
> On Wed, May 28, 2008 at 12:08 PM, Ramkumar R <ra...@gmail.com>
> 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 remove, by leaving
> the
> > critical exceptions like
> > a) IOException
> > b) XMLStreamException
> > c) PriviledegedActionException
> > d) and ParseConfigurationExceptions
> >
> > For the above said exceptions, we need some discussion as how to handle
> > them.
> >
> > I have now raised TUSCANY-2347 to address this issue by leaving the above
> > exceptions to still throw.
> >
> >
> snip..
>
> Hi Ram, I want to summarize the process here and make sure we are all on
> the
> same page. From previous ML discussions we are looking at the case where a
> user provides a contribution and we want the Tuscany runtime to have the
> flexibility to report as many validation exceptions as it can up front
> rather than just reporting the first one.
>
> So far the validation code has been changed so that..
>
> A - error and warning messages have been associated with a unique ID and
> have been moved into resource bundles
> B - the monitor has been flowed down into the various processing objects
> C - validation errors or warnings are now logged to the monitor using the
> unique message ID
>
> This leaves the validation code still throwing exceptions all over the
> place. These exceptions are a mixture of things.
>
> 1 - Fundamental exceptions, such as IOException, that mean that any
> subsequent processing would cause problems
> 2 - Validation exceptions that mean that subsequent processing would cause
> problems
> 3 - Validation exceptions that mean that subsequent processing can continue
> allowing further validation exceptions to be captured. There are probably
> several levels of this, e.g. stop processing the current component but
> other
> components can be validated.
> 4 - Validation exceptions that are really warnings
>
> IIUC you are disabling type 3 and 4 exceptions to allow a greater range of
> validation exceptions to be reported before validation processing stops.
>
> What happens with type 1 and 2 exceptions. I assume that validation
> processing stops after one of these exceptions. Have you had any thoughts
> about how better to categorize and deal with them since your previous
> post?
>
>
> Regards
>
> Simon
>
--
Thanks & Regards,
Ramkumar Ramalingam