Properties are huge. I'd use properties rather than init-params unless I *knew* I had no use for sub-applications.
When you use multiple sub-applications, the properties files can give you fine-grained control over copy, media references and sub-context-specific configuration data. Meanwhile, the struts-config.xml files give you fine-grained control over workflow and the classes used as entry points into the model. So, basically, between the two of them (i.e., struts-config-xxx.xml and com.yourdomain.xxx.ApplicationResources) you can swap/override *everything* in the default application if you use them extensively enough. Not that you'd always want to do that, just that you could. It makes managing a large application easier by allowing you to throw switches at the configuration level, rather than doing everything in control logic: someone wants to buy your product but customize some algorithm, just set up a sub-app for them and change the classes corresponding to the actions involved in the actionMapping and leave the rest as is; someone wants a reskinned version of the application, just update the properties that are referred to by your html:image tags, etc. Sorry if this is review, but I just recently started getting it, and I think the 1.1 features are going to make a lot of people want to upgrade/switch once they get it. My two cents. -JT -----Original Message----- From: C F [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 22, 2002 10:02 AM To: Struts Users Mailing List Subject: Re: How to manage application properties? Excellent... thanks for the info. I probably average 5-10 properties for some of my controller servlets, so I think I'll use the init-param method as you suggested. I guess I just got confused as to why there was the ApplicationResources.properties files when we did have the init-param/servlet option available to us..... so I wasn't really sure which path I should go down. I guess that properties file is there because people will potentially have huge numbers of message resources and also enables the internationalization aspect. Appreciate the help! Eddie Bush wrote:How many "settings" do you have? Are they volatile? You could: - specify settings as an init-param to the controller servlet. - specify settings as context params - use a properties file (as you mentioned) and look it up out of the classpath To get your properties read-in, you could: - write an initialization servlet - write a context listener - write a struts plugin All that your initializer (any of them) would have to do is something like: java.io.InputStream is = .getServletContext().getResourceAsStream(configFile); The "someObject" would vary depending on which approach you took. There are methods on the Properties class to read from an InputStream. See javadoc ;-) In order to store your newly loaded properties into application scope (if they're not particular to a certain user, this is where you should put them), you'd simply do something like: .getServletContext().setAttribute("mySpecialProps", mySpecialProps); Where: - someObject varies by your implementation again - "mySpecialProps" is the key you wish to use for looking up the properties - mySpecialProps is an instance of Properties (the one you just loaded) C F wrote: >Hello, > >This is a very "newbie" question I'm sure, so this might not be the appropriate forum. Maybe it belongs in the Tomcat forum? Not sure. > >Pretty basic objective.... I just want to be able to put application settings (things like path names, integer values, etc) in a *.properties file and access those properties from within my tomcat/struts(1.1) application. I see quite a bit of talk about ApplicationResources.properties, but it seems like people are only using that to store and retrieve messages. I'd rather not mix my messages with my settings. How do you do it? I'm aware of the java.util.properties class.... but I don't really know how to efficiently use it within the application servlet context (I don't want to reload it with every request)..... and I wouldn't know when to load it into application scope..... anyway, you see that I don't have a clue. I can think of plenty of ways to do it, but I would like know the most common/accepted method(s). So any tips would be much appreciated :) > >Thanks! > -- Eddie Bush -- To unsubscribe, e-mail: For additional commands, e-mail: --------------------------------- Do you Yahoo!? New DSL Internet Access from SBC & Yahoo!
