I'm having a little trouble understanding how Solr fits in with Jetty, and why I can't seem to get the start.jar in the distribution package to work.
I can run all of the example configurations via java -jar start.jar. However, when I try to run something like the follwing --
java -Dsolr.solr.home=/Users/jwwest/solr -jar $(brew --prefix solr)/libexec/example/start.jar
-- the following error occurs:
java.io.FileNotFoundException: No XML configuration files specified in start.config or command line.
at org.eclipse.jetty.start.Main.start(Main.java:506)
at org.eclipse.jetty.start.Main.main(Main.java:95)
I opened up the start.jar file, and there is a start.config file located inside of the jar which I'm assuming should handle this configuration for me. I'm not understanding why it will work when run from inside of the distribution examples directory, but not outside of it.
You also need to define the jetty.home property. Try:
java -Dsolr.solr.home=/Users/jwwest/solr -jar $(brew --prefix solr)/libexec/example/start.jar -Djetty.home=$(brew --prefix solr)/libexec/example
You can see the effective command line start.jar generates by using the --dry-run command line flag.
java -jar start.jar --dry-run
That will output everything with full path names so you can run it from outside the directory.
Source: http://www.eclipse.org/jetty/documentation/9.0.0.M3/advanced-jetty-start.html
The start.jar is a jetty specific mechanism that works to build out all the classpath requirements for starting up Jetty. It is generally only used in the scope of the jetty distribution. Pulling the start.jar out of the configuration and placing it somewhere else renders the default configuration of the start.config rather moot.
My understanding of Solr is that it bundles itself with a distribution of jetty, placing what it needs to run into the distribution and repackages it as its own. They may have a custom start.config file that further adds its own locations for classpath resources and the like, or not.
The exception you are seeings stems from the start.config file expecting an etc/ directory containing jetty.xml formatted xml files which are used to configure the jetty process.
Jetty being often used in an embedded format has little to do with this issue, it is simply a common use case because jetty is incredibly easy to embed into an application. Embedded instances of jetty rarely (if ever) leverage a start.jar...instead it is up to the embedding application to manage its own classpath.
First, you need to change your folder where start.jar is located, then execute the same command.
Jetty is often used as embedded container. If you want to use the jetty, then a good start would be to copy the example directory and rename it to what you want it to be. The solr directory is the one for basic configuration.
Else it is recommended to use tomcat and the solr.war file.
Related
dev_appserver.py starts a local deployement of my appengine service. I want to run my tests on behave on this local service. I want to start the server within my tests first. How to run the dev_appsrrver.py app.yaml command in my behave feature file in the start ?
I have tried subprocess.run("python","dev_appserver.py") but it says couldnt find the file dev_appserver.py. I'm trying on windows.
When you're attempting to launch executables using subprocess methods typically you're not getting by default the same environment (execution path and current working directory) you're getting yourself in a shell/terminal. Which means you may need to reference files (both executables and regular files) using full paths in the list of arguments you pass to those methods.
Since the subprocess.run() execution complaints about the dev_appserver.py location it means it's finding python OK (you may still want to check that's it's the 2.7 version) and you need to provide the full path for dev_appserver.py, which depends on your OS and the SDK you use. On Linux, for example (sorry, I'm not a windows guy), the path is:
<GAE_SDK_dir>/dev_appserver.py if using the GAE SDK
<gcloud_SDK_dir>/bin/dev_appserver.py if using the gcloud SDK
You'll most likely need to pass the path to your GAE app's app.yaml file, too - as an argument to dev_appserver.py, otherwise you'll see it complain about inability to locate the app or its files (or just having things run badly - if the app.yaml file isn't specified dev_appserver.py attempt to auto-detect it and that doesn't work in all cases). I'd avoid complications and just specify the app.yaml file(s).
Also note that the subprocess.run() args should be a list. Something like this:
subprocess.run(['python', '<sdk_path_to>/dev_appserver.py', '<app_path_to>/app.yaml'])
See also appcfg.py not working in command line - the post is about a different executable, but the answers are equally applicable to dev_appserver.py.
Quoting the App Engine documentation:
To start the local development server:
Run the dev_appserver.py command as follows from the directory that
contains your app's app.yaml configuration file:
Specify the directory
path to your app, for example:
dev_appserver.py [PATH_TO_YOUR_APP].
Alternatively, you can specify the
configuration file of a specific service, for example:
dev_appserver.py app.yaml.
To change the port, you include the --port
option:
dev_appserver.py --port=9999 [PATH_TO_YOUR_APP]
How can I index a shared folder (not local) with Solr ? Is it possible or should I copy my shared folder into a local folder ?
You can definitely run the indexer on the different server from Solr. You just need to run the post tool with the right parameters.
So, two things:
You can run the post tool as a jar, not as a classpath and full name invocation
You can see all supported parameters by running: java -jar example\exampledocs\post.jar -h , the one you want is -Durl
I try to run solr in schemaless mode on a windows machine, like it is described here. But if I run the command
java -Dsolr.solr.home=example-schemaless\solr -jar start.jar
I get the error:
Could not find or load main class .solr.home=example-schemaless.solr
check the path of your start.jar file. Make the correct path to start.jar file and set the solr home correctly, that may be fix your issue.
When I run solr using
java -jar "C:\solr\example\start.jar"
It writes logs to C:\solr\example\logs.
When I run it using
java -Dsolr.solr.home="C:\solr\example\solr"
-Djetty.home="C:\solr\example"
-Djetty.logs="C:\solr\example\logs"
-jar "C:\solr\example\
start.jar"
it writes logs only if I run it from
C:\solr\example>
any other folder - logs are not written.
This is important as I need to run it as a service later (using nssm)
What should I change?
As you have discovered, the Jetty-hosted example distributed with Solr must be started in the example directory to function properly. Try creating a batch file that changes to the directory then invokes Java, like this:
C:
cd C:\solr\example\
java -Dsolr.solr.home="C:\solr\example\solr"
-Djetty.home="C:\solr\example"
-Djetty.logs="C:\solr\example\logs"
-jar "C:\solr\example\
Then have NSSM run the batch file instead of java.
Both answers should work for you.
You could set it up using apache Tomcat as opposed to the Jetty instance Solr comes with. Tomcat which comes standard with a startup.bat batch file that you use to start your server
Here is the problem:
I have packaged my Java application into a single jar using the Maven plugin One-Jar.
Now I want to run the application as a Unix Daemon using JSVC, i.e. Apache Commons Daemon.
I am using JSVC as follows (which works for Jars made with the Maven assembly plugin, etc):
jsvc -user $USER -home $HOME -pidfile $PID_PATH -cp $PATH_TO_ONE_JAR my.package.MyClass
The error is this:
jsvc.exec error: Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader
jsvc.exec error: Service exit with a return value of 1
Does anyone know if it is even possible to use JSVC and One-Jar together, since One-Jar uses a custom class loader? The jar runs just fine when I run java -jar my-one-jar.jar.
What can be done?
Thank you for any insight!
I had to add all jars dependencies to the classpath option from jsvc. It seems jsvc doesn't use the jars inside another jar
If you use the (poorly-documented) Maven Shade Plugin instead of One-jar (they can achieve similar results as each other), it should solve your problems. It unpacks the dependent jars and stores the class files directly in the fat Jar (rather than having jars within the jar). I have used it to create an executable jar for running under JSVC with some success.
Of course, things are seldom as simple as they sound. With the Shade plugin, you may have to do some work to relocate classes when there are conflicts in your dependency tree, or use resource transformers to handle your non-Java resource files. But hopefully not.
(Of course Mkyong.com has a guide on this)