You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Farhan Tariq <fa...@gmail.com> on 2017/01/21 07:20:55 UTC

Re: ExtendedAccessLogValve.class overloaded timezone and set it to GMT

hi,

we have tomcat 7.0.68 deployed on linux.

To capture the log in local system timezone using ExtendedAccessLogValve
class we change the following line
"currentTimestampFormat.setTimeZone(TimeZone.getTimeZone("GMT"))"

into
"currentTimestampFormat.setTimeZone(TimeZone.getDefault())"

in ElementTimestampStruct class and then compile and replace the
catalina.jar in already deployed tomcat.

Now , The time is sync with the system set time which is GMT+5 but somehow
date is still operating on GMT as date get changed at 05:00 AM ( system
time). please help me in this regard to understand why the above mentioned
change have no impact of date field.

Regards
Farhan

On Thu, Dec 15, 2016 at 3:31 AM, Konstantin Kolinko <kn...@gmail.com>
wrote:

> 2016-12-14 18:48 GMT+03:00 Farhan Tariq <fa...@gmail.com>:
> > Hello team,
> >
> > I am not sure why the timezone is explicitly set to GMT in
> > ExtendedAccessLogValve class?
> > To capture URL encoded parameters I looking to use this class but need
> help
> > to get time in GMT+5. I am using tomcat 7 on redhat.
> > Any suggestions?
>
>
> 1. Please read the mailing list rules:
> http://tomcat.apache.org/lists.html#tomcat-users
>
> You have not mentioned what exact version of Tomcat you are using (1.)
>
> 2. Use of GMT in ExtendedAccessLogValve is by design.
>
> That valve implements log format specified by "Extended Log File
> Format" specification by W3C, and the specification dictates that the
> time is in GMT.
>
> http://tomcat.apache.org/tomcat-8.5-doc/config/valve.
> html#Extended_Access_Log_Valve
>
> https://www.w3.org/TR/WD-logfile.html
>
>
> It may be good to implement configurable timezone in AccessLogValve
> (currently it uses TimeZone.getDefault()), but I think that
> ExtendedAccessLogValve shall remain with GMT.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: ExtendedAccessLogValve.class overloaded timezone and set it to GMT

Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 24.01.2017 18:07, Farhan Tariq wrote:
> Hello chris,
>
> Yes we are facing the exact behavior as mentioned by you
>
> "2017-01-23 04:59:58 Something happened
> 2017-01-23 04:59:59 Something happened
> 2017-01-24 05:00:00 Something happened
> 2017-01-24 05:00:01 Something happened"
>
> The changes made to set timezone to system default only effective for time.
> We are only operating in GMT+5 and shipping tomcat logs to different
> solutions including SIEM in real-time. So we are purely depending on tomcat
> to write the logs with correct date time at first.

The above is certainly not true, and there is no technical reason why you cannot use a 
filter between the tomcat log and whatever.
You can probably do that in Java also, if you insist on it.
But why make it simple when it can be complicated, he ?

