Yep. Deployment for UT usually involves all the traditional
IT roles, just in development mode. By the time the
application gets through its initial lifecycle phases, subsequent
lifecycle phases need to be more strict. The admin role
early in the lifecycle should be very lenient as you said. The
admin role after deployment into production should be very
strict. The runtime impl/model has no way of differentiating.
There is a desire to use the same the implementation code in
the runtime in all phases of the lifecycle, so it's usually best to be
lenient in the runtime, and let the hosting environment take care
of knowing when to be strict.
I got the impression that you might have thought we were
disagreeing, but we're in violent agreement I think. To net it
out, Tuscany should be lenient in the model classes (warnings)
which enables a hosting environment with more context to
react properly.
Dave
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, March 31, 2008 3:27 PM
Subject: Re: Reporting errors for illegal SCA annotations (TUSCANY-2140)
scabooz wrote:
Hi Folks,
+1 for warnings when the application is developed. +1 for Errors when
you put the application into production. The trick is to know the
difference
between deployment for UT vs. deployment for real.
:-)
Dave
And the other trick is to allow processing of artifacts with errors to
proceed as well in dev, debug and admin scenarios as well.
For example we should be able to load a composite with errors in it, in
the admin tool, to show these errors to the administrator and allow him
to fix them.
Basically it's the same idea as a with Java editor. A Java editor that
wouldn't allow you to edit Java classes with errors wouldn't be very
useful :)
That means: Not throwing an exception that stops everything on the first
error, but instead report errors through the monitors that we already
have in various places in the code.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
