Hmmmmmmm.......... Why are you using the J2EE configuration? The key is
that smarturls will automatically redirect to / and you can just add a
/WEB-INF/content/index.jsp or an action and those can redirect or
forward or whatever. Is this something we should handle because there
are cases you must have a different welcome page? Or is this something
that is no longer necessary because of the smarturls/struts2 conventions?
-bp
Ted Husted wrote:
And on the subject of extensionless URIs and /index, I'm still haven't
figured out to use a default welcome page with an extensionless URI.
(See SmartURLs Issue 8.)
Past the initial welcome page, extensionless URIs work just fine. But
references to something like http://mailreader:8080/mailreader/ never
seems to work, unless we use an action extension, and don't use the
SmartURLs filter.
-Ted.
On Nov 2, 2007 10:04 AM, Ted Husted <[EMAIL PROTECTED]> wrote:
Just to follow up, I tried most of these using the 0.18 MailReader
using a .do extension mapping.
The result were the same, so long as "index.do" is appended to the end
of each of the URLs.
Without extension-mapping, evidentially, it tries to seek /index, and
then falls back to to the document-root /index when it isn't found in
the current directory.
-Ted.
On Nov 2, 2007 1:52 AM, Jeromy Evans <[EMAIL PROTECTED]> wrote:
Here's the same example in the unmodified MailReader:
Register a user and login:
GET http://localhost:8080/register/update!input allows you to edit your
current profile (okay)
GET http://localhost:8080/register/ shows the root index page (the one
at /index) (not okay)
GET
http://localhost:8080/register/login-input/register/login-input/register/login-input/
shows the root index page (not okay)
GET http://localhost:8080/register/update!input/login redirects to GET
http://localhost:8080/register/update!input/menu (not okay)
GET http://localhost:8080/subscribe/update!input/logout redirects to GET
http://localhost:8080/subscribe/update!input/index (not okay)
It seems to be a bit too eager matching actions in the root namespace.
Anyway, I wasn't intending to raise bugs. As I mentioned already, I
think this is going to be a great change, but the exception handling and
defaults need to be examined a little closer.
Hope that helps,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
