Failed Confluence XML Backup - Does order matter?

[Eli Kim]

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

[Adrien Ragot 2 · Accepted solution]

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.

[Adrien Ragot 2]

Or more simple solution in case the compilation isn't easy:

Might you be able to start Confluence in debug mode and connect your IDE? You'd even be able to change the variables and, guess what, change the code in live.

It's often a matter of passing the following system properties to the JVM:

-Xdebug
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y

To check you've done right, use jVisualVM (VisualVM on Mac OSX) to check the jvm was indeed started with the arguments.