• Post Reply Bookmark Topic Watch Topic
  • New Topic

Forwarding to servlet after JSF form submit

 
Naveen Sampra
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim and others,

I'm doing a form submit using: <h:commandLink value="Mark Approve" actionListener="#{pageBeanName.handleActions}" /> from an IFrame window on my page.

On the actionListener I want to update DB and forward the request to Dispatcher servlet which will re-render complete page including embeded JSF IFrame component.




I get the error: The requested resource (/sonic2/jsf/page/ps/qa/Dispatcher) is not available

This is because /jsf/page/ps/qa which is relative path to current JSF resource is pre-appended.

I need /sonic2/Dispatcher?rid=356& ......... format for the request to be forwarded successfully.

Any idea how to make this forward work ?

 
Tim Holloway
Bartender
Posts: 18412
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, embedding JSF in an IFRAME isn't something I would do lightly, but really, it seems like your problem here isn't JSF, it's just plain old URL formatting.

When you specify a URL beginning with "/", you're making a URL that's relative to the requesting server, but not to the webapp context. In other words, server-relative, path-absolute. Since J2EE typically has a context path, you need to prefix the URL with that context path, or the request won't be directed to the proper webapp.

On the strictly nitpicky side, the term "pre-append" is semantically strange, since the "app" in "append" means after. You can simply use the word "prepend", as a lot of people do, although I don't know if it's actually in the dictionary. Anyway, that's today's grammar lesson.

Also I know that in a lot of shops they get totally mental if you do straight string concatenation instead of using SrtingBuffer/StringBuilder. However, if you don't pay attention, you can actually be LESS efficient when you do that. That's because the compiler is going to do a fair amount of optimization on string concatenation expressions, but when you take direct control, it becomes harder to optimize (speaking as one who has written a compiler or 2). When you construct a largish string using StringBuilder, it's better to pre-allocate enough room for the ENTIRE string. That's because if you construct with a short string and keep appending to it, the initial buffer can't hold everything and has to be repeatedly expanded.

So


is usually going to be more efficient than


Because (if you picked a suitable worst-case length) the first example won't need to stop and expand the buffer, but the second case may actually need to do so for each append, in a worst-case scenario. And for short strings with relatively few appends, the worst-case scenario becomes extremely likely.
 
Naveen Sampra
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the tips on StringBuilder optimization and word optimization.

I'm still not sure if the issue is to do only with URL formating.
If you look at the error message, the J2EE context path or webapp path i.e /sonic2 is correctly prefixed.

However relative path to current JSF page jsf/page/ps/qa/ is also prefixed. This is causing forward to return a HTTP 404 error.

I'm looking into getRequestDispatcher behavior to try fix the path.

In the meantime are there any other suggestions to forward to a Servlet after JSF submit? Perhaps javascript on page that can be tied to an event.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!