Hi Stanton, I'm seeing them in Eclipse, as well as when the application is active (i.e., as it would be on a production server, executed either from Maven or from the command line). I'm guessing the bigger environment I'm using Shindig in has its JSON parser(s) and they're overriding whatever is being used in Shindig.
I don't think you can rely on forgiving parsers, nor should you. While I often read developers' comments deriding the lack of comments in JSON, the EMCA standard for JSON doesn't permit comments and parsers are completely within their rights in rejecting invalid files. That's essentially what's happening with Shindig. I've also noticed that the ./config/container.js file is labelled as JavaScript but is actually parsed as JSON, and it's completely full of comments. I removed all of the comments from all of the JSON files, as well as those found in ./config/container.js, and everything is now working fine... Ichiro On Wed, Nov 19, 2014 at 4:28 PM, Stanton Sievers <ssiev...@apache.org> wrote: > Where are you seeing these JSON parse errors? These files are used on the > server-side and the parsers are fairly forgiving. > > -Stanton > > Sent from a mobile device. Please forgive brevity or typos. > On Nov 18, 2014 3:39 PM, "Ichiro Furusato" <ichiro.furus...@gmail.com> > wrote: > > > Hi, > > > > I've recently started working with Shindig for a project and have found > > that I am getting JSON parsing errors on unmodified files in the Shindig > > source. On investigating I found that these files contained Apache > license > > boilerplate in the form of "/* */" style comments, which is invalid JSON > > as according to ECMA-404 (the JSON standard). > > > > The files containing comments are: > > > > ./config/gadget-admin.json > > ./config/oauth2.json > > ./config/oauth.json > > ./content/sampledata/canonicaldb.json > > > > > > > ./java/gadgets/src/test/resources/org/apache/shindig/gadgets/oauth2/oauth2_test.json > > > > The last test file will not be a problem in production, but the other > > four show up in the distribution jars. The first three are found in > > shindig-gadgets-2.5.1.jar, the fourth in shindig-social-api-2.5.1.jar. > > > > Given I'm building via Maven and won't have control over the incoming > > jars (which will contain these files) I'm wondering how others have > gotten > > around this problem, and if it's possible to simply remove the comments > > in the source files (which would seem to be the simplest solution). > > License boilerplate is meant to protect the intellectual property of the > > project -- it doesn't have to be included in every file, and certainly > > not in configuration files (which arguably have little IP to protect). > > > > I suppose I'm also curious as to why this problem apparently isn't > > affecting delivery of the project (i.e., it obviously passes its tests, > > the mvn -Prun demo works). I'm still new to working with Shindig so > > perhaps I'm missing something here... > > > > Cheers, > > > > Ichiro > > >
