https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
John Engebretson changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #19 from John Engebretson ---
We had a working version that chunked the jspService method, but dropped it
because our use cases didn't need it... and the whole package was already
pretty complex. Unfortunately I can't find the sour
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #18 from Christopher Schultz ---
These are good ideas, especially the Objective-C-style
_callTag_org_apache_taglibs_standard_tag_rt_core_SetTag_With_var_And_value
method generation and invocation.
The biggest problem with Java-code
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #17 from John Engebretson ---
Our Tomcat8 implementation modified Generator.java along the following lines:
1. When a tag call is found (any tag!):
- generate a method name that uniquely identifies the tag class and the
provided at
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #16 from Mark Thomas ---
My expectation was that you'd use the plug-in mechanism to implement the
optimisation for described in issue 1.
If you want to provide a generic optimisation to multiple/all tags then that
probably won't s
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #15 from John Engebretson ---
Sorry, I'm a little confused - are you planning to generate plugins for every
tag? I view this more as an optimization to the global JSP compiler.
--
You are receiving this mail because:
You are the
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #14 from Mark Thomas ---
Created attachment 37867
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37867&action=edit
Sample plug-in for
--
You are receiving this mail because:
You are the assignee for the bug.
-
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #13 from Mark Thomas ---
I've spent some time this afternoon looking at issue 1. Tomcat's tagPlugin
mechanism is the supported way to approach this. It lets you generate your own
optimised code for tags. It is pretty flexible so you
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #12 from Mark Thomas ---
Regarding issue 3:
The call to _jspx_page_context.getOut() is now only made when required.
The variable aliasing is more difficult. For more background see this thread
https://markmail.org/thread/7hksrkahp
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #11 from Mark Thomas ---
It has taken a while but I have just committed additional tests that bring the
code coverage for Generator close to 100%. Next steps will be looking at the
optimisations.
The work on the tests identified so
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #10 from John Engebretson ---
Good plan... our initial deployment had to be rolled back because I broke some
weird syntax in tag fragments.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #9 from Mark Thomas ---
Just a heads up that I am going to be spending some time improving the code
coverage of the unit tests for the Generator class before looking at options to
address issues 1 and 3. There are a lot of edge case
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #8 from John Engebretson ---
Thank you, I've confirmed we are missing the JspC parameter, and we are
correcting that in our apps.
--
You are receiving this mail because:
You are the assignee for the bug.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #7 from Mark Thomas ---
The setting at pre-compilation would control whether pooling was enabled or
not. You'd need to call JspC with :
... -poolingEnabled false ...
to disable tag pooling. Note that is all case sensitive.
Still
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #6 from John Engebretson ---
Hmm.
1. Tomcat 8?
2. We usually precompile our JSPs, perhaps there is something dynamic that
handles it and we never noticed?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #5 from Mark Thomas ---
I can't repeat issue 2. If I clean out the work directory, disable tag pooling
in conf/web.xml and then start Tomcat, the generated code doesn't have the
*_reuse variable.
--
You are receiving this mail bec
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #4 from Mark Thomas ---
Scratch that. The first example I looked at didn't have any pooling code but
another one did. I see the issue.
Regarding point 3, those parameters are required in some circumstances. I'm
currently looking to
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #3 from John Engebretson ---
Sure! Tag pooling generates several lines of code in the compiled JSP; the
lines below are copied from the attached source files, at the tail end of the
"Old-style generated code" blocks. The code is n
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
--- Comment #2 from Mark Thomas ---
Can you clarify what you mean in point 2? It isn't clear to me which logic you
are referring to. An example would probably be best.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
Mark Thomas changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Mark Tho
20 matches
Mail list logo
