[solved] java.lang.NullPointerException during startup

During the xwiki startup under tomcat8, I am seeing the following error:

2019-05-16 16:13:44,418 [localhost-startStop-1] ERROR .o.i.DefaultObservationManager - Failed to send event [org.xwiki.observation.event.ApplicationStartedEvent@48a0d337] to listener [com.xpn.xwiki.plugin.activitystream.internal.ActivityStreamMappingInitializer@78bb5e70]
java.lang.NullPointerException: null
at org.hibernate.cfg.Configuration.add(Configuration.java:720)
at org.hibernate.cfg.Configuration.addInputStream(Configuration.java:756)
at com.xpn.xwiki.plugin.activitystream.internal.ActivityStreamMappingInitializer.loadMappingFile(ActivityStreamMappingInitializer.java:71)
at com.xpn.xwiki.plugin.activitystream.internal.ActivityStreamMappingInitializer.onEvent(ActivityStreamMappingInitializer.java:65)
at org.xwiki.observation.internal.DefaultObservationManager.notify(DefaultObservationManager.java:309)
at org.xwiki.observation.internal.DefaultObservationManager.notify(DefaultObservationManager.java:274)
at org.xwiki.observation.internal.DefaultObservationManager.notify(DefaultObservationManager.java:326)
at org.xwiki.container.servlet.XWikiServletContextListener.contextInitialized(XWikiServletContextListener.java:126)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4821)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5264)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:585)
at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1794)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
May 16, 2019 4:13:48 PM org.apache.catalina.startup.HostConfig deployDescriptor

Is this something to be concerned about? Is there something wrong with my hibernate.cfg.xml file that needs correcting?

Depends on your version of XWiki/ But we’re no longer using the activitystream. You should check the release notes for 11.2 and 11.3. You seem to still have the activitystream plugin defined in your xwiki.cfg.

1 Like

It’s not really related to xwiki.cfg but you definitely have Activity Stream API in your wiki, maybe you installed it during the upgrade to “repair” Activity Stream Application, you should actually uninstall those.

1 Like

Thank you Gentlemen,

That’s exactly what the problem was. I had that plugin installed as a dependency of the Watchlist Application, thus:
Watchlist Application -> Watchlist API -> Activity Stream Plugin

Once I removed the Activity Stream Plugin from the wiki and all subwikis, the errors went away.

I really need to pay more attention to the release notes before upgrading.

This specific one would deserve some cleanup helper in the upgrade process actually, it’s far from obvious.

What I’ve discovered today is a whole series of errors related to my not paying attention to the release notes which are now gone, except for one that is already fixed in 11.3rc1.

@tmortagne, even if you didn’t have a cleanup helper - what if you had something like a “checker” that would look for things to be corrected and provide some form of logging/notification to warn the administrator that they’ve overlooked something - part of a diagnostic tool perhaps?

That said, my wiki ran pretty well considering the neglect it suffered during the multiple upgrades. I was only forced to look when I started having some performance problems after the last 11.3 upgrade which are hopefully gone now. I’ll have a better idea in a day or two.

It would not help much this use case since having this extension is valid, you might still need it because you use its API explicitly in some code. I just assumed it was not your case but this extension is still released and maintained (as long as 11.x branch is).

What I want to work on since a while is a step right after the flavor step in the DW which would gather all extensions installed as dependencies but which are not referenced as such anymore and suggest you to remove them (or switch them to “top level” extensions instead).

1 Like