Back to the original question... I found a solution and want to validate it:
1. I created a RequestFilter that maps to /* 2. This filter checks to see if request.getServletPath() matches any of the action paths in struts-config.xml. If so, it forwards to the action. 3. As an added feature, I added a set of allowed extensions to this filter's init parameters. So far I have .jsp,.html,.asp,.cfm (using .jsp ensures no one links to them directly, MVC enforced!) - so marketing can choose what technology they want to convey ;-) This seems to work great. For example, I have an "advancedSearch" action defined as follows: <action path="/advancedSearch" type="org.apache.struts.actions.ForwardAction" parameter=".advancedSearch"/> (ForwardAction will eventually be replaces, if necessary, with a real action). This allows all of the following URLs to work: http://site.com/do/advancedSearch (works with Struts by default) http://site.com/advancedSearch http://site.com/advancedSearch.html + all other extensions listed. Pretty slick IMO. Please let me know if I'm missing anything. Thanks, Matt Here's the code from RequestFilter.doFilter(): // get Struts' configuration ModuleConfig m = getModuleConfig(request); // get a list of actions ActionConfig[] actions = m.findActionConfigs(); // get the requested path String path = request.getServletPath(); for (int i = 0; i < actions.length; i++) { ActionConfig action = actions[i]; String actionPath = action.getPath(); String params = RequestUtil.getRequestParameters(request); // check to see if path ends with a vanity extension for (int j = 0; j < allowedExtensions.length; j++) { if (path.endsWith(allowedExtensions[j])) { path = path.substring(0, path.indexOf(allowedExtensions[j])); break; } } if (StringUtils.equalsIgnoreCase(actionPath, path)) { StringBuffer url = new StringBuffer(); boolean redirect = false; // change to true if using redirect if (redirect) { url.append(request.getContextPath()); } url.append("/do" + actionPath); url.append((!StringUtils.isEmpty(params)) ? ("?" + params) : ""); if (log.isDebugEnabled()) { log.debug("forwarding from path '" + path + "' to action '" + actionPath + "'"); } // This this until we have issues (this way the URL doesn't change) RequestDispatcher dispatcher = request.getRequestDispatcher(url.toString()); dispatcher.forward(request, response); // If a forward doesn't work - use the one below // Redirect the page to the desired URL // response.sendRedirect(response.encodeRedirectURL(url.toString())); // ensure we don't chain to requested resource return; } } protected ModuleConfig getModuleConfig(HttpServletRequest request) { ModuleConfig mConfig = (ModuleConfig) request.getAttribute(Globals.MODULE_KEY); if (mConfig == null) { mConfig = (ModuleConfig) config.getServletContext().getAttribute(Globals.MODULE_KEY); } return mConfig; } -----Original Message----- From: Jason Lea [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 3:10 PM To: Struts Users Mailing List Subject: Re: Is it possible to remove *.do or /do/* from the URL If there are only a small number of 'marketing' style URLs that are going to be used, you could do those mappings specifically in the web.xml and leave everything else to your /do/* mapping Eg Marketing URLs 'activities', 'contact', 'foo' /activities/* /contact/* /foo/* everything else /do/* Or you could wrap a filter around the /activities/*, /contact/*, /foo/* mappings and forward to the correct action. -- Jason Lea Matt Raible wrote: > The reason I don't like extension mapping is because I think path-mapping > (/do/*) is cleaner. Also, I like using path-mapping b/c then we can add > parameters and they look like regular URLs. > > For example - extension mapping: > > http://site.com/activities.do?activity=fishing or > http://site.com/activities.do?fishing > > path-mapping: > > http://site.com/do/activities/fishing > > And then in our "activities" action, we can do a check > (request.getPathInfo()) to see if we should serve up the "fishing" page vs. > the general activities one. > > Thanks to all for your opinions and practices. > > Matt > > -----Original Message----- > From: Micael [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 18, 2003 11:33 AM > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: Re: Is it possible to remove *.do or /do/* from the URL > > > I use .Whatever, where that is some marketing term that is acceptable. > > At 10:39 AM 9/18/2003 -0400, Vic Cekvenich wrote: > >>How about a hack: >>*.jsp >>It looks as jsp on top.... but it's a do. >>Or you can even say *.asp, or anything. >>Just pick a word marketing likes. >> >>.V >> >>Matt Raible wrote: >> >>>I agree with you - however, it's a marketing thing. The project I'm on > > has > >>>implemented a lot of folder/index.html (with meta-refresh) so that > > marketing > >>>materials have pretty URLs. I was simply hoping to accomplish this > > without > >>>doing anything extra - so http://site.com/do/activities can be put into >>>marketing materials as http://site.com/activities. Maybe we could have >>>marketing use http://site.com/activities/index.html and then use a filter >>>(mapped to *.html) to do a redirect to http://site.com/do/activities. >>>Matt >>>-----Original Message----- >>>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] >>>Sent: Thursday, September 18, 2003 1:26 AM >>>To: Struts Users Mailing List >>>Subject: Re: Is it possible to remove *.do or /do/* from the URL >>> >>>The important principle here is "Web Application != Web Site". If your >>>users feel compelled to use bookmarks and the back button in your webapps, >>>despite efforts to train them correctly, this is a pretty good sign that >>>you have not provided enough suitable navigation controls in your basic >>>UI. >>>Craig >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > > LEGAL NOTICE > > This electronic mail transmission and any accompanying documents contain > information belonging to the sender which may be confidential and legally > privileged. This information is intended only for the use of the > individual or entity to whom this electronic mail transmission was sent as > indicated above. If you are not the intended recipient, any disclosure, > copying, distribution, or action taken in reliance on the contents of the > information contained in this transmission is strictly prohibited. If you > have received this transmission in error, please delete the message. Thank > you > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]