tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 46339] Recursive tag files with JspFragment attributes fails
Date Sun, 28 Dec 2008 23:05:20 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=46339


Mark Thomas <markt@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Mark Thomas <markt@apache.org>  2008-12-28 15:05:19 PST ---
Thanks for the excellent test case. It made investigating this much, much
easier.

Unfortunately, the behaviour you are expecting appears to be in breach of the
JSP spec. I say "appears" since the JSP spec itself isn't 100% clear.
JSP.5.12.3 states that:

"When a tag file invokes a fragment that appears in the calling page, the JSP
container provides a way to synchronize variables between the local page scope
in the tag file and the page scope of the calling page."

What wasn't clear to me was how should this be interpreted for iterative and/or
nested tags. Should the tag's local page scope be synchronised with the page
scope of the page/tag that calls it (i.e. its immediate parent) or should it be
synchronised with the outermost calling JSP page?

Currently, Tomcat synchronises local page scope with the parent's page scope.
Your test case requires that the local page scope is synchronised with the
outermost calling JSP page.

I modified Tomcat so your test would pass and ran the JSP Technology
Compatibility Kit (TCK). The changes caused several failures. Further
investigation showed that the TCK expects the local page scope to be
synchronised only with the immediate parent. Based on experience, if there is
an ambiguity in the specification language and the TCK requires a particular
interpretation of the spec language then the TCK interpretation is the correct
one.

Therefore, I conclude that this bug in invalid since it attempts to do
something in breach of the spec.

To be sure, I will raise this with the EG in case the TCK is based on an
incorrect interpretation.


-- 
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


Mime
View raw message