On Wed, 16 Oct 2002, Martin Cooper wrote:
> Date: Wed, 16 Oct 2002 14:43:44 -0700
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Tiles Refactorings for 1.1 compatability
>
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, October 16, 2002 2:22 PM
> > To: Struts Developers List; [EMAIL PROTECTED]
> > Subject: Re: Tiles Refactorings for 1.1 compatability
> >
> >
> >
> >
> > On Wed, 16 Oct 2002, Ted Husted wrote:
> >
> > > Date: Wed, 16 Oct 2002 17:13:19 -0400
> > > From: Ted Husted <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> > > [EMAIL PROTECTED]
> > > To: Struts Developers List <[EMAIL PROTECTED]>
> > > Subject: Re: Tiles Refactorings for 1.1 compatability
> > >
> > > 10/16/2002 5:01:55 PM, Eddie Bush <[EMAIL PROTECTED]> wrote:
> > > >I think it's reasonable we would fix things to be
> > independent now, as
> > > >Martin and Craig have suggested, and then look at making modules
> > > >cooperate next.
> > >
> > > I'm not talking about anyting to do with modules
> > cooperating or not. I'm just saying that the supplemental
> > > Struts configuration files (for Validator and Tiles) can be
> > specified as a list, but the main struts-config
> > > cannot be. In my experience, many teams just want multiple
> > configuration files, period. This gives people what
> > > they want (multiple configs), without giving them something
> > else they might not want (Chinese walls within the
> > > application).
> > >
> > >
> >
> > Don't have time to dive into the substantive technical
> > details today, but
> > in general I'm OK with a strategy of comma-delimited list of
> > struts-config.xml resource files used to configure a single app module
> > (consistent with the Tiles and Validators styles). I presume
> > this just
> > means running as many Digester.parse() calls as you need, and no other
> > fundamental changes, right?
>
> 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.
> --
> Martin Cooper
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
