Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: dev@tomcat.apache.org
Subject: DO NOT REPLY [Bug 46339] Recursive tag files with JspFragment
 attributes fails
In-Reply-To: <bug-46339-78@https.issues.apache.org/bugzilla/>
References: <bug-46339-78@https.issues.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Message-Id: <20090108032102.33479234C498@brutus.apache.org>
Date: Wed,  7 Jan 2009 19:21:02 -0800 (PST)

https://issues.apache.org/bugzilla/show_bug.cgi?id=46339


--- Comment #6 from Konstantin Kolinko <knst.kolinko@gmail.com>  2009-01-07 19:20:59 PST ---
My reading of the spec (JSP 2.1, Final Release) is the following

1. The spec in many places uses "calling page" where "calling page or tag" is
meant, and I think that it is only for brevity. The full sentence with "or tag"
or "/tag" is usually written several lines below such a fragment.

E.g. JSP.5.12.3 that Mark cited in comment 1, continues with "The container
must then generate code to synchronize the page scope values for the variable
in
the tag file with the page scope equivalent in the calling page or tag file."

Thus, the NESTED and AT_BEGIN variables update the page scope of the calling
page or tag. It is said in JSP.5.12.3 (page "1-114"), in JSP.8.9 (page
"1-186"), and elsewhere.

That explains why the first patch that breaks TCK is incorrect.

It might require a review by an editor to lessen such omissions, especially in
the first sentences of a chapter and in tables.

2. Each JSP Fragment is associated with a JspContext of that page or tag in
context of which it is defined.

It is first mentioned in JSP.5.12.1 (page "1-113") and explained in detail in
Part II in chapter "7. JSP Fragments" in description of package
"javax.servlet.jsp.tagext" in Part II (pages "2-77" through "2-79").

I find it understandable, because the page author may reference any other
variable of the page, and those are of no concern for the tag authors.

This said, here is a solution for the recursive.tag file: redeclare the JSP
fragment. That is, patching recursive.tag:

- <x:recursive content="${content}" depth="${depth-1}"/>
+ <x:recursive depth="${depth-1}">
+   <jsp:attribute name="content">
+     <jsp:invoke fragment="content"/>
+   </jsp:attribute>
+ </x:recursive>

--
A small thing that was bugging me was how this redeclaration will work in view
of JSP.5.12.1 phrase that says "the results will be sent to the JspWriter of
the JspContext associated with the JspFragment." and how it plays along with
specifying an explicit Writer (var or varReader attributes of jsp:invoke
action).

That is: how invoking a fragment from a fragment will work if the writer for
the outer fragment was specified explicitly, but not for the inner fragment,
and the inner fragment belongs to the parent page?
That is, will it bypass it and write to the page? The answer is that it would
not. That is good.
As implemented in Tomcat, the JspWriter in not stored in JspContext of the tag,
but in the one of the page. Thus, specifying an explicit writer
(context.pushBody() call) is delegated to the page, thus affecting all the
tags. Thus, all fragments in the same response do write to the same writer.
I do not know where in the specification it comes from (I think it should be
written somewhere when defining a "JSP Context Wrapper"), but it works good.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org