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
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...