Trevor Grant has shared a document on Google Docs with you

[trevor . d . grant]

Trevor Grant has invited you to view the following document:

Open in Docs

Re: Access hidden fields array

[Tobias Soloschenko]

Hi,

thanks a lot for the clarification. I changed the implementation to access the 
parameter with brackets, now. Everything is working like expected.

kind regards

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

Re: Access hidden fields array

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Tobias,

On 5/3/17 6:48 AM, Tobias Soloschenko wrote:
> The reason why I used the brackets was that in some cases
> (browsers) only the first value was returned. (Even if there were
> more then one hidden field with that name)

This is incorrect. Browsers don't have a high-level API for
manipulating URLs, parameters, etc. If you are using a toolkit, it may
add these restrictions, but the browser has nothing to do with it.

> Also mentioned here: http://stackoverflow.com/a/6547234 - PHP is
> also resolving the variable without brackets.

PHP uses the "[]" suffix to indicate that a parameter name is expected
to have multiple values, and expose those values to the PHP script as
an array (instead of returning e.g. only the first value encountered).

> There are various other questions at stackoverflow mentioning to
> get the variable without brackets:
> 
> http://stackoverflow.com/questions/6547209/passing-array-using-html-fo
rm-hidden-element
>
> 
http://stackoverflow.com/questions/4237090/how-to-pass-array-through-hid
den-field
> http://stackoverflow.com/questions/29076219/javascript-storing-array-o
f-objects-in-hidden-field
>
>  Don't know if this should be supported.

The servlet spec is clear: the name of the parameter is the name of
the parameter from the HTTP request. If you decide to name your
parameter "array[]", then you must access it using "array[]".

If you want to use a framework that adds that kind of interpretation,
you are welcome to do so, but Tomcat will never add anything like that.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZCeZ+AAoJEBzwKT+lPKRYo3YP+gPNiJbe0zeTrowUnsKxiViI
0dBZqQwm4XLqxVPNobixQQ1Su0uKSfBCesQwrdhVZCBRGKb8DO5UvSxvWUexr84I
GFfNObXiZD9b0pf9JRGNjlrBT4EA8/ehWGCqgVT1cqUfme2GtPp5Km9ODjqzwhKO
XKhXSuBhO1weg948hNd0W1nrYfWd632FoWiLXVbiXERlsD4s5eTakgrkQkaf9NA0
meEbOFqvvNinU73Z2rLql0S3s4dW7UVlUNKqRK+yaWEM73RE8Ij985uXQAuiPOYz
LNdauOkFo9SshpEmAOGGN/TVCowqGKhkEcVL2Jo49oU0lGxyJJGkgtOrQwnWQsHy
3iJhVvV2AWTwN5ICevZ183oNSYDFALisIExuQmMoCg6aKIhHl4l9KccC+DMgpmZp
kAiGqJAIHzJOFcxXuP8gVuefmPJn4pfTA9ZN2yEFbWAwJm8IB6osadjfUTLwAdHz
dTBn1BtkcoB+cC3eiHmOnpigtkbHb7/j9Oeud3tCCuyvyA8ykKzPm4glkTq+heN4
yNvsGdBGthG7IdVHDaOptm8TGoWf9Q6r9k/jpkyl3DYInFm8D1m+UWJpSpaFwL+d
vHaZUAJTw/F1UQaoFCIShPca7ncNjNy/P3EERw07unHdynVtwGzDr3eKqBn73ehA
2cl2EUS9mgegSz/0/U2V
=H+SQ
-END PGP SIGNATURE-

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

Re: /.well-known Hidden directory url returns 404

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ian,

On 5/2/17 2:15 PM, Ian Brown wrote:
> Solved/Worked-around !! (Although there might be a better way) Many
> Thanks to Mark and Christopher!
> 
> As Mark indicated the solution is very simple, but what worked on
> my system is slightly, but critically different than what works on
> Mark's.
> 
> Mark's solution/system: cd webapps/ROOT mkdir .well-known
> 
> I have multiple virtual hosts with multiple apps but what I think
> would work on mine (extrapolated from below) is

