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.
Related
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)
In my project directory, there are two folders named as follows:
./.repl-1.7.170
./.cljs_node_repl
I believe these folders are automatically generated. What are they for? Is it OK to delete them periodically when cleaning up?
I think these are both working directories used by the REPL when compiling REPL-related code.
In either case, why do you need to delete them?
The only consideration around this I can think of is wanting to make sure they don't somehow get committed to source code control. For that you can just use ignores or excludes if for example, you are using git.
I was cleaning my Documents folder and renamed the folder containing all the python/html files for the application. I edited an HTML file, pushed to dotcloud, and the application is down. Does anyone know a why to fix this? I've already tried renaming the folder containing the files back to the original and pushing to dotcloud, but it failed.
Edit 1: I just tried pushing with older files from a previous computer, and it also failed. (This solution usually works, so is there something at dotcloud's end that changed?)
My application is here: www.hours.lambertnhs.com
I'm learning how to use django on a EC2 server, but i am editing the code on my local computer. When i run things like :
python manage.py startapp polls
It creates a folder with various files inside. Instead of individually adding the files to git, which leaves the possibility of me forgetting to add every newly created file, is it good practice just to:
git add (the root django project directory)
everytime django creates new files?
If this isn't good practice, what methods do you guys use to ensure that all files get added to git everytime new files are created?
I think you're over-thinking this. Ignore files you think you should (like *.pyc). Add all the files or do them individually, whichever you prefer. If you accidentally added one you shouldn't have, do a checkout of that file so that you don't add it. If you already committed with a file, git delete the file and commit.
You use git status, it will give you the list of all the files it's currently not tracking, so you can use that as a reference if you're afraid you'll forget something.
Additionally, I would say that you don't want to forget to properly setup your .gitignore, and then you can instruct git to add everything, otherwise, like Mark suggested, you would potentially be adding **.pyc* files, which you don't want to do.
I have a django project that I have been working on as a solo developer, and have been using TortoiseSVN to keep the code managed in a repository on a work server. I work on this on a local installation of django etc.
There is now a second person who will be working on this project, and the possibility of working on some other PCs.
Now, there should, for the time being, only be one development version (branch?) of this project, but the configuration file (settings.py) will need to be different on each computer that is being used. I want to create one local version of this file on each PC which should not need to be changed again.
How can I set the repository (preferably within TortoiseSVN) to exclude this one file? E.g. the repository should not include settings.py. When a checkout occurs, it should update all files in the local folder but not change/remove the local copy of settings.py. When a commit occurs, settings.py should be ignored and not uploaded.
At the moment settings.py is overwritten/updated as per any other file in the project folder/repository.
Any nudges in the right direction would be useful - I'm new to SVN generally and would like to know if this is something that's going to need detailed understanding of branching or if there is a simpler way.
Thanks
In TortoiseSVN, when you try to commit your files, in the file list dialog, right click the file and look for the Ignore option. You can ignore by complete filename or extension.
If the file is already in the repository, and you want to remove it from there and ignore it, you can simply right-click the file and in the TortoiseSVN menu look for the 'Delete and add to ignore list' option.
You'll be looking for the svn:ignore property, which tells subversion to not version files matching a pattern or patterns you specify.
There's some guidance on using it with TortoiseSVN at:
http://arcware.net/tortoisesvn-global-ignore-pattern-vs-svn-ignore/
These should help:
I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
Excluding Items from the Commit List
The typical solution is to do what bgever said and ignore the settings file itself, and then commit a file with example values, something like settings.py.example. That file should only be updated when you add or remove settings. When deploying, you'd copy that to settings.py and edit the values.