Re: Is it possible to programmatically compile jsp files?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jonathan,

On 3/25/20 09:51, Jonathan Yom-Tov wrote:
> I think I phrased my question incorrectly. What I want to do is to
> cache the HTML resulting from the JSPs evaluation so I can serve
> the cached result. The reason is that I'm working on an application
> which makes a lot of requests per page. This makes the page very
> slow. What I want to do is to serve some of the requests which
> build the page out of a cache. Rewriting the offending endpoints
> would be a very lengthy process. There are a lot of them and
> they're part of a legacy project which is very hard to get into.>
> So is pre-evaluating the JSPs the correct strategy or is there a
> better way?

I think the better way would be to use a caching (reverse) proxy.
mod_proxy and mod_cache in httpd can help you out a lot, here. Other
proxies are certainly capable of caching as well.

Remember that your "dynamic" page needs to return caching-control
headers that are appropriate for your needs.

- -chris

> On Tue, Mar 24, 2020 at 11:59 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Jonathan,
>
> On 3/24/20 10:44, Jonathan Yom-Tov wrote:
 I have a set of jsp files. These jsps' compilation result
 changes whenever a variable in my cache changes. I want to
 compile them whenever that variable changes so they're ready
 to serve without going through the normal pipeline. Is that
 possible?
>
> I completely agree with Olaf's response.
>
> That being said, there is a spec-defined way to invoke compilation
> of a JSP without evaluating it: make a request to
> /context/path/to/my.jsp?jsp_precompile
>
> This is defined in JSP 2.3 section 11.4.2. I wasn't able to find
> the JSP spec 3.0 publication, but I'll bet it will be in there once
> it's published (it may have been subsumed into Jakarta EE at this
> point).
>
> -chris
>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl57pAEACgkQHPApP6U8
pFiruA//XN+A+NfhOb5StY4vkKBlb7N95NgvNyap8lV7zFMDKwpPZ9SFtY3KHRtd
dHFtWafAuJpIdSHorPlxCZLZ0vkBKIR4vyOM00LLDJbxn6CJgQdv9ktbtFT5KOBA
0ZOv31AuFBkCwv3t0cjioyoxkEL9e9oFDONz3e7CelJsGTVnRjsqpVHrn12MnLze
WoscQh/iLg1vtqkqbUrAFqXCui88ffEShiSM6+feYetsoSKI64ZtH9yX1EbGINUe
f1FjluCnLfi7ZxIw9V60ohFVj8dfPLLegRiT/B4Dqy2EKFYf+HY/2Dy5D+qWXfWw
02c54KDz6uRc4gkcYn9jjgSbwrUbKh77FB/aRq0T5CLG5RCUHR2pM9j6f7LZ82rK
wgQTTg+125XEaCq6l09xJqw87cG8lNP+Ft4eObtt1s27Ae50Z9+PvFm7Q3EcEWPj
c2Gr39w4XPK9fnfx3molN3zb+yIb8EEUOw/4oR+bnDdTnQsqtAExn/DqOswESNFc
K87NWIg/5zm0yeQw7A27BM+SVUXJUhSFDKEyW+JJcQ6KF0ZYDUnJrOPK7Th/tpEL
4SyRijwDwtd552FnISR2XK+w5dSAfvHyon/McBrQtDXMksh9snBB8E76L+BIrTjR
8yj/K+pjVpOsZkR38BiQaDstUQQJPQBC1hwQ8bOXu1efCfxdbi8=
=V4eM
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is it possible to programmatically compile jsp files?

[Olaf Kock]

On 25.03.20 15:19, Jonathan Yom-Tov wrote:
> Sounds good. What would be the best way of evaluating the result so I can
> cache it?

Buffer the output (e.g. by providing a buffered stream for the response)

I'm not sure if this means that you'll need to wrap the response object,
of if you could just replace its output stream. But in general: In your
filter, make sure you get hold of the output stream and capture its
content before you pass the request along the filter chain. After
returning, obtain the buffer, save it for future use, then dump it on
the original output stream. The commons project has a couple of nice
options (I vaguely remember a TeeOutputStream or similar, which would
automagically be able to keep your current client happy, while also
filling up the buffer)


Olaf



