The following is from the specs In the JSP specification, a <jsp:include> action provides for the inclusion of static and dynamic resources located in the same context as the current page. This is a very convenient feature that is widely used by page authors. However, <jsp:include> falls short in flexibility when page authors need to get access to resources that reside outside of the web application. In many situations, page authors have the need to import the content of Internet resources specified via an absolute URL. Moreover, as sites grow in size, they may have to be implemented as a set of web applications where importing resources across web applications is a requirement. <jsp:include> also falls short in efficiency when the content of the imported resource is used as the source for a companion process/transformation action, because unnecessary buffering occurs. In the example below, the <acme:transform> action uses the content of the included resource as the input of its transformation. <jsp:include> reads the content of the response, writes it to the body content of the enclosing <acme:transform>, which then re-reads the exact same content. It would be more efficient if <acme:transform> could access the input source directly and avoid the buffering involved in the body content of <acme:transform>.
The url attribute is used to specify the URL of the resource to import. It can either be an absolute URL (i.e. one that starts with a protocol followed by a colon), a relative URL used to access a resource within the same context, or a relative URL used to access a resource within a foreign context. The three different types of URL are shown in the sample code below.
By default, the content of an imported resource is included inline into the JSP page. It is also possible to make the content of the resource available in two different ways: as a String object (attribute var), or as a Reader object (attribute varReader). Other tags can then access the resource's content through that exported object. Exporting the resource as a String object caches its content and makes it reusable. If the imported content is large, some performance benefits may be achieved by exporting it as a Reader object since the content can be accessed directly without any buffering. However, the performance benefits are not guaranteed since the reader�s support is implementation dependent. It is also important to note that the varReader scoped variable has nested visibility; it can only be accessed within the body content of <c:import>.
It is also important to note that the varReader scoped variable has nested visibility; it can only be accessed within the body content of <c:import>.
Not so clear of varReader. IS it same as var attribute. To my understanding var attribute is created at page scope and holds value of url attribute. We can print the value hold by var attribute ouside <c:import> tag in the page.
Can someone confirm my understanding and clear about varReader attribute
By default, the content of an imported resource is included inline into the JSP page. It is also possible to make the content of the resource available in two different ways: as a String object (attribute var), or as a Reader object (attribute varReader).
A Reader, however, needs to be nested within a <c:import> to assure that the Reader is properly closed and isn't accidentally left open. We can demonstrate this with the sample below:
<c:import url=http://sample.com/customers varReader="customers">
The advantage of using a Reader is that the content can be accessed directly without any buffering.
And yes, we can print the value held by var attribute outside the <c:import> tag in the page.
To sum up, the contents of an imported resource can be included inline like the standard jsp action <jsp:include>. apart from including it inline the contents can be stored as a String object using attribute var and as a Reader object using attribute varReader. Both do the same thing of making the content of the imported resource available to the page. While the string object is cached (for relatively smaller contents) the reader object doesn't cache the content and is ideal for high content imports.