Actually what Shindig does by default is it looks for a file called shindig.properties on the classpath. I am guessing if you put it in WEB-INF/classes it will find that version first before it looks in the jars on the classpath. The shindig.properties file is read in by the PropertiesModule class which is instantiated by Guice when the web app starts. A more flexible approach is to inject your own properties module, allowing you to read / override properties from other means that are more flexible than a file. Then you just need to replace the PropertiesModule injected by Guice in the web.xml with your PropertiesModule class. There is an example of this in the OpenSocial Explorer [1] which actually takes the shindig.properties file from the shindig-commons project and allows users of the OpenSocial Explorer to override them with a separate properties module.
[1] https://github.com/OpenSocial/explorer/blob/master/java/server/src/main/java/org/opensocial/explorer/server/modules/ExplorerPropertiesModule.java On Fri, Sep 20, 2013 at 8:25 PM, Mike Pawlowski <mpaw...@ca.ibm.com> wrote: > > > RE: Method 2 > > I think I figured this out. > > If you place an extracted version of the "shindig.properties" file in the > "WEB-INF/classes" folder, > it takes precedence over (i.e. completely overrides) the " > shindig.properties" file in the jar file and is loaded first. > > Is that correct? > If so, why isn't the shindig.properties file just stored there by default > for easy configuration (rather than in the jar file)? > > Thanks, > > Mike > > > > ----- Forwarded by Mike Pawlowski/Toronto/IBM on 2013-09-20 08:18 PM ----- > > From: Mike Pawlowski/Toronto/IBM > To: dev@shindig.apache.org, > Date: 2013-09-20 05:59 PM > Subject: Q: What is the recommended way to modify the > shindig.properties > configuration file? > > > Hi, > > A couple novice questions: > > What is the recommended way to modify the shindig.properties configuration > file? > > I noticed that this file is located inside a jar: > /WEB-INF/lib/shindig-common-2.5.0.jar > > I'm assuming in order to modify the file you must do the following > procedure: > [Method 1]: (a) Unjar the file; (b) Modify the shindig.properties file; (c) > Rejar the file; (d) Restart the server. > Is this correct? > If so, this seems a little inconvenient / awkward from a Shindig consumer's > perspective. > As a matter of convention, I try to avoid modifying 3rd-party build > binaries (i.e. produced jars) in order to > separate user modifications from the library, version control configuration > files in a simple & atomic manner > and prevent the inadvertent introduction of errors (during the rejar step). > > [Method 2]: Or is there an alternate mechanism for providing configuration > file updates (that I'm not aware of) > that override the main configuration file in the jar (e.g. Like endorsed > dirs or environment variables, etc.)? > > Thanks, > > Mike > > > ________________________________________________________________________________ > > Mike Pawlowski > IBM Toronto Labs > Jazz Development > Loc: [ D1 / R0Q / 8200 / MKM ], PWA: 317 > Tel: (905) 413-3320, Tie: 313-3320 > Email: mpaw...@ca.ibm.com > ________________________________________________________________________________
