"In such a situation, <c:url> may be used to build a URL with query string parameters. <c:import> will remove any session id information if necessary (see Section 7.5)." -From section 7.4
I'll try filing a bug and see what the jakarta-taglib developers think.
For now, I'm prepending the "http://server:port"; to make it an absolute URL, but that's probably slower and certainly less elegant.
K.C.
P.S. Speaking of elegant, perhaps my best bet is to extend <c:import> with a custom tag....
Kris Schneider wrote:
You're right about why it's failing (prepending of app context). This kind of thing should work:
<c:set var="textURL" value="/text.html"/>
<c:import url="${textURL}"/>
You could then also use textURL with <c:url>:
<a href="<c:url value="${textURL}"/>">...
Quoting "K.C. Baltz" <[EMAIL PROTECTED]>:
For various reasons, I am generating a URL for a context relative resource using <c:url> and storing the result in a variable. Then I'm using that value in a <c:import> in an attempt to include the content of the resource in the page. Example:
<!-- Stores "/myContext/text.html" in the variable textURL --> <c:url value="/text.html" var="textURL" />
<!-- attempts to insert the contents of text.html in the page, but nothing happens -->
<c:import url="${textURL}" />
I'm pretty sure the problem is that <c:url> generates a url with a leading slash followed by the context name, when <c:import> expects URLs that start with a slash to be relative to the current context. The spec seems to indicate <c:import> can handle URLs generated with <c:url>, but I don't see how.
Help?
K.C.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
