Re: SAML SSO Login issue

2022-05-11 Thread Olaf Kock

On 11.05.22 17:36, harish lal wrote:
> Facing SSO Login issue after upgrade from Tomcat 6.0.33 to Tomcat 7.0.62
>
> We upgraded our application from Tomcat 6.0.33 to Tomcat 7.0.62 due to web
> socket dependency in Tomcat.
> After upgrade , while try to do SAML SSO login from application we are
> facing below issue ,

Do you know that you "upgraded" to a version released in 2015 (see
https://archive.apache.org/dist/tomcat/tomcat-7/), which has seen its
end of life last year (see https://tomcat.apache.org/tomcat-70-eol.html)?

As a quick minimum - if you now have a hard dependency on Tomcat 7, you
should use the end-of-line 7.0.109 - maybe your issue is fixed in that
release already. In general (and if it isn't fixed) I'd recommend to go
to the latest in the 8.5 or 9.0 line and try to reproduce. I doubt
someone will start debugging 7 years old code that explicitly went out
of service more than a year ago. If you're lucky, someone will remember
something.

In case you still can reproduce: I'm quite uncertain what your phrase
"/If we remove only the "JSESSIONID" from the cookie/" means. Also, you
might want to look at all of the redirected requests and identify if
they're identical to each other, or where they're different.

Best,

Olaf


Re: tomcat-10.0.x Problem https multiple IP

2022-01-21 Thread Olaf Kock
Dear Jaebo,

On 21.01.22 10:29, Jaebo Nah wrote:
>  10.100.142.31  =   two.domain.loc
>
> 
>   address=" two.domain.loc"
>
>   SSLEnabled="true" defaultSSLHostConfigName="10.100.142.32" >
>
>       protocols="TLSv1.2,+TLSv1.1,+TLSv1">
>
>
Above, I only left the lines from your mail that deal with host names
and IP addresses and deleted all others. Note the mismatch between
"two..." refering to "...31" initially, and then you use "...32" later.

Individual IP addresses are no longer needed for https connections to a
server. I'd recommend to either handle them all in a single server, or,
if you need to run multiple tomcats, to handle the correct certificate
choice in a reverse proxy that delegates to the proper Tomcat in the
background.

Olaf



Re: Tomcat dedicated server

2022-01-20 Thread Olaf Kock
Hi Mark

On 20.01.22 10:18, Mark Thomas wrote:
> On 20/01/2022 08:54, Olaf Kock wrote:
>
>>  My rule of thumb is: The
>> more memory there is to be claimed in GC, the longer a full GC run
>> takes.
>
> Nope.
>
> The time a GC run takes is proportional to the size of objects in
> memory that do not need to be GC'd. GC walks the active object tree so
> it is the active objects that matter.
>
> Generally, the more memory you give the JVM to work with, the lower
> the impact of GC for both pauses and throughput.
>
> A rule of thumb I have seen in the past (may be out of date for
> current JVMs) is that the JVM needs roughly 5x the steady state memory
> requirements for GC to work most efficiently.
>
Thank you for setting my ancient rule of thumb straight - noted and
mentally corrected, this is really useful.

Obviously, the last time that I needed to squeeze the last bit of
performance out of a machine is so old that I never needed to revert
that ancient rule of thumb - now I have a cause to do so.

@Lance: I take it back and claim the opposite :)

Olaf


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



Re: Tomcat dedicated server

2022-01-20 Thread Olaf Kock
Hi Lance

On 19.01.22 23:35, Campbell, Lance wrote:
> On a Tomcat 9.x dedicated Linux server with 16G of memory, how much memory 
> would you allocate for the OS?
>
> Assume there is no file processing taking place.  Also assume Tomcat is 
> communicating primarily with a PostgreSQL database and Apache web server each 
> running on their own dedicated servers.  The Tomcat application server is the 
> only thing running on the Linux server.

It depends (TM)

Without knowing your application, the load (e.g. number of concurrent
users) and general setup, there's no way to tell. I'd rather handle the
question the other way around: How much memory does (your application
on) Tomcat require. Tomcat itself is happy with just a little bit of
memory, but applications vary widely. Also, some applications are
memory-bound, some are I/O-bound, some are CPU-bound. So memory might
not be your bottleneck to worry about.

You should load-test your application with a realistic load (plus
margin) and keep an eye on memory consumption. But in the end you'll
find out what is the first bottleneck to appear. It might not be memory.

But to come back closer to your original question: I recommend to
deactivate swapspace for production servers, and configure -Xms equal to
-Xmx, so that you find shortages of memory early (when you start the
application) rather than Sunday night at 3am. You might want to leave
1-2G for the OS and start testing this way, or rather test how little
memory your app requires to run and add margin. My rule of thumb is: The
more memory there is to be claimed in GC, the longer a full GC run
takes. Often, many short but frequent GC runs are preferable to fewer
but longer lasting. (I didn't check if this still applies to the newer
generation of garbage collectors, so take this GC-statement with a grain
of salt)

Olaf



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



Re: ClassFileTransformer in Tomcat 10 common classloader

2021-12-28 Thread Olaf Kock


On 28.12.21 00:36, Chew Kok Hoor wrote:
> We're using the old javax.servlet namespace for compatibility reasons.
>
> Some of our jar files are re-used by different web-apps, therefore we
> placed them in the common classloader.
>
> Is it possible to convert them dynamically, just like how we do it for
> servlets in the per app WEB-INF folder, by using the following in the
> context file:
>
> 

On top of what's already discussed:

You're not giving any indication that you need jakarta-ee at all, so if
you use javax.servlet: Just do it, and deploy on Tomcat 9 - that's a
very good choice that won't go away any time soon. If there's no need
for Tomcat 10, save yourself the hassle - at least for now.

Later on, you might want to divide your webapps into two groups: Those
that don't require any compatibility handling, because they're fully
migrated (or automatically migratable) to jakarta-ee, and those that
don't. Easy setup with a reverse proxy sending the traffic to either of
the two (or multiple) backends.

Olaf




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



Re: Handling database connection pooling outside Java, without DBCP et al?

2021-11-23 Thread Olaf Kock
I don't have experience with this particular setup, but one sentence (in
fact, one word) caught my attention:

On 23.11.21 14:23, jkla...@iki.fi wrote:
> We're in the process of adopting ProxySQL in front of MySQL, to act as the 
> connection pooler and for separating read and write traffic to different 
> database instances. After this, we have no need for DBCP or any other 
> Java-level pooling – in fact, having two levels of connection pooling would 
> probably be detrimental to performance, and certainly to our ability to 
> diagnose issues.

The keyword here is "probably": I'd say: Finish your migration with all
the current setup, and check if performance is worse than you expect (or
can live with) (and if diagnosis is hindered).

Then, if you /still/ want to eliminate Java pooling: The connection
pooling interfaces aren't that big - I'm not aware of a
non-pooling-connection-pool (or a configuration that disables what the
pool has been written for in the first place), but implementing your own
non-pooling-connection-pool should not be that much work, as you're only
handing out new connections unconditionally, and close them when the app
asks you to close them. And then configure Tomcat to use your
implementation instead of DBCP.

(As of my assumptions about configuration options or available
implementations: I can easily be proven wrong with a link to one of them)


Also, in the beginning you mention Tomcat 8.0 - while you're at it, you
might want to upgrade to one of the versions that still get updates,
e.g. 8.5 or 9.0.

Olaf


Re: tomcat hangs

2021-09-09 Thread Olaf Kock


On 09.09.21 12:50, Mehrdad Taagholi wrote:
> HiI use apache tomcat 8.0.32 and oracle-jdk-8u66 and redhat 6.After working 
> with the system for a few hours and the load on the system increases, 
> suddenly the tomcat hangs and no logs are printed and it is not possible to 
> connect via jvisualvm and I can not get any dump and I have to reload 
> Tomcat.I have increased maxthreads and use the HttpProtocol protocol.Please 
> suggest a way to fix the my tomact.

Seconding Jason's suggestion to look at your webapps.

However, as you explicitly ask for suggestions to fix your tomcat:
You're running a release from more than 5 years ago, where the general
version 8.0 has reached its end of life 3 years ago
(https://tomcat.apache.org/tomcat-80-eol.html), and are also running on
a JDK that has seen 200 more patch releases.

It's a good idea to keep your installations reasonably current -
specifically when you're looking for bugs in the infrastructure.

Try to reproduce on a current version (of Tomcat and JDK) - and look at
your webapps. As you can reproduce within a few hours, it's also a good
idea to connect a profiler early and check for the applications'
behaviour in the time running up to the problem.

More likely than not, your problem is in your application's code. Or, if
it's in Tomcat, there's a high likelyhood that it has been fixed in the
past 5 years.

Olaf

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



Re: Xms Xmx in JAVA_OPT vs CATALINA_OPTS

2021-08-03 Thread Olaf Kock
Onno,

On 03.08.21 04:57, Onno van der Straaten wrote:
> Hi, 
> I was looking at a Tomcat deployment and noticed settings in setenv.sh as 
> shown below. I noticed that Xms and Xmx is in JAVA_OPTS and CATALINA_OPTS 
> with the exact same settings. Do these settings make sense? What is the 
> purpose of repeating those settings? 
>
> I understand that JAVA_OPTS is for the JVM and CATALINA_OPTS is specific to 
> Tomcat. How do these settings relate to each other? I am assuming they could 
> be different. 
> Thanks and Regards, 
> Onno 
>
>
> JAVA_HOME="/usr/lib/jvm/jdk11_0411_oj9" 
> JAVA_OPTS="-Xms3000m -Xmx3000m" 
> CATALINA_OPTS="-Dcom.sun.management.jmxremote.port=8375 
> -Dcom.sun.management.jmxremote.ssl=false 
> -Dcom.sun.management.jmxremote.authenticate=false 
> -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true 
> -Dfile.encoding=UTF-8 -Dsun.net.inetaddr.ttl=300 -server 
> -Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=8192 -Xms3000m -Xmx3000m 
> -XX:MaxPermSize=500m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode 
> -XX:+PrintGCDateStamps -verbose:gc -XX:+PrintGCDetails 
> -Xloggc:"/opt/tomcat/tomcat-9.0.40/logs/garbage.log" 
> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M 
> -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory"
>  

JAVA_OPTS is used for /any/ start of a JVM, including when you run
bin/shutdown.sh, which opens a socket, issues the shutdown command and
terminates. Thus, it's an /absolute/ /overkill/ to set -Xms3000m (or any
memory setting) in JAVA_OPTS.

CATALINA_OPTS is added to these parameers when you start tomcat - thus
this is the right place to configure any memory that you need when you
run the server.

This means that both, JAVA_OPTS and CATALINA_OPTS are used when you run
tomcat. If you have conflicting settings in both: You figure out which
one takes precedence. I choose to not even try to remember which one
takes precedence as I don't trust this to be stable. Your best bet:
Leave any memory setting out of JAVA_OPTS. Most likely you don't need
any custom JAVA_OPTS in setenv.sh, because you're only interested in
configuring settings for the running tomcat. These values safely go into
CATALINA_OPTS.

Prevent ambiguities.

Olaf


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



Re: Ho to upgrade to newest version in tomcat 9

2021-07-28 Thread Olaf Kock


On 27.07.21 19:01, W wrote:
> Hi,
> I am on Ubuntu with tomcat 9.0.16I tried    sudo apt-get update    sudo 
> apt-get upgradeBut did not work. How to do it?

The distribution packages (here: Debian) typically pick one version and
keep it stable, optionally backporting security fixes to it. Odds are
that you're already not running the same code as in stock 9.0.16, but a
patched version.

If you want to be on the latest version as soon as it's out, you'll
either have to install manually from https://tomcat.apache.org, or find
a repository that you trust, that offers a packaged version.

Olaf



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



Re: Mixing Root Context webapp with other webapps

2021-07-09 Thread Olaf Kock


On 09.07.21 07:58, Jerry Malcolm wrote:
> I have one webapp that processes REST-style url paths and therefore
> needs to run in the ROOT context.  Is it possible to run other webapps
> in the same host with other non-root contexts?   In other words, when
> resolving a URL to a web app, does it try to map the url to the
> defined context strings first, and then to ROOT if there are no
> matches?  Or does ROOT override everything, and all URLs go to ROOT if
> it's defined?
>
If memory serves me well and this behavior didn't change in the past
decade, then all other web applications have precedence over root. That
is, if you deploy ROOT.war and json.war (and assume the context-path to
be /json), then your root application's /json path would never be reached.

It's easy to visualize this way around, because it's an absolutely
static mapping with the size being "number of webapps", while the other
way around, ROOT could also map /* to one of its servlets and then
determine what to do it. The spec has to means to explicitly hand a
request back to the appserver and every app would rather generate 404
than check if somebody else might be there to handle it.

Olaf



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



Re: Re-Use TCP Source Ports if the Socket is Unique?

2021-06-25 Thread Olaf Kock


On 25.06.21 14:46, Eric Robinson wrote:
> Olaf and Scott --
>
> Thanks to both of you for your comments. I may have asked my question poorly, 
> since what you both described is the way I understand TCP to work. There is 
> no correlation between an incoming connection to tomcat and its outgoing 
> connection to a database backend, nor would I expect there to be.
>
> Perhaps a simpler way to ask my question is: when a server has multiple IPs, 
> which one does tomcat use as its source IP when it initiates a three-way 
> handshake with a remote machine?
>
> For example, suppose my server has IP addresses 10.0.0.1 and 10.0.0.2, and my 
> tomcat connector looks like this...
>
>  port="8080"
> protocol="HTTP/1.1"
> address="10.0.0.2"
> connectionTimeout="2"
> redirectPort="8443"
>   />
>
> Tomcat is now listening on IP 10.0.0.2.
>
> But here's the question. If tomcat needs to initiate a TCP session to a 
> remote machine (acting as a TCP client), will it use 10.0.0.1 or 10.0.0.2 as 
> the source IP of the outbound connection? I'm assuming it will use the same 
> IP that the connector is configured to listen on.
>
Hi Eric,

again: There's no correlation. Your question boils down to a
context-free "which source IP does tomcat use for outgoing
connections?". In fact, Tomcat doesn't use any. It just asks the runtime
environment (ultimately I'd expect the OS) for a connection to a
particular destination, then it uses that.

How the connection is then established will depend on

* available network adapters
* best route to the target address
* OS or network configuration

It will /not/ depend on any of Tomcat's Connector-configurations whatsoever

Olaf


>> -Original Message-
>> From: Olaf Kock 
>> Sent: Friday, June 25, 2021 3:01 AM
>> To: users@tomcat.apache.org
>> Subject: Re: Re-Use TCP Source Ports if the Socket is Unique?
>>
>>
>> On 25.06.21 05:19, Eric Robinson wrote:
>>> Thanks for the feedback, Daniel.
>>>
>>> I guess the answer depends on whether the socket libraries use the tomcat
>> listening port as the source IP. If you have three tomcat instances 
>> listening on
>> three different IPs, each instance should be able to open a client connection
>> using the same source port, as long as each tomcat uses its listening IP as 
>> the
>> source IP of the socket.
>>> That's the part I'm still not sure about.
>> My expectation is that database connections do not have any correlation
>> with the listening port: Technically, DB connection pools can be shared 
>> across
>> all contained Hosts and Connectors /within a single tomcat/, and when
>> multiple processes are added to the game, it doesn't really change anything.
>>
>> In fact, it's not uncommon that there's a public facing network adapter,
>> where a http-connector listens, but a completely different network adapter
>> for any backend communication - e.g. to the database. All that I expect a
>> database driver to do is to specify where it wants to connect to, and the OS
>> figures out how that connection needs to be routed.
>> That's utterly independent of any http connection that comes in to the same
>> process.
>>
>> So: Don't expect any correlation, and you're safe.
>>
>> (Note: There /may/ be ways to configure a db-driver to specify a source
>> address, but I'd expect that rather to add a potential failure rather than
>> anything that I'd want to control. If you interpret such a situation 
>> differently:
>> Please elaborate)
>>
>> Best,
>>
>> Olaf
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> Disclaimer : This email and any files transmitted with it are confidential 
> and intended solely for intended recipients. If you are not the named 
> addressee you should not disseminate, distribute, copy or alter this email. 
> Any views or opinions presented in this email are solely those of the author 
> and might not represent those of Physician Select Management. Warning: 
> Although Physician Select Management has taken reasonable precautions to 
> ensure no viruses are present in this email, the company cannot accept 
> responsibility for any loss or damage arising from the use of this email or 
> attachments.
>
> -
> 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: Re-Use TCP Source Ports if the Socket is Unique?

2021-06-25 Thread Olaf Kock


On 25.06.21 05:19, Eric Robinson wrote:
> Thanks for the feedback, Daniel.
>
> I guess the answer depends on whether the socket libraries use the tomcat 
> listening port as the source IP. If you have three tomcat instances listening 
> on three different IPs, each instance should be able to open a client 
> connection using the same source port, as long as each tomcat uses its 
> listening IP as the source IP of the socket.
>
> That's the part I'm still not sure about.

My expectation is that database connections do not have any correlation
with the listening port: Technically, DB connection pools can be shared
across all contained Hosts and Connectors /within a single tomcat/, and
when multiple processes are added to the game, it doesn't really change
anything.

In fact, it's not uncommon that there's a public facing network adapter,
where a http-connector listens, but a completely different network
adapter for any backend communication - e.g. to the database. All that I
expect a database driver to do is to specify where it wants to connect
to, and the OS figures out how that connection needs to be routed.
That's utterly independent of any http connection that comes in to the
same process.

So: Don't expect any correlation, and you're safe.

(Note: There /may/ be ways to configure a db-driver to specify a source
address, but I'd expect that rather to add a potential failure rather
than anything that I'd want to control. If you interpret such a
situation differently: Please elaborate)

Best,

Olaf



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



Re: Where does Tomcat 9 (apt managed / standard config) store sessions in Ubuntu 18?

2021-06-20 Thread Olaf Kock


On 20.06.21 04:54, Gustavo Almeida wrote:
> "Configuration Reference - The Manager Component" says:
> "A Manager element MAY be nested inside a Context component. If it is not
> included, a default Manager configuration will be created automatically"
>
> My Context has no nested Manager element.
>
> So, guessing I'm using by default the Standard Manager Implementation,
> where does it store active sessions, if it does at all?

Without looking it up (thus I could easily be proved wrong): My
assumption is that the active sessions are in memory. Is there any
particular reason why you'd expect them on disk?

Olaf


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



Re: CATALINA_OPTS vs JAVA_OPTS

2021-06-16 Thread Olaf Kock
Service configurations are service configurations. You won't run the
other options as service, so those are for the JVM that is used for the
service. And I'm not aware that a service is stopped as the command line
version. At least I'd hope so - a standard JVM would be good enough, if
the start/stop mechanism not handled in the windows executable anyway.

Note: This is dangerous half-knowledge. I haven't been on Windows for
ages, just read about it still being around from time to time.

CATALINA_OPTS is utilized by the startup batch/script file, which is not
used for services /at all/.

Olaf

On 16.06.21 20:31, jonmcalexan...@wellsfargo.com.INVALID wrote:
> Ok, so this is a really good explanation. However, when setting up in Windows 
> as a Service, does the JAVA_OPTIONS in the Registry go in as JAVA_OPTS or 
> CATALINA_OPTS? Is there a way to have separate CATALINA_OPTS for Tomcat 
> Windows Services?
>
> Thanks,
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Infrastructure Engineer
> Asst Vice President
>
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
>
> Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
> 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
> 12/30/2020, 12/31/2020
> This message may contain confidential and/or privileged information. If you 
> are not the addressee or authorized to receive this for the addressee, you 
> must not use, copy, disclose, or take any action based on this message or any 
> information herein. If you have received this message in error, please advise 
> the sender immediately by reply e-mail and delete this message. Thank you for 
> your cooperation.
>
>> -Original Message-
>> From: Christopher Schultz 
>> Sent: Wednesday, June 16, 2021 11:14 AM
>> To: users@tomcat.apache.org
>> Subject: Re: CATALINA_OPTS vs JAVA_OPTS
>>
>> Noelette,
>>
>> On 6/16/21 11:29, Noelette Stout wrote:
>>> Thanks! I was mostly trying to figure out if there was precedence or
>>> if it was additive (i.e. 2GB to tomcat itself and another 2GB to the
>>> apps). We're having some resource issues on one of our servers, so I
>>> wanted to make sure I understood how the resources were being
>> allocated.
>>
>> No additivity at all: the last one on the command-line wins. There is no heap
>> separation between Tomcat and the applications: it's one(ish) big, happy
>> heap. :)
>>
>> A note about CATALINA_OPTS versus JAVA_OPTS: when you use the various
>> scripts provided by Tomcat, CATALINA_OPTS is only used when launching a
>> Tomcat instance. JAVA_OPTS is used when launching *any* Java process.
>> There are many Java processes those scripts will launch that aren't actually
>> launching Tomcat. Examples include:
>>
>> 1. catalina.sh configtest
>> 2. catalina.sh stop (also shutdown.sh)
>> 3. catalina.sh version
>> 4. tool-wrapper.sh [anything]
>>
>> In all of those cases, JAVA_OPTS will be passed to the JVM.
>>
>> Do you really need a 2 gig heap to send a "shutdown" command to a running
>> server? Probably not.
>>
>> -chris
>>
>>> On Wed, Jun 16, 2021 at 9:17 AM Rob Sargent 
>> wrote:

 On 6/16/21 9:06 AM, Noelette Stout wrote:
> openjdk version "1.8.0_292"
>
>
> On Wed, Jun 16, 2021 at 9:04 AM Rob Sargent 
 wrote:
>
 Both as for the same minimum so you should get 2G at start up.  I'm
 not sure which has precedency but I would be on java opt.  I don't
 have a catalina env, but you can see how CATALINA_OPTS is used in
 relationship with JAVA_OPTS


 -
 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
>

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



Re: Request: Encryption requirements for TLS and SSL for Tomcat

2021-06-08 Thread Olaf Kock

On 08.06.21 14:10, Emen-Eddine AISSAOUI wrote:
> Hello,
>
> I am contacting you regarding the cipher suite recommandations for TLS and 
> SSL for Tomcat.
>
> Could you please tell us which cipher suites are used and necessary and if 
> there is any particular prequesites regarding TLS and SSL encryption for the 
> proper functioning of Tomcat ?
>
> This is an urgent request for a customer feedback.

Are you asking for the Java prerequisites? Bitsize for keys requirement?
What do you call "proper functioning" of Tomcat? Because it functions
quite properly with any (supported) TLS settings.

In general, the recommendations for ciphers are independent of the app
server, it's rather a common industry standard (changing over time), but
heavily depends on the devices you need to support.

Can't go without this rant with regards to your urgency: If you have
customers paying /you/ for that information, how much of that money are
you willing to share for a quicker answer, /tailored/ to your
(customer's) /exact/ needs? 

Olaf



Re: Question about encrypting database passwords in the context.xml file - Tomcat 9

2021-06-07 Thread Olaf Kock


On 07.06.21 10:56, xcorpius wrote:
> Hello again!
>
> Checking the documentation ... Tomcat can create an encrypted password with 
> the "digest.sh" tool for application passwords.
>
> But you cannot create an encrypted password for the DB in the context.xml 
> file. The only solution without adding anything is to give restrictive 
> permissions to the context.xml file.
>
> Wouldn't it be the same problem? Why can't I generate an encrypted password 
> for the database with the "digest.sh" tool instead of having to use a 
> customized "factory"?
>
> I think people who develop Tomcat should consider this option.
>
> Thank you very much to all.

Sorry, those are not the same: Digested passwords cannot be undigested,
but any digestion of the same password reveals the same digested result,
so that they can be compared. (read about the difference between hashing
and encryption)

For a database connection, you'll need to undigest (e.g. unencrypt) the
password and get it in clear text. And that's precisely what the FAQ
answers as impossible to do securely (without requiring manual input of
keys at each startup)

There's nothing here to consider that hasn't been considered before.

Olaf

>> Hi,
>> I wanted to ask about how to encrypt database passwords in the
>> context.xml file in Tomcat 9.
> Hi,
> please check this article:
 https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/
 TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$

> It covers the topic once and for all...
> Olaf

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



Re: Question about encrypting database passwords in the context.xml file - Tomcat 9

2021-04-26 Thread Olaf Kock


On 26.04.21 13:10, xcorpius wrote:
> Hi,
>
> I wanted to ask about how to encrypt database passwords in the context.xml 
> file in Tomcat 9.
>
Hi,

please check this article:
https://cwiki.apache.org/confluence/display/TOMCAT/Password

It covers the topic once and for all...

Olaf


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



Re: Getting additional attributes for logged on users

2021-04-09 Thread Olaf Kock
Hi Carsten,

I'll be limiting my answer to the most notable lines and quote only those.

(anybody else reading this without following the mails live: Go to the
archive to see Carsten's full post)


On 08.04.21 22:08, Carsten Klein wrote:
>
> Typically, those desired extra attributes are stored in the user's
> record in the user database. That may be a SQL database or may be an
> Active Directory Server (or any other directory), which is already
> used for authentication and authorization.
>
> Wouldn't it be cool to make the Realm get us that extra information?

It would be cool, absolutely.

Even cooler if "the desired extra attributes" could be agreed upon - or
even what would be desirable in user management (is user + roles enough?
That requires redeployment any time the system gets more picky with
permissions.

Personally, I work with Liferay, where roles are runtime-configurable
and map to permissions. The permissions are what's checked in the
application code, and the applications couldn't care less about number
of roles or path through which a permission is assigned to a user.

> In its simplest form, these Realms get a new configuration property
> 'extraAttributes', which takes a comma separated list of field names
> to retrieve. Implicitly, for an SQL-based Realm, these fields are
> queried from the 'userTable' table. The JNDIRealm tries to find these
> attributes from the user's entry in the directory, of course.
>
> More complex configurations are possible (but likely not needed).

You first state "its simplest form", then state that more complex
solutions are likely not needed.

I'd argue that the current form is "the simplest form", as it provides
identifiers that can be used to look up extra information according to
the application's need.

I don't want to tear down your idea - only reflect that "only a little
bit more" will be barely enough for the next person coming around, and
end up being a really complex beast. And if you look at all the
different available attributes for users that make sense in some, but
not in other countries/cultures, you'll soon be implementing your own
anyway:

* What makes up the name? First/Last Name? Including middle name (common
in US, almost nonsensical in Germany)? There are cultures with just a
single name
* Gender: How many choices and what will they be named (by law, Germany
now has 3 genders)
* Address: I've recently sent out letters to international addresses,
and boy was it hard to ask for the right information to go to the
address sticker.
* Department: Makes sense in a business environment, not at all in a
community environment

While you name some samples that sound agreeable on first sight, I don't
think that they're agreeable enough to impose them on people unless
provided voluntarily and under arbitrary names. Which ends up with the
cost of a huge framework in order to potentially save a single database
request per log in.

E.g.: It would be cool, but I don't see it worth the price.

my 2 (Euro) Cent

Olaf



>
> I'm curious what you think about it :)
>
> Carsten
>
> -
> 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



[OT] Re: What exactly does the AJP connector on 8009 do?

2021-04-06 Thread Olaf Kock


On 06.04.21 11:53, André Warnier (tomcat/perl) wrote:
>
> Shortcut :
> - comment-out the AJP Connector in the tomcat configuration
> - restart tomcat
> - and wait for desperate support calls
>
That reminds me of the common wisdom in System Administration:

*Everybody* has a dedicated testing system. Always!

*Some* are lucky that they have a completely separate production system.


(lost the source)


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



Re: [OT] programming style or mental process ?

2021-04-04 Thread Olaf Kock
Hi André

On 04.04.21 12:23, André Warnier (tomcat/perl) wrote:
>
>   if (null == request.getCharacterEncoding()) {
>
> as opposed to
>
>   if (request.getCharacterEncoding() == null) {
>
>
> So why do (some) people write it the other way ?
> Is it purely a question of individual programming style ?
> Is there some (temporary ?) fashion aspect involved ?
> Do the people who write this either way really think in a different way ?
> Or is there really something "technical" behind this, which makes one
> or the other way be slightly more efficient (whether to compile, or
> optimise, or run) ?
>
> (*) excepting Yoda of course
>
I can't say I'm always writing Yoda style, but if I stretch my memory,
then the rationale behind this style of comparisons is to have a
constant on the left side, so that you get a compiler error in case
you're using = instead of ==.

In your case, with a function call, this wouldn't make a difference
"if(request.getCharacterEncoding() = null)" would be illegal syntax as
well, but "if(someObject = null)" is perfectly legal, but doesn't
express the author's intent clearly: Is it a smart person who's taking a
shortcut, or a newbie using the wrong operator?

Of course, the style doesn't really help people new to the language, as
they first need to understand that this is something that they might
want to apply to their code. And today, with so many IDE warnings being
flagged while typing, it might be outdated, though it still clearly
expresses the intent to have a real comparison and not an assignment here.

And I agree with the other answer posted already: It makes a lot more
sense in C++ with all the implicit boolean conversions and habits of
outsmarting the code's maintainers with clever expressions.

Olaf



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



Re: Mixed User Session

2021-01-15 Thread Olaf Kock


On 15.01.21 15:57, juan wrote:
> Hi,
>
> We were running tomcat 8.5.57 on CentOS 7 and together with CAS SSO, we
> have multiple servers behind an AWS load balancer setup with sticky
> sessions. We encountered a weird situation where a user who logged into
> their application was presented with another users profile after login. Has
> anyone encountered something similar to this? Both users hit the same
> tomcat server seconds apart and the user was on his personal computer and
> doesn't know the first user.

I've seen stuff like this happening when a reverse proxy was over-eager
in caching stuff that it saw. 100% of cases where I've seen this
behavior had this as a root cause.

"over-eager" might mean that Tomcat (e.g. your app) doesn't signal the
upstream proxy that the content is private, or the upstream proxy
ignoring such signals.


It's been a long time since I last saw it (and back then I didn't
fix it myself - just provided information like the above) so I barely
remember the key points to configure or look after. Maybe it helps
already, otherwise we'll have to wait for someone to point to the usual
suspects in the individual configurations.

Olaf


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



Re: regarding CVE-2020-8022 applicable to tomcat 8.5.57

2020-09-02 Thread Olaf Kock


On 02.09.20 10:16, Rathore, Rajendra wrote:
> Please let me know whether CVE-2020-8022 applicable to tomcat 8.5.57 or not, 
> if yes please let me know which release we fixing it.


The CVE states:

"A Incorrect Default Permissions vulnerability in the *packaging of
tomcat* on SUSE Enterprise Storage 5"

i.e. it's rather SUSE's packaging than tomcat itself. Correct me if I'm
wrong.

If you're running any SUSE system, here are the releases that *they*
fixed it: https://www.suse.com/de-de/security/cve/CVE-2020-8022/

I don't expect any update from the generic Apache distribution of Tomcat
for this CVE, unless I've missed some information that was well hidden
in the multitude of mentioned SUSE products in that report.

Olaf



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



Re: Allowing dir listing of root (/) dir of the machine

2020-08-24 Thread Olaf Kock


On 24.08.20 16:41, Aryeh Friedman wrote:
> On Mon, Aug 24, 2020 at 4:27 AM Mark Thomas  wrote:
>
>> On 23/08/2020 22:05, Aryeh Friedman wrote:
>>> In order to allow my developers to quickly access any temporarily
>> produced
>>> html files created/stored outside of webapps (such as those created by
>> the
>>> jacoco test coverage tool) I want to allow read only access to the root
>>> directory of the development server (firewalled and all access outside of
>>> the LAN is disabled) via tomcat.   I can get it to do any directory
>>> *EXCEPT* / as the docBase but a docBase of "/" returns an empty dir
>> listing
>>
[snip]
>> I'd do this with a ROOT.xml file in
>> $CATALINA_BASE/conf/Catalina/localhost but the above should work.
[snip]


I'd recommend to *not* go this route. Rather google for "java web file
manager" or variations thereof: You'll find several open source projects
that implement a file browser in a deployable web application. You can
apply password protection to it, update/deploy/configure the application
(e.g. to prevent /etc/passwd to be read) and so on.

I'm explicitly not linking any of those applications here, as I can't
recommend any from my own experience. I remember to have worked with one
ages ago that was implemented in a single JSP (great to plant a
debugging backdoor on production servers. But /cough/ who would ever do
that?)

Olaf



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



Re: Patch for Ubuntu 18

2020-07-20 Thread Olaf Kock

On 20.07.20 15:55, Celestino Federico (ETAS-SEC/ISY-IT) wrote:
>  
>
> Could someone tell me how to find a debdiff for tomcat8 package from
> version *8.5.39-1ubuntu1~18.04.3* (last version available on Ubuntu
> 18) and version *8.5.56*?
>
>
My expectation is that you'll have to create this yourself. In the
Debian world, they typically pick a version of any packaged software and
/might/ backport individual fixes from later releases, but won't update
to a newer minor version in most cases.

I'm not really sure where the sources are kept for the Debian packages,
but there you should be able to see the commit history, and potentially
all fixes that have been backported.

Personally, I find Tomcat releases stable (and backwards-compatible)
enough that I rarely rely on any distribution for Tomcat installations,
but rather take the stock download from tomcat.apache.org and add a
daemon start script.

Olaf




Re: file ownership of webapps and below

2020-07-14 Thread Olaf Kock


On 14.07.20 11:12, Christoph Kukulies wrote:
> I found there are some mismatches in file ownership from manual installation 
> and moving around webapps  trees from different tomcat versions.
> My current tomcat (9)  runs under user.group tomcat.tomcat. A couple of files 
> have ownership
>
> root.tomcat
> tomcat8.
>
> Would it be ok to chown all files below and including webapps to 
> tomcat.tomcat?

It depends (TM)


There are those who can't operate without tomcat having write access to
its own operations, e.g. because they rely on the manager app for
deployments.

And there are those who prefer Tomcat to not have any write access to
its own applications, as a means of hardening the installation.

My preference is to limit write permissions (and ownership) to temp,
work and logs. Your mileage may vary.


Olaf



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



Re: How to encrypt db password in tomcat context.xml

2020-06-28 Thread Olaf Kock


On 28.06.20 19:50, Jürgen Weber wrote:
 I would like to know how to encrypt and decrypt the database password in
 context.xml when the application is running which also allow me to change
 the db password for the purpose of security.
>> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> Well, I know a chief open source app server that has the password to
> decrypt all passwords buried in its open source, and I know auditors
> who are good if root cannot read passwords at first sight. The
> reasoning behind that is that running java -jar someappserverlib.jar
> -decrypt is a deliberate act that a god guy root does not do. So a
> hidden password is a step better, even if not in the cryptographic
> sense.

Hi Jürgen,

I don't get your point here. Are you arguing that the linked wiki
article is incorrect, insufficient or invalid?

Because I believe that the article documents how to implement everything
that you describe on your own, and gives arguments for why this is not
implemented out of the box.

Best,

Olaf




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



Re: How to encrypt db password in tomcat context.xml

2020-06-26 Thread Olaf Kock


On 26.06.20 15:05, FANG YAP wrote:
> Hi Tomcat,
>
> I would like to know how to encrypt and decrypt the database password in
> context.xml when the application is running which also allow me to change
> the db password for the purpose of security.


https://cwiki.apache.org/confluence/display/TOMCAT/Password




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



Re: Cryptominer malware and Tomcat

2020-06-18 Thread Olaf Kock
Hi Pete,

On 17.06.20 23:44, Pete Helgren wrote:
> I am going to guess that it is one of these two known vulnerabilities:
>
> CST-7111: RCE via JSON deserialization (LPS-88051/LPE-165981)
> The JSONDeserializer of Flexjson allows the instantiation of arbitrary
> classes and the invocation of arbitrary setter methods.
>
> CST-7205: Unauthenticated Remote code execution via JSONWS
> (LPS-97029/CVE-2020-7961)
> The JSONWebServiceActionParametersMap of Liferay Portal allows the
> instantiation of arbitrary classes and invocation of arbitrary setter
> methods.
>
> Found the signature in the logs and it's pretty clear that that is
> what we are up against.  However, if something else comes to mind,
> feel free to post back.  I  did come across a couple of other posts
> where the OP said there was nothing but Tomcat and they also ended up
> with the miner.
>
> I have some updating to do
>
Correct analysis.

What you need is this update
https://liferay.dev/blogs/-/blogs/security-patches-for-liferay-portal-6-2-7-0-and-7-1

And while you're at it: There has been another patch published this
month
https://liferay.dev/blogs/-/blogs/june-2020-security-patches-for-liferay-portal-7-1-and-7-2

Best,

Olaf


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



Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?

2020-05-15 Thread Olaf Kock


On 15.05.20 13:23, ohaya wrote:
>  Hi,
>
> I just tried adding the secret to the Apache side:
>
> ProxyPass ajp://192.168.218.XXX:8009 secret="123"
> ProxyPassReverse ajp://192.168.218.XXX:8009 secret="123"
>
> and I get an error when I try to start Apache:
>
> AH00526: Syntax error on line 554 of /apps/oracle/apache/conf/httpd.conf:
> ProxyPass unknown Worker parameter
>
> I am currently using Apache 2.4.39. Is there another way to specify the 
> "secret"?

With 9.0.20 you do not yet need to pass a secret - that came along later
(somewhere around 30-33 AFAIR). However, you'll need to make sure that
your AJP port is only available for the reverse proxy and nobody else -
there was a recent security disclosure, which led to the change of many
default settings for the AJP connector in the current releases.

It boils down to the last sentence of my previous answer: I've never
used REMOTE_USER headers for authentication, and there's no indicator in
your setup that you're allowing Tomcat to trust such a header. I might
be completely off here, but as nobody else answered yet, I thought I'd
give it a try.

Olaf

> Thanks,
> Jim
>
>
>  On Friday, May 15, 2020, 07:04:44 AM EDT, ohaya 
>  wrote:  
>  
>   Hi,
>
> The Tomcat version I am using is 9.0.20. I will take a look at the changelog. 
>
> This is the first time I have tried this, and I couldn't find much info, so I 
> appreciate the feedback. I will look for info about "secret". 
>
> I wasn't sure about the format on the Apache side for the 
> ProxyPass/ProxyPassReverse - does what I posted look all right?
>
> Also, when I was searching around for info, I saw some comments that seem to 
> be saying that the "tomcatAuthentication" parameter on the Tomcat connection 
> was no longer supported or something like that?
>
> Also re. "secret" on the Tomcat side: If that is set to, for example, 
> "mysecret", how do I pass that on the Apache side?
>
> Thanks again,
> Jim
>
>
>     On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock  
> wrote:  
>  
>  
> On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote:
>> Hi,
>>
>> I am using an Apache proxy in front of Tomcat 9, and I am using AJP 
>> connection to connect from the Apache to Tomcat, and I have the Apache 
>> sending a username to the Tomcat in a REMOTE_USER header.
>>
>> In the Tomcat server.xml I have:
>>
>>   > tomcatAuthentication="false"/>
>>
>> In the Apache httpd.conf, to test, this I have:
>>
>> 
>> ProxyPass ajp://192.168.218.XX:8009
>> ProxyPassReverse ajp://192.168.XX.224:8009
>> 
>>
>> But when I access the app via the Apache, it is not automatically logging me 
>> into the app.
>>
>> Is there anything else that I have to do to get this to work besides what I 
>> did above?  Is there something that I have to modify in the app itself to 
>> get this to work?
> Hi Jim,
>
> which exact version of Tomcat 9 are you using? Note that there were
> significant changes for the default and required configuration for the
> AJP connector, in order to use it. Best to find all of them: Search for
> AJP in the change log tomcat.apache.org/tomcat-9.0-doc/changelog.html
>
> Notable among them: Everything to do with "secret", and the default bind
> address, "localhost", for the AJP connector. i.e. I'd expect this
> configuration to be insufficient for any of the latest releases.
>
> I haven't ever used this REMOTE_USER authentication, but nothing in the
> configuration that you've posted gives any clue about what you do and
> what you send. I would expect Tomcat to *not* blindly accept any
> REMOTE_USER header by default, unless it's whitelisted and explicitly
> asked for - it otherwise would be a great way to exploit servers that
> don't have a remote proxy (or one where the remote proxy is configured
> to remove this header). Nothing in the configuration you post gives me a
> hint about what you do to make tomcat accept and trust this header.
>
> Olaf
>
>
>
> -
> 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: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?

2020-05-15 Thread Olaf Kock


On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote:
> Hi,
>
> I am using an Apache proxy in front of Tomcat 9, and I am using AJP 
> connection to connect from the Apache to Tomcat, and I have the Apache 
> sending a username to the Tomcat in a REMOTE_USER header.
>
> In the Tomcat server.xml I have:
>
>   tomcatAuthentication="false"/>
>
> In the Apache httpd.conf, to test, this I have:
>
> 
> ProxyPass ajp://192.168.218.XX:8009
> ProxyPassReverse ajp://192.168.XX.224:8009
> 
>
> But when I access the app via the Apache, it is not automatically logging me 
> into the app.
>
> Is there anything else that I have to do to get this to work besides what I 
> did above?  Is there something that I have to modify in the app itself to get 
> this to work?

Hi Jim,

which exact version of Tomcat 9 are you using? Note that there were
significant changes for the default and required configuration for the
AJP connector, in order to use it. Best to find all of them: Search for
AJP in the change log tomcat.apache.org/tomcat-9.0-doc/changelog.html

Notable among them: Everything to do with "secret", and the default bind
address, "localhost", for the AJP connector. i.e. I'd expect this
configuration to be insufficient for any of the latest releases.

I haven't ever used this REMOTE_USER authentication, but nothing in the
configuration that you've posted gives any clue about what you do and
what you send. I would expect Tomcat to *not* blindly accept any
REMOTE_USER header by default, unless it's whitelisted and explicitly
asked for - it otherwise would be a great way to exploit servers that
don't have a remote proxy (or one where the remote proxy is configured
to remove this header). Nothing in the configuration you post gives me a
hint about what you do to make tomcat accept and trust this header.

Olaf



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



Re: how do I switch class loaders

2020-05-08 Thread Olaf Kock


On 08.05.20 19:50, Christopher Schultz wrote:
> Olaf,
>
> On 5/8/20 13:19, Olaf Kock wrote:
>
> > You might want to hunt down duplicate classes in the JAR files on
> > your classpath. Worst case: unpack them all in temporary
> > directories and check for occurrences of the filename. Make sure
> > that one doesn't overwrite the other when unzipping.
>
> Or unpack them all and let the unzipper tell you if there are any
> filename collisions.
>
> Someone has probably written a "classpath scanner" that will just
> unzip everything and look for conflicts.


I've gotten follow up questions on how to use those tools in the past.
Key is to identify all the jars, less the options of the tool, but since
then I've just reverted to mention the low-tech version, and am not even
ashamed ;)

That's not to say that I don't trust Jonathan to use a classpath scanner
- it's just a low-tech-preference out of habit.

Plus, due to this habit, I currently can't come up with a tool's name to
look for :D

Olaf



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



Re: how do I switch class loaders

2020-05-08 Thread Olaf Kock


On 08.05.20 18:23, Jonathan Yom-Tov wrote:
> Oops, my bad  But that still leaves my original issue: why do I get a
> ClassCastException casting RedissonSessionManager to
> RedissonSessionManager?

The *only* reason that I've ever seen this happens (e.g. a class can't
be typecast to a legitimate superclass or interface): When the
superclass or interface is available through two different classloaders.

The error message omits the classloader, and instead of

  A cannot be cast to B

/should/ read

   A (from classloader X) cannot be cast to B (from classloader Y)

You might want to hunt down duplicate classes in the JAR files on your
classpath. Worst case: unpack them all in temporary directories and
check for occurrences of the filename. Make sure that one doesn't
overwrite the other when unzipping.

Olaf



> On Fri, 8 May 2020, 16:56 Luis Rodríguez Fernández, 
> wrote:
>
>> Hello Jonathan,
>>
>> It is not exactly the same :), look at the "$2" appended at the end.This is
>> an "anonymous inner class" [1]
>>
>> Cheers,
>>
>> Luis
>>
>> [1]
>>
>> https://stackoverflow.com/questions/11388840/java-compiled-classes-contain-dollar-signs
>>
>>
>> El vie., 8 may. 2020 a las 11:52, Jonathan Yom-Tov (<
>> jonathan.yom...@sysaid.com>) escribió:
>>
>>> This is very odd. I ran Tomcat with -verbose:class (see relevant output
>>> below). The class is being loaded twice from the same location, I'm
>>> guessing by two different class loaders. How can that be?
>>>
>>> [Loaded org.redisson.tomcat.RedissonSessionManager from
>>> file:/C:/dev/tomcat.9.0.19/lib/redisson-tomcat-9-3.12.2.jar]
>>> [Loaded org.redisson.tomcat.RedissonSessionManager$2 from
>>> file:/C:/dev/tomcat.9.0.19/lib/redisson-tomcat-9-3.12.2.jar]
>>>
>>> On Fri, May 8, 2020 at 11:04 AM Olaf Kock  wrote:
>>>
>>>> On 08.05.20 09:37, Jonathan Yom-Tov wrote:
>>>>> Thanks Mark. Just tried that. I put the redisson-tomcat jar outside
>> of
>>>>> WEB-INF/lib and added it with scope provided. I get the exact same
>>> issue.
>>>>> What am I doing wrong?
>>>> Make sure, it's actually gone from your webapp. Depending on the
>>>> deployment technique I've seen removed files to persist from previous
>>>> deployments.
>>>>
>>>> You might need to fully undeploy, then deploy the new version without
>>>> the jar in question. But inspect the runtime environment to make sure
>>>> you only have a single library accessible. Having the same class
>>>> available two different ways is a recipe for disaster, don't fix it my
>>>> messing with the classloader: Fix it by eliminating one of them.
>>>>
>>>> You might also check if you're not accessing any wrapped object, e.g.
>> by
>>>> inspecting getManager(session).getClass().getName().
>>>>
>>>> Olaf
>>>>
>>>>
>>>>
>>>>> Here's my code:
>>>>>
>>>>> HttpSession session = httpServletRequest.getSession(false);
>>>>> try {
>>>>> RedissonSessionManager rsm = (RedissonSessionManager)
>>>> getManager(session);
>>>>> } catch (Exception e) {
>>>>> e.printStackTrace();
>>>>> }
>>>>>
>>>>> private Manager getManager(HttpSession session) throws Exception {
>>>>>
>>>>> Field facadeSessionField =
>>>>> StandardSessionFacade.class.getDeclaredField("session");
>>>>> facadeSessionField.setAccessible(true);
>>>>> StandardSession stdSession = (StandardSession)
>>>>> facadeSessionField.get(session);
>>>>>
>>>>> return stdSession.getManager();
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> On Thu, May 7, 2020 at 11:52 PM Mark Thomas 
>> wrote:
>>>>>> On 07/05/2020 21:36, Jonathan Yom-Tov wrote:
>>>>>>> My application uses Redisson (a client which persists the session
>> to
>>>>>>> Redis). There are two Redisson jar files located in
>>> $CATALINA_HOME/lib,
>>>>>> so
>>>>>>> if I understand the docs correctly they're loaded by the common
>> class
>>>>>>> loader.
>>>>>>>
>>>>>>> I want to access the RedissonSessionManager class during a request.
>>> The
>>>>

Re: how do I switch class loaders

2020-05-08 Thread Olaf Kock


On 08.05.20 09:37, Jonathan Yom-Tov wrote:
> Thanks Mark. Just tried that. I put the redisson-tomcat jar outside of
> WEB-INF/lib and added it with scope provided. I get the exact same issue.
> What am I doing wrong?

Make sure, it's actually gone from your webapp. Depending on the
deployment technique I've seen removed files to persist from previous
deployments.

You might need to fully undeploy, then deploy the new version without
the jar in question. But inspect the runtime environment to make sure
you only have a single library accessible. Having the same class
available two different ways is a recipe for disaster, don't fix it my
messing with the classloader: Fix it by eliminating one of them.

You might also check if you're not accessing any wrapped object, e.g. by
inspecting getManager(session).getClass().getName().

Olaf



> Here's my code:
>
> HttpSession session = httpServletRequest.getSession(false);
> try {
> RedissonSessionManager rsm = (RedissonSessionManager) getManager(session);
> } catch (Exception e) {
> e.printStackTrace();
> }
>
> private Manager getManager(HttpSession session) throws Exception {
>
> Field facadeSessionField =
> StandardSessionFacade.class.getDeclaredField("session");
> facadeSessionField.setAccessible(true);
> StandardSession stdSession = (StandardSession)
> facadeSessionField.get(session);
>
> return stdSession.getManager();
> }
>
>
>
> On Thu, May 7, 2020 at 11:52 PM Mark Thomas  wrote:
>
>> On 07/05/2020 21:36, Jonathan Yom-Tov wrote:
>>> My application uses Redisson (a client which persists the session to
>>> Redis). There are two Redisson jar files located in $CATALINA_HOME/lib,
>> so
>>> if I understand the docs correctly they're loaded by the common class
>>> loader.
>>>
>>> I want to access the RedissonSessionManager class during a request. The
>>> problem is that if I do something like RedissonSessionManager manager =
>>> (RedissonSessionManager) session.getManager() I get a ClassCastException,
>>> presumably because they were loaded by different class loaders.
>>>
>>> Will it help if I somehow access the common class loader for this? If so
>>> how can I do that? If not is there some other way I can achieve this?
>> Make sure you don't have those JARs in your application's WEB-INF/lib as
>> well as $CATALINA_BASE/lib.
>>
>> In any recent version of Tomcat any JAR in $CATALINA_BASE/lib will be
>> visible to your application.
>>
>> 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: Tomcat 7.0.103

2020-04-20 Thread Olaf Kock
Hi Greg,

On 21.04.20 04:13, Hebner, Greg D. wrote:
> We are migrating from 7.0.68 to 7.0.103 to close some security 
> vulnerabilities. We are running LDAP authentication via JAAS. Authentication 
> was working normally on 7.0.68. we use scripts to configure Tomcat 
> installations so every install is exactly alike and we get expected results 
> and operation. On version 7.0.103, even though the catalina.out indicates 
> that LDAP authentication succeeded, I am returned to the login page. I have a 
> second authentication mechanism for non-LDAP authentication, and it still 
> operates normally.
>
> Is it possible that some configuration argument has been changed/added that 
> would cause this behavour? When I revert back to the 7.0.68 version, LDAP 
> authentication is restored. Help?

I didn't run into that issue, so can't answer from memory. But
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html might help
identifying - it's a bit of a reading, but might just help you find what
exactly changed and when.

Olaf


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



Re: How to shutdown tomcat

2020-04-17 Thread Olaf Kock


On 17.04.20 16:55, Blake McBride wrote:
> I suppose, never mind.  I created a startup listener that just does a
> System.exit(0) on contextDestroyed which is what I want - exit.
>
> Thanks.
>
> Blake
>
>
> On Fri, Apr 17, 2020 at 8:53 AM Blake McBride  wrote:
>
>> Greetings,
>>
>> I am running vanilla tomcat 9.0.34 on a 64 bit Linux box.  Short of
>> killall, I can't stop tomcat.  I am trying bin/shutdown.sh.  Sure
>> appreciate some help.

The proper solution is in your log:

"The web application [Kiss] appears to have started a thread named
[Thread-5] but has failed to stop it."

If that's not a daemon thread, the JVM, by design, can't stop.

Instead of calling System.exit(), do the right thing and implement
proper shutdown for all threads that the application starts on its own.
Or, if you don't care about interrupting them at inopportune time (as
you demonstrate with System.exit), simply set their daemon flag and
leave their buggy implementation in place.

By the way: This behavior will keep the application from proper
redeployment. My recommendation: Correct your implementation rather than
nuking it from orbit.

Olaf

>> 17-Apr-2020 08:44:41.745 WARNING [main]
>>  org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
>> web application [Kiss] appears to have started a thread named [Thread-5]
>> but has failed to stop it. This is very likely to create a memory leak.
>> Stack trace of thread:
>>  sun.misc.Unsafe.park(Native Method)
>>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>
>>  
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2044)
>>
>>  
>> java.util.concurrent.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:492)
>>  org.kissweb.rest.QueueManager$Dispatcher.run(QueueManager.java:61)
>>  java.lang.Thread.run(Thread.java:748)
>> 17-Apr-2020 08:44:41.745 WARNING [main]
>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
>> web application [Kiss] appears to have started a thread named
>> [pool-1-thread-1] but has failed to stop it. This is very likely to create
>> a memory leak. Stack trace of thread:
>>  sun.misc.Unsafe.park(Native Method)
>>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>
>>  
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2044)
>>
>>  java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>>
>>  
>> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
>>
>>  
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
>>
>>  
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>  java.lang.Thread.run(Thread.java:748)
>> 17-Apr-2020 08:44:41.749 INFO [main]
>> org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
>> ["http-nio-8080"]
>> 17-Apr-2020 08:44:41.750 INFO [main]
>> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
>> ["http-nio-8080"]
>> blake@i9-tower:~/intellijProjects/Kiss/tomcat/logs$
>>

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



Re: learning tomcat 7 on Linux

2020-04-08 Thread Olaf Kock


On 08.04.20 14:55, Andy Sloane wrote:
> Hi,
> I have set up a Linux CentOS 7 host, and have installed Tomcat 7...
>
> ...
> I would like to learn how to develop webapps.
>
I see no particular reason to start with Tomcat 7. Most of the code that
you will learn will be version independent, and the End of Life for
Tomcat 7 is already set to March 2021. I'd recommend to go with Tomcat
9. Installation - especially for development purposes - will be trivial
and is easier for development anyway.

I'm assuming you're running the old version, because that's what the
CenOS repositories hold. For development: No need to do this.

I don't know Richard's course, but I assume that he'll talk about a
development environment and installing a new dev environment as well:
Use that, rather than whatever comes with CentOS. Access permissions on
the files of a development server are far simpler than on fully
public-server-enabled installs.

Olaf


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



Re: How to increase Memory available to Tomcat?

2020-03-31 Thread Olaf Kock


On 31.03.20 17:02, o haya wrote:
> Hi,
>
> I am running Tomcat 9.02 under RHEL 7 (under Oracle JDK 1.8), and I would
> like to increase the memory that is available to Tomcat when it is running.
>
> I have tried sourcing the following:
>
> JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \
> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m
> -XX:+DisableExplicitGC \
> -Djava.security.egd=file:/dev/./urandom -d64"

You want to use CATALINA_OPTS for memory settings, not JAVA_OPTS.

JAVA_OPTS are used for every JVM start, including when you run
shutdown.sh - that one needs only a minimal amount of memory for short time.

> and also:
>
> CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \
> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m
> -XX:+DisableExplicitGC \
> -Djava.security.egd=file:/dev/./urandom"

your CATALINA_OPTS will be combined with the JAVA_OPTS, so that you
configure the memory twice.

But -Xms and -Xmx are the way to configure the memory.

> but even with those, when I check memory using "free", it is only using
> about 1.5GB.
>
> Can someone tell me how I can accomplish this?

Sounds suspiciously like you're running on 32bit, either the OS or JVM.
Upgrade to 64bit to have access to more memory.




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



Re: Does Tomcat/Java get around the problem of 64K maximum client source ports?

2020-03-26 Thread Olaf Kock
Hi Eric,

On 26.03.20 18:58, Eric Robinson wrote:
> Greetings,
>
> Many people say the maximum number of client ports is 64K. However, TCP 
> connections only require unique sockets, which are defined as...
>
> local_IP:local_port -> remote_ip:remote_port
>
> Theoretically, it is possible for a client process to keep using the same 
> local source port, as long as the connections are to a unique destinations. 
> For example on a local machine, the following connections should be 
> possible...
>
> 192.168.5.100:1400 -> 192.168.5.200:3306
> 192.168.5.100:1400 -> 192.168.5.201:3306
> 192.168.5.100:1400 -> 192.168.5.202:3306
> 192.168.5.100:1400 -> 192.168.5.203:3306
>
> I've seen this demonstrated successfully here:
>
> https://serverfault.com/questions/326819/does-the-tcp-source-port-have-to-be-unique-per-host
>
> As someone on that page pointed out, while it is possible, it does not 
> commonly occur in practice "because most TCP APIs don't provide a way to 
> create more than one connection with the same source port, unless they have 
> different source IP addresses." This leads to the 64K maximum client port 
> range, but it is really a limitation of the APIs, not TCP.
>
> So how does tomcat handle things? Is it limited to a maximum 64K client 
> source ports, or is it 64K per destination, as it should be?

To be honest, I can't remember to have seen a web- or application server
that accepts 64K concurrent connections at all, let alone to a single
client.

I can't come up with any reason to do so, I'd assume that there's a DOS
attack if I get 100 concurrent incoming connections from a single IP,
and a programming error if the server sets up more than 1K outgoing
connections

Maybe I'm missing the obvious, or have only administered meaningless
installations, but I fail to see the real world relevance of this question.



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



Re: Is it possible to programmatically compile jsp files?

2020-03-25 Thread Olaf Kock


On 25.03.20 15:19, Jonathan Yom-Tov wrote:
> Sounds good. What would be the best way of evaluating the result so I can
> cache it?

Buffer the output (e.g. by providing a buffered stream for the response)

I'm not sure if this means that you'll need to wrap the response object,
of if you could just replace its output stream. But in general: In your
filter, make sure you get hold of the output stream and capture its
content before you pass the request along the filter chain. After
returning, obtain the buffer, save it for future use, then dump it on
the original output stream. The commons project has a couple of nice
options (I vaguely remember a TeeOutputStream or similar, which would
automagically be able to keep your current client happy, while also
filling up the buffer)


Olaf



> On Wed, Mar 25, 2020 at 4:03 PM Olaf Kock  wrote:
>
>> On 25.03.20 14:51, Jonathan Yom-Tov wrote:
>>> I think I phrased my question incorrectly. What I want to do is to cache
>>> the HTML resulting from the JSPs evaluation so I can serve the cached
>>> result. The reason is that I'm working on an application which makes a
>> lot
>>> of requests per page. This makes the page very slow. What I want to do is
>>> to serve some of the requests which build the page out of a cache.
>>> Rewriting the offending endpoints would be a very lengthy process. There
>>> are a lot of them and they're part of a legacy project which is very hard
>>> to get into.
>>>
>>> So is pre-evaluating the JSPs the correct strategy or is there a
>> better way?
>>
>>
>> well, with that, you could either request the JSP yourself and cache the
>> result. To do this transparently, you could implement a ServletFilter
>> that caches the result if it senses a cacheable request and (on
>> subsequent requests) transparently serves the value from cache as long
>> as the criteria ("should re-evaluate") holds.
>>
>> Bonus points for taking care of concurrent requests during
>> re-evaluation, and pause them during the time a re-evaluation is done in
>> a different request.
>>
>> Olaf
>>
>>
>>
>>
>> -
>> 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: Is it possible to programmatically compile jsp files?

2020-03-25 Thread Olaf Kock


On 25.03.20 14:51, Jonathan Yom-Tov wrote:
> I think I phrased my question incorrectly. What I want to do is to cache
> the HTML resulting from the JSPs evaluation so I can serve the cached
> result. The reason is that I'm working on an application which makes a lot
> of requests per page. This makes the page very slow. What I want to do is
> to serve some of the requests which build the page out of a cache.
> Rewriting the offending endpoints would be a very lengthy process. There
> are a lot of them and they're part of a legacy project which is very hard
> to get into.
>
> So is pre-evaluating the JSPs the correct strategy or is there a
better way?


well, with that, you could either request the JSP yourself and cache the
result. To do this transparently, you could implement a ServletFilter
that caches the result if it senses a cacheable request and (on
subsequent requests) transparently serves the value from cache as long
as the criteria ("should re-evaluate") holds.

Bonus points for taking care of concurrent requests during
re-evaluation, and pause them during the time a re-evaluation is done in
a different request.

Olaf




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



Re: Is it possible to programmatically compile jsp files?

2020-03-24 Thread Olaf Kock


On 24.03.20 15:44, Jonathan Yom-Tov wrote:
> I have a set of jsp files. These jsps' compilation result changes whenever
> a variable in my cache changes. I want to compile them whenever that
> variable changes so they're ready to serve without going through the normal
> pipeline. Is that possible?
>
Sounds a lot like you're runtime-generating JSPs. I'd rather recommend
to implement a taglib or some other means to generate output dependent
on your cache's content.

At least I can't come up with a different idea for why a compilation
result would depend on some runtime data.

With runtime generation, you might easily run into concurrency issues,
e.g. requesting a JSP while it's overwritten, and only half of the file
is generated (or the file is not yet readable). This would leave a
compiler error, and if the timestamp doesn't update any more, leave you
with a weird result.

Is it possible? Sure. Is it likely the right solution to your problem: I
doubt (until proven opposite)

Olaf


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



Re: AW: gostCat patch

2020-03-23 Thread Olaf Kock


On 23.03.20 15:07, Mark Thomas wrote:
> On 23/03/2020 14:02, Fritze, Florian wrote:
>> Maybe I am making it too easy but if you or another tomcat developer could 
>> prevent the newest Tomcat from throwing this exception: 
>>
>> org.apache.catalina.core.StandardService.startInternal Failed to start 
>> connector [Connector[AJP/1.3-8011]]
>>  org.apache.catalina.LifecycleException: Der Start des 
>> Protokoll-Handlers ist fehlgeschlagen
>>  at 
>> org.apache.catalina.connector.Connector.startInternal(Connector.java:1057)
>>  at 
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>  at 
>> org.apache.catalina.core.StandardService.startInternal(StandardService.java:440)
>>  at 
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>  at 
>> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766)
>>  at 
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>  at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>  at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(Method.java:498)
>>  at 
>> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
>>  at 
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
>>  Caused by: java.lang.IllegalArgumentException: The AJP Connector is 
>> configured with secretRequired="true" but the secret attribute is either 
>> null or "". This combination is not valid.
>>  at 
>> org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274)
>>  at 
>> org.apache.catalina.connector.Connector.startInternal(Connector.java:1055)
>>  ... 12 more
>>
>> This could solve the problem for me: Please just let the tomcat run through 
>> and do not let it check for the validation criterion.
> Sorry, no.
>
> Research indicated that a large number of Tomcat users were running an
> AJP connector in an insecure configuration. The Tomcat team made a
> deliberate choice to break those configurations and require users to
> make configuration changes either to secure those configurations or to
> explicitly allow the insecure ones.

I applaude this decision. I believe that the error message is clear
enough to point to the root cause - and with the public awareness of the
Ghostcat vulnerability and necessity to patch, the release notes are
quite clear about the changed defaults.

The only change that I'd assume could help is to add a comment to
server.xml, next to the commented-out AJP-Connector, that states: "This
configuration isn't complete - read the documentation, particularly
'secretRequired', 'secret', ... to learn about the proper settings". But
even if that doesn't go in, the necessary change should be found quickly
given the above error message.

Olaf




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



Re: Security audit raises questions (Tomcat 7.0.93)

2020-03-18 Thread Olaf Kock


On 18.03.20 01:04, James H. H. Lampert wrote:
> On 3/17/20 3:50 PM, Mark Thomas wrote:
>> The XXS might be valid. I assume the tool provided a sample URL you
>> could use to validate the finding. That should point you in the right
>> direction but feel free to ask here if more help is required.
> Near as I can tell, it did but it didn't provide a sample URL.
>
> Note that *all* I have is a PDF of the report, and I think the URL may
> have gotten mangled by spanning a page-break. I've posted a screenshot
> (with identifying information redacted) of what I'm looking at in the
> report:
>
> https://www.flickr.com/gp/64159238@N03/02i78o
>
This issue, according to that screenshot, seems to be on an error.jsp.
The only error.jsp that I could find in Tomcat 7.0.93 and 7.0.100 is in
webapps/examples/jsp/security/protected/error.jsp, i.e. under
/webapps/examples

Are you sure that this is for tomcat, not for your own application?
Looking at tomcat's jsp, it's as simple as it can be, takes no external
input, and doesn't generate markup as the one you've posted. But just in
case: That examples webapp probably shouldn't be deployed on production
servers anyway (seeing it there, IMHO it'd be a good idea to not package
it in this way in the first place, but that's a different story)

Cheers,

Olaf


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



Re: Tomcat 8.5.51 fails

2020-02-13 Thread Olaf Kock

On 13.02.20 11:17, Olaf Kock wrote:
> On 13.02.20 10:36, kohm...@iris.eonet.ne.jp wrote:
>> On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote:
>>> Check in the file (tomcat_dir)/conf/server.xml, the Connector :
>>>
>>>      
>> The setting is the same as mine.
>>
>> I have use server.xml used in 8.5.50. In case of 8.5.50, I have no
>> problem.
>>
>> Please notice, I have been using Tomcat for 5 years with updates.
>> Why this time?
>
> Because this time, security relevant defaults changed: See these recent
> commits on the git mirror:
>
> https://github.com/apache/tomcat/commit/b962835f98b905286b78c414d5aaec2d0e711f75#diff-8dc0090e11bd1ca2caa389bb79d52262
>
> https://github.com/apache/tomcat/commit/2becbfd3228942a18b663ca715ee9c9b80743120#diff-8dc0090e11bd1ca2caa389bb79d52262

Or, even better digestible (I hit 'send' too early):

Mark's announcement of the availability contained:

> - AJP defaults changed to listen the loopback address, require a
secret and to be disabled in the sample server.xml

And the changelog on
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html for 8.5.51
contains this information on AJP:

  * Update: Disable (comment out in server.xml) the AJP/1.3 connector by
default. (markt)
  * Update: Change the default bind address for the AJP/1.3 connector to
be the loopback address. (markt)
  * Add: Rename the |requiredSecret| attribute of the AJP/1.3 Connector
to |secret| and add a new attribute |secretRequired| that defaults
to |true|. When |secretRequired| is |true| the AJP/1.3 Connector
will not start unless the |secret| attribute is configured to a
non-null, non-zero length String. (markt)
  * Add: Add a new attribute, |allowedRequestAttributesPattern| to the
AJP/1.3 Connector. Requests with unrecognised attributes will be
blocked with a 403. (markt)

There's also a discussion on the "Re: [ANN] Apache Tomcat 9.0.31
available" thread on this changed default that might give you some
background.

I hope, this helps,

Olaf



Re: Tomcat 8.5.51 fails

2020-02-13 Thread Olaf Kock


On 13.02.20 10:36, kohm...@iris.eonet.ne.jp wrote:
> On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote:
>> Check in the file (tomcat_dir)/conf/server.xml, the Connector :
>>
>>      
>
> The setting is the same as mine.
>
> I have use server.xml used in 8.5.50. In case of 8.5.50, I have no
> problem.
>
> Please notice, I have been using Tomcat for 5 years with updates.
> Why this time?


Because this time, security relevant defaults changed: See these recent
commits on the git mirror:

https://github.com/apache/tomcat/commit/b962835f98b905286b78c414d5aaec2d0e711f75#diff-8dc0090e11bd1ca2caa389bb79d52262

https://github.com/apache/tomcat/commit/2becbfd3228942a18b663ca715ee9c9b80743120#diff-8dc0090e11bd1ca2caa389bb79d52262




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



Re: Question on Apache Tomcat Patches

2020-02-11 Thread Olaf Kock


On 11.02.20 15:39, Walker, Mike (GE Aviation, US) wrote:
> So apache only releases full versions not upgrades?  Does that mean if you 
> run the version 7.99 it will create a new folder under Apache Software 
> Foundation folder for 7.99 files? Since this would imply a change to the path 
> for Tomcat would registry or other tomcat config files need to be modified 
> for the new path? I assume all deployed .war files would need to be 
> re-deployed in the new version also?
>
Simple:

The directory within the zip file will carry the number. Nothing forces
you to continue to use that version numbered directory in your
installation. You're free to move its contents around, rename the
directory etc.

I hope that helps,

Olaf


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



Re: RewriteValve does not work on HTTPS

2020-02-04 Thread Olaf Kock

On 04.02.20 20:31, Hua Zhang wrote:
> Best tomcat team,
>
> Hereby I have a question about an issue I found by using RewriteValve
> on tomcat 9.30
>
> The rewrite.config is very simple:
>
> /RewriteCond %{HTTP_HOST} =youkoop.com 
> RewriteRule ^.*$ https://www.youkoop.com [R=301,L]
> /
>
> All I want is just redirect a naked root domain to a www domain with
> HTTPS.
>
> The redirection works on HTTP but not HTTPS.
>
> http://youkoop.com => https://www.youkoop.com *works*
>
Note: Images don't get through in this mailing list. I can imagine what
"works" means, but for your next example: Please elaborate what "does
not work" means.
>
> *https*://youkoop.com  =>
> https://www.youkoop.com *does not work*

First thing to test: Does https://youkoop.com work without the redirect,
then with the "wrong" host name? Otherwise it might be as simple as a
misconfigured TLS host that's never invoked because of a certificate
mismatch.

Olaf



Re: Dates on Linux vs. Windows - Resolved

2020-01-08 Thread Olaf Kock


On 08.01.20 06:05, Jerry Malcolm wrote:
> Just to summarize for anybody who comes along with a similar
> problem I original set the timezone of mySQL RDS instance to
> Central time when I created it months back (unchangable after it's
> set).  I set my Linux timezone to Central as well in order to make my
> log files have entries with the correct timestamps.  But as I
> described earlier, changing the OS timezone made the JVM also go to
> Central as well.  But the JVM apparently assumed the database was in
> GMT so it subtracted 6 more hours off the already-central time from
> the db.  I guess the real error was not initially leaving the MySQL
> RDS in GMT.  But since that's not changeable without recreating a
> whole new RDS instance, the next option is what I did with the jvm.  
> Makes total sense, right???  :-)


That's why my personal general recommendation is to run all server code
and OS, and especially all stored data, in UTC only. Optionally, for
selected output (e.g. website display) have the application explicitly
convert to a timezone, dependent on the current user (see Christopher's
excellent answer). It's work, but it's what needs to be done. There is
no "it just works" when handling time without being explicit -
especially in the web / server world, where people access from different
timezones. Desktop applications can be more relaxed (but shouldn't).

Granted, it's easier for me with UTC being one or two hours off during
the year, but the advantage is: UTC is "forward only" - there's no
daylight saving back and forth, no need to interpret anything, just the
plain timestamp. On the technical side (logs) that's what I want, even
if it requires a bit of mental math.

I'm not always remembering to set all of this right away, but it's the
first thing I retroactively do once I run into those problems.

Olaf


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



Re: Tomcat 9 does not allow to read file in /tmp folder with 777 permission?

2020-01-04 Thread Olaf Kock


On 04.01.20 15:35, bphamhuu wrote:
> Hello,
>
> I have a java web application by Tomcat 9 servlet container which tries to
> read a file in /tmp folder with 777 permission on Ubuntu 18.04
>
> ls -ltr /tmp/test.txt
> -rwxrwxrwx 1 vagrant vagrant 10 Jan  3 17:03 /tmp/test.txt
>
> The java code is:
>
> try {
> result = FileUtils.readFileToString(new File("/tmp/test.txt"));
> } catch (IOException ex) {
> log.info("# Cannot read file. Reason: " + ex.getMessage());
> }
>
> But it always show the error
>
> # Cannot read file. Reason: File '/tmp/test.txt' does not exist


You're running tomcat on Ubuntu, I'm assuming you use the version from
the Debian repositories, not one that you downloaded from tomcat.apache.org.

Debian's tomcat is sandboxed. Read /usr/share/doc/tomcat9/README.Debian
(or an online version at
https://salsa.debian.org/java-team/tomcat9/blob/master/debian/README.Debian)
for more information (search for "sandboxed" to find the proper place)

Credits: I keep this under my belt since Emmanuel Bourg answered a
similar question on this list a while back.

And don't forget to reset the 777 permissions.

Olaf


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



Re: HSTS not apply to some request URI path on tomcat 8.5.9 Centos 7

2019-12-26 Thread Olaf Kock

On 26.12.19 11:22, Pattavee Sanchol wrote:
> Dear support team
>
> I config tomcat server to enabled HSTS some request URI path not
> response with Secure heading
>
> ...
>
>
> I some request URI such as http://192.168.1.1/%20 is not response with
> security hedering
>
>
> this is working
>
>
> image.png
> this not working
> image.png
>
Note: Images are stripped from the list, but I hope that I get the
problem: You're trying to deliver the HSTS header for some, but not all
of the requests coming in(?) (Otherwise, please correct)

I believe that this is chasing a ghost: It's a lot of work to make it
happen, but doesn't have any meaningful advantage: If *any* request
states that the server *only* wants to see HTTPS traffic, it doesn't
matter if *more* requests also state the same: The server will need to
provide proper answers to any HTTPS connection. You're basically asking
everybody who ever saw the HSTS header during the last 31536000 seconds
(your configuration) to rewrite a http-URL to a https-URL.

Thus, I'd recommend to just not worry about any specific conditions to
apply for those headers. Just send them - they don't harm, or make any
difference. Or give us some more specific reasons that I might have missed.

Olaf



Re: Exception while starting tomcat version 9.0.29

2019-12-20 Thread Olaf Kock


On 20.12.19 13:28, Kushagra Bindal wrote:
> Hi,
>
> We are working on upgrading our tomcat version from 8.5.24 to 9.0.29. In
> this process, while starting one of our services we found that while
> starting catalina.out is having some exception.
>
> Note: This exception we are getting before start of tomcat.
>
> 20-Dec-2019 09:52:09.144 WARNING [main]
> org.apache.tomcat.jdbc.pool.DataSourceFactory.getObjectInstance
> org.apache.catalina.UserDatabase is not a valid class name/type for this
> JNDI factory.
> 20-Dec-2019 09:52:09.145 SEVERE [main]
> org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans
> Unexpected error creating MBeans
> java.lang.NullPointerException
> at
> org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:129)
> at
> org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:71)
> ...
> 20-Dec-2019 09:52:09.148 SEVERE [main]
> org.apache.catalina.realm.CombinedRealm.startInternal Failed to start
> [org.apache.catalina.realm.UserDatabaseRealm] realm
> org.apache.catalina.LifecycleException: No UserDatabase component
> found under key [UserDatabase]
> ...
>
> Below is the server.xml file details.
>
>
> --
>
> ...
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>   factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>  
> url="jdbc:postgresql://<>:5444/<>?targetServerType=mastercurrentSchema=common"
>   pathname="conf/tomcat-users.xml" />
>   
> ...
>
>
Phew, that server.xml would have been so much more readable if you'd
removed all the commented xml before posting.

Anyway, I've shortened the log and server.xml in my quote to what I
assume is the cause for the error message. The stock server.xml contains
a MemoryUserDatabaseFactory, while it looks like your declaration is for
a generic JDBC connection.

    

>From the top of my head I can't give you the right class name to use,
but knowing this cause might put you on the right track.

Olaf




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



OT Developer Praise - was Re: EOL for Tomcat 9.X ?

2019-10-22 Thread Olaf Kock


On 22.10.19 17:56, Michael Osipov wrote:
> Am 2019-10-22 um 16:43 schrieb Christopher Schultz:
>>
>> So Tomcat 9 is looking good for aother 10 years at this point.
>
> ...and this is the reason why I appreciate the Tomcat devs' work. I
> can simply stick to a version and virtually forget about compat issues.
>
For me the reason is that I've never worried which version to pick:
Always picked the latest available and never ran into issues where the
newer version was imposing problems when used instead of the earlier
version. And that includes major version upgrades

Big Thank You!

Olaf


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



Re: Adding the manager app to an existing installation

2019-10-18 Thread Olaf Kock


On 18.10.19 17:21, Tom Povey wrote:
> Hi,
>
> I’ve been asked to help with an existing Tomcat install which is supporting a 
> live website. When it was installed, it did not have the manager app added. 
> We want to use the manager app now.
>
> I have copied the manager folder from another Tomcat install (same version 
> which is 5.5.36) and updated tomcat-users in the /conf directory but I can’t 
> login to the manager gui. I give the username and password for the 
> manager-gui role but it just comes back and redisplays the login prompt.

tomcat-users.xml, as far as I remember, requires restart of the server
to be taken into account. You didn't mention that you did this. Plus,
you only said "updated": By default there's no account in there, I'm
assuming that you "updated" correctly. You might want to post it here
(bar the actual password).

Plus, your version is 1 day shy of being 7 years old, with the
end-of-life being even a few more days longer in the past (30 Sep 2012)
http://tomcat.apache.org/tomcat-55-eol.html

It's about time to move on...

Olaf


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



Re: EOL for Tomcat 9.X ?

2019-10-18 Thread Olaf Kock


On 18.10.19 17:25, Robert Hicks wrote:
> Management is asking me if there is an end of life for Tomcat 9 reported. I
> don't see anything on the tomcat web site.

Mark recently answered this to a the same question for Tomcat 8.5:


There is no official date.

The Tomcat project maintains 3 major versions in parallel. Currently
these are:
- 9.0.x
- 8.5.x
- 7.0.x

We always provide at least 12 months notice of EOL.

Major releases are aligned with releases of the Servlet specification.
The current timetable for the next Servlet spec is TBD.

We haven't even announced EOL for 7.0.x yet so you have:
- x years until Tomcat 10 / Servlet 4.next is released
- 1 year for 7.0.x EOL
- y years until Tomcat 11 / Servlet 4.next+1 is released
- 1 year for 8.5.x EOL

Taking low estimates for x and y of 1 and 2 respectively, you have at
least 5 years before 8.5.x is EOL.

Take that figure as an "Engineering Estimate". Also known as a "wild guess".


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



Re: Password encryption in Tomcat 8.5.35

2019-09-16 Thread Olaf Kock


On 16.09.19 08:24, Olaf Kock wrote:
> If someone has access to the old Wiki's information, it'd be a great
> page to restore.
>
"Do you really want to send this mail?" - "Of course" - "so be it" - m(
Facepalm:

It takes the steps above to think of a way of accessing the old content:
Here it is, courtesy of the wayback machine:
https://web.archive.org/web/20180114041103/https://wiki.apache.org/tomcat/FAQ/Password

Cheers,

Olaf


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



Re: Password encryption in Tomcat 8.5.35

2019-09-16 Thread Olaf Kock


On 16.09.19 06:05, Mohan T wrote:
> Hi,
>
> We are using tomcat 8.5.35, on Red Hat Enterprise Linux Server release 7.4.
>
> Is it possible to encrypt or mask passwords that is being used in the 
> datasource for connecting to database. I am mentioning the credentials in 
> server.xml

There used to be a dedicated FAQ entry at
http://wiki.apache.org/tomcat/FAQ/Password, but the link is broken.

Currently, the only leftover that I can find is
https://cwiki.apache.org/confluence/display/TOMCAT/Security#, which says

> Why are passwords in plain text?
> We have a page dedicated to this topic. FAQ/Password

...but links to the same page this information is on, so the information
seems to be lost.

If someone has access to the old Wiki's information, it'd be a great
page to restore.

Until then, an option to implement this snake oil is mentioned here:
https://stackoverflow.com/questions/129160

Cheers,

Olaf


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



Re: [ANN] Apache Tomcat 9.0.24 available

2019-08-21 Thread Olaf Kock


On 20.08.19 21:43, Christopher Schultz wrote:
> Olaf,
>
> On 8/19/19 09:55, Olaf Kock wrote:
>
> > If nothing changed since I looked at it last time, ubuntu didn't
> > update to a new version, but at most backported some fixes while
> > staying on roughly the same version. At least typically.
>
> > I'm looking at the currently available information on the
> > "tomcat9" package in ubuntu 18.04, and I'm seeing version info
> > like "9.0.16-3~18.04.1".
>
> > If you want to be on the latest and greatest tomcat version, you
> > should rather maintain it for yourself. If you want the
> > distribution to maintain your tomcat, you're likely not on the very
> > latest version.
>
> While these two points are entirely accurate, we have two members of
> the Tomcat community who are either package maintainers or who can
> influence those maintainers.
>
> We have Coty from RedHat who rolls some releases for RHEL/CentOS and
> is pretty much up-to-date with all the releases. IIRC, the yum repo
> tracks the "actual" version numbers from ASF while some other package
> maintainers tend to back-port patches...
>
> ... such as Debian (apt), where Emmanuel is (?) the package manager
>
Hi Chris,

Thank you for the reminder - and thank you to the package maintainers
for keeping the versions up to date - one way or another. The quoted
Ubuntu version led me (repeatedly) down the track of assuming that this
is how it's (still) everywhere, but I'm happy to be corrected.

Old habits die slowly, and once you (well, me) have firmly established a
habit, it's hard to revert. I'll work on it - after all, I like the
perspective of not needing to think about most of my installation myself.

Promising to go more pro-distro in the future.

Olaf



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



Re: Tomcat 9 Getting Started

2019-08-20 Thread Olaf Kock
On 20.08.19 12:28, Enosh Mogire wrote:
> When I execute ls -la /opt/tomcat this is what I get
>
> enosh@hp:~$ ls -la /opt/tomcat
> total 36
> drwxr-xr-x 3 tomcat tomcat 4096 Aug 20 08:55 .
> drwxr-xr-x 7 root   root   4096 Aug 19 10:53 ..
> drwxr-xr-x 9 tomcat tomcat 4096 Aug 14 10:31 apache-tomcat-9.0.22
> -rw-r--r-- 1 tomcat tomcat  220 Apr  4  2018 .bash_logout
> -rw-r--r-- 1 tomcat tomcat 3771 Apr  4  2018 .bashrc
> lrwxrwxrwx 1 tomcat tomcat   32 Aug 13 08:50 latest ->
> /opt/tomcat/apache-tomcat-9.0.14

so indeed you've extracted the archive into a subdirectory: You'll find
/opt/tomcat/apache-tomcat-9.0.22/conf if you're looking for it. You can
move all of the content of the apache-tomcat-9.0.22 folder up one level,
or adjust your chmod command or the cd that you executed before. You'll
just find the content that you expect one folder further down.

Seeing the link in your directory, you should correct it, e.g.

rm /opt/tomcat/latest
ln -s /opt/tomcat/apache-tomcat-9.0.22 /opt/tomcat/latest
cd /opt/tomcat/latest

and continue from there. That directory will have the conf and all of
the other directories you expect.

Olaf


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



Re: Tomcat 9 Getting Started

2019-08-20 Thread Olaf Kock


On 20.08.19 10:14, Enosh Mogire wrote:
> So after installing and extracting the Tomcat archive file, I needed to set
> the required permissions on the files through the commands bellow
>
> enosh@hp:~$ sudo chgrp -R tomcat /opt/tomcat
> enosh@hp:~$ cd /opt/tomcat/
> enosh@hp:/opt/tomcat$ sudo chmod -R g+r conf
>
> The last command returns an error (chmod: cannot access 'conf': No such
> file or directory) and it is where I am stuck. Please advise accordingly,
> thank you.

What do you see when you execute

ls -la /opt/tomcat

?

It might be that you're just extracting into yet another subdirectory,
e.g. /opt/tomcat/apache-tomcat-9.0.24/

Olaf



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



Re: Tomcat 9 Getting Started

2019-08-20 Thread Olaf Kock
On 20.08.19 09:44, Enosh Mogire wrote:
> I trust that your week is well and that this email finds you well. My name
> is Enosh and I am a newbie to the system. I recently started a personal
> learning project with DHIS2 and I needed to install the Apache servlet but
> I keep on getting this error(attached screenshot). Please advise
> accordingly on how to solve this issue. Thank you.

Welcome,

please note that this list is read around the world, and people (like
me) might not know acronyms like DHIS2.

To help you, we'll need more details: "the Apache servlet" is not quite
descriptive, and this mailing list strips attachments - as the error
message most likely contains text: Please post the textual error message
here, along with log file contents and steps to reproduce - ideally with
everything required to reproduce the issue you're facing.

Cheers,

Olaf




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



Re: [ANN] Apache Tomcat 9.0.24 available

2019-08-19 Thread Olaf Kock


On 19.08.19 15:41, John Dale wrote:
> Does this get included in the apt framework for ubuntu automatically?
>
> John
>
>
> On 8/19/19, Mark Thomas  wrote:
>> The Apache Tomcat team announces the immediate availability of Apache
>> Tomcat 9.0.24.

If nothing changed since I looked at it last time, ubuntu didn't update
to a new version, but at most backported some fixes while staying on
roughly the same version. At least typically.

I'm looking at the currently available information on the "tomcat9"
package in ubuntu 18.04, and I'm seeing version info like
"9.0.16-3~18.04.1".

If you want to be on the latest and greatest tomcat version, you should
rather maintain it for yourself. If you want the distribution to
maintain your tomcat, you're likely not on the very latest version.

Olaf




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



Re: AW: Updating tomcat 7 to 9 got problems

2019-06-07 Thread Olaf Kock
Christopher,

On 07.06.19 16:41, Christopher Schultz wrote:
> Olaf,
>
> On 6/7/19 10:04, Olaf Kock wrote:
> > On 07.06.19 15:30, Support  wrote:
> >> Hi,
> >>
> >> it is not working my folder structure is usr/share/tomcat
>
> > [snip]
>
> > Further, if you've used your distro's packaged Tomcat installation,
> > the best way to get support for it might be through your distro's
> > forums. Tomcat installations from Linux package managers tend to be
> > exploded into a lot of directories that are unexpected in case one
> > is only used to the standard downloaded version and its directory
> > structure.
>
> Keep in mind that RedHat's package maintainer for Tomcat is a member
> of the Tomcat PMC, so asking here is actually likely to yield some
> good results.

That's good news (to me). Must have missed by my attention while reading
along

(Also sorry for misattributing the first quote to Bernd Schatz, I've
been overeagerly removing lines, correcting now)

Re-reading the original post, this was originating at a managed package,
but ended with the updated package installed from the regular distribution.

My main suggestion for this would be:

* Uninstall the package-manager version (7) to make sure not to have any
conflicts.
* Make sure that the permissions are right on the directories and
documented scripts
* and still: Provide more information on *how* it *doesn't* work.

Cheers,

Olaf


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



Re: AW: Updating tomcat 7 to 9 got problems

2019-06-07 Thread Olaf Kock


On 07.06.19 15:30, bernd.sch...@daimler.com wrote:
> Hi,
>
> it is not working my folder structure is usr/share/tomcat

On top of Bernd's questions: Please provide as much detail as you can.
"It is not working" isn't really helpful for coming up with additional
suggestions. How exactly is it not working? Do you see error messages
(as Bernd asked for the log), does it not start at all? Are the
applications not running, but Tomcat does?

We need to know what you observe, not what you want to observe (e.g.
everything working correctly), only then will we have the opportunity to
provide some help.

Also, note that there was no Tomcat 7.2. There was a 7.0.2 beta (in
2010), so I'm not even really sure where you come from.

Further, if you've used your distro's packaged Tomcat installation, the
best way to get support for it might be through your distro's forums.
Tomcat installations from Linux package managers tend to be exploded
into a lot of directories that are unexpected in case one is only used
to the standard downloaded version and its directory structure.

Best,

Olaf


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



Re: Running sudo from a servlet

2019-05-23 Thread Olaf Kock


On 22.05.19 18:31, Christopher Schultz wrote:
> Claude,
>
> On 5/21/19 14:20, Claude Brisson wrote:
> > (responding to myself)
>
> > The culprit is the option
>
> > NoNewPrivileges=true
>
> > in the file
> > /etc/systemd/system/multi-user.target.wants/tomcat8.service
>
> > When changed to false, one must also call 'systemctl daemon-reload'
> > and after a tomcat restart, the problem is solved.
>
> I'd seriously consider whether or not you want to actually do this.
>
> It might be better to write a tiny daemon which has elevated
> privileges to perform whatever operation you want and have your web
> application ping it to do some work, rather than making the whole
> Tomcat process able to elevate its privileges.


Seconding this. Running a web-facing daemon with the option of executing
system commands as root is a recipe for disaster. Don't even think of
going there.

There might be rare occasions where there's a good reason for this
architecture, but the keyword here is "rare". It'll need a *very* good
reason. And "how do I enable sudo?" isn't one.

You have been warned, and so has everyone else finding this thread in
future with the intend of making the same architectural decision.

On stackoverflow, this is called the x-y problem
(https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem).
I'd recommend reading a few of those answers and reconsider the
question, to come up with the X instead of the Y.


Olaf




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



Re: Latest Best Practices for Tomcat Tuning

2019-05-22 Thread Olaf Kock
On 22.05.19 16:36, Louis Zipes wrote:
> Hi Experts,
> I know that if you Google 'Tomcat Tuning' you will get some hits  (ex. 
> https://www.mulesoft.com/tcat/tomcat-performance) but  I would like to see if 
> we can have a discussion of best practices for Tomcat tuning from the group 
> of experts here.  Is there an updated top 10 list or something similar or 
> what people have found have greatly helped their performance.   Note that I 
> have looked through the archives but most of the hits I get date back 10 
> years.
>
> My personal situation is I'm running Tomcat 8.5.x on Windows with a third 
> party application.  Since it is a third party application I feel I can't open 
> up the actual coding itself so I'm left to tune around the margins (ex. 
> Parameters in service.bat, maybe try to switch our odbc.jar to a different 
> one, etc) but maybe I'm wrong.
>
> Basically, is there an updated list of best practices that we can discuss 
> here or is this not the appropriate venue.  I'm looking for a more generic 
> conversation that would benefit all users on this forum and if it helps me 
> personally then of course that is great!
>
> Or is the answer always get the stack dumps and analyze from there.   : )

IMHO the generic answer for tuning problems is always:

(1) Identify the #1 bottleneck
(2) Fix it
(3) Now bottleneck #2 has gotten a promotion: If you still feel the need
to continue tuning, continue at (1)

The bottleneck might be:

# CPU (in which case you might be out of luck with a 3rd party application)
# Memory
# I/O
# Database (a specific case of I/O)
# Network throughput, latency

or anything else, e.g. other backend systems.

Sorry, this is pragmatic, but might not be too helpful. It's the long
form of the consultant's standard answer "it depends".

Olaf


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



Re: Problem in ApacheTomcat - 8.0. 37: Files are not displaying in sorted order.

2019-04-24 Thread Olaf Kock
On 24.04.19 14:52, Rahul Ranjan wrote:
> Hi Team,
>
> I am facing an issue which is related to ApacheTomcat-8.0.37. I wrote
> a code to display the files/folder in browser. By default it should
> display in alphabetically sorted order. But it's not showing.
> I have migrated my code from Unix to Linux. In Unix system my code was
> working fine. Can you please tell me what could be the problem? 
>
> I am attaching you a screenshot for reference. I will appreciate any
> help.

Note: Attachments are stripped by the mailing list software

As you're asking for code that's not related to tomcat (just happens to
run on it), I'd expect a place like stackoverflow.com to be a better
place for getting debugging help. But either way, here or there: If you
expect anyone to help you debugging your code, you'll need to provide
it. I'm assuming that you didn't attach your code as an image (because
why would you turn perfectly valid characters into a pixellated image?).

Olaf



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



Re: Could not find datasource: java:/comp/env/jdbc/TOPSDB when start Tomcat 9.0.13

2019-03-25 Thread Olaf Kock



On 25.03.19 03:41, Hua, Gary - Saint Louis, MO - Contractor wrote:
> Hi experts:
> 
> After I deployed my application TOPS to Tomcat server(9.0.13) 
> on Linux box,  and started the server,  I got the following error:
> 
> 
> 1537 [main] FATAL connection.DatasourceConnectionProvider  - Could not find 
> datasource: java:/comp/env/jdbc/TOPSDB
> java.lang.ClassCastException: org.apache.tomcat.dbcp.dbcp2.BasicDataSource 
> cannot be cast to javax.sql.DataSource
> at 
> org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java>
> ...
> 
> I have tried to put different version of tomcat-dbcp.jar   like 
> tomcat-dbcp-7.0.47.jar/ tomcat-dbcp-8.0.23.jar/ tomcat-dbcp-9.0.13.jar  into 
> /opt/TomCat/apache-tomcat-9.0.13/lib, but not the same error occurred.

One way or another, the last sentence most likely is the most relevant
information, and key to solving your problem: Whenever a Java class
can't be typecast to its legitimate superclass or interface, this is a
clear sign that the superclass or interface can be found twice on the
classpath.

The error message only contains the class name, not the classloader, so
the root cause is effectively hidden. Make sure that
javax.sql.DataSource is nowhere to be found in your app's WEB-INF/lib,
and only once in tomcat's lib directory.

Olaf

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



Re: Default Max response size in Tomcat

2019-03-20 Thread Olaf Kock



On 20.03.19 12:08, Saurav Sarkar wrote:
> Just to add the stack trace.
> 
> I am getting ClientAbortException "Connection reset by peer" when i am
> trying to write to the response stream
> 
> 2019-03-20T10:32:28.501+ [APP/PROC/WEB/0] ERR
> org.apache.catalina.connector.ClientAbortException: java.io.IOException:
> Connection reset by peer
> 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at
> org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:364)
...

> 
> On Wed, Mar 20, 2019 at 3:51 PM Saurav Sarkar 
> wrote:
> 
>> Hi All
>>
>> I have a very basic test application which serves bytes from memory and
>> gives it back to the client.
>>
>> Whenever i try to send the request for byte size which is of over 2 GB i
>> get a connection reset error in my server code and a 502 error in my chrome
>> console. Below 2 GB it is working fine.
>>
>> In my client side i execute java script which i execute from the browser.
>> This basically executes an XMLHTTPRequest , gets the response (stores in
>> browser memory) and asks for a save.
>>
>> I would like to know if there Is there max response size default value
>> which is set in default tomcat configuration. ? or any other hints which
>> you can provide in my use.
>>
>>
>> Thanks and Regards,
>>
>> Saurav
>>
>> Below is the servlet or server side code
>>
>>
>>
>> response.setContentLength((int)length);
>>
>>   }
>>
>>   else
>>
>>   {
>>
>> response.addHeader("Content-Length", Long.toString(length));
>>
>>   }

You don't include the initial condition in your code, but I'm assuming
that the first line is hit: response.setContentLength((int)length);

int in Java is defined to be 32 bit, and always signed. That means that
any value larger than 2^31 or Integer.MAX_VALUE can't be expressed in
int as a positive number. In fact, anything between 2^31 and 2^32 will
be interpreted as a negative number, so you're effectively setting the
content length to be negative.

Note that there's also a setContentLengthLong method
https://docs.oracle.com/javaee/7/api/javax/servlet/ServletResponse.html#setContentLengthLong-long-



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



Re: What is `tomcat7/common/` for?

2019-03-13 Thread Olaf Kock


On 13.03.19 15:01, Joel Griffith wrote:

> I installed it using Ubuntu's apt-get install, so installing it again
> won't do anything different. Is there a documentation page
> that lists what files are supposed to be there?
> That would help. I can't seem to find one. 

If you installed through apt-get, you're getting some packaged version
that is distributed all over the file system. You can use "apt-file list
tomcat8" to see what's contained and where it will appear.

This is not comparable with the standard tomcat distribution.

The lib directory might be on /usr/share/tomcat8/lib - in my quick check
it wasn't empty.

Olaf


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



Re: What is `tomcat7/common/` for?

2019-03-13 Thread Olaf Kock


On 13.03.19 14:22, Joel Griffith wrote:
> > I think it was accomplishing something; tomcat7/common/lib/ contained a
> > bunch of .jar files that looked like standard Tomcat installation files
> > (tomcat7-websocket.jar, tomcat-catalina-7.0.68.jar, etc.).  If I switch
> > directories in the deployment script to tomcat8/lib/, which is
> empty, javac
> > complains that it can't find the files to compile.  It looks like
> I'm going
> > to need to go through /usr/share/java/ and find tomcat8 versions of
> all of
> > the .jar files in tomcat7/common/lib/ and symlink those to tomcat8/lib/,
> > unless someone knows a better way.

If your tomcat/lib folder is empty, I suggest to download the
distribution again. It has quite a few files in there. If yours doesn't,
you can either start over, or figure out where they are instead (e.g. if
you're using your Linux distribution's packaged tomcat)

Olaf


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



Re: I'm not able to get acces server status Apache Tomcat/9.0.16

2019-03-05 Thread Olaf Kock


On 04.03.19 19:06, ITMex wrote:
> Hi everyone, I'm running Apache Tomcat/9.0.16 over CentOS 7 so far is
> okay, but I'm not able to get acces to "server status, Manager App and
> Host Manager" menus, even from localhost I got the following message:
>
>
> HTTP Status 404 – Not Found

Did you deploy the manager app? (check your tomcat's webapps directory)
Are you connecting directly to your Tomcat, or to a local reverse proxy
(e.g. Apache httpd or nginx)?

Also, you'd not "even" get access from localhost, but "only", according
to the standard configuration for the manager app, if it is deployed.


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



Re: Tomcat Apache 7.0.79 upgrade to Latest version

2019-02-20 Thread Olaf Kock
Hi Nitin,

John gave you a good primer, for almost all of the rest I'll point to
the fine documentation again. Look at a diff between your current
installation and the plain vanilla download of the tomcat version that
you're running.

What I want to comment on is this:

On 20.02.19 15:33, Nitin Kadam wrote:
> I need to know below details.
> 1 How to take a backup before the upgrade (Main files).

My standard recommendation to this is: Do not specifically back up your
production system, do not plan to "maybe" go back. Rather *take your
existing backup* and *restore* it to a new system. Perform a disaster
recovery, as if your production server failed hard and you can't recover
the data. This will make sure that you have a proper system running
until you switch over to the new system.

This way of working has the nice benefit that you'll prove that your
backup is worth its name. If you don't have a backup: You know what to do.

If you follow this advice, you don't need a specific backup before the
migration.

Of course, you'll need to make sure that the applications that you're
running on the new and restored server use their backend storage
properly - but as we don't have a clue what applications you're running
(and the tomcat list is a bad place to get support for random
applications anyway), this exercise is left for you.


In conclusion: Make sure that your existing backup is worth its name.
Then think further. Operate on a restored server, 100% separate of the
production server that continues to run.

And inspect your installation's diff, read the fine documentation

Olaf



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



Re: Tomcat Apache 7.0.79 upgrade to Latest version

2019-02-20 Thread Olaf Kock


On 20.02.19 14:47, Nitin Kadam wrote:
> Thanks John  for reply..
>
> is there any documentation walkthrough for this upgrade available?
> i am new to Tomcat and e to doing this 1st time, It will be great help if 
> anyone
> provide same.

There's plenty of documentation on https://tomcat.apache.com - start
there and come back here if you don't understand the documentation with
specific questions. We don't know what's configured in your system, thus
can't provide a solution tailored for you.

As John said in a different branch of this thread, upgrading is
typically easy. The less changes you've made to the default
configuration, the easier the migration will be.

Start with the documents I've linked earlier, If you don't understand
parts of it, try to find that section in the regular documentation. If
you still have problems understanding, ask the questions here.

For a "walkthrough" guide for your system, there are plenty of companies
available that provide consulting, as well as training to get you
started. But the documentation is actually quite good.

Olaf



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



Re: Tomcat Apache 7.0.79 upgrade to Latest version

2019-02-20 Thread Olaf Kock


On 20.02.19 13:57, Nitin Kadam wrote:
> Hello Team,
>
> Can you please guide how we can migrate seamlessly from Tomcat
> apache 7.0.79 to 7.0.92 or any latest version that 8.x or 9.x ( Windows
> 2012 R2 server)escr

7.0 to 8.0: https://tomcat.apache.org/migration-8.html

8.0 to 8.5: https://tomcat.apache.org/migration-85.html

8.x to 9.0: https://tomcat.apache.org/migration-9.html

> the current environment is configured with SSL certificate ( SSL 443) .jks
> store and needs to upgrade same due to security vulnerability detected by
> Qualys scanner.

The documents have TLS documentation chapters. If you run into specific
problems, describe them here.

Olaf


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



Re: Anyway to set more max ram to Tomcat 32bit?

2019-01-04 Thread Olaf Kock


On 04.01.19 02:46, ark...@tutanota.com wrote:
> Something wierd seems to be going on... I have an application on tomcat that 
> used to be on a physical windows server 2008 standard 32-bit which I p2v'd 
> with vmware converter over as a VM. I'm upgrading the server to windows 
> server 2008 r2 64bit and instead of doing an inplace, I'm just building 
> another one up and doing parallel side by side, and its a fresh VM from the 
> start, no p2v stuff

This has been well answered in your crosspost on stackoverflow
https://stackoverflow.com/questions/54032183/anyway-to-set-more-max-ram-to-tomcat-32bit-why-there-is-hard-wall-limit-at-1gb

Please note that crossposting without linking all posts to each other is
rather considered disrespectful to those who volunteer to help out the
community for free. People might not know that the question is already
answered in the other location and still invest more time into solving a
long solved problem. See
http://meta.stackexchange.com/questions/141823/why-is-cross-posting-wrong-on-an-external-site
for more reasoning

I've already commented with this suggestion on one of your previous
stackoverflow postings (https://stackoverflow.com/questions/53826860),
that seems to have been posted here as your Alter Ego "Bo", who
collected no good karma)



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



Re: Java Supported Versions for Apache Tomcat/7.0.77

2019-01-03 Thread Olaf Kock


On 02.01.19 23:11, Janakiram Maganti wrote:
> Hi Support,
>
> Can you suggest what is the latest Java 8 version supported for “Apache 
> Tomcat/7.0.77”.
>
According to https://tomcat.apache.org/whichversion.html, there's no
maximum version, it's "Java 6 and later".

E.g. if you're running into specific problems with a particular Java
version, feel free to report an issue.

Olaf


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



Re: insufficient memory for the Java Runtime Environment to continue

2018-12-23 Thread Olaf Kock


On 22.12.18 22:58, Dhaval Jaiswal wrote:
> Application built in such a way that it consum memory and hence, it's
> exhaust all memory and results in crashing Java. Probably GC is not running
> when it reaches to its threshold. Is there a way I can call GC explicitly
> without affecting running application. I believe  need to identify the
> memory consumption as well.

I'd recommend to run the whole system in a profiler, set the memory as
advised to the same -Xms and -Xmx values.

GC *always* runs before an OutOfMemory condition - however, if it's an
allocation issue, technically the JVM isn't out of memory with your
original settings, because it rightfully tries to allocate more from the
OS until it reaches -Xmx. In that case it'd be correct to just stop
working if the OS can't provide more memory.

If you legitimately use that much memory for operations, you might want
to throttle the rate of processing - but we can't tell you where your
code problems are without your code. The problem is clearly application
specific and not tomcat related, as Tomcat happily runs with a lot less
memory.

In the beginning of this (mail-)thread you asked, which thread is
consuming  the memory: We don't know, and as memory isn't allocated to a
thread, it doesn't matter.

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



Re: insufficient memory for the Java Runtime Environment to continue

2018-12-22 Thread Olaf Kock


On 22.12.18 20:17, Dhaval Jaiswal wrote:
> System has allocated all mentioned RAM.
>
> I assume 13 would be fine.

Adding to John's question, what I forgot earlier: Another rule of thumb
is to identify the *minimum* amount of memory that the application can
run with, then add a bit of headroom. Typically there's no need to go
with a humongous heap if garbage collection has a chance to free it all
up quickly. Memory in webappliations typically tends to be largely
short-lived, and (especially) the young generation GC is typically
extremely quick. You want it to rather run often (e.g. through an
imposed memory limit) than rarely (due to a too large heapspace).

Olaf



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



Re: insufficient memory for the Java Runtime Environment to continue

2018-12-22 Thread Olaf Kock


On 22.12.18 13:35, Dhaval Jaiswal wrote:
> I am facing issue of crashing JAVA process and log files attached for
> the same. 
>
> Server total RAM is 16 GB.
>
> catalina.sh having following setting. 
> export JAVA_MEM_OPTS="-Xms1g -Xmx15g -XX:MaxPermSize=1536m"
>
> Can some one help where could be the problem? Which threads are
> consuming memory. How can i get rid out of this issue.

In addition to all the other great answers you already got: I've made it
a principle to configure production systems with identical values for
-Xms and -Xmx. In the end I'm intending to provide the max memory
anyways, and if something goes wrong along the way (as it does for you
in this situation) I prefer to know of the problems right when I start
up the server - not Sunday night at 3am when it tries to allocate the
missing (and allowed) chunk of memory from the OS before failing.

Experimenting along this principle will help you to quickly figure out
how much memory your system actually can provide (be aware of the
required non-heap memory that Christopher mentioned, when forming your
expectations.

Cheers,

Olaf



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



Re: Migrating app from Tomcat5.5.17 to Tomcat7, getting Description The origin server did not find a current representation for the target resource

2018-12-20 Thread Olaf Kock


On 20.12.18 14:04, Bo wrote:
> there is no 64bit for v5, but i see one for v6 and above
>
There doesn't need to be one. The installer just needs to find the 64
bit JRE (or JDK, can't remember when this requirement was changed) and
use it to start tomcat, e.g. for the service.

Tomcat itself, apart from optional native libraries, is pure Java and
architecturally doesn't care about the underlying bitsize. It just needs
to work with the different limitations that come with the various
options, e.g. lower max memory options.

My 2 cent on the rest of the thread:

You already got Mark's attention. If you're hoping that you get more
qualified answers than from him, carry on and upset him. My prediction
is though, that you'll get a solution to your problem sooner (or at all)
when you play nice and don't assume that everybody (or Mark in
particular) is working against you. Follow his suggestions in the other
mails on the thread - if they help: Thank him and apologize. If they
don't help: Provide what he has asked for (and apologize anyway).

Unless you're just interested in trolling. Then you'll rather get a
first row seat on everybody's ignore list. But until then, let's not
discuss what has been delivered in a Tomcat version that saw its end of
life in 2012.



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



Re: Spring+Tomcat

2018-12-13 Thread Olaf Kock
On 13.12.18 05:51, Adlet Azhibek wrote:
> *Hi all!*
> how should download a new version of tomcat with *necessary (.jar) files in
> a "lib" directory? I need, for example, "**spring-websocket-5. 1.3. RELEASE
> .jar" in "lib". What should I do? I've downloaded necessary jar files from *
> https://mvnrepository.com, *but it doesn't work**.*

Define "necessary": No Spring library is necessary for tomcat, so most
likely you can't download Tomcat anywhere *with* all the libraries that
you need for an arbitrary application.

If you have the libraries, you can copy them to tomcat's lib directory
yourself. Or better, bundle them in the webapp's WEB-INF/lib directory
for any webapp that requires them.

If you're a developer/vendor of an application that runs on Tomcat, your
installation instructions (and ideally the delivery package) should
include the libraries that your application requires (and that you're
willing to support). To equip your development environment with the
necessary dependencies, you'll need to use the appropriate way
prescribed by your build tool. E.g. if you use Maven, and you declare a
dependency as "provided", you better make sure that it is provided.

But ideally, have everything that you need in your webapp bundled in
WEB-INF/lib, rather than in tomcat's global lib/ directory.

Does that help, or did I miss an obvious aspect?

Olaf



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



Re: Translation help wanted

2018-11-13 Thread Olaf Kock



On 13.11.18 18:12, Mark Thomas wrote:



Seems time to add some AI-translate add-on to the code.

That is supported but it has to be paid for. That was something I was
thinking about. I have 10k characters of free translation (POEditor uses
either Google translate or Microsoft Automatic Translation) with my
POEditor account. The Tomcat messages average ~67.5 characters per
message so those free credits should be able to translate just under 150
messages.



We've been using automatic translation in Liferay for a while, but IMHO 
this didn't work out well.


Machine translations lack the context, and are rarely right (and 
accurate), but typically confusing, sometimes hillarious, partly rude 
and rather unhelpful. More than that: If even new terms will be 
automatically translated in the future, translators will always have to 
go through *everything* and identify the newly automatically translated 
strings. Not fun.


I'd recommend to not even consider it. At Liferay, which has 
considerable user-facing UI, this was a quick start, that triggered 
corrections once there was a wonky automatic translation. Plus, after a 
while we introduced a mechanism to identify newly translated strings. 
Without that, it's hard to maintain.


My 2 cents,

Olaf



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



Re: Number of Web Applications in one Tomcat

2018-10-29 Thread Olaf Kock



On 29.10.18 09:00, Ahmed, Tarek wrote:


TLDR? Do you deploy one web application per tomcat instance or several?

As you list the arguments quite well, I'd add my answer "it depends": 
General rule of thumb, to be executed in that order: If they're too few 
applications to worry about (and if they're stable): Don't worry, One 
server.


If they're completely unrelated and have different stakeholders and/or 
maintenance intervals: That's a good argument for multiple servers


If there are unstable applications (in the sense of actively maintained, 
forcing frequent redeployments): Another good argument for multiple servers.


If there have been problems in the past with load/memory etc: Good 
argument for multiple servers.


This /might/ end up as one app per server, but the number one is not the 
end goal. There are typically some related apps, with the same 
maintenance intervals and stakeholders - unless one of them is 
problematic, I group them together.


I hope that helps.

Olaf


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



Re: user lockout realm, logging ip addresses

2018-08-18 Thread Olaf Kock



On 18.08.2018 03:58, Alex O'Ree wrote:

Is it possible to configure the user lockout realm to log what ip address
the failed login attempt came from? I know the information needed will also
be in the access log but added it to the "attempt to login from a locked
account" message would be super helpful. Would it be more advisable to
extend the existing lockout realm and modify the log statements myself?
Looking at the source here: 
https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/realm/LockOutRealm.java#L216 
and here: 
https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/realm/LocalStrings.properties#L91, 
you can't configure it. But the realm is simple and you can roll your own.


Is it advisable? If you want that information in this log message: It 
might be your only option. You'll have to decide how intensely you'd 
like to have it.


Olaf

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



Re: 2018.03.07-2 Bundle issue with tomcat 8 - Post

2018-08-17 Thread Olaf Kock



On 17.08.2018 15:40, Mandal, Jayanta wrote:

Tomcat Version : We upgraded our tomcat environment from bundle 2016.10.31-2 to 
2018.03.07-2 & suddenly we are seeing all Post method stopped working with new 
bundle.


Previous Value

Changed Value

Bundle

2016.10.31-2


2018.03.07-2

Tomcat Server:

:  8.0.18-62_patch_01.ep7.el6.-patch-01

8.0.36-17.ep7.el6.0

As the downloads on tomcat.apache.org have only 3 digits for the version 
numbers: You're asking about /some/ version that /someone/ has packaged 
according to unknown standards and with unknown patches. Plus, it's a 
version that is already past its end of life, check 
https://tomcat.apache.org/tomcat-80-eol.html


Your best bet is to upgrade to 8.5 or 9.0. Use a stock version from 
tomcat.apache.org if you expect help on this list. If you expect support 
from your OS vendor (or whoever packaged this version for you), they'd 
be the ones to contact. They might provide support beyond this version's 
end-of-life.


Olaf

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



Re: [tomcat:8.0-jre8] CONFIDENTIAL adds Cache-Control: private?

2018-08-16 Thread Olaf Kock

Hi Martynas,

On 16.08.2018 14:40, Martynas Jusevičius wrote:

Hi,

my initial observations suggest, and SO post [1] seems to confirm, that when

 
 CONFIDENTIAL
 

is specified on a security-constraint in web.xml, Tomcat does two things:
1. automatically redirects to HTTPS
2. appends Cache-Control: private and Expires: Thu, 01 Jan 1970
01:00:00 CET response headers

Is that correct?
Without looking at the code, but with you stating this as an 
observation, I'd say yes, there's a good chance for it to be correct 
(well, you obviously observe it, and I can imagine it being on purpose)

I had added the CONFIDENTIAL because I want the redirect to HTTPS.
What I don't want is Tomcat overriding my caching headers and
effectively disabling browser caching.
There's a better way to redirect to HTTPS, rather than using this 
declaration. You can either do this in a servlet filter, proxy through 
Apache httpd or similar (where you can redirect/rewrite), or just deny 
tomcat to serve on port 80 anyways (just have a static redirect on port 
80). Add a pinch of HSTS, and you're set.


If an application declares CONFIDENTIAL, it might not like the content 
to be stored on any disc cache. Sending expired content will serve that 
purpose beautifully. And you're asking for CONFIDENTIAL, not ENCRYPTED 
(note: the ENCRYPTED declaration doesn't exist AFAIK)

Why in the world would those two things be conflated? And how do I
disable this header override behavior?
My best guess: Because one is not meant to be The Solution (TM) for the 
other.

Does disableProxyCaching attribute need to be set to false to in order
to do that? [2]

I'm running the tomcat:8.0-jre8 on Docker.

Pardon the sneaky comment:
Why on earth would someone ask for security related features on a server 
that has reached its end of life?

(this won't solve your problem, but static redirecting will)

I hope that helps,
Olaf

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



Re: Servlet Threads Changing Instance Data

2018-08-15 Thread Olaf Kock

Jerry,


On 15.08.2018 18:14, Jerry Malcolm wrote:
I have a mobile app that issues several http web service calls to 
initialize.  I was making them sequentially with no issues.  I then 
changed to give them all separate threads so they could load 
asynchronously.  Then the bottom fell out.  I started getting empty 
responses and some responses with results of three or four of the 
calls concatenated.  I traced the problem from the app back through 
apache through mod_jk and found the culprit to be Tomcat.


I'm a seasoned Tomcat developer for over 15 years.  I've never seen 
anything like this.  But it's really scary.  What I found is that 
sometime during the execution of one servlet call, it's thread data is 
swapped to thread data of another servlet call.  I know this sounds 
like Twilight Zone.  But here is a log output. At the beginning of 
doGet(), I generated a random text string just to keep track of the 
thread data/:/


Thread: ajp-nio-8009-exec-24 uid: rclebgb -->
Thread: ajp-nio-8009-exec-29 uid: ceycfqd -->
Thread: ajp-nio-8009-exec-29 uid: ceycfqd <--
Thread: ajp-nio-8009-exec-24 uid: ceycfqd <--

Note that when thread 24 starts I store the "rcl..." uid. Another call 
comes in and starts thread 29.  By the time thread 24's servlet code 
is done, it now has thread 29's data.  (The uid is just a quick 
variable for reference.  The request object, response object, 
EVERYTHING is now thread 29's data).


This explains why I'm getting empty responses and other response with 
the data for multiple requests concatenated together.  The "rcl..." 
instance data has totally disappeared, and all of the server calls are 
now using the "cey..." instance data (i.e. response object).


I figure this is some sort of timing/race condition that only occurs 
with a second call coming in while the first call is still in 
progress. I can go back to sending the mobile app calls serially and 
probably work around this.  But this is a huge problem.


Any ideas?  (BTW... Tomcat 9.0.7)



As we don't know which code generates this log output, it's hard to 
judge what actually causes your problem. You say "thread data" is being 
swapped, and the very first aspect that comes to my mind is: Servlets 
are inherently multithreaded, and a common pattern of bugs is if a 
servlet has a member variable that is used for request processing: There 
typically is only one Servlet object ever, thus they all share the same 
state, if the state is stored in a member variable. This might be 
directly in the servlet or in some other component or singleton somewhere.


Any state and request processing must be done on the request/response 
pair, and properly threadsafe in every other part of your code.


And most likely this is an issue that luckily shows up when you're 
issuing a lot of parallel threads due to parallelizing one client. It'd 
be a lot harder to reproduce if it were individual users, who (very) 
occasionally see the wrong data. Consider yourself lucky to have such a 
nice and reproducible issue.


Olaf



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



Re: Tomcat 5.5.17 migration to 6

2018-07-15 Thread Olaf Kock

On 14.07.2018 22:53, David Babooram wrote:

Alright.

I guess the thought the process was to upgrade to 6, then 7, 8


If your application doesn't do anything too tomcat specific, but is 
rather a standard web application, you might be able to just deploy it 
on Tomcat 8.5 and check if it all works, fix problems when they appear.


Rather than migrating 3 times, check what you've configured on Tomcat 
5.5, validate how to do the same on tomcat 8.5 or 9.0, and just do it. I 
haven't ever worried about tomcat versions - because I've never dug 
deeply into Tomcat, and you might be lucky to be able to work the same way.


It might be harder to migrate to a current Java version than to use a 
current Tomcat version.


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



Re: Apache http / tomcat connectors - source code of web-page is displayed rather than web-page

2018-07-05 Thread Olaf Kock



On 05.07.2018 12:35, Sandels Mark (RTH) OUH wrote:

Hi Peter

I would use tomcat to provide https if it could be configured to do this - is 
this fairly easy to do?

The IT Department have given me a Certificate and private key for the server 
(OXNETMDMS04) but do I need to use "keytool" to create a key store for the 
Certificate? (I am referring to the link 
https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html).
I'll go with André and Peter for the cause - that's the one line that 
was well hidden in the ~600 other lines of your httpd.conf.


With regards to https in Tomcat: 
https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html and 
https://tomcat.apache.org/tomcat-9.0-doc/config/http.html are quite good.


Alternatively, you can also just map *everything* from Tomcat through 
JkMount - this way Apache will forward all requests to tomcat, tomcat 
will handle the allowed/disallowed content (e.g. /WEB-INF/*) and you'll 
be safe again while still having encryption handled by Apache. I 
personally like it this way, because this neatly separates various 
aspects - like read-permissions on the private key: What tomcat doesn't 
need to read, it can't reveal to the world. And httpd typically knows 
how to drop root permissions. Too often I see tomcat run as root, 
because that's the quick fix to serve ports 80 and 443.


Not to mention that mod_rewrite has saved my bacon a few times when it 
took only a minute to configure to work around an application problem.


Olaf


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



Re: Apache http / tomcat connectors - source code of web-page is displayed rather than web-page

2018-07-05 Thread Olaf Kock



On 05.07.2018 09:43, Sandels Mark (RTH) OUH wrote:

Hi Olaf

The web-page displays correctly when I connect to Tomcat directly. I posted to 
the tomcat users group as I havn't had any reply to my post to the Apache http 
user group!

In answer to your other question, I do refer to the   and  
elements. The web-page embeds java (I have used NetBeans v8 to write the WAR application) 
within the html and the complete web-page source is displayed including the java commands.

Kind regards
Mark


Hi Mark,

in that case you might want to post some (relevant) tomcat 
configuration, rather than the httpd configuration. And maybe include 
your workers.properties. Log files.


Please post the relevant parts. Your httpd.conf hat almost 600 lines, 
and if there were more than 10 relevant lines for a tomcat question, 
they've been safely buried in the noise. Often it helps to try to 
reproduce a minimal test case for posting to discover the issue. As we 
don't have your environment available and will only be able to read, it 
really helps to boil down to a minimal test case.


Or you're lucky and someone has just been through the same experience - 
but then, the full unfiltered files won't help either.


Olaf



Olaf

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



Re: Apache http / tomcat connectors - source code of web-page is displayed rather than web-page

2018-07-05 Thread Olaf Kock




On 05.07.2018 09:18, Sandels Mark (RTH) OUH wrote:

When I go to my web-page using a browser (Chrome), the source code of the 
web-page is displayed.  I have added the PFX Certificate to Trusted Root 
Certification Authorities on my PC from which I launched Chrome.

Here is the URL I am using - https://oxnetmdms04/OracleStatus/

The oxnetmdms04 server is hosting Apache http (v. 2.4). I am also using Tomcat 
connectors (Tomcat v 9.0.2) which http users to pass the browser request to a 
tomcat service.

There are only a handful of tomcat-related lines in the config you 
posted - and those don't help too much. So far, it looks like you have a 
question with regards to Apache httpd, not Apache Tomcat.


Check if you get the same result when you connect to Tomcat directly.

Also, just to make sure: When you're saying that you get the source 
code, do you refer to the  and  elements that you see in 
your text? Or do you only see the unstyled HTML text? Because you only 
map "/servlet/*", "/*.jsp" and "/*.do" to your tomcat. In case those 
documents reference some CSS and/or Javascript that lives in the same 
webapplication, it won't be served by Apache, as it most likely wouldn't 
match those URLs.





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



Re: Setclasspath error in Tomcat 8.5

2018-06-29 Thread Olaf Kock




On 27.06.2018 23:06, kevin ferguson wrote:

Hi Guys

I have a configured Tomcat server 8.5 and java installed 1.8.0_171.
Java_home and Catalina_home configured and working.  Here is a short
version from my .bashrc
---
#Setup home for java and openolat
export CATALINA_BASE=/opt/tomcat
export CATALINA_HOME=/opt/tomcat
export JAVA_HOME=/usr/lib/jvm/java-8-oracle


I am running Ubuntu 16.04 in virtualbox.  I and trying to setup
Openolat 12.50 Learning management system.  Here is the installation
notes.  https://www.openolat.com/fileadmin/adminwiki/_START_.html

When I create the setenv.sh as per wiki instructions from above,  I
run the ./start on the commandline and get the setclasspath error see
attached below.
--
sudo ./start
: not found/bin/catalina.sh: 7: /opt/tomcat/bin/setenv.sh:
/bin/setclasspath.shcat
This file is needed to run this program
I guess that you or someone modified catalina.sh: The error message says 
that /bin/setclasspath.shcat is missing - this rather looks like someone 
removed a linebreak or started to type a command at the wrong location.


I'd suggest that you compare your bin/ directory content with the plain 
vanilla versions of the files from a fresh download.


Further more: Tomcat does not have a "start" command - it has 
"startup.sh", which you should *never* start as root (e.g. through 
sudo). If you indeed use "start", I suggest that you ask this question 
in the openolat community, because that would be theirs. I don't even 
see any command on that Wiki page you posted, and you're probably not 
asking us to go through the full wiki to figure out which instruction 
you followed, right?


A quick way to locate the problematic line is "grep setclasspath.shcat 
/opt/tomcat/bin/*", the output should give you the name of the file 
containing the typo.


Olaf

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



Re: Can't Connect to Apache.org Network

2018-06-12 Thread Olaf Kock



On 12.06.2018 23:33, Igal Sapir wrote:


Perhaps it to revisit the thresholds that trigger warnings/bans. The 
Tomcat SVN repo might be much larger today than it was when those were 
last examined and set.


You might want to start at https://github.com/apache/tomcat instead of 
pulling down SVN commit by commit. If only for speed.
Unless you want to commit back to svn, that is. (well - I haven't 
checked if that git mirror contains the SVN metadata - you'd be lucky if 
it does)


Olaf

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



Re: Deleting web.xml on tomcat exit

2018-06-07 Thread Olaf Kock

On 06.06.2018 21:36, Mark Thomas wrote:

On 06/06/18 20:30, Jan Tosovsky wrote:

Dear All,

I use tomcat as a Liferay portal engine. It is usually stopped in two steps.
There is Shutdown button available in Liferay Control panel, which stops the
webapp. Once this is finished, it is safe to stop tomcat via the standard
shutdown script.

If tomcat is stopped differently:
* tomcat is shutdown without shutting down the Liferay
* java crashes (out of memory)
* tomcat is killed
* OS is rebooted (driven by server hosting)

it sometimes (not always) deletes some web content, usually JSP pages, to my
experience especially of the ROOT app (in case of Liferay the default Tomcat
ROOT app is replaced with the core Liferay app).

After the last incident even the core config file ROOT/WEB-INF/web.xml was
missing. And without it tomcat was not able to launch the portal properly.

When you know what has happened it is 'easy' to fix.

But I am quite curious why anything is even deleted in such 'crash'
scenarios.

I met this in various tomcat versions, let say 7.0.xx- 8.0.xx running on
Oracle JDK 7-8 on both Windows 7-10 and CentOS 6-7.

Any idea why this happen?

There is no way I can think of that Tomcat would do this. I'd suggest
two things:
1. Talk to Liferay support
2. Change the file permissions


Indeed - I'd also recommend to bring this to the Liferay forums (or 
Liferay support, if you have a support (Enterprise) contract). I've 
never heard such behavior from Liferay, and shutdown in two steps is not 
typically necessary.


In case your shutdown processes run out of memory, it might be as simple 
as allocating a bit more memory, or to validate your custom plugins for 
their memory requirements during shutdown. I'm not aware that Liferay 
uses excessive memory during shutdown.


To add a few more pointers to look at: If you're on a 6.x version of 
Liferay, there's the possibility to deploy hooks that physically 
overwrite JSPs. These might get undeployed and redeployed, but there are 
some caveats to pay attention to - specifically to only overwrite a 
single JSP from a single hook. Technically, you'd be able to overwrite 
Liferay's web.xml from such a hook, but this is utterly useless and 
shouldn't be done. Only in case you're doing this, I could imagine a 
case where web.xml disappears.


But, Mark's recommendation is solid: Check the Liferay forums, this 
doesn't look like a tomcat issue. Send me the link to the forum post and 
I'll take a look at it there.


Olaf


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: How do we prevent directory access in apache

2018-05-29 Thread Olaf Kock

On 29.05.2018 05:07, Jins Raju Abraham wrote:

How do we prevent a directory access in apache. Tried searching this and there 
are a lot of suggestion about doing it in the .htaccess file.


"Apache Tomcat" doesn't know about .htaccess files. "Apache httpd" does, 
but you won't get an answer related to it on the Tomcat mailing list.


Tomcat doesn't display listings by default - search for "listing" in 
conf/web.xml where the default is documented and explicitly configured


Olaf

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



Re: Updating a working installation

2018-05-09 Thread Olaf Kock


On 09.05.2018 17:09, James H. H. Lampert wrote:

Question:

Is there an easy way to bump a working Tomcat installation from one 
release to another, without benefit of Linux "apt-get" or "yum," or 
WinDoze "cab" (this is an OS/400 installation), without having to 
rebuild the whole configuration (webapps, keystore, server.xml, 
web.xml, ) from scratch?




Depending on the changes in your configuration and changes introduced 
between your "come from" version versus the "go to" version.


IMHO the easiest way to figure out is to download your source and target 
version of vanilla tomcat and compare them with a diff tool. Pay special 
attention to the conf folder, and if any of the changes there are actual 
changes or in comments/documentation.


That will show you if
* it's enough to replace files
* you should delete files
* the default configuration of tomcat has changed and you'll need to 
validate if you need to bring those changes forward.


Of course, you'll also need to compare your current custom installation 
with the source version, to figure out which files you use 
out-of-the-box, and which ones you have changed.


It's hard to be more specific with this generic question.

Olaf

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



Re: Tomcat question

2018-04-23 Thread Olaf Kock



On 23.04.2018 14:49, Zahi Fail wrote:

This is the following code from my web.xml file:






Images are the least popular medium to communicate code. And on this 
list, this is actually enforced: Images are stripped. Please post the 
actual text - that should be even easier than creating screenshots.


Olaf

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



Re: ava.lang.IllegalArgumentException: Document base xxxx does not exist or is not a readable directory

2018-04-17 Thread Olaf Kock

On 16.04.2018 22:06, Support wrote:

SEVERE: Error initializing static Resources

java.lang.IllegalArgumentException: Document base
/home/testuser/resources/Raptor
does not exist or is not a readable directory


A few things are slightly off of my expectations:


But if you see below folder/permissions even after 777 it still says not a
readable directory.


it's quite bad practice to open up to 777


drwxr-xr-x. 4 root root35 Apr 16 14:45 /home/
drwxrwxrwx. 3 root tomcat  23 Apr 16 13:26 /home/testuser
drwxrwxrwx. 3 root tomcat  20 Apr 16 13:26 /home/ testuser/resources/
drwxrwxrwx. 7 root tomcat 170 Apr 16 13:27 /home/testuser /resources/Raptor/



If I change the document base to /user/share/tomcat/webapps this error goes

away.

* There are weird spaces in the /home/ directories - I'm assuming this 
comes from copy/paste and you rather mean those directories without the 
spaces. But there's a small chance that you're hiding issues through 
copy/paste/anonymize
* commonly, a directory /home/testuser would belong to a user named 
"testuser", not to root. Is there a reason why it should be owned by 
root? Is "testuser" an actual user account?
* What is the user account that tomcat is running under? What are the 
permissions/owner on  /usr/share/tomcat/webapps ? (note /usr/ vs /user/ 
- I assume a typo in your statement)


Olaf

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



Re: Trying to chase down "too many connection" problems with DB

2018-03-25 Thread Olaf Kock

Hi Shawn,

only some aspects answered for now, inline:


On 25.03.2018 19:31, Shawn Heisey wrote:

On 3/25/2018 3:15 AM, Olaf Kock wrote:
* Liferay comes (optionally) bundled with Tomcat to ease 
installation, however, the tomcat in there will be your own and is up 
to you to upgrade. Yes, new versions of Liferay will come with new 
versions of Tomcat, but new versions of Liferay won't be released 
because a new version of Tomcat is available. Running on an old 
Tomcat is your decision, not Liferay's. And the tomcat committers 
have done a great job providing drop-in-backwards-compatible newer 
versions. Of course, you'll need to validate, but the bundled version 
is no excuse to not upgrade Tomcat


Thank you for your response!

I know that the Tomcat version is basically ours to use or replace.  
Upgrading Tomcat may be perfectly safe for Liferay itself, but we 
cannot be sure that it is completely safe for the applications we've 
written using Liferay.


good - I just wanted to make sure that this is well known. Many people 
are not aware of this fact, when everything comes neatly bundled 
together - but indeed, it's nothing than a vanilla tomcat with an 
application preinstalled (and a few lines of extra configuration - you 
can see an easy diff when you download the same tomcat version in vanilla)


Many of our sites are still using Liferay 6.1.  The customers on those 
platforms are so risk-averse that they haven't allowed us to migrate 
them to 6.2 yet.  We want to get everything upgraded to the latest 
Liferay version, but the upgrade from 6.1 to 6.2 was very 
challenging.  We expect an upgrade to 7.x to be more difficult.


The difficulty of an upgrade is typically directly proportional to the 
level of customization (and the technique used for the customization). 
But that's nothing for the tomcat list.


If somebody can give me evidence to assure me that upgrading Tomcat 
and using configuration X will solve the problem, then I will pursue 
that.  I can't justify an upgrade because it MIGHT fix the problem.


Going to the latest Tomcat 7 release should be so straightforward that I 
assume it's part of the debugging process you're in, just in order to 
check if you're stuck with an issue there. With the positive side effect 
that you get all fixes, even the ones that you didn't know you should have.


* Liferay's default configuration (as configured through the setup 
wizard) configures the database with an internal connection, not 
using an appserver-configured pool. Please confirm that you manually 
configured Liferay for the appserver-provided pool.


We are using Liferay's configuration in portal-ext.properties for the 
Liferay database.  The pools configured in tomcat are used for our 
application, not Liferay itself.  The only complaint I have about 
Liferay's pool is that it seems to use more connections than I think 
should be necessary. But it IS re-using the pool (all connections are 
idle less than one minute), so it's not on my radar at the moment.  
The connections in the tomcat pools are NOT being re-used like I 
expect them to.


Liferay can be configured with URL/user/password/driver, or with a JNDI 
name - the later naturally referring to a container-provided pool. Both 
configurations are in portal-ext.properties.


Can I configure additional pools in portal-ext.properties for our 
application to use?  If so, is that recommended?  That will probably 
require code changes, but if it solves our difficulties, I'm not 
opposed to it.  We already need to touch all of that code anyway to 
adjust how we're closing JDBC resources.  Maybe we should find a new 
way to handle connection pooling.


I rather prefer to configure pools through the container. But yes, you 
can configure pools in Liferay's configuration as well. Ctrl-F "pool" in 
https://docs.liferay.com/portal/6.2/propertiesdoc/portal.properties.html 
(AFAIK no changes between 6.1 and 6.2)


* It might help looking at the pool/connection states through JMX, so 
that you can determine which pool is active on which size.


Does JMX work for pools other than the one for Liferay?  As soon as I 
can work out exactly where to add the remote JMX properties, I can 
give that a try.  If it's easy for you to tell me best practices for 
adjusting the java commandline for startup, please do.


Just look at what's available by default. I never needed to add more, 
rather needed to find the relevant info. Plenty of information 
everywhere for enabling/connecting through JMX.


Olaf




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



Re: Trying to chase down "too many connection" problems with DB

2018-03-25 Thread Olaf Kock



On 24.03.2018 05:08, Shawn Heisey wrote:

This message is long.  Lots of details, a fair amount of history.

The primary Tomcat version we've got is 7.0.42. Specifically, it is 
the Tomcat that's included with Liferay 6.2. This is why we haven't 
attempted an upgrade even though the version we're running is five 
years old -- we don't want to rock the boat too hard and risk 
everything not working.  Liferay is battle-tested with that version of 
Tomcat.


other have answered on different pool implementations already, I'd like 
to comment on the mentioned Liferay heritage:


* Liferay comes (optionally) bundled with Tomcat to ease installation, 
however, the tomcat in there will be your own and is up to you to 
upgrade. Yes, new versions of Liferay will come with new versions of 
Tomcat, but new versions of Liferay won't be released because a new 
version of Tomcat is available. Running on an old Tomcat is your 
decision, not Liferay's. And the tomcat committers have done a great job 
providing drop-in-backwards-compatible newer versions. Of course, you'll 
need to validate, but the bundled version is no excuse to not upgrade Tomcat


* Liferay 6.2 (CE) is no longer maintained - there's no new tomcat 
version expected for it


* Liferay's default configuration (as configured through the setup 
wizard) configures the database with an internal connection, not using 
an appserver-configured pool. Please confirm that you manually 
configured Liferay for the appserver-provided pool.


* It might help looking at the pool/connection states through JMX, so 
that you can determine which pool is active on which size.


Olaf



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



  1   2   >