On Nov 23, 2007 12:04 PM, Richard Wallace <rwallace_at_thewallacepack.net> 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. 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
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
Hi guys,
Thanks for your tests and reports. I Will add a better error checking
now to ResourceClassScanner.
--
Frank D. Martínez M.
Asimov Technologies Ltda.
Blog: http://www.ibstaff.net/fmartinez/