Good info Craig... So do I understand correctly then that you can specify multiple config files for an app regardless of module usage (well, one with just the "default" module really)? I thought I saw someone mention a CSV list in the ActionServlet init param, is that all there is to it?... If so, I don't think I was aware of that, definitely not fully anyway, and thank you for pointing it out :)
Frank -----Original Message----- From: "Craig McClanahan"<[EMAIL PROTECTED]> Sent: 6/18/05 1:05:17 AM To: "Struts Users Mailing List"<user@struts.apache.org> Subject: Re: long struts-config.xml file On 6/17/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > The longest I have is 173 action mappings. I haven't noticed any > performance problems with it. Struts basically loads it once at startup > and from then on it's in-memory, so the only potential problem I could > imagine is lookup speed, but that doesn't seem to be an issue. > In particular, all the configuration data for a single Struts module is loaded into a single set of HashMaps, no matter how many separate configuration files are used for that module. Map sizes in the hundreds are duck soup on modern JVMs. > Breaking it up makes sense as others have said from an organizational > standpoint. But, if your application doesn't make sense in multiple > modules, and some don't, then it's probably not a big problem... be sure > to have lots of comments in the config file and group things as logically > as possible, much like writing any code!, and a few hundred shouldn't be > an unmanageable number. > The largest Struts based configuration I've ever personally seen had many hundreds of actions, and a similar number of form beans and so on. They organized things with a separate configuration file for each logical segment of the applicaton (independent of whether it was going to be a separate Struts module or not). This wasn't done for performance reasons; it was much more related to code management (the config files for a particular logical segment should belong to the developers working on that segment, with the overall application architects exercising control over naming conventions to avoid conflicts). > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] [Message truncated. Tap Edit->Mark for Download to get remaining portion.] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]