Solr 7 extension


We are looking at upgrading our current Solr 4.6 SolrJ integration with Lucee to the latest Solr 7.1.0

I’m not sure if it is necessary to build a complete Lucee extension for this.

I’ve had some success just placing the JAR files in the server/lib folder and been able to reference individual ones directly but there are probably some dependency issues doing it that way. I’m not had much success with SolrInputDocument as a start.

The Solr documentation references ant using ivy, maven pom.xml, gradle or through pathing the classpath. Does anyone have any recommendations to the most suitable method of integration?

Here is the link to the Solr page.



Just to add a bit more info to this.

I’ve created an extension using the ant build mechanism as described in:

I based my extension on the lucene example:

Here is a starter repository for the work I’ve done:

When I deploy the generated .lex file it is failing on the 3rd JAR file with the error:

"ERROR","Thread-30","11/14/2017","16:17:49","","Extension;C:\Users\pjmoody\AppData\Local\Temp\httpclient-4.5.3.jar (The system cannot find the file specified);lucee.runtime.exp.NativeException: C:\Users\pjmoody\AppData\Local\Temp\httpclient-4.5.3.jar (The system cannot find the file specified)
	at Method)
	at java.util.jar.JarFile.<init>(
	at java.util.jar.JarFile.<init>(
	at lucee.runtime.osgi.BundleInfo.<init>(
	at lucee.runtime.osgi.BundleFile.<init>(
	at lucee.runtime.osgi.BundleFile.<init>(
	at lucee.runtime.config.XMLConfigAdmin.updateJar(
	at lucee.runtime.config.XMLConfigAdmin.updateRHExtension(
	at lucee.runtime.config.XMLConfigAdmin.updateRHExtension(
	at lucee.runtime.config.XMLConfigAdmin._updateRHExtension(
	at lucee.runtime.config.DeployHandler.deploy(
	at lucee.runtime.engine.Controler.control(
	at lucee.runtime.engine.Controler.access$000(
	at lucee.runtime.engine.Controler$
Caused by: C:\Users\pjmoody\AppData\Local\Temp\httpclient-4.5.3.jar (The system cannot find the file specified)

This looks similar to a problem reported by @John_Farrar on @21Solutions Web Sockets extension and reportedly fixed by an upgrade to Lucee.

I am running the latest version of Lucee

Is anyone able to help? I figure this could be a problem with OSGI and that I need to create a ticket in Jira?

Perhaps there is an easier way of deploying this as in my first post above?



I’ve created:
for this.


@pat.moody The problem here is with deploying the jar file which doesn’t work for some reason.

But httpclient ships with Lucee so you don’t need to put it in the extension anyway.


Many thanks Igal - I shall take another look. Ideally it would be good to install all of the required dependencies to their required version.



The version that ships with Lucee is 4.5.2:



Bundle-SymbolicName: org.lucee.httpcomponents.httpclient
Bundle-Version: 4.5.2


On further testing it appears that the core components required for Solr integration have the same problem when deploying through OSGI.

I suspect that this is why custom versions were required for the httpcomponents too.

Seems like we are going to have to use the CF JavaLoader like we did for Solr 4.6 or place the JAR’s directly to a lib folder

This is unfortunate and disappointing as OSGI would have been a cleaner method, making use of one of the core features of Lucee 5

Is there an alternative as mentioned above? e.g. through ivy, maven etc.


In Lucee you really do not need JavaLoader, you can specify the path to the jar file as the 3rd argument of

createObject("java", className, path)

But OSGi bundles do not suffer from the issue described by @John_Farrar in the WebSocket installer. The issue there is with a regular jar that must be in the classpath (issue is resolved for the next version of Tomcat). OSGi bundles should deploy properly.

JavaLoader and Lucee 5

Many thanks,

But when I try to deploy just the core solr7 libraries, excluding the httpcomponents, I get the same file not found error as above.


So, is it possible to deploy these libraries as a bundle? If I just copy the necessary files into the lib folder I have all sorts of problems with dependencies when working with SorlJ

The way I see it this is a bug with OSGI? Correct me if I’m wrong.

Cfcollection oustide of web context

The WebSocket extension, for example, is made of 2 OSGi bundles and 1 regular JAR. The 2 OSGi bundles were deploying with no problem. It was only the regular JAR that had the issue.

So, no, I do not think that there is a bug with OSGi here, but I really can’t tell without seeing your files etc.

Perhaps @micstriit can offer some insight.


The link to the files is included in discussions above.
It looks as though I might have come up with a workaround solution using this.javaSettings and applying a specific path. It would be good to be able to load it as an extension though.
The issue when loading files through OSGI is the file not found problem.
I have raised a Jira issue for this as discussed above.
Perhaps @micstriit can take a look?