Re: Define container.js in a war project

2011-01-24 Thread franck tankoua 
Thank you Maxwell.

I had that configuration.  Now I have create a CustomPropertiesModule like
you suggested in this thread. This works great for me and I am not oblige to
patch my local version of Shindig anymore.

Thanks.


On Fri, Jan 21, 2011 at 6:29 AM, Xandeco, Maxwell
maxwell.xand...@gft.comwrote:



 The way I use shindig it's as a dependence in my own project., basically
 this way:


 https://cwiki.apache.org/confluence/display/SHINDIG/How+use+shindig+out+of+the+box

 Maxwell
 
 De: franck tankoua [ftank...@gmail.com]
 Enviado: quinta-feira, 20 de janeiro de 2011 20:53
 Para: dev@shindig.apache.org
 Assunto: Re: Define container.js in a war project

 Thank you all.
 I like the final Idea from Maxwell.
 I think it is a good idea to give a possibilities to handle custom
 resources
 ourselves.
 I will try to install the properties from my shindig module.

 Just FYI, I am using in my project a dependency on shindig and I do not
 want
 to patch shindig jar in my environment if I want to change some default
 properties.

 Thanks a lot.

 On Wed, Jan 19, 2011 at 7:53 PM, Maxwell mchiar...@gmail.com wrote:

  I do not like the idea to work with classpath priorities, I did create
 a
  simple PropertiesModule in my project, something like:
 
  CustomPropertiesModule extends AbstractModule {
 
  public void configure(){
  install(new PropertiesModule(your-properties-file);
  }
 
  }
 
  I think would be a better approach, move all resources out of common-jar,
  and let final apps handle it.
 
  Cheers.
  Maxwell
 
  On Wed, Jan 19, 2011 at 8:58 PM, Paul Lindner lind...@inuus.com wrote:
 
   You can provide your own shindig.properties by putting it in a local
   classpath before the shindig jar.  You might consider implementing a
   system property to override the path (look at how we did it with
   shindig.port)
  
  
   On Wed, Jan 19, 2011 at 2:47 PM, Ryan J Baxter rjbax...@us.ibm.com
   wrote:
Hi Franck,
   
The container.js is specified in the shindig.properties file, which
  lives
in the shindig-common jar.  Since it's jarred up you cannot easily
 edit
   it
in the war.  One option would be to replace the PropertiesModule
 guice
module and point it to your own shindig.properties file and in that
  file
point it to your modified container.js file.
   
Another option would be to just modify the container.js file in
WEB-INF/classes/containers/default.
   
-Ryan
   
Email: rjbax...@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
   
   
   
From:   franck tankoua ftank...@gmail.com
To: dev@shindig.apache.org
Date:   01/19/2011 02:30 PM
Subject:Define container.js in a war project
   
   
   
Hi All,
   
Could someone help me on this.
I have thought it was possible through the WEB.xml or through the
 guice
module.
   
I cannot do something like the following as it is throwing A binding
  to
java.lang.String annotated with
@com.google.inject.name.Named(value=shindig.containers.default) was
already
configured :
{{{
   
  
 
 bindConstant().annotatedWith(Names.named(shindig.containers.default)).to(shindig/container.js);
}}}
   
Thanks
   
--
Franck
   
   
   
   
  
  
  
   --
   Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner
  
 



 --
 Franck




-- 
Franck

Re: Define container.js in a war project

2011-01-20 Thread franck tankoua 
Thank you all.
I like the final Idea from Maxwell.
I think it is a good idea to give a possibilities to handle custom resources
ourselves.
I will try to install the properties from my shindig module.

Just FYI, I am using in my project a dependency on shindig and I do not want
to patch shindig jar in my environment if I want to change some default
properties.

Thanks a lot.

On Wed, Jan 19, 2011 at 7:53 PM, Maxwell mchiar...@gmail.com wrote:

 I do not like the idea to work with classpath priorities, I did create a
 simple PropertiesModule in my project, something like:

 CustomPropertiesModule extends AbstractModule {

 public void configure(){
 install(new PropertiesModule(your-properties-file);
 }

 }

 I think would be a better approach, move all resources out of common-jar,
 and let final apps handle it.

 Cheers.
 Maxwell

 On Wed, Jan 19, 2011 at 8:58 PM, Paul Lindner lind...@inuus.com wrote:

  You can provide your own shindig.properties by putting it in a local
  classpath before the shindig jar.  You might consider implementing a
  system property to override the path (look at how we did it with
  shindig.port)
 
 
  On Wed, Jan 19, 2011 at 2:47 PM, Ryan J Baxter rjbax...@us.ibm.com
  wrote:
   Hi Franck,
  
   The container.js is specified in the shindig.properties file, which
 lives
   in the shindig-common jar.  Since it's jarred up you cannot easily edit
  it
   in the war.  One option would be to replace the PropertiesModule guice
   module and point it to your own shindig.properties file and in that
 file
   point it to your modified container.js file.
  
   Another option would be to just modify the container.js file in
   WEB-INF/classes/containers/default.
  
   -Ryan
  
   Email: rjbax...@us.ibm.com
   Phone: 978-899-3041
   developerWorks Profile
  
  
  
   From:   franck tankoua ftank...@gmail.com
   To: dev@shindig.apache.org
   Date:   01/19/2011 02:30 PM
   Subject:Define container.js in a war project
  
  
  
   Hi All,
  
   Could someone help me on this.
   I have thought it was possible through the WEB.xml or through the guice
   module.
  
   I cannot do something like the following as it is throwing A binding
 to
   java.lang.String annotated with
   @com.google.inject.name.Named(value=shindig.containers.default) was
   already
   configured :
   {{{
  
 
 bindConstant().annotatedWith(Names.named(shindig.containers.default)).to(shindig/container.js);
   }}}
  
   Thanks
  
   --
   Franck
  
  
  
  
 
 
 
  --
  Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner
 




-- 
Franck

Re: Define container.js in a war project

2011-01-20 Thread Matthew G Marum 

Hey everyone,

I'm trying to write a new EndToEnd test patterned after the others that are
under java/server.  However, when I attempt to use gadgets.util.hasFeature
() or gadgets.util.getFeatureParameters() functions they always return
null.  I am adding tests for some new changes so I may have a bug
somewhere, but are those functions expected to work in the EndToEnd tests?

Matthew Marum

Re: Define container.js in a war project

2011-01-19 Thread Paul Lindner 
You can provide your own shindig.properties by putting it in a local
classpath before the shindig jar.  You might consider implementing a
system property to override the path (look at how we did it with
shindig.port)


On Wed, Jan 19, 2011 at 2:47 PM, Ryan J Baxter rjbax...@us.ibm.com wrote:
 Hi Franck,

 The container.js is specified in the shindig.properties file, which lives
 in the shindig-common jar.  Since it's jarred up you cannot easily edit it
 in the war.  One option would be to replace the PropertiesModule guice
 module and point it to your own shindig.properties file and in that file
 point it to your modified container.js file.

 Another option would be to just modify the container.js file in
 WEB-INF/classes/containers/default.

 -Ryan

 Email: rjbax...@us.ibm.com
 Phone: 978-899-3041
 developerWorks Profile



 From:   franck tankoua ftank...@gmail.com
 To:     dev@shindig.apache.org
 Date:   01/19/2011 02:30 PM
 Subject:        Define container.js in a war project



 Hi All,

 Could someone help me on this.
 I have thought it was possible through the WEB.xml or through the guice
 module.

 I cannot do something like the following as it is throwing A binding to
 java.lang.String annotated with
 @com.google.inject.name.Named(value=shindig.containers.default) was
 already
 configured :
 {{{
 bindConstant().annotatedWith(Names.named(shindig.containers.default)).to(shindig/container.js);
 }}}

 Thanks

 --
 Franck







-- 
Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner

Re: Define container.js in a war project

2011-01-19 Thread Maxwell 
I do not like the idea to work with classpath priorities, I did create a
simple PropertiesModule in my project, something like:

CustomPropertiesModule extends AbstractModule {

public void configure(){
install(new PropertiesModule(your-properties-file);
}

}

I think would be a better approach, move all resources out of common-jar,
and let final apps handle it.

Cheers.
Maxwell

On Wed, Jan 19, 2011 at 8:58 PM, Paul Lindner lind...@inuus.com wrote:

 You can provide your own shindig.properties by putting it in a local
 classpath before the shindig jar.  You might consider implementing a
 system property to override the path (look at how we did it with
 shindig.port)


 On Wed, Jan 19, 2011 at 2:47 PM, Ryan J Baxter rjbax...@us.ibm.com
 wrote:
  Hi Franck,
 
  The container.js is specified in the shindig.properties file, which lives
  in the shindig-common jar.  Since it's jarred up you cannot easily edit
 it
  in the war.  One option would be to replace the PropertiesModule guice
  module and point it to your own shindig.properties file and in that file
  point it to your modified container.js file.
 
  Another option would be to just modify the container.js file in
  WEB-INF/classes/containers/default.
 
  -Ryan
 
  Email: rjbax...@us.ibm.com
  Phone: 978-899-3041
  developerWorks Profile
 
 
 
  From:   franck tankoua ftank...@gmail.com
  To: dev@shindig.apache.org
  Date:   01/19/2011 02:30 PM
  Subject:Define container.js in a war project
 
 
 
  Hi All,
 
  Could someone help me on this.
  I have thought it was possible through the WEB.xml or through the guice
  module.
 
  I cannot do something like the following as it is throwing A binding to
  java.lang.String annotated with
  @com.google.inject.name.Named(value=shindig.containers.default) was
  already
  configured :
  {{{
 
 bindConstant().annotatedWith(Names.named(shindig.containers.default)).to(shindig/container.js);
  }}}
 
  Thanks
 
  --
  Franck
 
 
 
 



 --
 Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner