Nested request in c:import
Hi, Under jsp 2.0 (jstl 1.2), is there any way to force c:import, or perhaps the requestDispatcher.include() in particular, to set up a new request scope when the resource is in the same context? I'm using c:import to do sort of a lightweight tiles replacement for a page menu, and the imported servlet execution is stomping on some of my request variables that my controller sets up for the view. So, for example: Controller does request.setAttribute(someModel,x); jsp does c:import imported controller does request.setAttribute(someModel,y) jsp for imported controller is happy (finds y) import returns jspi for original controller finds y instead of x under someModel, and bad things happen. I'd really like the imported servlet to see a wrapped/cloned request, in which it muck with anything, but that the original request context is untouched. I don't know if this prohibited by the jsp spec though. Thanks, -Clint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nested request in c:import
For the same context, c:import is the equivalent of RequestDispatcher.include, so the request scope is essentially shared. Is it possible for you to refactor either the included servlet or your controller to avoid the stomping? Clint Popetz wrote: Hi, Under jsp 2.0 (jstl 1.2), is there any way to force c:import, or perhaps the requestDispatcher.include() in particular, to set up a new request scope when the resource is in the same context? I'm using c:import to do sort of a lightweight tiles replacement for a page menu, and the imported servlet execution is stomping on some of my request variables that my controller sets up for the view. So, for example: Controller does request.setAttribute(someModel,x); jsp does c:import imported controller does request.setAttribute(someModel,y) jsp for imported controller is happy (finds y) import returns jspi for original controller finds y instead of x under someModel, and bad things happen. I'd really like the imported servlet to see a wrapped/cloned request, in which it muck with anything, but that the original request context is untouched. I don't know if this prohibited by the jsp spec though. Thanks, -Clint -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nested request in c:import
On 8/3/06, Kris Schneider [EMAIL PROTECTED] wrote: For the same context, c:import is the equivalent of RequestDispatcher.include, so the request scope is essentially shared. Is it possible for you to refactor either the included servlet or your controller to avoid the stomping? Not easily. But I just checked around, and the Spring MVC controller had a bit of code to check for the presence of javax.servlet.include.request_uri in the request and save away a copy of the request attributes, restoring them after view rendering, so that's what I'll do. -Clint Clint Popetz wrote: Hi, Under jsp 2.0 (jstl 1.2), is there any way to force c:import, or perhaps the requestDispatcher.include() in particular, to set up a new request scope when the resource is in the same context? I'm using c:import to do sort of a lightweight tiles replacement for a page menu, and the imported servlet execution is stomping on some of my request variables that my controller sets up for the view. So, for example: Controller does request.setAttribute(someModel,x); jsp does c:import imported controller does request.setAttribute(someModel,y) jsp for imported controller is happy (finds y) import returns jspi for original controller finds y instead of x under someModel, and bad things happen. I'd really like the imported servlet to see a wrapped/cloned request, in which it muck with anything, but that the original request context is untouched. I don't know if this prohibited by the jsp spec though. Thanks, -Clint -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: relative paths and c:import
Isn't there another solution? I do control both servers but forcing to use absolute URLs via a CMS would be a problem. I can imagine witing sort of a wrapper to adapt the result of c:import, but this must be a common problem. So I hope someone has already done the job? Martin -Ursprüngliche Nachricht- Von: Rahul Akolkar [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 22. November 2005 04:07 An: Tag Libraries Users List Betreff: Re: relative paths and c:import On 11/21/05, Martin Kindler [EMAIL PROTECTED] wrote: I am trying to integrate a Java/Struts webapp with another web site (based on Typo3, a PHP-based CMS). Some of my JSP-pages will integrate pages controlled by Typo3. I tried to use the c:import tag which basically seems to work: the page is fetched and the HTML-code inserted into my Struts-controlled page. But: relative URLs (especially images) are now relative to my context, meaning they are broken. The Typo3 site will be on another server than the Struts site. So, saying the URL of my Struts action is http://myStrutsApp.myServer.de/myContext/ShowIntegratedPage.do and c:import url=http://myTypo3App.anotherServer.de/myTypo3Page.php/ is part of the JSP, relative paths from myTypo3Page.php like img src=img/foo.jpg/, which should be interpreted as http://myTypo3App.anotherServer.de/img/foo.jpg will be interpreted as http://myStrutsApp.myServer.de/myContext/img/foo.jpg. snip/ If one webserver is serving content generated by another, absolute URLs are probably going to be necessary. -Rahul I tried the context-attribute (which seems only to work for other container based apps) and explicitly specifying a base-tag in my Typo3 page (soes not work). Can someone please help me? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: relative paths and c:import
On Tue, Nov 22, 2005 at 06:38:34PM +0100, Martin Kindler wrote: Isn't there another solution? I do control both servers but forcing to use absolute URLs via a CMS would be a problem. I can imagine witing sort of a wrapper to adapt the result of c:import, but this must be a common problem. So I hope someone has already done the job? You could try to write a bunch of regex's to do things like s/img src=.../img src=http:.../ (good luck. let me know which insane asylum you check into.) Depending on the structure of your site, you could also try putting the CMS servers content in an iframe. Of course, that completely sidesteps the whole issue since your jsp won't actually be doing the import anymore, so it doesn't work if you fiddling with the data in any way. Why is using absolute URLs a problem? It's really the _only_ way to refer to content that's on a different server. If you are actually processing the data from the CMS server in your jsp page the best way to fix it would probably be to have the jsp page entirely parse out the imported content and regenerate it. Of course, that's going to be a bit more work, and you'll probably want to communicate using xml instead of an arbitrary web page from the CMS web server. eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
relative paths and c:import
I am trying to integrate a Java/Struts webapp with another web site (based on Typo3, a PHP-based CMS). Some of my JSP-pages will integrate pages controlled by Typo3. I tried to use the c:import tag which basically seems to work: the page is fetched and the HTML-code inserted into my Struts-controlled page. But: relative URLs (especially images) are now relative to my context, meaning they are broken. The Typo3 site will be on another server than the Struts site. So, saying the URL of my Struts action is http://myStrutsApp.myServer.de/myContext/ShowIntegratedPage.do and c:import url=http://myTypo3App.anotherServer.de/myTypo3Page.php/ is part of the JSP, relative paths from myTypo3Page.php like img src=img/foo.jpg/, which should be interpreted as http://myTypo3App.anotherServer.de/img/foo.jpg will be interpreted as http://myStrutsApp.myServer.de/myContext/img/foo.jpg. I tried the context-attribute (which seems only to work for other container based apps) and explicitly specifying a base-tag in my Typo3 page (soes not work). Can someone please help me? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: relative paths and c:import
On 11/21/05, Martin Kindler [EMAIL PROTECTED] wrote: I am trying to integrate a Java/Struts webapp with another web site (based on Typo3, a PHP-based CMS). Some of my JSP-pages will integrate pages controlled by Typo3. I tried to use the c:import tag which basically seems to work: the page is fetched and the HTML-code inserted into my Struts-controlled page. But: relative URLs (especially images) are now relative to my context, meaning they are broken. The Typo3 site will be on another server than the Struts site. So, saying the URL of my Struts action is http://myStrutsApp.myServer.de/myContext/ShowIntegratedPage.do and c:import url=http://myTypo3App.anotherServer.de/myTypo3Page.php/ is part of the JSP, relative paths from myTypo3Page.php like img src=img/foo.jpg/, which should be interpreted as http://myTypo3App.anotherServer.de/img/foo.jpg will be interpreted as http://myStrutsApp.myServer.de/myContext/img/foo.jpg. snip/ If one webserver is serving content generated by another, absolute URLs are probably going to be necessary. -Rahul I tried the context-attribute (which seems only to work for other container based apps) and explicitly specifying a base-tag in my Typo3 page (soes not work). Can someone please help me? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
c:import for dynamic content
I am attempting to import a JSP file into a JSP using the c:import tag. The line looks something like this: ... c:import url=file://c:/dira/dirb/imported-file.jsp/ .. imported-file.jsp is being found ok, but it is not being processed as a JSP, it is appearing as static text. I am using some struts tags in imported-file.jsp that are just getting sent to the browser. Is there something I'm doing wrong here? Is there something I need to place around the c:import to make the imported file get processed? I am running this on jboss 4.0.1 (tomcat 5.0) with JSTL 1.1. Any help would be greatly appreciated. Rob
Re: c:import for dynamic content
On 11/3/05, Robert Butera [EMAIL PROTECTED] wrote: I am attempting to import a JSP file into a JSP using the c:import tag. The line looks something like this: ... c:import url=file://c:/dira/dirb/imported-file.jsp/ .. imported-file.jsp is being found ok, but it is not being processed as a JSP, it is appearing as static text. That's because, since you are using a file URL, the request is not being made via HTTP, and thus is not being processed by a container as a JSP page request. You'll need to use an HTTP (or HTTPS) URL to get the file processed as JSP. -- Martin Cooper I am using some struts tags in imported-file.jsp that are just getting sent to the browser. Is there something I'm doing wrong here? Is there something I need to place around the c:import to make the imported file get processed? I am running this on jboss 4.0.1 (tomcat 5.0) with JSTL 1.1. Any help would be greatly appreciated. Rob
c:import doesn't work with HEAD requests
I've been trying to figure out why occasionally my webapp gets
Premature end of file errors when trying to parse an xml configuration
file using x:parse. I finally figured out that it's not x:parse's fault
and the eof error is correct since the data it is getting fed ends up
being empty.
This happens when a HEAD request is received, instead of a GET reqeust.
It appears that the c:import tag doesn't actually import the requested url
in that case!
I created a minimal test case, which is attached. The output in the
log (catalina.out) shows that when a GET is performed, the testit.xml file
is correctly read, but when a HEAD is performed the Reader object has no
data.
I am using Tomcat 5.0.30 and JSTL 1.1.1. I looked at the release notes
for 1.1.2 but none of the bug fixes seem to apply to this.
Is there a bug for this already? Is this perhaps a Tomcat bug?
eric
%@ taglib uri=http://java.sun.com/jsp/jstl/xml; prefix=x %
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
c:import url=/testit.xml varReader=xmlSource
%
java.io.StringReader o =
(java.io.StringReader)pageContext.getAttribute(xmlSource);
System.out.println(o: + o);
char[] buf = new char[1];
while (o.read(buf) 0)
{
System.out.print(buf);
}
System.out.println();
System.out.println(--);
o.reset();
%
x:parse xml=${xmlSource} var=xmldoc /
/c:import
%
System.out.println(XX parsed ok);
%
worked: ${xmldoc}
foo
data data data
/foo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import and context attribute
Dylan MacDonald [EMAIL PROTECTED] wrote on 07/13/2005 05:41:46 PM: Can someone explain the context attribute in the c:import tag? snip/ It is used in cross-context imports and is the name of the context you're importing from. Most containers need to be configured to enable cross-context access. I'm working in a development environment that differs from the production environment in that the root of the server isn't /, it's /www (the production root is obviously /). snap/ I'm not sure I got this (I thought for a bit you were implying the difference between deploying, say, ROOT.war and mywebapp.war on Tomcat). In any case, relative urls like the one in the first c:import below should work if you are migrating all the contents of the context from the production to the dev environment. Portable code will prepend the context path obtained from the request at JSP invocation to any urls that need it. I don't think there is a cross-context angle to your problem, in reference to your earlier question about the context attribute. -Rahul Needless to say this makes it difficult to code anything with root-relative (e.g. /images/logo.gif) links. I can probably work around some of this but I thought I might be able to solve some of my issues with my jsp includes using the context attribute. But I cannot get it to work. I assumed I would change my c:import tag from this c:import url=includes/footer.jsp / to this: c:import url=/includes/footer.jsp context=/www / but that doesn't work. Any ideas? Thanks, Dylan MacDonald
c:import with non-english url
Hi,
I'm trying to use non-English url in
c:import url={my non-english url}
I'm getting fileNotFound exception even though I have URLEncode the url.
Is there any solution for this problem?
Thank you.
--
Regards,
Peik Feng
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: c:import problem
Hi Kris, Thanks for the reply. I have managed to get it worked out, but only be looking even closer at the Tomcat source. It turns out to be the way Tomcat wraps a request when using a RequestDispatcher. If the request given to the dispatcher is a wrapper, Tomcat will look up the chain until it finds the real original non-wrapped request, and wrap that. That was a bit different than the behaviour I expected (I assumed it would wrap my own wrapper, not look for the original request). I modified my own wrapper's getParameter() method to call super.getParameter() and now it works. This behavour isn't specified in the servlet spec or the Tomcat docs... Maybe it should be (would've saved me 5 hours of debugging). But I'll bring that up on an appropriate list and not here. Thanks again for replying. Christian -Original Message- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 4:03 PM To: Tag Libraries Users List Subject: Re: c:import problem Christian, Not sure if you're still wrestling with this, but I just wanted to post to say that I've been meaning to slap a little test app together as a sanity check and I'll post back when I get the chance to code run it... Quoting Christian Taylor [EMAIL PROTECTED]: Hi, I'm new to this list, but far from a newbie when it comes to servlets, JSP, JSTL and Tomcat. I've spent hours trying to debug this problem, searched the net and mailing lists and haven't been able to find a solution. Here is my situation: My application has many pages that use c:import to include a common header. The header takes a title parameter. I've seen other people doing this in the archives of this list. My code looks like this: c:import url=/include/header.jsp c:param name=title value=Title of the page/ /c:import header.jsp uses the title for the title tag as well as to display to the user at the top of the page. These pages can be accessed in two different ways: 1) By a normal user of the application through a web browser 2) From a servlet that uses RequestDispatchers to capture some pages to save as files that can be viewed offline. The problem I'm having is with #2. The title parameter does NOT get passed to header.jsp, and neither do request-scoped variables. My offline servlet creates request and response wrappers to pass to the RequestDispatcher's include() method. The wrapped request overrides the relevent parameter methods (getParameter(), getParameterMap(), etc.) and provides setter methods so I can pass parameters to the pages to be captured. It also defines a request-scoped variable called _OfflineBackup which the pages can use to detect how they are being accessed (some paths, etc. need to be different if the page is to work offline). My response wrapper is a typical override getOutputStream() and getWriter() to capture the output type of thing. I've looked through the Tomcat and taglibs-standard sources and can't find anything that would help. The code for the c:import tag appears to build a query string from the c:param tags and pass it as part of the URL to the RequestDispatcher it creates, but Tomcat's ApplicationDispatcher implementation doesn't seem to do anything with it, from what I can see in the source (but I'm not a Tomcat developer and am not that familiar with the source). The parameters in the wrapped request can be accessed from header.jsp, but not the actual parameters passed to header.jsp using c:param. This all leads me to my real question... why does my 'title' parameter work fine when I simply view the pages normally in a browser, but not when I use a RequestDispatcher and my wrapped request/response? The problem appears to be that Tomcat doesn't look at the parameters in the path when getRequestDispatcher(path) is called, which makes me wonder why the c:param tag ever works at all (but as I said, I'm not a Tomcat developer and have limited knowledge of the source so I could be wrong here, this is just what I've found from digging through the sources). My wrappers seem to be working fine, and the import works properly when viewing the page in a browser. I hope I explained everything well enough and I apologize for this being a bit long. I'm using Tomcat 5.0.28 and taglibs-standard 1.1.1. This is a servlet 2.4/jsp 2.0 application. Thanks in advance to anyone who might be able to help me here! Christian -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import problem
Christian, Not sure if you're still wrestling with this, but I just wanted to post to say that I've been meaning to slap a little test app together as a sanity check and I'll post back when I get the chance to code run it... Quoting Christian Taylor [EMAIL PROTECTED]: Hi, I'm new to this list, but far from a newbie when it comes to servlets, JSP, JSTL and Tomcat. I've spent hours trying to debug this problem, searched the net and mailing lists and haven't been able to find a solution. Here is my situation: My application has many pages that use c:import to include a common header. The header takes a title parameter. I've seen other people doing this in the archives of this list. My code looks like this: c:import url=/include/header.jsp c:param name=title value=Title of the page/ /c:import header.jsp uses the title for the title tag as well as to display to the user at the top of the page. These pages can be accessed in two different ways: 1) By a normal user of the application through a web browser 2) From a servlet that uses RequestDispatchers to capture some pages to save as files that can be viewed offline. The problem I'm having is with #2. The title parameter does NOT get passed to header.jsp, and neither do request-scoped variables. My offline servlet creates request and response wrappers to pass to the RequestDispatcher's include() method. The wrapped request overrides the relevent parameter methods (getParameter(), getParameterMap(), etc.) and provides setter methods so I can pass parameters to the pages to be captured. It also defines a request-scoped variable called _OfflineBackup which the pages can use to detect how they are being accessed (some paths, etc. need to be different if the page is to work offline). My response wrapper is a typical override getOutputStream() and getWriter() to capture the output type of thing. I've looked through the Tomcat and taglibs-standard sources and can't find anything that would help. The code for the c:import tag appears to build a query string from the c:param tags and pass it as part of the URL to the RequestDispatcher it creates, but Tomcat's ApplicationDispatcher implementation doesn't seem to do anything with it, from what I can see in the source (but I'm not a Tomcat developer and am not that familiar with the source). The parameters in the wrapped request can be accessed from header.jsp, but not the actual parameters passed to header.jsp using c:param. This all leads me to my real question... why does my 'title' parameter work fine when I simply view the pages normally in a browser, but not when I use a RequestDispatcher and my wrapped request/response? The problem appears to be that Tomcat doesn't look at the parameters in the path when getRequestDispatcher(path) is called, which makes me wonder why the c:param tag ever works at all (but as I said, I'm not a Tomcat developer and have limited knowledge of the source so I could be wrong here, this is just what I've found from digging through the sources). My wrappers seem to be working fine, and the import works properly when viewing the page in a browser. I hope I explained everything well enough and I apologize for this being a bit long. I'm using Tomcat 5.0.28 and taglibs-standard 1.1.1. This is a servlet 2.4/jsp 2.0 application. Thanks in advance to anyone who might be able to help me here! Christian -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
c:import problem
Hi, I'm new to this list, but far from a newbie when it comes to servlets, JSP, JSTL and Tomcat. I've spent hours trying to debug this problem, searched the net and mailing lists and haven't been able to find a solution. Here is my situation: My application has many pages that use c:import to include a common header. The header takes a title parameter. I've seen other people doing this in the archives of this list. My code looks like this: c:import url=/include/header.jsp c:param name=title value=Title of the page/ /c:import header.jsp uses the title for the title tag as well as to display to the user at the top of the page. These pages can be accessed in two different ways: 1) By a normal user of the application through a web browser 2) From a servlet that uses RequestDispatchers to capture some pages to save as files that can be viewed offline. The problem I'm having is with #2. The title parameter does NOT get passed to header.jsp, and neither do request-scoped variables. My offline servlet creates request and response wrappers to pass to the RequestDispatcher's include() method. The wrapped request overrides the relevent parameter methods (getParameter(), getParameterMap(), etc.) and provides setter methods so I can pass parameters to the pages to be captured. It also defines a request-scoped variable called _OfflineBackup which the pages can use to detect how they are being accessed (some paths, etc. need to be different if the page is to work offline). My response wrapper is a typical override getOutputStream() and getWriter() to capture the output type of thing. I've looked through the Tomcat and taglibs-standard sources and can't find anything that would help. The code for the c:import tag appears to build a query string from the c:param tags and pass it as part of the URL to the RequestDispatcher it creates, but Tomcat's ApplicationDispatcher implementation doesn't seem to do anything with it, from what I can see in the source (but I'm not a Tomcat developer and am not that familiar with the source). The parameters in the wrapped request can be accessed from header.jsp, but not the actual parameters passed to header.jsp using c:param. This all leads me to my real question... why does my 'title' parameter work fine when I simply view the pages normally in a browser, but not when I use a RequestDispatcher and my wrapped request/response? The problem appears to be that Tomcat doesn't look at the parameters in the path when getRequestDispatcher(path) is called, which makes me wonder why the c:param tag ever works at all (but as I said, I'm not a Tomcat developer and have limited knowledge of the source so I could be wrong here, this is just what I've found from digging through the sources). My wrappers seem to be working fine, and the import works properly when viewing the page in a browser. I hope I explained everything well enough and I apologize for this being a bit long. I'm using Tomcat 5.0.28 and taglibs-standard 1.1.1. This is a servlet 2.4/jsp 2.0 application. Thanks in advance to anyone who might be able to help me here! Christian
Works: Struts + c:import w/ Tomcat 5.0.18!!!
Hiho all, Just for interest: with Tomcat 5.0.18 (prior: 5.0.16) it finally works: Including a fragment using JSTL's c:import or jsp:include that is invoked by a Struts Action! Prior, it failed, when the importing JSP was also invoked by a Struts action; thus having two Struts' Action calls in one physical request. Now this finally works w/ the same JSTL 1.1 and Struts JARs! Thanks Apache! BTW.: or does someone know if this shall work even w/ prior versions? I once found a bug report regarding that special problem; but culd not remember if this was for Struts, JSTL or Tomcat. -- greetings, | /\ | \ / ASCII-Ribbon-Campaign Timo | X Against HTML Mail | / \ -- PUBLIC KEY: 52F3311A Timo Boewing [EMAIL PROTECTED] 2003/10/30 Fingerprint = F743 E0AA A2F0 1B33 F6FA 417B 72BE 740D 52F3 311A signature.asc Description: This is a digitally signed message part
c:import Not Throwing Error For Bad In-Context-JSP url Attribute
There seems to be an inconsistent behavior in the way c:import throws
errors for non-existent files. When the c:import url attribute is an
in-context-jsp (like pageHeader.jsp) that doesn't exist, no error is
thrown. However, when the url attribute is a file: that doesn't exist, an
error is thrown. Can anyone confirm, or explain this behavior?
I'm using the following pattern:
c:catch var=importError
c:import url=${param.pageURL}/
/c:catch
c:if test=${not empty importError}
c:out value=${importError.message}/
/c:if
Thank you.
- Jim
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import Not Throwing Error For Bad In-Context-JSP url Attribute
I think this is addressed in the 7.4 c:import section of the JSTL 1.0
Spec. There's an explanation of how errors are handled for internal vs.
external resources. Give it a look and see if it helps.
James Watkin wrote:
There seems to be an inconsistent behavior in the way c:import throws
errors for non-existent files. When the c:import url attribute is an
in-context-jsp (like pageHeader.jsp) that doesn't exist, no error is
thrown. However, when the url attribute is a file: that doesn't exist,
an error is thrown. Can anyone confirm, or explain this behavior?
I'm using the following pattern:
c:catch var=importError
c:import url=${param.pageURL}/
/c:catch
c:if test=${not empty importError}
c:out value=${importError.message}/
/c:if
Thank you.
- Jim
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import Not Throwing Error For Bad In-Context-JSP url Attribute
I'm not an expert in this area, but after looking at the spec:
http://jcp.org/aboutJava/communityprocess/final/jsr052/index.html
it seems like a JspException should be thrown, even for internal URLs. It's
quite possible that I'm overlooking something though.
- Jim
At 05:50 PM 1/22/2004 -0500, you wrote:
I think this is addressed in the 7.4 c:import section of the JSTL 1.0
Spec. There's an explanation of how errors are handled for internal vs.
external resources. Give it a look and see if it helps.
James Watkin wrote:
There seems to be an inconsistent behavior in the way c:import throws
errors for non-existent files. When the c:import url attribute is an
in-context-jsp (like pageHeader.jsp) that doesn't exist, no error is
thrown. However, when the url attribute is a file: that doesn't exist,
an error is thrown. Can anyone confirm, or explain this behavior?
I'm using the following pattern:
c:catch var=importError
c:import url=${param.pageURL}/
/c:catch
c:if test=${not empty importError}
c:out value=${importError.message}/
/c:if
Thank you.
- Jim
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import Not Throwing Error For Bad In-Context-JSP url Attribute
For an internal URL, try the equivalent JSP:
%
String path = request.getParameter(pageURL);
RequestDispatcher rd = request.getRequestDispatcher(path);
rd.include(request, response);
%
It seems to behave the same way. With TC 4.1.29, I don't see any log
info about the include, but on WLS 8.1.2 I get the following:
...Included resource or file /foo.jsp not found from requested
resource /import.jsp.
No exceptions are thrown, however, just an error logged.
James Watkin wrote:
I'm not an expert in this area, but after looking at the spec:
http://jcp.org/aboutJava/communityprocess/final/jsr052/index.html
it seems like a JspException should be thrown, even for internal URLs.
It's quite possible that I'm overlooking something though.
- Jim
At 05:50 PM 1/22/2004 -0500, you wrote:
I think this is addressed in the 7.4 c:import section of the JSTL
1.0 Spec. There's an explanation of how errors are handled for
internal vs. external resources. Give it a look and see if it helps.
James Watkin wrote:
There seems to be an inconsistent behavior in the way c:import
throws errors for non-existent files. When the c:import url
attribute is an in-context-jsp (like pageHeader.jsp) that doesn't
exist, no error is thrown. However, when the url attribute is a
file: that doesn't exist, an error is thrown. Can anyone confirm,
or explain this behavior?
I'm using the following pattern:
c:catch var=importError
c:import url=${param.pageURL}/
/c:catch
c:if test=${not empty importError}
c:out value=${importError.message}/
/c:if
Thank you.
- Jim
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
James Watkin
ACIS Software Development
The Anderson School at UCLA
[EMAIL PROTECTED]
Voice: 1-310-825-5030
Fax: 1-310-825-4835
__
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Q: c:forEach, c:import and variable scope?
Hello,
Here is the problem (using [] to avoid problems with email
clients not handling HTML well).
Summary:
c:forEach loop, inside it c:import, but the c:import-ed JSP does
not see the var from the c:forEach loop.
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
No go. ${foo} seems undefined there :( page.jsp does not see
it. Scope issue?
I then tried adding the following inside that c:forEach:
[c:set var=newFoo value=${foo} scope=request/]
However, that c:import-ed page.jsp does not see ${newFoo}
either. :(
I am using jakarta-taglibs 1.0.3 with JBoss/Jetty.
Is the above supposed to work?
How do I get the import-ed page.jsp to see a variable defined in
the page that imported it?
Thanks,
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: c:forEach, c:import and variable scope?
I can't see how that could work. The c:import operation is processing
that URL in an external context. You'd probably have to use
jsp:include for that sort of thing.
-Original Message-
From: otisg [mailto:[EMAIL PROTECTED]
Here is the problem (using [] to avoid problems with email
clients not handling HTML well).
Summary:
c:forEach loop, inside it c:import, but the c:import-ed JSP does
not see the var from the c:forEach loop.
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
No go. ${foo} seems undefined there :( page.jsp does not see
it. Scope issue?
I then tried adding the following inside that c:forEach:
[c:set var=newFoo value=${foo} scope=request/]
However, that c:import-ed page.jsp does not see ${newFoo}
either. :(
I am using jakarta-taglibs 1.0.3 with JBoss/Jetty.
Is the above supposed to work?
How do I get the import-ed page.jsp to see a variable defined in
the page that imported it?
Thanks,
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:forEach, c:import and variable scope?
I don't have my code in front of me, but I am pretty sure that is exactly
what I do for my client. I don't even recall having to set request scope,
but I'm not positive there.
Tomcat 5.x/JSTL 1.1
R
- Original Message -
From: Karr, David [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 11:21 AM
Subject: RE: c:forEach, c:import and variable scope?
I can't see how that could work. The c:import operation is processing
that URL in an external context. You'd probably have to use
jsp:include for that sort of thing.
-Original Message-
From: otisg [mailto:[EMAIL PROTECTED]
Here is the problem (using [] to avoid problems with email
clients not handling HTML well).
Summary:
c:forEach loop, inside it c:import, but the c:import-ed JSP does
not see the var from the c:forEach loop.
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
No go. ${foo} seems undefined there :( page.jsp does not see
it. Scope issue?
I then tried adding the following inside that c:forEach:
[c:set var=newFoo value=${foo} scope=request/]
However, that c:import-ed page.jsp does not see ${newFoo}
either. :(
I am using jakarta-taglibs 1.0.3 with JBoss/Jetty.
Is the above supposed to work?
How do I get the import-ed page.jsp to see a variable defined in
the page that imported it?
Thanks,
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:forEach, c:import and variable scope?
How bout this:
c:forEach var=foo items=${bars}
c:import url=some/page.jsp
c:param name=foop value=${foo}/
/c:import
/c:forEach
some/page.jsp
c:out value=${param.foop}/
-Ben
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
From: Rick Ross [EMAIL PROTECTED]
Reply-To: Tag Libraries Users List [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Subject: Re: c:forEach, c:import and variable scope?
Date: Tue, 9 Dec 2003 11:27:54 -0800
I don't have my code in front of me, but I am pretty sure that is exactly
what I do for my client. I don't even recall having to set request scope,
but I'm not positive there.
Tomcat 5.x/JSTL 1.1
R
- Original Message -
From: Karr, David [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 11:21 AM
Subject: RE: c:forEach, c:import and variable scope?
I can't see how that could work. The c:import operation is processing
that URL in an external context. You'd probably have to use
jsp:include for that sort of thing.
-Original Message-
From: otisg [mailto:[EMAIL PROTECTED]
Here is the problem (using [] to avoid problems with email
clients not handling HTML well).
Summary:
c:forEach loop, inside it c:import, but the c:import-ed JSP does
not see the var from the c:forEach loop.
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
No go. ${foo} seems undefined there :( page.jsp does not see
it. Scope issue?
I then tried adding the following inside that c:forEach:
[c:set var=newFoo value=${foo} scope=request/]
However, that c:import-ed page.jsp does not see ${newFoo}
either. :(
I am using jakarta-taglibs 1.0.3 with JBoss/Jetty.
Is the above supposed to work?
How do I get the import-ed page.jsp to see a variable defined in
the page that imported it?
Thanks,
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Shop online for kids toys by age group, price range, and toy category at
MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:forEach, c:import and variable scope?
Karr, David wrote:
I can't see how that could work. The c:import operation is processing
that URL in an external context. You'd probably have to use
jsp:include for that sort of thing.
Actually, the problem is that c:forEach exposes the current element
through a _page_ scope variable named by the var attribute, and an
included page (whether by c:import or jsp:include) doesn't see
page scope variables.
You can promote the variable to request scope, which is seen by the
included page:
[c:forEach var=foo items=${bars}]
[c:set var=foo scope=request value=${foo}/]
[c:import url=some/page.jsp/]
[/c:forEach]
or, if you use JSP 2.0, use a tag file custom action instead of
including a different JSP page. See the sample chapter from the 3rd
edition of my JSP book (should be in the stores any day now) for more
about tag files:
http://www.oreilly.com/catalog/jserverpages3/chapter/index.html
Hans
-Original Message-
From: otisg [mailto:[EMAIL PROTECTED]
Here is the problem (using [] to avoid problems with email
clients not handling HTML well).
Summary:
c:forEach loop, inside it c:import, but the c:import-ed JSP does
not see the var from the c:forEach loop.
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
No go. ${foo} seems undefined there :( page.jsp does not see
it. Scope issue?
I then tried adding the following inside that c:forEach:
[c:set var=newFoo value=${foo} scope=request/]
However, that c:import-ed page.jsp does not see ${newFoo}
either. :(
I am using jakarta-taglibs 1.0.3 with JBoss/Jetty.
Is the above supposed to work?
How do I get the import-ed page.jsp to see a variable defined in
the page that imported it?
Thanks,
Otis
--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 2.0 and JSTL 1.1
Details athttp://TheJSPBook.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:forEach, c:import and variable scope?
Ben Anderson wrote:
How bout this:
c:forEach var=foo items=${bars}
c:import url=some/page.jsp
c:param name=foop value=${foo}/
/c:import
/c:forEach
some/page.jsp
c:out value=${param.foop}/
-Ben
That should also work, but so should promoting it to request scope.
If it doesn't, there's a bug somewhere, maybe in the c:import
implementation (I don't think so) or in Jetty's PageContext or
RequestDispatcher include() methods implementation.
Hans
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
From: Rick Ross [EMAIL PROTECTED]
Reply-To: Tag Libraries Users List [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Subject: Re: c:forEach, c:import and variable scope?
Date: Tue, 9 Dec 2003 11:27:54 -0800
I don't have my code in front of me, but I am pretty sure that is exactly
what I do for my client. I don't even recall having to set request
scope,
but I'm not positive there.
Tomcat 5.x/JSTL 1.1
R
- Original Message -
From: Karr, David [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 11:21 AM
Subject: RE: c:forEach, c:import and variable scope?
I can't see how that could work. The c:import operation is
processing
that URL in an external context. You'd probably have to use
jsp:include for that sort of thing.
-Original Message-
From: otisg [mailto:[EMAIL PROTECTED]
Here is the problem (using [] to avoid problems with email
clients not handling HTML well).
Summary:
c:forEach loop, inside it c:import, but the c:import-ed JSP does
not see the var from the c:forEach loop.
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
No go. ${foo} seems undefined there :( page.jsp does not see
it. Scope issue?
I then tried adding the following inside that c:forEach:
[c:set var=newFoo value=${foo} scope=request/]
However, that c:import-ed page.jsp does not see ${newFoo}
either. :(
I am using jakarta-taglibs 1.0.3 with JBoss/Jetty.
Is the above supposed to work?
How do I get the import-ed page.jsp to see a variable defined in
the page that imported it?
Thanks,
Otis
--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 2.0 and JSTL 1.1
Details athttp://TheJSPBook.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: c:forEach, c:import and variable scope?
Wow, thanks for quick replies (problem not 100% solved, but all
replies helped!)
Comment below.
On Tue, 09 Dec 2003, Hans Bergsten
([EMAIL PROTECTED]) wrote:
Karr, David wrote:
I can't see how that could work. The c:import operation
is processing
that URL in an external context. You'd probably have to
use
jsp:include for that sort of thing.
Actually, the problem is that c:forEach exposes the current
element
through a _page_ scope variable named by the var attribute,
and an
included page (whether by c:import or jsp:include) doesn't
see
page scope variables.
Right, that is why I tried using c:set with session=request,
exactly as you wrote below. That didn't work with c:import.
I did try %@ include file=some/page.jsp % and that worked.
I would still prefer a more JSTL-ish way.
You can promote the variable to request scope, which is seen
by the
included page:
[c:forEach var=foo items=${bars}]
[c:set var=foo scope=request value=${foo}/]
[c:import url=some/page.jsp/]
[/c:forEach]
This didn't work for me with JBoss/Jetty (not the latest and
greatest).
I am trying the suggestion with c:param enclosed in c:import
now...
Otis
or, if you use JSP 2.0, use a tag file custom action instead
of
including a different JSP page. See the sample chapter from
the 3rd
edition of my JSP book (should be in the stores any day now)
for more
about tag files:
http://www.oreilly.com/catalog/jserverpages3/chapter/index.html
Hans
-Original Message-
From: otisg [mailto:[EMAIL PROTECTED]
Here is the problem (using [] to avoid problems with email
clients not handling HTML well).
Summary:
c:forEach loop, inside it c:import, but the c:import-ed JSP
does
not see the var from the c:forEach loop.
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
No go. ${foo} seems undefined there :( page.jsp does not
see
it. Scope issue?
I then tried adding the following inside that c:forEach:
[c:set var=newFoo value=${foo} scope=request/]
However, that c:import-ed page.jsp does not see ${newFoo}
either. :(
I am using jakarta-taglibs 1.0.3 with JBoss/Jetty.
Is the above supposed to work?
How do I get the import-ed page.jsp to see a variable
defined in
the page that imported it?
Thanks,
Otis
--
Hans Bergsten
[EMAIL PROTECTED]
Gefion Software
http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 2.0 and
JSTL 1.1
Details at
http://TheJSPBook.com/
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: c:forEach, c:import and variable scope?
We exist to serve. :-)
R
- Original Message -
From: otisg [EMAIL PROTECTED]
To: Hans Bergsten [EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 11:45 AM
Subject: Re: Re: c:forEach, c:import and variable scope?
Wow, thanks for quick replies (problem not 100% solved, but all
replies helped!)
Comment below.
On Tue, 09 Dec 2003, Hans Bergsten
([EMAIL PROTECTED]) wrote:
Karr, David wrote:
I can't see how that could work. The c:import operation
is processing
that URL in an external context. You'd probably have to
use
jsp:include for that sort of thing.
Actually, the problem is that c:forEach exposes the current
element
through a _page_ scope variable named by the var attribute,
and an
included page (whether by c:import or jsp:include) doesn't
see
page scope variables.
Right, that is why I tried using c:set with session=request,
exactly as you wrote below. That didn't work with c:import.
I did try %@ include file=some/page.jsp % and that worked.
I would still prefer a more JSTL-ish way.
You can promote the variable to request scope, which is seen
by the
included page:
[c:forEach var=foo items=${bars}]
[c:set var=foo scope=request value=${foo}/]
[c:import url=some/page.jsp/]
[/c:forEach]
This didn't work for me with JBoss/Jetty (not the latest and
greatest).
I am trying the suggestion with c:param enclosed in c:import
now...
Otis
or, if you use JSP 2.0, use a tag file custom action instead
of
including a different JSP page. See the sample chapter from
the 3rd
edition of my JSP book (should be in the stores any day now)
for more
about tag files:
http://www.oreilly.com/catalog/jserverpages3/chapter/index.html
Hans
-Original Message-
From: otisg [mailto:[EMAIL PROTECTED]
Here is the problem (using [] to avoid problems with email
clients not handling HTML well).
Summary:
c:forEach loop, inside it c:import, but the c:import-ed JSP
does
not see the var from the c:forEach loop.
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
No go. ${foo} seems undefined there :( page.jsp does not
see
it. Scope issue?
I then tried adding the following inside that c:forEach:
[c:set var=newFoo value=${foo} scope=request/]
However, that c:import-ed page.jsp does not see ${newFoo}
either. :(
I am using jakarta-taglibs 1.0.3 with JBoss/Jetty.
Is the above supposed to work?
How do I get the import-ed page.jsp to see a variable
defined in
the page that imported it?
Thanks,
Otis
--
Hans Bergsten
[EMAIL PROTECTED]
Gefion Software
http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 2.0 and
JSTL 1.1
Details at
http://TheJSPBook.com/
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Q: c:forEach, c:import and variable scope?
On Tue, 9 Dec 2003, otisg wrote:
Hello,
Here is the problem (using [] to avoid problems with email
clients not handling HTML well).
Summary:
c:forEach loop, inside it c:import, but the c:import-ed JSP does
not see the var from the c:forEach loop.
[c:forEach var=foo items=${bars}]
[c:import url=some/page.jsp/]
[/c:forEach]
In this page.jsp I try to access ${foo}, like so:
[c:out value=${foo}/]
No go. ${foo} seems undefined there :( page.jsp does not see
it. Scope issue?
Yup. As Hans said, you need to promote 'foo' to request scope.
I then tried adding the following inside that c:forEach:
[c:set var=newFoo value=${foo} scope=request/]
However, that c:import-ed page.jsp does not see ${newFoo}
either. :(
Hmm. This works fine for me...
--
Martin Cooper
I am using jakarta-taglibs 1.0.3 with JBoss/Jetty.
Is the above supposed to work?
How do I get the import-ed page.jsp to see a variable defined in
the page that imported it?
Thanks,
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: c:forEach, c:import and variable scope?
Hello,
Aaaalmost there :)
On Tue, 09 Dec 2003, Hans Bergsten
([EMAIL PROTECTED]) wrote:
Ben Anderson wrote:
How bout this:
c:forEach var=foo items=${bars}
c:import url=some/page.jsp
c:param name=foop value=${foo}/
/c:import
/c:forEach
some/page.jsp
c:out value=${param.foop}/
-Ben
That should also work, but so should promoting it to request
scope.
If it doesn't, there's a bug somewhere, maybe in the
c:import
implementation (I don't think so) or in Jetty's PageContext
or
RequestDispatcher include() methods implementation.
The c:param option _almost_ works.
In some/page.jsp I can:
[c:out value=${param.foop}/]
This prints out '3'.
However, when I use param.foop as the index for a Map, nothing
gets printed (in some/page.jsp):
[c:forEach var=x items=${myMap[param.foop]}]
[c:out value=${x}/]
[/c:forEach]
HOWEVER, if I hard-code the value of '3' on the c:forEach, then
things DO get printed:
[c:forEach var=x items=${myMap[3]}]
[c:out value=${x}/]
[/c:forEach]
Does this make any sense?
param.foop obviously has a value of '3' even in some/page.jsp,
but when I used it as a Map index, things fail to work.
Thanks again,
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:forEach, c:import and variable scope?
Could it be related to your map being keyed by Integers instead of
Strings? I know that JSTL/EL does a lot of magical conversions, but I'm
not sure how far they extend.
K.C.
otisg wrote:
Hello,
Aaaalmost there :)
On Tue, 09 Dec 2003, Hans Bergsten
([EMAIL PROTECTED]) wrote:
Ben Anderson wrote:
How bout this:
c:forEach var=foo items=${bars}
c:import url=some/page.jsp
c:param name=foop value=${foo}/
/c:import
/c:forEach
some/page.jsp
c:out value=${param.foop}/
-Ben
That should also work, but so should promoting it to request
scope.
If it doesn't, there's a bug somewhere, maybe in the
c:import
implementation (I don't think so) or in Jetty's PageContext
or
RequestDispatcher include() methods implementation.
The c:param option _almost_ works.
In some/page.jsp I can:
[c:out value=${param.foop}/]
This prints out '3'.
However, when I use param.foop as the index for a Map, nothing
gets printed (in some/page.jsp):
[c:forEach var=x items=${myMap[param.foop]}]
[c:out value=${x}/]
[/c:forEach]
HOWEVER, if I hard-code the value of '3' on the c:forEach, then
things DO get printed:
[c:forEach var=x items=${myMap[3]}]
[c:out value=${x}/]
[/c:forEach]
Does this make any sense?
param.foop obviously has a value of '3' even in some/page.jsp,
but when I used it as a Map index, things fail to work.
Thanks again,
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: c:forEach, c:import and variable scope?
The Map actually has Long as keys.
I thought JSTL take care of this by detecting these java.lang
types and converting appropriately.
No?
Thanks,
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
On Tue, 09 Dec 2003, K.C. Baltz ([EMAIL PROTECTED])
wrote:
Could it be related to your map being keyed by Integers
instead of
Strings? I know that JSTL/EL does a lot of magical
conversions, but I'm
not sure how far they extend.
K.C.
otisg wrote:
Hello,
Aaaalmost there :)
On Tue, 09 Dec 2003, Hans Bergsten
([EMAIL PROTECTED]) wrote:
Ben Anderson wrote:
How bout this:
c:forEach var=foo items=${bars}
c:import url=some/page.jsp
c:param name=foop value=${foo}/
/c:import
/c:forEach
some/page.jsp
c:out value=${param.foop}/
-Ben
That should also work, but so should promoting it to
request
scope.
If it doesn't, there's a bug somewhere, maybe in the
c:import
implementation (I don't think so) or in Jetty's PageContext
or
RequestDispatcher include() methods implementation.
The c:param option _almost_ works.
In some/page.jsp I can:
[c:out value=${param.foop}/]
This prints out '3'.
However, when I use param.foop as the index for a Map,
nothing
gets printed (in some/page.jsp):
[c:forEach var=x items=${myMap[param.foop]}]
[c:out value=${x}/]
[/c:forEach]
HOWEVER, if I hard-code the value of '3' on the c:forEach,
then
things DO get printed:
[c:forEach var=x items=${myMap[3]}]
[c:out value=${x}/]
[/c:forEach]
Does this make any sense?
param.foop obviously has a value of '3' even in
some/page.jsp,
but when I used it as a Map index, things fail to work.
Thanks again,
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
c:import and Struts actions physically losing bytes
Hello all, Yet again another problem: i want to include another dynamic resource via JSTL's c:import into a JSP. When doing so with another JSP everything works great. However, when doing so with a Struts action, the request gets shortened (First x bytes are cut)! The Struts action really does nothing more than that in my testcase: just setting a forward to the same JSP page to include. The page to include is kept simple to avoid intereference of any other called code, it just contains a page directive and Hello. Thus, c:import url=/WEB-INF/jsp/test.jsp / works, but c:import url=/simple.do / Simply cuts the first bytes of the request, thus i receive an incomplete document. As said, the Struts action really just sets a forward to the same JSP as in the first example. The document's beginning gets cut somewhere, not only the importing JSP gets cut but the cut also reaches to the called JSP. Am i doing wrong??? My setup: - J2SDK 1.4.1_02 on Debian GNU/Linux sid - Tomcat 5.0.14 - up to date JSTL 1.1 - up to date Struts web.xml links against JSP 2.0 / Servlet 2.4. BTW: When using jsp:include, the whole calling JSP is replaced w/ the called document. However, jsp:include is not an option die to c:import tech advantages. *But*, important may be this two-liner that Jasper throws to STDOUT: Nov 5, 2003 10:26:22 PM org.apache.jasper.runtime.PageContextImpl release WARNING: Internal error flushing the buffer in release() ? Bug due to Tomcat beta... or? Thanx -- greetings, | /\ | \ / ASCII-Ribbon-Campaign Timo | X Against HTML Mail | / \ -- PUBLIC KEY: 52F3311A Timo Boewing [EMAIL PROTECTED] 2003/10/30 Fingerprint = F743 E0AA A2F0 1B33 F6FA 417B 72BE 740D 52F3 311A signature.asc Description: This is a digitally signed message part
Re: How to use c:url with c:import?
K.C. Baltz wrote: 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: I'm pretty sure the problem is snip/ Uh, problem? the above works fine plugged into a page on my system. Does import work if you specify `url=/text.html` explicitly? -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use c:url with c:import?
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.
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use c:url with c:import?
I've left out a bit of detail in the hopes of making this simpler :).
I'm not actually using c:url, but rather a custom tag that extends the
Struts html:rewrite tag. My custom tag modifies the passed in URL, so
I can't skip that step. I could probably modify my custom tag to not
prepend the /context, but it seems like this is something that should
work. In the jstl-1.0 spec, it says the following:
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]
Re: How to use c:url with c:import?
Tried that. It just looks for my files in the ROOT context, rather than the context specified in the URL. I also tried context=, but that produced an exception. K.C. Hassan Schroeder wrote: Hassan Schroeder jumped the gun with: Uh, problem? the above works fine plugged into a page on my system. Sorry, missed the context relative part before :-) !-- Stores /myContext/text.html in the variable textURL -- c:url value=/text.html context=/ var=textURL / ^^^ Add that and give it a whirl... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with c:import (JSTL 1.0)
Thank you. Guess sometimes it just takes a second set of eyes to see the
obvious...
On Thu, 23 Oct 2003, Karr, David wrote:
Looks like you're missing a at the end of the c:if.
-Original Message-
From: Stephen Letschin [mailto:[EMAIL PROTECTED]
I am having a problem with a c:import that I hope someone has an answer
to.
lines deleted
%@ taglib uri=http://java.sun.com/jstl/core; prefix=c % %@ taglib
uri=http://java.sun.com/jstl/fmt; prefix=fmt %
fmt:setLocale value=en-US /
fmt:setBundle basename=resources.application / fmt:parseDate
var=lastModDate
value=10/23/2003
pattern=MM/dd/
scope=request /
c:if test=${empty lastModifiedDate || lastModDate lastModifiedDate}
c:set var=lastModifiedDate value=${lastModDate} scope=request
/ /c:if
Thanks.
Stephen Letschin
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Stephen Letschin Life is hard -- Bring your brain.
[EMAIL PROTECTED] -- Jim Peak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with c:import (JSTL 1.0)
Looks like you're missing a at the end of the c:if.
-Original Message-
From: Stephen Letschin [mailto:[EMAIL PROTECTED]
I am having a problem with a c:import that I hope someone has an answer
to.
lines deleted
%@ taglib uri=http://java.sun.com/jstl/core; prefix=c % %@ taglib
uri=http://java.sun.com/jstl/fmt; prefix=fmt %
fmt:setLocale value=en-US /
fmt:setBundle basename=resources.application / fmt:parseDate
var=lastModDate
value=10/23/2003
pattern=MM/dd/
scope=request /
c:if test=${empty lastModifiedDate || lastModDate lastModifiedDate}
c:set var=lastModifiedDate value=${lastModDate} scope=request
/ /c:if
Thanks.
Stephen Letschin
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import: relative links inside WEB-INF don't work
Right, James, that is why I said something LIKE struts. Micael At 12:08 PM 10/10/2003 -0400, you wrote: No you don't. That has nothing to do with Struts. You just need to understand how includes and imports work. http://java.sun.com/products/jsp/syntax/1.1/syntaxref1112.html http://java.sun.com/products/jsp/syntax/1.1/syntaxref117.html#8772 http://java.sun.com/webservices/docs/1.0/tutorial/doc/JSTL5.html#64122 -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Micael [EMAIL PROTECTED] To: Tag Libraries Users List [EMAIL PROTECTED]; Tag Libraries Users List [EMAIL PROTECTED] Sent: Friday, October 10, 2003 12:01 PM Subject: Re: c:import: relative links inside WEB-INF don't work You need to use something like struts to operate inside WEB-INF. At 05:34 PM 10/7/2003 -0400, Manolo Ramirez T. wrote: Hi, I have this problem with Tomcat 4.1.24 and taglibs-standard 1.0.3. When I try lo include a jsp inside WEB-INF I must to use an absolute url, this are my files: ### # /WEB-INF/jsp/prueba.jsp # ### %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=prueba2.jsp/ %-- doesn't work! --% # /WEB-INF/jsp/prueba1.jsp # %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=/WEB-INF/jsp/prueba2.jsp/ %-- works fine --% # /WEB-INF/jsp/prueba2.jsp # HELLO WORLD! #/END jsp:include works well with relative url's, What I'm missing? Is there any way to use c:import to do this?. Help please. Thanks in advance. Manolo Ramirez T. PD: forgive my english! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import: relative links inside WEB-INF don't work
Jim, the question is not how you can include a jsp but go to a jsp. Those are radically different issues when inside WEB-INF. At 12:08 PM 10/10/2003 -0400, you wrote: No you don't. That has nothing to do with Struts. You just need to understand how includes and imports work. http://java.sun.com/products/jsp/syntax/1.1/syntaxref1112.html http://java.sun.com/products/jsp/syntax/1.1/syntaxref117.html#8772 http://java.sun.com/webservices/docs/1.0/tutorial/doc/JSTL5.html#64122 -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Micael [EMAIL PROTECTED] To: Tag Libraries Users List [EMAIL PROTECTED]; Tag Libraries Users List [EMAIL PROTECTED] Sent: Friday, October 10, 2003 12:01 PM Subject: Re: c:import: relative links inside WEB-INF don't work You need to use something like struts to operate inside WEB-INF. At 05:34 PM 10/7/2003 -0400, Manolo Ramirez T. wrote: Hi, I have this problem with Tomcat 4.1.24 and taglibs-standard 1.0.3. When I try lo include a jsp inside WEB-INF I must to use an absolute url, this are my files: ### # /WEB-INF/jsp/prueba.jsp # ### %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=prueba2.jsp/ %-- doesn't work! --% # /WEB-INF/jsp/prueba1.jsp # %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=/WEB-INF/jsp/prueba2.jsp/ %-- works fine --% # /WEB-INF/jsp/prueba2.jsp # HELLO WORLD! #/END jsp:include works well with relative url's, What I'm missing? Is there any way to use c:import to do this?. Help please. Thanks in advance. Manolo Ramirez T. PD: forgive my english! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import: relative links inside WEB-INF don't work
As an aside, you certainly can, and I think should, execute JSPs within WEB-INF. I even execute my resources within WEB-INF. At 04:55 PM 10/7/2003 -0400, Serge Knystautas wrote: You shouldn't be able to execute JSPs within your WEB-INF, so all 3 of your examples should be forbidden. I think you might want to submit a bug report to whatever servlet engine you're using. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] Manolo Ramirez T. wrote: Hi, I have this problem with Tomcat 4.1.24 and taglibs-standard 1.0.3. When I try lo include a jsp inside WEB-INF I must to use an absolute url, this are my files: ### # /WEB-INF/jsp/prueba.jsp # ### %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=prueba2.jsp/ %-- doesn't work! --% # /WEB-INF/jsp/prueba1.jsp # %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=/WEB-INF/jsp/prueba2.jsp/ %-- works fine --% # /WEB-INF/jsp/prueba2.jsp # HELLO WORLD! #/END jsp:include works well with relative url's, What I'm missing? Is there any way to use c:import to do this?. Help please. Thanks in advance. Manolo Ramirez T. PD: forgive my english! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import: relative links inside WEB-INF don't work
You need to use something like struts to operate inside WEB-INF. At 05:34 PM 10/7/2003 -0400, Manolo Ramirez T. wrote: Hi, I have this problem with Tomcat 4.1.24 and taglibs-standard 1.0.3. When I try lo include a jsp inside WEB-INF I must to use an absolute url, this are my files: ### # /WEB-INF/jsp/prueba.jsp # ### %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=prueba2.jsp/ %-- doesn't work! --% # /WEB-INF/jsp/prueba1.jsp # %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=/WEB-INF/jsp/prueba2.jsp/ %-- works fine --% # /WEB-INF/jsp/prueba2.jsp # HELLO WORLD! #/END jsp:include works well with relative url's, What I'm missing? Is there any way to use c:import to do this?. Help please. Thanks in advance. Manolo Ramirez T. PD: forgive my english! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
c:import: relative links inside WEB-INF don't work
Hi, I have this problem with Tomcat 4.1.24 and taglibs-standard 1.0.3. When I try lo include a jsp inside WEB-INF I must to use an absolute url, this are my files: ### # /WEB-INF/jsp/prueba.jsp # ### %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=prueba2.jsp/ %-- doesn't work! --% # /WEB-INF/jsp/prueba1.jsp # %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=/WEB-INF/jsp/prueba2.jsp/ %-- works fine --% # /WEB-INF/jsp/prueba2.jsp # HELLO WORLD! #/END jsp:include works well with relative url's, What I'm missing? Is there any way to use c:import to do this?. Help please. Thanks in advance. Manolo Ramirez T. PD: forgive my english! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import: relative links inside WEB-INF don't work
You shouldn't be able to execute JSPs within your WEB-INF, so all 3 of your examples should be forbidden. I think you might want to submit a bug report to whatever servlet engine you're using. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] Manolo Ramirez T. wrote: Hi, I have this problem with Tomcat 4.1.24 and taglibs-standard 1.0.3. When I try lo include a jsp inside WEB-INF I must to use an absolute url, this are my files: ### # /WEB-INF/jsp/prueba.jsp # ### %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=prueba2.jsp/ %-- doesn't work! --% # /WEB-INF/jsp/prueba1.jsp # %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=/WEB-INF/jsp/prueba2.jsp/ %-- works fine --% # /WEB-INF/jsp/prueba2.jsp # HELLO WORLD! #/END jsp:include works well with relative url's, What I'm missing? Is there any way to use c:import to do this?. Help please. Thanks in advance. Manolo Ramirez T. PD: forgive my english! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import: relative links inside WEB-INF don't work
Hi, I'm using jsp's outside WEB-INF to include prueba and prueba1, I forget to say that. _ Manolo Ramirez T. Serge Knystautas wrote: You shouldn't be able to execute JSPs within your WEB-INF, so all 3 of your examples should be forbidden. I think you might want to submit a bug report to whatever servlet engine you're using. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import: relative links inside WEB-INF don't work
Manolo Ramirez T. wrote: Hi, I'm using jsp's outside WEB-INF to include prueba and prueba1, I forget to say that. In that case, you'd want the following: %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=WEB-INF/prueba2.jsp/ -- Pierre _ Manolo Ramirez T. Serge Knystautas wrote: You shouldn't be able to execute JSPs within your WEB-INF, so all 3 of your examples should be forbidden. I think you might want to submit a bug report to whatever servlet engine you're using. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Speed differences between jsp:include and c:import
Does anyone know if there are any speed differences between using jsp:include and c:import if one is including a file that is local to the web server? Obviously if one does c:import and imports a file from a remote web server that will be slower than including something on the local server. Sorry if this is a common question, but I searched google, here and struts-user and could not find an answer. Thanks! Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Speed differences between jsp:include and c:import
Sgarlata Matt wrote: Does anyone know if there are any speed differences between using jsp:include and c:import if one is including a file that is local to the web server? Obviously if one does c:import and imports a file from a remote web server that will be slower than including something on the local server. Sorry if this is a common question, but I searched google, here and struts-user and could not find an answer. Since c:import does what a jsp:include does if it a local resource, the difference should be minimal. It is open source though, so I'd check out the code and see what is any extra processing is done. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Speed differences between jsp:include and c:import
Just out of curiousity. Unless the code is doing something short of ridiculous.. How much of a speed difference could there really be? I mean what exactly are u looking for? Would a difference of 100 milli effect the outcome of ur app? 1 sec even? What is the you main concern? -Tim -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 9:35 AM To: Tag Libraries Users List Subject: Re: Speed differences between jsp:include and c:import Sgarlata Matt wrote: Does anyone know if there are any speed differences between using jsp:include and c:import if one is including a file that is local to the web server? Obviously if one does c:import and imports a file from a remote web server that will be slower than including something on the local server. Sorry if this is a common question, but I searched google, here and struts-user and could not find an answer. Since c:import does what a jsp:include does if it a local resource, the difference should be minimal. It is open source though, so I'd check out the code and see what is any extra processing is done. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Speed differences between jsp:include and c:import
Well we have three different include methods (4 if you count tiles:insert) and I'm just trying to fully understand the implications of using each. %@ include file= % is like a C include, so it leads to larger JSP files, but it offers a speed advantage over passing along the request, which is what jsp:include does. I was thinking that a naive implementation of c:import might just construct the URL and go fetch from the Internet every time, even if the URL was on the local machine. This would mean getting the content through the local web server rather than the local file system. This is a toy example, but I'm thinking that since jsp:include has been around longer that it might have been tuned better than c:import and thus could be depended on to be faster than c:import for nearly all containers. Does that make sense? Also, since you can store c:import in a variable I'm wondering if c:import might do some type of full read before printing to output, whereas I imagine jsp:include uses buffering. This could show a performance difference for very large files, with c:import requiring longer and taking more memory to get all the data in the import whereas jsp:include did things with buffers. Am I thinking about this too much? I really don't know how all this stuff is implemented ;) Matt - Original Message - From: Chen, Gin [EMAIL PROTECTED] To: 'Tag Libraries Users List' [EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 10:42 AM Subject: RE: Speed differences between jsp:include and c:import Just out of curiousity. Unless the code is doing something short of ridiculous.. How much of a speed difference could there really be? I mean what exactly are u looking for? Would a difference of 100 milli effect the outcome of ur app? 1 sec even? What is the you main concern? -Tim -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 9:35 AM To: Tag Libraries Users List Subject: Re: Speed differences between jsp:include and c:import Sgarlata Matt wrote: Does anyone know if there are any speed differences between using jsp:include and c:import if one is including a file that is local to the web server? Obviously if one does c:import and imports a file from a remote web server that will be slower than including something on the local server. Sorry if this is a common question, but I searched google, here and struts-user and could not find an answer. Since c:import does what a jsp:include does if it a local resource, the difference should be minimal. It is open source though, so I'd check out the code and see what is any extra processing is done. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Speed differences between jsp:include and c:import
Ah I c.. The code that ur interested in: org.apache.taglibs.standard.tag.common.core.ImportSupport org.apache.taglibs.standard.tag.common.el.ImportTag If you look at the code for ImportSupport you'll see Shawn's comments: //* // Actual URL importation logic /* * Overall strategy: we have two entry points, acquireString() and * acquireReader(). The latter passes data through unbuffered if * possible (but note that it is not always possible -- specifically * for cases where we must use the RequestDispatcher. The remaining * methods handle the common.core logic of loading either a URL or a local * resource. * * We consider the 'natural' form of absolute URLs to be Readers and * relative URLs to be Strings. Thus, to avoid doing extra work, * acquireString() and acquireReader() delegate to one another as * appropriate. (Perhaps I could have spelled things out more clearly, * but I thought this implementation was instructive, not to mention * somewhat cute...) */ You can follow the aquireXXX methods to see the implementation. -Tim -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 10:56 AM To: Tag Libraries Users List Subject: Re: Speed differences between jsp:include and c:import Well we have three different include methods (4 if you count tiles:insert) and I'm just trying to fully understand the implications of using each. %@ include file= % is like a C include, so it leads to larger JSP files, but it offers a speed advantage over passing along the request, which is what jsp:include does. I was thinking that a naive implementation of c:import might just construct the URL and go fetch from the Internet every time, even if the URL was on the local machine. This would mean getting the content through the local web server rather than the local file system. This is a toy example, but I'm thinking that since jsp:include has been around longer that it might have been tuned better than c:import and thus could be depended on to be faster than c:import for nearly all containers. Does that make sense? Also, since you can store c:import in a variable I'm wondering if c:import might do some type of full read before printing to output, whereas I imagine jsp:include uses buffering. This could show a performance difference for very large files, with c:import requiring longer and taking more memory to get all the data in the import whereas jsp:include did things with buffers. Am I thinking about this too much? I really don't know how all this stuff is implemented ;) Matt - Original Message - From: Chen, Gin [EMAIL PROTECTED] To: 'Tag Libraries Users List' [EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 10:42 AM Subject: RE: Speed differences between jsp:include and c:import Just out of curiousity. Unless the code is doing something short of ridiculous.. How much of a speed difference could there really be? I mean what exactly are u looking for? Would a difference of 100 milli effect the outcome of ur app? 1 sec even? What is the you main concern? -Tim -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 9:35 AM To: Tag Libraries Users List Subject: Re: Speed differences between jsp:include and c:import Sgarlata Matt wrote: Does anyone know if there are any speed differences between using jsp:include and c:import if one is including a file that is local to the web server? Obviously if one does c:import and imports a file from a remote web server that will be slower than including something on the local server. Sorry if this is a common question, but I searched google, here and struts-user and could not find an answer. Since c:import does what a jsp:include does if it a local resource, the difference should be minimal. It is open source though, so I'd check out the code and see what is any extra processing is done. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
c:import
I've looked through the archives and the suggested alternative for a dynamic
jsp:include reference is using the c:import url=${xyz}/. This is not
working in my JSP. The tag is including nothing in my page. I've even tried
to give it a static reference to the jsp c:import url=xyzPage.jsp/ and
still nothing. Does anyone know what's wrong?
- Billy -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import
Make sure that you are clear on the differences between c:import
jsp:include and @include they are all different and in my case the fact
that the imported page has no knowledge of my context hosed me.
R
Billy Bacon wrote:
I've looked through the archives and the suggested alternative for a dynamic
jsp:include reference is using the c:import url=${xyz}/. This is not
working in my JSP. The tag is including nothing in my page. I've even tried
to give it a static reference to the jsp c:import url=xyzPage.jsp/ and
still nothing. Does anyone know what's wrong?
- Billy -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import
Yes, I am importing the core library, I have plenty of other c: tags
within my jsp and they work perfectly that's why it confuses me that's it
not working. Seems like a pretty simple tag to use.
Before trying to convert this to JSTL I had bean:define tag (from Struts)
and a jsp:include page=%= xyz %/ tag and things worked fine.
But now I get nothing...
On 9/17/03 10:38 AM, Rick Ross [EMAIL PROTECTED] wrote:
Make sure that you are clear on the differences between c:import
jsp:include and @include they are all different and in my case the fact
that the imported page has no knowledge of my context hosed me.
R
Billy Bacon wrote:
I've looked through the archives and the suggested alternative for a dynamic
jsp:include reference is using the c:import url=${xyz}/. This is not
working in my JSP. The tag is including nothing in my page. I've even tried
to give it a static reference to the jsp c:import url=xyzPage.jsp/ and
still nothing. Does anyone know what's wrong?
- Billy -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import
I tried catching any exceptions and nothing was printed to the screen :-/
On 9/17/03 10:41 AM, Rick Ross [EMAIL PROTECTED] wrote:
Also, you might wanna do this to see if an error occurred:
c:catch var=ex
c:import url=${viewPage}/
/c:catch
c:if test=${not empty ex}
c:out value=${ex} /
/c:if
Billy Bacon wrote:
I've looked through the archives and the suggested alternative for a dynamic
jsp:include reference is using the c:import url=${xyz}/. This is not
working in my JSP. The tag is including nothing in my page. I've even tried
to give it a static reference to the jsp c:import url=xyzPage.jsp/ and
still nothing. Does anyone know what's wrong?
- Billy -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import
Is xyz only a scripting variable or is it also a scoped variable?
Quoting Billy Bacon [EMAIL PROTECTED]:
Yes, I am importing the core library, I have plenty of other c: tags
within my jsp and they work perfectly that's why it confuses me that's it
not working. Seems like a pretty simple tag to use.
Before trying to convert this to JSTL I had bean:define tag (from Struts)
and a jsp:include page=%= xyz %/ tag and things worked fine.
But now I get nothing...
On 9/17/03 10:38 AM, Rick Ross [EMAIL PROTECTED] wrote:
Make sure that you are clear on the differences between c:import
jsp:include and @include they are all different and in my case the fact
that the imported page has no knowledge of my context hosed me.
R
Billy Bacon wrote:
I've looked through the archives and the suggested alternative for a
dynamic
jsp:include reference is using the c:import url=${xyz}/. This is
not
working in my JSP. The tag is including nothing in my page. I've even
tried
to give it a static reference to the jsp c:import url=xyzPage.jsp/
and
still nothing. Does anyone know what's wrong?
- Billy -
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import
It's a scoped variable. But I think the problem is elsewhere because even
this doesn't work for me and no exception is thrown...
c:import url=myJspPage.jsp /
Any ideas?
On 9/17/03 11:34 AM, Kris Schneider [EMAIL PROTECTED] wrote:
Is xyz only a scripting variable or is it also a scoped variable?
Quoting Billy Bacon [EMAIL PROTECTED]:
Yes, I am importing the core library, I have plenty of other c: tags
within my jsp and they work perfectly that's why it confuses me that's it
not working. Seems like a pretty simple tag to use.
Before trying to convert this to JSTL I had bean:define tag (from Struts)
and a jsp:include page=%= xyz %/ tag and things worked fine.
But now I get nothing...
On 9/17/03 10:38 AM, Rick Ross [EMAIL PROTECTED] wrote:
Make sure that you are clear on the differences between c:import
jsp:include and @include they are all different and in my case the fact
that the imported page has no knowledge of my context hosed me.
R
Billy Bacon wrote:
I've looked through the archives and the suggested alternative for a
dynamic
jsp:include reference is using the c:import url=${xyz}/. This is
not
working in my JSP. The tag is including nothing in my page. I've even
tried
to give it a static reference to the jsp c:import url=xyzPage.jsp/
and
still nothing. Does anyone know what's wrong?
- Billy -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import
Have you tried a context-relative path (starts with /) to the page?
Quoting Billy Bacon [EMAIL PROTECTED]:
It's a scoped variable. But I think the problem is elsewhere because even
this doesn't work for me and no exception is thrown...
c:import url=myJspPage.jsp /
Any ideas?
On 9/17/03 11:34 AM, Kris Schneider [EMAIL PROTECTED] wrote:
Is xyz only a scripting variable or is it also a scoped variable?
Quoting Billy Bacon [EMAIL PROTECTED]:
Yes, I am importing the core library, I have plenty of other c: tags
within my jsp and they work perfectly that's why it confuses me that's
it
not working. Seems like a pretty simple tag to use.
Before trying to convert this to JSTL I had bean:define tag (from
Struts)
and a jsp:include page=%= xyz %/ tag and things worked fine.
But now I get nothing...
On 9/17/03 10:38 AM, Rick Ross [EMAIL PROTECTED] wrote:
Make sure that you are clear on the differences between c:import
jsp:include and @include they are all different and in my case the fact
that the imported page has no knowledge of my context hosed me.
R
Billy Bacon wrote:
I've looked through the archives and the suggested alternative for a
dynamic
jsp:include reference is using the c:import url=${xyz}/. This is
not
working in my JSP. The tag is including nothing in my page. I've even
tried
to give it a static reference to the jsp c:import url=xyzPage.jsp/
and
still nothing. Does anyone know what's wrong?
- Billy -
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import
Awesome. That worked!
Thanks Kris!
- Billy -
On 9/17/03 12:05 PM, Kris Schneider [EMAIL PROTECTED] wrote:
Have you tried a context-relative path (starts with /) to the page?
Quoting Billy Bacon [EMAIL PROTECTED]:
It's a scoped variable. But I think the problem is elsewhere because even
this doesn't work for me and no exception is thrown...
c:import url=myJspPage.jsp /
Any ideas?
On 9/17/03 11:34 AM, Kris Schneider [EMAIL PROTECTED] wrote:
Is xyz only a scripting variable or is it also a scoped variable?
Quoting Billy Bacon [EMAIL PROTECTED]:
Yes, I am importing the core library, I have plenty of other c: tags
within my jsp and they work perfectly that's why it confuses me that's
it
not working. Seems like a pretty simple tag to use.
Before trying to convert this to JSTL I had bean:define tag (from
Struts)
and a jsp:include page=%= xyz %/ tag and things worked fine.
But now I get nothing...
On 9/17/03 10:38 AM, Rick Ross [EMAIL PROTECTED] wrote:
Make sure that you are clear on the differences between c:import
jsp:include and @include they are all different and in my case the fact
that the imported page has no knowledge of my context hosed me.
R
Billy Bacon wrote:
I've looked through the archives and the suggested alternative for a
dynamic
jsp:include reference is using the c:import url=${xyz}/. This is
not
working in my JSP. The tag is including nothing in my page. I've even
tried
to give it a static reference to the jsp c:import url=xyzPage.jsp/
and
still nothing. Does anyone know what's wrong?
- Billy -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import
Okay, that's good, but I use page-relative paths successfully with c:import
all the time. Are you sure the page doing the import is in the same directory as
the page being imported?
Quoting Billy Bacon [EMAIL PROTECTED]:
Awesome. That worked!
Thanks Kris!
- Billy -
On 9/17/03 12:05 PM, Kris Schneider [EMAIL PROTECTED] wrote:
Have you tried a context-relative path (starts with /) to the page?
Quoting Billy Bacon [EMAIL PROTECTED]:
It's a scoped variable. But I think the problem is elsewhere because
even
this doesn't work for me and no exception is thrown...
c:import url=myJspPage.jsp /
Any ideas?
On 9/17/03 11:34 AM, Kris Schneider [EMAIL PROTECTED] wrote:
Is xyz only a scripting variable or is it also a scoped variable?
Quoting Billy Bacon [EMAIL PROTECTED]:
Yes, I am importing the core library, I have plenty of other c: tags
within my jsp and they work perfectly that's why it confuses me that's
it
not working. Seems like a pretty simple tag to use.
Before trying to convert this to JSTL I had bean:define tag (from
Struts)
and a jsp:include page=%= xyz %/ tag and things worked fine.
But now I get nothing...
On 9/17/03 10:38 AM, Rick Ross [EMAIL PROTECTED] wrote:
Make sure that you are clear on the differences between c:import
jsp:include and @include they are all different and in my case the
fact
that the imported page has no knowledge of my context hosed me.
R
Billy Bacon wrote:
I've looked through the archives and the suggested alternative for a
dynamic
jsp:include reference is using the c:import url=${xyz}/. This
is
not
working in my JSP. The tag is including nothing in my page. I've
even
tried
to give it a static reference to the jsp c:import
url=xyzPage.jsp/
and
still nothing. Does anyone know what's wrong?
- Billy -
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import
Yep, all my JSPs are in the same directory.
c:import url=xyz.jsp/ // didn't work
c:import url=/jsp/xyz.jsp/ // did the trick.
Dunno...
On 9/17/03 1:14 PM, Kris Schneider [EMAIL PROTECTED] wrote:
Okay, that's good, but I use page-relative paths successfully with c:import
all the time. Are you sure the page doing the import is in the same directory
as
the page being imported?
Quoting Billy Bacon [EMAIL PROTECTED]:
Awesome. That worked!
Thanks Kris!
- Billy -
On 9/17/03 12:05 PM, Kris Schneider [EMAIL PROTECTED] wrote:
Have you tried a context-relative path (starts with /) to the page?
Quoting Billy Bacon [EMAIL PROTECTED]:
It's a scoped variable. But I think the problem is elsewhere because
even
this doesn't work for me and no exception is thrown...
c:import url=myJspPage.jsp /
Any ideas?
On 9/17/03 11:34 AM, Kris Schneider [EMAIL PROTECTED] wrote:
Is xyz only a scripting variable or is it also a scoped variable?
Quoting Billy Bacon [EMAIL PROTECTED]:
Yes, I am importing the core library, I have plenty of other c: tags
within my jsp and they work perfectly that's why it confuses me that's
it
not working. Seems like a pretty simple tag to use.
Before trying to convert this to JSTL I had bean:define tag (from
Struts)
and a jsp:include page=%= xyz %/ tag and things worked fine.
But now I get nothing...
On 9/17/03 10:38 AM, Rick Ross [EMAIL PROTECTED] wrote:
Make sure that you are clear on the differences between c:import
jsp:include and @include they are all different and in my case the
fact
that the imported page has no knowledge of my context hosed me.
R
Billy Bacon wrote:
I've looked through the archives and the suggested alternative for a
dynamic
jsp:include reference is using the c:import url=${xyz}/. This
is
not
working in my JSP. The tag is including nothing in my page. I've
even
tried
to give it a static reference to the jsp c:import
url=xyzPage.jsp/
and
still nothing. Does anyone know what's wrong?
- Billy -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
why doesn't c:redirect work inside a file included with c:import?
List, In the files attached, navigating to http://localhost:8080/app-name/first.jsp will result in the text below: Before redirect I am the first page. Does anyone know a way to make c:redirect from a file included with c:import effective? If not, does anyone know how to use JSTL to access query parameters inside a file included with the % include % directive? Thank you in advance, David Foote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
c:import url to access a servlet
The following code does not seem to work: c:import url=/servlet/TestServlet / The correctly functioning URL if entered directly in the browser is localhost:8988/vls_local-jstl-context-root/servlet/TestServlet Can this tag be used against servlets accessed using /servlet/ and/or Servlet Mappings defined in web.xml? I would like the HTML returned from the doGet() method of the Servlet. This is just an exploration of the API please do not lecture on using Servlets to output HTML :-) -Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
More periodic refresh with JSTL c:import
This is a followup to a recent post to this group.
The snippet below imports a page and stores it into variable x if variable x
is more than 5 five minutes old. This makes the page load fast for the
great majority of hits.
However, if traffic to the site is slow, let's say a steady one hit every 6
minutes, then each surfer experiences a very slow response time as the site
goes through the slow c:import routine to load x before showing the page.
Meanwhile, my webserver is sitting idle for the remaining time between hits.
Is there a tag or other technique one can use to instruct the webserver to
keeps variable x up-to-date (ie, not more than 5 minutes old) in the
background without waiting for a hit before noticing the variable is stale?
Brian
-
c:set var=cachePeriod value=${5 * 60 * 1000} /
jsp:useBean id=n class=java.util.Date /
c:if test=${(n.time - cacheTime) cachePeriod}
c:remove var=x scope=application /
/c:if
c:if test=${empty applicationScope.x}
c:set var=x scope=application
c:import url=channel.jsp
c:param name=rssUrl value=http://www.slowurl.rss; /
/c:import
/c:set
jsp:useBean id=now class=java.util.Date /
c:set var=cacheTime value=${now.time} scope=application /
/c:if
c:out value=${applicationScope.x} escapeXml=false /
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
periodic refresh with JSTL c:import
This snippet prints out up-to-date information but it is slow ...
c:import url=channel.jsp
c:param name=rssUrl value=http://www.slowurl.rss; /
/c:import
This snippet makes it fast but stale...
c:import url=channel.jsp var=x scope=application
c:param name=rssUrl value=http://www.slowurl.rss; /
/c:import
c:out value=${applicationScope.x} escapeXml=false /
How can one use JSTL to do something in between, such as to update the
c:import once an hour?
c:if test=??? test if applicationScope.x is more than an hour old ???
c:import url=channel.jsp var=x scope=application
c:param name=rssUrl value=http://www.slowurl.rss; /
/c:import
/c:if
c:out value=${applicationScope.x} escapeXml=false /
Brian
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: periodic refresh with JSTL c:import
On Wed, 18 Dec 2002, Brian Buckley wrote:
How can one use JSTL to do something in between, such as to update the
c:import once an hour?
c:if test=??? test if applicationScope.x is more than an hour old ???
c:import url=channel.jsp var=x scope=application
c:param name=rssUrl value=http://www.slowurl.rss; /
/c:import
/c:if
c:out value=${applicationScope.x} escapeXml=false /
You could create a Date object and compare the time property of this
object against the current time; Hans has shown how to do this in previous
messages.
It might be easier to use the Cache Taglib, which isn't part of JSTL but
does exactly what you're looking for.
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
periodic refresh with JSTL c:import
Correction -- I meant to include an c:if clause around the fast but stale
way.
c:if test=${empty applicationScope.x}
c:import url=channel.jsp var=x scope=application
c:param name=rssUrl value=http://www.slowurl.rss; /
/c:import
/c:if
c:out value=${applicationScope.x} escapeXml=false /
Thanks.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: periodic refresh with JSTL c:import
You could create a Date object and compare the time property of this object against the current time; Hans has shown how to do this in previous messages. It might be easier to use the Cache Taglib, which isn't part of JSTL but does exactly what you're looking for. Thanks, Shawn. I found the Hans example and it does just what I need. In case you failed to notice :), my snippets were lifted from JSTL In Action. Excellent book. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Howto] use c:import with varReader to import/parse large XMLfile ?
On Mon, 25 Nov 2002, smallufo wrote:
I have a big XML file (about 500Kbytes) ,
while using general
x:parse var=doc
c:import url=/xxx.xml/
/x:parse
x:out select=$doc//xxx/
It costs a lot of time (about 12~14 seconds) to select nodes.
I wonder if varReader can improve the efficiency, I tried but cannot
find how to combine varReader with XML parsing, can somebody give me a
demonstration ?
x:parse accepts a Reader, so you can simply write
c:import url=/xxx.xml var=xml /
x:parse var=doc xml=${xml} /
--
Shawn Bayern
JSTL in Action http://www.manning.com/bayern
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Howto] use c:import with varReader to import/parse large XML file ?
In JSTL in Action page 336, Shawn demonstrated varReader attribute in c:import tag. I have a big XML file (about 500Kbytes) , while using general x:parse var=doc c:import url=/xxx.xml/ /x:parse x:out select=$doc//xxx/ It costs a lot of time (about 12~14 seconds) to select nodes. I wonder if varReader can improve the efficiency, I tried but cannot find how to combine varReader with XML parsing, can somebody give me a demonstration ?
Re: c:import
Craig Longman wrote: i've been trying to figure out what happens to the request object when you import a file, but had no answers from the tomcat list, so i thought i'd try here. when you include a file via c:insert that actually maps to another servlet, it appears that the request object (in tomcat 4.1.10 at least) doesn't reflect any of the actual request being delivered. i'm a little confused as to what i can do now. the specifics are that i have a servlet that i want to call with a url indicating a specific file that i want retrieved. this would be most useful if it could be called directly, or imported into another jsp file. the url would look like: /mapper/file-to-get the file-to-get would be retrieved by the servlet and then it looks up the correct file and processes it. however, when this url is invoked via a c:import url=/mapper/file, all of the information retrievable via the request object refer to the 'wrapping' request, to the jsp page contains the c:import. the parameters passed are available, but don't show up in the query string (because the query string is for the containing jsp page). is this the correct behaviour? i can't find anything definitive in the spec, so i'm not sure if this is a bug (it seems like 4.1.10 has a few) or the expected behaviour. and if it is expected, then is there _any_ of retrieving 'file-to-get' part if the servlet is invoked via an import? The JSTL c:import action behaves like a RequestDispatcher.include() when you import a resource in the same container. This means (as defined by the Servlet spec) that the URI for the request is the URI for the _including_ resource (the JSP page in this case), so the behavior you see is correct. You do have access to the URI info that was used to include the resource through request attributes. This is from the Servlet spec: SRV.8.3.1 Included Request Parameters Except for servlets obtained by using the getNamedDispatcher method, a servlet being used from within an include has access to the path by which it was invoked. The following request attributes are set: javax.servlet.include.request_uri javax.servlet.include.context_path javax.servlet.include.servlet_path javax.servlet.include.path_info javax.servlet.include.query_string These attributes are accessible from the included servlet via the getAttribute method on the request object. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pageshttp://TheJSPBook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: c:import
On Tue, 2002-09-17 at 20:52, Shawn Bayern wrote:
On 17 Sep 2002, Craig Longman wrote:
when you include a file via c:insert that actually maps to another
servlet, it appears that the request object (in tomcat 4.1.10 at
least) doesn't reflect any of the actual request being delivered.
i'm a little confused as to what i can do now.
Unless I'm misunderstanding your question, this sounds like the right
behavior. The relevant specification is actually the Servlet
specification (section SRV.8.2), though see JSTL 1.0 section 7.4 for the
specification of c:import.
hm. i only had the jstl and jsp specs. thanks, i'll try and find the
servlet spec.
however, when this url is invoked via a c:import url=/mapper/file,
all of the information retrievable via the request object refer to the
'wrapping' request, to the jsp page contains the c:import. the
parameters passed are available, but don't show up in the query string
(because the query string is for the containing jsp page).
I don't see any query string in the example; did you mean to write
/mapper?file-to-get? I'm not sure, from your description, what is being
lost.
If you need to pass parameters directly, you can use the c:param tag as
a subtag of c:import. Otherwise, I think I'd need a little more
information to help.
the parameters i refer to are, in fact, passed via c:param. so, the
relevant jsp file portion looks like:
c:import url=/mapper/testfile
c:param name=name1 value=${lookup1}/
/c:import
in the mapper servlet, i can do a request.getParameter( name1 ) and
get whatever value lookup1 contained. but if i do a
request.getQueryString(), it returns blank. also, i have no way of
extracting the 'testfile' information, it is simply lost; a call to
request.getRequestURI(), .getRequestURL() and .getServletPath() will
return references to the calling page (debug.jsp in this case). i guess
i could just turn the filename into a parameter also.
it just a bit disconcerting, i'm going to have to be very careful about
calling existing servlets as they will quite possibly break as well as
handling (possibly special handling) of cases where a servlet is called
either directly or imported. this might not be the case with a
cross-context servlet, and probably not the case with an absolute url,
i'll have to test. but then there is extra overhead in using those
types of connections also.
thanks.
--
CraigL-Thx();
Be Developer ID: 5852
signature.asc
Description: This is a digitally signed message part
Re: What sucks about c:import!
I'm assuming you want to get at things like cookies, user-agent and other http header data. you may want to make a request to the expert group, so that it is included in the next version of JSTL. I believe the current importsupport class just uses standard url httpurlconnection classes. shawn will know more about the current implementation and where it might go in the future. peter Mark R. Diggory wrote: Now that I have your attention. We are continually working with managing headers in our URL object requests to get resources from different locations. Is there really any way I can set the request Header info on the URL object being created by c:import? Right now I have my own custom implementations to aquire such resources. I'd rather be able to use the Standard Taglib. -Mark Diggory Harvard-MIT Data Center -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
Indeed - JSTL 1.0 does not support advanced HTTP operations from within JSP pages using c:import (e.g., basic authentication, free modification of headers), but a future version of JSTL could if there were enough perceived need. As Peter says, it's a good idea to inform the expert group if you'd like to see this feature; the address is [EMAIL PROTECTED] -- Shawn Bayern JSTL in Action http://www.jstlbook.com On Wed, 21 Aug 2002, peter lin wrote: I'm assuming you want to get at things like cookies, user-agent and other http header data. you may want to make a request to the expert group, so that it is included in the next version of JSTL. I believe the current importsupport class just uses standard url httpurlconnection classes. shawn will know more about the current implementation and where it might go in the future. peter Mark R. Diggory wrote: Now that I have your attention. We are continually working with managing headers in our URL object requests to get resources from different locations. Is there really any way I can set the request Header info on the URL object being created by c:import? Right now I have my own custom implementations to aquire such resources. I'd rather be able to use the Standard Taglib. -Mark Diggory Harvard-MIT Data Center -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
Isn't this the kind of thing that Jakarta Commons HttpClient specialises in? In which case a taglib for that would be a pretty nice affair... [I assume there's not one already..] Hen On Wed, 21 Aug 2002, Shawn Bayern wrote: Indeed - JSTL 1.0 does not support advanced HTTP operations from within JSP pages using c:import (e.g., basic authentication, free modification of headers), but a future version of JSTL could if there were enough perceived need. As Peter says, it's a good idea to inform the expert group if you'd like to see this feature; the address is [EMAIL PROTECTED] -- Shawn Bayern JSTL in Action http://www.jstlbook.com On Wed, 21 Aug 2002, peter lin wrote: I'm assuming you want to get at things like cookies, user-agent and other http header data. you may want to make a request to the expert group, so that it is included in the next version of JSTL. I believe the current importsupport class just uses standard url httpurlconnection classes. shawn will know more about the current implementation and where it might go in the future. peter Mark R. Diggory wrote: Now that I have your attention. We are continually working with managing headers in our URL object requests to get resources from different locations. Is there really any way I can set the request Header info on the URL object being created by c:import? Right now I have my own custom implementations to aquire such resources. I'd rather be able to use the Standard Taglib. -Mark Diggory Harvard-MIT Data Center -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
Well, the Jakarta Taglibs IO Taglib is a pretty good offering. I think Mark was just hoping for a standard solution. -- Shawn Bayern JSTL in Action http://www.jstlbook.com On Wed, 21 Aug 2002, Henri Yandell wrote: Isn't this the kind of thing that Jakarta Commons HttpClient specialises in? In which case a taglib for that would be a pretty nice affair... [I assume there's not one already..] Hen On Wed, 21 Aug 2002, Shawn Bayern wrote: Indeed - JSTL 1.0 does not support advanced HTTP operations from within JSP pages using c:import (e.g., basic authentication, free modification of headers), but a future version of JSTL could if there were enough perceived need. As Peter says, it's a good idea to inform the expert group if you'd like to see this feature; the address is [EMAIL PROTECTED] -- Shawn Bayern JSTL in Action http://www.jstlbook.com On Wed, 21 Aug 2002, peter lin wrote: I'm assuming you want to get at things like cookies, user-agent and other http header data. you may want to make a request to the expert group, so that it is included in the next version of JSTL. I believe the current importsupport class just uses standard url httpurlconnection classes. shawn will know more about the current implementation and where it might go in the future. peter Mark R. Diggory wrote: Now that I have your attention. We are continually working with managing headers in our URL object requests to get resources from different locations. Is there really any way I can set the request Header info on the URL object being created by c:import? Right now I have my own custom implementations to aquire such resources. I'd rather be able to use the Standard Taglib. -Mark Diggory Harvard-MIT Data Center -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
Thank you, I will post my comments there as well.
On another note, I've been playing around with Taglibraries for some
time now. I'd like to integrate the EL Engine into my libraries, from
what I understand it is now going to be part of the JSP 2.0 spec as
well. How might I go about integrating it into my Taglibraries? I've
seen examples like the following, is this really all I need to do?
import org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager;
public int doStartTag() throws JspException {
reader = getReaderFromFile((String)eval(file, file,
String.class));
exposeVariable(reader);
return EVAL_BODY_INCLUDE;
}
//*
// Utility methods
/**
* Evaluate elexprvalue
*/
private Object eval(String attName, String attValue, Class clazz)
throws JspException {
Object obj = ExpressionEvaluatorManager.evaluate(
attName, attValue, clazz, this, pageContext);
if (obj == null) {
throw new NullAttributeException(file, attName);
} else {
return obj;
}
}
private void exposeVariable(Reader reader) {
if (id != null) {
pageContext.setAttribute(id, reader);
}
}
thanks,
Mark Diggory
Indeed - JSTL 1.0 does not support advanced HTTP operations from within
JSP pages using c:import (e.g., basic authentication, free modification
of headers), but a future version of JSTL could if there were enough
perceived need. As Peter says, it's a good idea to inform the expert
group if you'd like to see this feature; the address is
[EMAIL PROTECTED]
-- Shawn Bayern JSTL in Action http://www.jstlbook.com On Wed, 21
Aug 2002, peter lin wrote:
I'm assuming you want to get at things like cookies, user-agent and
other http header data.
you may want to make a request to the expert group, so that it is
included in the next version of JSTL. I believe the current
importsupport class just uses standard url httpurlconnection classes.
shawn will know more about the current implementation and where it might
go in the future.
peter
Mark R. Diggory wrote:
Now that I have your attention. We are continually working with managing
headers in our URL object requests to get resources from different
locations. Is there really any way I can set the request Header info on
the URL object being created by c:import? Right now I have my own custom
implementations to aquire such resources. I'd rather be able to use the
Standard Taglib.
-Mark Diggory
Harvard-MIT Data Center
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
in the interest of discussion. I find it useful to have cookie, user-agent and other advanced capabilities in a web services context. As web services becomes more common place, supporting those features might become very important. peter lin Henri Yandell wrote: Isn't this the kind of thing that Jakarta Commons HttpClient specialises in? In which case a taglib for that would be a pretty nice affair... [I assume there's not one already..] Hen On Wed, 21 Aug 2002, Shawn Bayern wrote: Indeed - JSTL 1.0 does not support advanced HTTP operations from within JSP pages using c:import (e.g., basic authentication, free modification of headers), but a future version of JSTL could if there were enough perceived need. As Peter says, it's a good idea to inform the expert group if you'd like to see this feature; the address is [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
On Wed, 21 Aug 2002, Mark R. Diggory wrote: On another note, I've been playing around with Taglibraries for some time now. I'd like to integrate the EL Engine into my libraries, from what I understand it is now going to be part of the JSP 2.0 spec as well. How might I go about integrating it into my Taglibraries? JSP 2.0 makes the interface standard; with JSP 1.2 and JSTL 1.0, you need to use the custom interface supported by whichever implementation you choose (e.g., the Standard Taglib). I've seen examples like the following, is this really all I need to do? import org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager; Object obj = ExpressionEvaluatorManager.evaluate( attName, attValue, clazz, this, pageContext); Looks good to me. The JSP 2.0 API will be a little more complex, but that's a tradeoff for it's vastly superior generality: it allows for use of the EL even beyond JSP pages. (And some extra baggage is necessary to support JSP 2.0's notion of 'EL functions', which was added after JSTL 1.0.) -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
I'm sure I could look this up myself, but it might be nice to have it in the archives with this thread. Which jar is needed if I want to add EL to my taglib. Without having to include the whole JSTL implementation? Hen On Wed, 21 Aug 2002, Shawn Bayern wrote: On Wed, 21 Aug 2002, Mark R. Diggory wrote: On another note, I've been playing around with Taglibraries for some time now. I'd like to integrate the EL Engine into my libraries, from what I understand it is now going to be part of the JSP 2.0 spec as well. How might I go about integrating it into my Taglibraries? JSP 2.0 makes the interface standard; with JSP 1.2 and JSTL 1.0, you need to use the custom interface supported by whichever implementation you choose (e.g., the Standard Taglib). I've seen examples like the following, is this really all I need to do? import org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager; Object obj = ExpressionEvaluatorManager.evaluate( attName, attValue, clazz, this, pageContext); Looks good to me. The JSP 2.0 API will be a little more complex, but that's a tradeoff for it's vastly superior generality: it allows for use of the EL even beyond JSP pages. (And some extra baggage is necessary to support JSP 2.0's notion of 'EL functions', which was added after JSTL 1.0.) -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
On Wed, 21 Aug 2002, peter lin wrote: in the interest of discussion. I find it useful to have cookie, user-agent and other advanced capabilities in a web services context. As web services becomes more common place, supporting those features might become very important. But is it important to support this from within JSP pages, instead of Java-based components? -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
On Wed, 21 Aug 2002, Henri Yandell wrote: I'm sure I could look this up myself, but it might be nice to have it in the archives with this thread. Which jar is needed if I want to add EL to my taglib. Without having to include the whole JSTL implementation? This is tricky and in flux. The best thing to do for the JSTL 1.0 expression language is to drop 'standard.jar' into the application. Right now, the build process has a 'jsp20el.dist' target that produces a 'jsp20el.jar' archive containing just the JSP 2.0 EL. This may change, but it will work against the current versions of the CVS archive. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
The Jakarta Commons HttpClient has been usefull to me on a limited basis. All I really use it for is for building Multipart File Posts. And to do that I even had to use a Class someone wrote which is not in the HttpClient package right now. The nice thing about the package is that I can build a multipart requests off of files on the filesystem instead of byte[]'s in memory. On the other hand, I've recently encountered issues with the responses being buffered either in memory or on the filesystem, which kinda sucks when all you want is to get an an InputStream on a really big XML file and SAX parse it. So the HTTPClient library is a good package, but I see area's in need of improvement in it. -Mark Henri Yandell wrote: Isn't this the kind of thing that Jakarta Commons HttpClient specialises in? In which case a taglib for that would be a pretty nice affair... [I assume there's not one already..] Hen On Wed, 21 Aug 2002, Shawn Bayern wrote: Indeed - JSTL 1.0 does not support advanced HTTP operations from within JSP pages using c:import (e.g., basic authentication, free modification of headers), but a future version of JSTL could if there were enough perceived need. As Peter says, it's a good idea to inform the expert group if you'd like to see this feature; the address is [EMAIL PROTECTED] -- Shawn Bayern JSTL in Action http://www.jstlbook.com On Wed, 21 Aug 2002, peter lin wrote: I'm assuming you want to get at things like cookies, user-agent and other http header data. you may want to make a request to the expert group, so that it is included in the next version of JSTL. I believe the current importsupport class just uses standard url httpurlconnection classes. shawn will know more about the current implementation and where it might go in the future. peter Mark R. Diggory wrote: Now that I have your attention. We are continually working with managing headers in our URL object requests to get resources from different locations. Is there really any way I can set the request Header info on the URL object being created by c:import? Right now I have my own custom implementations to aquire such resources. I'd rather be able to use the Standard Taglib. -Mark Diggory Harvard-MIT Data Center -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
Shawn Bayern wrote: On Wed, 21 Aug 2002, peter lin wrote: in the interest of discussion. I find it useful to have cookie, user-agent and other advanced capabilities in a web services context. As web services becomes more common place, supporting those features might become very important. But is it important to support this from within JSP pages, instead of Java-based components? True, but these days, even the simplest of HTTP requests often deal with User-Agent to control presentation and cookie headers to preserve State. I'm not saying I want a full HttpClient implementation in my taglib, just a wee bit more access to the standard URL/URLConnection properties. Such that I can pass on a cookie I may have. Again, I'll send this discussion onto the expert group. -Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
I'm not sure where it should reside to be honest. I can see argument for both sides. If I wanted to access data that resides on an IIS machine that has challenge/response turned on, it would be good to have cookie/auth support in jstl c:import but one could easily argue it should be in a bean to provide more advanced capabilities like caching or other RPC protocols. For an enterprise solution with high loads, it might make more sense to create a custom solution, but I've seen situations where data comes from third parties. Trying to get data providers to build a custom RPC mechanism often is more trouble than it's worth, so a simple c:import mechanism that supports cookies authentication would be a simpler solution. I'm glad the decision isn't up to me because either way you go, some one is going to complain. peter Shawn Bayern wrote: On Wed, 21 Aug 2002, peter lin wrote: in the interest of discussion. I find it useful to have cookie, user-agent and other advanced capabilities in a web services context. As web services becomes more common place, supporting those features might become very important. But is it important to support this from within JSP pages, instead of Java-based components? -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
I think I agree with all of this. For JSTL 1.0, we opted to be a bit conservative since the need didn't yet strongly present itself. It wouldn't surprise me if a future version can add support for headers and HTTP POST; that might represent the knee in the curve, so to speak, between convenience and encumbrance. -- Shawn Bayern JSTL in Action http://www.jstlbook.com On Wed, 21 Aug 2002, peter lin wrote: I'm not sure where it should reside to be honest. I can see argument for both sides. If I wanted to access data that resides on an IIS machine that has challenge/response turned on, it would be good to have cookie/auth support in jstl c:import but one could easily argue it should be in a bean to provide more advanced capabilities like caching or other RPC protocols. For an enterprise solution with high loads, it might make more sense to create a custom solution, but I've seen situations where data comes from third parties. Trying to get data providers to build a custom RPC mechanism often is more trouble than it's worth, so a simple c:import mechanism that supports cookies authentication would be a simpler solution. I'm glad the decision isn't up to me because either way you go, some one is going to complain. peter Shawn Bayern wrote: On Wed, 21 Aug 2002, peter lin wrote: in the interest of discussion. I find it useful to have cookie, user-agent and other advanced capabilities in a web services context. As web services becomes more common place, supporting those features might become very important. But is it important to support this from within JSP pages, instead of Java-based components? -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: c:import full windows path
On Fri, 9 Aug 2002, Amarant Merah wrote: Is it possible to import a file based on full path? e.g. E:/somepath/myfile.xml I understand it is possible to import using full http url or relative to webapp like these: c:import url=http://domain.com/somepath/myfile.xml; var=xml/ c:import url=/somepath/myfile.xml var=xml/ I need something like c:import url=E:/abc/somepath/myfile.xml var=xml/ and the above doesn't work. Yes, you'd use a 'file' URL, as with a browser. For instance: c:import url=file:///e:/abc/somepath/myfile.xml / -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
c:import full windows path
Hi, Is it possible to import a file based on full path? e.g. E:/somepath/myfile.xml I understand it is possible to import using full http url or relative to webapp like these: c:import url=http://domain.com/somepath/myfile.xml; var=xml/ c:import url=/somepath/myfile.xml var=xml/ I need something like c:import url=E:/abc/somepath/myfile.xml var=xml/ and the above doesn't work. Basically I want to be able to import files that lie on other partitions outside the webapp. Any workaround? Regards, Amarant. = Amarant Merah - survive, and fighting. http://digital.yahoo.com.au - Yahoo! Digital How To - Get the best out of your PC! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
C:Import
I am trying to pass along the XML file I would like to
ttransform via parameter.
I get the error:
java.lang.ArrayIndexOutOfBoundsException at
org.apache.catalina.util.RequestUtil.URLDecode(RequestUtil.java:417)
I assume I have missed a step. I found some help on
encoding but it would appear to be old help.
So how do get a string from request and pass it along
to C:import do it can make sense out of it? Pretty
simple I am sure.
The file is:
% String xmlReq = request.getParameter(xml); %
%@taglib uri=http://java.sun.com/jstl/core;
prefix=c %
%@taglib uri=http://java.sun.com/jstl/xml;
prefix=x %
c:import url=generic.xsl var=xslt/
c:import url=%=xmlReq% var=xml/
x:transform xml=${xml} xslt=${xslt}/
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: C:Import
On Mon, 15 Jul 2002, Tim Ringwood wrote:
% String xmlReq = request.getParameter(xml); %
%@taglib uri=http://java.sun.com/jstl/core;
prefix=c %
%@taglib uri=http://java.sun.com/jstl/xml;
prefix=x %
c:import url=generic.xsl var=xslt/
c:import url=%=xmlReq% var=xml/
x:transform xml=${xml} xslt=${xslt}/
You cannot use rtexprvalues in the EL versions of JSTL tags. Replace the
second line with the following:
c:import url=${param.xmlReq} var=xml /
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
(coming in July 2002 from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
c:import when file doesn't exist
I remember hearing something about JSTL offering a try/catch syntax, or
maybe it was JSP 1.2. Anywhoo, I need it.
When I have the following, and $wrapperURL does not exist as a file, a
ServletException is thrown. I'd like to be able to gracefully handle
it.
c:import url=${pageScope.wrapperURL}/
Thanks,
Matt
Re: c:import when file doesn't exist
On Thu, 6 Jun 2002, Matt Raible wrote:
I remember hearing something about JSTL offering a try/catch syntax, or
maybe it was JSP 1.2. Anywhoo, I need it.
It's c:catch, as in
c:catch var=error
c:import ... /
/c:catch
c:if test=${not empty error}
Not there!
/c:if
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
(coming in July 2002 from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
compilation order with c:import
I have some problem using c:import together with jsp:include.
In fact when a page like this is compiled :
c:import url=include/boxEpNewsData.jsp
c:param name=ID%=request.getParameter(ID)%/c:param
c:param name=myDay value=${myDay} /
/c:import
p
jsp:include page=include/boxUltimeEpNews.jsp flush=false
jsp:param name=num value=20/
/jsp:include
I have the first part displayed after the second part, and it seems to me impossible
:-)
Looking in the generated java code of the page I have this:
_jspTagHandler4 = new org.apache.taglibs.standard.tag.el.core.ImportTag();
_jspTagHandler4.setPageContext( pageContext );
_jspTagHandler4.setParent( null );
setProperty( _jspTagHandler4, url, include/boxEpNewsData.jsp,
java.lang.String );
try
{
_jspTagHandlerAction = _jspTagHandler4.doStartTag();
.import something
}
catch( Throwable t )
{
_jspTagHandler4.doCatch( t );
}
finally
{
_jspTagHandler4.doFinally();
}
if( _jspTagHandlerAction == Tag.SKIP_PAGE )
{
return;
}
_jspTagHandler4.release();
out.write( \r\n\t\t\t\t\tp\r\n\t\t\t\t\t );
pageContext.include( include/boxUltimeEpNews.jsp );
So my consideration is that the import tag works different from the jsp:include and is
displayed after the completion of the rest of the page.
Unfortunately I cannot use only jsp:include because I got errors when using
jsp:param name=num value=%=request.getParameter(ID)%/
Thank you
Andrea Grittini
Andrea Grittini ( mailto:[EMAIL PROTECTED])
Tel: +39-2-97482.1- Fax: +39-2-97482?
Computer Design S.r.l., Via Piave 46 - 20010 S.Stefano Ticino - ITALY
http://www.cdesign.it/
Re: compilation order with c:import
I can't explain what you're seeing with the content switched around like
that. (What container are you using?)
However, regarding the use of jsp:param, you just need to use single
quotes around the value of the attribute. This should work:
jsp:param name=num value='%=request.getParameter(ID)%'/
--
Martin Cooper
At 07:33 AM 5/7/2002, Andrea Grittini wrote:
I have some problem using c:import together with jsp:include.
In fact when a page like this is compiled :
c:import url=include/boxEpNewsData.jsp
c:param name=ID%=request.getParameter(ID)%/c:param
c:param name=myDay value=${myDay} /
/c:import
p
jsp:include page=include/boxUltimeEpNews.jsp flush=false
jsp:param name=num value=20/
/jsp:include
I have the first part displayed after the second part, and it seems to
me impossible :-)
Looking in the generated java code of the page I have this:
_jspTagHandler4 = new
org.apache.taglibs.standard.tag.el.core.ImportTag();
_jspTagHandler4.setPageContext( pageContext );
_jspTagHandler4.setParent( null );
setProperty( _jspTagHandler4, url, include/boxEpNewsData.jsp,
java.lang.String );
try
{
_jspTagHandlerAction = _jspTagHandler4.doStartTag();
.import something
}
catch( Throwable t )
{
_jspTagHandler4.doCatch( t );
}
finally
{
_jspTagHandler4.doFinally();
}
if( _jspTagHandlerAction == Tag.SKIP_PAGE )
{
return;
}
_jspTagHandler4.release();
out.write( \r\n\t\t\t\t\tp\r\n\t\t\t\t\t );
pageContext.include( include/boxUltimeEpNews.jsp );
So my consideration is that the import tag works different from the
jsp:include and is displayed after the completion of the rest of the
page.
Unfortunately I cannot use only jsp:include because I got errors when
using
jsp:param name=num value=%=request.getParameter(ID)%/
Thank you
Andrea Grittini
Andrea Grittini ( mailto:[EMAIL PROTECTED])
Tel: +39-2-97482.1- Fax: +39-2-97482?
Computer Design S.r.l., Via Piave 46 - 20010 S.Stefano Ticino - ITALY
http://www.cdesign.it/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Using c:import to include the contents of a file
Great - thanks again! -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 8:53 PM To: Tag Libraries Users List; [EMAIL PROTECTED] Subject: Re: Using c:import to include the contents of a file Yes, you can do this. You need to use three slashes at the front, so your example would be: c:import url=file:///d:\repository\assets\doc.html/ From the remaining separators, you can use either '/' or '\', but personally I always use '/' because then I don't have to worry about which I can use where. -- Martin Cooper - Original Message - From: Matt Raible [EMAIL PROTECTED] To: 'Tag Libraries Users List' [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 7:14 PM Subject: Using c:import to include the contents of a file I want to do the following: c:import url=file://d:\repository\assets\doc.html/ However, I get an UnknownHostException - is it possible to do this with JSTL? My only solution (so far) is to use an iframe and do: iframe src=file://d:\repository\assets\doc.html/iframe It's the only way I've found to read a file from the filesystem when it's outside Tomcat's webapps directory. Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Using c:import to include the contents of a file
I want to do the following: c:import url=file://d:\repository\assets\doc.html/ However, I get an UnknownHostException - is it possible to do this with JSTL? My only solution (so far) is to use an iframe and do: iframe src=file://d:\repository\assets\doc.html/iframe It's the only way I've found to read a file from the filesystem when it's outside Tomcat's webapps directory. Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using c:import to include the contents of a file
Yes, you can do this. You need to use three slashes at the front, so your example would be: c:import url=file:///d:\repository\assets\doc.html/ From the remaining separators, you can use either '/' or '\', but personally I always use '/' because then I don't have to worry about which I can use where. -- Martin Cooper - Original Message - From: Matt Raible [EMAIL PROTECTED] To: 'Tag Libraries Users List' [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 7:14 PM Subject: Using c:import to include the contents of a file I want to do the following: c:import url=file://d:\repository\assets\doc.html/ However, I get an UnknownHostException - is it possible to do this with JSTL? My only solution (so far) is to use an iframe and do: iframe src=file://d:\repository\assets\doc.html/iframe It's the only way I've found to read a file from the filesystem when it's outside Tomcat's webapps directory. Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: failure of c:import
On Mon, 25 Mar 2002, Biske, Todd wrote: Is there a way using c:catch or some other mechanism to trap exceptional HTTP response codes, e.g. 4xx and 50x codes and perform action on them? When using this tag for include portlets from other contexts, it would seem that this type of functionality is critical. Todd -- great question. This is currently in flux; we're discussing how best to handle error conditions in c:import. It'll most likely be decided before JSTL's public final draft (PFD). -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
