You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@osm.net> on 2002/06/08 08:17:49 UTC
ComponentVerifier exceptions
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
Thoughts ?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentVerifier exceptions
Posted by Peter Donald <pe...@apache.org>.
At 10:28 AM 6/8/2002 +0200, you wrote:
>>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.
Well of the things you listed, Phoenix *requires* all except
verifyServiceNotALifecycle (so that could be a warning) but in most of the
other contains many of points could be warnings. So the only thing that can
possibly be a warning is verifyServiceNotALifecycle and a generic warning
vs violation seems overkill for one case. If we put things in like
component should not extend Component interface that would be a warning but
I tried to avoid anything like that.
>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).
There is little best-practice enforced besides making sure the service
interface does not extend lifecycle interfaces. (And I think that enforcing
that is a good thing)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentVerifier exceptions
Posted by Peter Royal <pr...@apache.org>.
On Saturday 08 June 2002 02:28 am, Peter Donald wrote:
> 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.
I'd be more for something like this but I do agree that it may be overkill. I
would vote against throwing VerifyWarnings as a type of exception. Its a
warning, and processing should be able to continue.
The other option would be to pass in a callback interface. Warnings could be
reported to it, and the callback could have the verifier abort if the warning
is fatal to the hosting container.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentVerifier exceptions
Posted by Stephen McConnell <mc...@osm.net>.
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.
Agreed.
> 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
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentVerifier exceptions
Posted by Peter Donald <pe...@apache.org>.
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.
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.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>