>
> I will try to play around with suggestion recommended by you and will let
> you know about the outcome.
>
> Thanks
> Farhan Tariq
>
> On Mon, Jan 23, 2017 at 8:38 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Farhan,
>>
>> On 1/21/17 2:20 AM, Farhan Tariq wrote:
>>> hi,
>>>
>>> we have tomcat 7.0.68 deployed on linux.
>>>
>>> To capture the log in local system timezone using
>>> ExtendedAccessLogValve class we change the following line
>>> "currentTimestampFormat.setTimeZone(TimeZone.getTimeZone("GMT"))"
>>>
>>> into "currentTimestampFormat.setTimeZone(TimeZone.getDefault())"
>>>
>>> in ElementTimestampStruct class and then compile and replace the
>>> catalina.jar in already deployed tomcat.
>>>
>>> Now , The time is sync with the system set time which is GMT+5 but
>>> somehow date is still operating on GMT as date get changed at 05:00
>>> AM ( system time). please help me in this regard to understand why
>>> the above mentioned change have no impact of date field.
>>
>> Are you saying that at 05:00, the timestamps in your log file look
>> like this:
>>
>> 2017-01-23 04:59:58 Something happened
>> 2017-01-23 04:59:59 Something happened
>> 2017-01-24 05:00:00 Something happened
>> 2017-01-24 05:00:01 Something happened
>>
>> ?
>>
>> What does TimeZone.getDefault() return in your environment?
>>
>> The java.util.Date object in ExtendedAccessLog recons time using only
>> the epoch time (milliseconds since 1970 in GMT), and always deals with
>> it as a long integer value. Only the DateFormat should be making any
>> interpretation at all as to how to format the date.
>>
>> However, the value of that date only changes once per INTERVAL
>> milliseconds, and it changes based upon the GMT date. So your
>> experience is expected given the code.
>>
>> Your attempt to change the time zone to something non-GMT isn't
>> compatible with the performance optimizations that have been made to
>> that class. If you want to completely change the time zone from GMT to
>> e.g. GMT+5, then you'll need to adjust the epoch time stored in
>> currentTimestamp by setting it forward by 5 hours.
>>
>> A single adjustment is not adequate, because the date value coming
>> from the request for logging will be off by 5 hours each time, and
>> that value is used to update the cached value.
>>
>> I don't believe it is going to be easy for you to change the time zone
>> with such a simple change to your code. You will need to add the
>> timezone adjustment each time a calculation is performed. For example:
>>
>> // ExtendedAccessLog.java:217 (tc9/trunk)
>>              long millis = eds.currentTimestamp.getTime();
>>              if (date.getTime() > (TZ_ADJ + millis + INTERVAL -1) ||
>>                      date.getTime() < (TZ_ADJ + millis)) {
>>                  eds.currentTimestamp.setTime(
>>                          date.getTime() - (date.getTime() % INTERVAL) +
>> TZ_ADJ);
>>                  eds.currentTimestampString =
>>
>> eds.currentTimestampFormat.format(eds.currentTimestamp);
>>              }
>>
>> You will have to set the value of TZ_ADJ to be 5hrs, or you could
>> compute it from TimeZone.getDefault(). Note that it won't adjust for
>> DST or anything like that. I'm not sure if that's a problem for you.
>>
>> I'm curious... what's wrong with GMT?
>>
>> - -chris
>>
>>> On Thu, Dec 15, 2016 at 3:31 AM, Konstantin Kolinko
>>> <kn...@gmail.com> wrote:
>>>
>>>> 2016-12-14 18:48 GMT+03:00 Farhan Tariq
>>>> <fa...@gmail.com>:
>>>>> Hello team,
>>>>>
>>>>> I am not sure why the timezone is explicitly set to GMT in
>>>>> ExtendedAccessLogValve class? To capture URL encoded parameters
>>>>> I looking to use this class but need
>>>> help
>>>>> to get time in GMT+5. I am using tomcat 7 on redhat. Any
>>>>> suggestions?
>>>>
>>>>
>>>> 1. Please read the mailing list rules:
>>>> http://tomcat.apache.org/lists.html#tomcat-users
>>>>
>>>> You have not mentioned what exact version of Tomcat you are using
>>>> (1.)
>>>>
>>>> 2. Use of GMT in ExtendedAccessLogValve is by design.
>>>>
>>>> That valve implements log format specified by "Extended Log File
>>>> Format" specification by W3C, and the specification dictates that
>>>> the time is in GMT.
>>>>
>>>> http://tomcat.apache.org/tomcat-8.5-doc/config/valve.
>>>> html#Extended_Access_Log_Valve
>>>>
>>>> https://www.w3.org/TR/WD-logfile.html
>>>>
>>>>
>>>> It may be good to implement configurable timezone in
>>>> AccessLogValve (currently it uses TimeZone.getDefault()), but I
>>>> think that ExtendedAccessLogValve shall remain with GMT.
>>>>
>>>> Best regards, Konstantin Kolinko
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>> -----BEGIN PGP SIGNATURE-----
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJYhiNaAAoJEBzwKT+lPKRYaIIQAJGxF3VN5tfrgtAiAVRHrbCx
>> wAlmCqqLQ/KpFTxh8JQiDFzmjvjGR8HXfZO9G1RkVAl5VcVWQ8RK6jizVaS21Wfi
>> BU5XFWiEz2goV9WpoJF12PUrrUKrvZzMo/n9QIXdWsD/wVFbXnUHPYKhhvIHx8uF
>> TZJRlB2Wav2oCw0gYNG5yMf/B/2afjptonZux3EUWAZHnKzZzvn9+PKVXHcRUWFj
>> ovtoCTG0NbRKAHphqFIHyL45V27JnkT14XGn8bhBdIQLhifhWfJVtu70HbBluol8
>> f80JPMNfB3wTzm+4QTMqTa4ZCYQrrA/s2LPicWJ4vKz0r52jnyKGoPDJKT7oQjEn
>> /ipBO20kH8PGxBjU64wbCEV1KEyCYq1+b/mnlX98KFJudNd4jk30pXAUuxhP2PHv
>> 40GyGWiJ2GGJpzPuh2df0keUbK11JMk4zsq0lSzzfG1ZJuGrey9Eq9kMA92qAv9R
>> es17bwoJPLbKDcY5Ilvi/O8kGU1kjRVrE647KK4HlVIdV8CDMcLLN2xZ4luz7pJL
>> L0FlkCedBvy+sBigXC0TTEJG2RZ2qenOC2hwb81ogSTGZ9AhycrsahqYgbm7x7bS
>> SC3LCu6NNT2+Si9ZIs5DyzdN1fys0ZbRHyMCSM5BQz81NadY8cYiHSHLPS6gRoB8
>> SyuqhSSaHAqeSZKPp2Fh
>> =NXSe
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>


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


