So I looked for references to PropertiesModule in the src and the only references I could find were in tests. While this may not be ideal, its fine for production use since the tests won't be run in a production situation.
We are investigating using Shindig in several different applications, from web applications to desktop applications. Right now we are tackling running Shindig on another context root, something other than /. To do that we need to be able to configure Shindig, mainly the container.js and shindig.properties file, after we have already built Shindig. I have created a JIRA here https://issues.apache.org/jira/browse/SHINDIG-1484. -Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: Maxwell <[email protected]> To: [email protected] Date: 12/15/2010 06:35 PM Subject: Re: shindig.BaseIfrGadget Constructor 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 > > > > > >
