Combining CRISP resources and dcevm+hotswap-agent

Hello dear developers,

I have successfully set up a brXM 13.4.2 starterstore project with dcevm and hotswap-agent. Works fine sofar including auto hotswap.

However, during startup all CRISP resources (which we heavily rely on) cannot be initialized. One example below:

[INFO] [talledLocalContainer] 11.05.2020 18:40:35 DEBUG ResourceResolversInitializingThread [AwsApiKeysInterceptor.<init>:26] using API key: ... for: http://localhost:8081/cockpit
[INFO] [talledLocalContainer] HOTSWAP AGENT: 18:40:35.556 INFO (org.hotswap.agent.plugin.spring.SpringPlugin) - Spring plugin initialized - Spring core version '5.1.13.RELEASE'
[INFO] [talledLocalContainer] java.io.FileNotFoundException: null cannot be resolved to URL
[INFO] [talledLocalContainer] 	at org.springframework.core.io.AbstractResource.getURL(AbstractResource.java:100)
[INFO] [talledLocalContainer] 	at org.hotswap.agent.plugin.spring.scanner.XmlBeanDefinitionScannerAgent.registerXmlBeanDefinitionScannerAgent(XmlBeanDefinitionScannerAgent.java:68)
[INFO] [talledLocalContainer] 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:352)
[INFO] [talledLocalContainer] 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:305)
[INFO] [talledLocalContainer] 	at org.onehippo.cms7.crisp.core.resource.RepositoryMapResourceResolverProvider.createChildApplicationContext(RepositoryMapResourceResolverProvider.java:321)
[INFO] [talledLocalContainer] HOTSWAP AGENT: 18:40:35.582 ERROR (org.hotswap.agent.plugin.spring.scanner.XmlBeanDefinitionScannerAgent) - Cannot get url from resource: null
[INFO] [talledLocalContainer] 	at org.onehippo.cms7.crisp.core.resource.RepositoryMapResourceResolverProvider.refreshResourceResolvers(RepositoryMapResourceResolverProvider.java:266)
[INFO] [talledLocalContainer] 	at org.onehippo.cms7.crisp.core.resource.RepositoryMapResourceResolverProvider$ResourceResolversInitializingThread.run(RepositoryMapResourceResolverProvider.java:396)

It seems that the Spring bean definitions cannot be located on the classpath. Obviously those are in crispregistry.yaml and therefore in the repository, dynamically loaded on startup.

Is there a way to make those beans available, e.g. in the filesystem? I have tried dropping a bean xml definition in hst-assembly, but to no avail.

Any clues on how to get CRISP resources running with dcevm+hotswap-agent?

Best regards,
Frank

Hi Frank,

You can add any custom beans or imports in site/components/src/main/resources/META-INF/hst-assembly/addon/crisp/overrides/*.xml like the example [1].

[1] https://documentation.bloomreach.com/13/library/concepts/crisp-api/configuring-crisp-addon.html#scroll_configuring-http-connection-pool
(see "Configuring Http Connection Pool " section)

And when importing a resource, use a classpath: resource or file: resource which can be resolved properly. e.g, file:${catalina.base}/conf/a/b/c.xml.

Hi,

after clearing a few obstacles the dcevm+hotswap-agent setup seems to work.I will be testing a switch from JRebel to this setup in brXM from now on.

A few notes:

  • Spring bean definitions in site/components/src/main/resources/META-INF/hst-assembly/addon/crisp/overrides/ are not successfully picked up (not sure why)
  • the same definitions in site/components/src/main/resources/META-INF/hst-assembly/overrides/ are picked up, however for a CRISP resource resolver bean all the relevant bean ids/refs needed to be explicitly named (including some taken from the hst-core jar) within the XML definition as well
  • some required interceptors from the cms module could not be located (understandably); after moving the bean definition to cms/src/main/resources/META-INF/hst-assembly/addon/crisp/overrides/ the bean initialization without duplicating ids/refs as well as the override assembly itself worked - including interceptors etc.; the resource resolver is usably by its id in a HST component or another custom Spring-based prototype bean

This is a somewhat confusing behaviour and deviates from the documentation. I am not aware of any local changes that would explain it.

The most surprising fact is that despite the exceptions (which led me to filing this issue) the CRISP beans/resources are actually available with no further actions required: I forgot to start a local service and concluded that the exception must be the root cause. However, after removing the custom CRISP beans and starting the local service all CRISP resources do work straight away … fun fact.

Thanks for your support and best regards,
Frank

@FvM just a note that if you are using agent and dcevm virtual machine, Elastic search will fail to start and Lucene has some trouble with it too. I haven’t tested it lately, but ES just fails to start with it.