cargo-jetty-7-and-onwards-deployer fails perform remote deploy on jetty-hightide (Jetty@Codehaus)

Can you please ZIP your Jetty configuration and send over?

I've downloaded jetty from http://dist.codehaus.org/jetty/jetty-hightide-7.4.1/jetty-hightide-7.4.1.v20110513.zip. I didn't configure much except that added etc/jetty-logging.xml to the end of <jetty>/start.ini. I've copied cargo-jetty-7-and-onwards-deployer.war to <jetty>/webapps/ and issued java -jar start.jar inside jetty's directory.

The actual jetty configuration I used is on my computer at my work place and I won't go there until next monday. However I've re-downloaded jetty from the previous link and without any configurations I managed to reproduce the issue at hand (I'll attach a zip of it - the deployer.war will be inside the webapps dir).

Edit: it was too big (~20MB) so I've uploaded at http://www.filedropper.com/jetty741 instead (tho' you're better off just downloading jetty for yourself, because this is a crappy file hosting service... sorry).

Committed revision 2905, which should probably fix the issue.

Can you please check?

I've checked out the code and built the deployer. I've compiled my test project then issued mvn cargo:deploy. There were no errors originating from maven, it reported `success' on the operation.

However the I got a warn on jetty's end (I'll attached the log.) Deploying the webapp manually didn't raise this warning. I couldn't verify if the test webapp was deployed correctly because deploying it manually or with cargo I couldn't view the webapp's default index.jsp (so it isn't related).

I'll look into it more tomorrow (it's really late on my end). Thanks for the help!

(Duplicate attachment. Whomever you're reading this, press delete if you can.)

See http://jira.codehaus.org/browse/CARGO-983?focusedCommentId=268656&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_268656.

I've rechecked that mvn cargo:deploy reports that the deployment was successful, but it isn't so. The warning on jetty's end (shown in the previous log I attached) gets raised, but the webapp doesn't deploy successfully: the `hello world' JSP cannot be viewed. The webapp itself is copied into <jetty>/webapps and deploys normally (the JPS mentioned is accessible) after I restart jetty.

How do you start Jetty; I mean who you know the OPTIONS value when starting Jetty?

I thnik CARGO uses OPTIONS=Server,jsp,jmx,resources,websocket,ext

In jetty's start.ini configuration file the options are the following:
`OPTIONS=Server,jsp,jmx,resources,websocket,ext,jta,plus,jdbc,annotations'. So nothing's really missing.

I don't know if I can configure the contents of the OPTIONS variable through cargo, but as I want only to deploy to an already running jetty instance the deployment process shouldn't fail because of this (moreover because every possible module of jetty is included in the options).

Can you please try with Jetty 7.4.x with no webapps deployed yet? I see your container has all the test-* webapps...

I'm actually trying to find out why the Jetty 7.x tests pass on the CI with 7.4 but not on your case. It is either because of the applications already deployed (i.e., Jetty bug), because of the jetty.xml/webdefault.xml file or some startup options.

OK, I've done the following in order:

• re-downloaded jetty 7.4.1 from the codehaus repository
• unpacked it deleted every webapp from <jetty>/webapps (kept .donotdelete)
• I also deleted the files from <jetty>/contexts-available because errors were thrown when starting jetty otherwise
• started jetty
• deployed (copied) the cargo-jetty-7-and-onwards-deployer to <jetty>/webapps (it got picked up)
• deployed the test webapp (with different context name `deployer-test') with cargo:deploy

mvn cargo:deploy reported success, but the result was the same:
> 2011-05-27 18:30:39.945:WARN::Failed startup of context
> ...
> javax.naming.NamingException: This context is immutable; remaining name 'env'
The webapp failed to deploy. After restarting jetty it gets picked up and works normally.

I have tried the following:

1) Downloaded http://download.eclipse.org/jetty/7.4.2.v20110526/dist/jetty-distribution-7.4.2.v20110526.tar.gz and extracted it
2) Added the cargo-jetty-deployer.war (version 1.1.1-SNAPSHOT) to webapps
3) bin/jetty.sh start
4) mvn clean install on your test project
5) Open http://localhost:8080/test

And it says "Hello World"

I have also tried step 2) with cargo-jetty-deployer.war (version 1.1.0) and it still works.

I have even tried with http://download.eclipse.org/jetty/7.4.1.v20110513/dist/jetty-distribution-7.4.1.v20110513.tar.gz and it still works!

What happens on your side? How come your ZIP is broken?

Hey, I spotted the difference: you are using Jetty@Codehaus, can you please try with Jetty@Eclipse?

Updated documentation on http://cargo.codehaus.org/Jetty+7.x accordingly

Oh jeez, never would have thought that the zip at codehaus could any be different from the one at eclipse. It works now. Thanks for getting to the bottom if this, I really appreciate it!

Coool 8)

Enjoy the weekend

Using Eclipse's latest Jetty 8.0.3 distribution and the latest cargo-jetty-7-and-onwards-deployer 1.1.3 I get the same

java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler

exception that was mentioned earlier in this issues.

In my project (which I'm going to attach a bit later) I've used the latest Cargo plugin (1.1.3).

I've seen at the cargo-jetty-7-and-onwards-deployer's pom.xml that it depends on the eclipse-deploy artifact, but not on the latest version (8.0.3) of it, which is available at the main Maven repo. Maybe this has to do something with the issue at hand... maybe not.

Edit.:

Just to make sure: I've downloaded Jetty, unpacked it to $JETTY_HOME. After this I've downloaded the cargo-jetty-7-and-onwards-deployer.war and copied into $JETTY_HOME/webapps. Started jetty: cd $JETTY_HOME; java -jar start.jar. I've verified that the cargo-jetty-7-fricking-long-name was deployed to it. After this I've packaged the project I've just attached with `mvn clean package` and issued `mvn cargo:deploy`, which resulted in an error (which error's log I'm going to attach, as I've forgotten to do that).

