Re: minimum module requirements, that sounds right. Really though, this is pretty endemic to any project that relies heavily on Guice. You just need to make sure that all bindings (@Inject annotations throughout the code) are provided. It's both really powerful and occasionally very confusing :)
--j On Wed, Dec 15, 2010 at 4:13 PM, Maxwell <[email protected]> wrote: > 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> > <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> > <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> > <tel:+19788993041> > > > > > >>>> developerWorks Profile > > > > > >>>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Thanks, > > > > > > Henry > > > > > > > > > > > > > > >
