Tomcat 8.5.32 parseHost error

[Daniel Savard]

Hi everyone,

I just upgraded from Tomcat 8.5.23 to 8.5.32 following the required action
on the last CVE issued and I am running into a problem with some
applications. Here is the output from the catalina.out log.

24-Jul-2018 17:02:49.867 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in 44025 ms
24-Jul-2018 17:02:50.368 INFO [https-jsse-nio-8443-exec-17]
org.apache.coyote.AbstractProcessor.parseHost The host [] is not valid
 Note: further occurrences of request parsing errors will be logged at
DEBUG level.
 java.lang.IllegalArgumentException
at org.apache.tomcat.util.http.parser.Host.parse(Host.java:73)
at org.apache.tomcat.util.http.parser.Host.parse(Host.java:40)
at
org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:277)
at
org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:1203)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:776)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:800)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1471)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)


Any hints on what cause this problem? Is it a configuration issue or a bug?
Anyone else encountered this problem with this version or another one?

Regards,
-
Daniel Savard

RE: Re: Tomcat 5.5.17 migration to 6.0.53

[David Babooram]

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, 24 July 2018 12:41 PM
To: users@tomcat.apache.org
Subject: [EXTERNAL] Re: Tomcat 5.5.17 migration to 6.0.53

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/24/18 10:54 AM, David Babooram wrote:
> I will try to be as clear as possible.

:)

> The files that were originally in
> /usr/local/tomcat/jakarta-tomcat-5.5.17/webapps/MYAPP/WEB-INF/lib
> were copied by default when I migrated the app to 
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/

Good, that's what you probably should have done.

> When I ran MYAPP I got the error from my previous email.
> 
> I then mv all the files from
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib
> into a temp directory , in attempt to make it use the global lib , but 
> still the same error.

Hmm. I'd expect lots of problems when removing all required libraries from your 
application.

Did you copy the "work" directory from the Tomcat 5.5 installation?
(I'm guessing not.)

> My next idea was to place the files from 
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib
> into  /usr/local/tomcat/apache-tomcat-6.0.53/lib , but with the new 
> structure I am unsure what belongs where.

Definitely undo that... it's likely to break your Tomcat installation.
You should basically never add anything other than maybe a JDBC driver to your 
CATALINA_BASE/lib directory. Definitely nothing application-specific.

I'd recommend removing all the files from CATALINA_BASE/lib and re-extracting 
the distro package you downloaded just to reset things back to the way they 
were.

-> 

ok I did not place it in CAT/lib yet so everything is in tact.  
However in the 5.5 there was a server/lib folder that has some jar files what 
do I do with these? I assume we need to put that in the /lib but not sure
server/lib/
catalina-ant.jar  catalina.jar  
commons-modeler.jar   servlets-invoker.jar  tomcat-ajp.jar 
tomcat-http.jar
catalina-ant-jmx.jar  catalina-optional.jar 
servlets-cgi.renametojar  servlets-ssi.renametojar  tomcat-apr.jar 
tomcat-jkstatus-ant.jar
catalina-cluster.jar  catalina-storeconfig.jar  
servlets-default.jar  servlets-webdav.jar   tomcat-coyote.jar  
tomcat-util.jar
>





> FYI : in my original /usr/local/tomcat/jakarta-tomcat-5.5.17/common
> I have the following directories
> 
> classes  endorsed  i18n  lib
> 
> 
> 
> 
> activation.jar antlr-2.7.2.jar

I think something got lost in the copy/paste. If you had files in the "common" 
loader in Tomcat 5.5 then you might have a bit of work figuring out which files 
are required by the application and which are expected to be supplied by the 
container (Tomcat).

I'm going to attempt to group these files into 2 categories: things that ought 
to be in your web application's WEB-INF/lib directory and which files should be 
ignored (because Tomcat and/or the JVM should be supplying them). Here goes:

1. Files supplied by the JVM and/or Tomcat (and should be ignored from your old 
installation):

> activation.jar (Modern JVMs supply this)   
> el-api-2.2.1-b04.jar   (Tomcat is required to supply the EL APIs)

-->   

Both those files are not present in /lib directory, I recheck the 
extracted data, this is what is present in /lib

ls lib
annotations-api.jar  catalina-ha.jar  catalina-tribes.jar  el-api.jar   
  jasper.jar   server   tomcat-coyote.jar  tomcat-i18n-es.jar  
tomcat-i18n-ja.jar
catalina-ant.jar catalina.jar ecj-4.3.1.jar
jasper-el.jar  jsp-api.jar  servlet-api.jar  tomcat-dbcp.jar
tomcat-i18n-fr.jar

A bit strange that you mention it should be in the /lib and its not 
there by default.  

So I just moved activations.jar and el-api-2 to /lib and then place 
back all the webapps libs into its container lib directory , and I THINK its 
working. At least I got the page to come up



>



2. Files that ought to be in WEB-INF/lib in your application:

> antlr-2.7.2.jar axis-ant.jar axis.jar bsf-2.3.0.jar 
> commons-beanutils-1.8.0.jar commons-chain-1.2.jar 
> commons-codec-1.3.jar commons-collections.jar commons-dbcp-1.2.1.jar 
> commons-digester-1.8.jar commons-discovery-0.2.jar 
> commons-fileupload-1.1.1.jar commons-io-1.1.jar commons-lang.jar 
> commons-logging-1.0.4.jar commons-pool-1.2.jar 
> commons-validator-1.3.1.jar edtftpj.jar ibatis-common-2.jar 
> ibatis-dao-2.jar ibatis-sqlmap-2.jar invoice-generator.jar 
> itext-1.3.jar iText-2.1.0.jar j2ssh-ant-0.2.9.jar 
> j2ssh-common-0.2.9.jar j2ssh-core-0.2.9.jar j2ssh-daemon-0.2.9.jar 
> jakarta-oro.jar jaxrpc.jar jsch-0.1.20.jar jstl-1.0.2.jar jstl-1.2.jar 
> junit.jar log4j-1.2.11.jar mailapi.jar ojdbc14.jar oro-2.0.8.jar 
> poi-2.5.1-final-20040804.jar 

Re: Re: Tomcat 5.5.17 migration to 6.0.53

[David Babooram]

Hey thanks.

Before I go through your recommendations with a fine tooth comb, do you think 
it will be there same amount of work trying to go straight to the latest Apache 
version?

I started thinking of this since your mentioned the vul.




Thanks,
David




On Tue, Jul 24, 2018 at 12:41 PM -0400, "Christopher Schultz" 
mailto:ch...@christopherschultz.net>> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/24/18 10:54 AM, David Babooram wrote:
> I will try to be as clear as possible.

:)

