I have created a page, and found the page using
Content content = contentService.find(expandAll()).withId(id).fetch().get();
where id
is the ContentId and expandAll()
returns an array of all Content.Expansions. I am not concerned about performance because I am only finding one content, and I know the content exists because I am the one who created it. Just to get that out of the way.
So, I have three problems that are almost certainly related, and I simply cannot get around. First, content.getBody()
returns an empty Map. It is not supposed to be empty, because there is content. Second, when I try to pass in a new ContentBody, âContentService.update()â throws an IllegalStateException âRequest-local WebResourceAssembler has already been initialisedâ. And third, even when I simply omit the body altogether so that the update succeeds, when I visit the page it tells me there are unpublished changes.
Long story short - why is it so hard to update content using the ContentService ???
Addendum #1 - The REST API helped me past the first issue. It is not enough to expand âbodyâ. You must actually expand âbody.storageâ.
Addendum #1A - Apparently, âbody.storageâ only works for the REST API. ContentService is still returning an empty Map.
So I have a question for the Atlassian developers
WHY did you mark the find methods deprecated, when the new methods do not return the same object as the original methods?
Are there ANY plans to document this new API, other than with javadoc?
1 Like
Under the hood the REST API uses the ContentService
Have you tried with the following syntax ?
return contentService.find(ExpansionsParser.parse("body.storage")).withId(ContentId.of(contentId)).fetch()
.map(content -> Response.ok(content).build())
.orElseThrow(notFound("content not found for id : " + contentId));
Now onto your questions:
WHY did you mark the find methods deprecated, when the new methods do not return the same object as the original methods?
I suspect you are talking about PageManager#get, CommentManager#get ...
methods right ?
Those indeed do not return the same objects as the ContentService.
The purpose of that was to decouple our API layer from the data layer and abstract away the concept of Content, and also apply the permission checks by default so app developers wonât have to bother with that when accessing content through the API.
As far as plans to document our APIs other than with javadoc , we have set up this plugin here Bitbucket to showcase some of the API usages , the team should be adding more examples when time permits.
Cheers
Hasnae (former Confluence person)
1 Like
Hi Robert,
we are running into the same problem - did you ever figure out a solution?
No. It was a prototype, and the project was never funded, so I never pursued it.