> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 3:51 PM
> To: Struts Developers List
> Subject: RE: Tiles Refactorings for 1.1 compatability
>
>
>
>
> 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.
That's true. However, I think it's more likely to be a problem when there
are multiple files, especially if different people are working on those
files. A well-defined naming convention would be a necessity.
>
> > 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.
Good point.
--
Martin Cooper
>
> > --
> > Martin Cooper
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
