HippoServiceRegistry returning null

Experience Manager (PaaS/OnPrem)
1

Hi all,

I’m trying to upgrade a local hippo instance from 12.0.0 to 12.3.0. Regression testing some of my code has led me to see some weird behaviour.

In 12.0.0 the following code returned a proper implementation instance:

        ConfigurationService configService = HippoServiceRegistry.getService(ConfigurationService.class);

After having changed the version to 12.3.0, running the same code returns null. When I remote debug the instance and run the following expression:

HippoServiceRegistry.getServices(Object.class)

I do get a list in which one of the objects is the implementation of the service interface I’m looking for. Any ideas?

As a side note, am I correct finding that the upgrade documentation is locked away for approved developers? Or is there some separate documentation for the community edition upgrades.

Anyway, thanks for any help you might be able to give!

Cheers,

Marnix

2

Hi @marnix

It sounds like that you have duplicate ConfigurationService class instance in your class loader. One is old from 12.0.0 and the other is newer at 12.3.0. And that cause HippoServiceRegistry does not work well to return you the correct version.

3

Hi!

You were right about the class loader being wonky. I had already tried a nice fresh new build to make sure it wasn’t a dependency problem, but the problem persisted. After digging a little more it seems one of the differences between v12.0.0 and v12.3.0’s cargo.run profile dependencies is that this one is no longer there:

             <dependency>
                <groupId>org.onehippo.cms</groupId>
                <artifactId>hippo-configuration-management-api</artifactId>
                <classpath>shared</classpath>
              </dependency>

This is the dependency that has the class that I’m using. Removing it causes the jar to no longer appear in the shared/libs/ folder of the tomcat container, causing the classloader problem I originally described.

Is there a particular reason for the removal of this dependency? I’m asking to make sure I’m not doing anything too weird.

For now I’ll try to add it back into my project’s pom to see if that’ll fix it. I’ll let you know if that helped.

Thanks for your help.

Cheers,

Marnix

4

Hi,

Yep, adding the dependency back into the cargo.run container dependencies, and setting the dependency to provided in both site and cms pom.xml files (to prevent them from having their own classes in the their individual classloaders), fixed the issue.

Please let me know if what I did was a bad idea :wink:

Cheers,

Marnix

5

[marnix] marnix https://community.bloomreach.com/u/marnix
December 11

Hi,

Yep, adding the dependency back into the cargo.run container
dependencies, and setting the dependency to provided in both site and
cms pom.xml files (to prevent them from having their own classes in the
their individual classloaders), fixed the issue.

Please let me know if what I did was a bad idea :wink:

Actually, you should go the other way around.

In the initial (not yet GA) 12.0.0 the hippo-configuration-management-api
was still setup for the shared/lib (shared classloader), but this was
changed in the final (GA) 12.0.2 release, where this dependency only is
used/needed within the cms web application.

So effectively, you should not need to add this dependency back to the
cargo.run profile as shared dependency, nor should the dependency need
to be marked provided in site or cms pom.xml files.
Practically you should not (need to) have any dependency management for
this artifact in your project at all.

HTH, Ate