Thanks Wes -- I have a dozen (or so) namespaces that each extend a base name. My base package does some "standard" tasks, one of which is establishing a custom interceptor stack that is designated as the default. A newly added sub-package was failing to behave and it extended the base AND also a couple plug-ins. The config-browser revealed the problem! One of the plug-ins was replacing my inherited custom interceptor stack with its own.
Scott On Tue, Mar 4, 2008 at 3:25 PM, Martin Gainty <[EMAIL PROTECTED]> wrote: > first and foremost read the doc available at > http://struts.apache.org/2.x/docs/package-configuration.html > note that packages define groupings of actions, results, result types, > interceptors, and interceptor-stacks > and yes one package can extend another package by specifying > extends="base_package" > Not sure why you would want to extend multiple packages (note the use of > keyword extends vs implements) > so in the example of > <package name="fu" extends="bar"> > states every action,result,resultType,interceptor and Interceptor-stack > from > base-package "bar" will be made available to new package "fu" > perhaps you are introducing differing namespaces and causing a mismatch? > > provided we're not seeing anything company proprietary can we see the > struts.xml declaration for both packages? > > ? > Martin- > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <user@struts.apache.org> > Sent: Tuesday, March 04, 2008 3:15 PM > Subject: Re: Package extends > > > > Does anyone know what the expectations are given this scenario? All I > hear > > are crickets... > > > > On Mon, Mar 3, 2008 at 8:12 PM, <[EMAIL PROTECTED]> wrote: > > > > > config-browser doesn't deserve to be exposed to the binary mess I have > > > created! I have refactored this Struts 2 application into oblivion. > If > > > package D extends packages A, B, and C and package A has a custom > > > default-interceptor defined, shouldn't package D inherit this stack? > I > am > > > having to duplicate the stack creation from package A inside package > D! > I > > > think the only way to stop the decline of this application is to close > the > > > lid on my laptop and focus on the Kansas v. Texas Tech game. Have you > ever > > > "improved" code so much that you ended up where you began? > > > > > > Peace, > > > Scott > > > > > > > > > On Mon, Mar 3, 2008 at 7:40 PM, Wes Wannemacher <[EMAIL PROTECTED]> > wrote: > > > > > > > Scott, > > > > > > > > Would it help if you dropped the config-browser into the app and saw > how > > > > badly you have it mangled ;) > > > > > > > > -Wes > > > > > > > > On Mon, 2008-03-03 at 18:58 -0600, [EMAIL PROTECTED] wrote: > > > > > I am knee deep in a problem where I have looked at it so long that > I > > > > am > > > > > nearly wrapped around the axle. Before I get into the gory > details, > > > > what > > > > > does a package extend when it specifies the extends attribute > followed > > > > by > > > > > multiple coma separated packages? I am chiefly interested in a > > > > > default-interceptor-ref that might have been established in only > one > > > > > "parent." Should this be the stack the child adopts? I'll stop > here > > > > before > > > > > blathering on about my mess. > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > Scott > > > [EMAIL PROTECTED] > > > > > > > > > > -- > > Scott > > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Scott [EMAIL PROTECTED]
