ianlee-dev / facebook-java-api

Automatically exported from code.google.com/p/facebook-java-api
0 stars 0 forks source link

users_getStandardInfo_response does not get unmarshalled properly #176

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Using FacebookJaxbRestClient.
FacebookJaxbRestClient client = new FacebookJaxbRestClient(API_KEY,
        SECRET, sessionKey);

2. get standard info.
UsersGetStandardInfoResponse standardInfo =
        (UsersGetStandardInfoResponse) client.users_getStandardInfo(...);
3. check standardInfo.getUser().size()

What is the expected output? What do you see instead?
The UsersGetStandardInfoResponse returned by
FacebookJaxbRestClient.users_getStandardInfo() always has an empty users list.

What version of the product are you using? On what operating system?
tested against trunk r599.

Please provide any additional information below.
The facebook xsd defines users_getStandardInfo_response to contain a user
element when in fact the returned value is actually standard_user_info.

Attached my quick hack to generate the right jaxb bindings.

Original issue reported on code.google.com by edward.i...@gmail.com on 5 Mar 2009 at 4:23

Attachments:

GoogleCodeExporter commented 8 years ago
After a quick review of user vs. standard_user_info complex types, it looks 
like a
schema element extension is warranted along the lines of
http://www.w3schools.com/schema/el_extension.asp

If standard_user_info contains a strict subset of user fields then we should 
capture
that relationship in the .xsd. The User class must stay for backwards 
compatability,
but I can see that it would work on the Java side if User extends 
StandardUserInfo.

Original comment by david.j....@googlemail.com on 5 Mar 2009 at 8:28

GoogleCodeExporter commented 8 years ago
I'm no xsd expert, so you're probably right. :)

I have a hunch, though, that having UsersGetStandardInfoResponse return a
StandardUserInfo list instead of User won't hurt much. users_getInfo() would 
still
return User list and since users_getStandardInfo() has been returning an empty 
list
all this time, maybe nobody's been using it at all? Hehe.

Having User extends StandardUserInfo will work but I don't know how it will help
existing callers of users_getStandardInfo().

Original comment by edward.i...@gmail.com on 5 Mar 2009 at 9:50

GoogleCodeExporter commented 8 years ago
After some thought, I think the best fix for this is to change the line in 
schema.xsd to:
<xsd:element name="standard_user_info" type="user" minOccurs="0" 
maxOccurs="unbounded" />

So, we're just saying that the element is of type user but is called
standard_user_info. I've checked in a JUnit test and it passes nicely now.

I've pushed out a new snapshot build of both 2.0.6-SNAPSHOT and 3.0.0-SNAPSHOT.

It may well be worth taking a look at the 3.0.0 "composition branch" code if 
you're
using the JAXB side of things. The main advantage is that instead of returning 
Object
for every method, the return types are correct for each method. This is 
achieved by
auto-generating code with an annotation processor. But, that detail doesn't 
matter
when you're just using the client. Let me know if you give it a go... happy to 
help
you get it setup.

Cheers,
Dave

Original comment by david.j....@googlemail.com on 7 Mar 2009 at 3:26