nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Failed Confluence XML Backup - Does order matter?

Eli Kim1

During a import of my Confluence XML Backup I see 2 entries in logging that are of concern:

Error while saving object [com.atlassian.confluence.like.LikeEntity]

Unable to complete import: Error while importing backup: Cannot case com.atlassian.confluence.pages.BlogPost to com.atlassian.confluence.pages.Page

For the casting, looking at Confluence 4.3.7 source, within the ImportProcessorContext function polyMorphicLookupByUnfixedId, for some reason it thinks it needs to cast a BlogPost to a Page. How is this determined in the XML? (Object class is correctly BlogPost)

Ass for trying to save the Like... I see the following...

The declaration of the BlogPost object that the Like refers to is written in the XML before the Like part. However, I am seeing that the BodyContent declaration for the BlogPost is declared before the BlogPost that it is referencing. Because of that, looking at the database state for that BodyContent entry, Content field is NULL. I know that can't be right.... but how do I fix this?? The database that the backup was made from correctly has a content id in that entry field.

Is Confluence 5 XML more robust? Should I try to upgrade to Confluence 5.2.3 then do a backup from there and import it? We are trying to switch from Oracle to MySQL so we do need the XML backup to work correctly

Accepted answers

Adrien Ragot 2

Your Question 1 - The casting

I have no idea. Should you increase the log level and retry? It will be very verbose, but you may see the stacktrace.

Your Question 2 - The order

No, the order doesn't matter:

If one element is required before another, it will be kept in memory (using the class DeferredOperations) until the other element is met. This creates problems of available memory when you make a really huge import (like several gigs) but Confluence does a good job at exporting in the right order.
If one element has a dependency, NULL will be inserted until Confluence gets the ID of the reference, then it edits the first record again to write the ID. This is the case you're meeting. Normal behavior.

All comments

Adrien Ragot 2

Your Question 1 - The casting

I have no idea. Should you increase the log level and retry? It will be very verbose, but you may see the stacktrace.

Your Question 2 - The order

No, the order doesn't matter:

If one element is required before another, it will be kept in memory (using the class DeferredOperations) until the other element is met. This creates problems of available memory when you make a really huge import (like several gigs) but Confluence does a good job at exporting in the right order.
If one element has a dependency, NULL will be inserted until Confluence gets the ID of the reference, then it edits the first record again to write the ID. This is the case you're meeting. Normal behavior.

Mark H_ Williams

The Casting:

I have enabled detailed SQL Debugging, The importexport package logging is on DEBUG. I can see the stack trace; however I can't see the data that it failed the casting on. If I do look at the logging, assuming its all serially done, I can figure out which entry the casting error SHOULD be. However the Object tag correctly says BLOGPOST. Why is it trying to cast to Page from the polymorph handle? Is it declared somewhere else in the XML?

Memory:

The entities.xml when extracted comes out to about 4 gigs. I have set our Confluence JVM memory max to 6 GB. I don't see any OutOfMemory errors so my resources should be sufficient.

Adrien Ragot 2

The first line of each entity in the XML should define which entity it's casted to. I assume your BlogPost entry in the XML looks like this:

<object class="BlogPost" package="com.atlassian.confluence.pages">
<id name="id">1015827</id>
<property name="title"><![CDATA[New version published today]]></property>
<collection name="bodyContents" class="java.util.Collection"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">1048594</id>
</element>
</collection>
<property name="version">2</property>
...
<property name="contentStatus"><![CDATA[current]]></property>
</object>

From reading the code, I reach the same conclusion as you do: It's working on a Like entity and the BlogPost entity isn't stored yet in the database. And lookupObjectByUnfixedHandle() returns something which isn't a BlogPost. I still have no idea why is that, sorry.

Mark H_ Williams

Yes that is how it looks and for some reason the variable classes has Page for some reason since I get the ClassCastException at clazz.cast(obj); looking at the source.

My only choice is to re-build that Confluence jar with more logging on that exception to see what is going on, but rebuilding it is turning out to be kind of a struggle.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

confluence-administration

backup