WorkEntry object does not have "location" property

[ptashcka]

Hi.

I've found following problem, when my facebook account has link to some employer and this employer has city/town property then method:

factory.createConnection(accessToken);

fails with following exception:

Caused by: org.codehaus.jackson.map.exc.UnrecognizedPropertyException: Unrecognized field "location" (Class org.springframework.social.facebook.api.WorkEntry), not marked as ignorable
 at [Source: sun.net.www.protocol.http.HttpURLConnection$HttpInputStream@18c3ee9; line: 1, column: 298] (through reference chain: org.springframework.social.facebook.api.WorkEntry["location"])

Actually I think this is an issue, but right now I'm looking a way to tell deserializer to ignore unknown properties. Please help.

[habuma]

This is, in fact, a bug. WorkEntry objects should probably gather position, location, and description values. And, to safeguard against any potential unexpected fields, we should configure it to ignore unknown fields.

I've created https://jira.springsource.org/browse/SOCIAL-145 to address this.

[tenzin]

Hi Craig, I want to know where to get the updated version of spring social with the fix to handle properties like "location" and "position".

[habuma]

The fix is in the latest snapshots. If you're using Maven in your project, you can add it by changing your version number from "1.0.0.M3" to "1.0.0.BUILD-SNAPSHOT" and having the snapshot repo in your pom.xml:

                <repository>
                        <id>org.springframework.maven.snapshot</id>
                        <name>Spring Maven Snapshot Repository</name>
                        <url>http://maven.springframework.org/snapshot</url>
                        <releases><enabled>false</enabled></releases>
                        <snapshots><enabled>true</enabled></snapshots>
                </repository>

If you just want to grab the JARs, you can get them at https://s3browse.springsource.com/br...mework/social/.

Note that a few other thanks have changed since M3...for instance, the FacebookApi interface is now known a simply Facebook (like with with the other *Api interfaces).

[Rob Blair]

So a year, 5 months later, the model does not have new fields.
Is this SOP for the Spring Social Facebook API -
coders should roll their own additions if there are other fields they want?
I also should check the latest 1.1.0 Milestone / snapshot before complaining too much!

[habuma]

Rob: Believe me, I understand your frustration. I've been involved in other projects this year that have left me splitting my time between Spring Social and other stuff. But rest assured that I am very focused now on moving this stuff forward and *hope* to cut a 1.1.0.M1 in time for SpringOne/2GX next month. I can't make any promises as to whether or not it will have everyone's desired new features or API enhancements in it (in fact, I can say with certainty that it won't have *everyone's* desired stuff), but it will have some new goodies for sure and more in followup milestones.

With regard to new fields in the API binding: Certainly the API binding is missing a few fields and endpoint bindings. Some of these were oversights and some are because the Graph API has changed and the API binding hasn't caught up yet.

But your statement is partially accurate: If there are other fields you want, you can request them via JIRA and I'll try to get to them done in between the other requests (some of which are rather large and more time consuming). Or, as you suggested, coders can roll their own additions. But when you do that, it would be greatly helpful if you submit pull requests via GitHub. This is open-source, after all, and that means that everyone has the opportunity to contribute. Every contribution made by the community helps move this forward even faster. It takes a lot less time for me to review and merge a pull request than it does to code the enhancement myself.

To capture this thought, I've created https://jira.springsource.org/browse/SOCIALFB-100. I'm going to try to find the time to perform this before 1.1.0.M1, but it would be helpful if someone in the community would step up and pitch in. Even if you don't want to or can't contribute pull requests to address gaps in the API binding's coverage, it would be helpful just to know what the gaps are and to create issues. Actually addressing those gaps is one thing, but I relish any help I can get in identifying the gaps. Thanks in advance!