• 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

Forwarding to servlet after JSF form submit

 
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ?

 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic