Re: Excessive number of tomcat-users.xml open files

2018-11-27 Thread Mark Thomas 
On 27/11/2018 19:13, Chen Levy wrote:
> Hello everyone
> 
> I have two Tomcat servers running under load, on two EC2 instances with 
> amazon-linux-2 and JRE 10.0.2, one server is 9.0.12 and the other 9.0.13
> The servers share the exact same application, configuration and load; 
> however, the 9.0.13 server keeps hundreds of open files of the following form 
> (obtained using 'lsof'):
> https-jss 30403 30515   ec2-user 1874r  REG  259,1  
> 216492934 /opt/apache-tomcat-9.0.13/conf/tomcat-users.xml
> http-nio- 30403 30485   ec2-user 1751r  REG  259,1  
> 216492934 /opt/apache-tomcat-9.0.13/conf/tomcat-users.xml
> 
> These open files do not exist on the 9.0.12 server
> These servers deploy a single application with the default content of the 
> webapps folder removed
> 
> It might be related to the following recent bug fix: 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58590
> 
> Has anyone else seen a similar behavior?

http://tomcat.apache.org/bugreport.html#Known_issues
http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
https://bz.apache.org/bugzilla/show_bug.cgi?id=62958

Mark

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

Re: help installing mod_jk on Centos 7 on a Google Cloud server

2018-11-27 Thread Lou Wallace 
Hi André,

Here is some info on the setup, let me know what it tells you.

tomcat
etc/tomcat
drwxrwxr-x. 3 root tomcat 23 Nov 18 17:48 Catalina
-rw-r--r--. 1 root tomcat  13443 Oct 16 09:16 catalina.policy
-rw-r--r--. 1 root tomcat   6496 Oct 16 09:16 catalina.properties
drwxr-xr-x. 2 root tomcat 20 Nov 18 17:48 conf.d
-rw-r--r--. 1 root tomcat   1394 Oct 16 09:16 context.xml
-rw-r--r--. 1 root tomcat547 Oct 16 09:16 log4j.properties
-rw-r--r--. 1 root tomcat   3288 Oct 16 09:16 logging.properties
-rw-r--r--. 1 root tomcat   6613 Oct 16 09:16 server.xml
-rw-r--r--. 1 root tomcat   1651 Oct 16 09:16 tomcat.conf
-rw-r-. 1 root tomcat   2418 Oct 16 09:16 tomcat-users.xml
-rw-r--r--. 1 root tomcat 167655 Oct 16 09:16 web.xml

DocumentRoot (from httpd.conf)
var/www/html

ServerRoot (from httpd.conf)
/etc/httpd

webapps directory is at
/var/lib/tomcat

tomcat.conf
# System-wide configuration file for tomcat services
# This will be loaded by systemd as an environment file,
# so please keep the syntax. For shell expansion support
# place your custom files as /etc/tomcat/conf.d/*.conf
#
# There are 2 "classes" of startup behavior in this package.
# The old one, the default service named tomcat.service.
# The new named instances are called tomcat@instance.service.
#
# Use this file to change default values for all services.
# Change the service specific ones to affect only one service.
# For tomcat.service it's /etc/sysconfig/tomcat, for
# tomcat@instance it's /etc/sysconfig/tomcat@instance.

# This variable is used to figure out if config is loaded or not.
TOMCAT_CFG_LOADED="1"

# In new-style instances, if CATALINA_BASE isn't specified, it will
# be constructed by joining TOMCATS_BASE and NAME.
TOMCATS_BASE="/var/lib/tomcats/"

# Where your java installation lives
JAVA_HOME="/usr/lib/jvm/jre"

# Where your tomcat installation lives
CATALINA_HOME="/usr/share/tomcat"

# System-wide tmp
CATALINA_TMPDIR="/var/cache/tomcat/temp"

# You can pass some parameters to java here if you wish to
#JAVA_OPTS="-Xminf0.1 -Xmaxf0.3"

# Use JAVA_OPTS to set java.library.path for libtcnative.so
#JAVA_OPTS="-Djava.library.path=/usr/lib"

# You can change your tomcat locale here
#LANG="en_US"

# Run tomcat under the Java Security Manager
SECURITY_MANAGER="false"

# Time to wait in seconds, before killing process
# TODO(stingray): does nothing, fix.
# SHUTDOWN_WAIT="30"

# If you wish to further customize your tomcat environment,
# put your own definitions here
# (i.e. LD_LIBRARY_PATH for some jdbc drivers)






Virus-free.
www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Nov 25, 2018 at 4:19 PM André Warnier (tomcat) 
wrote:

> On 25.11.2018 21:43, Lou Wallace wrote:
> > Whew. Just read that link
> >
> > Warning: If Apache and Tomcat are configured to serve content from the
> same
> > file system location then care must be taken to ensure that Apache is not
> > able to serve inappropriate content such as the contents of the WEB-INF
> > directory or JSP source code.
> >
> > This could occur if the Apache DocumentRoot overlaps with a Tomcat Host's
> > appBase or the docBase of any Context. It could also occur when using the
> > Apache Alias directive with a Tomcat Host's appBase or the docBase of any
> > Context.
> >
> > And I just checked and sure enough I can access from the browser the
> > contents of the site directory. Now I haven't yet configured httpd-vhosts
> > to define site yet - could that be why I can access the directory itself
> > from a browser?
> >
> > And where do I look to see if Apache DocumentRoot overlaps with a Tomcat
> > Host's appBase or the docBase?
> >
>
> Make a picture. I'm not kidding.
> Presumably, you know what a filesystem directory structure looks like.
> So make a little schema of the Apache httpd document directories, starting
> at what is
> indicated in the DocumentRoot of the httpd.conf (or apache2.conf or
> whatever it is on your
> system); and make a similar schema of the directories of Tomcat, starting
> at the positions
> mentioned in the appBase/docBase attributes.
> If any of these overlap, you have a problem. It is not a fatal problem,
> and one can avoid
> the problem with a careful httpd configuration. But if there is an
> overlap, you are always
> at risk of forgetting to configure this properly, so better to avoid it
> altogether.
> (Of course, all of this can happen only if Apache httpd and Tomcat are
> running on the same
> host; if not, there is no such risk. Unless of course they share some
> common network
> directories..
>
> browser <- A+B -> httpd + mod_jk <-- B --> tomcat
>  | |
>  A B
>  | |
>httpd

Excessive number of tomcat-users.xml open files

2018-11-27 Thread Chen Levy 
Hello everyone

I have two Tomcat servers running under load, on two EC2 instances with 
amazon-linux-2 and JRE 10.0.2, one server is 9.0.12 and the other 9.0.13
The servers share the exact same application, configuration and load; however, 
the 9.0.13 server keeps hundreds of open files of the following form (obtained 
using 'lsof'):
https-jss 30403 30515   ec2-user 1874r  REG  259,1  
216492934 /opt/apache-tomcat-9.0.13/conf/tomcat-users.xml
http-nio- 30403 30485   ec2-user 1751r  REG  259,1  
216492934 /opt/apache-tomcat-9.0.13/conf/tomcat-users.xml

These open files do not exist on the 9.0.12 server
These servers deploy a single application with the default content of the 
webapps folder removed

It might be related to the following recent bug fix: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=58590

Has anyone else seen a similar behavior?

Thanks
Chen

Re: [slightly OT] Re: Tomcat 9 does not work with Java 11

2018-11-27 Thread Andi Meister 
Shawn, thank you for you hint regarding the license. I will keep an eye on
that.

And thanks for testing.

The mentioned jvm.dll IS in the location where the log tells.
And Tomcat service runs as "local system account". I did not change
anything to the default values in the installer.

Very strange...

Ralf


Am Di., 27. Nov. 2018 um 16:10 Uhr schrieb Shawn Heisey :

> On 11/27/2018 3:08 AM, Andi Meister wrote:
> > What I did now:
> > - removed Tomcat services by service.bat
> > - uninstalled all Tomcats (7 and 9)
> > - uninstalled all Java (was only Version 11)
> > - server reboot
> > - Installed Java 11 (File: jdk-11.0.1_windows-x64_bin.exe)
>
> That filename tells me you're installing the JDK from Oracle.
>
> I have a side note for you:  The license for Java from Oracle has
> changed dramatically in version 11 compared to previous versions.
>
> If your use of Oracle Java will be for commercial or production, you
> have to pay Oracle a license fee for that machine.  The only way you can
> use their Java for free is if you're developing your application.  Once
> you deploy it to production running with Oracle Java 11, they expect
> payment.
>
> You might think I'm trying to pull a fast one here.  I'm not.  Right
> there in the license mentioned on the Java download page, under the
> "Further, You may not" section, is this bullet point: "use the Programs
> for any data processing or any commercial, production, or internal
> business purposes other than developing, testing, prototyping, and
> demonstrating your Application;"
>
>
> https://www.oracle.com/technetwork/java/javase/terms/license/javase-license.html
>
> So if you want to use Java 11 for production, get OpenJDK.It is still free.
>
> > [2018-11-27 10:56:50] [error] [ 3060] Failed creating Java C:\Program
> > Files\Java\jdk-11.0.1\bin\server\jvm.dll
>
> I downloaded Java 11 from Oracle's website, same executable filename you
> mentioned, and installed it.  The exact DLL path mentioned in this log
> entry is there.  If that DLL is there when you open the mentioned
> directory ... this problem makes me wonder if maybe the Tomcat service
> is running as a user that does not have permission to access that
> directory location, so it cannot find the parts of Java that it needs.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Translations update

2018-11-27 Thread tomcat 

On 27.11.2018 15:21, Mark Thomas wrote:

On 27/11/2018 13:19, Rémy Maucherat wrote:


Yes, I agree: it's not possible for non english speakers to use Tomcat, so
it did seem pointless. Mark still wanted to do the experiment, and since
the tool was easy and I had some time I did that French stuff. Anyway it's
done now, and people are sometimes happy to get i18n, so...


Congrats to everyone involved in completing the French translations and
in expanding the language coverage generally. And a special
congratulations / thank you to Rémy who contributed over 1700 (no, that
is not a typo!) translations.

I do think this experiment has been worthwhile.


Just as a note : I think so too.
But as far as I am concerned, the real usefulness was in showing how 
dully/repetitive/uncertain such an exercise could be, how this could easily result in 
imperfect/inconsistent translations (either stylistically, or technically) and in thinking 
about how this process could possibly be made more agreeable/efficient/accurate/sustainable.


 Yes, there are some

users who prefer English to their native language but there are also
some users who find the translations helpful.


No contest there.
What I am otherwise thinking is : there are many people who would like to look at an 
original tomcat logfile, and understand much of it, but still have trouble with a 
particular message or section. They might then want to quickly get a translation in their 
own language, to check that they really got it, and then go back to the original, to pick 
up the words in English that they will need, to search further (in Google, or in the 
documentation).  Because for these people, more often than not :
- changing the original language in which a tomcat server writes its logfile, will not be 
an option (think a corporate server e.g.)

- or repeating the issue after changing the logging language will not be an 
option
- or searching anywhere with the translated (non-english) message will not be a practical 
option.


 The good thing is that it

is easy to set Tomcat up to work either way.

I wonder. Is there any value in any of the following:

- The ability to change the language Tomcat uses while Tomcat is
running? I'm thinking an option exposed via JMX and the Manager app.

- The ability to 'translate' messages. I'm thinking something that takes
a message in one language, searches through the l10n strings to find a
match and then provides the same message in an alternative language.
Finding an efficient way to do this could be interesting.



I will take this as a oh-so-cautious acknowledgement that there might be something into 
the "translation-on-the-fly" idea.  But I think that it is still not exploiting the 
current available technology fully, in the sense that someone will still need to maintain 
these l10n files in the future, and I don't know how many Rémy's you are going to find 
(repeatedly) for doing that, at the tomcat level.


Allow me to be a bit megalomaniac maybe for an instant.
There are hundreds of projects on the Apache.org page.  Of these, maybe up to 50% are 
Java-based, so they use roughly the same techniques to log messages.

They are also all relatively within the same general "computer area" of course.
This would lead me to think that many of these projects may have
- the same kind of basic vocabulary
- the same kind of problematic, in terms of making technical info/warning/error messages, 
accessible preferably in many languages.
- the same kind of issues with keeping these messages and translations up-to-date, 
accurate, meaningful, consistent.

- the same kind of manpower issues to achieve that lofty goal
So why not be looking at creating a global "Apache thesaurus" containing all these 
technical terms and their translations (starting with tomcat of course), and creating some 
global plugin software that can handle such translations for all these projects ?

In other words, some kind of "log4j+i18n"..

Oh, wait : https://cwiki.apache.org/confluence/display/JOSHUA/




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

Re: [slightly OT] Re: Tomcat 9 does not work with Java 11

2018-11-27 Thread Shawn Heisey 

On 11/27/2018 3:08 AM, Andi Meister wrote:

What I did now:
- removed Tomcat services by service.bat
- uninstalled all Tomcats (7 and 9)
- uninstalled all Java (was only Version 11)
- server reboot
- Installed Java 11 (File: jdk-11.0.1_windows-x64_bin.exe)


That filename tells me you're installing the JDK from Oracle.

I have a side note for you:  The license for Java from Oracle has 
changed dramatically in version 11 compared to previous versions.


If your use of Oracle Java will be for commercial or production, you 
have to pay Oracle a license fee for that machine.  The only way you can 
use their Java for free is if you're developing your application.  Once 
you deploy it to production running with Oracle Java 11, they expect 
payment.


You might think I'm trying to pull a fast one here.  I'm not.  Right 
there in the license mentioned on the Java download page, under the 
"Further, You may not" section, is this bullet point: "use the Programs 
for any data processing or any commercial, production, or internal 
business purposes other than developing, testing, prototyping, and 
demonstrating your Application;"


https://www.oracle.com/technetwork/java/javase/terms/license/javase-license.html

So if you want to use Java 11 for production, get OpenJDK.It is still free.


[2018-11-27 10:56:50] [error] [ 3060] Failed creating Java C:\Program
Files\Java\jdk-11.0.1\bin\server\jvm.dll


I downloaded Java 11 from Oracle's website, same executable filename you 
mentioned, and installed it.  The exact DLL path mentioned in this log 
entry is there.  If that DLL is there when you open the mentioned 
directory ... this problem makes me wonder if maybe the Tomcat service 
is running as a user that does not have permission to access that 
directory location, so it cannot find the parts of Java that it needs.


Thanks,
Shawn


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

Re: Translations update

2018-11-27 Thread tomcat 

On 27.11.2018 13:13, PÉNET Ludovic wrote:

Le 27/11/2018 12:01, André Warnier a écrit :

On 26.11.2018 17:01, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 11/26/18 10:05, Rémy Maucherat wrote:



[...]


A corollary of this is that the error messages and the documentation
should agree with each other. Do we have French-language documentation
for this stuff?


+1
I believe that this is the important point, which I tried to
illustrate with the tongue-in-cheek example above.

+1



I must say that, although I tried to participate as much I could, I
have some reservations about this whole translation project.  And that
is because most of the original messages which I have seen, are really
"technical" and not at all oriented to a general public which may be
using applications built on tomcat, but rather to a public having to
deal specifically with tomcat Java code and tomcat configuration
files.
This public is going to need messages which they can later connect to
that code and/or to the configuration files language and/or to the
available documentation.
And let's face it : in terms of anything computer-related,
non-native-English-speakers (such as myself) lost out a long time ago,
and have had, and will have, to learn a modicum of English technical
computer language anyway, just to understand the basics of their field
of expertise.
That is not what most of us would culturally prefer, but it is a fact of life.

+1

[...]


I would go to https://translate.google.com, paste in the above
message, and instantly get :
French : "Impossible de trouver la classe principale:
org.apache.catalina.startup.Bootstrap. Le programme va sortir."

German : "Die Hauptklasse konnte nicht gefunden werden:
org.apache.catalina.startup.Bootstrap. Das Programm wird geschlossen."

Spanish : "No se pudo encontrar la clase principal:
org.apache.catalina.startup.Bootstrap. Programa saldrá."

Polish : "Nie można znaleźć głównej klasy:
org.apache.catalina.startup.Bootstrap. Program zostanie zamknięty."
(Note : I don't know anything about the Polish language, just adding
it for the fun; but also to ilustrate that the same website provides
dozens of target languages.)

The point is : are any of the above worse/better than what we get by
this current quite time-consuming one-off (but to remain relevant,
regularly repeated and maintained) translation effort, in the
perpective of the potential users of these messages ?


IMHO, you took an easy example... In a lot of cases, Google Translate was of no 
help when
trying to translate some more difficult strings. As pointed before, the 
original English
sentences are sometimes, hem, not Oxford English or the vocabulary really too 
specific.



1) disclaimer : I do not have any employment, commercial or other relations 
with Google.

