On Wed, 16 Oct 2002, Ted Husted wrote:
> Date: Wed, 16 Oct 2002 19:32:21 -0400
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: RE: Tiles Refactorings for 1.1 compatability
>
> 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.
>
Yep ... catching this particular problem is only one step along the way.
> 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+.
>
Perhaps a validate() method on ApplicationConfig that could be called once
everything has been populated, so you could at least catch everything
possible at app startup time instead of waiting to run into each specific
issue at runtime?
> -Ted.
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
