Closing this issue as 2.8 is now End of Life version

Hi Anatoli,
thank you for your comment.
My issue is solved now according to your advice.
Thank you.

Hi Dmitry,

It seems like your issue is different from the problem described in this case. The problem described here can only happen when you migrate from versions of confluence earlier than 2.2.x. Can you please create a support ticket under https://support.atlassian.com so that we can help you to fix your problem.

Anatoli.

I have the same issue while upgrading from 2.7.3 to 3.0

"No server id found."

Thank you

Because of CONF-9959, it is preferable to choose 2.5.8 as the intermediary version, not 2.7.

Update: 2.7.2 is an acceptable intermediary version as well (it's the fix-for version in CONF-9959).

Hi Tim,

Thanks for looking into it. I agree it's too risky for this time. We will unschedule this bug for now. The Confluence upgrade notes have been updated to mention the need to find an intermediary step between 2.2 and 2.8.

Cheers,
Don

The Bandana persister accepts a map of objects and serializes them to XML internally. There are a couple of options:

1. Extend Bandana with an interface for writing a literal XML stream into the store
2. Create something like a LiteralXmlFragment object that wraps a string and configure XStream with a custom converter that just writes that string verbatim to the serialized XML output. Then, in the BandanaConfigMigrator, create instances of those objects from the old config files instead of deserializing them.

I think the latter might be a better way to go, but either way, this is a kind of scary change to put into Confluence 2.9 at this stage of the development cycle. There's a great risk here that it will end up writing bandana configuration data into the database that could cause errors when reading back at a later time. I'd recommend that this be rescheduled for early in the 3.0 cycle

First line of attack is to see if we can prevent the upgrade process from deserializing the object. We just need to pull it from a file and write it to the DB. We should be able to do all of that as XML, and never try to load the class.

This bug has a moderately straightforward workaround and is difficult to fix. I'm rescheduling the fix to 2.9.

This bug arises from changes made to the system in Confluence 2.3 and 2.8.

In 2.3, configurations were migrated from the file-system to the database (using Bandana). Part of this migration required the the XML configuration file to be read into its associated Java object - in this case a LeftNavSettings object. This object would then be passed to a Bandana persister to store its information in the database.

In 2.8, the Left Navigation Theme was moved out of core Confluence into a separate theme Plugin, and with it the LeftNavSettings class.

The final piece to the puzzle is that upgrades must be performed prior to plugin initialization; this can be seen in the application server's web.xml file where the UpgradeLauncherServletContextListener (for upgrades) is immediately above the LifecycleServletContextListener (for plugins). This means that a class in a plugin will not be available to the upgrade process.

LeftNavSettings is, thus, a victim of circumstance in any pre-2.3 to 2.8 upgrade. After a 2.3 upgrade and before 2.8, the settings will have been moved to the database - subsequently in the 2.8 upgrade the LeftNavSettings class will not be required and its absence will not be missed. This is the reason for the incremental upgrade workaround.