Re: ExtendedAccessLogValve.class overloaded timezone and set it to GMT

Posted by Farhan Tariq <fa...@gmail.com>.
Hello chris,

Yes we are facing the exact behavior as mentioned by you

"2017-01-23 04:59:58 Something happened
2017-01-23 04:59:59 Something happened
2017-01-24 05:00:00 Something happened
2017-01-24 05:00:01 Something happened"

The changes made to set timezone to system default only effective for time.
We are only operating in GMT+5 and shipping tomcat logs to different
solutions including SIEM in real-time. So we are purely depending on tomcat
to write the logs with correct date time at first.

I will try to play around with suggestion recommended by you and will let
you know about the outcome.

Thanks
Farhan Tariq

On Mon, Jan 23, 2017 at 8:38 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Farhan,
>
> On 1/21/17 2:20 AM, Farhan Tariq wrote:
> > hi,
> >
> > we have tomcat 7.0.68 deployed on linux.
> >
> > To capture the log in local system timezone using
> > ExtendedAccessLogValve class we change the following line
> > "currentTimestampFormat.setTimeZone(TimeZone.getTimeZone("GMT"))"
> >
> > into "currentTimestampFormat.setTimeZone(TimeZone.getDefault())"
> >
> > in ElementTimestampStruct class and then compile and replace the
> > catalina.jar in already deployed tomcat.
> >
> > Now , The time is sync with the system set time which is GMT+5 but
> > somehow date is still operating on GMT as date get changed at 05:00
> > AM ( system time). please help me in this regard to understand why
> > the above mentioned change have no impact of date field.
>
> Are you saying that at 05:00, the timestamps in your log file look
> like this:
>
> 2017-01-23 04:59:58 Something happened
> 2017-01-23 04:59:59 Something happened
> 2017-01-24 05:00:00 Something happened
> 2017-01-24 05:00:01 Something happened
>
> ?
>
> What does TimeZone.getDefault() return in your environment?
>
> The java.util.Date object in ExtendedAccessLog recons time using only
> the epoch time (milliseconds since 1970 in GMT), and always deals with
> it as a long integer value. Only the DateFormat should be making any
> interpretation at all as to how to format the date.
>
> However, the value of that date only changes once per INTERVAL
> milliseconds, and it changes based upon the GMT date. So your
> experience is expected given the code.
>
> Your attempt to change the time zone to something non-GMT isn't
> compatible with the performance optimizations that have been made to
> that class. If you want to completely change the time zone from GMT to
> e.g. GMT+5, then you'll need to adjust the epoch time stored in
> currentTimestamp by setting it forward by 5 hours.
>
> A single adjustment is not adequate, because the date value coming
> from the request for logging will be off by 5 hours each time, and
> that value is used to update the cached value.
>
> I don't believe it is going to be easy for you to change the time zone
> with such a simple change to your code. You will need to add the
> timezone adjustment each time a calculation is performed. For example:
>
> // ExtendedAccessLog.java:217 (tc9/trunk)
>             long millis = eds.currentTimestamp.getTime();
>             if (date.getTime() > (TZ_ADJ + millis + INTERVAL -1) ||
>                     date.getTime() < (TZ_ADJ + millis)) {
>                 eds.currentTimestamp.setTime(
>                         date.getTime() - (date.getTime() % INTERVAL) +
> TZ_ADJ);
>                 eds.currentTimestampString =
>
> eds.currentTimestampFormat.format(eds.currentTimestamp);
>             }
>
> You will have to set the value of TZ_ADJ to be 5hrs, or you could
> compute it from TimeZone.getDefault(). Note that it won't adjust for
> DST or anything like that. I'm not sure if that's a problem for you.
>
> I'm curious... what's wrong with GMT?
>
> - -chris
>
> > On Thu, Dec 15, 2016 at 3:31 AM, Konstantin Kolinko
> > <kn...@gmail.com> wrote:
> >
> >> 2016-12-14 18:48 GMT+03:00 Farhan Tariq
> >> <fa...@gmail.com>:
> >>> Hello team,
> >>>
> >>> I am not sure why the timezone is explicitly set to GMT in
> >>> ExtendedAccessLogValve class? To capture URL encoded parameters
> >>> I looking to use this class but need
> >> help
> >>> to get time in GMT+5. I am using tomcat 7 on redhat. Any
> >>> suggestions?
> >>
> >>
> >> 1. Please read the mailing list rules:
> >> http://tomcat.apache.org/lists.html#tomcat-users
> >>
> >> You have not mentioned what exact version of Tomcat you are using
> >> (1.)
> >>
> >> 2. Use of GMT in ExtendedAccessLogValve is by design.
> >>
> >> That valve implements log format specified by "Extended Log File
> >> Format" specification by W3C, and the specification dictates that
> >> the time is in GMT.
> >>
> >> http://tomcat.apache.org/tomcat-8.5-doc/config/valve.
> >> html#Extended_Access_Log_Valve
> >>
> >> https://www.w3.org/TR/WD-logfile.html
> >>
> >>
> >> It may be good to implement configurable timezone in
> >> AccessLogValve (currently it uses TimeZone.getDefault()), but I
> >> think that ExtendedAccessLogValve shall remain with GMT.
> >>
> >> Best regards, Konstantin Kolinko
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYhiNaAAoJEBzwKT+lPKRYaIIQAJGxF3VN5tfrgtAiAVRHrbCx
> wAlmCqqLQ/KpFTxh8JQiDFzmjvjGR8HXfZO9G1RkVAl5VcVWQ8RK6jizVaS21Wfi
> BU5XFWiEz2goV9WpoJF12PUrrUKrvZzMo/n9QIXdWsD/wVFbXnUHPYKhhvIHx8uF
> TZJRlB2Wav2oCw0gYNG5yMf/B/2afjptonZux3EUWAZHnKzZzvn9+PKVXHcRUWFj
> ovtoCTG0NbRKAHphqFIHyL45V27JnkT14XGn8bhBdIQLhifhWfJVtu70HbBluol8
> f80JPMNfB3wTzm+4QTMqTa4ZCYQrrA/s2LPicWJ4vKz0r52jnyKGoPDJKT7oQjEn
> /ipBO20kH8PGxBjU64wbCEV1KEyCYq1+b/mnlX98KFJudNd4jk30pXAUuxhP2PHv
> 40GyGWiJ2GGJpzPuh2df0keUbK11JMk4zsq0lSzzfG1ZJuGrey9Eq9kMA92qAv9R
> es17bwoJPLbKDcY5Ilvi/O8kGU1kjRVrE647KK4HlVIdV8CDMcLLN2xZ4luz7pJL
> L0FlkCedBvy+sBigXC0TTEJG2RZ2qenOC2hwb81ogSTGZ9AhycrsahqYgbm7x7bS
> SC3LCu6NNT2+Si9ZIs5DyzdN1fys0ZbRHyMCSM5BQz81NadY8cYiHSHLPS6gRoB8
> SyuqhSSaHAqeSZKPp2Fh
> =NXSe
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: ExtendedAccessLogValve.class overloaded timezone and set it to GMT

Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 23.01.2017 16:38, Christopher Schultz wrote:
> I'm curious... what's wrong with GMT?

