So, I’m trying to save an item through webservices (several items, actually, but that’s besides the point) and I get the attached server fault message as a reply. Can anyone out there tell me what it means?
The error code is: 56
And the text is: Failed to save item with id ‘-1’. The underlying error was: An exception occurred while processing the internal request handler call: java.lang.RuntimeException: contentid may not be null.
This strikes me as very odd, because the content id is clearly “-1” (for -make-a-new-item-dangit-) as it states earlier in the message. Which leads me to believe that there’s something deeper going on and I’ve just missed it.
Clarification: Server version 6.7. Not sure of the build.
I have been able to get 10-15 other similar content items to load with no problems. So, either there is something wrong with my image encoding, or the data for this particular item (and items like it).
Thanks for the input, however I found that when I used attachment parts (yes, i tried those first), the attachment file streams are left open, memory (a lot of it) leaks, and my temp files which I had previously called deleteOnExit() on never get deleted (if I call delete() on them manually after using attachments, i get a return value of false and they do not delete).
This happened even on the content that didn’t throw these error as well as the ones that do.
Base 64 encoding of attachments work, I can control the file streams and memory usage with a finer tooth, and it’s working for other similar content items. So, i’m not going to mess with that particular mess.
The other thing I see is the use of “-1” as the id. I’m pretty sure that this is not correct. In Java, the content ID for a new item is null, although sometimes 0 is used (it’s a long integer).
-1 and 0 both do the same thing… since the check to see if a new id needs to be created is, apparently, “contentid < 1”
Also, after quite a bit of fiddling, I found that changing the sys_title fixed my issue… no clue why… are periods not allowed or something?
Still, the issue of leaking memory persists with soap attachment part file streams not getting closed. I wonder if this is an issue in the version of rxwebservices.jar that I’m using, or the axis or soap packages… Being that I’ve implemented a workaround, I’m not entirely inclined to continue debugging.
For reference, I’ve been using the rxwebservices, wsdl4, soap, saaj, jaxrpc, oro, jai, and axis jar files distributed with 6.5.2. If this issue has already been addressed in 6.7 libraries, please let me know.