Cfcollection oustide of web context

dev support
1

Is there anyway to create a collection outside of a web context so it is available from other sites…I have a CRM which is used to drive the product listings on a couple of websites. I wanted to be able to reindex on the CRM but have the searches available on the other sites.

2

Anyone able to assist on this?

3

we used to do this all the time (in a different way). We used to have one server that held the collection and a thin service that was basically your search service.

That would be much more modern way to do this. So you can have the heavy lifting of updating collections done by that server/container/context and the others would just send a url query and get results in whatever format you want.

As a thin aside if you are doing lucee to lucee webservices they are usually pretty fast since they use binary communications so you could just expose one cfc with a search method and the other servers use it as a webservice call.

Much nicer solution than trying to get all the collections using the same repo (which will give you odd results I bet)

HTH

MD

4

Now why didn’t I think of that :slight_smile: thanks Mark

1 Like
5

Glad to help!

6

please keep in mind cfcollection is extremely vulnerable to dodgy files as the underlying engine dates back to 2009

7

It’s still using lucene right?

This should be a pluggable thing IMHO but it’s so tied into the implementation :confused:

8

It’s already an extension, so that’s about as pluggable as it gets?

9

Yeah, sure but if you look at the functions, you would have to copy what lucene does, rather than having a generic interface.

For example, moving it to elastic search would be interesting.

10

having revisited these tags recently, the old verity era tag api does feel rather clunky

I was hoping to implement a full text search for lucee docs, rather than just falling back on duck
duck go, the approach was going to be something like generating a raw zip file of docs content,
minus all the navigation which could be fetched by a microservice possibly running on the
lucee.org server, as docs just runs off s3 with cloudfront

@pat.moody was looking at getting a solr 7 implementation up and running
https://lucee.daemonite.io/t/solr-7-extension/3002/12

11

I’ve not revisited this for a while. Michael Offner @micstriit made comments on this ticket in relation to the apache JAR files being “classic” and not OSGI compatible. He said he might find some time to get the extension to work with the “classic” jar’s.
https://luceeserver.atlassian.net/browse/LDEV-1584
Also related is:
https://luceeserver.atlassian.net/browse/LDEV-1749

What I did was to reference the required JAR files directly in the Application.cfc I’ll revisit what I did in the morning and update you.

The workaround solution uses this.javaSettings and applying a specific path to the JAR’s I’ll dig out an example.

1 Like
12

@Zackster - I promised an example of loading group or specific jars - here goes.

		this.javaSettings = {
			//LoadPaths = ["/var/www/WEB-INF/lib/solr/", "/var/www/WEB-INF/lib/solr/zookeeper-3.4.10.jar" ], loadCFMLClassPath = true, reloadOnChange= true, watchInterval = 100, watchExtensions = "jar,class,xml"
			LoadPaths = ["/var/www/WEB-INF/lib/solr/", "/var/www/WEB-INF/lib/solr/zookeeper-3.4.10.jar" ]
		};

Here is an example for non - cloud use. I do have examples for zookeeper too.

		 //Non cloud usage - change mySolrServer:port to suit
		Builder = createObject( "java", "org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Builder" );
		mySolrServer = Builder.init( baseSolrUrl="http://mySolrServer:9983/solr/" & "collection-name" ).withQueueSize(50).withThreadCount(2).build();