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 <[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