2) I did not really take an "easy example". Well yes, I did : it just happened to be easy 
in the sense that it is was the first error message in a tomcat logfile that was lying 
around on my laptop.


But what I did do, was to take a complete sentence out of the logfile, and not just one 
word at a time, or a sentence containing "markers" (like the "{n}" things of these 
prototype messages we just translated).
Google translate seems to work many times better when what you feed it, are complete 
sentences instead of just words.
(Note: I did not really find this out, out of the blue. I found out because I was recently 
doing some marketing-text translation of my own, from German to English to Spanish, and 
although I know those languages reasonably, it was still a good help in merely 
figuring-out the style of the translations for phrases, and some specialised vocabulary).


3) I have tried more tomcat log messages since, and the results seem to be relatively 
consistent, as far as I am concerned.
Following are some additional examples taken from real tomcat logfiles, including some of 
which I remember seeing while translating in POEditor : (I'll just put the French 
translations this time, to stay in tune with the current thread; but I have checked the 
translation in some additional languages, and they look of similar quality.)


"SEVERE [ajp-nio-8009-exec-7] org.apache.coyote.ajp.AjpMessage.processHeader Invalid 
message received with signature 18245"
--> "SEVERE [ajp-nio-8009-exec-7] org.apache.coyote.ajp.AjpMessage.processHeader Message 
non valide reçu avec la signature 18245"


"Note: further occurrences of HTTP header parsing errors will be logged at DEBUG 
level."
--> "Remarque: les autres erreurs d'analyse d'en-tête HTTP seront enregistrées au niveau 
DEBUG."


