65761K of 142888K >> 2017-09-07 18:17:10.581 ERROR 8184 --- [ main] c.b.solr.autoconfigure.SolrServer : Unable to download solr. If you need to connect through a proxy, the 'solr.dowload.proxyHost', 'solr.download.proxyPort', 'solr.download.proxyUserName' and 'solr.download.proxyPassword' properties are available. Also, make sure the user running this application has write priveleges to the download directory C:\Users\USER\AppData\Local\Temp\solr-5.3.1. A different download directory may be specified via the 'solr.server.workingDirectory' property.
During the reference implementation startup, the system will attempt to download Solr, install it and launch it on your behalf. Solr is a required component and fulfills search functionality.
From what you've provided, it looks like something failed part way through the download. There should have been an additional stack trace that would provide additional information on the specific nature of the fault. Nonetheless, something happened midway through the download (network failure, something). You have several options:
Try deleting the C:\Users\USER\AppData\Local\Temp\solr-5.3.1 directory and try starting again. See if on a second attempt the download is successful. If this works, the download problem must have been temporary.
OR,
Download solr yourself from http://archive.apache.org/dist/lucene/solr/5.3.1/solr-5.3.1.zip (it looks like you're on windows, so the zip file is appropriate). Expand the zip to the C:\Users\USER\AppData\Local\Temp\solr-5.3.1 directory. Now try starting again. This time, the system will detect you already have a solr installation and should skip the download step.
Related
I've cloned the nixpkgs repo. From the top of that repo, I can run nix-build -A waf to build waf, and nix-env -f . -iA waf to make waf part of my user environment. Neither complains -- but afterward I am still unable to call waf:
[jeff#jbb-dell:~/nix/nixpkgs]$ waf
waf: command not found
[jeff#jbb-dell:~/nix/nixpkgs]$
Most packages, when I build them using nix-build -A, produce a symlink called result that goes to a folder containing the executable in question. Strangely, though, in waf's case the symlink is to a file, not a folder.
I'm running NixOS. If I add waf to environment.systemPackages in my configuration, upon building I get an error that seems to be a result of the strangeness described in the previous paragraph:
[jeff#jbb-dell:~/nix/jbb-config]$ sudo nixos-rebuild switch
building Nix...
building the system configuration...
these derivations will be built:
/nix/store/s618gllra3g2vn62c92advg9ks2swkz1-system-path.drv
/nix/store/gpph3adrgn949mikfvkwld86flshdbvq-unit-polkit.service.drv
/nix/store/i7xql7889ank54fnhd16zk4z79l1ix88-unit-systemd-fsck-.service.drv
/nix/store/dv9p4fsrqn1fwdvy9scyc7g9422wvm7c-dbus-1.drv
/nix/store/y730jf9s9nrzmkf55i01nlwinw5gxpsp-unit-dbus.service.drv
/nix/store/4wjan71p2di7lscnscdfhp55j49dcymx-system-units.drv
/nix/store/qrzwrpsz0hh5gzaxic6ww8mnwl03zwil-unit-dbus.service.drv
/nix/store/lhq0s9s5v3sqvjx6mqlyqj6hf4kv38sf-user-units.drv
/nix/store/hk5wbmf4dpna3dn0h0q1balj3482l6xd-etc.drv
/nix/store/yj3lfyv5sbp751xzy9jdw1d06n9gdiin-nixos-system-jbb-dell-19.09.1889.692a8cabbcc.drv
building '/nix/store/s618gllra3g2vn62c92advg9ks2swkz1-system-path.drv'...
The store path /nix/store/f1ylicjswpfx1wbvxapsnwy987qnlxl6-waf-2.0.18 is a file and can't be merged into an environment us ing pkgs.buildEnv! at /nix/store/kncarzyhspzsplkcmmyiqg2cavrwr373-builder.pl line 96.
builder for '/nix/store/s618gllra3g2vn62c92advg9ks2swkz1-system-path.drv' failed with exit code 2
cannot build derivation '/nix/store/yj3lfyv5sbp751xzy9jdw1d06n9gdiin-nixos-system-jbb-dell-19.09.1889.692a8cabbcc.drv': 1 dependencies couldn't be built
error: build of '/nix/store/yj3lfyv5sbp751xzy9jdw1d06n9gdiin-nixos-system-jbb-dell-19.09.1889.692a8cabbcc.drv' failed
[jeff#jbb-dell:~/nix/jbb-config]$
This looks like an implementation error to me. waf, as a top-level Nixpkgs package, should put its binary in $out/bin.
I've checked for usages of waf in nixpkgs and it seems to be used inside derivations only via wafHook.
If you only need waf inside a derivation, I recommend going with wafHook, following the example of other packages. If you need to install it in your user profile, ideally you can send a PR to make waf a proper package or you can work around it with a custom derivation.
My goal is to set jetty to run as a service and figured I should have it run in command line first. My current aim is to be able to run jetty from root path. Once that's done, I can then set the same command to run as a service via https://nssm.cc/.
The issue
The webapp I am deploying in this Jetty instance uses logback to manage it's logging <file>logs/app.log</file>
This works as expected.
C:\jetty>java -jar start.jar
This does not C:\>java -jar C:\jetty\start.jar. (Note the different cmd path). Jetty can't figure out correct paths for log files. After some testing, I was able to rectify the path issue but still jetty is complaining about not being able to find the log file, even though I see it exists. So, permissions issue perhaps? I go ahead and give everyone full read and write access to the entire folder. No dice, still the same error.
Command I run now
C:\>java -Djetty.base=C:\jetty -Duser.dir=C:\jetty -jar C:\jetty\start.jar but the error persists.
....
12:11:51,095 |-INFO in ch.qos.logback.core.FileAppender[FILE] - File property is set to [logs/app.log]
12:11:51,111 |-ERROR in ch.qos.logback.core.FileAppender[FILE] - Failed to create parent directories for [C:\jetty\logs\app.log]
12:11:51,111 |-ERROR in ch.qos.logback.core.FileAppender[FILE] - openFile(logs/app.log,true) call failed. java.io.FileNotFoundException: logs\app.log (The system cannot find the path specified)
at java.io.FileNotFoundException: logs\app.log (The system cannot find the path specified)
....
Jetty version is 9.4.9.v20180320
Create a proper ${jetty.base} directory, outside of of the ${jetty.home} directory.
Next, get yourself a fresh copy of jetty-home (or the jetty-distribution which really only adds documentation, demos, and sample bases to jetty-home).
http://search.maven.org/#search|gav|1|g:"org.eclipse.jetty" AND a:"jetty-home"
Unpack that jetty-home artifact into a fresh directory.
Important:
Don't touch any content in jetty-home
Don't edit anything in jetty-home
Don't remove anything from jetty-home
Don't add anything into jetty-home
Leave jetty-home alone
Treat jetty-home as a read-only directory
All above bullets apply even if using jetty-distribution
Lastly, start jetty per the recommendations in the Jetty Documentation.
> cd \path\to\myjettybase
> java -jar \path\to\jetty-home\start.jar
Note the lack of declared system properties for -Djetty.home and -Djetty.base, this is important!
This will set up the following important directory properties.
jetty.base will be your CWD, or \path\to\myjettybase
jetty.home will be where your start.jar was found, aka \path\to\jetty-home\
user.dir will be your CWD and point to \path\to\myjettybase
What's important, for logging configurations like yours, is the user.dir system property. (aka the current working directory)
The technique you are using where you don't pay attention to the working directory and just attempt to force values into the JVM with system properties is only viable in the simplest of projects and usecases. (your requirements have outgrown that kind of setup)
I'm working on a long-term project for some time now. After moving some folders around, correctly refactoring different parts of the code, Webstorm's Dart analyser is showing NO errors, but running either pub serve or pub build fails.
Pub or Dart2JS doesn't seems to be traversing folders correctly.
This is the first error I get:
[Error from Dart2JS on CS_Game_Engine|web/main.dart]:
web/UIElements/NodeSettingsItems/TextVariableEditor.dart:4:1:
Can't read 'file:///Data/ownCloud/cybersecgame/CS%20Game%20Engine/web/UIElements/Data/Variables/Variable.dart' (Could not find asset CS_Game_Engine|web/UIElements/Data/Variables/Variable.dart.).
import '../../Data/Variables/Variable.dart';
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is interesting, because the file TextVariableEditor.dart, as you see in the error, is located in the web/UIElements/NodeSettingsItems/ directory.
The file I am trying to access (Variables.dart) is located in web/Data/Variables/Variable.dart.
The import statement moves 2 folders up with the ../../, but Pub or Dart2JS is not going 2 folders up, its only going 1 folder up. See the error again:
Can't read 'file:///Data/ownCloud/cybersecgame/CS%20Game%20Engine/web/UIElements/Data/Variables/Variable.dart'
It's looking for the file in the wrong place. I'm not sure what to do to fix this, and I've looked around and can't really find anything. Again, Webstorm's Dart Analyzer shows no issues, but the pub build or pub serve both fail, unable to find the file.
I've used the ../../ many times before in my code, but this is the first time it is causing issues. There are other errors similar to this, but having the same issue of not reading the ../../ correctly.
Update 1:
I've done more testing, and adding an additional ../ to the path's beginning fixes the error during the pub build. However, now Webstorm and it's Dart Analyzer is showing lots of errors since the path is obviously wrong (1 too many ../). This is a workaround, but not a fix. Does anybody know why pub or the Dart2JS is reading the path incorrectly? Somehow skipping one of the ../?
Code within the web directory should only access files in two places:
Things in the web directory, via relative paths
Things in packages via package: imports
#2 is interesting. This can include files within your own project, you just need to put those files in the lib directory and access them via a package:my_proj URI.
See https://github.com/dart-lang/sample-pop_pop_win/ as an example
See also https://www.dartlang.org/tools/pub/package-layout
I have deployed my webapplication on a jetty server, and I am trying to edit those deployed files using WebStorm 8.0.4. But I am unable to save the edited files and getting the following error:
Try turning the 'safe write' feature (Settings/General, 'Use safe writes') off - does it help? It creates a temporary copy of a file: creates a separate temp file, deletes the original and then renames. With this option the original file permissions may be lost, this causes problems, especially when working on remote drives.
Follow these steps.
Open C:\Users\YourUserName\.m2\repository (If you use maven)
Find org folder and Navigate org\eclipse\jetty\jetty-webapp\yourJettyVersion
There will be a .jar file.
Open it with winrar or some program like winrar.
Navigate org\eclipse\jetty\webapp
Find webdefault.xml and Open it with any text editor.
Search useFileMappedBuffer parameter in file
You will see a param value.
Change it to false.
Save and Exit.
I'm sorry for any English mistakes.
Is there a way to fix the file locking issue caused by jetty entirely from gradle?
Some clarification:
When using the Gradle Jetty plugin by running gradle jettyRun, jetty causes the static resource files (html, css, js, etc.) to be locked when using Windows.
You can see a description of the problem in Files locked on Windows.
The same article also describes how you can fix that. Basically you have to either:
Disable the use of file mapped buffer
Not use NIO at all.
Both things require to add some jetty specific configuration files to the project, which I do not want to do - the jetty plugin is used only for convenience, and maintaining configuration for it does not feel right.
I do not need NIO for testing on the local machine, so any solution works.
Edit:
For now, I picked the option at which you set useFileMappedBuffer to false. This is how to do it:
Specify a path to your webdefault.xml like
[jettyRun, jettyRunWar,jettyStop]*.with {
//other configs
webDefaultXml = file("${project.webAppDir}/WEB-INF/jetty-webdefault.xml")
}
Get file from the latest 6.1.x distribution of jetty. The plugin seems to support only jetty 6. You can localte it at jetty-6.1.26\etc\webdefault.xml. Obviously, you have to place it at the path specified at the previous step.
Change the default servlet init parameter useFileMappedBuffer to false
I will research the option of using embeded jetty insted of the plugin.
I found a plugin that seem to be a better alternative:
https://github.com/akhikhl/gretty
Positives
Does not lock your files and support hot deployment (even something Gretty call "fast reload")
Gretty 1.2.0 uses Jetty 9.2.9.v20150224. Jetty plugin provided by Gradle 2.2.1 uses Jetty 6.1.25.
same task is used jettyRun (or more simply run).
"Press any key to stop the server". Jetty plugin required CTRL+C then Y.
From what I can tell, the documentation seem to be awesome (Gradle's not so much)
Negatives
A bit more bloated code to setup the buildscript's classpath dependency or apply plugin directly from URL (see doc)
Gretty crash unless you explicitly apply plugin: 'war' (Jetty plugin extends the War plugin)
Kiril answered his own question, many thanks. You should follow Kiril's instructions and this will help you find the appropriate webdefault.xml.
To find out what version of Jetty is started by Gradle, execute
gradle jettyRun -i
And you'll see something like this:
...
Tmp directory = determined at runtime
Web defaults = org/mortbay/jetty/webapp/webdefault.xml
Web overrides = none
Webapp directory = C:\dev\my-project\src\main\webapp
Starting jetty 6.1.25 ...
jetty-6.1.25
...
It took me a while to find a copy of Jetty 6.1.25 as it is no longer listed on the Jetty download page (not even in the archive section!).
You can then grab the appropriate copy of webdefault.xml from here, adjusting the version number as appropriate for your needs:
http://grepcode.com/file/repo1.maven.org/maven2/org.mortbay.jetty/jetty/6.1.25/org/mortbay/jetty/webapp/webdefault.xml