Winstone has ceased the development upstream, so we are the one maintaining it. That obviously doesn't make sense.

Another benefit is that this would also allow us to start delivering features that depend on WebSockets, etc.

This work involves writing a new driver code that accepts options that Winstone accepts but instead drive Jetty. For this purpose, I have refactored Winstone to explicitly list up all the options in use.

The general option compatibility is important so as not to disrupt existing deployments, even if we might consciously decide to skip some uncommon options if those are deemed too hard to match.

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
pom.xml
war/pom.xml
http://jenkins-ci.org/commit/jenkins/b19f4650d7cc146e28398a33ad0625d46991e27f
Log:
[FIXED JENKINS-18366] Winstone is now powered by Jetty

Integrated in jenkins_main_trunk #2925
[FIXED JENKINS-18366] Winstone is now powered by Jetty (Revision b19f4650d7cc146e28398a33ad0625d46991e27f)

Result = SUCCESS
kohsuke : b19f4650d7cc146e28398a33ad0625d46991e27f
Files :

• war/pom.xml
• pom.xml
• changelog.html

Could you please add this to the next LTS including --spdy option?

I use "java -jar jenkins.war" to run a new 1.536, it works. Ant it extract the war into the temp directory.
And I stop it by Ctrl-C, I found most files in the above temp are deleted except webapp\WEB-INF\lib.
Then I try to run it again, I don't see the extract log and I use browser to connect to Jenkins and only see the directory and file under the Jenkins directory.

Do I need to do any configuration for Jetty 8 ?

I see the same problem as Dennys in 1.537.
Even if I enforce the JENKINS_HOME environment variable using

>>java -DJENKINS_HOME=/path/to/jenkins_home/ -jar jenkins.war

the files are extracted into the users temp directory and jenkins can only be started sucessfully ONCE.

Every following startup hangs.

migration to jetty seem to ignore JENKINS_HOME

Since 536 we have a problem with some of the tests for our self-developed Jenkins plugins.
It concerns tests which use JenkinsRule class as Junit rule:

@Rule
public JenkinsRule jenkinsRule = new JenkinsRule();

After a test is running (successfully), the Jenkins automatic InjectedTest that checks Jelly files correctness is failling with the following exception:

Caused by: java.nio.file.DirectoryNotEmptyException: [path to plugin]/target/jenkins-for-test/help
(or /images)
The full stack trace is further down.
This happens, even when the only test in in the test class is empty.
When the respective test is set as Ignored and not run, the build passes successfully and InjectedTest is passing without errors.

org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite(org.jvnet.hudson.test.junit.FailedTest) Time elapsed: 0.005 sec <<< ERROR!
java.lang.Exception: Failed to initialize exploded war
at org.jvnet.hudson.test.WarExploder.getExplodedDir(WarExploder.java:49)
at org.jvnet.hudson.test.HudsonTestCase.createWebServer(HudsonTestCase.java:492)
at org.jvnet.hudson.test.HudsonTestCase.newHudson(HudsonTestCase.java:469)
at org.jvnet.hudson.test.HudsonTestCase.setUp(HudsonTestCase.java:312)
at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.setUp(JellyTestSuiteBuilder.java:133)
at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:49)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.nio.file.DirectoryNotEmptyException: [path to plugin]/target/jenkins-for-test/images
at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:241)
at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1071)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at hudson.Util.deleteFile(Util.java:239)
at hudson.Util.deleteRecursive(Util.java:307)
at hudson.Util.deleteContentsRecursive(Util.java:204)
at hudson.Util.deleteRecursive(Util.java:298)
at hudson.FilePath$12.invoke(FilePath.java:1077)
at hudson.FilePath$12.invoke(FilePath.java:1074)
at hudson.FilePath.act(FilePath.java:912)
at hudson.FilePath.act(FilePath.java:885)
at hudson.FilePath.deleteRecursive(FilePath.java:1074)
at org.jvnet.hudson.test.WarExploder.explode(WarExploder.java:96)
at org.jvnet.hudson.test.WarExploder.<clinit>(WarExploder.java:58)
at org.jvnet.hudson.test.HudsonTestCase.createWebServer(HudsonTestCase.java:492)
at org.jvnet.hudson.test.HudsonTestCase.newHudson(HudsonTestCase.java:469)
at org.jvnet.hudson.test.HudsonTestCase.setUp(HudsonTestCase.java:312)
at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.setUp(JellyTestSuiteBuilder.java:133)
at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:49)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