"java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method 
names must be tokens"
--> "java.lang.IllegalArgumentException: caractère non valide trouvé dans le nom de la 
méthode. Les noms de méthodes HTTP doivent être des jetons."
(I admit that "jeton" may not be the best possible translation for "token" in the tomcat 
context, but

Re: [slightly OT] Re: Tomcat 9 does not work with Java 11

2018-11-27 Thread Mark Thomas 
On 27/11/2018 14:08, Eduardo Quintanilla wrote:
> A follow up question. When the option "Use default" is selected in the 
> Tomcatw manager. Where is that value configured? I assumed it was JAVA_HOME.

It is the default Java version configured in the registry. From memory
(it is a long time since I looked at this so I might have misremembered
/ Oracle might have changed how it works) there is a Java plug-in that
gets added to the control panel that lets you select the default version
from among the installed versions.

Mark


> 
> Eduardo Quintanilla
> Software Developer 
> Block Networks 
> 
> -Original Message-
> From: Mark Thomas  
> Sent: martes, 27 de noviembre de 2018 4:23 a. m.
> To: users@tomcat.apache.org
> Subject: Re: [slightly OT] Re: Tomcat 9 does not work with Java 11
> 
> On 27/11/2018 08:47, André Warnier (tomcat) wrote:
>> On 27.11.2018 01:49, Christopher Schultz wrote:
> 
> 
> 
>>> Hmm... just realized that the service.bat file might not be included 
>>> in the "installer" bundle. You might have to grab the ZIP bundle from 
>>> the Tomcat downloads site to get those scripts.
>>>
>>> - -chris
>>
>> This may be the right moment to suggest that this (these ?) ZIP
>> bundle(s) could be included by default, when running the installer 
>> (not unpacked, just copied along and dropped somewhere).  For as long 
>> as I can remember (which is getting somewhat shorter these days, but 
>> still goes back to tomcat 4.x), this has been an issue which regularly 
>> crops up with the Windows versions : whenever something goes wrong, 
>> people are being referred to files that they do not have, and it 
>> always takes a while to explain, download etc..
>> It would be easier if the files were already there anyway.
>> In the past, there may have been a concern for the extra size of the 
>> download (nowadays about 11 MB for each 32/64 bit version), but 
>> compared to many other downloads nowadays, this is still quite reasonable.
>> (And in fact, there are many common files, so not everything would 
>> have to be downloaded.  Also the 32-bit version is less useful these 
>> days.)
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=56323
> 
> It wasn't back-ported to 7.0.x. I'm not aware of of causing issues in 8.5.x 
> or 9.0.x so it could be back-ported.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: Translations update

2018-11-27 Thread Mark Thomas 
On 27/11/2018 13:19, Rémy Maucherat wrote:

> Yes, I agree: it's not possible for non english speakers to use Tomcat, so
> it did seem pointless. Mark still wanted to do the experiment, and since
> the tool was easy and I had some time I did that French stuff. Anyway it's
> done now, and people are sometimes happy to get i18n, so...

Congrats to everyone involved in completing the French translations and
in expanding the language coverage generally. And a special
congratulations / thank you to Rémy who contributed over 1700 (no, that
is not a typo!) translations.

I do think this experiment has been worthwhile. Yes, there are some
users who prefer English to their native language but there are also
some users who find the translations helpful. The good thing is that it
is easy to set Tomcat up to work either way.

I wonder. Is there any value in any of the following:

- The ability to change the language Tomcat uses while Tomcat is
running? I'm thinking an option exposed via JMX and the Manager app.

- The ability to 'translate' messages. I'm thinking something that takes
a message in one language, searches through the l10n strings to find a
match and then provides the same message in an alternative language.
Finding an efficient way to do this could be interesting.

Mark

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

RE: [slightly OT] Re: Tomcat 9 does not work with Java 11

2018-11-27 Thread Eduardo Quintanilla 
A follow up question. When the option "Use default" is selected in the Tomcatw 
manager. Where is that value configured? I assumed it was JAVA_HOME.

Eduardo Quintanilla
Software Developer 
Block Networks 

-Original Message-
From: Mark Thomas  
Sent: martes, 27 de noviembre de 2018 4:23 a. m.
To: users@tomcat.apache.org
Subject: Re: [slightly OT] Re: Tomcat 9 does not work with Java 11

On 27/11/2018 08:47, André Warnier (tomcat) wrote:
> On 27.11.2018 01:49, Christopher Schultz wrote:



>> Hmm... just realized that the service.bat file might not be included 
>> in the "installer" bundle. You might have to grab the ZIP bundle from 
>> the Tomcat downloads site to get those scripts.
>>
>> - -chris
> 
> This may be the right moment to suggest that this (these ?) ZIP
> bundle(s) could be included by default, when running the installer 
> (not unpacked, just copied along and dropped somewhere).  For as long 
> as I can remember (which is getting somewhat shorter these days, but 
> still goes back to tomcat 4.x), this has been an issue which regularly 
> crops up with the Windows versions : whenever something goes wrong, 
> people are being referred to files that they do not have, and it 
> always takes a while to explain, download etc..
> It would be easier if the files were already there anyway.
> In the past, there may have been a concern for the extra size of the 
> download (nowadays about 11 MB for each 32/64 bit version), but 
> compared to many other downloads nowadays, this is still quite reasonable.
> (And in fact, there are many common files, so not everything would 
> have to be downloaded.  Also the 32-bit version is less useful these 
> days.)

https://bz.apache.org/bugzilla/show_bug.cgi?id=56323

It wasn't back-ported to 7.0.x. I'm not aware of of causing issues in 8.5.x or 
9.0.x so it could be back-ported.

Mark

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


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

Re: Translations update

2018-11-27 Thread Rémy Maucherat 
On Tue, Nov 27, 2018 at 12:01 PM André Warnier (tomcat) 
wrote:

> I must say that, although I tried to participate as much I could, I have
> some reservations
> about this whole translation project.  And that is because most of the
> original messages
> which I have seen, are really "technical" and not at all oriented to a
> general public
> which may be using applications built on tomcat, but rather to a public
> having to deal
> specifically with tomcat Java code and tomcat configuration files.
> This public is going to need messages which they can later connect to that
> code and/or to
> the configuration files language and/or to the available documentation.
> And let's face it : in terms of anything computer-related,
> non-native-English-speakers
> (such as myself) lost out a long time ago, and have had, and will have, to
> learn a modicum
> of English technical computer language anyway, just to understand the
> basics of their
> field of expertise.
> That is not what most of us would culturally prefer, but it is a fact of
> life.
>

Yes, I agree: it's not possible for non english speakers to use Tomcat, so
it did seem pointless. Mark still wanted to do the experiment, and since
the tool was easy and I had some time I did that French stuff. Anyway it's
done now, and people are sometimes happy to get i18n, so...

Rémy

Re: Translations update

2018-11-27 Thread PÉNET Ludovic 

Le 27/11/2018 12:01, André Warnier a écrit :

On 26.11.2018 17:01, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 11/26/18 10:05, Rémy Maucherat wrote:



[...]


A corollary of this is that the error messages and the documentation
should agree with each other. Do we have French-language documentation
for this stuff?


+1
I believe that this is the important point, which I tried to
illustrate with the tongue-in-cheek example above.

+1



I must say that, although I tried to participate as much I could, I
have some reservations about this whole translation project.  And that
is because most of the original messages which I have seen, are really
"technical" and not at all oriented to a general public which may be
using applications built on tomcat, but rather to a public having to
deal specifically with tomcat Java code and tomcat configuration
files.
This public is going to need messages which they can later connect to
that code and/or to the configuration files language and/or to the
available documentation.
And let's face it : in terms of anything computer-related,
non-native-English-speakers (such as myself) lost out a long time ago,
and have had, and will have, to learn a modicum of English technical
computer language anyway, just to understand the basics of their field
of expertise.
That is not what most of us would culturally prefer, but it is a fact 
of life.

+1

[...]


I would go to https://translate.google.com, paste in the above
message, and instantly get :
French : "Impossible de trouver la classe principale:
org.apache.catalina.startup.Bootstrap. Le programme va sortir."

German : "Die Hauptklasse konnte nicht gefunden werden:
org.apache.catalina.startup.Bootstrap. Das Programm wird geschlossen."

Spanish : "No se pudo encontrar la clase principal:
org.apache.catalina.startup.Bootstrap. Programa saldrá."

Polish : "Nie można znaleźć głównej klasy:
org.apache.catalina.startup.Bootstrap. Program zostanie zamknięty."
(Note : I don't know anything about the Polish language, just adding
it for the fun; but also to ilustrate that the same website provides
dozens of target languages.)

The point is : are any of the above worse/better than what we get by
this current quite time-consuming one-off (but to remain relevant,
regularly repeated and maintained) translation effort, in the
perpective of the potential users of these messages ?


IMHO, you took an easy example... In a lot of cases, Google Translate 
was of no help when trying to translate some more difficult strings. As 
pointed before, the original English sentences are sometimes, hem, not 
Oxford English or the vocabulary really too specific.


How many times did I prefix a command with LANG=C to obtain a message I 
can search on Google ?

More than the finger count of all subscribers of this list, I guess...

I thought the same way as André when starting to translate strings, but 
I was both happy to find a way to help a bit the project.
If this kind of translation might not be most useful, translating 
manuals seems, however, more useful.


Ludovic

|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|


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

Re: Translations update

2018-11-27 Thread tomcat 

On 26.11.2018 17:01, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 11/26/18 10:05, Rémy Maucherat wrote:

On Mon, Nov 26, 2018 at 3:46 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

André,

On 11/26/18 08:35, André Warnier (tomcat) wrote:

On 26.11.2018 13:29, Rémy Maucherat wrote:

On Sat, Nov 24, 2018 at 9:48 AM Ludovic Pénet
 wrote:


Le vendredi 23 novembre 2018 à 23:51 +0100, Rémy Maucherat
a écrit :

On Wed, Nov 21, 2018 at 10:58 AM Mark Thomas
 wrote:


- French has increased from 18% to 64% coverage



Done (well, close enough, a few tribes/ha remain) !

A single translation remains to be performed.

Jump to https://poeditor.com/join/project/NUTIjDWzrl and be
the one to complete the French translation. ;-)



Ok, you could have finished it, I was busy.

Now we can try to harmonize terms, fixes are then easy to do
with the search feature

Common ones we have right now: - "socket" (usually
untranslated or cleverly omitted): ? - "endpoint" (for
websockets, and for the Tomcat connectors, so possibly two
different terms): "point d'entrée" ?


That sounds like exactly the opposite of "endpoint" to me.
Although I must say that even in English, the vocabulary used
in some reference documents (in particular everything to do
with XML-based protocols, such as SOAP, SAML, OASIS and the
like) is sometimes mysterious and counter-intuitive. What about
"cible" here ? Or more literally, "point final" ?


I disagree.

An "endpoint" is a thing to which clients connect... an "entry
point", as Rémy suggests.



French and English constructs are the opposite in a lot of cases so
that's why I though that "point d'entrée" was pretty good, as you
stay the endpoint for the client is the "startingpoint" for the
server (but there it sounds really bad).





For "socket", "soquet" (like the piece in which you insert a
plug, or a lightbulb) sounds ok to me.


This sounds okay to me, thought I don't know French at all. :)


- "thread" (often it is untranslated elsewhere): "fil
d'exécution" ? - "membership" (that's the clustering
object): "gestionnaire de membres" ?


"Membership" refers to "le fait d'être membre", no ? "adhésion"
? (like "cluster members" -> "adhérents au cluster" (with the
appropriate French pronounciation for "cleustère") :-)


What would you call a list of people who belong to a certain
fancy club or society? That's the word that should be used,
here.



So ... In that case it would simply be "liste de membres". Which
after a quick check actually looks quite good in the context of the
Tribes strings.

I have another difficult one for Tribes: that "replicated map"
which should be ?? "structure répliquée" ? I used various terms for
that annoying one ...


I'm a bug fan of naming things what they *mean*, not what they are.

For example, seeing this in code:

Map> mapOfStringToClass = ...;

Is totally worthless from a self-documenting code perspective. This is
much better:

   Map> beanImplementationClasses = ...;



or, even better from a French perspective :

   Carte> classedImplementationdHaricot = ...;

;-)


I think we should do the same thing with our descriptions, here.

So, for example, the fact that it's called "replicatedMap" in English
probably doesn't matter. The "replicated" part is important. The "map"
probably isn't. It could be any collection of objects. So, "replicated
structure" seems reasonable, here.

On the other hand, when saying "something is wrong with the
MacGuffin[1]", translating the word "MacGuffin" may make things worse.
If you want to know how to look it up in the documentation and/or
code, it needs to agree with what's there. Since the code is
(nominally) in English, the term might need to be in English.

A corollary of this is that the error messages and the documentation
should agree with each other. Do we have French-language documentation
for this stuff?


+1
I believe that this is the important point, which I tried to illustrate with the 
tongue-in-cheek example above.


I must say that, although I tried to participate as much I could, I have some reservations 
about this whole translation project.  And that is because most of the original messages 
which I have seen, are really "technical" and not at all oriented to a general public 
which may be using applications built on tomcat, but rather to a public having to deal 
specifically with tomcat Java code and tomcat configuration files.
This public is going to need messages which they can later connect to that code and/or to 
the configuration files language and/or to the available documentation.
And let's face it : in terms of anything computer-related, non-native-English-speakers 
(such as myself) lost out a long time ago, and have had, and will have, to learn a modicum 
of English technical computer language anyway, just to understand the basics of their 
field of expertise.

That is not what most of us would

Re: Translations update

2018-11-27 Thread PÉNET Ludovic 

Le 27/11/2018 11:51, Rémy Maucherat a écrit :

On Mon, Nov 26, 2018 at 5:31 PM André Warnier (tomcat) 
wrote:


On 26.11.2018 15:01, Ludovic Pénet wrote:
>>> - "endpoint" (for websockets, and for the Tomcat connectors, so
>> >possibly
>>> >>two different terms): "point d'entrée" ?
>> >
>> >That sounds like exactly the opposite of "endpoint" to me.
>> >Although I must say that even in English, the vocabulary used in some
>> >reference documents
>> >(in particular everything to do with XML-based protocols, such as SOAP,
>> >SAML, OASIS and
>> >the like) is sometimes mysterious and counter-intuitive.
>> >What about "cible" here ?
>> >Or more literally, "point final" ?
> Terminaison ?
>
>
>> >
+1 for "terminaison", else untranslated "endpoint".



Ok for "terminaison" in the end, updated.

Kinda meh for "répartiteur", which sounds ok in theory but not so great 
in

practice.

Example:
The dispatcher returned from the ServletContext does not support
asynchronous dispatching
->
Le répartiteur de Servlets retourné par le ServletContext ne supporte 
pas

