Open GoogleCodeExporter opened 8 years ago
Not even a comment in 8 days. Everyone must be reassigned to answering support
calls
for the Nexus One. This sucks.
Original comment by jre...@gmail.com
on 15 Jan 2010 at 3:11
13 days, no comment. Disheartening. It appears Google has abandoned this
project.
Original comment by jre...@gmail.com
on 19 Jan 2010 at 8:54
It's an open-source project. Contributions welcome.
Original comment by luke.bla...@gmail.com
on 19 Jan 2010 at 9:05
I have asked three separate independent developers to look into the matter.
None have
gotten anywhere. Another developer (not a java developer mind you) will begin
looking
into the source code in the very near future. I hope he will make some level of
progress. I was under the impression, perhaps incorrectly, that even though
this was
an open source project that there were Google Developers actively working on the
project. That does not appear to be the case even though Google claims to
really want
to support/promote data liberation. Oh well, I just have to recalibrate my
expectations is all.
Original comment by jre...@gmail.com
on 19 Jan 2010 at 9:09
Looks like this particular error maybe coming from a call in the GData Java
Client Library caused by a redirect on
a delete (which seems to make sense given that the import is probably deleting
existing content and then
replacing with the imported page). The workaround for this error is described
at:
http://code.google.com/p/gdata-java-client/issues/detail?id=92
I have downloaded the source and am attempting to locate the specific call to
see if it is a potential quick fix (and
to verify this is the actual problem). Hope this helps in tracking down and
fixing the bug.
Original comment by childs.m...@gmail.com
on 20 Jan 2010 at 8:34
This error is getting thrown on this call:
return sitesService.update(new URL(oldEntry.getId()), newEntry);
The documentation for the API states that .update takes three arguments the
entry URL, the entry and an etag
(which it says must match the existing tag). If the etag is null then no
precondition is set, and if it is a * then
the update happens unconditionally. This call can (and appears to) throw the
ServiceException error - which
denotes some type of system error. My Java is just rusty enough that I can't
remember if leaving the argument
out implies a null value or not (I thought it had to be an explicit
declaration). Something about this particular
call is unhappy. I'm going to try to do some testing to see if I can further
narrow it down.
Original comment by childs.m...@gmail.com
on 20 Jan 2010 at 9:06
Thanks Matt for getting involved! Hopefully you'll either have this fixed or
will
have at least identified enough information to help Google make a fix sooner.
Original comment by jre...@gmail.com
on 21 Jan 2010 at 7:19
I have found the fix for this:
Line 47 of EntryUpdaterImpl.java reads:
return sitesService.update(new URL(oldEntry.getId()), newEntry);
This returns the Service Forbidden If-Match If-No-Match Header Required Error
According to the docs for this call there is a third parameter that can be
included -
the etag of the page or the * for an unconditional overwrite. Since this is a
bulk
import/export tool - I added the *. The line now reads:
return sitesService.update(new URL(oldEntry.getId()), newEntry, "*");
and when I run the code in the IDE (I'm using NetBeans 6.8) it works like a
champ.
I've made my own clone of the repository and will check this code back in when
I get
the chance. I am curious - when I perform the build locally my JAR file is
considerably smaller than yours and does not run. I'd like to understand why
(and am
fully ready to hear that there is some NetBeans thing that I have missed).
Original comment by childs.m...@gmail.com
on 27 Jan 2010 at 10:37
Original comment by gk5...@kickstyle.net
on 8 Mar 2010 at 5:03
Original issue reported on code.google.com by
jre...@gmail.com
on 6 Jan 2010 at 7:26