I'm still lost here, I'm not sure how modules works in shindig, for what i understood to gadgets render works properly I have to include:
org.apache.shindig.common.PropertiesModule: org.apache.shindig.gadgets.DefaultGuiceModule: org.apache.shindig.gadgets.oauth.OAuthModule Am I wrong? Maxwell On Wed, Dec 15, 2010 at 9:50 PM, John Hjelmstad <[email protected]> wrote: > 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 > > > > > > > > > >
