We should actually make it work like interceptors do: don't check for the class until the user actually tries to use the result type. If the user tries to use it and we don't have the class, don't just log a warning: blow up with an exception.
Bob On 8/30/06, Ted Husted <[EMAIL PROTECTED]> wrote:
In my experience, the easiest way to flatten the learning curve is consistency. Right now, our approach to default result types is inconsistent. Most results work out of the box, but some require people to add optional JARs to the distribution. For the "optional" results, we've started to add apologetic logging statements, saying "Oops, I'm here, but my JAR isn't, but you probably don't care anyway." If we are going to have optional result types, then let's have optional result types. Let's add an "optional" attribute, so that we can render more meaningful logging statements. 1 When optional=true, and the support class is absent, then nothing is logged. 2 When optional=true, and the support class is present, then a DEBUG logging statement saying the result is enabled is logged 3 When optional=false (the default), and the support class is absent, a runtime exception is logged and thrown (fail fast). 4 When optional=false, and the support class is present, then nothing is logged (the nominal case). Even if we mark a result type optional in the configuration, we can still override the setting in a package, so if we need to do a problem determination, we can add the result again as "optional=false" in a package, so that we can be sure the system sees the result, but not the JAR. -Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
