https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #31 from John Engebretson ---
Wondeful, thank you very much! And the non-static Logger does make sense as a
safety measure.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #29 from John Engebretson ---
Thank you! :)
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #28 from Mark Thomas ---
There needs to be agreement from the Tomcat committers to add all of this. I'm
confident the new interface will be accepted. I'm not sure about the optimised
implementations.
I can't be any moire precise
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #27 from John Engebretson ---
For planning purposes, approximately when can we expect to see this in Tomcat 9
and 10?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #26 from Mark Thomas ---
The duplication of the try/catch and Type.valueOf() struck me as too much to
duplicate for the numerical types.
char and boolean were much more borderline whether it there was enough code
duplication to
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #25 from Christopher Schultz ---
I noticed that some of the boxed/primitive handling (e.g. boolean, char) are
handled in separate branches and others (e.g. long, int, short) are handled
together in a single branch (with
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #24 from Mark Thomas ---
There can be issues around loggers and class loading with Jasper. Tomcat has a
custom LogManager that ID's logger by a combination of name and
ThreadContextClassLoader (rather than just name).
Depending on
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #23 from John Engebretson ---
My constant reaction is "I'm glad you're doing this and not me." Your
expertise is creating a far better implementation than I did! Thank you for
your hard work.
The code looks solid; the only thing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #22 from Mark Thomas ---
Updated branch:
https://github.com/markt-asf/tomcat/tree/bz-64872
The tests for the optimised ELInterpreter show about 10% improvement. The tests
for the custom StringInterpreter (that handles
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #21 from John Engebretson ---
Sounds like a good plan!
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #20 from Mark Thomas ---
Most of the String conversion (outside of EL) should be reasonably optimal
already. Enums look to be by far the most likely potential optimisation there
unless folks are using custom PropertyEditors.
The
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #19 from John Engebretson ---
A StringInterpreter is a good idea. I've had the nagging feeling that there
are other places where this pattern is useful and I just haven't found them
yet centralizing the logic will make that
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #18 from Mark Thomas ---
ACK re the Enum handling. I'll take another look at options for that. I'm still
leaning towards something like a "StringInterpreter".
--
You are receiving this mail because:
You are the assignee for the
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #17 from John Engebretson ---
Thanks for the activation info, that's perfect.
I've verified the enum case works as I intended on our production servers; the
compiled java code correctly points directly to the enum rather than any
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #16 from Mark Thomas ---
Glad you think it is heading in the right direction. It might not look it but
the important parts are heavily based on the patch you provided.
I am only going from source code rather than testing but I
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #15 from John Engebretson ---
Reading over your commit, it is vastly superior to my implementation, and I am
grateful for your efforts. :)
The attached patch addresses the attr="enumValue" case using a code branch
towards the
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #14 from Mark Thomas ---
Here is a first pass at a possible approach using ELInterpreter.
This doesn't address the attr="enumValue" case but my reading of the attached
patch is that it doesn't handle that case either. Since that
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #13 from Mark Thomas ---
Thanks for that.
I think it should be possible to use the extension point added for bug 54239 to
implement this. I'll take a look.
--
You are receiving this mail because:
You are the assignee for the
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #12 from John Engebretson ---
Created attachment 37561
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37561=edit
Extract from Tomcat8 optimizations
Approval was rapid, and the extract is attached. It is not a patch file
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #11 from Mark Thomas ---
Tx.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #10 from John Engebretson ---
I'll have to run it past the lawyers, etc. I'll submit the request
immediately. Previous submissions have taken between one day and two weeks but
this should be an easy one.
--
You are receiving
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #9 from Mark Thomas ---
Understood. Any chance you could provide that patch anyway? Saves re-inventing
the wheel.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #8 from John Engebretson ---
Our internal patch contained more than one change (the release process was
challenging) but separating out this change comes to around 60 lines of code
across two files.
However, that patch is not up
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #7 from Mark Thomas ---
That all seems reasonable to me.
How big is the patch? Generally, the smaller the patch the fewer the concerns
around size of patch vs how widely used the feature is likely to be.
--
You are receiving
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #6 from John Engebretson ---
We have a Tomcat8 implementation deployed that addresses the following cases:
Boolean/boolean properties:
value="true"
value="${true}"
value="${'true'}"
String properties:
value="${'myString'}"
Enum
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #5 from Mark Thomas ---
Yes, I could support a feature like that.
The tricky part is going to be implementing it. The JSP engine doesn't have
access to the internals of the EL parser. Just musing on that, are all the uses
of the
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #4 from John Engebretson ---
"Fudging the spec is not an option." Understood.
"That said, I do wonder why expression language is being used in these
instances rather than a scriptlet." EL was originally used for this because a)
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #3 from Mark Thomas ---
Fudging the spec is not an option. Providing an option that provides non-spec
compliant behaviour and is disabled by default is an option.
That said, I do wonder why expression language is being used in
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
--- Comment #2 from John Engebretson ---
I think you're right that the letter of step #2 proscribes this change. My
subsequent text in no way attempts to undermine or change that statement.
In the vast majority of cases, when a JSP author
https://bz.apache.org/bugzilla/show_bug.cgi?id=64872
Mark Thomas changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Mark
31 matches
Mail list logo