de répartition (???) asynchrone
Looks like a good candidate for untranslated now ...

I might claim for this one. :-)

"Le répartiteur de Servlets retourné par le ServletContext n'est pas 
capable de fonctionner de manière asynchrone"


might be better.


@+!

Ludovic

|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|


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

Re: Translations update

2018-11-27 Thread Rémy Maucherat 
On Mon, Nov 26, 2018 at 5:31 PM André Warnier (tomcat) 
wrote:

> On 26.11.2018 15:01, Ludovic Pénet wrote:
> >>> - "endpoint" (for websockets, and for the Tomcat connectors, so
> >> >possibly
> >>> >>two different terms): "point d'entrée" ?
> >> >
> >> >That sounds like exactly the opposite of "endpoint" to me.
> >> >Although I must say that even in English, the vocabulary used in some
> >> >reference documents
> >> >(in particular everything to do with XML-based protocols, such as SOAP,
> >> >SAML, OASIS and
> >> >the like) is sometimes mysterious and counter-intuitive.
> >> >What about "cible" here ?
> >> >Or more literally, "point final" ?
> > Terminaison ?
> >
> >
> >> >
> +1 for "terminaison", else untranslated "endpoint".
>

Ok for "terminaison" in the end, updated.

Kinda meh for "répartiteur", which sounds ok in theory but not so great in
practice.

Example:
The dispatcher returned from the ServletContext does not support
asynchronous dispatching
->
Le répartiteur de Servlets retourné par le ServletContext ne supporte pas
de répartition (???) asynchrone
Looks like a good candidate for untranslated now ...

And for Tribes membership, I'm updating to "registre de membres" rather
than "liste", it sounds more service-ish like it actually does something
rather than being dumb and static.

Rémy

Re: [slightly OT] Re: Tomcat 9 does not work with Java 11

2018-11-27 Thread Mark Thomas 
On 27/11/2018 08:47, André Warnier (tomcat) wrote:
> On 27.11.2018 01:49, Christopher Schultz wrote:



>> Hmm... just realized that the service.bat file might not be included
>> in the "installer" bundle. You might have to grab the ZIP bundle from
>> the Tomcat downloads site to get those scripts.
>>
>> - -chris
> 
> This may be the right moment to suggest that this (these ?) ZIP
> bundle(s) could be included by default, when running the installer (not
> unpacked, just copied along and dropped somewhere).  For as long as I
> can remember (which is getting somewhat shorter these days, but still
> goes back to tomcat 4.x), this has been an issue which regularly crops
> up with the Windows versions : whenever something goes wrong, people are
> being referred to files that they do not have, and it always takes a
> while to explain, download etc..
> It would be easier if the files were already there anyway.
> In the past, there may have been a concern for the extra size of the
> download (nowadays about 11 MB for each 32/64 bit version), but compared
> to many other downloads nowadays, this is still quite reasonable.
> (And in fact, there are many common files, so not everything would have
> to be downloaded.  Also the 32-bit version is less useful these days.)

https://bz.apache.org/bugzilla/show_bug.cgi?id=56323

It wasn't back-ported to 7.0.x. I'm not aware of of causing issues in
8.5.x or 9.0.x so it could be back-ported.

Mark

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

Re: Overriding MultiPartConfig

2018-11-27 Thread Mark Thomas 
On 26/11/2018 21:57, Mark A. Claassen wrote:
> Thanks for the reply!
> 
> I have been working this for a while and having been failing.  There is so 
> much going on here that I don't understand that I feel like such a newby.
> 
> First, when the multi-part config is in my local web.xml, everything works.  
> However, if I remove that whole servlet from my web.xml, I see that Jersey 
> initializes my servlet on its own first, and then my context listener tries 
> to add it again and the registration object I get back from addServlet is 
> null.
> 
> I assume that Jersey is doing this auto-configuration based on the 
> annotations I use, but if this is true, why does it work when the 
> configuration is in my web.xml?  The org.apache.catalina.Wrapper created in 
> the Application has an Overridable property, but it is false here.

web.xml takes precedence over web-fragment.xml files and annotations
(Servlet spec rules for merging configuration settings).

I suspect Jersey sees there is no Servlet and defines a default.

Maybe try this and if this doesn't work ask the Jersey folks.

- Define the Servlet in web.xml

- In your ServletContextListener use
  ServletContext#getServletRegistrations() and find the Servlet in
  question

- Modify the MultiPartConfig for that Servlet as required.

HTH,

Mark


> 
> Any help would be appreciated.  Is this more of a Jersey question?
> 
> Mark Claassen
> Senior Software Engineer
> 
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN  46601
> E-mail: mailto:mclaas...@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>   
> ---
> Confidentiality Notice: OCIESERVICE
> ---
> The contents of this e-mail message and any attachments are intended solely 
> for the addressee(s) named in this message. This communication is intended to 
> be and to remain confidential. If you are not the intended recipient of this 
> message, or if this message has been addressed to you in error, please 
> immediately alert the sender by reply e-mail and then delete this message and 
> its attachments. Do not deliver, distribute, copy, disclose the contents or 
> take any action in reliance upon the information contained in the 
> communication or any attachments.
> 
> -Original Message-
> From: Mark Thomas  
> Sent: Monday, November 26, 2018 12:42 PM
> To: Tomcat Users List 
> Subject: Re: Overriding MultiPartConfig
> 
> On 26/11/2018 17:11, Mark A. Claassen wrote:
>> I am having trouble finding a way to override my MultiPart config.  I have a 
>> servlet with a configuration in the web.xml.
>>   
>> ...
>> 
>>   ...
>> 
>>   
>>
>> However, I would like to be able to be able to configure this outside of the 
>> web.xml file so it can be changed outside of the webapp directory.  Is there 
>> a way to do this from the "context" in the conf/Catalina/localhost directory?
> 
> No.
> 
>> Doing it programmatically would be ok for me as well, but I can't find 
>> anyway to access the multi-part config through the standard APIs.
> 
> You can only do this if you remove the entry from web.xml.
> 
> You'd need to register the servlet in a ServletContextListener and then use 
> ServletContext#addServlet() and then ServletRegistration.Dynamic#
> setMultipartConfig()
> 
> (along with ading any other configuration / mapping required by the servlet)
> 
>> I don't think I can use the annotation @MultipartConfig since I am writing 
>> something that extends javax.ws.rs.core.Application and I need to be able to 
>> configure this at startup time.
> 
> @MultipartConfig has to be added to a Servlet class and can only be changed 
> by recompilation - which is more work than changing web.xml.
> 
>> I am just using Jersey, running inside of Tomcat.
>>
>> Thanks!
>>
>> Mark Claassen
>> Senior Software Engineer
>>
>> Donnell Systems, Inc.
>> 130 South Main Street
>> Leighton Plaza Suite 375
>> South Bend, IN  46601
>> E-mail: mailto:mclaas...@ocie.net
>> Voice: (574)232-3784
>> Fax: (574)232-4014
>>
>> Disclaimer:
>> The opinions provided herein do not necessarily state or reflect those 
>> of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes 
>> no legal liability or responsibility for the posting.
>>
>>
> 
> 
> -
> 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:

Re: [slightly OT] Re: Tomcat 9 does not work with Java 11

2018-11-27 Thread Andi Meister 
What I did now:
- removed Tomcat services by service.bat
- uninstalled all Tomcats (7 and 9)
- uninstalled all Java (was only Version 11)
- server reboot
- Installed Java 11 (File: jdk-11.0.1_windows-x64_bin.exe)
- reboot
- Installed Tomcat 9 (File: apache-tomcat-9.0.13.exe)
- During installation I was asked for the path to Java (field was empty). I
entered the path to the root of Java 11: C:\Program Files\Java\jdk-11.0.1
- Start Service at the end of the installation

And again this error:

[2018-11-27 10:56:50] [info]  [ 3208] Commons Daemon procrun (1.1.0.0
64-bit) started

[2018-11-27 10:56:50] [info]  [ 3208] Running 'Tomcat9' Service...

[2018-11-27 10:56:50] [info]  [ 3060] Starting service...

[2018-11-27 10:56:50] [error] [ 3060] The specified procedure could not be
found.

[2018-11-27 10:56:50] [error] [ 3060] Failed creating Java C:\Program
Files\Java\jdk-11.0.1\bin\server\jvm.dll

[2018-11-27 10:56:50] [error] [ 3060] The specified procedure could not be
found.

[2018-11-27 10:56:50] [error] [ 3060] ServiceStart returned 1

[2018-11-27 10:56:50] [error] [ 3060] The specified procedure could not be
found.

[2018-11-27 10:56:50] [info]  [ 3208] Run service finished.

[2018-11-27 10:56:50] [info]  [ 3208] Commons Daemon procrun finished


Am Di., 27. Nov. 2018 um 10:50 Uhr schrieb Andi Meister <
blackpum...@googlemail.com>:

> Chris,
> I tried your suggestions, but it did not help. Still the same error.
> I will now try a complete remove of Java and Tomcat.
> Then install Java11 and after that install Tomcat9.
>
> Andre,
> I can report that in Tomcat 7 there is no service.bat etc.
> But in Tomcat 9 everything is there in the bin folder.
>
> Ralf
>
>
> Am Di., 27. Nov. 2018 um 09:47 Uhr schrieb André Warnier (tomcat) <
> a...@ice-sa.com>:
>
>> On 27.11.2018 01:49, Christopher Schultz wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA256
>> >
>> > Andi,
>> >
>> > On 11/26/18 15:08, Andi Meister wrote:
>> >> Tomorrow I will try it on an other machine with no previous Tomcat
>> >> installed. But my problem is that I have to get it to run on this
>> >> machine. What could I do? First uninstall all jdks and Tomcats and
>> >> then install jdk11 and newest Tomcat?
>> >
>> > You might want to:
>> >
>> > 1. C:...\tomcat-7> bin\service.bat remove  (optional name parameter)
>> >
>> > 2. C:...\tomcat-9> bin\service.bat install (optional name parameter)
>> >
>> > Something might be broken in the service definition, and this should
>> > reset everything. Note that any of the system properties you might
>> > have defined in the existing service will be wiped-out by this
>> > process. So, you might want to take a few screenshots of the various
>> > configuration screens if you are using anything other than the plain
>> > defaults.
>> >
>> > Hmm... just realized that the service.bat file might not be included
>> > in the "installer" bundle. You might have to grab the ZIP bundle from
>> > the Tomcat downloads site to get those scripts.
>> >
>> > - -chris
>>
>> This may be the right moment to suggest that this (these ?) ZIP bundle(s)
>> could be
>> included by default, when running the installer (not unpacked, just
>> copied along and
>> dropped somewhere).  For as long as I can remember (which is getting
>> somewhat shorter
>> these days, but still goes back to tomcat 4.x), this has been an issue
>> which regularly
>> crops up with the Windows versions : whenever something goes wrong,
>> people are being
>> referred to files that they do not have, and it always takes a while to
>> explain, download
>> etc..
>> It would be easier if the files were already there anyway.
>> In the past, there may have been a concern for the extra size of the
>> download (nowadays
>> about 11 MB for each 32/64 bit version), but compared to many other
>> downloads nowadays,
>> this is still quite reasonable.
>> (And in fact, there are many common files, so not everything would have
>> to be downloaded.
>>   Also the 32-bit version is less useful these days.)
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

