• 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 ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is there a key difference between url-pattern / and /* ?

 
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There appears to be a subtle difference between:



and



Both seem to send all requests through the servlet I'm aming for, but the /* on messes up forwards to JSP files. My app works as I expect when I use the "/" version (I don't need suffixes or prefixes since I've written some routing code). I'm wondering if they are supposed to be behave differently or if my Tomcat container has a little bug I'm exploiting wrongly?

If you use the "/" version, would you expect a URL like this to map to it....

http://mysite.com/

... and also ones like this...

http://mysite.com/some/arbitrary/path/here

?
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's not a bug. In the second example, the "*" acts as a wild card to matches all URLs. In the servlet request, the extra parts of the URL are available as the so-called "path extra info".
 
Chris Corbyn
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, so to clarify:



Should still match http://mysite.com/some/random/path

?

This is what's happening and what I want to happen so I'm happy if that's the expected behaviour
 
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The answer is in the servlet spec:


SRV.11.2 Specification of Mappings

In theWeb application deployment descriptor, the following syntax is used to define mappings:

  • A string beginning with a / character and ending with a /* suffix is used for path mapping.
  • A string beginning with a *. prefix is used as an extension mapping.
  • A string containing only the / character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.

  • All other strings are used for exact matches only.



  • The pattern /* will force everything through your servlet.
    The pattern / will make your servlet the default servlet for the app, meaning it will pick up every pattern that doesn't have another exact match.

    I just tested this in Tomcat and the / mapping will override a 404 error page entry in web.xml.
    [ August 19, 2007: Message edited by: Ben Souther ]
     
    Chris Corbyn
    Ranch Hand
    Posts: 114
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks, I wasn't sure where to look for that

    Overriding the 404 isn't a problem since by the very nature of what I'm doing I need to determine when to show a 404 myself.

    I'm probably going to run into all kinds of roadblocks here but we'll see how I go. It's an interesting experiment in the worst case scenario
     
    Ben Souther
    Sheriff
    Posts: 13411
    Firefox Browser VI Editor Redhat
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I've also just noticed that it overrides the welcome-file entry.
    Make sure that's what you want before you use it this way.
     
    Chris Corbyn
    Ranch Hand
    Posts: 114
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The routing would handle that too:



    Effectively you could say that all I've done is made a more flexible <servlet-mapping> configuration. It's not finished yet though because mapping request URIs to values is only one side of it. It also need to be able to take an unclean URL and produce the clean version of it:

     
    Chris Corbyn
    Ranch Hand
    Posts: 114
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    OK, this is working great. I'm posting mostly out of interest since nobody understood me the first time I explained how I wanted to carry this idea from a PHP framework point of view

    Everything to do with URLs and link production (not yet developed) is centered around a "Router" class and an XML file which provides everything it knows about what a URL looks like.

    I wont post the code for the Router class yet, but just to explain:

    My front controller delegates requests over to action controllers. Each "action" belongs to a "module" which is effectively a collection of actions in the same sub-package.

    e.g. app.somemodule.SomeAction, app.somemodule.AnotherAction, app.anothermodule.IndexAction etc.

    The only way the Front controller knows which action to run is from the URL. Ok, nothing new here, this would work fine.



    http://somesite.com/context-path/forum/createPost.do?threadId=52

    But with mine you'd skip web.xml entirely and modify a file I provide called routing.xml:



    Which allows http://somesite.com/context-path/forum/createPost/threadId/52

    Then there's the case where you decide that by default each module will at least have some default action. Let's call it the IndexAction - "index".

    http://somesite.com/context-path/forum/index.do
    http://somesite.com/context-path/forum.do

    Or in my routing.xml we can just explicitly provide a parameter if it's not there.



    http://somesite.com/context-path/forum/index
    http://somesite.com/context-path/forum

    Then one day you decide to change your URL schema to something like:

    http://somesite.com/context-path/moduleName-actionName

    Easy:



    Now one day we decide to change the "forum" module to "bbs" but only in terms of the URL, no point in rewriting a whole load of code to change all the hyperlinks right?



    Now going to http://somesite.com/context-path/bbs/createPost/threadId/52 actually takes you to the forum module's createPost action tranparently.

    Maybe in our first example we decide to clean up a bit and drop the "threadId" bit from our URL, just passing the ID instead:



    Now the URL http://somesite.com/context-path/bss/createPost/52 is actually the same as the first URL I posted in this post.

    I can't be bothered to go on any more, but basically that's what I've been doing and what I was talking about a few weeks ago when I first mentioned this and got a slightly confused response
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic