On 3 February 2012 23:31, Ciancetta, Jesse E. <[email protected]> wrote:
> >-----Original Message----- > >From: Jasha Joachimsthal [mailto:[email protected]] > >Sent: Friday, February 03, 2012 12:39 PM > >To: [email protected] > >Subject: Re: Problems overriding rave host configuration > > > >Hi, > > > >Something goes wrong in the Rave-Shindig override mechanism but I haven't > >found where yet. On startup the OverridablePropertyPlaceholderConfigurer > >for rave-shindig says it load my custom shindig properties, but later > >Shindig says it loads the default container.js and therefore goes to > >localhost:8080. > >It is probably caused by the Shindig upgrade in December 2011. I'm afraid > I > >won't have the time soon to dive into the code base, anyone else? > > I don't think it was related to the shindig upgrade -- I think this issue > may have been around longer than that. > > I just committed a change which I'm hoping resolves the issue, but I > didn't write the original property loader code so I'm just basing these > changes on how I *think* it was intended to work: > > -- We have a single properties file for the rave-shindig project which is > used to initialize both Shindig proper (via Guice) as well as all of our > custom Rave specific extensions (via Spring). > > -- That single properties file is called rave.shindig.properties. It > contains a copy of all of the properties from the default > shindig.properties file plus all of our Rave specific properties. > > -- When our extended/custom version of Shindig initializes, it reads all > of the properties it would have normally read from shindig.properties from > rave.shindig.properties instead. The default shindig.properties file is > never read. Ever. Not even a little. :-) > > -- When our extended/custom version of Shindig initializes, our Rave > components are also initialized based on the properties contained in > rave.shindig.properties. > > -- We'd like to be able to set a system property called > "rave-shindig.override.properties" which points to a custom version of > rave.shindig.properties. If that property is set, it is read instead of > the default rave.shindig.properties file and used to initialize both > Shindig proper and all of our custom components. > > Hopefully all of that was the original intent. > Yes that was the intent. Originally we had 1 property file for the Guice modules and 1 for the Spring configuration. Later they were merged, because one should not care which framework handles what properties. > > So based on all of that and digging around in the property initialization > code I noticed that the guice component which reads rave.shindig.properties > looked for an override property called "shindig.override.properties", but > on the spring side (and the documentation on the rave website) the > properties loader was looking for an override property called > "rave-shindig.override.properties". I updated the guice loader to also > look for "rave-shindig.override.properties" and ran a bunch of tests and > everything appears to be working as I think it's supposed to. > > Here are the tests I did after my changes: > > -- Clean build, cargo:start -- works fine > > -- Set "rave-shindig.override.properties" system property (as a JVM system > property -- *not* an environmental variable) to a file that doesn't exist > -- ran another build and then cargo:start -- blows up as expected: "Unable > to load properties from resource. c:\temp\custom.shindig.properties (The > system cannot find the file specified)" > I set the system property by changing the <cargo.args> element in > \rave\rave-project\rave-portal\pom.xml to this: > > > <cargo.args>-Drave-shindig.override.properties="c:\temp\custom.shindig.properties"</cargo.args> > There are other ways to achieve this as well -- this is just one of > them. > > -- Copied > rave\rave-project\rave-portal\target\tomcat6x\webapps\ROOT\WEB-INF\classes\rave.shindig.properties > to c:\temp\custom.shindig.properties -- cargo:start -- works as expected > NOTE that I copied the *post build* version of > rave.shindig.properties -- there is apparently a step in the build process > that does a literal replacement of the ${rave.database.location} with a > literal value... If you copy the version straight from SVN trunk (like I > did the first time) you'll end up with an error at application > initialization time: "Could not resolve placeholder > 'rave.database.location'" > > -- Changed shindig.containers.default property in > custom.shindig.properties to a file that doesn't exist -- cargo:start -- > blows up as expected: "Error injecting constructor, > org.apache.shindig.config.ContainerConfigException: The file > 'C:\temp\custom-container.js' doesn't exist." > > -- Copied > rave\rave-project\rave-shindig\src\main\webapp\WEB-INF\classes\containers\default\container.js > to C:\temp\custom-container.js -- cargo:start -- works as expected > > Hopefully this solves the issues that others were seeing as well. If not, > please let us know! > Thanks for diving into it! > > --Jesse > > > > >Jasha Joachimsthal > > > >Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 > >US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll > free) > > > >www.onehippo.com > > > > > >On 3 February 2012 17:00, William Hayes > ><[email protected]>wrote: > > > >> Hi Carl, > >> > >> I'm having the same problem - I'm trying to override the domain name and > >> Tomcat ports, and I have updated those files in particular with no > >> success. I'm getting the same error as you. > >> > >> Are you using the maven cargo:start to start Rave or using the binaries? > >> > >> I'm a bit confused as to the best approach. Do we make the changes in > the > >> source and then run 'mvn install' or 'mvn -Pdist'? Or do we take the > >> binaries and alter the Ports and Domain after they are packaged into > >> binaries? > >> > >> I'm trying to test out Jasha's LDAP module, but I'm stuck on this basic > >> issue. > >> > >> Wm > >> > >> > >> > >> On 2/2/12 2:33 PM, "Louton, Carl O." <[email protected]> wrote: > >> > >> >Hello, > >> > > >> >I am having some difficulty with the override portal configuration. I > can > >> >properly specify portal.properties, rave-shinding.properties, and my > own > >> >container.js file. However, when the portal loads, the gadget iframes > are > >> >still pointing at a url that looks like > >> >"//locahost:8080/gadgets/ifr?url=...", which does not work when I'm > >> >trying to access the portal from anything but the same machine. > >> > > >> >The override mechanism worked in the past, as of Rave 0.6, but I've > >> >recently tried to start using 0.8 to test it out, and began having this > >> >issue. > >> > > >> >Carl Louton > >> >E543 - HIS, Visualization & Decision Support > >> >The MITRE Corp. > >> >781-271-5231 > >> > > >> > > >> > > >> > >> > >> >
