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.