I do not think if you just write a custom module to load properties, shindig will use it for handle properties, has a few direct references to PropertiesModule in shindig, so do not matter if you just write and load a module to load properties, shindig is still using the Properties Module.
I wrote a simple how-to to create a "out of box" project: https://cwiki.apache.org/confluence/display/SHINDIG/How+use+shindig+out+of+the+box Open a issue on JIRA and submit the patch. On Wed, Dec 15, 2010 at 7:14 PM, Ryan J Baxter <[email protected]> wrote: > Thanks for the input John. So, my original assumption is correct then? I > can provide my own properties guice module in the web.xml which loads my > own properties file and Shindig will use those properties even after I > have built Shindig? > > Maxwell, I am working on a similar project where we are investigating how > to include Shindig in an existing app, so being able to configure Shindig > after we have built it, is very important for us. > > Also this thread is kind of getting away from my original question, but I > appreciate this discussion as well. Does anyone else have any thoughts on > my original question? Its a small change and I am willing to make it. > > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > > > > From: John Hjelmstad <[email protected]> > To: [email protected] > Date: 12/15/2010 03:46 PM > Subject: Re: shindig.BaseIfrGadget Constructor > > > > The default resource path is "shindig.properties" -- PropertiesModule just > ends up delegating to ClassLoader.getResource(...) to load it. CL.gR() in > turn loads in Classpath-preferential order, so you could just stick your > own > shindig.properties file earlier in the classpath than the JAR in which > it's > packaged by default. > > Alternately, you could your own PropertiesModule, or if you don't need the > properties remove its binding. > > Best, > John > > On Wed, Dec 15, 2010 at 12:31 PM, Maxwell <[email protected]> wrote: > > > Yes, the problem is, it reads from shindig.properties and this file is > in > > shindig-common.jar, if you want or have to change a property you can > not. > > > > I think a better approach is remove this file and the container.js from > > common, the app must be responsible to put configuration files in the > > classpath, will be to much easier to do changes like the app context. > > > > I know you guys normally use shindig project as base to create a new > app, > > but some people like me, have to include shindig in a app, not as the > main > > structure, > > > > Sent from my iPhone > > > > On 15/12/2010, at 18:16, Henry Saputra <[email protected]> wrote: > > > > > Actually the PropertiesModule does load all the key-value pairs from > > > shindig.properties. > > > > > > Take a look at PropertiesModule.readPropertyFile(). > > > > > > - Henry > > > > > > On Wed, Dec 15, 2010 at 11:57 AM, Ryan J Baxter <[email protected]> > > wrote: > > >> Your right, this is my inexperience shining through here. I thought > the > > >> PropertiesModule actually loaded all the properties from > > >> shindig.properties, but I guess not. It looks like its just used to > set > > >> the values of shindig.port and shindig.host. So there is no way to > > change > > >> the property values set in shindig.properties after you have built > > >> shindig? > > >> > > >> -Ryan > > >> > > >> Email: [email protected] > > >> Phone: 978-899-3041 <tel:+19788993041> > > >> developerWorks Profile > > >> > > >> > > >> > > >> From: Maxwell <[email protected]> > > >> To: "[email protected]" <[email protected]> > > >> Date: 12/15/2010 02:41 PM > > >> Subject: Re: shindig.BaseIfrGadget Constructor > > >> > > >> > > >> > > >> Yes you can use your own version of container.js, but I do not think > you > > >> can use the same for shindig.properties. How could you do that? > > >> > > >> Sent from my iPhone > > >> > > >> On 15/12/2010, at 17:23, "Ryan J Baxter" <[email protected]> wrote: > > >> > > >>> I am not so worried about container.js and shindig.properties being > in > > a > > >> > > >>> common jar because its possible to point to your own versions of > these, > > >>> right? My understanding is that shindig.properties is loaded from a > > >> guice > > >>> module. shindig.properties also contains a property that points to > the > > >>> container.js file you want to use. So you can create your own guice > > >>> module which loads your own shindig.properties file and that > > >>> shindig.properties file can point to your own container.js file. If > I > > >> am > > >>> wrong, please let me know, because then that will cause more issues > for > > >>> me. > > >>> > > >>> To my original point in the email, I just find the way it is > currently > > >>> coded to cause people to have to do more work than they should to > > >>> implement their own container. Would anyone be against me opening a > > bug > > >> > > >>> for this and fixing it? > > >>> > > >>> -Ryan > > >>> > > >>> Email: [email protected] > > >>> Phone: 978-899-3041 <tel:+19788993041> > > >>> developerWorks Profile > > >>> > > >>> > > >>> > > >>> From: Maxwell <[email protected]> > > >>> To: "[email protected]" <[email protected]> > > >>> Date: 12/15/2010 02:16 PM > > >>> Subject: Re: shindig.BaseIfrGadget Constructor > > >>> > > >>> > > >>> > > >>> You are right, if you want to run shindig in a non-root context, you > > >> must. > > >>> Override the constructor, copy the code and change the serverBase. > > >>> > > >>> That's bad, another thing that is bad about this is the fact you > have > > >>> container.js and shindig.properties in common jar. > > >>> > > >>> If you want to create a new project and set shindig as dependence, > you > > >>> will have a lot of workaround to do that. > > >>> > > >>> Sent from my iPhone > > >>> > > >>> On 15/12/2010, at 17:03, "Ryan J Baxter" <[email protected]> > wrote: > > >>> > > >>>> I have a question about the constructor for shindig.BaseIfrGadget > in > > >>>> shindig-container.js which is part of the feature > shindig.container. > > >> Why > > >>> > > >>>> do we set the serverBase_ variable to '/gadgets/' in the > constructor > > of > > >> > > >>>> this object? Because of the way this is coded it makes it hard for > > >>>> objects extending shindig.BaseIfrGadget to override serverBase_. > For > > >>>> example, even if you wanted to override serverBase_ in the > opt_params > > >>>> passed into the constructor, you wouldn't be able to because after > we > > >>> add > > >>>> the params to the object we just set serverBase_ to '/gadgets/'. > The > > >>> only > > >>>> way to extend shindig.BaseIfrGadget and to override serverBase_ is > to > > >>>> never call the super constructor and instead put the code from the > > >>>> constructor of shindig.BaseIfrGadget in the constructor of your > > >>> extending > > >>>> class and set serverBase_ to whatever value you want. > > >>>> > > >>>> Wouldn't it be cleaner to not set serverBase_ in the > > >>> shindig.BaseIfrGadget > > >>>> constructor and instead have it as a member variable to the class > > >>> itself? > > >>>> > > >>>> -Ryan > > >>>> > > >>>> Email: [email protected] > > >>>> Phone: 978-899-3041 <tel:+19788993041> > > >>>> developerWorks Profile > > >>>> > > >>> > > >>> > > >>> > > >> > > >> > > >> > > >> > > > > > > > > > > > > -- > > > Thanks, > > > Henry > > > > > >
