10/16/2002 6:51:23 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: >> That's one possibility, but it leaves the door wide open for people to shoot >> themselves in the foot. >> >> Consider a situation with two config files, a.xml and b.xml. Now, a.xml >> contains an action, actionA, that specifies a form bean named theBean of >> type FormBeanA, and b.xml contains an action, actionB, that specifies a form >> bean named theBean of type FormBeanB. If the config entry in web.xml lists >> a.xml before b.xml, then actionA will fail; in the other order, actionB will >> fail. An interesting one to debug... >> > >This is semantically equivalent to declaring two actions with the same >path in the same file, with equivalent results. > >> At the very least, the config reading code would need to be modified to >> throw an exception whenever a duplicate entry of any type was encountered. >> That would alleviate most of the problem, but would still leave the door >> open for an interesting debugging session if, for example, actionB >> referenced theBean, but theBean itself was accidentally omitted from b.xml >> (but still configured through a.xml). >> > >We should probably do this anyway to deal with my previous comment.
Using the same element name more than once is really only the tip of the iceberg. We can also delete or rename a form bean from the file and Struts will not catch the problem until runtime. Heck, we can set validate to true and omit the input property and not catch the problem until validate actually fails. Or now specify an input forward that doesn't exist. We can also specify entries from the Application Resources that don't exist, or ask Actions to find forwards that can't be found. Forms can specify formbean properties that don't exist, ActionMappings can specify classes that don't exist, and so on. I agree that it would be a Good Thing if someone were to write a utility that vetted the configuration to be sure all the references resolved, but doing a proper job with something like this sounds like a task for 1.1+. -Ted. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