Hmm, multiple VHs will definitely be a problem, unless you either have
separate appbase directories (.well-known in each one) or ...
something very complicated. Do you have to allow users/apps to specify
their own certs, or are you king of the whole castle?

> cd webapps mkdir .well-known In other words /ROOT and /.well-known
> are at the same level under webapps/
> 
> Here is what appears to work for me:
> 
> With virtual hosts create the directories for each host you want to
> secure  ~/webapps/hosteddomain.tld/.well-known and
> ~/webapps/hosteddomain.tld/.well-known/acme-challenge replacing
> /hosteddomain.tld with the appropriate domain name.
> 
> If you have multiple apps for multiple hosts your directory
> structure should follow this pattern. host1.tld/ROOT/ 
> host1.tld/app1/ host1.tld/.well-known/acme-challenge/ 
> host2.tld/ROOT/ host2.tld/app1/ 
> host2.tld/.well-known/acme-challenge/

That will work.

> Why it is not obvious to me: I expected all urls to be routed with
> the same rules, but that is not what happens. Hidden directories
> are routed differently (on my system).

That should not happen. Remember: there is no such thing as a "hidden
directory".

> In my earlier example where I had www.mydomain.tld/stats/ 
> www.mydomain.tld/.well-known/acme-challenge/test.html 1- the stats
> directory was routed to: contextPath= ,
> servletPath=/stats/index.html 2- the .well-knowndirectory was
> routed to: contextPath=/.well-known,
> servletPath=/acme-challenge/test.html

That's what I'd expect.

> In directory terms I expected /stats/index.html
> to map to: www.mydomain.tld/ROOT/stats/index.html

If you have a /stats application, then the URL will be routed there.

Once an application has been selected based upon context-path match
(e.g. /stats) Tomcat won't check any other application. So if you have
application /stats and look for /stats/no-file.html you'll get a 404
even if ROOT/stats/no-file.html exists.

> /.well-known/acme-challenge/test.htmlto map to:
> www.mydomain.tld/ROOT/.well-known/acme-challenge/test.html What I
> get is /stats/index.html
> maps to: www.mydomain.tld/ROOT/stats/index.html 
> /.well-known/acme-challenge/test.htmlmaps to:
> www.mydomain.tld/.well-known/acme-challenge/test.html

You haven't told us what apps you have configured, so it's tough to
tell what "should" be happening.

> Christopher: Would love to hear your talk & meet, but I won't be at
> the conference. Thanks for the invitation. We absolutely need a
> certbot-auto for tomcat.

My goal is to create a script that someone with certbot expertise can
use to roll-into certbot.

> There a lots of problem reports on the web for getting the
> certificate request verified under Tomcat.

I think that's because lots of people (a) don't understand the
issuance model for LE or (b) don't really know how to configure
Tomcat. It's dead simple to get LE to issue a certificate using only
Tomcat and a properly-configured DNS name.

