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