[OT] Re: Connection pool and parallel deployment problem

2018-11-27 Thread tomcat 

On 27.11.2018 10:13, Esther Montes wrote:

Buenas tardes nomás kiero saber si tengo que ir otra vez  al banco para
para  q me meten unas claves o asi me va a entregar los depósitos


Either this is some fiendishly elaborate new scam method of which I haven't heard before, 
or else there is someone hopelessly confused out there..





El mar., 27 de nov. de 2018 1:03 AM, Gilles SCHLIENGER <
gilles.schlien...@cncc.fr> escribió:


Thanks a lot Heegu,

I looked at your project on github.
1. Which part of the code is exporting JMX beans ? Is it the @ManagedBean
annotation ?

2. What do you use JMX for ?

Thanks again
Regards
Gilles


-Message d'origine-
De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
Envoyé : mardi 27 novembre 2018 08:36
À : Tomcat Users List
Objet : Re: Connection pool and parallel deployment problem

Dear Gilles,

I apologize for the delay in reply.

I make simple webapp and upload to github. In project, my test result is
included.

https://github.com/elfhazardwork/dbcp2-test

Tomcat's parallel deploy mechanism is deploy new version before undeploy
old.
So, If your webapp is use JMX, bean name will duplicate and crush.

The connection pool is used where the developer does not explicitly declare
JXM.
So this is a Tomcat bug.
Otherwise, you must set JMX bean name dynamically.

I hope this helps.


2018년 11월 27일 (화) 오전 2:03, Chris Cheshire 님이 작성:


On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
 wrote:


Hi,
I understand your needs, but what is your problem, since you don't use

parallel deployment ?

Your connections are not closed but they will not be recreated when you

deploy your webapp again, so there should be no problem ?


Gilles



I added my 2c because I am seeing what you describe here


- I undeploy the first version of the webapp
- I check on my postgresql and mysql database and all connections are

still opened (even if I wait for a long time)


Yes I know you are using parallel deployment and I am not, but that
doesn't necessarily mean that the problem you see is limited to only
parallel deployment. Maybe the problem can be simplified to "
Tomcat considers the connections closed, the database doesn't."

I could well be wrong, I'll leave it up to the gurus to decide :)



-Message d'origine-
De : Chris Cheshire [mailto:yahoono...@gmail.com]
Envoyé : lundi 26 novembre 2018 15:27
À : Tomcat Users List
Objet : Re: Connection pool and parallel deployment problem

I'm interested in what solution there is for this because I have the
exact same problem but without parallel deployment.

[snip]

On Mon, Nov 26, 2018 at 3:54 AM Gilles SCHLIENGER
 wrote:


Hi Christopher,

Thanks for your email.

About connection pools not being closed, maybe the connection pool is

closed but the connections to the database are not.


Here are the tests I did:

+ TEST 1:
- I deploy my war
- I login to my webapp
- I check on my postgresql and mysql database that connections have

been opened (select...)

- I undeploy my webapp through the manager webapp
- I check that the connections are still opened
- Tomcat is still running
- I redeploy the exact samed webapp and login to my application
- No other connection is being opened

+ TEST 2:
- I deploy my war
- I login to my webapp
- I check on my postgresql and mysql database that connections have

been opened (select...)

- I deploy a new version of my application and login with another

browser

- I check on my postgresql and mysql database that new connexions

have

been opened (they doubled)

- I undeploy the first version of the webapp
- I check on my postgresql and mysql database and all connections are

still opened (even if I wait for a long time)


For tests 1 and 2, I used C3p0, DBCP2 and even HikariCP




My results are the same. Using mysql, connection pools defined in
server.xml (for user realm for access control to host manager app) and
in my context.xml for my application. When I use the host-manager to
reload an app, the connections are closed (no abandoned connection
warnings) but not released. It is no until I stop tomcat completely
and restart it that the connections are released in mysql. This has
been the case for tomcat 7, 8.5 and 9 versions, with constant updates
of mysql 5.7 and its driver, using both the apache connection pool and
the tomcat connection pool. The driver lives in the tomcat/lib
directory (since it is needed for the user realm datasource).



-Message d'origine-
De : Christopher Schultz [mailto:ch...@christopherschultz.net]
Envoyé : samedi 24 novembre 2018 17:19
À : users@tomcat.apache.org
Objet : Re: Connection pool and parallel deployment problem

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gilles,

On 11/23/18 05:07, Gilles SCHLIENGER wrote:


[snip]




The warning/error messages are not actually linked to the
connexions not closed. To ovoid these messages, you can: - move the
jars (connexion pool, drivers...) into TOMCAT/lib - Have a
ServletContextListener that calls

Re: [slightly OT] Re: Tomcat 9 does not work with Java 11

2018-11-27 Thread Andi Meister 
Chris,
I tried your suggestions, but it did not help. Still the same error.
I will now try a complete remove of Java and Tomcat.
Then install Java11 and after that install Tomcat9.

Andre,
I can report that in Tomcat 7 there is no service.bat etc.
But in Tomcat 9 everything is there in the bin folder.

Ralf


Am Di., 27. Nov. 2018 um 09:47 Uhr schrieb André Warnier (tomcat) <
a...@ice-sa.com>:

> On 27.11.2018 01:49, Christopher Schultz wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Andi,
> >
> > On 11/26/18 15:08, Andi Meister wrote:
> >> Tomorrow I will try it on an other machine with no previous Tomcat
> >> installed. But my problem is that I have to get it to run on this
> >> machine. What could I do? First uninstall all jdks and Tomcats and
> >> then install jdk11 and newest Tomcat?
> >
> > You might want to:
> >
> > 1. C:...\tomcat-7> bin\service.bat remove  (optional name parameter)
> >
> > 2. C:...\tomcat-9> bin\service.bat install (optional name parameter)
> >
> > Something might be broken in the service definition, and this should
> > reset everything. Note that any of the system properties you might
> > have defined in the existing service will be wiped-out by this
> > process. So, you might want to take a few screenshots of the various
> > configuration screens if you are using anything other than the plain
> > defaults.
> >
> > Hmm... just realized that the service.bat file might not be included
> > in the "installer" bundle. You might have to grab the ZIP bundle from
> > the Tomcat downloads site to get those scripts.
> >
> > - -chris
>
> This may be the right moment to suggest that this (these ?) ZIP bundle(s)
> could be
> included by default, when running the installer (not unpacked, just copied
> along and
> dropped somewhere).  For as long as I can remember (which is getting
> somewhat shorter
> these days, but still goes back to tomcat 4.x), this has been an issue
> which regularly
> crops up with the Windows versions : whenever something goes wrong, people
> are being
> referred to files that they do not have, and it always takes a while to
> explain, download
> etc..
> It would be easier if the files were already there anyway.
> In the past, there may have been a concern for the extra size of the
> download (nowadays
> about 11 MB for each 32/64 bit version), but compared to many other
> downloads nowadays,
> this is still quite reasonable.
> (And in fact, there are many common files, so not everything would have to
> be downloaded.
>   Also the 32-bit version is less useful these days.)
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Character encoding problems using jsp:include with jsp:param in Tomcat 8.5 only.

2018-11-27 Thread Thorsten Schöning 
Guten Tag Christopher Schultz,
am Montag, 26. November 2018 um 16:07 schrieben Sie:

> web.xml
> - ---
> 
>   UTF-8
> 

Tested that with Tomcat 9 and this setting fixed my problem the same
as using SetCharacterEncodingFilter. It doesn't work in Tomcat 8.5, I
guess because that simply doesn't implement Servlet 4.0?

Because I still need to support Tomcat 7 and 8.0 for some time, I'll
keep SetCharacterEncodingFilter for now and just document the better
solution. Thanks!

P.S.:

I've send you a private mail some days ago, unrelated to Tomcat. Did
you get that? Just want to make sure that I'm not spam filtered.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


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

RE: Connection pool and parallel deployment problem

2018-11-27 Thread Gilles SCHLIENGER 
You can try HikariCP, it is mentionned in the Spring documentation


-Message d'origine-
De : HeeGu Lee [mailto:elfhazardw...@gmail.com] 
Envoyé : mardi 27 novembre 2018 10:28
À : Tomcat Users List
Objet : Re: Connection pool and parallel deployment problem

I'm glad to solve problem.
But I am concerned that the C3p0 is not updated since 2015.

Let's hope for a better library.
Bye~

2018년 11월 27일 (화) 오후 6:20, Gilles SCHLIENGER 님이
작성:

> Thanks,
>
> I don't have this problem using C3p0
>
> Parallel deployment is working fine so far, especially now that we will
> use connection pools configured inside the webapp (no more context xml file)
>
> Regards
> Gilles
>
> -Message d'origine-
> De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
> Envoyé : mardi 27 novembre 2018 10:17
> À : Tomcat Users List
> Objet : Re: Connection pool and parallel deployment problem
>
> 1. JMX registration is call by BasicDataSource of apache commons-dbcp2
> library.
> It is hidden inside and can not be controlled.
>
> The name of the spring bean is referenced as part of the JMX name.
> You can change the bean name for each distribution.
> But that is not smart.
>
> 2. Usually, JMX is use for system monitoring.
> Using tool like grafana, you will see jvm heap momory, running thread
> count, network traffic of Tomcat.
>
>
> 2018년 11월 27일 (화) 오후 6:03, Gilles SCHLIENGER 님이
> 작성:
>
> > Thanks a lot Heegu,
> >
> > I looked at your project on github.
> > 1. Which part of the code is exporting JMX beans ? Is it the @ManagedBean
> > annotation ?
> >
> > 2. What do you use JMX for ?
> >
> > Thanks again
> > Regards
> > Gilles
> >
> >
> > -Message d'origine-
> > De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
> > Envoyé : mardi 27 novembre 2018 08:36
> > À : Tomcat Users List
> > Objet : Re: Connection pool and parallel deployment problem
> >
> > Dear Gilles,
> >
> > I apologize for the delay in reply.
> >
> > I make simple webapp and upload to github. In project, my test result is
> > included.
> >
> > https://github.com/elfhazardwork/dbcp2-test
> >
> > Tomcat's parallel deploy mechanism is deploy new version before undeploy
> > old.
> > So, If your webapp is use JMX, bean name will duplicate and crush.
> >
> > The connection pool is used where the developer does not explicitly
> declare
> > JXM.
> > So this is a Tomcat bug.
> > Otherwise, you must set JMX bean name dynamically.
> >
> > I hope this helps.
> >
> >
> > 2018년 11월 27일 (화) 오전 2:03, Chris Cheshire 님이 작성:
> >
> > > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
> > >  wrote:
> > > >
> > > > Hi,
> > > > I understand your needs, but what is your problem, since you don't
> use
> > > parallel deployment ?
> > > > Your connections are not closed but they will not be recreated when
> you
> > > deploy your webapp again, so there should be no problem ?
> > > >
> > > > Gilles
> > > >
> > >
> > > I added my 2c because I am seeing what you describe here
> > >
> > > > > - I undeploy the first version of the webapp
> > > > > - I check on my postgresql and mysql database and all connections
> are
> > > still opened (even if I wait for a long time)
> > >
> > >
> > > Yes I know you are using parallel deployment and I am not, but that
> > > doesn't necessarily mean that the problem you see is limited to only
> > > parallel deployment. Maybe the problem can be simplified to "
> > > Tomcat considers the connections closed, the database doesn't."
> > >
> > > I could well be wrong, I'll leave it up to the gurus to decide :)
> > >
> > >
> > > > -Message d'origine-
> > > > De : Chris Cheshire [mailto:yahoono...@gmail.com]
> > > > Envoyé : lundi 26 novembre 2018 15:27
> > > > À : Tomcat Users List
> > > > Objet : Re: Connection pool and parallel deployment problem
> > > >
> > > > I'm interested in what solution there is for this because I have the
> > > > exact same problem but without parallel deployment.
> > > >
> > > > [snip]
> > > >
> > > > On Mon, Nov 26, 2018 at 3:54 AM Gilles SCHLIENGER
> > > >  wrote:
> > > > >
> > > > > Hi Christopher,
> > > > >
> > > > > Thanks for your email.
> > > > >
> > > > > About connection pools not being closed, maybe the connection pool
> is
> > > closed but the connections to the database are not.
> > > > >
> > > > > Here are the tests I did:
> > > > >
> > > > > + TEST 1:
> > > > > - I deploy my war
> > > > > - I login to my webapp
> > > > > - I check on my postgresql and mysql database that connections have
> > > been opened (select...)
> > > > > - I undeploy my webapp through the manager webapp
> > > > > - I check that the connections are still opened
> > > > > - Tomcat is still running
> > > > > - I redeploy the exact samed webapp and login to my application
> > > > > - No other connection is being opened
> > > > >
> > > > > + TEST 2:
> > > > > - I deploy my war
> > > > > - I login to my webapp
> > > > > - I check on my postgresql and mysql database that connections have
> > > been opened (select...)
> > > > > - I deploy a new

