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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
