Richard Wallace wrote:
> Alright, I did a bit more digging. I hadn't noticed that check for if
> it is a directory. The problem is that since I'm running jetty with the
> maven-jetty-plugin jetty:run target (super useful for debugging), the
> /WEB-INF/lib and /WEB-INF/classes directories don't exist.
It is odd that context.getRealPath("/WEB-INF/lib") is actually returning
something non-null though, so in some sense they must exist "Jim, but
not as we know it".
> With the
> jetty:run target, the plugin doesn't assemble the war, it runs
> everything in place and tells jetty what it should use for the classpath.
>
OK. See the JavaDoc of:
com.sun.ws.rest.spi.container.servlet.ServletContainer
perhaps you could set the init-param:
com.sun.ws.rest.config.property.ResourcePaths
to point to the relevant locations? I guess it all depends on what base
path for context.getRealPath() with Jetty for a non-standard deployment
config.
Another workaround is to create your own class that extends
DynamicResourceConfig with an empty public constructor that configures
things from the java.class.path system property (see the
com.sun.ws.rest.api.container.ContainerFactory code). Then set up the
web.xml to point to this class using the "webresourceclass" init-param.
> This is what is causing the scanning code to die. The solution is to
> use the jetty:run-war target instead. The bad thing about running the
> plugin that way is that changes to things like jsps and templates don't
> just automatically get used, the webapp has to be redeployed. A pain
> but something I can live with.
>
> As you said, more error handling code would have made this much easier
> to track down.
>
Tis done.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109