> The main solution is to put Apache httpd in front of Tomcat so the 
> url gets routed to the right directory. So I think you will be
> seeing this issue again.
If you have httpd our front, then issuing a certificate for Tomcat is
completely unnecessary, and it's just an academic exercise. Certbot,
for instance, can self-host a web server, so if you are going to
stand-up httpd just for LE cert issuance, then just allow certbot to
host itself instead.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZCeVpAAoJEBzwKT+lPKRYiyAP/0QujIQD6pibcCzsqgl2TIZF
x2jgUkCxzTLZ4BjFOlT03IAbrgLcQd928iy8JxrYepNLYq19VSZUDccex7e8pynO
mWoAgx0MVB8e5CR+UuMq5B9oJ7H2aA/+ARWYl9mpRrT9rRy/187ATcwA1Y5eQcrP
MOSguwt7vpRqBaX925cp/DbAeV6G5P62Wfxd/MKMaX57heC5jICmI085XGGBkeLF
XIJhtmzh7fYD/zAJsISjrDuhNeOv1X8ObsJ4po+IYkEIMHTu9DWNchZfIPUFrhqi
InKsM/yeLmA2eSK8WhrJwvfuXvdv88TC+admQWHlwJXnfbQDsxYVH11PulWqkSAk
9/W7YQ0uakgS6qE1OoHACgAUGxP0lYekLtExPNCHtgBIuSmD+hRPgG54hLm0c/q1
uPIFxvhKu/7gFBdkbGi0icOAkjLwE+fnXYwzUMClT2oHLK3Z2wByxizbQeJlQB4R
mp54XzTh4tMSEsEYmGd1s/x7P6QiFWT31iRLbXpRbHJO1HyYT+ea8j5Aioki0J4h
iyy9KnxecoZomDNoUfOmk/c/+fTIuDvVnSVlK+2Ol0EwYHAZv3+UrQK5WFy/C+KD
Vxk97pxyE3mXWolHuFvzjfiClhCuWGzzJQYOaESal3JmA+zlnC2QZQOv/50sxIqs
olUmniCCe41bIOvIWGXq
=PcH6
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@to

Re: Access hidden fields array

[tomcat]

Hi again.

First, on this list please do not top-post.
See : http://tomcat.apache.org/lists.html#tomcat-users
  Important --> 6

I have reformated your message according to that.
>

2017-05-03 12:05 GMT+02:00 André Warnier (tomcat) :


On 03.05.2017 11:23, Tobias Soloschenko wrote:


Hello everyone,

I just updated to tomcat 8.0.43 and I noticed a special behavior I want to
discuss. (I don't know if this only occurs with this version)

When I add two hidden fields within a form like:






I just thought to access the parameter values within the java api like

String[] myArray = httpServletRequest.getParameterValues("array");


In my case however I just can access them like (with brackets):

String[] myArray = httpServletRequest.getParameterValues("array[]");


This also applies to httpServletRequest.getParameterMap().containsKey


Is this an expected behavior?




I would tend to say : yes, it is expected.
(This also has nothing to do with tomcat per se, and is more of the domain
of the HTML and HTTP specifications).

I have not checked the relevant HTML/HTTP specs to verify which characters
precisely are allowed in the "name" attribute of a HTML  field.
But assuming that "[" and "]" /are/ allowed in such attributes, then that
is the name under which the value of this parameter will be sent by the
browser to the server.

More precisely : if you have in your form an  element such as :



(whatever "xyz[123abc]" may be, in terms of valid characters)
then "xyz[123abc]" is the name/label of this parameter, and the browser
will send the corresponding input field value to the server as something
like :

xyz[123abc]=1

The fact that this label /resembles/ the way in which you would invoke an
array in Java (or any other server-side programming language) is pure
coincidence.

In other words again, in your above example, if you replaced "array[]" by
"array][" (or "array)(", or "array(xyz)" or "variable#1") everywhere, it
would work just the same. It's just a label.

And the fact that in your example they are seen as an array on the java
side, is just because there is more than one value sent by the browser with
that same label, and the POST parsing logic on the server side then makes
this into an array of values.

This all being said, I would not name any input fields in a form with a
name like "array[]". That is bound to create confusion, as you yourself can
now attest.
You can name is "ferrari" instead; but that does not mean that on the
server side, you should expect something red with 4 wheels and 12 cylinders.




On 03.05.2017 12:48, Tobias Soloschenko wrote:

Hi,

thanks for the detailed answer.

The reason why I used the brackets was that in some cases (browsers) only
the first value was returned. (Even if there were more then one hidden
field with that name)

Also mentioned here: http://stackoverflow.com/a/6547234 - PHP is also
resolving the variable without brackets.

There are various other questions at stackoverflow mentioning to get the
variable without brackets:

http://stackoverflow.com/questions/6547209/passing-array-using-html-form-hidden-element
http://stackoverflow.com/questions/4237090/how-to-pass-array-through-hidden-field
http://stackoverflow.com/questions/29076219/javascript-storing-array-of-objects-in-hidden-field

Don't know if this should be supported.



There is something confusing in your posts so far.
This is a Tomcat user's list. Tomcat is a Java Servlet Engine, written in Java.
Your example above also seemed to be Java.
But the links you propose above all relate to PHP applications, and they are a bit 
confusing (and sometimes also confused) themselves.
I mean, there is some information in them that may be relevant to your issue, but also a 
lot of noise that is irrelevant here.


There are 3 parts to your issue :
1) how the HTML form is generated, before it is sent to the browser
2) once it is "in" the browser, what the  looks like (in terms of input fields and 
values), and how its content will be sent to the server when the user presses the submit 
button
3) the application, on the server side, which will parse this POST content, and how the 
data will look to it