> On Wed, Mar 25, 2020 at 4:03 PM Olaf Kock  wrote:
>
>> On 25.03.20 14:51, Jonathan Yom-Tov wrote:
>>> I think I phrased my question incorrectly. What I want to do is to cache
>>> the HTML resulting from the JSPs evaluation so I can serve the cached
>>> result. The reason is that I'm working on an application which makes a
>> lot
>>> of requests per page. This makes the page very slow. What I want to do is
>>> to serve some of the requests which build the page out of a cache.
>>> Rewriting the offending endpoints would be a very lengthy process. There
>>> are a lot of them and they're part of a legacy project which is very hard
>>> to get into.
>>>
>>> So is pre-evaluating the JSPs the correct strategy or is there a
>> better way?
>>
>>
>> well, with that, you could either request the JSP yourself and cache the
>> result. To do this transparently, you could implement a ServletFilter
>> that caches the result if it senses a cacheable request and (on
>> subsequent requests) transparently serves the value from cache as long
>> as the criteria ("should re-evaluate") holds.
>>
>> Bonus points for taking care of concurrent requests during
>> re-evaluation, and pause them during the time a re-evaluation is done in
>> a different request.
>>
>> Olaf
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is it possible to programmatically compile jsp files?

[Jonathan Yom-Tov]

Sounds good. What would be the best way of evaluating the result so I can
cache it?

On Wed, Mar 25, 2020 at 4:03 PM Olaf Kock  wrote:

>
> On 25.03.20 14:51, Jonathan Yom-Tov wrote:
> > I think I phrased my question incorrectly. What I want to do is to cache
> > the HTML resulting from the JSPs evaluation so I can serve the cached
> > result. The reason is that I'm working on an application which makes a
> lot
> > of requests per page. This makes the page very slow. What I want to do is
> > to serve some of the requests which build the page out of a cache.
> > Rewriting the offending endpoints would be a very lengthy process. There
> > are a lot of them and they're part of a legacy project which is very hard
> > to get into.
> >
> > So is pre-evaluating the JSPs the correct strategy or is there a
> better way?
>
>
> well, with that, you could either request the JSP yourself and cache the
> result. To do this transparently, you could implement a ServletFilter
> that caches the result if it senses a cacheable request and (on
> subsequent requests) transparently serves the value from cache as long
> as the criteria ("should re-evaluate") holds.
>
> Bonus points for taking care of concurrent requests during
> re-evaluation, and pause them during the time a re-evaluation is done in
> a different request.
>
> Olaf
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
[image: SysAid Technologies]

Jonathan Yom-Tov
Senior Architect
jonathan.yom...@sysaid.com
Phone (IL): +972 (3) 533-3675 Ext. 932
[image: SysAid Technologies]

  [image: SysAid on Facebook]    [image:
SysAid on Twitter]    [image: SysAid on
Linked-in]    [image:
SysAid on YouTube]    [image: SysAid
on Instagram] 
[image: Banner] 

Re: Is it possible to programmatically compile jsp files?

[Olaf Kock]

On 25.03.20 14:51, Jonathan Yom-Tov wrote:
> I think I phrased my question incorrectly. What I want to do is to cache
> the HTML resulting from the JSPs evaluation so I can serve the cached
> result. The reason is that I'm working on an application which makes a lot
> of requests per page. This makes the page very slow. What I want to do is
> to serve some of the requests which build the page out of a cache.
> Rewriting the offending endpoints would be a very lengthy process. There
> are a lot of them and they're part of a legacy project which is very hard
> to get into.
>
> So is pre-evaluating the JSPs the correct strategy or is there a
better way?


well, with that, you could either request the JSP yourself and cache the
result. To do this transparently, you could implement a ServletFilter
that caches the result if it senses a cacheable request and (on
subsequent requests) transparently serves the value from cache as long
as the criteria ("should re-evaluate") holds.

Bonus points for taking care of concurrent requests during
re-evaluation, and pause them during the time a re-evaluation is done in
a different request.

Olaf




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is it possible to programmatically compile jsp files?

[Jonathan Yom-Tov]

I think I phrased my question incorrectly. What I want to do is to cache
the HTML resulting from the JSPs evaluation so I can serve the cached
result. The reason is that I'm working on an application which makes a lot
of requests per page. This makes the page very slow. What I want to do is
to serve some of the requests which build the page out of a cache.
Rewriting the offending endpoints would be a very lengthy process. There
are a lot of them and they're part of a legacy project which is very hard
to get into.

So is pre-evaluating the JSPs the correct strategy or is there a better way?

