• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
  • Piet Souris
  • Himai Minh

org.glassfish.jersey.bundles:jaxrs-ri invalidates DefaultServlet

Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Using Tomcat 7. For my Jersey servlets(resources) to be initialized, I had to include the dependency org.glassfish.jersey.bundles:jaxrs-ri, which worked great. The runtime now recognize my Application class annotated with ApplicationPath.
Using jaxrs-ri gave birth to a new problem though; DefaultServlet no longer works. For example, navigating to a url in a browser, say localhost:9090/project/page.html will not work with this dependency present.

Did some googling but was unable to find anything useful.
Posts: 1845
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What have you got in your web.xml file?
Have you got servlet mappings for "*" in there that would interfere with the ones that have been disabled?

The example code in t he documentation does exactly that.
I you give it servlet mapping e.g. /rest/* and put all your rest resources under the /rest path (as an example) then it should no longer greedily grab every single request, and your standard handler will get a look in.

Saloon Keeper
Posts: 25477
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As a general rule, you should pretend that Tomcat's Default Servlet doesn't exist and that the default handling for URL resources is done by magic. If you start acting like there's a Tomcat Default Servlet in your webapp, you're likely to end up with a non-compliant J2EE webapp.

I think Stefan has your answer. If there's a "/*" mapping rule in your web.xml, it's going to hijack ALL incoming URL requests. Specifically, any css, javascript, image, html or JSP urls, because they'll all match the servlet routing pattern. It's not that "the default servlet no longer works". The Default Servlet works just fine. But web.xml is routing all traffic to your Jersey servlet instead, since the Default Servlet, true to its name, only acts on URLs that haven't been scooped up and handled by a servlet mapping pattern in web.xml.

The only time it's ever save to use "/*" or "*" as a servlet mapping is if the webapp in question is strictly web services or it is prepared to manually implement the various functions that the Default Servlet would normally be handling such as copying images and CSS, constructing directory listings, synthesizing default "404" and "503" pages and so forth. Since the Default Servlet is an artifact of a particular version of a particulat J2EE/JEE server, attempting to usurp all its functions can be hazardous.
permaculture is giving a gift to your future self. After reading this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
    Bookmark Topic Watch Topic
  • New Topic