I have been wondering about that too.  It seems a rather bad idea to me, as it brings 
potential problems of compatibility with log-exploiting programs, hosting servers 
somewhere else, comparing time between different computers and applications etc.
Not even mentioning issues of future tomcat updates, re-calculating the times when users 
send problem reports and so on.

Would it not be better if it was an external utility which reads the logs, that makes any 
adjustments required ?
I'd bet that some external perl script, 10 lines max, would filter these files in no time 
at all.


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


Re: ExtendedAccessLogValve.class overloaded timezone and set it to GMT

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Farhan,

On 1/21/17 2:20 AM, Farhan Tariq wrote:
> hi,
> 
> we have tomcat 7.0.68 deployed on linux.
> 
> To capture the log in local system timezone using
> ExtendedAccessLogValve class we change the following line 
> "currentTimestampFormat.setTimeZone(TimeZone.getTimeZone("GMT"))"
> 
> into "currentTimestampFormat.setTimeZone(TimeZone.getDefault())"
> 
> in ElementTimestampStruct class and then compile and replace the 
> catalina.jar in already deployed tomcat.
> 
> Now , The time is sync with the system set time which is GMT+5 but
> somehow date is still operating on GMT as date get changed at 05:00
> AM ( system time). please help me in this regard to understand why
> the above mentioned change have no impact of date field.