On Tue, Mar 24, 2020 at 11:59 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jonathan,
>
> On 3/24/20 10:44, Jonathan Yom-Tov wrote:
> > I have a set of jsp files. These jsps' compilation result changes
> > whenever a variable in my cache changes. I want to compile them
> > whenever that variable changes so they're ready to serve without
> > going through the normal pipeline. Is that possible?
>
> I completely agree with Olaf's response.
>
> That being said, there is a spec-defined way to invoke compilation of
> a JSP without evaluating it: make a request to
> /context/path/to/my.jsp?jsp_precompile
>
> This is defined in JSP 2.3 section 11.4.2. I wasn't able to find the
> JSP spec 3.0 publication, but I'll bet it will be in there once it's
> published (it may have been subsumed into Jakarta EE at this point).
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl56gpIACgkQHPApP6U8
> pFjQRg//Sc+dmxwrmjtZEqiI6KIBsvBS6A3jpTPMhUb6akiYy9YqciuuLJnYu8EE
> tTYHkAo+52lIU15csUTRhGXzj1YgLexg3pVEroVChYgg9uwg0hN3+yp0UhbAjgxs
> tZ1eEbVJX5wEm7MiHEFZTxbkQnZ5nQXUGeQnM6cdVaZJKZs7Hu+unMiAKldz+zlP
> oNnfnchf4QEmI+z1L3ktBdwGBXaKCKTkdXXcPJKqzq/pEl/32/ncZS5xYOK0hcK3
> DK3pLLRxC9iBMKt5HSNMWAfiQMDtpVKpR4tLuwP+bB2rEKlkRYfslKzUHnWQlY0F
> afT1dOSQvxEWFpMmnzU5H/d6/G9+xYKSlq/duCBm/7OZndXUe1A+HDr+CUQNbem6
> hHSszZ4kZoyt6B8iIJKigduwY4GcZV2ZKTO334KTscXXNka0B3Um94UK1CQP4CWS
> n0lChV/bkqNviwcsA/Zq4YxrENpisVCvC2n4fILQ2ftqIgXmYR4sdYp5h3+joiEx
> 64saVENrOaLO8gMtGF1nsUhuJlvld4VA9bkdRkHDfO63nvUN4x3McxPG7VxOplmh
> Kws+axYpVekuHw0a7WkMQkPx0tIbIFuTs34KuoDifOjAoPGCCbOGKP9UlhndX9IR
> S0oMMgDKuO6DupVTx28xX9qfjXnNRVSnaSETBhNO6qajiUZA7V4=
> =ZiT1
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
[image: SysAid Technologies]

Jonathan Yom-Tov
Senior Architect
jonathan.yom...@sysaid.com
Phone (IL): +972 (3) 533-3675 Ext. 932
[image: SysAid Technologies]

  [image: SysAid on Facebook]    [image:
SysAid on Twitter]    [image: SysAid on
Linked-in]    [image:
SysAid on YouTube]    [image: SysAid
on Instagram] 
[image: Banner] 

Re: [OT] Tomcat Wiki Source Code Download

[Brian Burch]

On 25/3/20 8:09 am, Mark Thomas wrote:

On 24/03/2020 22:00, Christopher Schultz wrote:

On 3/24/20 17:54, Brian Burch wrote:





So I had the source all along, but never thought to look there!



Seems like another case where the documentation is misleading to
someone who isn't familiar with the current situation. (I'm used
to two other apache projects where all their web site and wiki
source is in one place, although updating it isn't trivial
either!)


Does that project maintain 4 separate simultaneous releases? :)


No, perhaps two, and not all the time!

I had also completely forgotten that tomcat provides its own local 
documentation web pages during installation. If I had remembered, and if 
I had fully appreciated that the pages were release-dependent, then I 
would have realised why the apache tomcat online source needs to be 
segmented.


By way of excuse, I've not needed to work seriously on tomcat for 
several years and at my age stuff just slips away with time!


Thanks for making this clear to me. I really appreciate the considerable 
patient help from my old-time acquaintances!



Few do but we could still update the source page to make it clearer that
the tomcat-X.Y-docs pages are copies of the documentation web app from
the most recent X.Y release.


Leave it to me. I'll work on a couple of changes and post some diffs to 
the dev list soon (days, not weeks, I hope). After that, I'll get back 
to the logging documentation changes.


Brian


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org