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
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109