Are you saying that at 05:00, the timestamps in your log file look
like this:

2017-01-23 04:59:58 Something happened
2017-01-23 04:59:59 Something happened
2017-01-24 05:00:00 Something happened
2017-01-24 05:00:01 Something happened

?

What does TimeZone.getDefault() return in your environment?

The java.util.Date object in ExtendedAccessLog recons time using only
the epoch time (milliseconds since 1970 in GMT), and always deals with
it as a long integer value. Only the DateFormat should be making any
interpretation at all as to how to format the date.

However, the value of that date only changes once per INTERVAL
milliseconds, and it changes based upon the GMT date. So your
experience is expected given the code.

Your attempt to change the time zone to something non-GMT isn't
compatible with the performance optimizations that have been made to
that class. If you want to completely change the time zone from GMT to
e.g. GMT+5, then you'll need to adjust the epoch time stored in
currentTimestamp by setting it forward by 5 hours.

A single adjustment is not adequate, because the date value coming
from the request for logging will be off by 5 hours each time, and
that value is used to update the cached value.

I don't believe it is going to be easy for you to change the time zone
with such a simple change to your code. You will need to add the
timezone adjustment each time a calculation is performed. For example:

// ExtendedAccessLog.java:217 (tc9/trunk)
            long millis = eds.currentTimestamp.getTime();
            if (date.getTime() > (TZ_ADJ + millis + INTERVAL -1) ||
                    date.getTime() < (TZ_ADJ + millis)) {
                eds.currentTimestamp.setTime(
                        date.getTime() - (date.getTime() % INTERVAL) +
TZ_ADJ);
                eds.currentTimestampString =

eds.currentTimestampFormat.format(eds.currentTimestamp);
            }

