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. 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.
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.
Thanks,
Rich
Paul Sandoz wrote:
> Hi Rich,
>
> Richard Wallace wrote:
>> Hello,
>>
>> I'm playing with Jersey because I really like the way the JSR-311
>> APIs are shaping up and am trying to decide what to use to create a
>> REST API to an existing webapp.
>>
>
> Thanks for checking things out and your feedback.
>
>
>> I'm trying to get a simple spike up and running using maven and the
>> maven-jetty-plugin. The first problem I've run into is that 0.5-ea
>> is not deployed to any maven 2 repository. That's no biggie, I've
>> just used the maven-install-plugin to install it locally. It would
>> be nice to get into a public repo though.
>>
>
> We decided we would only push the stable builds to the maven
> repository i.e. the API of which either Jersey or JAX-RS is not changing.
>
> The latest builds occur every time we do a commit, the API can change
> quite rapidly, and we did not want to push in-between versions of
> JAX-RS APIs that have been agreed in the expert group to a maven
> repository (currently we are in between 0.4 and 0.5 of the JAX-RS API).
>
> But it is great that you tried things out with the latest because you
> found a bug in a new an important Jersey feature that is meant to
> simplify deployment. So i am wondering if we should review what we
> push to maven...
>
>
>> Once I got that and the dependencies right, I tried running and am
>> getting an exception on startup.
>>
>> Caused by: java.util.zip.ZipException: error in opening zip file
>> at java.util.zip.ZipFile.open(Native Method)
>> at java.util.zip.ZipFile.<init>(ZipFile.java:114)
>> at java.util.jar.JarFile.<init>(JarFile.java:133)
>> at java.util.jar.JarFile.<init>(JarFile.java:97)
>> at
>> com.sun.ws.rest.impl.container.config.ResourceClassScanner.indexJar(ResourceClassScanner.java:133)
>>
>> at
>> com.sun.ws.rest.impl.container.config.ResourceClassScanner.index(ResourceClassScanner.java:108)
>>
>> at
>> com.sun.ws.rest.impl.container.config.ResourceClassScanner.scan(ResourceClassScanner.java:78)
>>
>>
>> This seems to be caused because I'm not setting the
>> com.sun.ws.rest.config.property.ResourcePaths servlet init parameter
>> so the defaults of /WEB-INF/lib and /WEB-INF/classes are used. The
>> exception is thrown because the indexJar(File) method is trying to
>> treat these directories as jars.
>
> Yes, it is assumed that /WEB-INF/lib and /WEB-INF/classes would be
> directories (using file.isDirectory() which in this case is returning
> false) and scans for class files, directories or jar files
> recursively. Here is the code for ResourceClassScanner.index:
>
> private void index(File file)
> throws MalformedURLException, IOException, ClassNotFoundException {
>
> if (file.isDirectory()) {
> indexDir(file);
> } else {
> indexJar(file);
> }
>
> }
>
> (I just tested with the provided SimpleServet example (deploying on
> Glassfish) and it worked fine scanning the /WEB-INF/lib and
> /WEB-INF/classes directories.)
>
> So /WEB-INF/lib and/or /WEB-INF/classes are not directories or zip
> files but something else?
>
> To get the paths the servlet code uses:
>
> context.getRealPath("/WEB-INF/lib")
>
> and such calls are not returning null, otherwise the code would have
> barfed earlier when File instances are created.
>
> What servlet container are you using?
>
> Perhaps we are running up against different deployment mechanisms of a
> web application? I sort of expected this might occur...
>
> Note that we also need to have better error checking in the class
> scanning code... i am going to do that. When done i will ping the list
> so. Would you be willing to try running with that build to help me
> find the root cause?
>
>
>> So, am I supposed to manually be specifying which jar to scan?
>>
>
> By default you should not have to do any configuration unless you
> don't want certain things to be scanned.
>
> Thanks,
> Paul.
>
>> Thanks,
>> Rich
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>