mvn jetty:run does not seem to support WAR overlays...

could it be that jetty:run uses a different class loader - where if some resources is in the local project and also in an overlay war, it barfs (so it looks like the resource does not exist?)

I can point you at an example project shortly which has this issue; "mvn jetty:run" fails, but "mvn jetty:run-war" works...

See http://docs.codehaus.org/display/JETTY/Multiple+WebApp+Source+Directory
the ordering is trivial.

JETTY-1028 is fixed for 6.1.19 .. w/c could be related.
You can verify that the overlays work by doing a jetty:run on contrib/cometd/demo

Please re-open if you have a test-case where jetty:run does not handle the overlays.

thanks for the feedback. Any idea when 6.1.19 is out? I'll give this another test as soon as I get a chance!

I'm not sure but It would probably be before the 1st half of july.

I'm wondering if the failure is in calls to

servletContext.getRealPath(uri)

any idea if the contrib/cometd/demo uses that API?

James,

No, the cometd demo doesn't call getRealPath. Have you got a project that produces the error?

cheers
Jan

I do - though its a refactor to use maven overlays that caused me to hit this issue again and didn't wanna check in my changes as it breaks everything . When I've got it working later today (I hope) I'll post you details of the sample application.

On further debugging (after switching to 7.0.1.v20091125 of the plugin) - it seems that the issue is actually calling servletContext.getRealPath(uri) for a resource which is not within WEB-INF. It works perfectly for stuff inside WEB-INF! I think this might be due to the plugin making target/webinf and target/jsp and my resources are not JSP files and were not in WEB-INF.

So for now my work around is to put all resources I want to reuse from the overlays and access via servletContext.getRealPath(uri) inside WEB-INF.

for completeness here's the project...

http://github.com/scalate/scalate

the sub-module which reuses a maven war overlay is the scalate-sample (which reuses the scalate-war WAR)...

http://github.com/scalate/scalate/tree/master/scalate-sample/

to get things to work I had to move all the resources I wanted to share inside WEB-INF - which is now working perfectly! Huge thanks for all your help. Jetty rocks!

Hi James,

So the problem is that you're trying to get the path of a resource out of a packed war.

Here's the javadoc from the getRealPath method:

• Returns a <code>String</code> containing the real path
• for a given virtual path. For example, the path "/index.html"
• returns the absolute file path on the server's filesystem would be
• served by a request for "http://host/contextPath/index.html",
• where contextPath is the context path of this ServletContext..
  *
• <p>The real path returned will be in a form
• appropriate to the computer and operating system on
• which the servlet container is running, including the
• proper path separators. This method returns <code>null</code>
• if the servlet container cannot translate the virtual path
• to a real path for any reason (such as when the content is
• being made available from a <code>.war</code> archive).

So when you're running with an overlayed war, we can pull out a stream to the resource to serve them back to you, but we can't return you the path on disk because its inside the war.

An immediate workaround would be to not do jetty:run but jetty:run-war, so the overlay plugin processes the the wars and merges them together.

Perhaps we should add an option so the mvn jetty:run plugin was to take all the dependent overlayed wars and unpacks them before deploying the target webapp.

cheers
Jan

Reopening with fix.

James,

I've committed a fix to jetty-7 codehaus trunk.

If you put this configuration into your jetty-maven-plugin pom:

<webAppConfig>
<unpackOverlays>true</unpackOverlays>

then all the overlayed wars will be unpacked to the target/tmp directory and thus ServletContext.getRealPath() will return a good value.

This fix will go into jetty-maven-plugin 7.0.2, due out next week, so stay tuned.

cheers
Jan