Only (3) is really relevant on this list.

And as far as that is concerned :

A) if your  contains 3 input elements like
 
 
 

then what the browser sends to the server (in one way or another), will look 
like

f1=1
f1=2
f1=3

and, in a Java application on the server, to get these values you would use 
something like :

String[] myArray = httpServletRequest.getParameterValues("f1");

and in myArray, you would get [ "1", "2", "3" ]

and this is true whatever the name "f1" would be replaced by, in the  as well as in 
the Java code.


B) if your  contains 3 input elements like




then what the browser sends to the server (in one way or another), will look 
like

f1=1
f2=2
f3=3

then, in the Java application on the server, if you use something like :

String[] myArray = httpServletRequest.getParameterValues("f1");

in my

Re: Access hidden fields array

[Tobias Soloschenko]

Hi,

thanks for the detailed answer.

The reason why I used the brackets was that in some cases (browsers) only
the first value was returned. (Even if there were more then one hidden
field with that name)

Also mentioned here: http://stackoverflow.com/a/6547234 - PHP is also
resolving the variable without brackets.

There are various other questions at stackoverflow mentioning to get the
variable without brackets:

http://stackoverflow.com/questions/6547209/passing-array-using-html-form-hidden-element
http://stackoverflow.com/questions/4237090/how-to-pass-array-through-hidden-field
http://stackoverflow.com/questions/29076219/javascript-storing-array-of-objects-in-hidden-field

Don't know if this should be supported.

kind regards

Tobias

2017-05-03 12:05 GMT+02:00 André Warnier (tomcat) :

