Bloomreach 12 to 14 Upgrade

Experience Manager (PaaS/OnPrem)
1

Hi there! :wave:

My organization has been using Bloomreach for 4 years now and the last upgrade we went through was 3 years ago (11 to 12)

Now, I’m working on reconciling the differences between our version 12 code base and what it takes to get 14 running.

I decided the best way to start this process would be to build a new project off the bloomreach 14.5 archetype and pull custom files and doc types over 1 by 1.

The plan is to hopefully use this topic to get help when I can’t seem to find the answer I need using Google or Bloomreach docs.

First Problem

I pulled over a single document type that has in for an array of supertypes:

hipposysedit:supertype: ['hippostd:taggable', 'hippotranslation:translated',
            'hippotaxonomy:classifiable', 'contentplatform:basedocument', 'hippostd:relaxed']

The document is added to the equivalent .cnd file, but when I attempt to run using cargo, I get the following error:

[INFO] [talledLocalContainer]   at org.apache.jackrabbit.core.NamespaceRegistryImpl.getURI(NamespaceRegistryImpl.java:478) ~[jackrabbit-core-2.18.5-h3.jar:14.2.3]
[INFO] [talledLocalContainer]   at org.apache.jackrabbit.core.session.SessionContext$PermissionAwareNamespaceRegistry.getURI(SessionContext.java:392) ~[jackrabbit-core-2.18.5-h3.jar:2.18.5-h3]
[INFO] [talledLocalContainer]   at org.apache.jackrabbit.commons.AbstractSession.getNamespaceURI(AbstractSession.java:132) ~[jackrabbit-jcr-commons-2.18.5-h3.jar:?]

From what I can see from the code history it was not necessary to manually define this namespace. Do I need to do so now?

2

I am going to restate your objective to ensure we are talking about the same thing, recreate document types within version 14, that currently exist in a v12 implementation?

We did a similar exercise though it was from v12 → v13. We completed the upgrade steps, then ran into issues with deployment. In order to identify the area where we had caused an issue we created a clean project, and migrated sections of the codebase until we identified the issue. From what I gather from your execution you are taking files built and defined from version v12 and placing them into a v14 implementation, this will cause lots of issues that will be hard to track down. I would recommend attempting the upgrade from v12 to v13, then once that is successfully working in your production environment, going from v13 to v14.

If you want to skip a version I would build the project from the ground up. You already have the documents and types defined in v12, this would just be an exercise in recreating the documents via the UI to ensure they are v14 compatible. If you have custom classes or other aspects of the system, review the v14 documentation for those custom implementation, if available.

Best of luck, getting to v14 will be worth it.

1 Like
3

That is in fact, what I’ve decided to do @mdg (skip a version and build from the ground up). Thank you for validating this strategy :smiley:

I’m just taking one file at a time, rebuilding and ensuring I can start up. Slow going, but better than trying to upgrade our version 12 code in place