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 <[EMAIL PROTECTED]> wrote:
>
> 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 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
