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)
Related
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.
with io.open("filepath/filename",mode="w",encoding="utf8") as file:
file.write(jsondata)
But it seems something wrong.
my flaskapp return 500 and no error logs
But when i remove it everything can run as normal.
what should i do?
If you are using OpenShift 2, it is likely your web application is running under Apache/mod_wsgi. You shouldn't in that case be using relative path names as the current working directory of the application is effectively undefined and likely not writable. Instead construct an absolute path name. Depending on what file is for, you may be best to write files into the data directory provided to you and specified by the OPENSHIFT_DATA_DIR environment variable, if it potentially needs to persist. Or OPENSHIFT_TMP_DIR if a temporary file. Details of important variables for directories can be found in:
https://developers.openshift.com/managing-your-applications/environment-variables.html#directory-variables
As to why you aren't seeing any error, this is likely because Flask is swallowing the error up when generating the 500 response. You would need to configure Flask to log details of the error.
I am trying to configuring HTTPS based on this tutorial:
Configuring HTTPS for your Elastic Beanstalk Environment
I am stuck at the following section:
To set the OpenSSL_HOME variable
Enter the path to the OpenSSL installation:
c:\ set OpenSSL_HOME=path_to_your_OpenSSL_installation
My openSSL is installed in c:\OpenSSL, so would I write set OpenSSL_HOME=C:\ OpenSSL?
Do I enter such command in Command Prompt?
Finally this step:
To include OpenSSL in your path
Open a terminal or command interface and enter the appropriate command for your operating system:
c:\ set Path=OpenSSL_HOME\bin;%Path%
My %Path% here would be what?
My openSSL is installed in c:\OpenSSL, so would I write set OpenSSL_HOME=C:\ OpenSSL?
Yes, but without the space after C:\:
set OpenSSL_HOME=C:\OpenSSL
Do I enter such command in Command Prompt?
You can. Do note, however, that with this approach, you would be modifying the OpenSSL_HOME environment variable for that particular command window only, and it would be accessible only to processes that are run from that same window. As soon as you close the window, your variable disappears.
If you need to make it persistent, especially through reboots, you have to configure the OS's global environment instead. On Windows, right-click on My Computer, go to Properties, Advanced system settings, Environment Variables, and add a new entry for your variable.
My %Path% here would be what?
That is an existing environment variable. You are modifying the existing Path, so by including %Path% to the end of your assignment, you preserve the existing Path so that existing paths can still be accessed.
Fir, note that the example in the documentation is wrong. It should be this instead:
c:\ set Path=%OpenSSL_HOME%\bin;%Path%
With that said, lets say for example that Path already contains a value of C:\Windows\;etc. After the assignment, the new Path will be C:\OpenSSL\bin;C:\Windows\;etc
I am trying to create a "warless" (exploded war, war directory only) deployment of embedded Jetty. I have been able to make it run by passing the path to the war folder to the WebAppContext(...) constructor and making sure that extractWAR, copyWebDir and CopyWebInf are set to false. I do not set a temp directory.
This runs fine. However, after stopping this, the content of the war folder is deleted and replaced with just one empty subfolder - jsp. So, next time this runs there is nothing there to run... and that is the problem.
I would ideally also like to keep any JSP compilation artifacts in place (for various reasons I am not doing build-time precompiled JSPs .... yet).
Does anyone know what causes this? I am assuming Jetty believes that this is a temp folder and that it should be removed... but it isn't.
Found the cause. Something else was setting the temp folder to the same path as the exploded war. Once I changed that to a different folder the deletion no longer happened.
That still leaves my other question though... but I'll live with it.
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