# HippoServiceRegistry returning null

**URL:** <https://community.bloomreach.com/t/hipposerviceregistry-returning-null/660>\
**Category:** Experience Manager (PaaS/OnPrem)\
**Created:** [December 10, 2018, 11:40am UTC](https://community.bloomreach.com/t/hipposerviceregistry-returning-null/660 "2018-12-10T11:40:07Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![marnix](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.bloomreach.com/marnix/32/228_2.png) [@marnix](https://community.bloomreach.com/u/marnix)\
**Post date:** [December 10, 2018, 11:40am UTC](https://community.bloomreach.com/t/hipposerviceregistry-returning-null/660/1 "2018-12-10T11:40:07Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ThoLe](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.bloomreach.com/thole/32/98_2.png) [@ThoLe](https://community.bloomreach.com/u/ThoLe)\
**Post date:** [December 11, 2018, 9:19am UTC](https://community.bloomreach.com/t/hipposerviceregistry-returning-null/660/2 "2018-12-11T09:19:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![marnix](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.bloomreach.com/marnix/32/228_2.png) [@marnix](https://community.bloomreach.com/u/marnix)\
**Post date:** [December 11, 2018, 10:33am UTC](https://community.bloomreach.com/t/hipposerviceregistry-returning-null/660/3 "2018-12-11T10:33:23Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![marnix](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.bloomreach.com/marnix/32/228_2.png) [@marnix](https://community.bloomreach.com/u/marnix)\
**Post date:** [December 11, 2018, 11:13am UTC](https://community.bloomreach.com/t/hipposerviceregistry-returning-null/660/4 "2018-12-11T11:13:18Z")

</div>

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 😉

Cheers,

Marnix

---

<div class="post-metadata">

**Author:** ![ate.douma](https://avatars.discourse-cdn.com/v4/letter/a/b782af/32.png) [@ate.douma](https://community.bloomreach.com/u/ate.douma)\
**Post date:** [December 12, 2018, 11:03am UTC](https://community.bloomreach.com/t/hipposerviceregistry-returning-null/660/5 "2018-12-12T11:03:29Z")

</div>

> [marnix] marnix [https://community.bloomreach.com/u/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 😉

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