I upgrade my Jenkins and use java -jar jenkins.war to run 1.537, 1.538. It shows following message (it doesn't extract war to any directory). Any work around for it ?

Running from: D:\Jenkins\jenkins.war
webroot: EnvVars.masterEnvVars.get("JENKINS_HOME")
2013/11/6 06:42:49 org.eclipse.jetty.util.log.JavaUtilLog info
Info: jetty-8.y.z-SNAPSHOT
2013/11/6 06:42:49 org.eclipse.jetty.util.log.JavaUtilLog info
Info: NO JSP Support for , did not find org.apache.jasper.servlet.JspServlet
2013/11/6 06:42:49 org.eclipse.jetty.util.log.JavaUtilLog info
Info: Started SelectChannelConnector@0.0.0.0:80
2013/11/6 06:42:49 winstone.Logger logInternal
Info: Winstone Servlet Engine v2.0 running: controlPort=disabled

to run Jenkins with Jetty instead of Winstone, you need a new Environment Variable "JETTY_HOME", so Jetty know knows where to extract it's stuff.

for me (on Windows)

set JETTY_HOME=%JENKINS_HOME%

did the job.
HTH

JETTY_HOME works for me on 1.538, thanks.

I am seeing something similar to Dennys and Matthias under 1.538 running on Ubuntu 12.04. JENKINS_HOME is set to /var/lib/jenkins and Jenkins is started with the argument --webroot=/var/cache/jenkins/war but Jetty extracts jenkins.war to /tmp/jetty-0.0.0.0-8080-jenkins.war--any-/webapp. It runs fine for awhile but then some process deletes most of the files under the webapp directory (oddly the directories are not deleted). I tried setting the environment variable JETTY_HOME=$JENKINS_HOME but the war file is still extracted to /tmp. Is there a way to get Jetty to extract it to somewhere other than /tmp?

Hi Jason,

We ran into the same issue as you with Ubuntu 11.04. What ended up working was the following:

1. Create (or choose) a directory where you want to have the WAR be extracted, and make sure the "jenkins" user has R/W access to it. We ended up using $JENKINS_HOME/tmp

2. Modify the /etc/default/jenkins file to specify the java.io.tmpdir option as an argument to starting Jenkins. For example something like:

JAVA_ARGS="-Djava.io.tmpdir=$JENKINS_HOME/tmp"

3. Restart Jenkins

I have the same error with our Jenkins after an upgrade to 1.539. It extract the war file into our /tmp folder but this one is cleaned by some other process and I can't guarantee that all files will not be deleted... This is a horrible behavior for us and so, it's blocker.

Nov 20, 2013 3:29:14 PM org.eclipse.jetty.util.log.JavaUtilLog info
INFO: jetty-8.y.z-SNAPSHOT
Nov 20, 2013 3:29:14 PM org.eclipse.jetty.util.log.JavaUtilLog info
INFO: Extract jar:file:/usr/lib/jenkins/jenkins.war!/ to /tmp/jetty-0.0.0.0-8181-jenkins.war-_jenkins-any-/webapp
Nov 20, 2013 3:29:16 PM org.eclipse.jetty.util.log.JavaUtilLog info
INFO: NO JSP Support for /jenkins, did not find org.apache.jasper.servlet.JspServlet
Jenkins home directory: /data/jenkins found at: System.getProperty("JENKINS_HOME")

@dev, I have try to use your solution and I define another tmp folder for Jenkins but it still extract its war file into our /tmp folder.

Here an echo of my command line exectuded when I start the service.

Starting Jenkins
JAVA_CMD : /usr/java/java6/bin/java -Djava.awt.headless=true -XX:MaxPermSize=512M -Xms512m -Xmx4096m -DJENKINS_HOME=/data/jenkins -jar /usr/lib/jenkins/jenkins.war
PARAMS : --logfile=/data/logs/jenkins/jenkins.log --webroot=/data/jenkins/war --daemon --httpPort=8181 --ajp13Port=8010 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20 -Djava.io.tmpdir=/data/jenkins/tmp --prefix=/jenkins --accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/var/log/jenkins/access_log

Thx for any help

Hi Benjamin,

Looks like you are passing the "-Djava.io.tmpdir" argument to the Servlet container, not to the Java runtime. That "-D" argument needs to be a part of JAVA_CMD.

Hi,

Just to add my observations here.

Following the instructions from dev #comment-189758 the issue is gone for my Jenkins 1.539 installation.
The only thing to add is make sure that the JENKINS_HOME var is defined before the JAVA_ARGS var.

Alex

@dev, Oh my god, you right ! I define this property into the JENKINS_ARGS and no JAVA_ARGS. I fix this error tomorrow and I keep you aware of the result. Thx

Hi,
I am having trouble getting the Jenkins webpage up using a Solaris 10 server (JRE 1.6.0_26-b03).
The log shows Jenkins started successfully (Jenkins is fully up and running).
However when I try to connect using a web browser (tried IE and Firefox from Jenkins server localhost and remote machines) it hangs indefinitely.
Checking netstat shows the connection is ESTABLISHED.
All versions of Jenkins prior to 1.535 work perfectly under Solaris 10 and no versions after 1.534 work.
So I can only assume it was the introduction of Jetty in 1.535 that has caused this issue.
Cheers,
Josh

Solaris 10: CLI broken at Jenkins 1.535+

• Per https://issues.jenkins-ci.org/browse/JENKINS-20128?focusedCommentId=188660&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-188660, CLI works fine up to and including 1.534

@Josh, we're running Solaris 10 and while the Jenkins UI appears to work just fine in 1.535 and above, the CLI hangs:

java -jar 1.538/WEB-INF/jenkins-cli.jar -s http://cits.icc.intcx.net:8080 version

Exception in thread "main" java.net.SocketTimeoutException: connect timed out
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385)
        at java.net.Socket.connect(Socket.java:546)
        at hudson.cli.CLI.connectViaCliPort(CLI.java:211)
        at hudson.cli.CLI.<init>(CLI.java:134)
        at hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
        at hudson.cli.CLI._main(CLI.java:469)
        at hudson.cli.CLI.main(CLI.java:384)

Observations

• Jetty is unpacked to the -Djava.io.tmpdir directory regardless of setting -DJETTY_HOME=/some/dir/.
• JNLP port is enabled; setting this to either random or a fixed port did not address the CLI timeout.

@maschuru

migration to jetty seem to ignore JENKINS_HOME

File a separate bug (with a JIRA link) please. Do not reopen this one.

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
pom.xml
war/pom.xml
http://jenkins-ci.org/commit/jenkins/2394c0cd0e233449c85da3bc75628420a2b07a05
Log:
[FIXED JENKINS-18366] Winstone is now powered by Jetty

(cherry picked from commit b19f4650d7cc146e28398a33ad0625d46991e27f)

Conflicts:
changelog.html
war/pom.xml

Integrated in jenkins_main_trunk #3787
[FIXED JENKINS-18366] Winstone is now powered by Jetty (Revision 2394c0cd0e233449c85da3bc75628420a2b07a05)

Result = SUCCESS
jesse glick : 2394c0cd0e233449c85da3bc75628420a2b07a05
Files :

• war/pom.xml
• pom.xml