On Wed, 28 May 2003, Jason Carreira wrote:

> >
> > Doesn't it allready does this with the exception of
> > extracting servletPath according to the spec? If this is a
> > problem of ambiguous spec then maybe we should determine what
> > the majority of containers are doing, and also submit this
> > ambiguity to Sun. I thought Jetty was famous for keeping
> > strict to spec. So if in Jetty url-pattern * doesn't work,
> > maybe it's not in the spec. Then if /* returns paths as
> > described above, it's not too much work to adapt
> > ServletDispatcher to it (to spec?). Should I really need a
> > custom dispatcher? I'm not implemeting nothing new, and it's
> > not a question of making it work in 2 containers, but just to
> > make it work according to spec, which in the end means what
> > should be in url-pattern.
> >
> > Thanks
> > Fernando
> >
>
>
> ServletDispatcher is based on finding the action name by using "." as
> the delimter:
>
>         // Get action name ("Foo.action" -> "Foo" action)
>         int beginIdx = name.lastIndexOf("/");
>         int endIdx = name.lastIndexOf(".");
>
>         return name.substring(((beginIdx == -1) ? 0 : (beginIdx + 1)),
> (endIdx == -1) ? name.length() : endIdx);
>
> If we refactored out a parent class, we could have 2 subclasses, one of
> which finds the Action name from the "." and the other of which uses
> everything after the last "/" as the action name.
>
> Jason

Yes but if "." doesn't exist it allready uses everything after the last
"/" without throwing Exceptions, so in fact it's allready doing both
options. The problem is how to get the name to parse from the request, and
that should be done according to spec.

I only see reason for 2 classes if there is really some conflicting
behaviour that will not be possible to have transparently in
the same class.

Even if it will be really necessary 2 classes, you still have to figure
out what should go in url-pattern for it to work.

Fernando




-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to