avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: ComponentVerifier exceptions
Date Sat, 08 Jun 2002 08:28:54 GMT

Peter Donald wrote:

> At 08:17 AM 6/8/2002 +0200, you wrote:
>> The current implementation of ComponentVerifier does not make a 
>> distinction between a verification error and a verification warning.  
>> I think we should consider the addition of a VerifyWarning as a type 
>> of exeception that can be thrown during verification  that indicates 
>> bad practice.
>> For example, a component implementing both Composable and Serviceable 
>> is inconsitent but computationally possible.  Such a condition could 
>> throw a VerificationWarning as opposed to the current VerifyException 
>> (the same case applies for the mixing of Parameterizable and 
>> Configurable) thrown by the verifyLifecycle method.
>> VerifyWarning candidates include:
>>  verifyPublic
>>  verifyLifecycles
>>  verifyServiceIsaInterface
>>  verifyServiceNotALifecycle
> If there is a such a thing as a warning it should result in error 
> message but the rest of verification process should continue or else 
> later stages in container managing will fail.


> So I think if a container wishes for certain things to be warnings 
> then they should subclass the verifier to perform their container 
> specific validations.

I don't think verification is container specific (at least in general). 
 The sort of things I'm differentiating here are not container related - 
they are best practice related.

When verifying a component its a similar action to compiling some code - 
we get errors and warning with references to what/where things went 
wrong.  The VerifyException effectively terminates the verification 
process (which is the right thing to do when an the condition 
invalidates futher processing of the model).  However, we don't have a 
mechanisms for filtering back warning messages.

> The other alternative would be to create a VerifyEvent + 
> VerifyListener but I played with that for a while and the added 
> complexity was not justified given the added complexity it would 
> introduce.

If a empty list is passed in as an argument to any verification method, 
and the list is used exclusively for the attribution of warnings (e.g. 
list.add( warning ) ) it seems that the level of complexity inside the 
respective verification method implementations should be limited to (a) 
including the list in any sub-verification method calls, (b) in the case 
of a warning condition - adding a string message to the list describing 
the warning condition, and (c) in the case of an error condition, 
passing the list as an argument to VerifyException constructor.  The 
client invoking the verification can then validate technical integrity 
(i.e. no VerifyException thrown) and verify best practice by checking 
the list content.

The big plus is that build time verification can be treated differently 
to runtime verification.  At build time we may want to spit out messages 
and complain loudly (e.g. using an verify ant task that is aiming to 
ensure developer best-practice), but at runtime its a kernel that is 
verifying that it can load and deploy the component - in which case we 
will want to be more flexible (because the prime objective is 
deployment, not best-practice).

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message