Re: Connection pool and parallel deployment problem

2018-11-27 Thread HeeGu Lee 
I'm glad to solve problem.
But I am concerned that the C3p0 is not updated since 2015.

Let's hope for a better library.
Bye~

2018년 11월 27일 (화) 오후 6:20, Gilles SCHLIENGER 님이
작성:

> Thanks,
>
> I don't have this problem using C3p0
>
> Parallel deployment is working fine so far, especially now that we will
> use connection pools configured inside the webapp (no more context xml file)
>
> Regards
> Gilles
>
> -Message d'origine-
> De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
> Envoyé : mardi 27 novembre 2018 10:17
> À : Tomcat Users List
> Objet : Re: Connection pool and parallel deployment problem
>
> 1. JMX registration is call by BasicDataSource of apache commons-dbcp2
> library.
> It is hidden inside and can not be controlled.
>
> The name of the spring bean is referenced as part of the JMX name.
> You can change the bean name for each distribution.
> But that is not smart.
>
> 2. Usually, JMX is use for system monitoring.
> Using tool like grafana, you will see jvm heap momory, running thread
> count, network traffic of Tomcat.
>
>
> 2018년 11월 27일 (화) 오후 6:03, Gilles SCHLIENGER 님이
> 작성:
>
> > Thanks a lot Heegu,
> >
> > I looked at your project on github.
> > 1. Which part of the code is exporting JMX beans ? Is it the @ManagedBean
> > annotation ?
> >
> > 2. What do you use JMX for ?
> >
> > Thanks again
> > Regards
> > Gilles
> >
> >
> > -Message d'origine-
> > De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
> > Envoyé : mardi 27 novembre 2018 08:36
> > À : Tomcat Users List
> > Objet : Re: Connection pool and parallel deployment problem
> >
> > Dear Gilles,
> >
> > I apologize for the delay in reply.
> >
> > I make simple webapp and upload to github. In project, my test result is
> > included.
> >
> > https://github.com/elfhazardwork/dbcp2-test
> >
> > Tomcat's parallel deploy mechanism is deploy new version before undeploy
> > old.
> > So, If your webapp is use JMX, bean name will duplicate and crush.
> >
> > The connection pool is used where the developer does not explicitly
> declare
> > JXM.
> > So this is a Tomcat bug.
> > Otherwise, you must set JMX bean name dynamically.
> >
> > I hope this helps.
> >
> >
> > 2018년 11월 27일 (화) 오전 2:03, Chris Cheshire 님이 작성:
> >
> > > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
> > >  wrote:
> > > >
> > > > Hi,
> > > > I understand your needs, but what is your problem, since you don't
> use
> > > parallel deployment ?
> > > > Your connections are not closed but they will not be recreated when
> you
> > > deploy your webapp again, so there should be no problem ?
> > > >
> > > > Gilles
> > > >
> > >
> > > I added my 2c because I am seeing what you describe here
> > >
> > > > > - I undeploy the first version of the webapp
> > > > > - I check on my postgresql and mysql database and all connections
> are
> > > still opened (even if I wait for a long time)
> > >
> > >
> > > Yes I know you are using parallel deployment and I am not, but that
> > > doesn't necessarily mean that the problem you see is limited to only
> > > parallel deployment. Maybe the problem can be simplified to "
> > > Tomcat considers the connections closed, the database doesn't."
> > >
> > > I could well be wrong, I'll leave it up to the gurus to decide :)
> > >
> > >
> > > > -Message d'origine-
> > > > De : Chris Cheshire [mailto:yahoono...@gmail.com]
> > > > Envoyé : lundi 26 novembre 2018 15:27
> > > > À : Tomcat Users List
> > > > Objet : Re: Connection pool and parallel deployment problem
> > > >
> > > > I'm interested in what solution there is for this because I have the
> > > > exact same problem but without parallel deployment.
> > > >
> > > > [snip]
> > > >
> > > > On Mon, Nov 26, 2018 at 3:54 AM Gilles SCHLIENGER
> > > >  wrote:
> > > > >
> > > > > Hi Christopher,
> > > > >
> > > > > Thanks for your email.
> > > > >
> > > > > About connection pools not being closed, maybe the connection pool
> is
> > > closed but the connections to the database are not.
> > > > >
> > > > > Here are the tests I did:
> > > > >
> > > > > + TEST 1:
> > > > > - I deploy my war
> > > > > - I login to my webapp
> > > > > - I check on my postgresql and mysql database that connections have
> > > been opened (select...)
> > > > > - I undeploy my webapp through the manager webapp
> > > > > - I check that the connections are still opened
> > > > > - Tomcat is still running
> > > > > - I redeploy the exact samed webapp and login to my application
> > > > > - No other connection is being opened
> > > > >
> > > > > + TEST 2:
> > > > > - I deploy my war
> > > > > - I login to my webapp
> > > > > - I check on my postgresql and mysql database that connections have
> > > been opened (select...)
> > > > > - I deploy a new version of my application and login with another
> > > browser
> > > > > - I check on my postgresql and mysql database that new connexions
> > have
> > > been opened (they doubled)
> > > > > - I undeploy the first version of the webapp
> > > > > - I check on my postgresql

RE: Connection pool and parallel deployment problem

2018-11-27 Thread Gilles SCHLIENGER 
Thanks,

I don't have this problem using C3p0

Parallel deployment is working fine so far, especially now that we will use 
connection pools configured inside the webapp (no more context xml file)

Regards
Gilles

-Message d'origine-
De : HeeGu Lee [mailto:elfhazardw...@gmail.com] 
Envoyé : mardi 27 novembre 2018 10:17
À : Tomcat Users List
Objet : Re: Connection pool and parallel deployment problem

1. JMX registration is call by BasicDataSource of apache commons-dbcp2
library.
It is hidden inside and can not be controlled.

The name of the spring bean is referenced as part of the JMX name.
You can change the bean name for each distribution.
But that is not smart.

2. Usually, JMX is use for system monitoring.
Using tool like grafana, you will see jvm heap momory, running thread
count, network traffic of Tomcat.


2018년 11월 27일 (화) 오후 6:03, Gilles SCHLIENGER 님이
작성:

