Error accessing the Template Query Generator tool

Experience Manager (PaaS/OnPrem)
1

Error when attempting to access Template Query Generator tool from within Bloomreach Essentials. I was trying to use this feature while following documentation to create a new document type within our CMS backed application.

image
image1924Ă—1522 233 KB

There are multiple errors logged actually which all appear as the one shown below.

 2:55:16 AM -  Error: [$http:baddata] Data must be a valid JSON object. Received: " An server error occured. Please check server logfiles for more inormation.". Parse error: "{}" https://errors.angularjs.org/1.8.2/$http/baddata?p0=%0A%0A%0AAn%20server%20error%20occured.%20Please%20check%20server%20logfiles%20for%20more%20inormation.&p1=%7B%7D

Looking into the logs I see the following error message.

17-Feb-2022 02:19:35.226 INFO [http-nio-8080-exec-4] org.apache.cxf.phase.PhaseInterceptorChain.doDefaultLogging Application {http://taxonomy.plugins.essentials.cms7.onehippo.org/}TaxonomyResource has thrown exception, unwinding now: java.lang.NullPointerException: null
17-Feb-2022 02:19:35.227 WARNING [http-nio-8080-exec-4] org.apache.cxf.phase.PhaseInterceptorChain.unwind Exception in handleFault on interceptor org.apache.cxf.jaxrs.interceptor.JAXRSDefaultFaultOutInterceptor@1a32e697
	org.apache.cxf.interceptor.Fault
		at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162)
		at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128)
		at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201)
		at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104)
		at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
		at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
		at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
		at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
		at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
		at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
		at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
		at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
		at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225)
		at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298)
		at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:222)
		at javax.servlet.http.HttpServlet.service(HttpServlet.java:655)
		at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273)
		at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
		at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
		at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
		at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
		at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
		at org.onehippo.cms7.essentials.filters.NoCacheFilter.doFilter(NoCacheFilter.java:47)
		at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
		at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
		at org.onehippo.cms7.essentials.filters.RequirementsCheckFilter.doFilter(RequirementsCheckFilter.java:66)
		at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
		at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
		at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197)
		at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
		at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:540)
		at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
		at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
		at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
		at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
		at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:357)
		at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:382)
		at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
		at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:895)
		at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1722)
		at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
		at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
		at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
		at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
		at java.lang.Thread.run(Thread.java:748)
	Caused by: java.lang.NullPointerException
		at org.onehippo.cms7.essentials.plugin.sdk.services.JcrServiceImpl.destroySession(JcrServiceImpl.java:65)
		at org.onehippo.cms7.essentials.plugin.sdk.services.ContentTypeServiceImpl.fetchContentTypes(ContentTypeServiceImpl.java:94)
		at org.onehippo.cms7.essentials.plugin.sdk.services.ContentTypeServiceImpl.fetchContentTypesFromOwnNamespace(ContentTypeServiceImpl.java:69)
		at org.onehippo.cms7.essentials.templatequery.rest.TemplateQueryGeneratorResource.getTemplateQueries(TemplateQueryGeneratorResource.java:101)
		at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
		at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
		at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
		at java.lang.reflect.Method.invoke(Method.java:498)
		at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179)
		at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
		... 43 more
17-Feb-2022 02:19:35.231 SEVERE [http-nio-8080-exec-4] org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage An unexpected error occurred during error handling. No further error processing will occur.
	org.apache.cxf.interceptor.Fault
		at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162)
		at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128)
		at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201)
		at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104)
		at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
		at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
		at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
		at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
		at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
		at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
		at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
		at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
		at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225)
		at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298)
		at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:222)
		at javax.servlet.http.HttpServlet.service(HttpServlet.java:655)
		at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273)
		at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
		at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
		at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
		at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
		at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
		at org.onehippo.cms7.essentials.filters.NoCacheFilter.doFilter(NoCacheFilter.java:47)
		at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
		at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
		at org.onehippo.cms7.essentials.filters.RequirementsCheckFilter.doFilter(RequirementsCheckFilter.java:66)
		at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
		at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
		at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197)
		at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
		at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:540)
		at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
		at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
		at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
		at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
		at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:357)
		at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:382)
		at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
		at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:895)
		at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1722)
		at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
		at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
		at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
		at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
		at java.lang.Thread.run(Thread.java:748)
	Caused by: java.lang.NullPointerException
		at org.onehippo.cms7.essentials.plugin.sdk.services.JcrServiceImpl.destroySession(JcrServiceImpl.java:65)
		at org.onehippo.cms7.essentials.plugin.sdk.services.ContentTypeServiceImpl.fetchContentTypes(ContentTypeServiceImpl.java:94)
		at org.onehippo.cms7.essentials.plugin.sdk.services.ContentTypeServiceImpl.fetchContentTypesFromOwnNamespace(ContentTypeServiceImpl.java:69)
		at org.onehippo.cms7.essentials.templatequery.rest.TemplateQueryGeneratorResource.getTemplateQueries(TemplateQueryGeneratorResource.java:101)
		at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
		at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
		at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
		at java.lang.reflect.Method.invoke(Method.java:498)
		at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179)
		at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
		... 43 more