> On 03.05.2017 11:23, Tobias Soloschenko wrote:
>
>> Hello everyone,
>>
>> I just updated to tomcat 8.0.43 and I noticed a special behavior I want to
>> discuss. (I don't know if this only occurs with this version)
>>
>> When I add two hidden fields within a form like:
>>
>> 
>>
>> 
>>
>>
>> I just thought to access the parameter values within the java api like
>>
>> String[] myArray = httpServletRequest.getParameterValues("array");
>>
>>
>> In my case however I just can access them like (with brackets):
>>
>> String[] myArray = httpServletRequest.getParameterValues("array[]");
>>
>>
>> This also applies to httpServletRequest.getParameterMap().containsKey
>>
>>
>> Is this an expected behavior?
>>
>>
>>
> I would tend to say : yes, it is expected.
> (This also has nothing to do with tomcat per se, and is more of the domain
> of the HTML and HTTP specifications).
>
> I have not checked the relevant HTML/HTTP specs to verify which characters
> precisely are allowed in the "name" attribute of a HTML  field.
> But assuming that "[" and "]" /are/ allowed in such attributes, then that
> is the name under which the value of this parameter will be sent by the
> browser to the server.
>
> More precisely : if you have in your form an  element such as :
>
> 
>
> (whatever "xyz[123abc]" may be, in terms of valid characters)
> then "xyz[123abc]" is the name/label of this parameter, and the browser
> will send the corresponding input field value to the server as something
> like :
>
> xyz[123abc]=1
>
> The fact that this label /resembles/ the way in which you would invoke an
> array in Java (or any other server-side programming language) is pure
> coincidence.
>
> In other words again, in your above example, if you replaced "array[]" by
> "array][" (or "array)(", or "array(xyz)" or "variable#1") everywhere, it
> would work just the same. It's just a label.
>
> And the fact that in your example they are seen as an array on the java
> side, is just because there is more than one value sent by the browser with
> that same label, and the POST parsing logic on the server side then makes
> this into an array of values.
>
> This all being said, I would not name any input fields in a form with a
> name like "array[]". That is bound to create confusion, as you yourself can
> now attest.
> You can name is "ferrari" instead; but that does not mean that on the
> server side, you should expect something red with 4 wheels and 12 cylinders.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Access hidden fields array

[tomcat]

On 03.05.2017 11:23, Tobias Soloschenko wrote:

Hello everyone,

I just updated to tomcat 8.0.43 and I noticed a special behavior I want to
discuss. (I don't know if this only occurs with this version)

When I add two hidden fields within a form like:






I just thought to access the parameter values within the java api like

String[] myArray = httpServletRequest.getParameterValues("array");


In my case however I just can access them like (with brackets):

String[] myArray = httpServletRequest.getParameterValues("array[]");


This also applies to httpServletRequest.getParameterMap().containsKey


Is this an expected behavior?




I would tend to say : yes, it is expected.
(This also has nothing to do with tomcat per se, and is more of the domain of the HTML and 
HTTP specifications).


I have not checked the relevant HTML/HTTP specs to verify which characters precisely are 
allowed in the "name" attribute of a HTML  field.
But assuming that "[" and "]" /are/ allowed in such attributes, then that is the name 
under which the value of this parameter will be sent by the browser to the server.


More precisely : if you have in your form an  element such as :



(whatever "xyz[123abc]" may be, in terms of valid characters)
then "xyz[123abc]" is the name/label of this parameter, and the browser will send the 
corresponding input field value to the server as something like :


xyz[123abc]=1

The fact that this label /resembles/ the way in which you would invoke an array in Java 
(or any other server-side programming language) is pure coincidence.


In other words again, in your above example, if you replaced "array[]" by "array][" (or 
"array)(", or "array(xyz)" or "variable#1") everywhere, it would work just the same. It's 
just a label.


And the fact that in your example they are seen as an array on the java side, is just 
because there is more than one value sent by the browser with that same label, and the 
POST parsing logic on the server side then makes this into an array of values.


This all being said, I would not name any input fields in a form with a name like 
"array[]". That is bound to create confusion, as you yourself can now attest.
You can name is "ferrari" instead; but that does not mean that on the server side, you 
should expect something red with 4 wheels and 12 cylinders.



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

Access hidden fields array

[Tobias Soloschenko]

Hello everyone,

I just updated to tomcat 8.0.43 and I noticed a special behavior I want to
discuss. (I don't know if this only occurs with this version)

When I add two hidden fields within a form like:






I just thought to access the parameter values within the java api like

String[] myArray = httpServletRequest.getParameterValues("array");


In my case however I just can access them like (with brackets):

String[] myArray = httpServletRequest.getParameterValues("array[]");


This also applies to httpServletRequest.getParameterMap().containsKey


Is this an expected behavior?


kind regards and thanks in advance

Tobias

Re: http to https redirect 301

[tomcat]

On 03.05.2017 09:23, Yuval Schwartz wrote:

Thanks, comments below.

On Tue, May 2, 2017 at 10:43 AM, Mark Thomas  wrote:


On 02/05/2017 07:51, Yuval Schwartz wrote:

Thanks, remarks below.

On Tue, May 2, 2017 at 12:12 AM, Mark Thomas  wrote:


On 01/05/17 14:23, Yuval Schwartz wrote:

Tomcat version: 8.0.22
jdk: 1.8.0_05

I have a webapp that uses a tomcat server behind a load balancer.

I recently added a the option to connect to my webapp via https.

I would like to redirect all http requests to https.
I achieved this by implementing the instruction outlined here:
https://elastx.zendesk.com/hc/en-us/articles/214238826-

Force-https-with-Tomcat


However, I notice that this performs a redirect with repsonse code 302
(moved temporarily). I would like the response code to be 301.

I found this bug report on the matter:
https://bz.apache.org/bugzilla/show_bug.cgi?id=59399

Does this mean that in order to achieve a 301 redirect, I need to

update

my

tomcat version?


Yes.



Will this automatically make the redirect use a 301 response code, or is
there a setting that I need to set?


https://tomcat.apache.org/tomcat-8.0-doc/config/realm.
html#Common_Attributes
transportGuaranteeRedirectStatus


Is there anyway to achieve a 301 redirect without updating
the tomcat version?


Without patching Tomcat, no. And that isn't recommended.




Just to be clear, what "isn't recommended"? Not upgrading regularly?


Double negative interrogative forms are hard to answer.
What is not recommended is patching tomcat, for the reason detailed in Mark's next 
paragraph below : new minor releases would overwrite your patch.
What is recommended is to keep your tomcat installation such, that installing a new minor 
release does not cause grief.
There is information about that in the "/RUNNING.txt" file which comes with every tomcat 
release.









I actually didn't know that I should be updating minor versions

regularly.

Is there any recommendation as to the frequency that I should be doing

this?

There is no fixed recommendation. However, the Tomcat team does not
produce patch releases, only new minor versions. It comes down to
whenever there is a bug or security vulnerability fixed that you care
about.

Mark



Thank you.









Mark



Thank you.





-
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







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

Re: http to https redirect 301

[Yuval Schwartz]

Thanks, comments below.

On Tue, May 2, 2017 at 10:43 AM, Mark Thomas  wrote:

> On 02/05/2017 07:51, Yuval Schwartz wrote:
> > Thanks, remarks below.
> >
> > On Tue, May 2, 2017 at 12:12 AM, Mark Thomas  wrote:
> >
> >> On 01/05/17 14:23, Yuval Schwartz wrote:
> >>> Tomcat version: 8.0.22
> >>> jdk: 1.8.0_05
> >>>
> >>> I have a webapp that uses a tomcat server behind a load balancer.
> >>>
> >>> I recently added a the option to connect to my webapp via https.
> >>>
> >>> I would like to redirect all http requests to https.
> >>> I achieved this by implementing the instruction outlined here:
> >>> https://elastx.zendesk.com/hc/en-us/articles/214238826-
> >> Force-https-with-Tomcat
> >>>
> >>> However, I notice that this performs a redirect with repsonse code 302
> >>> (moved temporarily). I would like the response code to be 301.
> >>>
> >>> I found this bug report on the matter:
> >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
> >>>
> >>> Does this mean that in order to achieve a 301 redirect, I need to
> update
> >> my
> >>> tomcat version?
> >>
> >> Yes.
> >>
> >
> > Will this automatically make the redirect use a 301 response code, or is
> > there a setting that I need to set?
>
> https://tomcat.apache.org/tomcat-8.0-doc/config/realm.
> html#Common_Attributes
> transportGuaranteeRedirectStatus
>
> >>> Is there anyway to achieve a 301 redirect without updating
> >>> the tomcat version?
> >>
> >> Without patching Tomcat, no. And that isn't recommended.
>

Just to be clear, what "isn't recommended"? Not upgrading regularly?


> >>
> >>
> > I actually didn't know that I should be updating minor versions
> regularly.
> > Is there any recommendation as to the frequency that I should be doing
> this?
>
> There is no fixed recommendation. However, the Tomcat team does not
> produce patch releases, only new minor versions. It comes down to
> whenever there is a bug or security vulnerability fixed that you care
> about.
>
> Mark
>

Thank you.


>
>
> >
> >
> >> Mark
> >>
> >
> > Thank you.
> >
> >
> >>
> >>
> >> -
> >> 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
>
>