> Thanks a lot Heegu,
>
> I looked at your project on github.
> 1. Which part of the code is exporting JMX beans ? Is it the @ManagedBean
> annotation ?
>
> 2. What do you use JMX for ?
>
> Thanks again
> Regards
> Gilles
>
>
> -Message d'origine-
> De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
> Envoyé : mardi 27 novembre 2018 08:36
> À : Tomcat Users List
> Objet : Re: Connection pool and parallel deployment problem
>
> Dear Gilles,
>
> I apologize for the delay in reply.
>
> I make simple webapp and upload to github. In project, my test result is
> included.
>
> https://github.com/elfhazardwork/dbcp2-test
>
> Tomcat's parallel deploy mechanism is deploy new version before undeploy
> old.
> So, If your webapp is use JMX, bean name will duplicate and crush.
>
> The connection pool is used where the developer does not explicitly declare
> JXM.
> So this is a Tomcat bug.
> Otherwise, you must set JMX bean name dynamically.
>
> I hope this helps.
>
>
> 2018년 11월 27일 (화) 오전 2:03, Chris Cheshire 님이 작성:
>
> > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
> >  wrote:
> > >
> > > Hi,
> > > I understand your needs, but what is your problem, since you don't use
> > parallel deployment ?
> > > Your connections are not closed but they will not be recreated when you
> > deploy your webapp again, so there should be no problem ?
> > >
> > > Gilles
> > >
> >
> > I added my 2c because I am seeing what you describe here
> >
> > > > - I undeploy the first version of the webapp
> > > > - I check on my postgresql and mysql database and all connections are
> > still opened (even if I wait for a long time)
> >
> >
> > Yes I know you are using parallel deployment and I am not, but that
> > doesn't necessarily mean that the problem you see is limited to only
> > parallel deployment. Maybe the problem can be simplified to "
> > Tomcat considers the connections closed, the database doesn't."
> >
> > I could well be wrong, I'll leave it up to the gurus to decide :)
> >
> >
> > > -Message d'origine-
> > > De : Chris Cheshire [mailto:yahoono...@gmail.com]
> > > Envoyé : lundi 26 novembre 2018 15:27
> > > À : Tomcat Users List
> > > Objet : Re: Connection pool and parallel deployment problem
> > >
> > > I'm interested in what solution there is for this because I have the
> > > exact same problem but without parallel deployment.
> > >
> > > [snip]
> > >
> > > On Mon, Nov 26, 2018 at 3:54 AM Gilles SCHLIENGER
> > >  wrote:
> > > >
> > > > Hi Christopher,
> > > >
> > > > Thanks for your email.
> > > >
> > > > About connection pools not being closed, maybe the connection pool is
> > closed but the connections to the database are not.
> > > >
> > > > Here are the tests I did:
> > > >
> > > > + TEST 1:
> > > > - I deploy my war
> > > > - I login to my webapp
> > > > - I check on my postgresql and mysql database that connections have
> > been opened (select...)
> > > > - I undeploy my webapp through the manager webapp
> > > > - I check that the connections are still opened
> > > > - Tomcat is still running
> > > > - I redeploy the exact samed webapp and login to my application
> > > > - No other connection is being opened
> > > >
> > > > + TEST 2:
> > > > - I deploy my war
> > > > - I login to my webapp
> > > > - I check on my postgresql and mysql database that connections have
> > been opened (select...)
> > > > - I deploy a new version of my application and login with another
> > browser
> > > > - I check on my postgresql and mysql database that new connexions
> have
> > been opened (they doubled)
> > > > - I undeploy the first version of the webapp
> > > > - I check on my postgresql and mysql database and all connections are
> > still opened (even if I wait for a long time)
> > > >
> > > > For tests 1 and 2, I used C3p0, DBCP2 and even HikariCP
> > > >
> > >
> > >
> > > My results are the same. Using mysql, connection pools defined in
> > > server.xml (for user realm for access control to host manager app) and
> > > in my context.xml for my application. When I use the host-manager to
> > > reload an app, the connections are closed (no abandoned

Re: Connection pool and parallel deployment problem

2018-11-27 Thread HeeGu Lee 
1. JMX registration is call by BasicDataSource of apache commons-dbcp2
library.
It is hidden inside and can not be controlled.

The name of the spring bean is referenced as part of the JMX name.
You can change the bean name for each distribution.
But that is not smart.

2. Usually, JMX is use for system monitoring.
Using tool like grafana, you will see jvm heap momory, running thread
count, network traffic of Tomcat.


2018년 11월 27일 (화) 오후 6:03, Gilles SCHLIENGER 님이
작성:

> Thanks a lot Heegu,
>
> I looked at your project on github.
> 1. Which part of the code is exporting JMX beans ? Is it the @ManagedBean
> annotation ?
>
> 2. What do you use JMX for ?
>
> Thanks again
> Regards
> Gilles
>
>
> -Message d'origine-
> De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
> Envoyé : mardi 27 novembre 2018 08:36
> À : Tomcat Users List
> Objet : Re: Connection pool and parallel deployment problem
>
> Dear Gilles,
>
> I apologize for the delay in reply.
>
> I make simple webapp and upload to github. In project, my test result is
> included.
>
> https://github.com/elfhazardwork/dbcp2-test
>
> Tomcat's parallel deploy mechanism is deploy new version before undeploy
> old.
> So, If your webapp is use JMX, bean name will duplicate and crush.
>
> The connection pool is used where the developer does not explicitly declare
> JXM.
> So this is a Tomcat bug.
> Otherwise, you must set JMX bean name dynamically.
>
> I hope this helps.
>
>
> 2018년 11월 27일 (화) 오전 2:03, Chris Cheshire 님이 작성:
>
> > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
> >  wrote:
> > >
> > > Hi,
> > > I understand your needs, but what is your problem, since you don't use
> > parallel deployment ?
> > > Your connections are not closed but they will not be recreated when you
> > deploy your webapp again, so there should be no problem ?
> > >
> > > Gilles
> > >
> >
> > I added my 2c because I am seeing what you describe here
> >
> > > > - I undeploy the first version of the webapp
> > > > - I check on my postgresql and mysql database and all connections are
> > still opened (even if I wait for a long time)
> >
> >
> > Yes I know you are using parallel deployment and I am not, but that
> > doesn't necessarily mean that the problem you see is limited to only
> > parallel deployment. Maybe the problem can be simplified to "
> > Tomcat considers the connections closed, the database doesn't."
> >
> > I could well be wrong, I'll leave it up to the gurus to decide :)
> >
> >
> > > -Message d'origine-
> > > De : Chris Cheshire [mailto:yahoono...@gmail.com]
> > > Envoyé : lundi 26 novembre 2018 15:27
> > > À : Tomcat Users List
> > > Objet : Re: Connection pool and parallel deployment problem
> > >
> > > I'm interested in what solution there is for this because I have the
> > > exact same problem but without parallel deployment.
> > >
> > > [snip]
> > >
> > > On Mon, Nov 26, 2018 at 3:54 AM Gilles SCHLIENGER
> > >  wrote:
> > > >
> > > > Hi Christopher,
> > > >
> > > > Thanks for your email.
> > > >
> > > > About connection pools not being closed, maybe the connection pool is
> > closed but the connections to the database are not.
> > > >
> > > > Here are the tests I did:
> > > >
> > > > + TEST 1:
> > > > - I deploy my war
> > > > - I login to my webapp
> > > > - I check on my postgresql and mysql database that connections have
> > been opened (select...)
> > > > - I undeploy my webapp through the manager webapp
> > > > - I check that the connections are still opened
> > > > - Tomcat is still running
> > > > - I redeploy the exact samed webapp and login to my application
> > > > - No other connection is being opened
> > > >
> > > > + TEST 2:
> > > > - I deploy my war
> > > > - I login to my webapp
> > > > - I check on my postgresql and mysql database that connections have
> > been opened (select...)
> > > > - I deploy a new version of my application and login with another
> > browser
> > > > - I check on my postgresql and mysql database that new connexions
> have
> > been opened (they doubled)
> > > > - I undeploy the first version of the webapp
> > > > - I check on my postgresql and mysql database and all connections are
> > still opened (even if I wait for a long time)
> > > >
> > > > For tests 1 and 2, I used C3p0, DBCP2 and even HikariCP
> > > >
> > >
> > >
> > > My results are the same. Using mysql, connection pools defined in
> > > server.xml (for user realm for access control to host manager app) and
> > > in my context.xml for my application. When I use the host-manager to
> > > reload an app, the connections are closed (no abandoned connection
> > > warnings) but not released. It is no until I stop tomcat completely
> > > and restart it that the connections are released in mysql. This has
> > > been the case for tomcat 7, 8.5 and 9 versions, with constant updates
> > > of mysql 5.7 and its driver, using both the apache connection pool and
> > > the tomcat connection pool. The driver lives in the tomcat/lib
> > > directory (since it is

Re: Connection pool and parallel deployment problem

2018-11-27 Thread Esther Montes 
Buenas tardes nomás kiero saber si tengo que ir otra vez  al banco para
para  q me meten unas claves o asi me va a entregar los depósitos

El mar., 27 de nov. de 2018 1:03 AM, Gilles SCHLIENGER <
gilles.schlien...@cncc.fr> escribió:

> Thanks a lot Heegu,
>
> I looked at your project on github.
> 1. Which part of the code is exporting JMX beans ? Is it the @ManagedBean
> annotation ?
>
> 2. What do you use JMX for ?
>
> Thanks again
> Regards
> Gilles
>
>
> -Message d'origine-
> De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
> Envoyé : mardi 27 novembre 2018 08:36
> À : Tomcat Users List
> Objet : Re: Connection pool and parallel deployment problem
>
> Dear Gilles,
>
> I apologize for the delay in reply.
>
> I make simple webapp and upload to github. In project, my test result is
> included.
>
> https://github.com/elfhazardwork/dbcp2-test
>
> Tomcat's parallel deploy mechanism is deploy new version before undeploy
> old.
> So, If your webapp is use JMX, bean name will duplicate and crush.
>
> The connection pool is used where the developer does not explicitly declare
> JXM.
> So this is a Tomcat bug.
> Otherwise, you must set JMX bean name dynamically.
>
> I hope this helps.
>
>
> 2018년 11월 27일 (화) 오전 2:03, Chris Cheshire 님이 작성:
>
> > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
> >  wrote:
> > >
> > > Hi,
> > > I understand your needs, but what is your problem, since you don't use
> > parallel deployment ?
> > > Your connections are not closed but they will not be recreated when you
> > deploy your webapp again, so there should be no problem ?
> > >
> > > Gilles
> > >
> >
> > I added my 2c because I am seeing what you describe here
> >
> > > > - I undeploy the first version of the webapp
> > > > - I check on my postgresql and mysql database and all connections are
> > still opened (even if I wait for a long time)
> >
> >
> > Yes I know you are using parallel deployment and I am not, but that
> > doesn't necessarily mean that the problem you see is limited to only
> > parallel deployment. Maybe the problem can be simplified to "
> > Tomcat considers the connections closed, the database doesn't."
> >
> > I could well be wrong, I'll leave it up to the gurus to decide :)
> >
> >
> > > -Message d'origine-
> > > De : Chris Cheshire [mailto:yahoono...@gmail.com]
> > > Envoyé : lundi 26 novembre 2018 15:27
> > > À : Tomcat Users List
> > > Objet : Re: Connection pool and parallel deployment problem
> > >
> > > I'm interested in what solution there is for this because I have the
> > > exact same problem but without parallel deployment.
> > >
> > > [snip]
> > >
> > > On Mon, Nov 26, 2018 at 3:54 AM Gilles SCHLIENGER
> > >  wrote:
> > > >
> > > > Hi Christopher,
> > > >
> > > > Thanks for your email.
> > > >
> > > > About connection pools not being closed, maybe the connection pool is
> > closed but the connections to the database are not.
> > > >
> > > > Here are the tests I did:
> > > >
> > > > + TEST 1:
> > > > - I deploy my war
> > > > - I login to my webapp
> > > > - I check on my postgresql and mysql database that connections have
> > been opened (select...)
> > > > - I undeploy my webapp through the manager webapp
> > > > - I check that the connections are still opened
> > > > - Tomcat is still running
> > > > - I redeploy the exact samed webapp and login to my application
> > > > - No other connection is being opened
> > > >
> > > > + TEST 2:
> > > > - I deploy my war
> > > > - I login to my webapp
> > > > - I check on my postgresql and mysql database that connections have
> > been opened (select...)
> > > > - I deploy a new version of my application and login with another
> > browser
> > > > - I check on my postgresql and mysql database that new connexions
> have
> > been opened (they doubled)
> > > > - I undeploy the first version of the webapp
> > > > - I check on my postgresql and mysql database and all connections are
> > still opened (even if I wait for a long time)
> > > >
> > > > For tests 1 and 2, I used C3p0, DBCP2 and even HikariCP
> > > >
> > >
> > >
> > > My results are the same. Using mysql, connection pools defined in
> > > server.xml (for user realm for access control to host manager app) and
> > > in my context.xml for my application. When I use the host-manager to
> > > reload an app, the connections are closed (no abandoned connection
> > > warnings) but not released. It is no until I stop tomcat completely
> > > and restart it that the connections are released in mysql. This has
> > > been the case for tomcat 7, 8.5 and 9 versions, with constant updates
> > > of mysql 5.7 and its driver, using both the apache connection pool and
> > > the tomcat connection pool. The driver lives in the tomcat/lib
> > > directory (since it is needed for the user realm datasource).
> > >
> > >
> > > > -Message d'origine-
> > > > De : Christopher Schultz [mailto:ch...@christopherschultz.net]
> > > > Envoyé : samedi 24 novembre 2018 17:19
> > > > À : users@tomcat.apache.org
> >

RE: Connection pool and parallel deployment problem

2018-11-27 Thread Gilles SCHLIENGER 
Thanks a lot Heegu,

I looked at your project on github.
1. Which part of the code is exporting JMX beans ? Is it the @ManagedBean 
annotation ?

2. What do you use JMX for ?

Thanks again
Regards
Gilles


-Message d'origine-
De : HeeGu Lee [mailto:elfhazardw...@gmail.com] 
Envoyé : mardi 27 novembre 2018 08:36
À : Tomcat Users List
Objet : Re: Connection pool and parallel deployment problem

Dear Gilles,

I apologize for the delay in reply.

I make simple webapp and upload to github. In project, my test result is
included.

https://github.com/elfhazardwork/dbcp2-test

Tomcat's parallel deploy mechanism is deploy new version before undeploy
old.
So, If your webapp is use JMX, bean name will duplicate and crush.

The connection pool is used where the developer does not explicitly declare
JXM.
So this is a Tomcat bug.
Otherwise, you must set JMX bean name dynamically.

I hope this helps.


2018년 11월 27일 (화) 오전 2:03, Chris Cheshire 님이 작성:

> On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
>  wrote:
> >
> > Hi,
> > I understand your needs, but what is your problem, since you don't use
> parallel deployment ?
> > Your connections are not closed but they will not be recreated when you
> deploy your webapp again, so there should be no problem ?
> >
> > Gilles
> >
>
> I added my 2c because I am seeing what you describe here
>
> > > - I undeploy the first version of the webapp
> > > - I check on my postgresql and mysql database and all connections are
> still opened (even if I wait for a long time)
>
>
> Yes I know you are using parallel deployment and I am not, but that
> doesn't necessarily mean that the problem you see is limited to only
> parallel deployment. Maybe the problem can be simplified to "
> Tomcat considers the connections closed, the database doesn't."
>
> I could well be wrong, I'll leave it up to the gurus to decide :)
>
>
> > -Message d'origine-
> > De : Chris Cheshire [mailto:yahoono...@gmail.com]
> > Envoyé : lundi 26 novembre 2018 15:27
> > À : Tomcat Users List
> > Objet : Re: Connection pool and parallel deployment problem
> >
> > I'm interested in what solution there is for this because I have the
> > exact same problem but without parallel deployment.
> >
> > [snip]
> >
> > On Mon, Nov 26, 2018 at 3:54 AM Gilles SCHLIENGER
> >  wrote:
> > >
> > > Hi Christopher,
> > >
> > > Thanks for your email.
> > >
> > > About connection pools not being closed, maybe the connection pool is
> closed but the connections to the database are not.
> > >
> > > Here are the tests I did:
> > >
> > > + TEST 1:
> > > - I deploy my war
> > > - I login to my webapp
> > > - I check on my postgresql and mysql database that connections have
> been opened (select...)
> > > - I undeploy my webapp through the manager webapp
> > > - I check that the connections are still opened
> > > - Tomcat is still running
> > > - I redeploy the exact samed webapp and login to my application
> > > - No other connection is being opened
> > >
> > > + TEST 2:
> > > - I deploy my war
> > > - I login to my webapp
> > > - I check on my postgresql and mysql database that connections have
> been opened (select...)
> > > - I deploy a new version of my application and login with another
> browser
> > > - I check on my postgresql and mysql database that new connexions have
> been opened (they doubled)
> > > - I undeploy the first version of the webapp
> > > - I check on my postgresql and mysql database and all connections are
> still opened (even if I wait for a long time)
> > >
> > > For tests 1 and 2, I used C3p0, DBCP2 and even HikariCP
> > >
> >
> >
> > My results are the same. Using mysql, connection pools defined in
> > server.xml (for user realm for access control to host manager app) and
> > in my context.xml for my application. When I use the host-manager to
> > reload an app, the connections are closed (no abandoned connection
> > warnings) but not released. It is no until I stop tomcat completely
> > and restart it that the connections are released in mysql. This has
> > been the case for tomcat 7, 8.5 and 9 versions, with constant updates
> > of mysql 5.7 and its driver, using both the apache connection pool and
> > the tomcat connection pool. The driver lives in the tomcat/lib
> > directory (since it is needed for the user realm datasource).
> >
> >
> > > -Message d'origine-
> > > De : Christopher Schultz [mailto:ch...@christopherschultz.net]
> > > Envoyé : samedi 24 novembre 2018 17:19
> > > À : users@tomcat.apache.org
> > > Objet : Re: Connection pool and parallel deployment problem
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > Gilles,
> > >
> > > On 11/23/18 05:07, Gilles SCHLIENGER wrote:
> >
> > [snip]
> >
> > >
> > > > The warning/error messages are not actually linked to the
> > > > connexions not closed. To ovoid these messages, you can: - move the
> > > > jars (connexion pool, drivers...) into TOMCAT/lib - Have a
> > > > ServletContextListener that calls
> > > >

RE: Connection pool and parallel deployment problem

2018-11-27 Thread Gilles SCHLIENGER 
Just one more thing I forgot to mention :
When I see the conections opened on databases using an sql query, I also see 
the Threads of the connection pool still present using jConsole to connect to 
tomcat
Gilles


-Message d'origine-
De : Chris Cheshire [mailto:yahoono...@gmail.com] 
Envoyé : lundi 26 novembre 2018 18:04
À : Tomcat Users List
Objet : Re: Connection pool and parallel deployment problem

On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
 wrote:
>
> Hi,
> I understand your needs, but what is your problem, since you don't use 
> parallel deployment ?
> Your connections are not closed but they will not be recreated when you 
> deploy your webapp again, so there should be no problem ?
>
> Gilles
>

I added my 2c because I am seeing what you describe here

> > - I undeploy the first version of the webapp
> > - I check on my postgresql and mysql database and all connections are still 
> > opened (even if I wait for a long time)


Yes I know you are using parallel deployment and I am not, but that
doesn't necessarily mean that the problem you see is limited to only
parallel deployment. Maybe the problem can be simplified to "
Tomcat considers the connections closed, the database doesn't."

I could well be wrong, I'll leave it up to the gurus to decide :)


> -Message d'origine-
> De : Chris Cheshire [mailto:yahoono...@gmail.com]
> Envoyé : lundi 26 novembre 2018 15:27
> À : Tomcat Users List
> Objet : Re: Connection pool and parallel deployment problem
>
> I'm interested in what solution there is for this because I have the
> exact same problem but without parallel deployment.
>
> [snip]
>
> On Mon, Nov 26, 2018 at 3:54 AM Gilles SCHLIENGER
>  wrote:
> >
> > Hi Christopher,
> >
> > Thanks for your email.
> >
> > About connection pools not being closed, maybe the connection pool is 
> > closed but the connections to the database are not.
> >
> > Here are the tests I did:
> >
> > + TEST 1:
> > - I deploy my war
> > - I login to my webapp
> > - I check on my postgresql and mysql database that connections have been 
> > opened (select...)
> > - I undeploy my webapp through the manager webapp
> > - I check that the connections are still opened
> > - Tomcat is still running
> > - I redeploy the exact samed webapp and login to my application
> > - No other connection is being opened
> >
> > + TEST 2:
> > - I deploy my war
> > - I login to my webapp
> > - I check on my postgresql and mysql database that connections have been 
> > opened (select...)
> > - I deploy a new version of my application and login with another browser
> > - I check on my postgresql and mysql database that new connexions have been 
> > opened (they doubled)
> > - I undeploy the first version of the webapp
> > - I check on my postgresql and mysql database and all connections are still 
> > opened (even if I wait for a long time)
> >
> > For tests 1 and 2, I used C3p0, DBCP2 and even HikariCP
> >
>
>
> My results are the same. Using mysql, connection pools defined in
> server.xml (for user realm for access control to host manager app) and
> in my context.xml for my application. When I use the host-manager to
> reload an app, the connections are closed (no abandoned connection
> warnings) but not released. It is no until I stop tomcat completely
> and restart it that the connections are released in mysql. This has
> been the case for tomcat 7, 8.5 and 9 versions, with constant updates
> of mysql 5.7 and its driver, using both the apache connection pool and
> the tomcat connection pool. The driver lives in the tomcat/lib
> directory (since it is needed for the user realm datasource).
>
>
> > -Message d'origine-
> > De : Christopher Schultz [mailto:ch...@christopherschultz.net]
> > Envoyé : samedi 24 novembre 2018 17:19
> > À : users@tomcat.apache.org
> > Objet : Re: Connection pool and parallel deployment problem
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Gilles,
> >
> > On 11/23/18 05:07, Gilles SCHLIENGER wrote:
>
> [snip]
>
> >
> > > The warning/error messages are not actually linked to the
> > > connexions not closed. To ovoid these messages, you can: - move the
> > > jars (connexion pool, drivers...) into TOMCAT/lib - Have a
> > > ServletContextListener that calls
> > > AbandonedConnectionCleanupThread.checkedShutdown();
> >
> > The Connector/J devs haven't been able to understand how ClassLoaders
> > work, and have never really fixed that long-standing bug in a
> > satisfying way as far as I know. But you should always use a
> > ServletContextListener to attempt to shut-down the
> > AbadonedConnectionCleanuopThread.
> >
> > BTW that thread does not work as documented. It's claimed that it
> > doesn't start unless you issue a query with a timeout, but it always
> > starts whether or not you use queries with timeouts. It's frustrating.
> >
>
> Should we be using checked or unchecked shutdown?
>
> -
> To unsubscribe,

[slightly OT] Re: Tomcat 9 does not work with Java 11

2018-11-27 Thread tomcat 

On 27.11.2018 01:49, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andi,

On 11/26/18 15:08, Andi Meister wrote:

Tomorrow I will try it on an other machine with no previous Tomcat
installed. But my problem is that I have to get it to run on this
machine. What could I do? First uninstall all jdks and Tomcats and
then install jdk11 and newest Tomcat?


You might want to:

1. C:...\tomcat-7> bin\service.bat remove  (optional name parameter)

2. C:...\tomcat-9> bin\service.bat install (optional name parameter)

Something might be broken in the service definition, and this should
reset everything. Note that any of the system properties you might
have defined in the existing service will be wiped-out by this
process. So, you might want to take a few screenshots of the various
configuration screens if you are using anything other than the plain
defaults.

Hmm... just realized that the service.bat file might not be included
in the "installer" bundle. You might have to grab the ZIP bundle from
the Tomcat downloads site to get those scripts.

- -chris


This may be the right moment to suggest that this (these ?) ZIP bundle(s) could be 
included by default, when running the installer (not unpacked, just copied along and 
dropped somewhere).  For as long as I can remember (which is getting somewhat shorter 
these days, but still goes back to tomcat 4.x), this has been an issue which regularly 
crops up with the Windows versions : whenever something goes wrong, people are being 
referred to files that they do not have, and it always takes a while to explain, download 
etc..

It would be easier if the files were already there anyway.
In the past, there may have been a concern for the extra size of the download (nowadays 
about 11 MB for each 32/64 bit version), but compared to many other downloads nowadays, 
this is still quite reasonable.
(And in fact, there are many common files, so not everything would have to be downloaded. 
 Also the 32-bit version is less useful these days.)




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