I’ve also noticed that requests to all of the following are returning a 500 status error:

Any clue on what could be going wrong or how to solve it? We’ve upgraded to v13 last summer and I believe the essentials tool was functioning properly after that however we use it so seldom that I cannot be certain. Additionally we’ve also upgraded recently to 13.4.14 from 13.4.6 if that matters. So far I haven’t come across any indication that we may have missed some manual step for essentials regarding these past two upgrades.

2

From what I can tell when debugging the decompiled internal code is that jcrService.createSession() is returning null as shown in the screenshot below and the corresponding session variable has no null checks before jcrService.destroySession(session) is called later down the line. So what could cause createSession to return null?

image
image1794Ă—1870 375 KB

3

After debugging it after downloading sources for JcrServiceImpl I now see the underlying exception being caught in the corresponding createSession method.

javax.jcr.LoginException: Wrong username or password.
4

Trying to debug into the login code to understand more of the underlying cause I can see that it seems to be failing on the line below.

image
image2250Ă—782 114 KB

When I try to download sources through IntelliJ for RepositoryImpl though I get the following error.

Sources not found for: org.onehippo.cms7:hippo-repository-engine:13.4.14

It’s sort of hard to understand exactly what the problem is here but it seems like there is an issue logging into the repository with the default credentials though…

5

I was able to get the sources downloaded and to debug further after rebuilding and reattaching again for some reason. More importantly I think I may have a hunch to what my problem is. I’m currently running locally with a backup of the production CMS repository as we normally do for development and the admin user may not be present because it’s probably been removed in production in order to not have default credentials linger.

I would have guessed that the admin user would be bootstrapped through development-data but perhaps not or at least not from what I can see in our project. I’ll have to do a bit more digging on this but that may be the source of the issue.

6

So it appears that the admin user does exist within my local repository database but I’m guessing that the password has most likely been altered to be something more secure. Since it appears that the essentials tool doesn’t ask for a login and instead is set to use the hardcoded the admin:admin credentials I figured I’ll just change my admin password for my local setup back to admin but doing so through the CMS doesn’t seem to be an option.

image

7

I was able to replace the admin password with the default one through the CMS Console under /hippo:configuration/hippo:users/admin. Once I changed that and wrote it to the repository it took a few minutes and a few refreshes of the /essentials tool and then the Template Query Generator tool then stopped showing errors and started showing the document types expected.

Bloomreach, would it be a reasonable change to have the essentials tool prompt for a password similar to the CMS and CMS Console and to require a user with admin role? This would allow at least for custom local setups to to still use Essentials and just to specific a user to be used instead of hard coding local credentials.

8

Hi Jeff,
Thanks for posting your findings.

Actually your suggestion to have the Essentials tool not have a hardcoded admin/admin password isn’t new, see ESSENTIALS-723, but it has never gotten any priority, because it is only happening in a local development environment. Honestly I don’t think this will be any different today.

Regards, Jeroen

9

Thanks, I read over the ticket linked @jeroen.hoffman, I can see the points made there but I think they are missing the point of whether it is a perceived security issue or not for local development. I think the point is that developers may end up in the scenario where they do not have the default admin credentials set and that the better developer experience would be to either just prompt for the admin credentials up front when the Essentials tool is opened instead of using a hard coded default or at least to have a more reasonable UX in the case where the credentials fail to tell the user that the Essentials tool requires the default admin password to be set… If there is no real security concern about the default credentials in local development then the prompt could say something along the lines of “Hey wait, the Essentials tool needs the default admin user and password to be set in order to function correctly. Please ensure there is a active user named admin with password admin that is within the administrators role before accessing the Essentials tool.”

I appreciate the background and the explanation but to be honest my opinion is that there is no excuse for a poor developer experience if Bloomreach wants to be competitive in the market. I’ve noticed that there seems to be a bit of a half hearted attempt to promote/support the use of the Essentials tool beyond initial site setup and scaffolding and this can be seen with regard to the lack of a way to uninstall plugins for example. My recommendation would be to either smooth these rough edges or to pitch the Essentials Tool a bit more directly as a tool for initial setup which should be removed afterword’s. Furthermore, setting up things like template queries should be something that a user can do when they define document types in the CMS as opposed to resorting the Essentials tool as an example because that is an ongoing effort.

10

@jpierson

or to pitch the Essentials Tool a bit more directly as a tool for initial setup which should be removed afterword’s

I was involved in early development of the Essentials and this was exactly the reason our project PM rejected a lot of stuff related to the issues you just mention. I believe we even had a basic uninstall implementation, but it was dropped (the reasoning was: if you make a mistake, just start a new project again from scratch).
At some point we added tools section (gallery, beans generator and other config related tools) which were useful in later stages of the project, so “initial setup” definition became a bit of an gray area.

1 Like
11

Thanks @machak, this is useful background information.