You will have to set the value of TZ_ADJ to be 5hrs, or you could
compute it from TimeZone.getDefault(). Note that it won't adjust for
DST or anything like that. I'm not sure if that's a problem for you.

I'm curious... what's wrong with GMT?

- -chris

> On Thu, Dec 15, 2016 at 3:31 AM, Konstantin Kolinko
> <kn...@gmail.com> wrote:
> 
>> 2016-12-14 18:48 GMT+03:00 Farhan Tariq
>> <fa...@gmail.com>:
>>> Hello team,
>>> 
>>> I am not sure why the timezone is explicitly set to GMT in 
>>> ExtendedAccessLogValve class? To capture URL encoded parameters
>>> I looking to use this class but need
>> help
>>> to get time in GMT+5. I am using tomcat 7 on redhat. Any
>>> suggestions?
>> 
>> 
>> 1. Please read the mailing list rules: 
>> http://tomcat.apache.org/lists.html#tomcat-users
>> 
>> You have not mentioned what exact version of Tomcat you are using
>> (1.)
>> 
>> 2. Use of GMT in ExtendedAccessLogValve is by design.
>> 
>> That valve implements log format specified by "Extended Log File 
>> Format" specification by W3C, and the specification dictates that
>> the time is in GMT.
>> 
>> http://tomcat.apache.org/tomcat-8.5-doc/config/valve. 
>> html#Extended_Access_Log_Valve
>> 
>> https://www.w3.org/TR/WD-logfile.html
>> 
>> 
>> It may be good to implement configurable timezone in
>> AccessLogValve (currently it uses TimeZone.getDefault()), but I
>> think that ExtendedAccessLogValve shall remain with GMT.
>> 
>> Best regards, Konstantin Kolinko
>> 
>> ---------------------------------------------------------------------
>>
>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>> 
>> 
> 
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYhiNaAAoJEBzwKT+lPKRYaIIQAJGxF3VN5tfrgtAiAVRHrbCx
wAlmCqqLQ/KpFTxh8JQiDFzmjvjGR8HXfZO9G1RkVAl5VcVWQ8RK6jizVaS21Wfi
BU5XFWiEz2goV9WpoJF12PUrrUKrvZzMo/n9QIXdWsD/wVFbXnUHPYKhhvIHx8uF
TZJRlB2Wav2oCw0gYNG5yMf/B/2afjptonZux3EUWAZHnKzZzvn9+PKVXHcRUWFj
ovtoCTG0NbRKAHphqFIHyL45V27JnkT14XGn8bhBdIQLhifhWfJVtu70HbBluol8
f80JPMNfB3wTzm+4QTMqTa4ZCYQrrA/s2LPicWJ4vKz0r52jnyKGoPDJKT7oQjEn
/ipBO20kH8PGxBjU64wbCEV1KEyCYq1+b/mnlX98KFJudNd4jk30pXAUuxhP2PHv
40GyGWiJ2GGJpzPuh2df0keUbK11JMk4zsq0lSzzfG1ZJuGrey9Eq9kMA92qAv9R
es17bwoJPLbKDcY5Ilvi/O8kGU1kjRVrE647KK4HlVIdV8CDMcLLN2xZ4luz7pJL
L0FlkCedBvy+sBigXC0TTEJG2RZ2qenOC2hwb81ogSTGZ9AhycrsahqYgbm7x7bS
SC3LCu6NNT2+Si9ZIs5DyzdN1fys0ZbRHyMCSM5BQz81NadY8cYiHSHLPS6gRoB8
SyuqhSSaHAqeSZKPp2Fh
=NXSe
-----END PGP SIGNATURE-----

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