> The files that were originally in
> /usr/local/tomcat/jakarta-tomcat-5.5.17/webapps/MYAPP/WEB-INF/lib
> were copied by default when I migrated the app to
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/

Good, that's what you probably should have done.

> When I ran MYAPP I got the error from my previous email.
>
> I then mv all the files from
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib
> into a temp directory , in attempt to make it use the global lib ,
> but still the same error.

Hmm. I'd expect lots of problems when removing all required libraries
from your application.

Did you copy the "work" directory from the Tomcat 5.5 installation?
(I'm guessing not.)

> My next idea was to place the files from
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib
> into  /usr/local/tomcat/apache-tomcat-6.0.53/lib , but with the new
> structure I am unsure what belongs where.

Definitely undo that... it's likely to break your Tomcat installation.
You should basically never add anything other than maybe a JDBC driver
to your CATALINA_BASE/lib directory. Definitely nothing
application-specific.

I'd recommend removing all the files from CATALINA_BASE/lib and
re-extracting the distro package you downloaded just to reset things
back to the way they were.

> FYI : in my original /usr/local/tomcat/jakarta-tomcat-5.5.17/common
> I have the following directories
>
> classes  endorsed  i18n  lib
>
>
>
>
> activation.jar antlr-2.7.2.jar

I think something got lost in the copy/paste. If you had files in the
"common" loader in Tomcat 5.5 then you might have a bit of work
figuring out which files are required by the application and which are
expected to be supplied by the container (Tomcat).

I'm going to attempt to group these files into 2 categories: things
that ought to be in your web application's WEB-INF/lib directory and
which files should be ignored (because Tomcat and/or the JVM should be
supplying them). Here goes:

1. Files supplied by the JVM and/or Tomcat (and should be ignored from
your old installation):

> activation.jar (Modern JVMs supply this)
> el-api-2.2.1-b04.jar   (Tomcat is required to supply the EL APIs)

2. Files that ought to be in WEB-INF/lib in your application:

> antlr-2.7.2.jar axis-ant.jar axis.jar bsf-2.3.0.jar
> commons-beanutils-1.8.0.jar commons-chain-1.2.jar
> commons-codec-1.3.jar commons-collections.jar
> commons-dbcp-1.2.1.jar commons-digester-1.8.jar
> commons-discovery-0.2.jar commons-fileupload-1.1.1.jar
> commons-io-1.1.jar commons-lang.jar commons-logging-1.0.4.jar
> commons-pool-1.2.jar commons-validator-1.3.1.jar edtftpj.jar
> ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar
> invoice-generator.jar itext-1.3.jar iText-2.1.0.jar
> j2ssh-ant-0.2.9.jar j2ssh-common-0.2.9.jar j2ssh-core-0.2.9.jar
> j2ssh-daemon-0.2.9.jar jakarta-oro.jar jaxrpc.jar jsch-0.1.20.jar
> jstl-1.0.2.jar jstl-1.2.jar junit.jar log4j-1.2.11.jar mailapi.jar
> ojdbc14.jar oro-2.0.8.jar poi-2.5.1-final-20040804.jar quartz.jar
> saaj.jar smtp.jar standard-1.0.6.jar stringtemplate.jar
> struts-core-1.3.10.jar struts-el-1.3.10.jar
> struts-extras-1.3.10.jar struts-faces-1.3.10.jar
> struts-mailreader-dao-1.3.10.jar struts-scripting-1.3.10.jar
> struts-taglib-1.3.10.jar struts-tiles-1.3.10.jar wsdl4j-1.5.1.jar
> xmlrpc-2.0.jar

3. Wait, there is another category. You appear to have some conflicts
in your existing libraries:

> jstl-1.0.2.jar jstl-1.2.jar

and
> jakarta-oro.jar oro-2.0.8.jar

If those files have the same classes in each of them, you might be
looking at some problems. Check the contents to see if they are
distinct or if you have duplicate libraries.

4. Things you might want to look into.

> mailapi.jar

Is that javamail?

> smtp.jar

Is that *also* javamail?

> ojdbc14.jar

Is that the Oracle JDBC driver? If the container (Tomcat) is managing
your connection-pool, then you'll want to put this file into
CATALINA_BASE/lib and *nowhere else*.

> junit.jar

Are you sure you need the junit runtime in your running application?
My guess is "no" and you might want to see if things still work is you
remove this. But it can wait until later.

Finally (and I say this as a proud Apache Struts 1.x user) it's
important that you understand that (a) Apache Struts 1.x has reached
EOL and (b) there are unpatched, publicly-reported security
vulnerabilities in the version you are using (1.3.10). You should
really research those vulnerabilities and make sure 

Re: Need information

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Francesco,

On 7/24/18 12:39 PM, Francesco Viscomi wrote:
> Ok thanks, i need to know for Tomcat 7

You want "context aliases":

https://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Standard_Im
plementation

Search for the "aliases" attribute.

> And Tomcat 8.5

You want "post-load resources":

https://tomcat.apache.org/tomcat-8.5-doc/config/resources.html

Search for "PostResources".

Resources are available in both pre-resource and post-resource forms.
I recommend using post-resource so that a stray file in the target
location can't mask a file provided by the application.

On the other hand, if the application contains a "default config file"
and you want to override it with an environment-specific replacement,
then you'll want to use pre-resources instead of post-resources.

Note that "resources" are used to load EVERYTHING, including class
files, etc. You should read and re-read the entire section on
Resources in the user-guide until you understand the implications of
the configuration you are about to implement.

- -chris

> Il mar 24 lug 2018, 18:20 Christopher Schultz
>  ha scritto:
> 
> Francesco,
> 
> On 7/24/18 2:26 AM, Francesco Viscomi wrote:
 Ok thanks, anyway is there a way to add a resource to the
 tomcat classpath, i know that it is possibile because in my
 previous job i 've used that :)
> 
> Yes, this is possible, but the answer depends upon your Tomcat
> version.
> 
> Please tell us your tomcat version.
> 
> -chris
> 
 Il mar 24 lug 2018, 00:00 M. Manna  ha 
 scritto:
 
> This is not relevant to tomcat. you have to read how to
> configure spring application environment variables and
> classpath. Below are some examples, which you can read and
> configure yourself.
> 
> 
> https://docs.spring.io/spring-boot/docs/current/reference/html/boo
t-f
>
> 
eatures-external-config.html
> 
>
>
>
>
> 
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#bo
> ot-features-external-config-application-property-files 
> 
>
>
> 
https://stackoverflow.com/questions/41461786/how-to-externalize-appli
> cation-properties-in-tomcat-webserver-for-spring 
> 
>
>
>
>
> 
Thanks,
> 
> On Mon, 23 Jul 2018, 21:58 Francesco Viscomi, 
>  wrote:
> 
>> Because I need to add a folder (properties) under the
>> tomcat installation in order to read the properties in a
>> file with the following annotation (using spring) 
>> @PropertySource("classpath:properties/application.properties");
>>
>>
>>
>>
>>
>>
>>
>
>> 
2018-07-23 22:21 GMT+02:00 M. Manna :
>> 
>>> You should never modify them, unless you know precisely
>>> what you're
> doing
>>> it, and why.
>>> 
>>> What ia your reason to modify them? What would you like
>>> to do?
>>> 
>>> On Mon, 23 Jul 2018, 20:30 Francesco Viscomi, 
>>> 
>> wrote:
>>> 
 Sir Manna you're right, but at the moment I cannot
 go through debug; So if there is an explanation and
 why i should modify them, it will
> be
>>> very
 important to me.
 
 thanks
 
 2018-07-23 18:06 GMT+02:00 M. Manna
 :
 
> http://tomcat.apache.org/tomcat-8.5-doc/class-loader-
>
> 
howto.html#Class_Loader_Definitions
> 
> Also, you should try and pay attention to
> Bootstrap.java file and
>> debug
> through the execution to understand how it's
> working.
> 
> 
> On 23 July 2018 at 17:03, Francesco Viscomi 
> 
>>> wrote:
> 
>> hi all In catalina.properties i find :
>> common.loaders serverr.loaders shared.loaders
>> 
>> And i wasn t able to find out the meaning of
>> that variables, some
>> one
 can
>> tell to me and if possibile also a link to the 
>> documentation in
>> wich
> these
>> variable are treated
>> 
>> 
>> Thanks
>> 
> 
 
 
 
 -- Ing. Viscomi Francesco
 
>>> 
>> 
>> 
>> 
>> -- Ing. Viscomi Francesco
>> 
> 
 
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Us

Re: Tomcat 5.5.17 migration to 6.0.53

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/24/18 10:54 AM, David Babooram wrote:
> I will try to be as clear as possible.

:)

