-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 12/11/19 13:01, Mark Thomas wrote:
> On 11/12/2019 17:43, Christopher Schultz wrote:
>
> <snip/>
>
>>> I'm not sure why we need this over and above the RequestFacade
>>> object.
>>
>> The RequestFacade is intended to protect the container from the
>> application, right?
>
> It can cut both ways.
>
>> And they are (usually) re-used. If a RequestFacade object is
>> retained by the application and used later, a later
>> client-request may be confused with the one the application was
>> expectin g> In the solution I presented, the facades are one-time
>> use and will stay dead once they are killed. The application
>> can't make a mistake and read a later client-request or write to
>> a later client-response.
>
> Setting RECYCLE_FACADES=true does exactly that. Continued used by
> the app triggers an NPE since the underlying request/response is no
> longer there. Hence my question.
RequestFacade currently has a number of methods that perform
null-checks on the "request" member, but not all methods do this. Exampl
e:
@Override
public ServletContext getServletContext() {
if (request == null) {
throw new IllegalStateException(
sm.getString("requestFacade.nullRequest"));
}
return request.getServletContext();
}
Negative example:
@Override
public AsyncContext startAsync() throws IllegalStateException {
return request.startAsync();
}
Should these be aligned?
It seems to me that if recycleFacades="false" then there really isn't
any reason to wrap the request (response, etc.) in a facade object at
all, is there? Is there any opportunity to further reduce memory
footprint by just NOT creating these objects at all?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3xQK4ACgkQHPApP6U8
pFjeYg/+MBc+iKgAtAmlf6D6MzgODhoGmGwibpPxsyssQ4jcmLPGUtwF/SVR5wtD
5QI+Nk3waVO0m9AUas0dSbEZnqYXrj0/yIqg2f8IpjKhwfayHfc0XQ7h+NMffK3o
WFpgFmIHb6L1nKBz7UCdLh4aAP4+AYzVH/yaw7aHNa1etZ4BH8CFcnEuzeaezU34
X5pYvP1vKtGae5kv5TuDKPll6UeA3xBSHhj6IJI8CSSwazPnOiwOITMPftCiAQ/3
qE4wR9AcYtdG8w+szAgpSIDkwqkEWGCTDtwxaTpfb4QZoxSCAcLRI8kYoUDkwV/u
lPgV647lM619r5yeEJ/aLaH/b11mr3dgWustu1+N7xupyosCLpgaRdbsr6ZBu+WY
ITalE2BSNMfjrV9RI45SVGfnWQ8RHzbmt9d5+oOyzo434zIx9pYY7IUEk8mSQ513
eb/D4Ap5BI2M2niOrVs6RnV9WEkvHdYq0/R23xO8LsmyyuAlBS3HuNrnK15z7Yva
a2FhZSSD7guPUXQWgB78HhabfhpvYSwVL/T5oghYMe3Q13Q6NMoY/lbzb7GEmZyr
FZy1sTnPXb0ScApqHVhKkXUgmWck/x/WDtsGf7NeGZV0uNQsLrdSURxCv1kbwlND
GajyDd4stFGPlJx5ycb7ci6vZqVqNGCTWgED/jPQNkGHGbiIgU4=
=Ygte
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
