FWIW, we don't actually use PropertiesModule ourselves, except as a convenience for supplying injected values in tests. We override each of the @Named injected values w/ either command-line or dynamic flags (--foo=bar or data sourced by a dynamic config system pushed via alternate means).
The reason it's still there is simplicity: a convenient way to whip up an instance of Shindig to play. Production readiness is its own ball of wax and depends on the installation. --j On Wed, Dec 15, 2010 at 3:43 PM, Maxwell <[email protected]> wrote: > I do not like the idea to use the "classpath order" to override a resource. > > Yes I can write my own module to load the properties, it's pretty easy, but > there are few direct references to PropertiesModule in Shindig, I'm using > shindig as a dependence in a new web project, and not using the shindig > project as a "main plataform", so I still thinking that remove the > resources > from common.jar it's a better idea, that it's common for most frameworks, > like log4j when you need a properties to work properly. > > Maybe we can leave the .properties in the common, but move to a folder, and > PropertiesModule first try to read from classpath root that should be > provided by the application, if did not find, get from the default > location. > > What do you think? Remember that I'm talking about use the shinding as a > external framework, maybe you have a better idea, i'm just using shindig > for > a couple of weeks, i do not know much. > > Thanks. > > On Wed, Dec 15, 2010 at 6:44 PM, John Hjelmstad <[email protected]> wrote: > > > 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> <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> <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> <tel:+19788993041> > > > >>>> developerWorks Profile > > > >>>> > > > >>> > > > >>> > > > >>> > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > -- > > > > Thanks, > > > > Henry > > > > > >