> The files that were originally in
> /usr/local/tomcat/jakarta-tomcat-5.5.17/webapps/MYAPP/WEB-INF/lib
> were copied by default when I migrated the app to
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/

Good, that's what you probably should have done.

> When I ran MYAPP I got the error from my previous email.
> 
> I then mv all the files from
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib
> into a temp directory , in attempt to make it use the global lib ,
> but still the same error.

Hmm. I'd expect lots of problems when removing all required libraries
from your application.

Did you copy the "work" directory from the Tomcat 5.5 installation?
(I'm guessing not.)

> My next idea was to place the files from
> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib
> into  /usr/local/tomcat/apache-tomcat-6.0.53/lib , but with the new
> structure I am unsure what belongs where.

Definitely undo that... it's likely to break your Tomcat installation.
You should basically never add anything other than maybe a JDBC driver
to your CATALINA_BASE/lib directory. Definitely nothing
application-specific.

I'd recommend removing all the files from CATALINA_BASE/lib and
re-extracting the distro package you downloaded just to reset things
back to the way they were.

> FYI : in my original /usr/local/tomcat/jakarta-tomcat-5.5.17/common
> I have the following directories
> 
> classes  endorsed  i18n  lib
> 
> 
> 
> 
> activation.jar antlr-2.7.2.jar

I think something got lost in the copy/paste. If you had files in the
"common" loader in Tomcat 5.5 then you might have a bit of work
figuring out which files are required by the application and which are
expected to be supplied by the container (Tomcat).

I'm going to attempt to group these files into 2 categories: things
that ought to be in your web application's WEB-INF/lib directory and
which files should be ignored (because Tomcat and/or the JVM should be
supplying them). Here goes:

1. Files supplied by the JVM and/or Tomcat (and should be ignored from
your old installation):

> activation.jar (Modern JVMs supply this) 
> el-api-2.2.1-b04.jar   (Tomcat is required to supply the EL APIs)

2. Files that ought to be in WEB-INF/lib in your application:

> antlr-2.7.2.jar axis-ant.jar axis.jar bsf-2.3.0.jar 
> commons-beanutils-1.8.0.jar commons-chain-1.2.jar 
> commons-codec-1.3.jar commons-collections.jar 
> commons-dbcp-1.2.1.jar commons-digester-1.8.jar 
> commons-discovery-0.2.jar commons-fileupload-1.1.1.jar 
> commons-io-1.1.jar commons-lang.jar commons-logging-1.0.4.jar 
> commons-pool-1.2.jar commons-validator-1.3.1.jar edtftpj.jar 
> ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar 
> invoice-generator.jar itext-1.3.jar iText-2.1.0.jar 
> j2ssh-ant-0.2.9.jar j2ssh-common-0.2.9.jar j2ssh-core-0.2.9.jar 
> j2ssh-daemon-0.2.9.jar jakarta-oro.jar jaxrpc.jar jsch-0.1.20.jar 
> jstl-1.0.2.jar jstl-1.2.jar junit.jar log4j-1.2.11.jar mailapi.jar 
> ojdbc14.jar oro-2.0.8.jar poi-2.5.1-final-20040804.jar quartz.jar 
> saaj.jar smtp.jar standard-1.0.6.jar stringtemplate.jar 
> struts-core-1.3.10.jar struts-el-1.3.10.jar 
> struts-extras-1.3.10.jar struts-faces-1.3.10.jar 
> struts-mailreader-dao-1.3.10.jar struts-scripting-1.3.10.jar 
> struts-taglib-1.3.10.jar struts-tiles-1.3.10.jar wsdl4j-1.5.1.jar 
> xmlrpc-2.0.jar

3. Wait, there is another category. You appear to have some conflicts
in your existing libraries:

> jstl-1.0.2.jar jstl-1.2.jar

and
> jakarta-oro.jar oro-2.0.8.jar

If those files have the same classes in each of them, you might be
looking at some problems. Check the contents to see if they are
distinct or if you have duplicate libraries.

4. Things you might want to look into.

> mailapi.jar

Is that javamail?

> smtp.jar

Is that *also* javamail?

> ojdbc14.jar

Is that the Oracle JDBC driver? If the container (Tomcat) is managing
your connection-pool, then you'll want to put this file into
CATALINA_BASE/lib and *nowhere else*.

> junit.jar

Are you sure you need the junit runtime in your running application?
My guess is "no" and you might want to see if things still work is you
remove this. But it can wait until later.

Finally (and I say this as a proud Apache Struts 1.x user) it's
important that you understand that (a) Apache Struts 1.x has reached
EOL and (b) there are unpatched, publicly-reported security
vulnerabilities in the version you are using (1.3.10). You should
really research those vulnerabilities and make sure that you have
mitigated them all, or you risk exposing your users and servers to
exploitation.

Hope that helps,
- -chris

> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Monday, 23 July 2018
> 2:29 PM To: users@tomcat.apache.org Subject: [EXTERNAL] Re: Tomcat
> 5.5.17 migration to 6.0.53
> 
>

Re: Need information

[Francesco Viscomi]

Ok thanks, i need to know for
Tomcat 7
And
Tomcat 8.5
Thanks

Il mar 24 lug 2018, 18:20 Christopher Schultz 
ha scritto:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Francesco,
>
> On 7/24/18 2:26 AM, Francesco Viscomi wrote:
> > Ok thanks, anyway is there a way to add a resource to the tomcat
> > classpath, i know that it is possibile because in my previous job i
> > 've used that :)
>
> Yes, this is possible, but the answer depends upon your Tomcat version.
>
> Please tell us your tomcat version.
>
> - -chris
>
> > Il mar 24 lug 2018, 00:00 M. Manna  ha
> > scritto:
> >
> >> This is not relevant to tomcat. you have to read how to configure
> >> spring application environment variables and classpath. Below are
> >> some examples, which you can read and configure yourself.
> >>
> >>
> >> https://docs.spring.io/spring-boot/docs/current/reference/html/boot-f
> eatures-external-config.html
> 
> >>
> >>
> >>
> https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#bo
> ot-features-external-config-application-property-files
> 
> >>
> >> https://stackoverflow.com/questions/41461786/how-to-externalize-appli
> cation-properties-in-tomcat-webserver-for-spring
> 
> >>
> >>
> >>
> Thanks,
> >>
> >> On Mon, 23 Jul 2018, 21:58 Francesco Viscomi,
> >>  wrote:
> >>
> >>> Because I need to add a folder (properties) under the tomcat
> >>> installation in order to read the properties in a file with the
> >>> following annotation (using spring)
> >>> @PropertySource("classpath:properties/application.properties");
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> 2018-07-23 22:21 GMT+02:00 M. Manna :
> >>>
>  You should never modify them, unless you know precisely what
>  you're
> >> doing
>  it, and why.
> 
>  What ia your reason to modify them? What would you like to
>  do?
> 
>  On Mon, 23 Jul 2018, 20:30 Francesco Viscomi,
>  
> >>> wrote:
> 
> > Sir Manna you're right, but at the moment I cannot go
> > through debug; So if there is an explanation and why i
> > should modify them, it will
> >> be
>  very
> > important to me.
> >
> > thanks
> >
> > 2018-07-23 18:06 GMT+02:00 M. Manna :
> >
> >> http://tomcat.apache.org/tomcat-8.5-doc/class-loader-
> >> howto.html#Class_Loader_Definitions
> >>
> >> Also, you should try and pay attention to Bootstrap.java
> >> file and
> >>> debug
> >> through the execution to understand how it's working.
> >>
> >>
> >> On 23 July 2018 at 17:03, Francesco Viscomi
> >> 
>  wrote:
> >>
> >>> hi all In catalina.properties i find : common.loaders
> >>> serverr.loaders shared.loaders
> >>>
> >>> And i wasn t able to find out the meaning of that
> >>> variables, some
> >>> one
> > can
> >>> tell to me and if possibile also a link to the
> >>> documentation in
> >>> wich
> >> these
> >>> variable are treated
> >>>
> >>>
> >>> Thanks
> >>>
> >>
> >
> >
> >
> > -- Ing. Viscomi Francesco
> >
> 
> >>>
> >>>
> >>>
> >>> -- Ing. Viscomi Francesco
> >>>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltXUcMACgkQHPApP6U8
> pFh7SQ//ermX00upIzMhYb/aeGGKBR2d115iKrr5PQj6xek6A3Z+CGWzBeuLhCCd
> Y3JgyDAQZ4Pdh0Ntxgs1qXDkYna+fMGHBu5cuZyXuJzBHrjk65HCYmMJ/LzRdGU+
> OVNZ4E42Jlecugbwbf5GBQ+JHnWRCZgdB0qvCOo07EXQFXerc0OaN2RtaCpbgcsB
> w7faSKxJwW5AiEWNGjTH460mR+AEqZDygCScV2dF2R8OVFtxmjtjM6vnbDrTAUL4
> 6SOz/X7yNva4zxxvIor9wLgSgoH3K/ZjEj4f4AmOw9fT6vHOvQoS/dxNS//FemF2
> qAK9S69ih1ZgNtYzri+aFTqr0C7yycvRmR82PgQ5NlYRSEXicSW6l9e9JnOjufYQ
> wcXz06aVeIaaJGLhn1TYhFukjkFqSohCRr5FTBhcjqgk8uuvKelp8oFdTLyWRwi1
> DsL5r7e8GhhJmN2pKuPqMSVJHpe9TrsL5JAa+kFSnqJkHKG45oVJrVtyiXMPfdnk
> ACAHO2a169GzHVIwlH3F+GEarnABZ8ptJiszFUSqEjz4I0sHSk1iHzPsyc55/Bad
> jKuUt6LJNFZEDBMZy7upo/Zp8DMX4qkXOh9Sr4KxgfndrRFn4oM63hz1NwOfqXgv
> p+b7vL7MNTF24fJHsm/oLRuCG8t8Ul4IKIHNfnOe7a4TiLPXt08=
> =VRnC
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Changing Sever.xml without restarting Tomcat 8.5

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Laurie,

On 7/24/18 5:54 AM, Laurie Miller-Cook wrote:
> Hi Chris
> 
> You mentioned the below in your reply
> 
> "You might also want to consider having separate Tomcat instances
> per domain. That might be more manageable, though it will require
> more memory on your server(s)."
> 
> Is there a best practice guide to what we are trying to achieve,
> multiple domains on one server, we are new to Tomcat, so we are
> implementing what we can find in documentation on the web?

The only best-practice advice I can give is "do what is best for your
use-case". Completely un-helpful, I know. I can only tell you what my
own experience has been.

We've gotten a lot of mileage out of multi-instance Tomcat
deployments. We deploy a single application to a single Tomcat
instance, and we have 4 applications to deply. That means that every
node in our deployments are running 4 JVMs each with Tomcat + a single
application.

We find that this gives us the most flexibility at the expense of a
little memory.

> We need to be able to supply each customer the same IP Port, say 80
>  or 443, if we have multiple instances of Tomcat on one server
> then would we need a proxy in front (for wants of better words)
> which could then direct the customers to the correct websites and
> hence get the same IP Port. We also use SSL so I assume wildcard
> certificate would need to be applied to each Tomcat instance?

You would need to have a reverse-proxy, yes. You should have this,
anyway, because trusting a single JVM/Tomcat/application not to go
down for any number of reasons is asking for trouble. So a
proxy+multiple node deployment should already be in your plans.

The TLS certificate issue should be handled at the proxy, using
whatever strategy makes sense for you. I don't know what kinds of
certificates you need, but any decent proxy should allow you to deploy
(virtually) unlimited certificates for any number of domains. Wildcard
certs aren't always the right approach, but this is outside the scope
of our discussion, here. You can configure any certificates you may
need at the proxy. You could do it with Tomcat, too, but ... see my
previous assertion about *needing* a reverse-proxy.

> Would each instance of Tomcat require its own JVM, hence your 
> comment about more memory on the servers, do you know of any 
> resourcing guide lines for multiple instances on Tomcat on one 
> server?
Yes, each instance is a separate JVM. The overhead of a single JVM
isn't much (where "much" is, of course, relative). If your application
can run comfortably in a few MB of heap space then Tomcat's
contribution to your memory footprint is going to be fairly large. But
most Java web applications these days have multi-gigabyte heaps. JVM
and Tomcat overhead is something like 32MiB. That's nothing compared
to the huge amounts of memory your application is likely to require.

Hope that helps,
- -chris

> -Original Message- From: Christopher Schultz
>  Sent: Monday, July 23, 2018 7:33 PM 
> To: users@tomcat.apache.org Subject: Re: Changing Sever.xml without
> restarting Tomcat 8.5
> 
> Laurie,
> 
> On 7/23/18 12:25 PM, Laurie Miller-Cook wrote:
>> Hi there,
> 
>> I have an issue where we have multiple virtual hosts in separate
>> base directory's on a single Tomcat installation.  If I need to
>> change something within server.xml I need to restart Tomcat which
>> means I need to do this within an outage window as it affects all
>> of the Websites, is there a way of reloading the server.xml
>> without restarting Tomcat?
> 
>> As a bit of background we have a wildcard domain, so 
>> ..com so we have created multiple webapp 
>> directories with their own Manage and have multiple entries in
>> the server.xml file for the different hosts.
> 
>> What need to be able to do is, for example, is add another host
>> to the xml site and get that to take effect automatically without
>> the need to restarting Tomcat as this restarts all the other
>> websites and hence gives outages to our customers.
> 
>> Any help would be greatly appreciated.
> 
> Tomcat won't reload server.xml. It's just too complicated to
> determine what has changed and how to perform an in-place reinit
> that only does what is "necessary".
> 
> On the other hand, JMX is very powerful and you can make runtime
> changes to Tomcat using that. Maybe you can consider performing two
> operations whenever you need to add a virtual host:
> 
> 1. Modify the conf/server.xml 2. Issue a JMX command to provision
> the new virtual host in the running Tomcat
> 
> You might also want to consider having separate Tomcat instances
> per domain. That might be more manageable, though it will require
> more memory on your server(s).
> 
> -chris
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 

Re: Need information

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Francesco,

On 7/24/18 2:26 AM, Francesco Viscomi wrote:
> Ok thanks, anyway is there a way to add a resource to the tomcat
> classpath, i know that it is possibile because in my previous job i
> 've used that :)

Yes, this is possible, but the answer depends upon your Tomcat version.

Please tell us your tomcat version.

- -chris

> Il mar 24 lug 2018, 00:00 M. Manna  ha
> scritto:
> 
>> This is not relevant to tomcat. you have to read how to configure
>> spring application environment variables and classpath. Below are
>> some examples, which you can read and configure yourself.
>> 
>> 
>> https://docs.spring.io/spring-boot/docs/current/reference/html/boot-f
eatures-external-config.html
>>
>>
>> 
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#bo
ot-features-external-config-application-property-files
>> 
>> https://stackoverflow.com/questions/41461786/how-to-externalize-appli
cation-properties-in-tomcat-webserver-for-spring
>>
>>
>> 
Thanks,
>> 
>> On Mon, 23 Jul 2018, 21:58 Francesco Viscomi,
>>  wrote:
>> 
>>> Because I need to add a folder (properties) under the tomcat
>>> installation in order to read the properties in a file with the
>>> following annotation (using spring) 
>>> @PropertySource("classpath:properties/application.properties");
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
2018-07-23 22:21 GMT+02:00 M. Manna :
>>> 
 You should never modify them, unless you know precisely what
 you're
>> doing
 it, and why.
 
 What ia your reason to modify them? What would you like to
 do?
 
 On Mon, 23 Jul 2018, 20:30 Francesco Viscomi,
 
>>> wrote:
 
> Sir Manna you're right, but at the moment I cannot go
> through debug; So if there is an explanation and why i
> should modify them, it will
>> be
 very
> important to me.
> 
> thanks
> 
> 2018-07-23 18:06 GMT+02:00 M. Manna :
> 
>> http://tomcat.apache.org/tomcat-8.5-doc/class-loader- 
>> howto.html#Class_Loader_Definitions
>> 
>> Also, you should try and pay attention to Bootstrap.java
>> file and
>>> debug
>> through the execution to understand how it's working.
>> 
>> 
>> On 23 July 2018 at 17:03, Francesco Viscomi
>> 
 wrote:
>> 
>>> hi all In catalina.properties i find : common.loaders 
>>> serverr.loaders shared.loaders
>>> 
>>> And i wasn t able to find out the meaning of that
>>> variables, some
>>> one
> can
>>> tell to me and if possibile also a link to the
>>> documentation in
>>> wich
>> these
>>> variable are treated
>>> 
>>> 
>>> Thanks
>>> 
>> 
> 
> 
> 
> -- Ing. Viscomi Francesco
> 
 
>>> 
>>> 
>>> 
>>> -- Ing. Viscomi Francesco
>>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltXUcMACgkQHPApP6U8
pFh7SQ//ermX00upIzMhYb/aeGGKBR2d115iKrr5PQj6xek6A3Z+CGWzBeuLhCCd
Y3JgyDAQZ4Pdh0Ntxgs1qXDkYna+fMGHBu5cuZyXuJzBHrjk65HCYmMJ/LzRdGU+
OVNZ4E42Jlecugbwbf5GBQ+JHnWRCZgdB0qvCOo07EXQFXerc0OaN2RtaCpbgcsB
w7faSKxJwW5AiEWNGjTH460mR+AEqZDygCScV2dF2R8OVFtxmjtjM6vnbDrTAUL4
6SOz/X7yNva4zxxvIor9wLgSgoH3K/ZjEj4f4AmOw9fT6vHOvQoS/dxNS//FemF2
qAK9S69ih1ZgNtYzri+aFTqr0C7yycvRmR82PgQ5NlYRSEXicSW6l9e9JnOjufYQ
wcXz06aVeIaaJGLhn1TYhFukjkFqSohCRr5FTBhcjqgk8uuvKelp8oFdTLyWRwi1
DsL5r7e8GhhJmN2pKuPqMSVJHpe9TrsL5JAa+kFSnqJkHKG45oVJrVtyiXMPfdnk
ACAHO2a169GzHVIwlH3F+GEarnABZ8ptJiszFUSqEjz4I0sHSk1iHzPsyc55/Bad
jKuUt6LJNFZEDBMZy7upo/Zp8DMX4qkXOh9Sr4KxgfndrRFn4oM63hz1NwOfqXgv
p+b7vL7MNTF24fJHsm/oLRuCG8t8Ul4IKIHNfnOe7a4TiLPXt08=
=VRnC
-END PGP SIGNATURE-

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

RE: Re: Tomcat 5.5.17 migration to 6.0.53

[David Babooram]

Hi Christopher,


I will try to be as clear as possible.



The files that were originally in 
/usr/local/tomcat/jakarta-tomcat-5.5.17/webapps/MYAPP/WEB-INF/lib were copied 
by default when I migrated the app to  
/usr/local/tomcat/apache-tomcat-6.0.53/webapps/

When I ran MYAPP I got the error from my previous email.

I then mv all the files from 
/usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib into a temp 
directory , in attempt to make it use the global lib , but still the same error.

My next idea was to place the files from 
/usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib into  
/usr/local/tomcat/apache-tomcat-6.0.53/lib , but with the new structure I am 
unsure what belongs where.



FYI : in my original /usr/local/tomcat/jakarta-tomcat-5.5.17/common  I have the 
following directories

classes  endorsed  i18n  lib




activation.jar
antlr-2.7.2.jar
axis-ant.jar
axis.jar
bsf-2.3.0.jar
commons-beanutils-1.8.0.jar
commons-chain-1.2.jar
commons-codec-1.3.jar
commons-collections.jar
commons-dbcp-1.2.1.jar
commons-digester-1.8.jar
commons-discovery-0.2.jar
commons-fileupload-1.1.1.jar
commons-io-1.1.jar
commons-lang.jar
commons-logging-1.0.4.jar
commons-pool-1.2.jar
commons-validator-1.3.1.jar
edtftpj.jar
el-api-2.2.1-b04.jar
ibatis-common-2.jar
ibatis-dao-2.jar
ibatis-sqlmap-2.jar
invoice-generator.jar
itext-1.3.jar
iText-2.1.0.jar
j2ssh-ant-0.2.9.jar
j2ssh-common-0.2.9.jar
j2ssh-core-0.2.9.jar
j2ssh-daemon-0.2.9.jar
jakarta-oro.jar
jaxrpc.jar
jsch-0.1.20.jar
jstl-1.0.2.jar
jstl-1.2.jar
junit.jar
log4j-1.2.11.jar
mailapi.jar
ojdbc14.jar
oro-2.0.8.jar
poi-2.5.1-final-20040804.jar
quartz.jar
saaj.jar
smtp.jar
standard-1.0.6.jar
stringtemplate.jar
struts-core-1.3.10.jar
struts-el-1.3.10.jar
struts-extras-1.3.10.jar
struts-faces-1.3.10.jar
struts-mailreader-dao-1.3.10.jar
struts-scripting-1.3.10.jar
struts-taglib-1.3.10.jar
struts-tiles-1.3.10.jar
wsdl4j-1.5.1.jar
xmlrpc-2.0.jar


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Monday, 23 July 2018 2:29 PM
To: users@tomcat.apache.org
Subject: [EXTERNAL] Re: Tomcat 5.5.17 migration to 6.0.53

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/23/18 12:51 PM, David Babooram wrote:
> Hello
>
> I have begun a migration from 5.5 to 6. Yes I know 6 is EOL but the
> migration from 5.5 to 6 has some more documentation compared to
> 5.5 to the latest version.
>
> I followed the standard migration of libs and classes from /common
> /shared etc to the new /lin directory for 6..
>
> The server engine runs and I can see the examples web pages come up.
>
> When I migrated my production webapps to the 6.0 instance however I
> get the following error.
>
> HTTP Status 500 - java.lang.LinkageError: loader constraint
> violation: when resolving interface method
> "javax.servlet.jsp.JspApplicationContext.getExpressionFactory()Ljavax/
el/ExpressionFactory;"
>
>
the class loader (instance of org/apache/jasper/servlet/JasperLoader)
> of the current class, org/apache/jsp/index_jsp, and the class loader
> (instance of org/apache/catalina/loader/StandardClassLoader)
> for resolved class, javax/servlet/jsp/JspApplicationContext, have
> different Class objects for the type javax/el/ExpressionFactory used
> in the signature
>
> Any insight on this is welcomed.
>
> I notice in that my app has its own lib directory, does this means
> that there is a conflict with the lib files from the base directory ?

Possibly. What files do you have in your app's WEB-INF/lib directory?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltWHmYACgkQHPApP6U8
pFi4ow//e1d8mPY8X7K2X1h2X9Maim12GIbKAv0OrvthWMWYMIt6POTrxRepJLg6
BxgQ2Duabf2wCmZhGRRcBotc7++Niyyh3bHPwy11UfsHXkLPQlE1bnfprgYsUI+5
JRUf4ZHLQ+HCXTn3R54U5Z+a6U4ucSotPt2FwpslIGH2lZFrjSjM+lELagNIJvvU
gysavLRPZIQSCvDfPw1MeDbmtPalbVlq0XvS4d4szvWJy0oNzF1mRG4u6KWniisz
t0ULSmp/2virBNPmQ9SdeoG23avPtfxVOY2BbP1O5IAjKSfhPV+UNhvu48ufq5gj
gVYGVf5edxZy241ApGZHZoSSfl5LEiN1vJpIsF1a8HcqffhBTJTwtDzhscQDVxw9
89iiwTGEp5VtugI8vqMNI1hO9b0ESJhAfsCuMwvEvL2sivWWROXRzExsFiSFe0x2
K9tpqXBonXZ+4y+xwQdBoaDcRRjKhUW9rP5CbkNvDOfpttsnyD6c7ff1t/9K3vr/
FnBFCqo0qDRdSLckbtmU5C6/yHUjQiFtMXbMtnEVXwnk3zo0ICJnvxvTINp346nq
EiYAMcZF+RemlO3+0whK+B7BKgF9L4baqvQmglJaIEVY2D6w4SmW/xCO55a4V2c4
gRD9xNP6u7M/dlFGs+VaJvdwkh4wNxj319vxYsZ2O2KsdmDdvUw=
=YuGP
-END PGP SIGNATURE-

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




Notice of Confidentiality:

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. If 
you are not

RE: Changing Sever.xml without restarting Tomcat 8.5

[Laurie Miller-Cook]

Hi Chris

You mentioned the below in your reply

"You might also want to consider having separate Tomcat instances per domain. 
That might be more manageable, though it will require more memory on your 
server(s)."

Is there a best practice guide to what we are trying to achieve, multiple 
domains on one server, we are new to Tomcat, so we are implementing what we can 
find in documentation on the web?

We need to be able to supply each customer the same IP Port, say 80 or 443, if 
we have multiple instances of Tomcat on one server then would we need a proxy 
in front (for wants of better words) which could then direct the customers to 
the correct websites and hence get the same IP Port.  We also use SSL so I 
assume wildcard certificate would need to be applied to each Tomcat instance?

Would each instance of Tomcat require its own JVM, hence your comment about 
more memory on the servers, do you know of any resourcing guide lines for 
multiple instances on Tomcat on one server?

Sorry for all the questions.

All the best

Laurie Miller-Cook
dd: +44 (0)1252 607220
e: laurie.miller-c...@larmerbrown.com 

-Original Message-
From: Christopher Schultz  
Sent: Monday, July 23, 2018 7:33 PM
To: users@tomcat.apache.org
Subject: Re: Changing Sever.xml without restarting Tomcat 8.5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Laurie,

On 7/23/18 12:25 PM, Laurie Miller-Cook wrote:
> Hi there,
> 
> I have an issue where we have multiple virtual hosts in separate base 
> directory's on a single Tomcat installation.  If I need to change 
> something within server.xml I need to restart Tomcat which means I 
> need to do this within an outage window as it affects all of the 
> Websites, is there a way of reloading the server.xml without  
> restarting Tomcat?
> 
> As a bit of background we have a wildcard domain, so 
> ..com so we have created multiple webapp 
> directories with their own Manage and have multiple entries in the  
> server.xml file for the different hosts.
> 
> What need to be able to do is, for example, is add another host to  
> the xml site and get that to take effect automatically without the  
> need to restarting Tomcat as this restarts all the other websites and 
> hence gives outages to our customers.
> 
> Any help would be greatly appreciated.

Tomcat won't reload server.xml. It's just too complicated to determine what has 
changed and how to perform an in-place reinit that only does what is 
"necessary".

On the other hand, JMX is very powerful and you can make runtime changes to 
Tomcat using that. Maybe you can consider performing two operations whenever 
you need to add a virtual host:

1. Modify the conf/server.xml
2. Issue a JMX command to provision the new virtual host in the running Tomcat

You might also want to consider having separate Tomcat instances per domain. 
That might be more manageable, though it will require more memory on your 
server(s).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltWH1YACgkQHPApP6U8
pFif+xAAqBJLoPub6ZsICJGVp5N87IYUlhcsFXEULLkomOkDCHGROea91uhUOdu+
a9JRZbC6tQQmhopqGNb5HkZrkNvkPBT13/71TDB7faGzwLXOv1/V0dRPO7KscgTq
PikAuyXhSNyfOYorv7xKq2MwUdT86dAovukf8ClEDE1mX/7CgtE/MjW64eQcTc59
HNB8CilW8bAs3ApZso1EQEaUYoE7EkCtyWlnEFAtbbPsgzDD3CTpp4iqiVDGXkYD
LsXUvLM8DtVdslzLztX5rRRxDaPsYXd8g9IOfi4yLqOMeOeO0FogBc6VpuC1d7gD
TOeQARm0k2Xf/RbUKbAbD1gV/8xFPI4bKtSJINSD/A5o1Qpvv/rtVz0pQYJA8fgb
u8v485wpmEFSDN+tE9MXE6YQ6HBJRtGQJ8j2xhhqU+iTbXonYX+BbxW9sqhXvvua
5i6cMjuWBuu49HYreaVHdV9N2kfxEJ2wLzVKXE3BEsWnVGYJEFHYizqS3yNyj9qv
cDw1Pc5jfYdfzFkn8oXZe1t1fHXRcxTN6XpwBKzmHxEkwCh+cvwwkZ10zaEjphs1
22X6xsi88e0ng/xdoQPKb+CPNq/13VYS0l1jlAcMc8DPeocSonMv20Y9pySep80h
YioelFbIrdjH7teVKoR9GoR2f/vA22D7UV600GOi2nXiWVWkn2Y=
=hB5A
-END PGP SIGNATURE-

-
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