Why does the XMLRPC service report that exportSpace with four arguments doesn't exist?

[Brian M Thomas]

I have a need to export over 500 spaces, and I just really don't want to do that via the UI.

The (admittedly deprecated) XMLRPC methods page claims the existence of a method 

String exportSpace(String token, String spaceKey, String exportType, boolean exportAll) 

The method with three String arguments works fine, but when I add the exportAll parameter, which I need, I get this message:

java.lang.NoSuchMethodException: com.sun.proxy.$Proxy2320.exportSpace(java.lang.String, java.lang.String, java.lang.String, boolean)

Here's the XML body I sent:

<?xml version="1.0"?>
<methodCall>
 <methodName>confluence2.exportSpace</methodName>
 <params>
 <param>
 <value>f69b255d7a</value>
 </param>
 <param>
 <value>cm2011</value>
 </param>
 <param>
 <value>TYPE_XML</value>
 </param>
 <param>
 <value><boolean>1</boolean></value>
 </param>
 </params>
</methodCall>

Is this truly not implemented, or am I doing something wrong?

[Shannon S]

Hi Brian,

In this case, due to the depreciation, it's been completely removed from new versions of Confluence and is not possible.

There's a feature request to include it in future releases: 

• CONFSERVER-40457

You actually might be able to accomplish this with Bob Swift's CLI add-on, so go ahead and have a look at that.

Kind Regards,
Shannon

[Shannon S]

Brian - one more thing - my colleague and I tested with SOAP, and it will work with that, so you could switch to that from XMLRPC and give it a try.

Kind Regards,
Shannon

[Brian M Thomas]

So in fact they deleted the method with four arguments, which is the only one that can export an entire space, but kept the one which only offers limited export  (I've demonstrated that that one works; it just doesn't suit my need).  Can someone explain the logic behind that?  

Regardless, it's inexcusable to remove a method from the API without any notice, let alone before you've implemented it in the new one.

As to Bob Swift's CLI, well, that's the first place I looked, and while it once had that, it no longer has, because it's converting to use the REST APIs.  I've downloaded an earlier version, but if the method doesn't even exist any more, there's no point.

A SOAP implementation, for which I have neither tools nor experience, sounds like a great deal of effort for an obsolescent feature, but it looks as if I have no alternative.

I've been trying for a week now to find a way to script this operation; it's getting near to the time that it would have taken to do it manually.  There are several methods that should work but for some unexpected reason simply do not.

[Shannon S]

Brian,

We announced the deprecation prior to the release as well as in the release notes starting in Confluence 5.5. 

We're consolidating the capabilities we currently have in multiple different APIs into a single, easy to use REST API. Over the next several releases we will be deprecating our existing APIs as equivalent resources are made available in the REST API. See Confluence REST API in our developer documentation for more details. 

For this reason, some of those previous features will no longer work. At this time, the only possible solution to accomplish what you require is to use the SOAP API as I suggested. Please be aware, since it is deprecated, there is no guarantee that it will continue to function going forward, as these features are removed from new releases of Confluence.

I do encourage you to watch the feature as I sent you earlier, and please do provide your feedback on that case, as it will be seen by our team, and as it is public, other users can vote and comment to foster interest.

Kind Regards,
Shannon

[Brian M Thomas]

Shannon:

You quote the deprecation notice: 

Over the next several releases we will be deprecating [I assume that meant removed, since you've already deprecated the entire XMLRPC/SOAP service] our existing APIs as equivalent resources are made available in the REST API 

 Where does that give me notice that you will be removing one version of a method while leaving another in place, before its replacement is available?

I am already more than a week late with this project, and developing a SOAP client is not only not a great investment, since its target implementation is obsolescent, but it will add more delay while I procure and learn the use of a new set of tools that are complex and heavyweight.  It would be faster to create a Java utility that exercises the regular page requests, which I had hoped to avoid due to my short deadline, and because my efforts to date on using a REST client tool to do that have not been successful due to some arcana which I can't identify in the interchanges.

You have taken away something that I depended on — and, I repeat, without notice —  and without anything to replace it.  Given that, I need you to find me a method that will work without days or weeks of development work.

[Brian M Thomas]

Why does my previous reply not display here?  Did someone delete it as inappropriate?

[Mikael Sandberg]

@Brian M Thomas your previous reply was marked as spam so I moved it for you. I have seen this happen when you copy/paste text.

[Brian M Thomas]

Thanks.  Odd that it should happen in that specific situation, of which the reply in question is, in fact, an example;  I had mistakenly replied to the email notice of Shannon's reply, and when I got the "undeliverable" message I copied and pasted it here.

It was a rich-text message, and it contained some formatting HTML that this editor doesn't create and some other process apparently forbids (since it did appear here right after I posted it, and I even edited it after); perhaps that was what it didn't like. Otherwise, I can't even guess how that discrimination happened.

[Shannon S]

Brian,

The overall depreciation notice would explain why parts of the API aren't included in future releases. Unfortunately, not every call available from SOAP / XMLRPC is available in REST API, but if you do continue to find others that you rely on, please let us know, and I can include that in a feature request.

Kind Regards,
Shannon

[Brian M Thomas]

The overall depreciation notice would explain why parts of the API aren't included in future releases.

Words fail me for expressing how strongly I disagree with that statement, but it doesn't matter, and I'll repeat that it was just reckless to remove a part of a feature without explanation, and bizarre to do it while leaving in place the same method with a different signature.

But I don't intend to engage in disputing about what is ultimately irrelevant; what I need is a solution to a problem caused by Atlassian's action, which was to remove it without first providing a replacement, whether or not proper notice is deemed to have been given.