Attached the log mentioned earlier.

Hi Kohányi

The Jetty deployer dependency used by the WAR doesn't change much, it is compatible with both Jetty 7 and Jetty 8.

We have changed the Jetty 8 version based on the latest release (check http://cargo.codehaus.org/Jetty+8.x for details), but the issue could not be replicated: all tests still pass.

Can you please send a copy of your Jetty configuration? You can also directly compare it with the ones generated by the tests, check the artifacts on http://bamboo.ci.codehaus.org/browse/CARGO-SAMPLESJETTY8X/latest/artifact

Thank you

Can you please send a copy of your Jetty configuration?

I've modified nothing that comes with the Jetty distribution from Eclipse. I've downloaded jetty-distribution-8.0.3.v20111011.zip from this link, unzipped it and put cargo-jetty-7-and-onwards-deployer-1.1.3.war (downloaded from this link) into Jetty's webapps directory. After this, I've only started Jetty and did not modify jetty.xml or any other configuration file that comes with Jetty.

However, I'm going to upload the jetty.xml that comes with the above mentioned distribution.

Also, I've checked the artifacts / container configurations you've linked previously. Specifically, I've downloaded this jetty.xml (which you're using for testing deployments to a remote Jetty instance I presume) and replaced Jetty's original jetty.xml with it. Using this setup the same exception is thrown as before:

2011-10-14 16:48:50.210:WARN:oejs.ServletHandler:Error for /cargo-jetty-deployer/deploy
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler

This new jetty.xml contains some stuff I don't quite understand, like the following snippet:

<Call name="addBean">
  <Arg>
    <New class="org.eclipse.jetty.deploy.ContextDeployer">
      <Set name="contexts"><Ref id="Contexts"/></Set>
      <Set name="configurationDir"><SystemProperty name="config.home" default="."/>/contexts</Set>
      <Set name="scanInterval">5</Set>
      <Call name="setAttribute">
        <Arg>org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern</Arg>
        <Arg>.*/jsp-api-[^/]*\.jar$|.*/jsp-[^/]*\.jar$</Arg>
      </Call>
    </New>
  </Arg>
</Call> 

As I've checked the page you've linked (http://cargo.codehaus.org/Jetty+8.x) I couldn't find anything that would suggest that if I want to deploy to a remote Jetty instance I have to configure anything in Jetty (or any of its configuration files) except that I have to download the deployer-thingy and deploy that first to Jetty. Did I miss something? (Not that using the jetty.xml containing org.eclipse.jetty.deploy.ContextDeployer instantiantion would solve anything.)

Please, consider downloading the aforementioned Jetty distribution and the cargo-jetty-7onwards-deployer and try to deploy the Maven project to it using mvn cargo:deploy. Maybe your tests give false positive results? I don't really know, but I don't think I'm doing anything wrong.

Thanks in advance!

The promised jetty.xml. (Straight out-of the Jetty's latest distribution.)

Hi Kohányi

Thank you for your analysis. I have no idea what these options do, perhaps someone else who knows more about Jetty can answer?

One other potential difference between the Jetty started by CARGO and the Jetty that you start manually are the Jetty profiles enabled. Based on http://bamboo.ci.codehaus.org/artifact/CARGO-SAMPLESJETTY8X/JOB1/build-53/Container-logs/jetty8x/remote/RemoteDeploymentTest/testDeployUndeployRedeployWarRemotely/cargo.log I believe CARGO uses OPTIONS=Server,jsp,jmx,resources,websocket,ext

Does this ring any bell to you?

OK, I've figured out, the last thing you mentioned, that CARGO uses these:

OPTIONS=Server,jsp,jmx,resources,websocket,ext

instead of the default (that comes with Jetty's default jetty.ini):

OPTIONS=Server,jsp,jmx,resources,websocket,ext,plus,annotations

helped a bit.

This way everything works almost as it should.

(Also, removing annotations from the OPTIONS requires one to comment out the line (in jetty.ini) that imports etc/jetty-annotations.xml and as a result that annotations aren't used the plus option and the import for etc/jetty-plus.xml also have to be removed.)

However, this is quite a let down, because this way one can't use Jetty's additional features: like JNDI (me for example ).

I don't know if this is related, but as per Jetty's documentation at Eclipse, the ContextDeployer is deprecated in favor of something else.

Next week I'll try to update your DeployerServer or hack-up a new implementation and see if I'm able to overcome this.

Hi Kohányi

I'm very glad that at least one workaround has been found

When looking into the Jetty documentation, I think that the new DeploymentManager exists since Jetty 7.1 (but not in Jetty 7.0): http://archive.eclipse.org/jetty/7.1.0.v20100505/apidocs/org/eclipse/jetty/deploy/DeploymentManager.html

If you can rewrite the DeployerServer using the Jetty DeploymentManager then it would be great; we would then simply add a note saying that "it only works with Jetty 7.1 and onwards; not Jetty 7.0". We also would recheck if it does work the Jetty@Codehaus...

Thank you

Hi Kohányi

I have opened the same issue for https://jira.codehaus.org/browse/CARGO-1049 so let's continue the work over there.

Thank you

This has actually been fixed FOR REAL in thanks to CARGO-1049. Documentation updated.