FWIW - this change did not fix those NPEs. I have been looking more into those logs and the code and I see another place where the dependency is missing and that can result in the cache manager being null. It's a bit complex to understand and I still need to be 100% sure that is the only thing causing this. But anyway, what I'll explain is definitely an issue whether or not it fully solves the problem at hand.

During JPA subsystem add operation, at boot time (in performBootTime()), the JPASubsystemAdd installs a JPAService (that's the name of the class). This JPAService in its start() (i.e. when it is started) registers the CacheDeploymentHelper (name of the class). This CacheDeploymentHelper is responsible to registering a CacheDeploymentListener with the jipijapa EventListenerRegistration. The  CacheDeploymentListener is a EventListener which ultimately delegates to InfinispanCacheDeploymentListener. The InfinispanCacheDeploymentListener is itself responsible for adding the relevant dependencies to the PU (through the addCacheDependencies() method) and at a later time also return the cache manager (through the startCache() method). 

Now if I'm reading the stacktraces, the logs and the thread names in those logs correctly http://teamcity.cafe-babe.org/viewLog.html?buildId=5377&buildTypeId=bt13&tab=buildResultsDiv#testNameId6893764851641965028, then I suspect that when the DUP triggers a addCacheDependencies() which ultimately iterates over the registered EventListener(s), the JPAService hasn't yet started which effectively means the InfinispanCacheDeploymentListener hasn't had a chance to setup the dependencies on the PU service. This ultimately means that the PU service can potentially be started before any of its (unspecified) dependencies are available.

The fix for this is to make the PU service depend on the JPAService so that things fall in place. Note that similar problem (i.e. missing dependency on JPAService) might exist in other places within the JPA subsystem, since from the looks of it, nothing in the code depends on that service and I think most of the code assumes that, that service will be installed by the time the control reaches the DUPs and other JPA infrastructure. For now, I'm going to add that JPAService dependency to the PU service and trigger some runs on TeamCity to see if that fixes this specific issue.