Hi Davies I've never deployed shindig using the root.war approach, but heres what i have started shindig server as: $ svn co http://svn.apache.org/repos/asf/shindig/trunk/ $ vi shindig.properties container.js web.xml # Make watever changes $ mvn -Prun
I don't know how other people deploy shindig, but i think just putting all your js and running shindig server should be enough. Sorry if this causes more confusion. Thanks Gagan On Mon, Mar 28, 2011 at 7:00 AM, Davies,Douglas <[email protected]> wrote: > Hello. I’m new to this listserv, so please correct any protocol/etiquette > mistakes I might make. > > I’m pretty new to opensocial and shindig. I’ve played around with bringing > the war file down and renaming it ROOT.war. I’ve also played around with > creating a new webapp application archetype and just pulling down the maven > artifacts. The issue I’m struggling with (and I’ve seen references to it on > this group) is the root web app v.s. non-root webapp approach. It would > appear to me that since through 1.0, 2.0, and now 3.0 the root deployment > nature of shindig hasn’t changed, that this is the desired approach. > However I see many references to people patching container.js and > shindig.properties to get it to run in a different web context. I would > think the later is the more common case, but I might be missing something. > The fact that there isn’t just 1 location to change the context (and > besides the fact that localhost is referenced all over the place) steers me > into thinking the architects did not intend for this scenario however. But > then again, this is a reference implementation for us to change as required. > > Then a co-worker pointed me to this article > > > http://www.freesoftwaremagazine.com/columns/opensocial_overview_how_opensocial_works_and_integrate_with_cms > > And asked if I inferred from this that the javascript container code should > be installed on one server while the shindig server should be installed on > another (for security reasons???). My thought was is I’d build a > shindig.war that was specific to our needs and allow anyone to drop this > into there current environment. I was envisioning it on the same host so > that the javascript and server were both deployed together and the webapp > could just reference /shindig/gadgets, etc. All the hosting webapp would > have to do is define the DIV elements that want to render into and provide > some database setup for persistence. What is the drawback of this approach? > What is the preferred approach? I hope this makes sense. > > One other thing... If anyone is aware of consultants/contractors that are > shindig experts, I’d be interested in talking to them about a possible stint > at our company to help steer us in the right direction. > > Thanks, > > Doug Davies > OCLC, Online Computer Library Catalog
