Update to 10.1.14 breaks our application

[Richard Cook]

Hi,

We have a spring boot application (v3.1.4) It currently uses


org.apache.tomcat
tomcat-jdbc
10.1.13


A renovate bot updated this package to 10.1.14 and now our app fails
on startup, with the following exception..

2023-10-11T22:27:16.981Z WARN 7 — [ main]
o.h.e.j.e.i.JdbcEnvironmentInitiator : HHH000342: Could not obtain
connection to query metadata
java.sql.SQLException: null
at 
org.apache.tomcat.jdbc.pool.ConnectionPool.setupConnection(ConnectionPool.java:351)
~[tomcat-jdbc-10.1.14.jar!/:na]
at 
org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:200)
~[tomcat-jdbc-10.1.14.jar!/:na]
at 
org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:133)
~[tomcat-jdbc-10.1.14.jar!/:na]
at 
org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.j




Caused by: java.lang.IllegalArgumentException:
org.apache.tomcat.jdbc.pool.PooledConnection is not an interface
at 
java.base/java.lang.reflect.Proxy$ProxyBuilder.validateProxyInterfaces(Proxy.java:706)
~[na:na]
at java.base/java.lang.reflect.Proxy$ProxyBuilder.(Proxy.java:648)
~[na:na]
at 
java.base/java.lang.reflect.Proxy.lambda$getProxyConstructor$1(Proxy.java:440)
~[na:na]
at 
java.base/jdk.internal.loader.AbstractClassLoaderValue$Memoizer.get(AbstractClassLoaderValue.java:329)
~[na:na]
at 
java.base/jdk.internal.loader.AbstractClassLoaderValue.computeIfAbsent(AbstractClassLoaderValue.java:205)
~[na:na]
at java.base/java.lang.reflect.Proxy.getProxyConstructor(Proxy.java:438)
~[na:na]
at java.base/java.lang.reflect.Proxy.getProxyClass(Proxy.java:398) ~[na:na]
at 
org.apache.tomcat.jdbc.pool.ConnectionPool.getProxyConstructor(ConnectionPool.java:377)
~[tomcat-jdbc-10.1.14.jar:na]
at 
org.apache.tomcat.jdbc.pool.ConnectionPool.setupConnection(ConnectionPool.java:339)
~[tomcat-jdbc-10.1.14.jar:na]


The code throws the exceptino when lef.afterPropertiesSet() is called.


@Bean(name = "fsEntityManagerFactory")
public EntityManagerFactory entityManagerFactory(DataSource fsDataSource) {
LocalContainerEntityManagerFactoryBean lef = new
LocalContainerEntityManagerFactoryBean();
HibernateJpaVendorAdapter vendorAdapter = new HibernateJpaVendorAdapter();
lef.setDataSource(fsDataSource);
lef.setJpaVendorAdapter(vendorAdapter);
lef.setPackagesToScan("xx");
lef.setPersistenceUnitName("fsPersistenceUnit");
HashMap properties = new HashMap<>();
properties.put("hibernate.dialect", "org.hibernate.dialect.DB2Dialect");
properties.put(AvailableSettings.ENHANCER_ENABLE_ASSOCIATION_MANAGEMENT,
"false");
properties.put(AvailableSettings.ENHANCER_ENABLE_DIRTY_TRACKING, "false");
properties.put(AvailableSettings.ENHANCER_ENABLE_LAZY_INITIALIZATION, "false");
properties.put("hibernate.jdbc.fetch_size", hibernateFetchSize);
properties.put("hibernate.show_sql", hibernateShowSQL);
properties.put("hibernate.default_schema", hibernateDefaultSchema);

lef.setJpaPropertyMap(properties);
lef.afterPropertiesSet();
return lef.getObject();
}


Right now I've reverted back to 10.1.13 and it works.

What is the best way to fix this?

I saw the release notes, updates were changed to the connection
pooling classes, but I'm unsure on how to proceed.

Thank you,

Rich
CONFIDENTIALITY NOTICE:
This is a transmission from Kohl's, Inc. and may contain information which is 
confidential and proprietary.
If you are not the addressee, any disclosure, copying or distribution or use of 
the contents of this message is expressly prohibited.
If you have received this transmission in error, please destroy it and notify 
us immediately at 262-703-7000.

CAUTION:
Internet and e-mail communications are Kohl's property and Kohl's reserves the 
right to retrieve and read any message created, sent and received. Kohl's 
reserves the right to monitor messages by authorized Kohl's Associates at any 
time without any further consent.

Installing Jenkins (WAR) on Tomcat - Corrupts SMTP / Email for Java Apps

[Decker, Richard]

Tomcat Users,

Sorry if this is a bit off base, but does anyone have experience with this 
unusual problem? As soon as I uninstall Jenkins (& restart tomcat), I can send 
java emails just fine through Tomcat. When I load the Jenkins war it breaks 
emails being sent immediately, by our other installed (custom) java apps in 
Tomcat. This server has been around for 6+ years, and the problem just starting 
occurring on Jan 24th of this year, without me knowing what changed. Looking at 
the smtp logs, it corrupts the mail before it leaves the system, before it hits 
the mail server. Replacing the original message with garbage like this example 
below:


--=_Part_3_1832428443.1648744184783--


Curiously when I deleted the 'work' dir under tomcat it temporarily solved the 
problem, allowing emails to be sent properly/correctly, but email eventually 
became corrupt again, just hours later, and deletion of the 'work' dir does 
nothing now (tried many times). I removed every mail related plugin in the 
.jenkins install dir, thinking the JVM was being corrupted with multiple java 
mail files, with no success/luck on the email send. Searched through the 
markmail archive, Jenkins forum, and google with nothing really matching the 
described issue.


Env: Oracle Linux 7.9
Tomcat: 8.5.72  (tried with 8.5.65, when I know it was working)
Java: jdk1.8.0_311  (tried with 281, when I know it was working)
Apr: 1.7.0
Apr-util: 1.6.1
Openssl: 1.1.1l
tomcat-native: 1.2.31-src
Jenkins: 2.332.1 LTS (tried several / various previous versions that I know 
worked)
Postfix: 2.10.1-9.el7.x86_64
Mail Jar: javax.mail-1.6.2.jar


V/R,

Re: ClassFileTransformer in Tomcat 10 common classloader

[Richard Huntrods]

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:




I have a similar situation. I run two sites on different servers. Today
I upgraded to TC 9.0.56 on both without incident. (I do the upgrades
manually from the tar.gz files).

However, in keeping up with where things are going, I also run a
development copy of the latest 10 (currently 10.0.14). Initially I ran
the offline converter, but as my main applications are still running in
production under 9.0.x, I don't really want to convert them from
javax.servlet to jakarta.servlet just yet.

My overall deployments are quite simple. I don't modify much on a stock
download of tomcat - just server.xml (to add HTTPS support for my certs)
and web.xml (to force HTTPS). Maybe 10 lines different in both files.

My libraries for the applications are now stored in webapps rather than
the common library area, but ALL my stuff still run javax.servlet.

I found that by adding the single line "  " after the  in the main
conf/context.xml file, everything auto-converts and runs perfectly.

Frankly, for my purposes, this has to be the simplest solution.

Cheers,

-R


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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

Re: users Digest 22 Jun 2020 10:06:54 -0000 Issue 13885

[Richard Huntrods]

Brian & Calder,

On 6/22/2020 3:06 AM, 
users-digest-h...@tomcat.apache.org<mailto:users-digest-h...@tomcat.apache.org> 
wrote:

On Mon, Jun 22, 2020, 01:04 Brian 
<mailto:brian...@emailbb.com> wrote

[ snip ]

- For some reason, the people at Ubuntu/Debian/Linux decided that Tomcat's


log should be found inside syslog, instead of staying independent inside
"catalina.out". Why is that? I don't know and I don't like it!


[ snip ]
.
Sorry - don't have a specific answer for your Ubuntu implementation.
.
However, this is one reason we do not use "distro-specific" Tomcat
installations (to include implementations of WebSphere and WebLogic).
.
For example, we grab the plain vanilla Tomcat ZIP and extract it to "/opt/"
(as in "/opt/tomcat/") - we now have complete control over its
configuration and runtime instantiation.

I agree completely. I started with Tomcat in 2000 on Sun Sparc servers running 
Solaris 8. Over the years I gradually updated to Solaris 10 on Sparc then Intel 
servers. Finally a couple of years ago I switched to Ubuntu (currently 
18.04LTS) for simplicity in engaging the community.

Because my development server was a windows/intel machine (now perma-set to 
Win7) I needed a generic way to operate Tomcat on any OS.

As mentioned above, I always grabbed the zip and/or the tar.gz and simply 
extracted the file to an appropriate working directory. For Ubuntu, I use 
/opt/tomcat as well. This allows me to keep things under my control, or at 
least know where everything is and that it will remain relatively constant. Any 
variations or changes are well documented in the Tomcat changelogs and 
assistance can be rendered by the community.

Likewise I try and keep my Tomcat current and my Java versions consistent with 
the current Tomcat. I've found that although the upgrade process can sometimes 
be painful, it is at least well documented.

Cheers,

-Richard




[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
  Virus-free. 
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

Re: learning tomcat 7 on Linux

[Richard Monson-Haefel]

I agree with Olaf.  My courses are for Tomcat 9. I would upgrade to 9. My
course shows you in detail how to install 9 on Linux (although I use
LinuxMint its all done with the bash shell so its should work just as as
well on CentOSO)

On Wed, Apr 8, 2020 at 11:50 AM Olaf Kock  wrote:

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

-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Re: learning tomcat 7 on Linux

[Richard Monson-Haefel]

Hi,

A bit of self-promotion here.

I just released a course, "Tomcat for Java Development" less than two weeks
ago which includes coverage of Tomcat on Linux. I'm also releasing - later
this week - a complementary course, "Java Application Development with
Tomcat". The first course teaches how to install, configure, troubleshoot,
and secure Tomcat. The second course focuses on the development of web
applications using servlets and JSPs on Tomcat.  Both are introductory
level courses but they are very current and I think pretty good. They are
also pretty short - less than 2 hours each.

You can find "Tomcat for Java Development" on Pluralsight.com today and
"Java Application Development with Tomcat" later in the week.

Good luck!

Richard


On Wed, Apr 8, 2020 at 7:56 AM Andy Sloane 
wrote:

> Hi,
> I have set up a Linux CentOS 7 host, and have installed Tomcat 7...
>
> [root@db3 ROOT]# /sbin/tomcat version
> Server version: Apache Tomcat/7.0.76
> Server built:   Mar 17 2020 23:48:55 UTC
> Server number:  7.0.76.0
> OS Name:Linux
> OS Version: 3.10.0-1062.12.1.el7.x86_64
> Architecture:   amd64
> JVM Version:1.8.0_242-b08
> JVM Vendor: Oracle Corporation
>
> I would like to learn how to develop webapps.
>
> This is just for a hobby - I'll never sell anything I write, and will never
> be a dev.  I currently work doing UNIXy stuff for a big US multinational.
> This is just a thing on the side, like learning to play guitar.   Can
> someone please suggest some resources?
>
> Many thanks.
>


-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Re: Re: Proposal: Note on web site that Tomcat 10 is a milestone-release

[Richard Huntrods]

On 3/4/2020 6:28 AM, Martin Grigorov wrote:

On Wed, Mar 4, 2020 at 4:02 PM Johan Compagner 
wrote:




Or for now generate 2 build artifacts? (as long as it is really just

the

package rename)


Hm, no. I just tested locally Tomcat 10.0.1 with Apache Wicket (9.x,
master). Nothing more.
Tomcat 10.0.x is not production ready so it is too early to do anything
about Jakarta APIs in Wicket.
First we need to release Wicket 9.0.0 (with Javax APIs) and then we can
start thinking about Jakarta APIs.



yes exactly, so many frameworks are going to do that (wait)
So not release any artifacts that use the new jakarta api's
So that means that for many people they can't start test or use Tomcat 10..
Because who is using plain servlet api only?
Any 3rd part dependency is your code  that uses some javax.servlet package
needs to make a special release..
This will take ages, not to mention will only be really done for the latest
releases of those packages (like Wicket 9)


There is no official release of Jakarta EE 9 yet!
I didn't even bother to replace javax.servlet:servlet-api Maven dependency
with the Jakarta one in Wicket.
I just used https://github.com/apache/tomcat-jakartaee-migration to migrate
(already built) wicket-examples.war and it worked fine!
Later I tried to do the same with a Spring Boot based application but the
migration tool faced some problems with the nested archives in Boot's
special packaging.

Tomcat 10.0.x is for early adopters to test it and report issues. But as
Chris suggested we should make this more clear in the docs!
I've committed some improvements. If anyone have more ideas for improvement
I'll be happy to apply them! :-)


Thank you for that Martin. I installed 10.0.x today, and as expected it
broke because all my servlets are based on javax. I grabbed a copy of
the migration tool. Sadly (for me) it required Maven to build, but after
some hesitency, I grabbed Maven and installed that (it was really easy).

With Maven installed and working, I built the migration tool. Again,
easy. With the tool built I simply converted both of my application's
war files, copied them over the originals in webapps, started TC 10 and
everything worked!

So I guess I'm "ready" for TC10 now. :-)

-R


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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

Re: Role/Path Based Access Valve?

[Richard Monson-Haefel]

Thanks, Chris.  As I said it was hypothetical but I appreciate the help!

On Tue, Mar 3, 2020 at 2:42 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 3/3/20 09:14, Richard Monson-Haefel wrote:
> > Thank you for your reply, Chris.
> >
> > I think I know where you are coming from when you say:
> >
> > "Why would you override the authorization decisions made by the
> > application developers?
> >
> > To be transparent: I'm a developer not an operations person nor do
> > I work for a large company so my use-case is hypothetical rather
> > than actual."
> >
> > But that assumes that you are running a dev-ops shop where the
> > developers also control all the operations and are responsible for
> >  cybersecurity. This scenario works fine in small companies where
> > dev-ops is the SOP, but in larger organizations, it's not really
> > feasible.  It's been my experience that IT departments separate
> > security responsibilities from development responsibilities. They
> > cooperate, but the security folks are the ultimate gatekeepers for
> > encryption, authentication, and authorization.  This is done for
> > the same reason that larger organizations - with big IT departments
> > - separate the role of managing the database from developers who
> > use it.
>
> So like slide 1 of this presentation?
>
> https://tomcat.apache.org/presentations.html#latest-locking-down-tomcat
>
> If the people responsible for security can't tell the developers to
> fix something in the application, then there are much bigger problems
> than the isolation of sec and dev.
>
> > If I'm ACME Bank and I have a slew of contractors working on an
> > application that will manage the client's finances I do not want
> > the contractors to decide what security privileges users should
> > have - that's the role of operations or management or if hosting
> > the client.
> This is what requirements-gathering exercises are all about. If you
> are a small devops shop, then it's all one thing. If you are a huge
> corporation, requirements-gathering is the world's most excruciating
> stage, because you can't do anything until ALL the requirements are
> laid out in insane detail. Security requirements go into this process.
>
> So I understand that sometimes, band-aids need to be put into place.
> But what you are asking for is a tourniquet. The band-aid is to
> hand-edit the web.xml file and fix the roles. Anything else should be
> so painful that you are forced to, ya know, TALK to your development tea
> m.
>
> - -chris
>
> > On Tue, Mar 3, 2020 at 7:51 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Richard,
> >
> > On 3/3/20 08:26, Richard Monson-Haefel wrote:
> >>>> Thank you, Mark.  I was actually aware of how to do it using
> >>>> the web.xml.
> >>>>
> >>>> I was looking for a valve that could do the same thing, and
> >>>> here is the reason:
> >>>>
> >>>> If I, as the Tomcat admin, want to manage access permissions
> >>>>  (authorization) I can use the /tomcat/conf/web.xml file.
> >>>> However, this file is overridden by matching elements in an
> >>>> individual WAR.
> >
> > This will never work. If conf/web.xml is even allowed to set
> >  (and I'm not sure either way), they would be
> >  relative to every web application and not relative to the server's
> >  root. IT would be very difficult to manage this in the way you
> > describe.
> >
> >>>> So If I say on the tomcat web.xml that only Bill and Ted have
> >>>>  access to path A, but an individual WAR's web.xml says that
> >>>>  Everyone has access to Path A, then the WAR web.xml wins,
> >>>> right?
> >
> > Yes. (Bogus!)
> >
> >>>> If I use a valve I can short-circuit the process before it
> >>>> even gets to the web application.  In that way, no matter
> >>>> what the developers put into the WAR I have multiple control
> >>>> from Tomcat. Make sense?
> >
> > That does makes sense, but please help us understand the use-case.
> > Why would you override the authorization decisions made by the
> > application's developers?
> >
> > I'm not sure if you can do this at the "Server level", but you can
> > use url-rewrite[1] to reject URLs based upon the logged-in user's
> > roles. Search the user's manual 

Re: Role/Path Based Access Valve?

[Richard Monson-Haefel]

Ok. That makes sense. Thanks again, Mark.

On Tue, Mar 3, 2020 at 8:18 AM Mark Thomas  wrote:

> On 03/03/2020 13:50, Christopher Schultz wrote:
> > Richard,
> >
> > On 3/3/20 08:26, Richard Monson-Haefel wrote:
> >> Thank you, Mark.  I was actually aware of how to do it using the
> >> web.xml.
> >
> >> I was looking for a valve that could do the same thing, and here is
> >> the reason:
> >
> >> If I, as the Tomcat admin, want to manage access permissions
> >> (authorization) I can use the /tomcat/conf/web.xml file. However,
> >> this file is overridden by matching elements in an individual WAR.
> >
> > This will never work. If conf/web.xml is even allowed to set
> >  (and I'm not sure either way), they would be
> > relative to every web application and not relative to the server's
> > root. IT would be very difficult to manage this in the way you describe.
>
> +1
>
> >> If I use a valve I can short-circuit the process before it even
> >> gets to the web application.  In that way, no matter what the
> >> developers put into the WAR I have multiple control from Tomcat.
> >> Make sense?
> >
> > That does makes sense, but please help us understand the use-case. Why
> > would you override the authorization decisions made by the
> > application's developers?
> >
> > I'm not sure if you can do this at the "Server level", but you can use
> > url-rewrite[1] to reject URLs based upon the logged-in user's roles.
> > Search the user's manual for "user-in-role".
>
> The real difficulty here is that you are fighting how Java EE (and now
> Jakarta EE) are architected / designed / intended to be used.
>
> The expectation is that security constraints are defined using roles in
> web.xml and then users are mapped to roles in the container.
>
> If is often the case the application defined roles don't map to the
> organisation roles in the authentication system. The fix for
> https://bz.apache.org/bugzilla/show_bug.cgi?id=55477 should help with
> that but that is still in discussion (it has been quiet for a while).
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Re: Role/Path Based Access Valve?

[Richard Monson-Haefel]

Thank you for your reply, Chris.

I think I know where you are coming from when you say:

 "Why would you override the authorization decisions made by the
application developers?

To be transparent: I'm a developer not an operations person nor do I work
for a large company so my use-case is hypothetical rather than actual."

But that assumes that you are running a dev-ops shop where the developers
also control all the operations and are responsible for cybersecurity. This
scenario works fine in small companies where dev-ops is the SOP, but in
larger organizations, it's not really feasible.  It's been my experience
that IT departments separate security responsibilities from development
responsibilities. They cooperate, but the security folks are the ultimate
gatekeepers for encryption, authentication, and authorization.  This is
done for the same reason that larger organizations - with big IT
departments - separate the role of managing the database from developers
who use it.

If I'm ACME Bank and I have a slew of contractors working on an application
that will manage the client's finances I do not want the contractors to
decide what security privileges users should have - that's the role of
operations or management or if hosting the client.

On Tue, Mar 3, 2020 at 7:51 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 3/3/20 08:26, Richard Monson-Haefel wrote:
> > Thank you, Mark.  I was actually aware of how to do it using the
> > web.xml.
> >
> > I was looking for a valve that could do the same thing, and here is
> > the reason:
> >
> > If I, as the Tomcat admin, want to manage access permissions
> > (authorization) I can use the /tomcat/conf/web.xml file. However,
> > this file is overridden by matching elements in an individual WAR.
>
> This will never work. If conf/web.xml is even allowed to set
>  (and I'm not sure either way), they would be
> relative to every web application and not relative to the server's
> root. IT would be very difficult to manage this in the way you describe.
>
> > So If I say on the tomcat web.xml that only Bill and Ted have
> > access to path A, but an individual WAR's web.xml says that
> > Everyone has access to Path A, then the WAR web.xml wins, right?
>
> Yes. (Bogus!)
>
> > If I use a valve I can short-circuit the process before it even
> > gets to the web application.  In that way, no matter what the
> > developers put into the WAR I have multiple control from Tomcat.
> > Make sense?
>
> That does makes sense, but please help us understand the use-case. Why
> would you override the authorization decisions made by the
> application's developers?
>
> I'm not sure if you can do this at the "Server level", but you can use
> url-rewrite[1] to reject URLs based upon the logged-in user's roles.
> Search the user's manual for "user-in-role".
>
> - -chris
>
> [1] https://tuckey.org/urlrewrite/
> > On Tue, Mar 3, 2020 at 7:04 AM Mark Thomas 
> > wrote:
> >
> >> On 03/03/2020 12:27, Richard Monson-Haefel wrote:
> >>> I've tried to find this but keep running into the three remote
> >>> address valves (address, IP, and CIDR) what I'm looking for is
> >>> an access valve
> >> that
> >>> uses roles from a realm that checks roles to either path or
> >>> web
> >> application
> >>> identifiers - not remote address.  This is classic
> >>> authorization - role-based authorization.
> >>
> >> Servlet specification, version 4, section 13.2 & 13.8 in
> >> particular.
> >>
> >> Mark
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5eYMEACgkQHPApP6U8
> pFgR0RAApNme6FTo3wJ6GuJekpo4jMDFdavXtRR4f0yBJiHMve2iSzN9FELaJMp6
> 4rPgD0gNPA6BR/Sd4RSxJ2NcQ2zYiaboprJs3ub04LbruHcgrvPrcR8i/ZT7zm3R
> TWvRQ47n2RkaVjvmdsZqGROQ6hSa6CHLgXSeWeDyBtjOnWNZIaXBdlpiyZlT8CAg
> AT6PI6sehpx15KHEoSVxpS0zbHeLrkyIQqzKmyufZS4PMkROCQQr8Qr/SAmrpb67
> zF6Ulwq5wxhy5Zrp/wh2rUuBBm5TJEENR1RbeSuYFKP2Fb8pViUeNrtE1PKsAlBf
> cYIL20+7H8Ib0aQgY9uCweIsKAHnOmmiZ2GHqKxarGjJ04iSz8P6IxyBMM1dAJJ9
> bbYOQ7hNFIerYtqlz2loEHmHcPJvEYCXVnHziWBDvPi39ajoc93TbmTcD7KHY8gC
> NBAnFhloeCGN97gF1fplXB/YOEW2u3p2jLdjHKXJk3tAu94sMAhR1wjALAogo8Va
> CVhO5B

Re: Role/Path Based Access Valve?

[Richard Monson-Haefel]

Thank you, Mark.  I was actually aware of how to do it using the web.xml.

I was looking for a valve that could do the same thing, and here is the
reason:

If I, as the Tomcat admin, want to manage access permissions
(authorization) I can use the /tomcat/conf/web.xml file. However, this file
is overridden by matching elements in an individual WAR.

So If I say on the tomcat web.xml that only Bill and Ted have access to
path A, but an individual WAR's web.xml says that Everyone has access to
Path A, then the WAR web.xml wins, right?

If I use a valve I can short-circuit the process before it even gets to the
web application.  In that way, no matter what the developers put into the
WAR I have multiple control from Tomcat.  Make sense?

On Tue, Mar 3, 2020 at 7:04 AM Mark Thomas  wrote:

> On 03/03/2020 12:27, Richard Monson-Haefel wrote:
> > I've tried to find this but keep running into the three remote address
> > valves (address, IP, and CIDR) what I'm looking for is an access valve
> that
> > uses roles from a realm that checks roles to either path or web
> application
> > identifiers - not remote address.  This is classic authorization -
> > role-based authorization.
>
> Servlet specification, version 4, section 13.2 & 13.8 in particular.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Role/Path Based Access Valve?

[Richard Monson-Haefel]

I've tried to find this but keep running into the three remote address
valves (address, IP, and CIDR) what I'm looking for is an access valve that
uses roles from a realm that checks roles to either path or web application
identifiers - not remote address.  This is classic authorization -
role-based authorization.

-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Re: this.getServletConfig() returns null

[Richard Monson-Haefel]

That worked! Thank you!

On Fri, Feb 14, 2020 at 1:10 PM Mark Thomas  wrote:

> On 14/02/2020 18:29, Richard Monson-Haefel wrote:
> > Hi,
> >
> > I'm experimenting with using annotations.  I created a Servlet with
> > annotations and then attempt to get the init parameters in the doGet()
> > method, but I keep getting a null value when I use
> > this.getServletConfig().  If I save the ServletConfig in an instance
> > variable from the init() method it works as expected.  Shouldn't the
> > this.getServletConfig() return the configuration object instead of a
> null?
> > What am I missing?
>
> You need to call super.init(confg)
>
> Mark
>
>
> >
> > Here is a listing. The code is also attached. I've run it both with and
> > without a web.xml file (just the root element when present).
> > @WebServlet(
> > name="myservlet",
> > urlPatterns={"/"},
> > initParams={
> > @WebInitParam(name="name", value="Richard"),
> > @WebInitParam(name="greeting", value="Hola")
> > }
> > )
> > public class TheServlet extends HttpServlet {
> >
> >   ServletConfig myConfig;
> >
> >   public void init(ServletConfig config) throws ServletException{
> >myConfig = config;
> >   }
> >
> > protected void doGet(HttpServletRequest request, HttpServletResponse
> > response) throws ServletException, IOException {
> >
> > // Set content type
> >   response.setContentType("text/plain");
> >
> >// Get initialization parameters
> >
> >//ServletConfig config = this.getServletConfig();
> >//^^  The above returns null 
> >
> >ServletConfig config = myConfig;
> >//^^^The above works 
> >
> >if(config != null){
> >   String name = config.getInitParameter("name");
> >   String greeting = config.getInitParameter("greeting");
> >   response.getWriter().println(greeting + " " +name);
> >}else{
> >   response.getWriter().println("there is no config");
> >}
> >   }
> > }
> >
> > Thanks in advance!
> >
> > Richard
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

this.getServletConfig() returns null

[Richard Monson-Haefel]

Hi,

I'm experimenting with using annotations.  I created a Servlet with
annotations and then attempt to get the init parameters in the doGet()
method, but I keep getting a null value when I use
this.getServletConfig().  If I save the ServletConfig in an instance
variable from the init() method it works as expected.  Shouldn't the
this.getServletConfig() return the configuration object instead of a null?
What am I missing?

Here is a listing. The code is also attached. I've run it both with and
without a web.xml file (just the root element when present).
@WebServlet(
name="myservlet",
urlPatterns={"/"},
initParams={
@WebInitParam(name="name", value="Richard"),
@WebInitParam(name="greeting", value="Hola")
}
)
public class TheServlet extends HttpServlet {

  ServletConfig myConfig;

  public void init(ServletConfig config) throws ServletException{
   myConfig = config;
  }

protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {

// Set content type
  response.setContentType("text/plain");

   // Get initialization parameters

   //ServletConfig config = this.getServletConfig();
   //^^  The above returns null 

   ServletConfig config = myConfig;
   //^^^The above works 

   if(config != null){
  String name = config.getInitParameter("name");
  String greeting = config.getInitParameter("greeting");
  response.getWriter().println(greeting + " " +name);
   }else{
      response.getWriter().println("there is no config");
   }
  }
}

Thanks in advance!

Richard
-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Re: Expression Language ${initParam.whatever} not working

[Richard Monson-Haefel]

Thanks, Mark. Your explanation was good but the code didn't do it.

On Mon, Feb 10, 2020 at 12:10 PM Mark Thomas  wrote:

> On 10/02/2020 18:03, Richard Monson-Haefel wrote:
> > Hi Simon,
> >
> > Thanks for the response but I don't think that is the issue. I can use
> the
> >  instead, but I want to use the initParam for the JSP page
> > which is named and mapped in the  element.  Perhaps I'm still
> > missing something.
>
> The EL implicit object initParam holds the *ServletConext*'s init
> params, not the Servlet's.
>
> You probably want something like (untested)
>
> ${ pageContext.servletConfig.initParameter("greeting_color") }
>
> Mark
>
>
> >
> > On Mon, Feb 10, 2020 at 12:00 PM Simon Funnell 
> > wrote:
> >
> >> In your web.xml you want:
> >>
> >> 
> >> greeting_color
> >> green
> >>   
> >>
> >> I think you have defined an initialization parameter for the servlet,
> not
> >> the context.
> >>
> >> On Mon, 10 Feb 2020 at 17:54, Richard Monson-Haefel <
> >> monsonhae...@gmail.com>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> Tomcat version: 9.0.30
> >>> Operating System: macOS 10.15.2
> >>>
> >>> While I can access my initParam vis a JSP scriptlet I cannot access the
> >>> same initial paramter EL expression.
> >>>
> >>> Here is the JSP code I'm using
> >>>
> >>> 
> >>>   
> >>> 
> >>>  >>> %>">Hello ${param.name} from
> hello.jsp
> >>>
> >>> 
> >>> color is ${initParam["greeting_color"]}
> >>>   
> >>> 
> >>>
> >>> Here is my web.xml declaring the initial parameters
> >>>
> >>> http://xmlns.jcp.org/xml/ns/javaee;
> >>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >>>   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
> >>>
> http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd
> >> "
> >>>   version="4.0"
> >>>   metadata-complete="true">
> >>>
> >>>
> >>>   
> >>>   
> >>>   HiJsp
> >>>   /hello.jsp
> >>>   
> >>>   greeting_color
> >>>   green
> >>>   
> >>>   
> >>>   
> >>>   HiJsp
> >>>   /hola/*
> >>>   
> >>> 
> >>>
> >>> Here is the output (source)
> >>>
> >>> 
> >>> 
> >>> 
> >>> Hello richard from
> >>> hello.jsp
> >>> 
> >>> color is
> >>> 
> >>> 
> >>>
> >>> I don't understand why the JSP expression <%= %> works but the EL
> >>> expression ${ } doesn't.  I've tried many variations and other EL
> >> implicit
> >>> objects I've tried worked fine.
> >>>
> >>> What am I missing?
> >>>
> >>> The WAR is attached for your convenience.
> >>>
> >>>
> >>>
> >>> --
> >>> Richard Monson-Haefel
> >>> https://twitter.com/rmonson
> >>> https://www.linkedin.com/in/monsonhaefel/
> >>>
> >>> -
> >>> 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
>
>

-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Re: Expression Language ${initParam.whatever} not working

[Richard Monson-Haefel]

Hi Simon,

Thanks for the response but I don't think that is the issue. I can use the
 instead, but I want to use the initParam for the JSP page
which is named and mapped in the  element.  Perhaps I'm still
missing something.

On Mon, Feb 10, 2020 at 12:00 PM Simon Funnell 
wrote:

> In your web.xml you want:
>
> 
> greeting_color
> green
>   
>
> I think you have defined an initialization parameter for the servlet, not
> the context.
>
> On Mon, 10 Feb 2020 at 17:54, Richard Monson-Haefel <
> monsonhae...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Tomcat version: 9.0.30
> > Operating System: macOS 10.15.2
> >
> > While I can access my initParam vis a JSP scriptlet I cannot access the
> > same initial paramter EL expression.
> >
> > Here is the JSP code I'm using
> >
> > 
> >   
> > 
> >  > %>">Hello ${param.name} from hello.jsp
> >
> > 
> > color is ${initParam["greeting_color"]}
> >   
> > 
> >
> > Here is my web.xml declaring the initial parameters
> >
> > http://xmlns.jcp.org/xml/ns/javaee;
> >   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
> >   http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd
> "
> >   version="4.0"
> >   metadata-complete="true">
> >
> >
> >   
> >   
> >   HiJsp
> >   /hello.jsp
> >   
> >   greeting_color
> >   green
> >   
> >   
> >   
> >   HiJsp
> >   /hola/*
> >   
> > 
> >
> > Here is the output (source)
> >
> > 
> > 
> > 
> > Hello richard from
> > hello.jsp
> > 
> > color is
> > 
> > 
> >
> > I don't understand why the JSP expression <%= %> works but the EL
> > expression ${ } doesn't.  I've tried many variations and other EL
> implicit
> > objects I've tried worked fine.
> >
> > What am I missing?
> >
> > The WAR is attached for your convenience.
> >
> >
> >
> > --
> > Richard Monson-Haefel
> > https://twitter.com/rmonson
> > https://www.linkedin.com/in/monsonhaefel/
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
>


-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

Expression Language ${initParam.whatever} not working

[Richard Monson-Haefel]

Hi,

Tomcat version: 9.0.30
Operating System: macOS 10.15.2

While I can access my initParam vis a JSP scriptlet I cannot access the
same initial paramter EL expression.

Here is the JSP code I'm using


  

">Hello ${param.name} from hello.jsp


color is ${initParam["greeting_color"]}
  


Here is my web.xml declaring the initial parameters

http://xmlns.jcp.org/xml/ns/javaee;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
  http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd;
  version="4.0"
  metadata-complete="true">


  
  
  HiJsp
  /hello.jsp
  
  greeting_color
  green
  
  
  
  HiJsp
  /hola/*
  


Here is the output (source)




Hello richard from hello.jsp


color is



I don't understand why the JSP expression <%= %> works but the EL
expression ${ } doesn't.  I've tried many variations and other EL implicit
objects I've tried worked fine.

What am I missing?

The WAR is attached for your convenience.



-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/

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

Re: Re: Database timeout

[Richard Huntrods]

On 7/27/2019 9:43 PM, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 7/25/19 21:44, Richard Huntrods wrote:
>> I'm having an ongoing issue with the database connections timing
>> out after a long period of inactivity (i.e. no-one connecting to
>> the tomcat applicaton).
>>
>> But first...
>>
>> My system: OS: Ubuntu 18.04.2 LTS (server) Tomcat: 9.0.22
>> (installed from tomcat distribution, not via apt get) Java: OpenJDK
>> "11.0.3" 2019-04-16 Mysql: Ver 14.14 Distrib 5.7.26
>>
>> I'm using the standard 8-hour timeout on mysql connections, and
>> have the set autoReconnect=true when I connect to the database:
>>
>> jdbc:mysql://127.0.0.1:3306/mydb?autoReconnect=true
>>
>> Everything works fine except for the 8-hour timeouts. If I click
>> the tomcat link again, the autoReconnect works and the applications
>> is back up instantly.
> This is the documented behavior of MySQL Connector/J: after a
> disconnect, it will fail the first subsequent connection usage and
> mark the connection as failed. Only after that will the connection
> become available the reconnect.
Yes, that is what I understand from reading the documents. I was just
hoping there might be another config item I missed.
>
>> The only message in any log is this:
>>
>>> SQL Problem: The last packet successfully received from the
>>> server was 30,394,076 milliseconds ago.  The last packet sent
>>> successfully to the server was 30,394,076 milliseconds ago. is
>>> longer than the server configured value of 'wait_timeout'. You
>>> should consider either expiring and/or testing connection
>>> validity before use in your application, increasing the server
>>> configured values for client timeouts, or using the Connector/J
>>> connection property 'autoReconnect=true' to avoid this problem.
>>> SQL State: 08S01 Vendor Error: 0
>> Is there a way other than using a longer timeout value to stop the
>> connection from breaking? That is, is there a pre-emptive form of
>> autoReconnect?
> You should be using a connection pool with a connection
> validation-check. If you enable those, you shouldn't even have the
> "SQL Problem" after a timeout.

 we do use a Java coded connection pool that's legacy code that I
have not had a chance to replace. It does work, except for the timeout.

The timeout itself is not unexpected. The client took a big hit in the
economic downturn and there is almost no activity on the application,
sometimes for weeks at a time.  Basically, with no-one using the system
it's behaving as one would expect.

It's just that when you do go to log on, it *always* seems to be down,
do to lack of activity. Click refresh and it's back up (again, as
expected). I'd just like to have it not go down.

>> Some other statistics: I have a 'watchdog' process (servlet + cron
>> job) that exercises the database on regular intervals. In spite of
>> that, I still get these SQL timeouts.
> Maybe it's not doing what you think it is.

Again, I suspect this is the case. I have no idea why that should be,
but when you remove all that's obvious, what is left must be suspected.

Looks like I will be digging into / rebuilding this code.

>
>> I've been tracking the timeouts since April 2019. All timeouts
>> exceed 8 hours. The minimum between timeouts was 9.3 hours, maximum
>> was 166.1 hours with an average since April 2019 of 35 hours.
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl09J/IACgkQHPApP6U8
> pFjjqA//ULfwUhS4r0NWVxIljVck9uUHKtzJW5Wk2fzCnjr0MQh3h4bNJSZj7Myt
> aFUWt3Cw+KmJ1zSOoAkDpDIvfvJsszCJhE5NP7DGi7iZMcA9Ln4JIpVEFpIbOj+J
> 9dV9+yHom60vLefwhl8v+Rh5PYsA6Sr87T6PXj8wkIrPvdr5LGnz+YzONFaCZKok
> R9YujGVoDiA3mI+FXX3V6BwyOw2w7zwJYJHRJ6kdB/bVjzcZ0DDsW1OOo5iifAeX
> IevbR7pa+K0GuCZrvzje/6MefI3Lm6giXFReMIU4PpwLL+oITM6ImbYuUJxA7Lqk
> kWb79SQAcw5MAlbeNXVuYL/1eGuyG1Vf5wkAZj4sf8XPMWeyWbstLOk6WN7Mwtm3
> 0ALPQgSs1Dhb8BUVOgCC4AtfvbBfE3/47dP6ZDumU8DNfV78SZdKcaaWvFSXobZu
> m0qk8raDdAhRxQ8FwJlzgZLWU7sqTjxw9D8F5mD9VPiTxD/IuVxGV9fOZDKN9vP4
> q69km58evlFew0KIkHQE7MCKhDL7+oQ9Q7i3/dJmxHXxwWLpZDLTAGWANes/ksD6
> GAsWkpFHejNu/cNJYOJ/B2Yl1FvPPqq1k0QBVQTYleJ+FXThOzJOyShd38tMdWgW
> bcy7ZeUgglI6B1VNlxp7ROQhA3fj5xOexL/sqi5kWICNiAsaQwU=
> =0TT3
> -END PGP SIGNATURE-
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contac

Re: Re: Database timeout

[Richard Huntrods]

On 7/27/2019 7:18 AM, Mark Thomas wrote:
> On 26/07/2019 02:44, Richard Huntrods wrote:
>> I'm having an ongoing issue with the database connections timing out
>> after a long period of inactivity (i.e. no-one connecting to the tomcat
>> applicaton).
>>
>> But first...
>>
>> My system:
>> OS: Ubuntu 18.04.2 LTS (server)
>> Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
>> Java: OpenJDK "11.0.3" 2019-04-16
>> Mysql: Ver 14.14 Distrib 5.7.26
>>
>> I'm using the standard 8-hour timeout on mysql connections, and have the
>> set autoReconnect=true when I connect to the database:
>>
>> jdbc:mysql://127.0.0.1:3306/mydb?autoReconnect=true
> Full configuration please.

The database is run entirely from within the servlets and supporting
Java code, no configuration at all in server.xml. Unfortunately it's a
legacy part of the system that I have not had the time to rewrite.

Basically the only change to the default server.xml is to add the 443
enabling block and point it to our certificates. I don't change anything
else from what is supplied as the standard tomcat 9.0.22 tar.gz file
aside from clearing out the default webapps directory.

I'll see what I can grab in the way of database configuration from the code.

>
> Mark
>
>
>> Everything works fine except for the 8-hour timeouts. If I click the
>> tomcat link again, the autoReconnect works and the applications is back
>> up instantly.
>>
>> The only message in any log is this:
>>
>>> SQL Problem: The last packet successfully received from the server was 
>>> 30,394,076 milliseconds ago.  The last packet sent successfully to the 
>>> server was 30,394,076 milliseconds ago. is longer than the server 
>>> configured value of 'wait_timeout'. You should consider either expiring 
>>> and/or testing connection validity before use in your application, 
>>> increasing the server configured values for client timeouts, or using the 
>>> Connector/J connection property 'autoReconnect=true' to avoid this problem.
>>> SQL State: 08S01
>>> Vendor Error: 0
>> Is there a way other than using a longer timeout value to stop the
>> connection from breaking? That is, is there a pre-emptive form of
>> autoReconnect?
>>
>> Some other statistics: I have a 'watchdog' process (servlet + cron job)
>> that exercises the database on regular intervals. In spite of that, I
>> still get these SQL timeouts.
>>
>> I've been tracking the timeouts since April 2019. All timeouts exceed 8
>> hours. The minimum between timeouts was 9.3 hours, maximum  was 166.1
>> hours with an average since April 2019 of 35 hours.
>>
>> Thanks in advance.
>>
>> -Richard
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> --
>> This communication is intended for the use of the recipient to whom it is 
>> addressed, and may contain confidential, personal, and or privileged 
>> information. Please contact us immediately if you are not the intended 
>> recipient of this communication, and do not copy, distribute, or take action 
>> relying on it. Any communications received in error, or subsequent reply, 
>> should be deleted or destroyed.
>> ---
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

Database timeout

[Richard Huntrods]

I'm having an ongoing issue with the database connections timing out
after a long period of inactivity (i.e. no-one connecting to the tomcat
applicaton).

But first...

My system:
OS: Ubuntu 18.04.2 LTS (server)
Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
Java: OpenJDK "11.0.3" 2019-04-16
Mysql: Ver 14.14 Distrib 5.7.26

I'm using the standard 8-hour timeout on mysql connections, and have the
set autoReconnect=true when I connect to the database:

jdbc:mysql://127.0.0.1:3306/mydb?autoReconnect=true

Everything works fine except for the 8-hour timeouts. If I click the
tomcat link again, the autoReconnect works and the applications is back
up instantly.

The only message in any log is this:

> SQL Problem: The last packet successfully received from the server was 
> 30,394,076 milliseconds ago.  The last packet sent successfully to the server 
> was 30,394,076 milliseconds ago. is longer than the server configured value 
> of 'wait_timeout'. You should consider either expiring and/or testing 
> connection validity before use in your application, increasing the server 
> configured values for client timeouts, or using the Connector/J connection 
> property 'autoReconnect=true' to avoid this problem.
> SQL State: 08S01
> Vendor Error: 0

Is there a way other than using a longer timeout value to stop the
connection from breaking? That is, is there a pre-emptive form of
autoReconnect?

Some other statistics: I have a 'watchdog' process (servlet + cron job)
that exercises the database on regular intervals. In spite of that, I
still get these SQL timeouts.

I've been tracking the timeouts since April 2019. All timeouts exceed 8
hours. The minimum between timeouts was 9.3 hours, maximum  was 166.1
hours with an average since April 2019 of 35 hours.

Thanks in advance.

-Richard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

Re: HTTP to HTTPS redirect not happening

[Richard Huntrods]

I apologise for top posting in advance, but just a quick update and
quicker question...

After Konstantin found my typo, I tried editing the global web.xml file
(/conf/web.xml) . In my case, this is actually the file I want based on
the behaviour described by Konstantin as this entire tomcat instance is
for this one application and it's static web pages, so *everything*
needs to have the redirect.

After fixing the typo, I tried it again and it works perfectly.

So now I have two ways to accomplish what I want:
1. Edit /conf/web.xml and add the lines.

2. Edit server.xml and add the RewriteValve line, then create
rewrite.config in /conf/Catalina/localhost.

So my question - which is considered "more elegant" or better, more
appropriate appoach - the valve or the change to web.xml?

I'm leaning towards the valve simply because I kind of like the whole
concept of valves, but if editing web.xml is just as good... ?

Thanks,

-Richard


On 7/20/2019 2:08 PM, Richard Huntrods wrote:
> Sorry for top-posting. It's the default with my mail program
> (thunderbird)...
>
> On 7/20/2019 11:27 AM, Konstantin Kolinko wrote:
>> сб, 20 июл. 2019 г. в 17:47, Richard Huntrods :
>>> OK. That was really weird.
>>>
>>> As I said in my message, following the directions on the web did NOT
>>> work. It didn't force redirection from http to https.
>>>
>>> What it DID end up doing was to kill the tomcat servlet application.
>>> Before the change it was working fine, and after the change it would
>>> only generate a 404 page.
>>>
>>> I reverted to the original /conf/web.xml, restarted tomcat and the
>>> servlet application is back up and running perfectly.
>>>
>>> So this code in /conf/web.xml affected the servlet but not the ROOT
>>> static web pages.
>> 1. The web.xml file and its behavior are defined in the Servlet
>> Specification.
>>
>> Some random instructions on the net have to be used carefully.
>>
>> 2. The web.xml file is the one in your web application
>> (WEB-INF/web.xml).
>>
>> The /conf/web.xml file provides defaults for all web applications, and
>> SHOULD not be edited. (The /conf/context.xml should not be exited as
>> well. That is another frequent error.).
>>
>> Those defaults are merged with the web.xml file of your web
>> application using merging rules defined in the Servlet Specification.
>>
>> There is an option, "logEffectiveWebXml" [1] that turns on logging of
>> the merged web.xml file.
> I still am having trouble understanding why the web application's
> WEB-INF/web.xml would be the appropriate place to put the change when
> I want to affect ROOT. I would have thought
> webapps/ROOT/WEB-INF/web.xml would have been the correct one.
>>
>> 3. Beware of typos.
>>
>> The tag "" is misspelled.
>
> AARRR
>
> TYPOS
>
> And I checked that code several times before implementing it. Of
> course it wouldn't work 'as designed'. Ouch.
>
> I can clearly see why 'fixing stuff' using that code would generate
> the 404 errors I was seeing. That does prove I was editing the correct
> web.xml files, at least. Since the typo was in the block that then
> defined the url-pattern, messing that up would mess up everything.
>
> One person asked what the logs said. Nothing. Start up log was normal,
> access log was normal.
>
>>
>> There is an option, "xmlValidation" [1] that turns on automatic
>> validation of web.xml against the XML schema specified in that file.
>>
>> (Personally, I usually run with
>> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
>> and that turns "xmlValidation" on as well).
>>
>> 4. Top-posting is bad.
>
> Again, sorry. In the end I solved it using a Rewritevalve instead of
> web.xml, and I think that may be the more elegant solution. Certainly
> it's cleaner - edit server.xml and add one file, rewrite.config. That
> takes care of everywhere; both the static pages I started wanting to
> fix, and also the servlet application which I discovered could be
> forced to run http when I was testing. This fixes all.
>
> One last point. I started this particular application for a client
> back in early 2001. At that time I was considered a maverick for
> choosing open source (Tomcat, MySQL) over the then-ubiquitous
> proprietary solutions "everyone" was using. I even got to speak at
> Unix user groups at the time, and even spoke at a CIPS meeting in
> August 2001 (Montreal, PQ, Canada) on the use of open source for
> enterprise solutions.
>
> Mostly folks simply didn't want to believe it could be done.
>
> Fa

Re: Re: HTTP to HTTPS redirect not happening

[Richard Huntrods]

Sorry for top-posting. It's the default with my mail program
(thunderbird)...

On 7/20/2019 11:27 AM, Konstantin Kolinko wrote:
> сб, 20 июл. 2019 г. в 17:47, Richard Huntrods :
>> OK. That was really weird.
>>
>> As I said in my message, following the directions on the web did NOT
>> work. It didn't force redirection from http to https.
>>
>> What it DID end up doing was to kill the tomcat servlet application.
>> Before the change it was working fine, and after the change it would
>> only generate a 404 page.
>>
>> I reverted to the original /conf/web.xml, restarted tomcat and the
>> servlet application is back up and running perfectly.
>>
>> So this code in /conf/web.xml affected the servlet but not the ROOT
>> static web pages.
> 1. The web.xml file and its behavior are defined in the Servlet Specification.
>
> Some random instructions on the net have to be used carefully.
>
> 2. The web.xml file is the one in your web application (WEB-INF/web.xml).
>
> The /conf/web.xml file provides defaults for all web applications, and
> SHOULD not be edited. (The /conf/context.xml should not be exited as
> well. That is another frequent error.).
>
> Those defaults are merged with the web.xml file of your web
> application using merging rules defined in the Servlet Specification.
>
> There is an option, "logEffectiveWebXml" [1] that turns on logging of
> the merged web.xml file.
I still am having trouble understanding why the web application's
WEB-INF/web.xml would be the appropriate place to put the change when I
want to affect ROOT. I would have thought webapps/ROOT/WEB-INF/web.xml
would have been the correct one.
>
> 3. Beware of typos.
>
> The tag "" is misspelled.

AARRR

TYPOS

And I checked that code several times before implementing it. Of course
it wouldn't work 'as designed'. Ouch.

I can clearly see why 'fixing stuff' using that code would generate the
404 errors I was seeing. That does prove I was editing the correct
web.xml files, at least. Since the typo was in the block that then
defined the url-pattern, messing that up would mess up everything.

One person asked what the logs said. Nothing. Start up log was normal,
access log was normal.

>
> There is an option, "xmlValidation" [1] that turns on automatic
> validation of web.xml against the XML schema specified in that file.
>
> (Personally, I usually run with
> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
> and that turns "xmlValidation" on as well).
>
> 4. Top-posting is bad.

Again, sorry. In the end I solved it using a Rewritevalve instead of
web.xml, and I think that may be the more elegant solution. Certainly
it's cleaner - edit server.xml and add one file, rewrite.config. That
takes care of everywhere; both the static pages I started wanting to
fix, and also the servlet application which I discovered could be forced
to run http when I was testing. This fixes all.

One last point. I started this particular application for a client back
in early 2001. At that time I was considered a maverick for choosing
open source (Tomcat, MySQL) over the then-ubiquitous proprietary
solutions "everyone" was using. I even got to speak at Unix user groups
at the time, and even spoke at a CIPS meeting in August 2001 (Montreal,
PQ, Canada) on the use of open source for enterprise solutions.

Mostly folks simply didn't want to believe it could be done.

Fast forward to 2019, when Tomcat & Mysql/MariaDB are now often the
ubiquitous choices, with proprietary solutions are used mostly where
upper management has bought the FUD.

A lot has changed in Tomcat in that time; in Unix as well. I started
with Solaris 8, then Solaris 10, and more recently Ubuntu. I love the
way things have gotten better.

More than that, I try to "keep up" with changes in security and overall
robustness and best practices. I did just update from Tomcat 8.5.41 to
9.0.22 on Wednesday. It went without a hitch and took about 30 minutes
total, including testing on the devel server. Basically it was easy
because I try and keep things up to date.

But... there are still places where legacy code lives in the
application. Sadly, I'm one developer and it was a pretty big system. I
tend to be proactive, but only if I think the benefit can really justify
the time spent figuring it all out.

Cheers,

-Richard

> [1] http://tomcat.apache.org/tomcat-9.0-doc/config/context.html
>
> Best regards,
> Konstantin Kolinko
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
infor

Re: Re: HTTP to HTTPS redirect not happening

[Richard Huntrods]

Thanks. However, what I don't understand is why putting that code into the 
webapps WEB-INF/web.xml would cause the behaviour I want in ROOT.

Sadly, this is a production server and I can't play with it except after hours.

EDIT. I tried working with web.xml on my development server, and could not get 
it to work, no matter which web.xml I used. In fact, whenever I edited the 
'correct' web.xml, I immediately started getting '404' errors. If I removed the 
changes and restarted, the errors went away.

So I tried something different after re-checking the internet. My original info 
came from here:
https://gist.github.com/jtgasper3/10501274

after typing "force tomcat http to https" the above link was one, and the one 
I'd used to originally edit tomcat/conf/web.xml.

The following bit caught my eye:
albertus82 commented on Oct 31, 2018
Some applications don't work correctly with that security-constraint, so I 
followed a completely different approach:
Edit conf/server.xml and add the following element into :

Create the file conf/Catalina/localhost/rewrite.config:
RewriteCond %{HTTPS} =off
RewriteRule ^(.*) https://%{HTTP_HOST}:443$1 [R=301]

I tried that on localhost (devel box) and it didn't work at first, but only 
because I did not have port 80 'turned on' on that machine. Once I did that it 
worked.

I then implemented the above 'fix' in the production conf/server.xml and 
conf/Catalina/localhost and after restarting tomcat, ALL PAGES redirect from  
http to https as I had wanted. I even put the web pages back to just using 
index.html (moral: always make backups before you start doing stuff!).

On reflection, I do think the valve was the more appropriate way to tackle this 
problem, so I'm very happy with the solution.

-R

On 7/20/2019 3:48 AM, logo wrote:

Richard,



Am 20.07.2019 um 04:19 schrieb Richard Huntrods 
<mailto:huntr...@athabascau.ca>:

I tried implementing automatic redirection from HTTP to HTTPS on my
tomcat today, but it's not working.

First, my system:
OS: Ubuntu 18.04.2 LTS (server)
Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
Java: OpenJDK "11.0.3" 2019-04-16
Mysql: Ver 14.14 Distrib 5.7.26

This web application has it's own domain (let's call it "mydomain.com" )
and has working HTTPS - and has done  for some time now.

Static web pages are served on this application via tomcat using the
ROOT directory ../tomcat/webapps/ROOT

Again, this is working just fine. If I type 
"https://mydomain.com;<https://mydomain.com> I see
the secure static pages. If I type "http://mydomain.com;<http://mydomain.com> I 
see the same
pages, but browsers inform me the page isn't secure.

I want to force tomcat to redirect "http://mydomain.com;<http://mydomain.com> to
"https://mydomain.com;<https://mydomain.com> always.

I found instructions for auto-redirection on several on-line sites, and
all had the same instructions.

I already have the redirect code in server.xml:

  

So all I had to add (according to the instructions) was code at the end
of ...tomcat/conf/web.xml



Secured
/*


CONFIDENTIAL



just before the final 


This should go into your webapp's WEB-INF/web.xml! Not the tomcat/conf!

Hope this helps,

Peter



I did this and restarted tomcat. It doesn't work.

After restarting tomcat, if I type in 
"http://mydomain.com;<http://mydomain.com> I still see
the unsecured version. It does not auto-redirect to https.

What am I missing?

Thanks,
-Richard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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



[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
  Virus-free. 
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recip

Re: HTTP to HTTPS redirect not happening

[Richard Huntrods]

Fixed it by brute force.

First, I tried putting the changes ONLY in
../tomcat/webapps/ROOT/WEB-INF/web.xml instead of ../tomcat/conf/web.xml

The good news is that didn't affect the servlet application. The bad
news is now the http://mydomain.com/ started getting the 404 error. So I
undid that and the error went away.

That led me to the brute force approach.

The application (servlets on tomcat) has a large set of static web pages
that are used as promotional material for the application. In the early
days this was on a different apache server, but over the years (and due
to colocation costs) migrated to the ROOT directory of tomcat. It's
always worked just fine, so why mess with stuff that's working and not
'wrong'.

There are about a dozen html pages and lots of other files, but only the
dozen html pages matter. They all have a single link (via tabbed menu)
to "index.html". It was not difficult to rename index.html to be
home.html and change all the links (took all of 10 min total). I then
created a new index.html with the single key line in :

 https://mydomain.com/home.html;>

This line I've used before in other java servlet/tomcat applications
when I really want http://mydomain.com to automatically redirect to the
servlet application (I change home.html to the servlet URL). It works.

After making this change - and I didn't even have to restart tomcat - it
now works perfectly.

Eventually I'll figure out what I did wrong trying to use web.xml to do
the above auto-redirection, but this works and is simple.

-R

On 7/20/2019 7:47 AM, Richard Huntrods wrote:
> OK. That was really weird.
>
> As I said in my message, following the directions on the web did NOT
> work. It didn't force redirection from http to https.
>
> What it DID end up doing was to kill the tomcat servlet application.
> Before the change it was working fine, and after the change it would
> only generate a 404 page.
>
> I reverted to the original /conf/web.xml, restarted tomcat and the
> servlet application is back up and running perfectly.
>
> So this code in /conf/web.xml affected the servlet but not the ROOT
> static web pages.
>
> I'm thinking I need to make the change I noted, but in ROOT/web.xml
> instead. I'll try that today. But it was weird that the change in
> /conf/web.xml killed the servlet but didn't affect the ROOT static
> pages at all. Especially weird  since the servlet application ONLY
> runs on port 443 (https).
>
> -R
>
> On 7/19/2019 7:18 PM, Richard Huntrods wrote:
>> I tried implementing automatic redirection from HTTP to HTTPS on my
>> tomcat today, but it's not working.
>>
>> First, my system:
>> OS: Ubuntu 18.04.2 LTS (server)
>> Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
>> Java: OpenJDK "11.0.3" 2019-04-16
>> Mysql: Ver 14.14 Distrib 5.7.26
>>
>> This web application has it's own domain (let's call it
>> "mydomain.com" ) and has working HTTPS - and has done  for some time
>> now.
>>
>> Static web pages are served on this application via tomcat using the
>> ROOT directory ../tomcat/webapps/ROOT
>>
>> Again, this is working just fine. If I type "https://mydomain.com; I
>> see the secure static pages. If I type "http://mydomain.com; I see
>> the same pages, but browsers inform me the page isn't secure.
>>
>> I want to force tomcat to redirect "http://mydomain.com; to
>> "https://mydomain.com; always.
>>
>> I found instructions for auto-redirection on several on-line sites,
>> and all had the same instructions.
>>
>> I already have the redirect code in server.xml:
>>
>>   >connectionTimeout="2"
>>redirectPort="443" />
>>
>> So all I had to add (according to the instructions) was code at the
>> end of ...tomcat/conf/web.xml
>>
>> 
>>     
>> Secured
>> /*
>> 
>> 
>> CONFIDENTIAL
>> 
>> 
>>
>> just before the final 
>>
>> I did this and restarted tomcat. It doesn't work.
>>
>> After restarting tomcat, if I type in "http://mydomain.com; I still
>> see the unsecured version. It does not auto-redirect to https.
>>
>> What am I missing?
>>
>> Thanks,
>> -Richard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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

Re: HTTP to HTTPS redirect not happening

[Richard Huntrods]

OK. That was really weird.

As I said in my message, following the directions on the web did NOT
work. It didn't force redirection from http to https.

What it DID end up doing was to kill the tomcat servlet application.
Before the change it was working fine, and after the change it would
only generate a 404 page.

I reverted to the original /conf/web.xml, restarted tomcat and the
servlet application is back up and running perfectly.

So this code in /conf/web.xml affected the servlet but not the ROOT
static web pages.

I'm thinking I need to make the change I noted, but in ROOT/web.xml
instead. I'll try that today. But it was weird that the change in
/conf/web.xml killed the servlet but didn't affect the ROOT static pages
at all. Especially weird  since the servlet application ONLY runs on
port 443 (https).

-R

On 7/19/2019 7:18 PM, Richard Huntrods wrote:
> I tried implementing automatic redirection from HTTP to HTTPS on my
> tomcat today, but it's not working.
>
> First, my system:
> OS: Ubuntu 18.04.2 LTS (server)
> Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
> Java: OpenJDK "11.0.3" 2019-04-16
> Mysql: Ver 14.14 Distrib 5.7.26
>
> This web application has it's own domain (let's call it "mydomain.com"
> ) and has working HTTPS - and has done  for some time now.
>
> Static web pages are served on this application via tomcat using the
> ROOT directory ../tomcat/webapps/ROOT
>
> Again, this is working just fine. If I type "https://mydomain.com; I
> see the secure static pages. If I type "http://mydomain.com; I see the
> same pages, but browsers inform me the page isn't secure.
>
> I want to force tomcat to redirect "http://mydomain.com; to
> "https://mydomain.com; always.
>
> I found instructions for auto-redirection on several on-line sites,
> and all had the same instructions.
>
> I already have the redirect code in server.xml:
>
>   connectionTimeout="2"
>redirectPort="443" />
>
> So all I had to add (according to the instructions) was code at the
> end of ...tomcat/conf/web.xml
>
> 
> 
> Secured
> /*
> 
> 
> CONFIDENTIAL
> 
> 
>
> just before the final 
>
> I did this and restarted tomcat. It doesn't work.
>
> After restarting tomcat, if I type in "http://mydomain.com; I still
> see the unsecured version. It does not auto-redirect to https.
>
> What am I missing?
>
> Thanks,
> -Richard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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

HTTP to HTTPS redirect not happening

[Richard Huntrods]

I tried implementing automatic redirection from HTTP to HTTPS on my
tomcat today, but it's not working.

First, my system:
OS: Ubuntu 18.04.2 LTS (server)
Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
Java: OpenJDK "11.0.3" 2019-04-16
Mysql: Ver 14.14 Distrib 5.7.26

This web application has it's own domain (let's call it "mydomain.com" )
and has working HTTPS - and has done  for some time now.

Static web pages are served on this application via tomcat using the
ROOT directory ../tomcat/webapps/ROOT

Again, this is working just fine. If I type "https://mydomain.com; I see
the secure static pages. If I type "http://mydomain.com; I see the same
pages, but browsers inform me the page isn't secure.

I want to force tomcat to redirect "http://mydomain.com; to
"https://mydomain.com; always.

I found instructions for auto-redirection on several on-line sites, and
all had the same instructions.

I already have the redirect code in server.xml:

   

So all I had to add (according to the instructions) was code at the end
of ...tomcat/conf/web.xml

 
 
 Secured
 /*
 
 
 CONFIDENTIAL
 
 

just before the final 

I did this and restarted tomcat. It doesn't work.

After restarting tomcat, if I type in "http://mydomain.com; I still see
the unsecured version. It does not auto-redirect to https.

What am I missing?

Thanks,
-Richard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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

Re: tomcat 7.0.90 ubuntu web-security.xml doesn't work.

[richard coleman]

Chris,

Thanks for responding.  I got that from the web.xml file itself;

> 


The only references I can find (including the archives of this list) are
copies of web.xml with those same instructions.  Creating a block that
adheres to that DTD and placing it in the bottom of web.xml (before the
last  tag) works as expected.

The web.xml file is dynamically generated and so I am left with having to
remember to update the tomcat7/webapps//WEB-INF/web.xml by hand *after* it
is finished deploying from the .war file.  If I could place it in a
separate static web-security.xml file than it can be packaged in the .war
file and automatically applied whenever the application is deployed.

Thanks again for your help,

rik.

On Fri, Jul 19, 2019 at 2:44 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 7/19/19 11:33, richard coleman wrote:
> > Hi all,
> >
> > Running tomcat 7.0.90, I am trying to add a security block to a
> > struts 1 application to redirect *most* urls to https.  It works
> > fine when I add it to the web.xml file in the
> > webapps//WEB-INF/web.xml file.
> >
> > That file states that I should be able to add it to a separate
> > web-security.xml file, but when I do so, tomcat *ignores* the
> > web-security.xml file.
> >
> > Is there something that's *not* mentioned that I am forgetting to
> > do to actually get this to work?
>
> I think you are asking the wrong mailing list. If you are using Struts
> for the redirection, then you want to ask the Struts folks why it's
> not working. You might want to provide en example of your
> configuration when doing so if you post over there.
>
> You might get crickets in response since you are asking about a
> product that was abandoned years ago. I feel your pain; I still use
> Struts 1.x myself. :(
>
> I've never heard of web-security.xml. Ever.
>
> What is it you are trying to configure in web-security.xml that works
> when you put it into web.xml? Why not just put it into web.xml if
> that's where it works?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0yD6MACgkQHPApP6U8
> pFjuIg/+ND6tguQw6z579Tabcc3movui80Zdva4EEyMzzCaJl0kkvF8wqVdEzErG
> uCOni0gwo3VflY5cdOM8cdAjcoR2iue3LrWOKQKEtuKpTuv6bGPO/HjGUBtKzMnd
> 0tBzohjEofy7IlS3+PhIVczdzKuU44s+SWUojYkQrtGSh2sgjkCfFC2IRisxoAWU
> YF29FARLbimkHDTlhjr0SqeUf5z5rt7l5y7IC8kzA2ipEJQaARfu+x/cQSlivPYd
> vrgOChrNFrqAhBHX5R+5KosL2nGPGT2cWodiVuC567Kyt5+vzp2PNLBKLwS3tT7T
> iOFGjZ3Z3AmctVebWFPEILuyoX9tqz0uZJjjkkeiLHl4d4RkvRAQOqjOyi0TyvNx
> bSenOp0YMp6Sq++lvDSmN3fx1VzoTMbfA4yacCFGLaflzJADO15kVRV/PM8aPAl6
> KPv16DrhGzxMCGVMoccQNxCYl1T0QyJfFJT+ocJVQ9ZRF1ZVd7rylq7RZwocnTh7
> tQptLst5e+SC3mcVvOhU/RLYXdqbstgaM93x8tvYv2jmtV7qmFyTDc/PGxYMr4Nh
> LfvVtyZG0Yq3672FwLgjIsbxMi91fkvGMJbXYkCUJXjvXNl+q8FwrzOJo/aGiXfY
> o0YExXDpKPRVMeEx36UXWjCu+JbFu6SBiX9zBkqt0k1NoC1jplU=
> =3GI8
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

tomcat 7.0.90 ubuntu web-security.xml doesn't work.

[richard coleman]

Hi all,

Running tomcat 7.0.90, I am trying to add a security block to a struts 1
application to redirect *most* urls to https.  It works fine when I add it
to the web.xml file in the webapps//WEB-INF/web.xml file.

That file states that I should be able to add it to a separate
web-security.xml file, but when I do so, tomcat *ignores* the
web-security.xml file.

Is there something that's *not* mentioned that I am forgetting to do to
actually get this to work?

Thanks,

rik.

Connector difference explanation request - two ways of getting SSL in server.xml

[Richard Huntrods]

Apologies if this is really basic, but I've seen two ways of handling
https (SSL) for tomcat and don't understand the differences.

The first example uses letsencrypt cert files 'in situ' (i.e. where they
have been created). The second example uses the same files, but
converted by a manual shell script into a single .keystore file, stored
in ./tomcat/keys

The thing I really don't understand is the different protocols used.

Fair warning: the second example is something I've been using for a
while, so it may be out of fashion even though it works. The first
example is "brand new" that I got online and want to use mainly because
it removes the manual conversion step from cert to .keystore.


   
 
   


vs.



My system:
OS: Ubuntu 18.04.2 LTS (server)
Tomcat: 8.5.41 (installed from tomcat distribution, not via apt get)
Java: OpenJDK "11.0.3" 2019-04-16

Everything works fine. I'm mostly just curious about the other
differences between the two connectors.

Thanks in advance.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

Re: Cannot receive email from tomcat.apache.org

[Richard Huntrods]

I have confirmed with my email provider that tomcat.apache.org does 
indeed have nucleus.com on a blacklist. I can provide proof if needed, 
but I do need to get nucleus.com REMOVED from this blacklist.


Thank you.

-Richard

On 4/23/2019 9:14 AM, Richard Huntrods wrote:
I'm still not receiving any email from either 
'users@tomcat.apache.org' or 'users-dig...@tomcat.apache.org' - not 
since the tomcat listserv server crash in early April.


I asked my mail server provider to check their logs, and this is the 
reply I received yesterday:



Hello Richard,

I received a response from our email admin team this morning 
regarding your inquiry:

There were no emails sent from users@tomcat.apache.org or
users-dig...@tomcat.apache.org to our system between April 15 and 
April 18th.
There was an email sent from huntr...@nucleus.com to 
users@tomcat.apache.org on

Apr 17 14:28:59 EST.

You may want to inquire with the people distributing this digest if 
they can send you a test message to determine what might be causing 
the non-delivery issue, as we are not even seeing it coming into our 
server at this time. 


This seems odd as I know I saw messages on the archive from that time 
- so I should have received at least the digest.


Since my provider is of little help, I have two questions for the 
tomcat.apache.org mailing list admins:


1. Is the digest still being emailed on a regular basis? I never was 
subscribed to 'users', only to 'users-digest'.


2. Could you check and see whether or not tomcat.apache.org has 
"blacklisted" the server 'nucleus.com'? This happened to me once 
before - a site blacklisted nucleus "because it looked suspicious". 
Nucleus.com is a Calgary Alberta Canada internet provider that has 
been in business since before 2000 (I've been a customer since early 
2001) and is most certainly not 'suspicious'. They host many of the 
larger Calgary business accounts as well as consumer accounts. Their 
email servers are robust and secure.


But - it could be the listserv my not recognize nucleus.com and 
therefore won't email to it.


3. Is there any way to reply directly to me at this email address from 
a 'tomcat.apache.org' mail address so we could test this?


Thanks,

-Richard



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: Cannot receive email from tomcat.apache.org

[Richard Huntrods]

I'm still not receiving any email from either 'users@tomcat.apache.org' 
or 'users-dig...@tomcat.apache.org' - not since the tomcat listserv 
server crash in early April.


I asked my mail server provider to check their logs, and this is the 
reply I received yesterday:



Hello Richard,

I received a response from our email admin team this morning regarding 
your inquiry:

There were no emails sent from users@tomcat.apache.org or
users-dig...@tomcat.apache.org to our system between April 15 and 
April 18th.
There was an email sent from huntr...@nucleus.com to 
users@tomcat.apache.org on

Apr 17 14:28:59 EST.

You may want to inquire with the people distributing this digest if 
they can send you a test message to determine what might be causing 
the non-delivery issue, as we are not even seeing it coming into our 
server at this time. 


This seems odd as I know I saw messages on the archive from that time - 
so I should have received at least the digest.


Since my provider is of little help, I have two questions for the 
tomcat.apache.org mailing list admins:


1. Is the digest still being emailed on a regular basis? I never was 
subscribed to 'users', only to 'users-digest'.


2. Could you check and see whether or not tomcat.apache.org has 
"blacklisted" the server 'nucleus.com'? This happened to me once before 
- a site blacklisted nucleus "because it looked suspicious". Nucleus.com 
is a Calgary Alberta Canada internet provider that has been in business 
since before 2000 (I've been a customer since early 2001) and is most 
certainly not 'suspicious'. They host many of the larger Calgary 
business accounts as well as consumer accounts. Their email servers are 
robust and secure.


But - it could be the listserv my not recognize nucleus.com and 
therefore won't email to it.


3. Is there any way to reply directly to me at this email address from a 
'tomcat.apache.org' mail address so we could test this?


Thanks,

-Richard


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [NUCLEUS #813966] Urgent: Problem receiving email

[Richard Huntrods]

there are two email addresses that send the emails to me.

Tomcat Users List 

and Tomcat Digest 

I used to get only the digest, but this week even emails from 'users' 
are not coming through at all.


Cheers,

-Richard

On 4/18/2019 5:42 PM, Nigel Koppert via RT wrote:

Hi Richard,

Unfortunately there's not much we can tell from the message you 
provided for examination, as it appears all of sender/receiver 
information is only referencing the apache server that is hosting 
their mail accounts; there are no references to huntr...@nucleus.com.
Could you please provide us with the mail address that sends these 
digests to huntr...@nucleus.com? Once I have that information I can 
put an inquiry in with our mail admins.
  


--
Nigel Koppert
Support Analyst
Nucleus Information Service

Phone: (403) 509-4960
Toll Free: (888) 466-6336

On 2019-04-18 19:59:21, huntr...@nucleus.com wrote:

Greetings!

Could you please look at the mail server that supports the above email
address (huntr...@nucleus.com)?

Last week I stopped receiving emails from the tomcat forum. They had a
server outage and changed servers, and ever since I have not received a
single email from the list or the digest.

I've been able to send emails to them, and received word (via the digest
archive using a browser) that they have been sending me emails as
recently as yesterday.

Attached is an email from yesterday that I did not receive. I've
obtained it from the archive in 'raw' form so you can inspect the
headers and try and find out why I am not receiving these emails.

I should also note I've checked the spam, junk and other folders on this
email account and there is nothing there.

Thanks,

-Richard




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Is there a problem with the digest?

[Richard Huntrods]

ROkdh
  ZmMZtFlsQeQJsWoqGrQo/kEYicVlMVOgjmOOzOa5fRb/IqlGlBn4a4me3hWthLLtMy+OOEim
  6ENjntVTBQiTP/YqrxWDbCkaD7b2e9wY5N3JlRxMIQHfcHaND3PRdQSn7oHYXmJl
Message-ID: 
Date: Thu, 18 Apr 2019 12:12:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
  Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit

On 17/04/2019 19:28, Richard Huntrods wrote:
> Nothing changed since before your server crashed to after, and I've
> checked all junk and spam filters.
> 
> I am still not receiving any of the digests anymore. Are the digests

> even being sent out?

Yes they are. Looking in the logs I see a bunch of deliveries to your
mail host shortly after you sent this message. Did any of those arrive
in your inbox? If so, the headers may be instructive.

Mark


> 
> Thanks,
> 
> -R
> 
>> On 12/04/2019 16:32, Mark Thomas wrote:

>> > On 12/04/2019 16:29, Mark Thomas wrote:
>> >> Which address did you use to subscribe to the digest list? It wasn't
>> >> this one...
>> > > Ignore that. ezmlm cmd line error on my part. I see your digest
>> > subscription in the logs from this address. Hmmm.
>> > > Let me go and dig into the mail logs...
>>
>> Nothing obvious. And my test digest subscription is working. Are you
>> still having issues?
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 
> ---

> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 



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

Re: Is there a problem with the digest?

[Richard Huntrods]

Nothing changed since before your server crashed to after, and I've 
checked all junk and spam filters.


I am still not receiving any of the digests anymore. Are the digests 
even being sent out?


Thanks,

-R


On 12/04/2019 16:32, Mark Thomas wrote:
> On 12/04/2019 16:29, Mark Thomas wrote:
>> Which address did you use to subscribe to the digest list? It wasn't
>> this one...
> 
> Ignore that. ezmlm cmd line error on my part. I see your digest

> subscription in the logs from this address. Hmmm.
> 
> Let me go and dig into the mail logs...


Nothing obvious. And my test digest subscription is working. Are you
still having issues?

Mark

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




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Is there a problem with the digest?

[Richard Huntrods]

Why google? Actually I was continuing to research the problem I'd 
posted, and the digest archive showed up as the first two hits. :-)


-R

On 4/12/2019 7:34 AM, Konstantin Kolinko wrote:

пт, 12 апр. 2019 г. в 17:27, Richard Huntrods :

It's been four days since I've seen a 'users-dig...@tomcat.apache.org'
email. I posted a question on April 9, and no digest since (I subscribed
to the digest), yet I found a reply on the digest archive by searching
with Google.

Why Google? The are several public archives of this mailing list, as
listed here:
https://tomcat.apache.org/lists.html#tomcat-users


So again... is there a problem with digest emails? I have no spam
filters enabled and there's nothing in a junk or trash folder.

I also tried sending a blank email to
users-digest-h...@tomcat.apache.org yesterday and no reply from that either.

I never tried sending a "blank" email. Those may be rejected by spam
filer (as well as e-mails using HTML formatting).

I usually add a few lines of text.

Best regards,
Konstantin Kolinko



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Is there a problem with the digest?

[Richard Huntrods]

It's been four days since I've seen a 'users-dig...@tomcat.apache.org' 
email. I posted a question on April 9, and no digest since (I subscribed 
to the digest), yet I found a reply on the digest archive by searching 
with Google.


So again... is there a problem with digest emails? I have no spam 
filters enabled and there's nothing in a junk or trash folder.


I also tried sending a blank email to 
users-digest-h...@tomcat.apache.org yesterday and no reply from that either.


-R


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Problem with SSH in latest Tomcat

[Richard Huntrods]

Greetings!

I would like to 'do what's necessary' to remove the following error. 
Google tells me it's related to my security implementation, which is 
HTTPS by default. I am convinced the problem is in how I invoke the port 
443 connector in my server.xml. I've been running this servlet on 
versions of Tomcat since 2001, and have kept my Tomcat instances up to 
date. Most recently I started noticing this in the logs, and
am pretty sure it's because I've been copying the connector code bit 
from server.xml to server.xml as I upgraded versions of Tomcat.


I really suspect my connector is now out-of-date and could use some 
guideance as to the best new form. I see in the recent server.xml they 
use a different involcation, but don't know if this is best...


OS: Ubuntu 18.04 LTS Live server
Tomcat: 8.5.39, installed from tar.gz obtained from Tomcat.

I've done this enough times to "get it right", so it's just this Hello 
error I want to eradicate...


Here is the error message:

08-Apr-2019 01:00:23.477 SEVERE [https-jsse-nio-443-exec-9] 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun

 java.lang.UnsupportedOperationException: Unsupported SSL v2.0 ClientHello
    at 
java.base/sun.security.ssl.SSLEngineInputRecord.handleUnknownRecord(SSLEngineInputRecord.java:373)
    at 
java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:195)
    at 
java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:975)
    at 
java.base/sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:902)
    at 
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:680)

    at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
    at 
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:475)
    at 
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:238)
    at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1475)
    at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

    at java.base/java.lang.Thread.run(Thread.java:844)

My certificates are new and correct, and have run fine in past versions 
of Tomcat without problems...


THIS IS MY SERVER.XML - Most of it is identical to the server.xml 
supplied with Tomcat 8.5.39 My changes are after the *** THIS IS MY 
CONNECTOR ... *** comment.


Thanks,
-Richard

**




  className="org.apache.catalina.startup.VersionLoggerListener" />

  
  
  

  
  className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
  className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
  className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />


  
  
    
    
  

  
  

    

    


    
    
    

    
    
    
    
    
    
    

       maxThreads="150" enableLookups="false" scheme="https" 
secure="true"

   keystoreFile="./keys/.keystore" keystorePass="password"
   clientAuth="false" sslProtocol="TLS" />

    
    


    

    
    

  
  

  
  
    
    
  

  

    
    

    
    directory="logs"

   prefix="localhost_access_log" suffix=".txt"
   pattern="%h %l %u %t %r %s %b" />

    showReport="false" showServerInfo="false" />


  
    
  



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: Re: Resource Request - MySQL Data Pool

[Richard Huntrods]

Chris,

Thanks. Lots to go through...

On 3/26/2019 9:00 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Richard,

On 3/25/19 14:15, Richard Huntrods wrote:

 It's time to update my application to use "real" (i.e.
current best practices) data connection pooling.

:)


My application is Java Servlets, no beans, no JSP. Database is
MySQL.

System etc. details: Ubuntu live server 18.04.2, built March 6,
2019.

MySQL - latest installed via 'apt-get install mysql-server' after
system build.

So... MariaDB, then? Or does Ubuntu still stock MySQL binaries?

Seems to be MySQL. See next...



OpenJVM - 11? - again, latest version installed via 'apt-get
install default-jdk' at same time.

Should be pretty easy to determine this:

$ java -version


I typed 'java -version' and this was the output:

openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed 
mode)


I also typed 'mysql -version' and got this (still not sure if Ubuntu 
uses MariaDB or MySQL by default):


mysql  Ver 14.14 Distrib 5.7.25, for Linux (x86_64) using EditLine wrapper




Tomcat 8.5.39 - just updated the same day it came out.

Sounds good so far.


This system has been running in production since the early 2001's.
OS has changed over the years from Sun Solaris 8.x to Solaris 10.x
and now to Ubuntu 18.04 (server). Java has been updated over the
years as well, as has Tomcat and MySQL. Through all that the system
works quite perfectly.

Except... there are occasional hangs that implicate the 'home
grown' data connection pool.  I wrote this by hand (in Java) back
in 2001 because there was nothing much available back then. Since
it kept working, I didn't have the time/inclination to change over
the years.

You may find that your home-grown connection pool is actually okay,
but it's being used incorrectly by client code (which is also your
code). IF you have problems with the client code, the "real"
connection-pool can help you tolerate them, but it won't magically fix
them.


I had problems some years ago with one particular version of the 
connector which had a memory leak (in the connector). I avoided that 
version and have had no particular problems. Some years ago I did a 
pretty exhaustive examination of my application using various metering 
tools to see if I was creating memory leaks with my database code. I 
found one (forgot to close the connection), fixed it and there weren't 
any more.


I also encapsulate ALL my database access into a single "DBMS.java" 
class which is used by all the servlets to access data. The DBMS class 
calls the various pool creation and management classes as needed, so all 
my data "stuff" is in one place (or set of classes).


That makes it simple but also makes it more complex as the "roll my own" 
pool is quite integrated into the DBMS code. I'll have to simplify and 
then do the testing as you suggest below.



But the latest connector (mysql-connector-java-8.0.15.jar, a.k.a.
"com.mysql.cj.jdbc.Driver" is giving me some hiccups. I thought
rather than trying to debug my own connection pool, it was time to
switch over to a proper "modern" supported connection pooling
system.

Which brings me to my question.

Would the community please weigh in on the BEST tutorials /
documents regarding creating a Tomcat/MySQL database connection
pool for Servlets (not JSP or beans) with some good code examples
and server.xml examples?

I've already done some extensive internet searches, but when you
are doing something for the first time it's hard to tell the
difference between "really really good" and "blogger who has not
really tried it".

You will want Tomcat to create the connection pool for you. Anything
else is a waste of time. Here's what happens:


Here we are in total agreement. I *want* Tomcat to manage the pool as I 
suspect pool timeouts are the overall issue that I'm seeing. Basically, 
after several hours of inactivity (the application isn't used a lot 
these days), it just "loses" it's connection and then subsequent data 
accesses generate exceptions as the connection is no longer present. It 
does not happen when the system is being used and data accessed 
regularly, only if the system sits idle for several hours.


So at least to me it's clearly an issue with the home-grown connection 
pool "losing" touch with the database but not in a way that is evident 
to my current code. I've resorted to "tricks" using cron and another 
servlet to regularly access the database to keep the pool open, but I 
figured a Tomcat managed pool would have more capability to handle such 
things.


I could rewrite my own pool, but at this point I'd rather use Tomcat 
pools as I can just offload that portion of my code to a community 
resource, which 

Re: Re: Resource Request - MySQL Data Pool

[Richard Huntrods]

Luis,

Thanks very much. I'll have a look.

Cheers,

-Richard

On 3/26/2019 1:43 AM, Luis Rodríguez Fernández wrote:

Hello Richard,

In my experience the best is to "start simple". I would have a look at the
apache tomcat doc [1], configure your pool with a minimal setup and test.
Everything depends on your application workload, how your queries looks
like, etc,  so I am afraid that there are no "silver bullets" in this
domain.

Hope it helps,

Luis


[1]
https://tomcat.apache.org/tomcat-8.5-doc/jndi-datasource-examples-howto.html






El lun., 25 mar. 2019 a las 19:15, Richard Huntrods ()
escribió:


 It's time to update my application to use "real" (i.e. current
best practices) data connection pooling.

My application is Java Servlets, no beans, no JSP. Database is MySQL.

System etc. details:
Ubuntu live server 18.04.2, built March 6, 2019.

MySQL - latest installed via 'apt-get install mysql-server' after system
build.

OpenJVM - 11? - again, latest version installed via 'apt-get install
default-jdk' at same time.

Tomcat 8.5.39 - just updated the same day it came out.

This system has been running in production since the early 2001's. OS
has changed over the years from Sun Solaris 8.x to Solaris 10.x and now
to Ubuntu 18.04 (server). Java has been updated over the years as well,
as has Tomcat and MySQL. Through all that the system works quite perfectly.

Except... there are occasional hangs that implicate the 'home grown'
data connection pool.  I wrote this by hand (in Java) back in 2001
because there was nothing much available back then. Since it kept
working, I didn't have the time/inclination to change over the years.

But the latest connector (mysql-connector-java-8.0.15.jar, a.k.a.
"com.mysql.cj.jdbc.Driver" is giving me some hiccups. I thought rather
than trying to debug my own connection pool, it was time to switch over
to a proper "modern" supported connection pooling system.

Which brings me to my question.

Would the community please weigh in on the BEST tutorials / documents
regarding creating a Tomcat/MySQL database connection pool for Servlets
(not JSP or beans) with some good code examples and server.xml examples?

I've already done some extensive internet searches, but when you are
doing something for the first time it's hard to tell the difference
between "really really good" and "blogger who has not really tried it".

Thanks very much in advance.

-Richard


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


-
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

Resource Request - MySQL Data Pool

[Richard Huntrods]

 It's time to update my application to use "real" (i.e. current 
best practices) data connection pooling.


My application is Java Servlets, no beans, no JSP. Database is MySQL.

System etc. details:
Ubuntu live server 18.04.2, built March 6, 2019.

MySQL - latest installed via 'apt-get install mysql-server' after system 
build.


OpenJVM - 11? - again, latest version installed via 'apt-get install 
default-jdk' at same time.


Tomcat 8.5.39 - just updated the same day it came out.

This system has been running in production since the early 2001's. OS 
has changed over the years from Sun Solaris 8.x to Solaris 10.x and now 
to Ubuntu 18.04 (server). Java has been updated over the years as well, 
as has Tomcat and MySQL. Through all that the system works quite perfectly.


Except... there are occasional hangs that implicate the 'home grown' 
data connection pool.  I wrote this by hand (in Java) back in 2001 
because there was nothing much available back then. Since it kept 
working, I didn't have the time/inclination to change over the years.


But the latest connector (mysql-connector-java-8.0.15.jar, a.k.a. 
"com.mysql.cj.jdbc.Driver" is giving me some hiccups. I thought rather 
than trying to debug my own connection pool, it was time to switch over 
to a proper "modern" supported connection pooling system.


Which brings me to my question.

Would the community please weigh in on the BEST tutorials / documents 
regarding creating a Tomcat/MySQL database connection pool for Servlets 
(not JSP or beans) with some good code examples and server.xml examples?


I've already done some extensive internet searches, but when you are 
doing something for the first time it's hard to tell the difference 
between "really really good" and "blogger who has not really tried it".


Thanks very much in advance.

-Richard


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: Tomcat behind Apache web server ProxyPass settings for WebSocket

[richard]

On 2018-12-04 20:00, rich...@xentu.com wrote:
I'm trying to see the WebSocket examples that ship with Tomcat 9 in 
action.


If I point my browser directly at tomcat on 8080, they work.

However, Tomcat is behind an Apache2 webserver and I can't seem to get
the ProxyPass settings right. Other Tomcat applications work if I
access them via Apache, but WebSocket applications don't. The snake
demo for example, gives a 'Info: WebSocket closed' message.

Apache is on the same server as Tomcat and has the proxy_wstunnel mod 
loaded.


The relevant (I think) part of my  VirtualHost in the Apache2 conf
file is like this:

  ProxyPass/http://127.0.0.1:8080/  #works ok
  ProxyPassReverse /http://127.0.0.1:8080/  #works ok
  ProxyPass/ws://127.0.0.1:8080/
  ProxyPassReverse /ws://127.0.0.1:8080/

Could anyone tell me what's wrong here?


Thanks.
Richard



Luis & Christopher, thanks for your suggestions.

I've now got a VirtualHost that works, the key section being:

  RewriteEngine On
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteRule /(.*)   ws://localhost:8080/$1 [P,L]
  RewriteCond %{HTTP:Upgrade} !=websocket [NC]
  RewriteRule /(.*)   http://localhost:8080/$1 [P,L]

taken as is from a post at stackoverflow, except that Tomcat defaults to 
8080:


https://stackoverflow.com/questions/27526281/websockets-and-apache-proxy-how-to-configure-mod-proxy-wstunnel

I'd still be interested in knowing if and how this can be achieved with 
ProxyPass however. I spent quite a bit of time trying to match the 
protocol as well as the path in Proxy path, but if it is possible, I 
couldn't get the syntax right.



Richard






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

Tomcat behind Apache web server ProxyPass settings for WebSocket

[richard]

I'm trying to see the WebSocket examples that ship with Tomcat 9 in 
action.


If I point my browser directly at tomcat on 8080, they work.

However, Tomcat is behind an Apache2 webserver and I can't seem to get 
the ProxyPass settings right. Other Tomcat applications work if I access 
them via Apache, but WebSocket applications don't. The snake demo for 
example, gives a 'Info: WebSocket closed' message.


Apache is on the same server as Tomcat and has the proxy_wstunnel mod 
loaded.


The relevant (I think) part of my  VirtualHost in the Apache2 conf file 
is like this:


  ProxyPass/http://127.0.0.1:8080/  #works ok
  ProxyPassReverse /http://127.0.0.1:8080/  #works ok
  ProxyPass/ws://127.0.0.1:8080/
  ProxyPassReverse /ws://127.0.0.1:8080/

Could anyone tell me what's wrong here?


Thanks.
Richard




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

Re: OT: Java Textbook?

[Richard Huntrods]

Completely off-topic.  But I figure this is the perfect group to ask 
this question to.  I will be teaching a university level intro to Java 
programming (for non-programming majors) in the spring semester.  I am 
looking for a good textbook to use.   I've been out of academia for 
years.  So I'm not up to date on available java textbooks.   If you 
are aware of a good textbook, please let me know.  You can reply 
here.  Or just PM me at the address above (please put 'textbook' in 
the subject line if you PM me).


Thanks.

Jerry (ProfJerry.com) 


Jerry,
I do teach intro Java programming at an on-line University, plus I've 
taught Java for many years in other colleges and continuing-ed programs.


My personal preferred text is Bruce Eckel's "Thinking in Java", but it's 
really more of a reference text than a good "reader". There are many 
easy to read texts, but I find them all very short on substance.


Our course currently uses the OER (Online Educational Resource) text 
JavaNotes, a.k.a. "Introduction to Programming Using Java",, 7ed by 
David Eck. I'm not terribly fond of this book.


https://math.hws.edu/javanotes/

I am currently revising the course and will be using the 8th edition of 
the same text by Eck.


https://math.hws.edu/eck/cs124/javanotes8/

The primary benefit of this text is that it is OER. That means it's 
free, and being OER you are free to modifiy/edit/extend the book as long 
as you observe the OER rules, which basically state you keep the 
authorship intact.


Frankly, I think OER is the wave of the future in texts simply because 
it takes the power away from the book publishers and puts it back in the 
hands of those who directly benefit from having free, good texts.


Cheers,
-Richard



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: One tomcat server with different webapps on different ports?

[richard]

On 2018-11-24 23:25, Geraldo Netto wrote:

Hello Richard/Friends,

I might be wrong, but I guess the best approach would be to use apache
httpd or nginx as a reverse proxy and leave tomcat alone


Kind Regards,

Geraldo Netto
Sapere Aude => Non dvcor, dvco
http://exdev.sf.net/

On Sun, 25 Nov 2018 at 00:05,  wrote:


Tomcat/9.0.13


I'd like to have my webapps generally on 443, but the manager and
host-manager on some other port, say 444.

My reason for doing that would be that I could then use linux's 
iptables

to restrict access to 444 to a few known addresses, but anyone could
access 443.

I would of course want to use the manager application on 444 to manage
the applications visible on 443.

Is this possible?


Richard

-



Hi Geraldo.

How would that help?

Can I have different virtual hosts in Apache get their content from 
different webapps in Tomcat?


Richard





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

One tomcat server with different webapps on different ports?

[richard]

Tomcat/9.0.13


I'd like to have my webapps generally on 443, but the manager and 
host-manager on some other port, say 444.


My reason for doing that would be that I could then use linux's iptables 
to restrict access to 444 to a few known addresses, but anyone could 
access 443.


I would of course want to use the manager application on 444 to manage 
the applications visible on 443.


Is this possible?


Richard

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

Re: Translation help wanted

[Richard HO]

Hi, Mark

I used to be a JEE application server developer and developed it for three
years. I am also a blogger at the same time.
My article will be posted to the WeChat subscription account.
Currently, there are more than 15,000 subscribers. Content will be read by
all  followers.

This morning, I posted an article about the translation of Tocmat
internationalization information and error messages.
Our target language is Simplified Chinese. So, many developers have joined
in and everyone works together.
 At noon, the progress of Chinese translation has reached 10%.

[image: WechatIMG551.jpeg]
  But in the afternoon, I suddenly found that the progress became 3%,

  and I saw your name in the contributor.


  Excuse me, did you clear some content?

Is the translated content unqualified?



[image: 3abc.jpg]
[image: translator.jpg]



Richard


Mark Thomas  于2018年11月12日周一 下午7:49写道：

> All,
>
> Apache Tomcat includes some translations for error messages and parts of
> the user interface - primarily the Manager web application. We would
> like to improve the coverage and quality of these translations.
> Accordingly, the Tomcat project has been set up on POEditor, a web-based
> service for managing the translation of resource files.
>
> The aim is that anyone who wants to contribute to the translations (it
> could be anything from fixing a typo in an existing translation to
> adding support for a new language) can create an account and contribute.
>
> If you would like to contribute in this way then the
> The Tomcat project can be found here:
>
> https://poeditor.com/join/project/NUTIjDWzrl
>
> Anyone should be able to join up as a contributor. If you are
> interested, please sign up and start contributing.
>
> Note: All contributions will be taken as being made under the terms of
> the Apache License version 2.
>
> I'm aiming to export the translations on a regular basis to the Tomcat
> source code. How regularly will depend on the rate of new/updated
> translations but as a minimum, I'm aiming to get any updates into the
> next Tomcat 9 release.
>
> If you have any difficulties or questions, please ask here.
>
> Thanks,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: SSL Errors and Warnings with various version of Tomcat

[Richard Tearle]

On Tue, 13 Nov 2018 at 14:10, Mark Thomas  wrote:
>
> On 13/11/2018 14:00, Rémy Maucherat wrote:
> > On Tue, Nov 13, 2018 at 2:50 PM Richard Tearle <
> > richard.tea...@northgateps.com> wrote:
> >
> >> Hi
> >>
> >> Our applications are all working fine with Tomcat 8.5.34 and Tomcat
> >> Native 1.2.17; Centos 7.5; OpenSSL 1.0.2k-fips  26 Jan 2017; Oracle
> >> Java JRE 8u172
> >>
> >> On upgrading to Tomcat 8.5.35 and Tomcat Native 1.2.18, we get the
> >> following warning:
> >>
> >> 12-Nov-2018 14:37:03.459 WARNING [main]
> >> org.apache.tomcat.util.net.openssl.OpenSSLEngine. Failed
> >> getting cipher list
> >>  java.lang.Exception: Invalid Server SSL Protocol
> >> (error::lib(0):func(0):reason(0))
> >> at org.apache.tomcat.jni.SSLContext.make(Native Method)
> >> at org.apache.tomcat.util.net
> >> .openssl.OpenSSLEngine.(OpenSSLEngine.java:73)
> >>
> >
> > There was a patch porting problem in 8.5 in the jni.SSL class.
>
> Sorry. My mistake.
>
> I'll get the necessary fix back-ported for the next 8.5.x release.
>
> Mark

OK - so I just hold off until the next release - we can live with that.

Thanks all!

Richard

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

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

SSL Errors and Warnings with various version of Tomcat

[Richard Tearle]

Hi

Our applications are all working fine with Tomcat 8.5.34 and Tomcat
Native 1.2.17; Centos 7.5; OpenSSL 1.0.2k-fips  26 Jan 2017; Oracle
Java JRE 8u172

On upgrading to Tomcat 8.5.35 and Tomcat Native 1.2.18, we get the
following warning:

12-Nov-2018 14:37:03.459 WARNING [main]
org.apache.tomcat.util.net.openssl.OpenSSLEngine. Failed
getting cipher list
 java.lang.Exception: Invalid Server SSL Protocol
(error::lib(0):func(0):reason(0))
at org.apache.tomcat.jni.SSLContext.make(Native Method)
at 
org.apache.tomcat.util.net.openssl.OpenSSLEngine.(OpenSSLEngine.java:73)
at 
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getImplementedProtocols(OpenSSLUtil.java:63)
at org.apache.tomcat.util.net.SSLUtilBase.(SSLUtilBase.java:67)
at org.apache.tomcat.util.net.SSLUtilBase.(SSLUtilBase.java:51)
at 
org.apache.tomcat.util.net.openssl.OpenSSLUtil.(OpenSSLUtil.java:42)
at 
org.apache.tomcat.util.net.openssl.OpenSSLImplementation.getSSLUtil(OpenSSLImplementation.java:36)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:103)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1087)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:265)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:638)
at org.apache.catalina.startup.Catalina.load(Catalina.java:661)
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.load(Bootstrap.java:309)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)

On downgrading Tomcat Native to 1.2.17, and still keeping Tomcat
8.5.35, we get the following FATAL:

12-Nov-2018 17:24:17.474 SEVERE [https-openssl-nio-8443-exec-2]
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
 java.lang.UnsatisfiedLinkError:
org.apache.tomcat.jni.SSL.renegotiatePending(J)I
at org.apache.tomcat.jni.SSL.renegotiatePending(Native Method)
at 
org.apache.tomcat.util.net.openssl.OpenSSLEngine.getHandshakeStatus(OpenSSLEngine.java:1021)
at 
org.apache.tomcat.util.net.openssl.OpenSSLEngine.wrap(OpenSSLEngine.java:457)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
at 
org.apache.tomcat.util.net.SecureNioChannel.handshakeWrap(SecureNioChannel.java:440)
at 
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:211)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1475)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

Our application is fine with Tomcat 8.5.34 and Tomcat Native 1.2.18 as well.

Our connector configuration is, which we've not changed whilst testing
various version combinations:

   






We'd like to upgrade to Tomcat 8.5.35 and Tomcat Native 1.2.18,
without the warning (our implementers get twitchy when they see
warnings, even more so when it's around SSL/TLS...)

Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use it

Re: [EXTERNAL] Re: Configuring CORS filter

[Bradley, Richard]

Thank you Mark!  For the quick reply!  Yeah...Apache reports it as LOW and
they report as MEDIUM.  We have to mitigate all MEDIUM and HIGH
vulnerabilities.

Best regards,

Rick


On Wed, Jun 20, 2018 at 1:00 PM, Mark Thomas  wrote:

> On 20/06/18 18:16, Bradley, Richard wrote:
> > Hello,
> >
> > Tomcat version: 8.5.31
> > O/S: Windows Server 2008 R2
> >
> > McAfee vulnerability checker has reported a MEDIUM level vulnerability as
> > follows:
> >
> > Vulnerability: CVE-2018-8014: Apache Tomcat Vulnerability Prior To 8.5.32
> > [FID 23621]
> >
> > Apache Software Foundation reports this in  annou...@tomcat.apache.org
> > <https://lists.apache.org/list.html?annou...@tomcat.apache.org>:
> >
> > CVE-2018-8014 Insecure defaults for CORS filter
> >
> > and the only mitigation is to "Configure the filter appropriately for
> your
> > environment"
> >
> > My question is:
> >
> > What if you don't have a CORS filter configured anywhere in the Tomcat
> and
> > web apps associated web.xml files?
>
> You have nothing to worry about.
>
> Well, apart from the poor quality of your vulnerability scanner that
> looks like it is reporting a CORS issue without checking to see if CORS
> headers are being sent.
>
> Mark
>
>
> -----
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>


-- 
Richard M. Bradley (Rick)

*Geospatial Engineer*
BLM NOC EGIS
Sanborn Map Company, Inc.
Phone number: (303) 236-4538
rmbrad...@blm.gov




"Decide that you want it more than you're afraid of it.  Your greatest
dreams are all on the other side of the wall of fear and caution."

- Unknown

This e-mail, including any attachments, contains information intended only
for the use of the individual or entity to which it is addressed and may
contain information that is privileged and/or confidential or is otherwise
protected by law. If you are not the intended recipient or agent or an
employee responsible for delivering the communication to the intended
recipient, you are hereby notified that any review, use, disclosure,
copying and/or distribution of its contents is prohibited. If you have
received this e-mail in error, please notify us immediately by reply to
sender only and destroy the original.

Configuring CORS filter

[Bradley, Richard]

Hello,

Tomcat version: 8.5.31
O/S: Windows Server 2008 R2

McAfee vulnerability checker has reported a MEDIUM level vulnerability as
follows:

Vulnerability: CVE-2018-8014: Apache Tomcat Vulnerability Prior To 8.5.32
[FID 23621]

Apache Software Foundation reports this in  annou...@tomcat.apache.org
<https://lists.apache.org/list.html?annou...@tomcat.apache.org>:

CVE-2018-8014 Insecure defaults for CORS filter

and the only mitigation is to "Configure the filter appropriately for your
environment"

My question is:

What if you don't have a CORS filter configured anywhere in the Tomcat and
web apps associated web.xml files?

It seems that if you explicitly configure a minimum filter specified in the
documentation

(https://tomcat.apache.org/tomcat-8.5-doc/config/filter.html#CORS_Filter)

then you have to be concerned about the cors.support.credentials allowing
the default of "true".

Thanks,

Rick





-- 
Richard M. Bradley (Rick)

*Geospatial Engineer*
BLM NOC EGIS
Sanborn Map Company, Inc.
Phone number: (303) 236-4538
rmbrad...@blm.gov




"Decide that you want it more than you're afraid of it.  Your greatest
dreams are all on the other side of the wall of fear and caution."

- Unknown

This e-mail, including any attachments, contains information intended only
for the use of the individual or entity to which it is addressed and may
contain information that is privileged and/or confidential or is otherwise
protected by law. If you are not the intended recipient or agent or an
employee responsible for delivering the communication to the intended
recipient, you are hereby notified that any review, use, disclosure,
copying and/or distribution of its contents is prohibited. If you have
received this e-mail in error, please notify us immediately by reply to
sender only and destroy the original.

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 17 April 2018 at 16:45, Richard Tearle
<richard.tea...@northgateps.com> wrote:
> On 17 April 2018 at 14:54, Mark Thomas <ma...@apache.org> wrote:
>> On 17/04/18 11:36, Mark Thomas wrote:
>>> On 17/04/18 10:14, Richard Tearle wrote:
>>
>> 
>>
>>> Now all we need to to do is to figure out how to fix this. With the
>>> understanding of what is (probably) going wrong, the problem can be
>>> produced with a clean build and the certs we use for unit tests which
>>> makes things a lot easier. I hope to make progress on this today.
>>
>> I believe this is fixed in trunk for both 9.0.x and 8.5.x.
>>
>> Are you able to build either of those from source and test? If not, I
>> can provide a snapshot build for you to test with.
>>
>> Cheers,
>>
>> Mark
>>
>
> I've built from source, re-enabled the health check, and so
> far so good - it's been running an hour without an error.
>
> Once this run has finished, I'll run it overnight, and let you
> know tomorrow morning.
>
> Many thanks for your help on this.
>
> --
> Richard

Just a quick follow up - I've run our test for 8 hours, without the
connection closed error.

Again, many thanks.

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 17 April 2018 at 14:54, Mark Thomas <ma...@apache.org> wrote:
> On 17/04/18 11:36, Mark Thomas wrote:
>> On 17/04/18 10:14, Richard Tearle wrote:
>
> 
>
>> Now all we need to to do is to figure out how to fix this. With the
>> understanding of what is (probably) going wrong, the problem can be
>> produced with a clean build and the certs we use for unit tests which
>> makes things a lot easier. I hope to make progress on this today.
>
> I believe this is fixed in trunk for both 9.0.x and 8.5.x.
>
> Are you able to build either of those from source and test? If not, I
> can provide a snapshot build for you to test with.
>
> Cheers,
>
> Mark
>

I've built from source, re-enabled the health check, and so
far so good - it's been running an hour without an error.

Once this run has finished, I'll run it overnight, and let you
know tomorrow morning.

Many thanks for your help on this.

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 16 April 2018 at 22:04, Mark Thomas <ma...@apache.org> wrote:
> On 11/04/18 09:22, Richard Tearle wrote:
>
> 
>
>> I've built tomcat from source using the link you provided, and rebuilt the
>> containers with this tomcat, and can still reproduce the issue. I've uploaded
>> the logs (30s before the connection closed error), to dropbox:
>>
>> https://www.dropbox.com/s/qe50jbd196krtyo/logs-10-04-17.zip?dl=0
>
> Thanks for these.
>
> I've started to look at them. I don't have any firm conclusions yet. I
> have noticed that the problem occurs after a connection is made to the
> service from localhost rather than the remote IP that is making the
> other requests. The localhost client does not present a certificate.
>
> My working theory (so chances are it is completely wrong) is that the
> missing certificate in the request from localhost puts the OpenSSL
> engine into an error state that is not correctly handled by Tomcat
> causing the subsequent request to fail.
>
> I've also noticed that the debug level log message consistently report 0
> bytes being read which looks wrong but is probably a separate (minor) issue.
>
> Investigations continue.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Ah that rings a bell.

Our containers have a simple health check, simply does

curl --connect-timeout 5 --max-time 20 -k -s -S --stderr -\
https://localhost:${TOMCATS_PORT}/ |\
grep -q "NSS: client certificate not found" || exit 1

just to make sure the ESB is responding, with something we expect.
These are set to run at an interval of every 2m30s. The full parameters
in the docker-compose[1] file are:

healthcheck:
  test: ["CMD", "/usr/local/bin/healthcheck.sh"]
  interval: 2m30s
  timeout: 10s
  retries: 3
  start_period: 20s

I've also disabled the health check on ESB container, and my tests
ran through for an hour, without a connection closed error.

[1] https://docs.docker.com/compose/compose-file/#healthcheck

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 5 April 2018 at 08:35, Richard Tearle <richard.tea...@northgateps.com> wrote:
>
> On 4 April 2018 at 17:58, Mark Thomas <ma...@apache.org> wrote:
> > On 26/03/18 08:25, Richard Tearle wrote:
> >
> > 
> >
> > Thanks. I've got the test application and UI running but I haven't yet
> > reproduced the problem. What parameters are you calling run-test.sh with?
>
> This usually get's a failure within 10 minutes of running:
>
> ./run-test.sh 28800 5000 5000 0 0 true
>
> (I've just tried it and it failed after 4m 23s - from the previous rounds
> of testing, it failed at around the 4m 30s mark 7 times out of 10)
>
> > I'll continue to try and reproduce the issue but I think it makes sense
> > to try and generate some debug data on your system as you can reproduce it.
> >
>
> I'll get onto this, but it might not be until next week.
>
> Thanks
>
> Richard.

I've built tomcat from source using the link you provided, and rebuilt the
containers with this tomcat, and can still reproduce the issue. I've uploaded
the logs (30s before the connection closed error), to dropbox:

https://www.dropbox.com/s/qe50jbd196krtyo/logs-10-04-17.zip?dl=0

Regards

-- 

Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 4 April 2018 at 17:58, Mark Thomas <ma...@apache.org> wrote:
> On 26/03/18 08:25, Richard Tearle wrote:
>
> 
>
> Thanks. I've got the test application and UI running but I haven't yet
> reproduced the problem. What parameters are you calling run-test.sh with?

This usually get's a failure within 10 minutes of running:

./run-test.sh 28800 5000 5000 0 0 true

(I've just tried it and it failed after 4m 23s - from the previous rounds
of testing, it failed at around the 4m 30s mark 7 times out of 10)

> I'll continue to try and reproduce the issue but I think it makes sense
> to try and generate some debug data on your system as you can reproduce it.
>

I'll get onto this, but it might not be until next week.

Thanks

Richard.

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

Hi

On 24 March 2018 at 23:06, Mark Thomas <ma...@apache.org> wrote:
> On 23/03/18 15:00, Richard Tearle wrote:
>> On 22 March 2018 at 23:06, Mark Thomas <ma...@apache.org> wrote:
>>> On 22/03/18 15:27, Richard Tearle wrote:
>>>> On 22 March 2018 at 14:49, Mark Thomas <ma...@apache.org> wrote:
>>>
>>> 
>>>
>
> I've taken another look at the configuration options and
> disableSessionTickets="true" is the only one that stands out as a
> possibility.
>
> I think we have reached the point where we need a reproducible test case.
>
> Mark
>

I've uploaded a ZIP with my test "UI" code (standalone java program),
and the "ESB"
code which goes into tomcat.

https://www.dropbox.com/s/nhfx7va4uzkr728/Source.zip?dl=0

In the support folder within the ZIP are updated scripts to create the
certificates - which
now includes generating the client certificate as well. Also in there
are the server.xml
and other tomcat configuration files that are changed as part of our
installation process
- although these are the same as I'd included in the previous ZIP.

Also included is a very simple shell script I use to call the UI.
Usually setting the ESB
delay to 5 seconds causes the connection closed error to occur in
around 5 minutes of
running the program.

Kinds Regards

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 22 March 2018 at 23:06, Mark Thomas <ma...@apache.org> wrote:
> On 22/03/18 15:27, Richard Tearle wrote:
>> On 22 March 2018 at 14:49, Mark Thomas <ma...@apache.org> wrote:
>
> 
>
> OK. Time to think about this. NIO + JSSE works whereas NIO + OpenSSL
> doesn't with the same configuration apart from the presence of the
> native library.
>
> That points to something OpenSSL specific.
>
> Disabling client verification fixes the problem.
>
> So it looks to be something to do with how OpenSSL handles client
> verification. It feels like configuration at this point rather than a
> bug but it needs some more thought.
>
> There will probably be some configuration combinations to experiment
> with but if they fail, something we can use to reproduce this is going
> to be the next step.
>
> Mark
>

That's fine and many thanks for your help - I can get quite a good turn around
on testing various configuration changes. Anything that looks
promising, I'll run
for 8 hours, and we can usually get an inkling after an hour.

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 22 March 2018 at 14:49, Mark Thomas <ma...@apache.org> wrote:
> On 22/03/18 07:46, Richard Tearle wrote:
>> On 21 March 2018 at 14:54, Mark Thomas <ma...@apache.org> wrote:

[snip]

> Excellent.
>
> There have been a few moving parts here so I'd like to get some
> clarification on exactly where we are. I know from bitter personal
> experience that it is all too easy to end up using a slightly different
> TLS configuration to the one you think you are using so please could you
> confirm the following.
>
> The connector name can be obtained from the logs. You'll see lines that
> look like this:
>
> 22-Mar-2018 14:39:30.156 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["http-nio-8080"]
> 22-Mar-2018 14:39:30.161 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["https-jsse-nio-8443"]
> 22-Mar-2018 14:39:30.163 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["ajp-nio-8009"]
>
> The part I am using below is the bit in the square brackes. The format
> is ---.
>
> What we have so far is:
>
> 8.0.x, http-nio- (this is always JSSE in 8.0.x), clientAuth="true"
> This works.

Yes this works.

> 8.5.x, http-nio-openssl-, certificateVerification="required"
> This fails intermittently

Its https-openssl-nio- and yes this fails intermittently.

> 8.5.x, http-nio-jsse-,  certificateVerification="required"
> This works

Its https-jsse-nio-, and yes this works

> Is this correct?
>
> Thanks,
>
> Mark
>

Also working is 8.5.x, https-openssl-nio-, certificateVerification="none"

Thanks

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 21 March 2018 at 14:54, Mark Thomas <ma...@apache.org> wrote:
>
>
> Progress.
>
> Tomcat 8.0.x is more relaxed about the content of PKCS12 trust stores
> then 8.5.x because of a change[1] made so that the effectiveness of the
> certificateVerificationDepth configuration attribute did not depend on
> the presence of a certificate revocation list.
>
> The PKCS12 store the scripts you provided creates includes the private
> key of the trusted certificate. This is ... unusual. 8.5.x skips this
> cert as it does not expect a trusted cert to include the private key.
>
> I've tried various ways to get openssl to create a PKCS12 file without
> the private key but with the certificate without success. In the end I
> used keytool to do this and that worked. Something along these lines:
>
> keytool -storetype pkcs12 -importcert -file ca-cert.pem \
> -keystore ca-truststore.p12
>
> With the modified trust store 8.5.x started with the same configuration
> as 8.0.x.
>
> Please can you test your set-up with 8.5.x, the modified trust store and
> the same configuration as 8.0.x (NIO, JSSE). That should help us track
> down where the problem may lie.
>
> Thanks,
>
> Mark
>

I created the PKCS12 as you showed above used my 8.0.x configuration and
ran my test application for 8 hours without a single connection closed error .

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 20 March 2018 at 19:58, Mark Thomas <ma...@apache.org> wrote:

> On 20/03/18 14:49, Richard Tearle wrote:
> OK. Can you share you configuration and the steps you used to create the
> self-signed certificate. I'd like to see if I can reproduce this.
>
>
> Mark
>

I thought it might be easier to drop the configuration and certificate
generating scripts into a ZIP on dropbox:

https://www.dropbox.com/s/ib98y6ti2bem53v/TomcatCertsIssue.zip?dl=0

In the root of the ZIP contains two scripts, run the create-cert.sh,
to generate them.

Our Java installation has the Java Cryptography Extension (JCE)
installed, and generally we run with the java security manager
enabled, but I've tested running without it doesn't seem to affect the
error we get.

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 20 March 2018 at 14:49, Richard Tearle
<richard.tea...@northgateps.com> wrote:
> Hello
>
> On 20 March 2018 at 11:29, Mark Thomas <ma...@apache.org> wrote:
>>
>> 
>>
>> There are rather too many factors at play here. It would be good to try
>> and eliminate some of them.
>>
>> What are the known working 8.0.x versions?
>>

Sorry I missed these in my previous reply:

8.0.50, 8.0.48 to 8.0.46, 8.0.41. 8.0.33, 8.0.26

--

 Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

Hello

On 20 March 2018 at 11:29, Mark Thomas <ma...@apache.org> wrote:
>
> On 20/03/18 07:52, Richard Tearle wrote:
> > Hello
> >
> > We have 4 applications built on the same architecture with a web UI
> > and camel based ESB running in separate Tomcat's, using REST/XML to
> > communicate between the two. This is all deployed within separate
> > Docker containers but on the same VM (at least for test), either on
> > Centos Linux or Oracle Linux. This all works on Tomcat 8.0.x. We've
> > been upgrading to Tomcat 8.5.x since November last year, but this has
> > been hampered by what looks to be random connection closed errors when
> > our UI communicates to the ESB. We have a series of Selenium based
> > autotests which will fail in different places, but with the same
> > error:
>
> 
>
> There are rather too many factors at play here. It would be good to try
> and eliminate some of them.
>
> What are the known working 8.0.x versions?
>
> I looks like you are using JSSE with 8.0.x. It should be possible to use
> the exact same configuration with 8.5.x. No need to use the native
> library and no need to switch to the new configuration style.
>
> Lets try and get 8.5.x working with JSSE. That should help narrow down
> the root cause. What happens when you transfer the working 8.0.x config
> to 8.5.x?

On startup we get:

20-Mar-2018 14:43:18.908 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed
to initialize component [Connector[HTTP/1.1-4001]]
 org.apache.catalina.LifecycleException: Protocol handler initialization failed
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:935)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:530)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:852)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at org.apache.catalina.startup.Catalina.load(Catalina.java:633)
at org.apache.catalina.startup.Catalina.load(Catalina.java:656)
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.load(Bootstrap.java:309)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
Caused by: java.lang.IllegalArgumentException: the trustAnchors
parameter must be non-empty
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:114)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:85)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:216)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1043)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:540)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:932)
... 13 more
Caused by: java.security.InvalidAlgorithmParameterException: the
trustAnchors parameter must be non-empty
at 
java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
at 
java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130)
at 
org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:389)
at 
org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:313)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:112)
... 19 more

> Also, anything you can do to reduce the complexity of the test
> application (ideally reducing it to simple Servlets/JSPs) would make it
> easier for others to reproduce the issue.

I can ZIP my code and drop it somewhere if that will help.

> Hmm. That looks like a controlled shutdown. Random thought, does setting
> disableSessionTickets="true" help at all when using OpenSSL?
>

I'm afraid that didn't work, but thanks for the suggestion.

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


-- 

Richard

-- 
This email is sent on behalf of Northgate 

Connection closed error and certificateVerification="required"

[Richard Tearle]

 data:

*** CertificateVerify
Signature Algorithm SHA512withRSA
I/O dispatcher 1, WRITE: TLSv1.2 Handshake, length = 520
I/O dispatcher 1, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 197, 39, 73, 181, 14, 87, 139, 81, 247, 181, 32, 17 }
***
I/O dispatcher 1, WRITE: TLSv1.2 Handshake, length = 40
I/O dispatcher 1, READ: TLSv1.2 Change Cipher Spec, length = 1
I/O dispatcher 1, READ: TLSv1.2 Handshake, length = 40
*** Finished
verify_data:  { 84, 164, 177, 160, 235, 23, 31, 20, 252, 149, 214, 245 }
***
%% Cached client session: [Session-101,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
I/O dispatcher 1, WRITE: TLSv1.2 Application Data, length = 391
I/O dispatcher 1, READ: TLSv1.2 Alert, length = 26
I/O dispatcher 1, RECV TLSv1.2 ALERT:  warning, close_notify
I/O dispatcher 1, closeInboundInternal()
I/O dispatcher 1, closeOutboundInternal()
I/O dispatcher 1, SEND TLSv1.2 ALERT:  warning, description = close_notify
I/O dispatcher 1, WRITE: TLSv1.2 Alert, length = 26

The failed call doesn't make it into the ESB application logs, and I
can't see any errors in any of the ESB logs.

I appreciate that I haven't included all the information required to
help resolve this issue; so please tell me what extra information is
required.

-- 

Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Tomcat 8.5.28 SSL - Cannot store non-PrivateKeys

[Richard Tearle]

Hello

On 1 March 2018 at 23:31, George S. <geor...@mhsoftware.com> wrote:

> I'm hitting the error:
>
> SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8443]]
> org.apache.catalina.LifecycleException: Failed to initialize component
> [Connector[HTTP/1.1-8443]]
> Caused by: org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> Caused by: java.lang.IllegalArgumentException: Cannot store
> non-PrivateKeys
>
> The connector is configured as:
>
>
>  address="10.0.0.62"
>maxThreads="150" SSLEnabled="true">
> 
>  certificateFile="conf/certificate.pem"
>  type="RSA" />
> 
> 
>
> I've verified the tomcat user can read the two files, and I've su'd to
> user tomcat and used:
>
> openssl rsa -in key.pem -text
>
> and the private key was dumped as expected. The key is not encrypted. The
> cert is self-signed and was generated by OpenSSL using CA.sh.
>
> I'm kind of at a loss here. The example server.xml entries show naming PEM
> files directly, and the connector docs seem to imply that pem files are
> supported.
>
> Can anyone give me a pointer on what to do here?
>
> --
> George S.
> *MH Software, Inc.*
> Voice: 303 438 9585
> http://www.mhsoftware.com
>


Are you using the Tomcat Native Library? I think that's required when using
PEM encoded certificates.

-- 

*Richard Tearle BSc(Hons) MCP*

Senior Consultant

*Northgate Public Services (NPS)*

Mobile: +44 (0)7738 888315

Email: richard.tea...@northgateps.com

Web: www.n <http://www.northgate-is.com/>orthgatepublicservices.co.uk

Please consider the environment before printing this e-mail

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

Re: Tomcat behind IIS on windows 2012

[richard]

On 2018-03-02 20:59, rich...@xentu.com wrote:

If I want to have IIS act as an intermediary between Tomcat and the
outside world, if I've understood it correctly, there seem to be two
choices.

Either add something called HttpPlatformHandler into IIS

https://www.iis.net/downloads/microsoft/httpplatformhandler

or, use the Apache Tomcat Connectors

https://archive.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win64/jk-1.2.30/ia64/

Is either considered best practice, to be preferred over the other?


Regards
Richard


ps: I posted this same question over at javaranch a week or so back,
but with no responses as yet. I'll copy any answer here over to that
forum.



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


Mark & Andre,

Thank you for your responses.
Useful.

Regards
Richard

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

Tomcat behind IIS on windows 2012

[richard]

If I want to have IIS act as an intermediary between Tomcat and the 
outside world, if I've understood it correctly, there seem to be two 
choices.


Either add something called HttpPlatformHandler into IIS

https://www.iis.net/downloads/microsoft/httpplatformhandler

or, use the Apache Tomcat Connectors

https://archive.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win64/jk-1.2.30/ia64/

Is either considered best practice, to be preferred over the other?


Regards
Richard


ps: I posted this same question over at javaranch a week or so back, but 
with no responses as yet. I'll copy any answer here over to that forum.




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

Re: where to put jars used by several apps

[richard]

On 2017-11-25 14:35, rich...@xentu.com wrote:

I've written a few jersey webapps, and each has about 20 jar files
included as Maven dependencies.

The inclusion of those jars increases the size of the resulting wars
by a factor of over 100. Uploading a war via 'Tomcat Web Application
Manager' takes several minutes, presumably due in part to the war
size.

Given that these webapps require the same set of jars in their
WEB-INF/lib/, I thought I could place them in say

C:\Program Files\Apache Software Foundation\Tomcat 7.0\lib\jersey

where all webapps could find them.

In catalina.properties, I appended this new directory to the
common.loader list of paths:

common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,
${catalina.base}/lib/jersey/*.jar

Then, in each jersey webapp, I'd modify pom.xml to exclude those files
from the war.


  maven-war-plugin
  3.2.0
  
WEB-INF/lib/*.jar
  


This approach seems to work.

So, the question I'm seeking advise on is this:

If I have a collection of jars that I want to keep on Tomcat, for some
but not all webapps, and those jars are not to be included in the
wars, is this an acceptable technique? Or is it going to land me in
trouble? Does the order of locations in common.loader matter?


Thanks for any advice
Richard




Ray & Nasry, thanks for your observations.

Seems like my approach, in my situation at least, isn't going to cause 
me problems, so that's good.


I'm only deploying to one server & the only apps on it are ones I've 
written, so I can take care of the versions of the jars involved.


Regards
Richard





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

where to put jars used by several apps

[richard]

I've written a few jersey webapps, and each has about 20 jar files 
included as Maven dependencies.


The inclusion of those jars increases the size of the resulting wars by 
a factor of over 100. Uploading a war via 'Tomcat Web Application 
Manager' takes several minutes, presumably due in part to the war size.


Given that these webapps require the same set of jars in their 
WEB-INF/lib/, I thought I could place them in say


C:\Program Files\Apache Software Foundation\Tomcat 7.0\lib\jersey

where all webapps could find them.

In catalina.properties, I appended this new directory to the 
common.loader list of paths:


common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar, 
${catalina.base}/lib/jersey/*.jar


Then, in each jersey webapp, I'd modify pom.xml to exclude those files 
from the war.



  maven-war-plugin
  3.2.0
  
WEB-INF/lib/*.jar
  


This approach seems to work.

So, the question I'm seeking advise on is this:

If I have a collection of jars that I want to keep on Tomcat, for some 
but not all webapps, and those jars are not to be included in the wars, 
is this an acceptable technique? Or is it going to land me in trouble? 
Does the order of locations in common.loader matter?



Thanks for any advice
Richard

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

Re: Trouble with TLS/SSL and Tomcat 8.5.23

[Richard Tearle]

On 23 November 2017 at 17:20, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 11/23/17 8:28 AM, Richard Tearle wrote:
>> Yes I read through that thread, but we don't really like Java key
>> stores, and I don't think the work around would work for us.
>
> Java keystores are ... awful.
>
>> Instead, I did what perhaps I should have done a while ago (on
>> version 8.0.x), and built Tomcat Native libraries, deployed, and
>> changed the certificate references in the connector to use our .PEM
>> files (which the PKCS12 files are built from), and fingers crossed,
>> its looking OK at the moment.
>
> So are you using the APR connector, then?
>
> You do have some other options:
>
> 1. JSSE with a PKCS12 keystore. OpenSSL can work with those types of
> keystores.
>
> 2. JSSE with PEM-encoded DER files. I prefer PEM-encoded DER files for
> everything, simply because they are so easy to work with.
>
> 3. JSSE+OpenSSL with PEM-encoded DER files.
>
> Option #3 will get you the performance of OpenSSL's crypto but without
> using the APR connector (which isn't quite as efficient as the
> pure-Java NIO connector). Java's crypto seems to be hobbled for some
> reason... some kind of mistake in the native-optimization that ends up
> falling-back to pure-Java crypto which ... simply isn't fast enough
> for real-world workloads).
>
> I think the APR connector is likely to disappear with the next major
> release of Tomcat (10.x I would guess) as the NIO+OpenSSL combination
> is becoming more mature and offers better performance and scalability.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloXA2AACgkQHPApP6U8
> pFilzA/9E5R4NjcoB1yE6oQ2sXb7TURJg/WDJls00Y7RjwSN1UmkiiAdwktcuH0T
> hL6+2M71yrJ+rnCLbyQGEmPdJdFSAv4rTy+eoHJqDTf9jakUYvLC+XvIdWgz/p6i
> tWhIRZAS/sr4JmwFgrIY4I4iKcmJ/pGjrQHLu59H0gEYFdOCoA+WpsNgmIiFLUr6
> IWochlde/ahxP6vNOZJLYxBb8kQ8JUBWXHN+2jGiD5GU7jav3DmwlFKeaoelbclk
> DUUbzc+no83pSIcwzsNsIcPjxdh9fSIzP3nAdNDlIJtGF3SDwwu6HyP0cEb+r+rg
> l9LjDwUrcIFB7pAas38bUpf8DjSysRLk5Jh013BhxUJIcB5hZflrUqeq6Nb+JonC
> EepZoUNSWFiblB36ofNmyJUXaRshBqVfD/x1teJXpoLVJ/HUY8A84T3DlLIzHMAS
> lMfJ4CaCYyDqeA5KL9PZMyEpiPivn4aqeMeVEkrz/DHamLvWhJ649mfRb9BNOBE0
> 3uJvLHOYanORuVWAyQc6nmpSFuda3lgUCZVN9/jhRNW6AszBjLi/9xb7vP/EE41I
> jXZYnJgra1tdL2wq85cqR3NRIf2HrZrvaVsQOikn+MqHR19Pwm5T3xrlIN9hT4EP
> t9LeqizK0vK0cz0/tDBVmqXjASyP5ArJ0dz6uJqijJtGjUWe+gM=
> =bf9o
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Hi

I think Option #1 was what I was trying to achieve originally. I'll take a look
at option #3 tomorrow.

Thanks for the heads up

Richard.

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Trouble with TLS/SSL and Tomcat 8.5.23

[Richard Tearle]

On 23 November 2017 at 05:33, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 11/22/17 8:40 AM, Richard Tearle wrote:
>> Hello
>>
>> Apache Tomcat 8.5.23 Centos 7.4 (3.10.0-514.16.1.el7.x86_64) Java
>> 1.8.0_152 (with jce) Running in Docker Container
>>
>> I'm upgrading our applications from Apache Tomcat 8.0.47 to
>> 8.5.23, but when trying to get TLS/SSL working on a connector I get
>> the following error:
>>
>> 22-Nov-2017 11:52:46.098 SEVERE [main]
>> org.apache.coyote.AbstractProtocol.init Failed to initialize end
>> point associated with ProtocolHandler ["https-jsse-nio2-18443"]
>> java.lang.IllegalArgumentException:
>> java.security.InvalidAlgorithmParameterException: the trustAnchors
>> parameter must be non-empty at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
> actJsseEndpoint.java:115)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJs
> seEndpoint.java:86)
>> at
>> org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:9
> 82)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpo
> int.java:245)
>>
>>
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
>> at
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Pro
> tocol.java:66)
>>
>>
> at org.apache.catalina.connector.Connector.initInternal(Connector.java:9
> 97)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>
>>
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.ja
> va:549)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>
>>
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java
> :875)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>
>>
> at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:644) at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62)
>>
>>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498) at
>> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311) at
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>> Caused by: java.security.InvalidAlgorithmParameterException: the
>> trustAnchors parameter must be non-empty at
>> java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:
> 200)
>>
>>
> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
>> at
>> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.
> java:130)
>>
>>
> at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:
> 368)
>> at
>> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.jav
> a:292)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstrac
> tJsseEndpoint.java:113)
>> ... 20 more
>>
>> I've changed the connector configuration to use
>> SSLHostConfig/Certificate, but our certificate generation process
>> (self signed certificates) has remained the same. I did a quick
>> internet search, and saw that other people had similar, but not
>> exact issues, and going back to 8.5.4 "solved" the issue. So I did
>> this as a quick test, so at least I could see that our
>> configuration changes where correct, and yes the application ran ok
>> with Tomcat 8.5.4. The connector configuration is:
>>
>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>> server="Apache" maxPostSize="10"> > certificateVerification="none" sslProtocol="TLSv1.2"
>> protocols="TLSv1.2"
>> truststoreFile="/usr/local/tomcat/ssl/ca-truststore.p12"
>> truststoreType="PKCS12" truststorePassword="${truststore.pass}"
>> honorCipherOrder="true"
>> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_EC

Re: Trouble with TLS/SSL and Tomcat 8.5.23

[Richard Tearle]

Peter

On 22 November 2017 at 15:08, Peter Kreuser <l...@kreuser.name> wrote:
>
>
>
>
> Richard,
>
>
>
>
>
>> Gesendet: Mittwoch, 22. November 2017 um 14:40 Uhr
>> Von: "Richard Tearle" 
>> <richard.tea...@northgateps.com[mailto:richard.tea...@northgateps.com]>
>> An: users@tomcat.apache.org[mailto:users@tomcat.apache.org]
>> Betreff: Trouble with TLS/SSL and Tomcat 8.5.23
>> Hello
>>
>> Apache Tomcat 8.5.23
>> Centos 7.4 (3.10.0-514.16.1.el7.x86_64)
>> Java 1.8.0_152 (with jce)
>> Running in Docker Container
>>
>> I'm upgrading our applications from Apache Tomcat 8.0.47 to 8.5.23,
>> but when trying to get TLS/SSL working on a connector I get the
>> following error:
>>
>> 22-Nov-2017 11:52:46.098 SEVERE [main]
>> org.apache.coyote.AbstractProtocol.init Failed to initialize end point
>> associated with ProtocolHandler ["https-jsse-nio2-18443"]
>> java.lang.IllegalArgumentException:
>> java.security.InvalidAlgorithmParameterException: the trustAnchors
>> parameter must be non-empty
>> at 
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
>> at 
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
>> at org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
>> at 
>> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:982)
>> at 
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:245)
>> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
>> at 
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66)
>> at org.apache.catalina.connector.Connector.initInternal(Connector.java:997)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at 
>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at 
>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:644)
>> 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.load(Bootstrap.java:311)
>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>> Caused by: java.security.InvalidAlgorithmParameterException: the
>> trustAnchors parameter must be non-empty
>> at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
>> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
>> at 
>> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130)
>> at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:368)
>> at 
>> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:292)
>> at 
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
>> ... 20 more
>>
>> I've changed the connector configuration to use
>> SSLHostConfig/Certificate, but our certificate generation process
>> (self signed certificates) has remained the same. I did a quick
>> internet search, and saw that other people had similar, but not exact
>> issues, and going back to 8.5.4 "solved" the issue. So I did this as a
>> quick test, so at least I could see that our configuration changes
>> where correct, and yes the application ran ok with Tomcat 8.5.4. The
>> connector configuration is:
>>
>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>> maxThreads="150" SSLEnabled="true" scheme="https"
>> secure="true" server="Apache" maxPostSize="10">
>> > sslProtocol="TLSv1.2" protocols="TLSv1.2"
>> truststoreFile="/usr/local/tomcat/ssl/ca-truststore.p12"
>> truststoreType="PKCS12"
>> truststorePassword="${truststore.pass}" honorCipherOrder="true"
>
> The error message says that either the file simply is not there or the cert 

Trouble with TLS/SSL and Tomcat 8.5.23

[Richard Tearle]

Hello

Apache Tomcat 8.5.23
Centos 7.4 (3.10.0-514.16.1.el7.x86_64)
Java 1.8.0_152 (with jce)
Running in Docker Container

I'm upgrading our applications from Apache Tomcat 8.0.47 to 8.5.23,
but when trying to get TLS/SSL working on a connector I get the
following error:

22-Nov-2017 11:52:46.098 SEVERE [main]
org.apache.coyote.AbstractProtocol.init Failed to initialize end point
associated with ProtocolHandler ["https-jsse-nio2-18443"]
 java.lang.IllegalArgumentException:
java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
at org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:982)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:245)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:997)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
at org.apache.catalina.startup.Catalina.load(Catalina.java:644)
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.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
Caused by: java.security.InvalidAlgorithmParameterException: the
trustAnchors parameter must be non-empty
at 
java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
at 
java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130)
at 
org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:368)
at 
org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:292)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
... 20 more

I've changed the connector configuration to use
SSLHostConfig/Certificate, but our certificate generation process
(self signed certificates) has remained the same. I did a quick
internet search, and saw that other people had similar, but not exact
issues, and going back to 8.5.4 "solved" the issue. So I did this as a
quick test, so at least I could see that our configuration changes
where correct, and yes the application ran ok with Tomcat 8.5.4. The
connector configuration is:


   
  

 


Setting javax.net.debug=all in CATALINA_OPTS and viewing the resultant
logging, seems to indicate that the certificate is being loaded, but
not the trust store, with the only truststore loaded coming from:
/opt/jre1.8.0_152/lib/security/cacerts

Best Regards


Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
n

RE: Tomcat on macOS

[Decker, Richard M]

Mark,

> -Original Message-
> From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID]
> Sent: Friday, May 19, 2017 10:44 AM
> To: Tomcat Users List 
> Subject: Re: Tomcat on macOS
> 
> Chris,
> 
> On 5/19/2017 7:33 AM, Christopher Schultz wrote:
> > Israel,
> >
> > On 5/18/17 10:52 AM, Israel Timoteo wrote:
> >> Any comments from the community for ...
> >
> >> 1) What tools is the community using for simultaneous applications
> >> deployment on several servers, let’s say more than 20?
> >
> > I am using neither of these strategies, but...
> >
> > a. FarmWebDeployer [1]
> 
> Doesn't this require a cluster (and therefore multicast)? That becomes
> challenging in a cloud environment where there's no multicast easily
> available.
> 
> > b. Auto-deploy + scp
> 
> This would be nice with a little scripting.
> 
> >
> > Why in the world are you deploying a web application to 20+
> > macos-based servers? Or do you have a Macos client and 20+
> > non-macos-based servers?
> >
> >> 4) Is JAVA_OPTS required?
> >
> > JAVA_OPTS is only required if you require any java opts. Do you
> > require such options? Usually, when people set JAVA_OPTS they really
> > want to set CATALINA_OPTS instead.
> >
> > Hope that helps,
> > -chris
> >
> > [1]
> > http://tomcat.apache.org/tomcat-8.0-doc/config/cluster-deployer.html
> 
> What I do is use Jenkins, Maven, Nexus, and a little Groovy scripting.
> 
> 1. Maven with the Tomcat Maven Plugin [1]
> 
> The WAR file is customized (context.xml) based on the target environment.
> 
> 2. Jenkins
> 
> The build is run by Jenkins, and the build number (with a little 0 padding 
> via a
> Groovy script) is tacked onto the WAR name as app##nn.war.

I don't mean to hijack the thread, but could you expand on this? Could you 
please provide examples of your Groovy scripts?

> 
> This allows the parallel deploy feature to be used [2].
> 
> 3. Nexus
> 
> This is where all of the base artifacts are stored. Nexus 2 is used currently
> since Nexus 3 doesn't have the REST API needed to cleanly interact with the
> Jenkins job via a Groovy script. Maybe I should learn how to write a Nexus
> plugin to get lists of artifact versions via REST . . .
> 
> 4. Groovy scripting
> 
> Groovy is used in Jenkins to do the following:
> 
> a. Query Nexus to get a list of artifact versions b. Prevent non-production
> artifacts from landing on production platforms c. Create the final number for
> parallel deployment
> 
> To expand this to multiple machines, a set of pipeline jobs could be created.
> 
> a. Build the customized WAR for the target environment b. Multiple jobs
> deploy to the servers in the target environment c. Multiple jobs validate the
> deployment d. Final job sends mail to interested parties with success / 
> failure
> 
> I know that's a lot of infrastructure. There are certainly things that could 
> be
> done differently. Ant (with Ivy), or gradle could be used for the builds. A
> different repository manager could be used (other than Nexus). A different
> CI / CD system could be used (other than Jenkins).
> 
> Anything that meets at least the following requirements could be strung
> together.
> 
> a. Reliable place to get the WAR file you need to deploy b. Reliable build
> system that can be automated c. Build system that can deploy to Tomcat d.
> Testing that the deployment actually worked e. Notification
> 
> The end result is that some authorized person can log into Jenkins, select a
> version of an application to deploy, deploy it to the target environment,
> know that it's been successful (or not), and have notifications automatically
> sent out.
> 
> [1] http://tomcat.apache.org/maven-plugin.html
> [2]
> https://tomcat.apache.org/tomcat-8.0-
> doc/config/context.html#Parallel_deployment
> 
> . . . just my (rather lengthy) 2 cents
> /mde/

Re: how to upgrade tomcat 8.5.x?

[Richard Huntrods]

On 16/05/2017 17:18, Igal @ Lucee.org wrote:

On 5/16/2017 8:27 AM, Kreuser, Peter wrote:


I'd say a more robust (and the documented way) is to use a 
Tomcat-Home directory and a Tomcat-Base Directory.


$CATALINA_HOME holds the actual distributed Tomcat-"Binaries" 
(ZIP/TGZ),

$CATALINA_BASE holds your adapted config, libs and webapps.

This way you can just exchange the CATALINA_HOME with a new version 
(say 8.5.15) and restart Tomcat. In case there are differences in 
configs between versions, adapt your conf using 
https://tomcat.apache.org/migration-85.html#Tomcat_8.5.x_configuration_file_differences 



I agree that separating the CATALINA_HOME from CATALINA_BASE is a 
much better setup, but if Tomcat was not set up like that already 
then for a minor upgrade this complicates the process.


The simplest way to upgrade is the one I documented.


That simple approach is incomplete. It assumes that:
a) the JARs in $CATALINA_HOME/bin haven't changed
b) the names of the JARs in $CATALINA_HOME/lib haven't changed
c) no configuration changes are required.

a) sometimes happens

b) happens when the JDT compiler is updated

c) can be checked via the migration guides

Mark



Well, I just upgraded my servers from Tomcat 8..5.12 to 8.5.14. The 
complex way is to create a new tomcat directory for the new version, 
then rename webapps to webapps.orig and create a new webapps directory 
to hold my war files. Then compare all the config files and make 
appropriate changes to the stock config files, then test. This takes a 
while.


So for the minor change from 12 to 14, I decided to try a new way. On my 
windows devel box, I unzipped a new download of 12 and a new download of 
14 into their own new directories, then compared all the files in both 
(yay for the ancient program "windiff").  I then built a batch file to 
copy only the changed files and tested this. Once satisfied, I built a 
shell script to make the same changes on my devel unix server, and 
tested this. Once I was sure it worked without any problems, I ported 
the script (and virgin 8.5.14 directory) to my production servers. On 
scheduled maintenance I shut down each tomcat 12, ran the script and 
then restarted tomcat. All worked perfectly.


Here's the file changes from 8.5.12 to 8.5.14, no including the changes 
to "webapps" which I don't use:



#!/bin/sh
#
# update files in tomcat 8.5.12 to 8.5.14
#
# when done, rename apache-tomcat-8.5.12 to apache-tomcat-8.5.14
# then fix the symbolic link and restart tomcat
#

cp ./apache-tomcat-8.5.14/RELEASE-NOTES ../apps/apache-tomcat-8.5.12
cp ./apache-tomcat-8.5.14/bin/bootstrap.jar 
../apps/apache-tomcat-8.5.12/bin
cp ./apache-tomcat-8.5.14/bin/tomcat-juli.jar 
../apps/apache-tomcat-8.5.12/bin
cp ./apache-tomcat-8.5.14/lib/annotations-api.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-ant.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-ha.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-storeconfig.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-tribes.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina.jar 
../apps/apache-tomcat-8.5.12/lib

cp ./apache-tomcat-8.5.14/lib/el-api.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jasper-el.jar 
../apps/apache-tomcat-8.5.12/lib

cp ./apache-tomcat-8.5.14/lib/jasper.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jaspic-api.jar 
../apps/apache-tomcat-8.5.12/lib

cp ./apache-tomcat-8.5.14/lib/jsp-api.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/servlet-api.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-api.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-coyote.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-dbcp.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-es.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-fr.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-ja.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-jdbc.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-jni.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-util-scan.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-util.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-websocket.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/websocket-api.jar 
../apps/apache-tomcat-8.5.12/lib




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

RE: BackupManager Heterogeneous Environment / Functionality?

[Decker, Richard M]

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, May 05, 2016 4:26 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: BackupManager Heterogeneous Environment / Functionality?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Richard,

On 5/5/16 3:29 PM, Decker, Richard M wrote:
> I'm trying to configure & demo an Apache Tomcat [v8] cluster env, that 
> supports different apps functioning on different systems.
> 
> Basically, I'm trying to setup an environment where an app can be on 
> only 1 or 2 (deployed or running) out of the 3 Tomcat systems in the 
> cluster. However, this does not seem to work for me, as I can't get 
> away from the 404s when Apache HTTPD goes to a random (round robin) 
> Tomcat system, that does not have the application (running or 
> deployed) on it.

The one thing you forgot to post was your JkMounts from httpd.conf (or 
similar). Can you post those? I believe this can be entirely solved with a 
slightly more complicated configuration.

Chris, 

Thanks for the quick reply. The info you requested is below. The config is 
identical (minus machine names) on the 2 apache httpd systems.

[httpd.conf] equivalent - All JkUn/Mounts


# All requests go to tomcattest by default
JkMount /* acttomcattest
# examples:
# Static files in the examples webapp are served by apache
#Alias /examples /tomcat/webapps/examples
# here we serve the generic default page via apache instead of tomcat
JkUnMount / tomcattest
JkUnMount /index.html tomcattest
JkUnMount /logo.gif  tomcattest
# Serve gif using httpd
#JkUnMount /*.gif  tomcattest


JkMount /status statustest


> This happens with both new & cached sessions. I can bring an entire 
> Tomcat system down, and it works as designed, but not for (stopped or 
> undeployed) single applications. I'm really not sure how Tomcat and 
> Apache are supposed to communicate with each other in this regard; so 
> they know what apps are deployed/running on each system. Is this even 
> possible?

Yep. You just need to tell your load-balancer about which applications can be 
found where.

So you're suggesting that I list every app in the apache/httpd config, or just 
those that won't be deployed across the whole (3 system) env?  Sound promising 
, but problematic of having to restart the Apache service, whenever a change is 
made.

> According to the link below, it should work...
> 
> http://tomcat.apache.org/tomcat-8.0-doc/config/cluster-manager.html
>
>
>
> 
The org.apache.catalina.ha.session.BackupManager also replicates
> deltas but only to one backup node. The location of the backup node is 
> known to all nodes in the cluster. It also supports heterogeneous 
> deployments, so the manager knows at what locations the web 
> application is deployed.
> 
>  Env - Top Down 
> 
> [Load Balancer] - (Sticky Sessions) | [HTTPD1] - [HTTPD2] - (Load 
> Balanced, Sticky Sessions) | [Tomcat1] - [Tomcat2] - [Tomcat3] -
> (BackupManager)

Okay.

>  Config 
> 
> [HTTPD] worker.list=tomcattest, statustest
> 
> worker.tomcat1.type=ajp13 worker.tomcat1.host=tomcat1 
> worker.tomcat1.port= #worker.tomcat1.lbfactor=5
> 
> worker.tomcat2.type=ajp13 worker.tomcat2.host=tomcat2 
> worker.tomcat2.port= #worker.tomcat2.lbfactor=5
> 
> worker.tomcat3.type=ajp13 worker.tomcat3.host=tomcat3 
> worker.tomcat3.port= #worker.tomcat3.lbfactor=5
> 
> worker.tomcattest.type=lb
> worker.tomcattest.balance_workers=tomcat1,tomcat2,tomcat3
> worker.tomcattest.sticky_session=True # lb methods: [R]equest, 
> [S]ession, [T]raffic, [B]usiness worker.tomcattest.method=R 
> worker.statustest.type=status

If you define more than one lb worker, you can do this in a more nuanced way. 
For example:

worker.tomcat1.host=tomcat1
worker.tomcat1.port=

worker.tomcat2.host=tomcat2
worker.tomcat2.port=

worker.tomcat3.host=tomcat3
worker.tomcat3.port=

worker.app-a.type=lb
worker.app-a.balance_workers=tomcat1,tomcat2
worker.app-a.sticky_session=True

worker.app-a.type=lb
worker.app-a.balance_workers=tomcat2,tomcat3
worker.app-a.sticky_session=True

Then, in httpd.conf:

JkMount /app-a/*   app-a
JkMount /app-b/*   app-b

I think I follow you here.

You can just deploy the applications wherever you want them.

Now, how do you deploy them everywhere but then allow one of them to be taken 
out of service without taking-down the whole Tomcat instance?

Tomcat app manager - stopping the application. Or removing/deleting/ 
undeploying the application itself while Tomcat is (hot) running. This will 
most likely break the config for Apache <-> Tomcat though?

There are several ways of doing that which I'll summarize, here. L

BackupManager Heterogeneous Environment / Functionality?

[Decker, Richard M]

ASF Tomcat Members,

I'm trying to configure & demo an Apache Tomcat [v8] cluster env, that supports 
different apps functioning on different systems. Basically, I'm trying to setup 
an environment where an app can be on only 1 or 2 (deployed or running) out of 
the 3 Tomcat systems in the cluster. However, this does not seem to work for 
me, as I can't get away from the 404s when Apache HTTPD goes to a random (round 
robin) Tomcat system, that does not have the application (running or deployed) 
on it. This happens with both new & cached sessions. I can bring an entire 
Tomcat system down, and it works as designed, but not for (stopped or 
undeployed) single applications. I'm really not sure how Tomcat and Apache are 
supposed to communicate with each other in this regard; so they know what apps 
are deployed/running on each system. Is this even possible? According to the 
link below, it should work...

http://tomcat.apache.org/tomcat-8.0-doc/config/cluster-manager.html
The org.apache.catalina.ha.session.BackupManager also replicates deltas but 
only to one backup node. The location of the backup node is known to all nodes 
in the cluster. It also supports heterogeneous deployments, so the manager 
knows at what locations the web application is deployed.


Env - Top Down


[Load Balancer] - (Sticky Sessions)
|
[HTTPD1] - [HTTPD2] - (Load Balanced, Sticky Sessions)
|
[Tomcat1] - [Tomcat2] - [Tomcat3] - (BackupManager)

--
Stats
--

[HTTPD] X 2
Server version: Apache/2.4.18 (Unix)
Server built:   Dec 21 2015 14:42:09

[Tomcat] X 3
Server version: Apache Tomcat/8.0.33
Server built:   Mar 18 2016 20:31:49
Server number:  8.0.33.0
OS Name:Linux
OS Version: 3.10.0-327.4.4.el7.x86_64
Architecture:   amd64
JVM Version:1.8.0_77-b03
JVM Vendor: Oracle Corporation

[Linux] X 3 Tomcat Systems
IPv6/IPv4 Group Memberships
Interface   RefCnt Group
--- -- -
lo  1  all-systems.mcast.net
eth01  228.0.0.4
eth01  all-systems.mcast.net
eth11  all-systems.mcast.net


Config


[HTTPD]
worker.list=tomcattest, statustest

worker.tomcat1.type=ajp13
worker.tomcat1.host=tomcat1
worker.tomcat1.port=
#worker.tomcat1.lbfactor=5

worker.tomcat2.type=ajp13
worker.tomcat2.host=tomcat2
worker.tomcat2.port=
#worker.tomcat2.lbfactor=5

worker.tomcat3.type=ajp13
worker.tomcat3.host=tomcat3
worker.tomcat3.port=
#worker.tomcat3.lbfactor=5

worker.tomcattest.type=lb
worker.tomcattest.balance_workers=tomcat1,tomcat2,tomcat3
worker.tomcattest.sticky_session=True
# lb methods: [R]equest, [S]ession, [T]raffic, [B]usiness
worker.tomcattest.method=R
worker.statustest.type=status

[tomcat] X3 - server.xml

























-
Cluster Basics
-

All your session attributes must implement java.io.Serializable - Done

Uncomment the Cluster element in server.xml - Done

If you have defined custom cluster valves, make sure you have the 
ReplicationValve defined as well under the Cluster element in server.xml - N/A

If your Tomcat instances are running on the same machine, make sure the 
Receiver.port attribute is unique for each instance, in most cases Tomcat is 
smart enough to resolve this on it's own by autodetecting available ports in 
the range 4000-4100 - N/A

Make sure your web.xml has the  element - Done

If you are using mod_jk, make sure that jvmRoute attribute is set at your 
Engine  and that the jvmRoute 
attribute value matches your worker name in workers.properties - Done

Make sure that all nodes have the same time and sync with NTP service! - Done

Make sure that your loadbalancer is configured for sticky session mode - Done



Thanks for reading!

Re: Tomcat 7: wrong realm being used?

[richard]

On 2016-04-17 14:29, Konstantin Kolinko wrote:

2016-04-17 15:26 GMT+03:00  <rich...@xentu.com>:
I posted this same query at stackoverflow a couple of days back, but 
with no

response, although I've simplified the issue very slightly since then.

http://stackoverflow.com/questions/36653744/tomcat-7-wrong-realm-being-used

I have a realm defined in server.xml:


  

  

  


and two web applications, both inside the webapps folder on the tomcat
server, with identical security settings in their web.xml files:


  test-role



  
Memory Realm
/*
  
  
test-role
  



  BASIC



However, one application uses the JDBCRealm, as I'd expect, while the 
other

uses conf/tomcat-users.xml.
Looking at the postgresql logs, the second application never even 
queries

the database.

I can't see anything different in the two configurations. Without any
declaration of a UserDatabaseRealm I don't
see how any applications would get to look at tomcat-users.xml.

I'm wondering if anyone here could help me diagnose what's wrong.



1. Full Tomcat version = ?

(Per mailinglist rules,
http://tomcat.apache.org/lists.html#tomcat-users
-> 1.)

2. The problem is odd. I do not remember similar reports.


no META-INF/context.xml


The context file can also be in 
${catalina.base}/conf/${engineName}/${hostName}/

being a file named ${appName}.xml [1]

3. You can dump effective web.xml by setting logEffectiveWebXml="true"
on Context [1]

4. You can copy your misbehaving web application and  try to simplify
it until you can isolate your issue.

5. You can try debugging [2].

Possible place for a breakpoint:
org.apache.catalina.authenticator.AuthenticatorBase#invoke()
// Realm realm = this.context.getRealm();

6. Generally, I do not like JDBCRealm as it uses a single database
connection. The recommended alternative is DataSourceRealm [3]

[1]
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context

[2] https://wiki.apache.org/tomcat/FAQ/Developing#Debugging

[3] http://tomcat.apache.org/tomcat-7.0-doc/config/realm.html

Best regards,
Konstantin Kolinko




Thanks for your various pointers Konstantin,


1. Full Tomcat version


Apologies! Apache Tomcat/7.0.55 on Windows Server 2012 R2.

I'd been following your suggestion 4, simplifying to try & isolate the 
cause.


Anyway, the problem has now vanished. As far as I know, the only thing I 
did differently was to edit the project locally in eclipse & re-upload 
the war. Previously, I'd been editing in situ on the Tomcat server & 
then restarting the service.


I'm assuming that all Tomcat's configuration is reloaded from scratch on 
a service restart, so I don't know why I saw the previous behaviour.


Regards
Richard



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

Tomcat 7: wrong realm being used?

[richard]

I posted this same query at stackoverflow a couple of days back, but 
with no response, although I've simplified the issue very slightly since 
then.


http://stackoverflow.com/questions/36653744/tomcat-7-wrong-realm-being-used

I have a realm defined in server.xml:


  autoDeploy="true" deployIgnore="^welcome.*">
failureCount="3" lockOutTime="3600">

  

  


and two web applications, both inside the webapps folder on the tomcat 
server, with identical security settings in their web.xml files:



  test-role



  
Memory Realm
/*
  
  
test-role
  



  BASIC



However, one application uses the JDBCRealm, as I'd expect, while the 
other uses conf/tomcat-users.xml.
Looking at the postgresql logs, the second application never even 
queries the database.


I can't see anything different in the two configurations. Without any 
declaration of a UserDatabaseRealm I don't

see how any applications would get to look at tomcat-users.xml.

I'm wondering if anyone here could help me diagnose what's wrong.

Richard

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

Re: Cors-Filter

[RICHARD DOUST]

> On Feb 26, 2016, at 3:40 PM, Christopher Schultz 
> <ch...@christopherschultz.net> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Jose,
> 
> On 2/26/16 7:08 AM, Jose María Zaragoza wrote:
>> 2016-02-26 9:08 GMT+01:00 RICHARD DOUST <rdo...@mac.com>:
>>> My question is, why doesn't it work, or, how can I debug it?
>> 
>> Are you tested to allow to all origins (default option) ? Only for 
>> testing purpose, I mean:
>> 
>> cors.allowed.origins 
>> *
>> 
>> At first sight, your settings should work, but ...
> 
> This is exactly what I was going to suggest.
> 
> Also, what HTTP METHOD are you actually using? POST?

POST

> 
> If you are using https://, I would make sure that https:// URLs
> actually appear in your configuration (you only have HTTP URLs).

The origin of the request is http://, that’s why I put it in there. Do I also 
need to put https:// in there? Seems counter-intuitive, but okay.

I’ll try it.

Thanks.

> 
> - -chris
> 
>>> I guess I'm going to have to figure out how to get the code for
>>> org.apache associated with the jar file so that I can see the
>>> source in Eclipse and set a breakpoint. I have read elsewhere
>>> that any http page that attempts to mix in https content is as
>>> insecure as the page that uses http exclusively, being subject to
>>> man in the middle attacks and that once you need https everything
>>> needs to be https, but in a large SPA, that seems to me to mean a
>>> lot of potentially unnecessary overhead. I'd like to know what
>>> some experts think.
>>> 
>>> Thanks
>>> 
>>> Sent from my iPad
>>> 
>>>> On Feb 26, 2016, at 2:42 AM, André Warnier (tomcat)
>>>> <a...@ice-sa.com> wrote:
>>>> 
>>>>> On 25.02.2016 22:59, RICHARD DOUST wrote: Hi,
>>>>> 
>>>>> I’m running Tomcat 7.0. Can’t find the version.bat file, so I
>>>>> don’t know more than that. It’s installed on a Windows
>>>>> computer running Windows Server 2003 DataCenter Edition.
>>>>> (How’s that for refusing to upgrade?) Anyway, it’s a client’s
>>>>> box. I’m trying to migrate an application to JavaScript from
>>>>> GWT, but that’s beside the point. The problem is, I’m unable
>>>>> to send an XMLHttpRequest to this Tomcat instance via https.
>>>>> The site is being served by the same domain, but via http.
>>>>> 
>>>>> I get:
>>>>> 
>>>>> Failed to load resource: Origin http://www.domain.com is not
>>>>> allowed by Access-Control-Allow-Origin.
>>>>> https://www.domain.com/application/api/request XMLHttpRequest
>>>>> cannot load https://www.domain.com/application/api/reqeuest.
>>>>> Origin http://www.domain.com is not allowed by
>>>>> Access-Control-Allow-Origin.
>>>>> 
>>>>> This is an excerpt my web.xml file for the war:
>>>>> 
>>>>>>  CorsFilter 
>>>>>> org.apache.catalina.filters.CorsFilter> 
>>>>>> 
>>>>>> 
> 
>>>>>> cors.allowed.origins 
>>>>>> http://www.domain.com, http://beta.domain.com:8080,
>>>>>> http://localhost:8080  
>>>>>>  cors.allowed.methods 
>>>>>> GET,POST,HEAD,OPTIONS,PUT 
>>>>>>  
>>>>>> 
>>>>>>  CorsFilter 
>>>>>> /api/* 
>>>>> 
>>>>> 
>>>>> I’d like to debug this, but I don’t know how to go about it.
>>>>> Am I suffering from a basic misunderstanding? Does cors not
>>>>> allow http to https? Anyway, any help would be appreciated.
>>>>> 
>>>> 
>>>> Honestly, I don't know much about CORS, but I looked at the
>>>> specs, here : http://tools.ietf.org/html/rfc6454 (*) and it
>>>> seems to me indeed that in 3.2, Q: Why not just use the host?, 
>>>> it indeed says that the scheme "http" or "https", is part of
>>>> the origin. I interpret this as meaning that if the HTML page
>>>> was obtained from "http://www.domain.com;, a call made from
>>>> within it, to "https://www.domain.com; would not qualify as
>>>> "from the same origin".
>>>> 
>>>> Further in 3.2.1, it gives some examples :
>>>> 
>>>> Each of the following resources has a dif

Re: Cors-Filter

[RICHARD DOUST]

There's no doubt in my mind that this is considered a cross-domain request. The 
question is, why is it not being allowed given the configuration. The domain 
that requested the original page (via http) is specifically set to be allowed 
to access the site in a cross-domain scenario.
My question is, why doesn't it work, or, how can I debug it?
I guess I'm going to have to figure out how to get the code for org.apache 
associated with the jar file so that I can see the source in Eclipse and set a 
breakpoint.
I have read elsewhere that any http page that attempts to mix in https content 
is as insecure as the page that uses http exclusively, being subject to man in 
the middle attacks and that once you need https everything needs to be https, 
but in a large SPA, that seems to me to mean a lot of potentially unnecessary 
overhead. I'd like to know what some experts think.

Thanks

Sent from my iPad

> On Feb 26, 2016, at 2:42 AM, André Warnier (tomcat) <a...@ice-sa.com> wrote:
> 
>> On 25.02.2016 22:59, RICHARD DOUST wrote:
>> Hi,
>> 
>> I’m running Tomcat 7.0. Can’t find the version.bat file, so I don’t know 
>> more than that. It’s installed on a Windows computer running Windows Server 
>> 2003 DataCenter Edition. (How’s that for refusing to upgrade?) Anyway, it’s 
>> a client’s box. I’m trying to migrate an application to JavaScript from GWT, 
>> but that’s beside the point. The problem is, I’m unable to send an 
>> XMLHttpRequest to this Tomcat instance via https. The site is being served 
>> by the same domain, but via http.
>> 
>> I get:
>> 
>> Failed to load resource: Origin http://www.domain.com is not allowed by 
>> Access-Control-Allow-Origin.   
>> https://www.domain.com/application/api/request
>> XMLHttpRequest cannot load https://www.domain.com/application/api/reqeuest. 
>> Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin.
>> 
>> This is an excerpt my web.xml file for the war:
>> 
>>>
>>>CorsFilter
>>>org.apache.catalina.filters.CorsFilter
>>>
>>>cors.allowed.origins
>>> http://www.domain.com, 
>>> http://beta.domain.com:8080, http://localhost:8080
>>> 
>>>
>>>cors.allowed.methods
>>>GET,POST,HEAD,OPTIONS,PUT
>>>
>>>  
>>> 
>>>
>>> CorsFilter
>>> /api/*
>>>
>> 
>> 
>> I’d like to debug this, but I don’t know how to go about it. Am I suffering 
>> from a basic misunderstanding? Does cors not allow http to https? Anyway, 
>> any help would be appreciated.
>> 
> 
> Honestly, I don't know much about CORS, but I looked at the specs, here :
> http://tools.ietf.org/html/rfc6454 (*)
> and it seems to me indeed that in
> 3.2, Q: Why not just use the host?,
> it indeed says that the scheme "http" or "https", is part of the origin.
> I interpret this as meaning that if the HTML page was obtained from 
> "http://www.domain.com;, a call made from within it, to 
> "https://www.domain.com; would not qualify as "from the same origin".
> 
> Further in 3.2.1, it gives some examples :
> 
> Each of the following resources has a different origin from the
>   others.
> 
>   http://example.com/
>   http://example.com:8080/
>   http://www.example.com/
>   https://example.com:80/
>   https://example.com/
>   http://example.org/
> 
> 
> (*) pointed at by the on-line Tomcat documentation :
> https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter
> -> cors.allowed.origins -> "origin"
> 
> 
> -
> 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

Cors-Filter

[RICHARD DOUST]

Hi,

I’m running Tomcat 7.0. Can’t find the version.bat file, so I don’t know more 
than that. It’s installed on a Windows computer running Windows Server 2003 
DataCenter Edition. (How’s that for refusing to upgrade?) Anyway, it’s a 
client’s box. I’m trying to migrate an application to JavaScript from GWT, but 
that’s beside the point. The problem is, I’m unable to send an XMLHttpRequest 
to this Tomcat instance via https. The site is being served by the same domain, 
but via http.

I get:

Failed to load resource: Origin http://www.domain.com is not allowed by 
Access-Control-Allow-Origin.   
https://www.domain.com/application/api/request
XMLHttpRequest cannot load https://www.domain.com/application/api/reqeuest. 
Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin.

This is an excerpt my web.xml file for the war:

>   
>   CorsFilter
>   
> org.apache.catalina.filters.CorsFilter
>   
>   cors.allowed.origins
>http://www.domain.com, 
> http://beta.domain.com:8080, http://localhost:8080
>   
>   
>   cors.allowed.methods
>   GET,POST,HEAD,OPTIONS,PUT
>   
>   
> 
>   
> CorsFilter
> /api/*
>   


I’d like to debug this, but I don’t know how to go about it. Am I suffering 
from a basic misunderstanding? Does cors not allow http to https? Anyway, any 
help would be appreciated.

Thanks,
Richard

users@tomcat.apache.org

[richard]

I have several webapps on tomcat, and in ROOT I have a login.jsp and 
login-error.jsp.


Is it possible to have that one login jsp referenced by the 
 elements of other webapps on the same server? If so, 
how would I reference it?



  ???/login.jsp
  ???/login-error.jsp


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

RE: 1catalina.org.apache.juli.FileHandler

[richard]

On 2016-02-05 19:04, Caldarale, Charles R wrote:

From: rich...@xentu.com [mailto:rich...@xentu.com]
Subject: 1catalina.org.apache.juli.FileHandler



I'm trying to understand logging.properties.


Make sure you carefully read this first:
http://tomcat.apache.org/tomcat-8.0-doc/logging.html


Should I have jar on my system somewhere containing
1catalina.org.apache.juli.FileHandler?


Not exactly.  The 1catalina is a prefix, as noted by this line in the 
above doc:


"A prefix may be added to handler names, so that multiple handlers of
a single class may be instantiated. A prefix is a String which starts
with a digit, and ends with '.'. For example, 22foobar. is a valid
prefix."

 - Chuck



Ah, I see.
Thanks for your help Chuck.

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

1catalina.org.apache.juli.FileHandler

[richard]

I'm trying to understand logging.properties.

Should I have jar on my system somewhere containing
1catalina.org.apache.juli.FileHandler?

If so, other than asking!, how would I go about finding what jar a 
particular class would be in? I've tried this tool:


https://github.com/javalite/jar-explorer

but it doesn't reveal 1catalina's location. Seems an odd class name.

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

Tomcat 8 - server.xml Not Updating

[Richard Morey]

Hi --

I have just installed Tomcat 8 on Windows 2008 R2. I go into the host 
manager and add two virtual hosts. However, the server.xml file does not 
get updated. When I restart the Tomcat service the two virtual hosts no 
longer appear in the host manager web UI.


Additionally, if I manually add hosts to the server.xml file they do not 
appear either.


It appears as though Tomcat is neither reading nor writing to this file, 
however, when I tried renaming it Tomcat - as expected - would not 
start.


Has anyone else run into this problem? Can anyone offer a solution?

Thanks

Rich

Session replication/fail-over for medium sized tomcat farm

[Charles Richard]

Hi,

We are currently using a product called Terracotta to do session
fail-over/replication but are considering moving away from this product as
it doesn't seem to support Java 7 and Tomcat 7.

What products exist out there that would help with session
fail-over/replication?  I only know of 3:

- Terracotta
- Hazelcast
- Tomcat native session failover (is not recommended for many tomcat nodes)

I want to make sure i know all options before making a decision.

Thanks,
Charles

Re: Session replication/fail-over for medium sized tomcat farm

[Charles Richard]

On Fri, Jul 3, 2015 at 9:58 AM, Daniel Mikusa dmik...@pivotal.io wrote:

 On Fri, Jul 3, 2015 at 8:36 AM, Charles Richard 
 charle...@thelearningbar.com wrote:

  Hi,
 
  We are currently using a product called Terracotta to do session
  fail-over/replication but are considering moving away from this product
 as
  it doesn't seem to support Java 7 and Tomcat 7.
 
  What products exist out there that would help with session
  fail-over/replication?  I only know of 3:
 
  - Terracotta
  - Hazelcast
  - Tomcat native session failover (is not recommended for many tomcat
 nodes)
 

 I think that recommendation is just for the DeltaManager.  You can use the
 BackupManager with larger numbers of nodes since it's not replicating
 session data to all of the nodes in the cluster.

 http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-manager.html

 In addition to that Redis and Memcached are two popular ways of sharing
 session state.

 Dan

  In the link you sent, it mentions the following:

Downside of the BackupManager: not quite as battle tested as the delta
manager. 

Are you aware of companies using this for their Tomcat farms?

Thanks,
Charles


 
  I want to make sure i know all options before making a decision.
 
  Thanks,
  Charles
 

How to force Tomcat to use the system clock?

[Salisbury, Richard W DLA CTR INFORMATION OPERATIONS]

Greetings,

We have found a need to stop and start Tomcat once in a while to allow
Tomcat to connect via HTTPS with some other servers.  We think the
restart may be synchronizing the time Tomcat uses with the server OS
system time, and we are looking for ways to prevent having to stop/start
Tomcat.

Details:
Our instance of Tomcat 6.0.36 runs on HP-UX B11.31 ia64 with JVM Version
1.7.0.08.  It hosts a custom servlet which, when invoked, connects with
a remote server via HTTPS to retrieve some data.  However, after about a
month the timestamp Tomcat sends in the SSL handshake appears to drift
enough for the remote server's time to start rejecting requests because
the timestamp is too far off (according to our partner's remote
application logs).  

We have confirmed that our server clock is set correctly and synced with
NTP, and matches the system clock on the remote server, which also uses
NTP.  So one thing we thought might be happening is that Tomcat (or the
Java that Tomcat runs on) may be keeping an internal clock, perhaps
using a separate thread as a way to speed up the retrieval of time so
that it does not have to go to the OS system clock every time it needs
the current time.  And maybe this internal clock is not synced with the
server time until Tomcat (or the JVM) is restarted.

If this is the case, would anyone have an idea of how to force Tomcat
(or Java) to use the server's system clock every time instead of using
its own internal clock?   We do not care about the performance hit on
this because this is a low-volume application.  Or, if we are
misunderstanding Tomcat and it actually uses the system clock every time
it needs to get the current time, is there something else we should be
looking at?

We have researched on the web, checked the Apache mail archives, read
the Tomcat configuration guide, looked up the Java system options, but
have not studied the Tomcat source code yet.  We did find that there is
a Java Wrapper product out there by Tanuki Software that provides an
option to use system time or a background thread, which is what caused
us to wonder if Tomcat might be doing something similar.

For more information on what the Tanuki wrapper does, here is an excerpt
we found on their website
http://wrapper.tanukisoftware.com/doc/english/prop-use-system-time.html:
As of Wrapper version 3.1.0, a new timer mechanism was added to the
Wrapper. This new timer was made the default in Wrapper version 3.2.0.
Rather than keeping time by querying the system clock, the Wrapper
creates a background thread which enters a light weight loop and
increments an internal tick counter.  Internally all timekeeping has
been modified to be based on these ticks. (If the system time is being
used, then the tick count at any particular moment is calculated from
the system time rather than from the counter.) 

Thanks in advance for any ideas that are shared. 
Richard


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

Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden

[RICHARD DOUST]

After getting the debugging worked out I found that, even though I thought I'd 
removed the Cors Filter, it was still being invoked. Not sure why, but that's 
different issue that I'll look into later. The Cors Filter was denying access 
to the resource. I had thought that the Cors Filter was there to check for 
cross domain requests, but it appears that it's checking all requests. Even 
though this particular request is not cross domain, the filter was not 
configured to allow the origin (because I didn't think I needed to), so it 
denied access based on origin. 

Thanks for your help in resolving the issue Konstantin.

Richard
 
 On Feb 9, 2015, at 2:12 PM, RICHARD DOUST rdo...@me.com wrote:
 
 I have removed the CORS Filter from the web.xml, redeployed, and the behavior 
 is the same. Still get the 403 Forbidden return code.
 
 The instructions on that web site say that I should attach source to the jar 
 file for Tomcat. It's not clear to me how to do that. How do I select the jar 
 file? It's running remotely.
 
 Thanks,
 Richard
 
 On Feb 9, 2015, at 10:47 AM, RICHARD DOUST rdo...@me.com wrote:
 
 Ok. Found the archives for source. Now all I've got to do is figure out how 
 to get Eclipse to look at the source when I'm running Tomcat remotely. I'll 
 review that page you sent the link to.
 
 Richard
 
 On Feb 9, 2015, at 10:14 AM, RICHARD DOUST rdo...@me.com wrote:
 
 We are running 7.0.57. I have not tried to debug yet, but am willing to 
 give it a try. I have gone to the apache site to download the source for 
 that version but can only find 7.0.59. If you can tell me how to get the 
 source for 7.0.57, I'll take it down, otherwise, I'll update the executable 
 and use the source for 7.0.59.
 
 I will try removing the CORS filter from the deployment and see if that 
 changes the behavior. I'll update this thread when I know the results.
 
 Thanks for your input.
 
 Richard
 
 On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko knst.koli...@gmail.com 
 wrote:
 
 2015-02-06 23:30 GMT+03:00 RICHARD DOUST rdo...@me.com 
 mailto:rdo...@me.com:
 Hi,
 
 I've got an application that ran well with Tomcat 6.0, but is causing me 
 problems on Tomcat 7.0. The front end is IIS (listening on port 80, 
 passing requests to the isapi_redirect (1.2.40) filter which is 
 configured to send some urls on to ajp13, then to port 8009 were Tomcat 
 is listening), all running on Windows Server 2003.
 
 I know the isapi filter is working because I've configured mappings to 
 the Tomcat docs and manager web apps and can get to them without any 
 problems (via IIS).
 
 I have a servlet deployed to Tomcat that I'm POSTing to via an 
 XMLHttpRequest in a browser. For the life of me, I cannot get it to 
 respond to me with anything but a 403 and I can't figure out why. It is 
 not a cross-domain request, so a CORS Filter (which is installed in 
 support of a rewrite of the application which is underway) can't be 
 having any effect. I have added an init-param to the servlet definition 
 in the web.xml to make sure that it's not an issue having to do with the 
 fact that it's a POST:
 
 servlet
 ,
 .
 .
 init-param
 param-namereadonly/param-name
 param-valuefalse/param-value
 /init-param
 /servlet
 
 
 In the isapi_redirect.log I can see that the request is being passed to 
 the ajp13 connector. The request is well formed. Everything is as it 
 should be. The war file is configured as it was configured with Tomcat 
 6.0, in terms of its deployment descriptor with the above minor 
 difference. Here is an excerpt from the isapi_redirect log with the 
 request itself preceding what's shown here:
 
 00 00 00  - ManagerRqst  (Tail end of request XML)
 [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from 
 ajp13 pos=0 len=38 max=8192
 [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 
 00 09 46 6F 72 62 69 64 64 65 6E 00 00  - .Forbidden..
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 
 00 0A 74 65 78 74 2F 70 6C 61 69 6E 00  - .text/plain.
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 
 01 30 00 00 00 00 00 00 00 00 00 00 00  - 0...
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (705): status = 403
 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2
 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = 
 [text/plain]
 [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] 
 = [0]
 [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug

Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden

[RICHARD DOUST]

We are running 7.0.57. I have not tried to debug yet, but am willing to give it 
a try. I have gone to the apache site to download the source for that version 
but can only find 7.0.59. If you can tell me how to get the source for 7.0.57, 
I'll take it down, otherwise, I'll update the executable and use the source for 
7.0.59.

I will try removing the CORS filter from the deployment and see if that changes 
the behavior. I'll update this thread when I know the results.

Thanks for your input.

Richard

 On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko knst.koli...@gmail.com wrote:
 
 2015-02-06 23:30 GMT+03:00 RICHARD DOUST rdo...@me.com 
 mailto:rdo...@me.com:
 Hi,
 
 I've got an application that ran well with Tomcat 6.0, but is causing me 
 problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing 
 requests to the isapi_redirect (1.2.40) filter which is configured to send 
 some urls on to ajp13, then to port 8009 were Tomcat is listening), all 
 running on Windows Server 2003.
 
 I know the isapi filter is working because I've configured mappings to the 
 Tomcat docs and manager web apps and can get to them without any problems 
 (via IIS).
 
 I have a servlet deployed to Tomcat that I'm POSTing to via an 
 XMLHttpRequest in a browser. For the life of me, I cannot get it to respond 
 to me with anything but a 403 and I can't figure out why. It is not a 
 cross-domain request, so a CORS Filter (which is installed in support of a 
 rewrite of the application which is underway) can't be having any effect. I 
 have added an init-param to the servlet definition in the web.xml to make 
 sure that it's not an issue having to do with the fact that it's a POST:
 
 servlet
,
.
.
init-param
param-namereadonly/param-name
param-valuefalse/param-value
/init-param
 /servlet
 
 
 In the isapi_redirect.log I can see that the request is being passed to the 
 ajp13 connector. The request is well formed. Everything is as it should be. 
 The war file is configured as it was configured with Tomcat 6.0, in terms of 
 its deployment descriptor with the above minor difference. Here is an 
 excerpt from the isapi_redirect log with the request itself preceding what's 
 shown here:
 
 00 00 00  - ManagerRqst  (Tail end of request XML)
 [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 
 pos=0 len=38 max=8192
 [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 00 
 09 46 6F 72 62 69 64 64 65 6E 00 00  - .Forbidden..
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 00 
 0A 74 65 78 74 2F 70 6C 61 69 6E 00  - .text/plain.
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 01 
 30 00 00 00 00 00 00 00 00 00 00 00  - 0...
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (705): status = 403
 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2
 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = 
 [text/plain]
 [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = 
 [0]
 [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
 start_response::jk_isapi_plugin.c (1025): Starting response for URI 
 '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1)
 [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
 start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive
 [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 
 pos=0 len=2 max=8192
 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 05 01 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00  - 
 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
 ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK
 [Fri Feb 06 14:08:35.453 2015] [1128:4744] [debug] 
 HttpExtensionProc::jk_isapi_plugin.c (2317): service() returned OK
 [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] 
 ajp_reset_endpoint::jk_ajp_common.c (810): (ajp13) resetting endpoint with 
 socket 2300
 [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] ajp_done::jk_ajp_common.c 
 (3144): recycling connection pool for worker ajp13 and socket 2300
 
 I have a breakpoint set in the servlet's doPost method. It gets hit if I use 
 the rewrite which bypasses IIS and goes direct to port 8080 to hit Tomcat 
 directly. It does not get hit when the request is sent via IIS. I have no 
 insight into what or where the problem

Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden

[RICHARD DOUST]

Ok. Found the archives for source. Now all I've got to do is figure out how to 
get Eclipse to look at the source when I'm running Tomcat remotely. I'll review 
that page you sent the link to.

Richard

 On Feb 9, 2015, at 10:14 AM, RICHARD DOUST rdo...@me.com wrote:
 
 We are running 7.0.57. I have not tried to debug yet, but am willing to give 
 it a try. I have gone to the apache site to download the source for that 
 version but can only find 7.0.59. If you can tell me how to get the source 
 for 7.0.57, I'll take it down, otherwise, I'll update the executable and use 
 the source for 7.0.59.
 
 I will try removing the CORS filter from the deployment and see if that 
 changes the behavior. I'll update this thread when I know the results.
 
 Thanks for your input.
 
 Richard
 
 On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko knst.koli...@gmail.com 
 wrote:
 
 2015-02-06 23:30 GMT+03:00 RICHARD DOUST rdo...@me.com 
 mailto:rdo...@me.com:
 Hi,
 
 I've got an application that ran well with Tomcat 6.0, but is causing me 
 problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing 
 requests to the isapi_redirect (1.2.40) filter which is configured to send 
 some urls on to ajp13, then to port 8009 were Tomcat is listening), all 
 running on Windows Server 2003.
 
 I know the isapi filter is working because I've configured mappings to the 
 Tomcat docs and manager web apps and can get to them without any problems 
 (via IIS).
 
 I have a servlet deployed to Tomcat that I'm POSTing to via an 
 XMLHttpRequest in a browser. For the life of me, I cannot get it to respond 
 to me with anything but a 403 and I can't figure out why. It is not a 
 cross-domain request, so a CORS Filter (which is installed in support of a 
 rewrite of the application which is underway) can't be having any effect. I 
 have added an init-param to the servlet definition in the web.xml to make 
 sure that it's not an issue having to do with the fact that it's a POST:
 
 servlet
   ,
   .
   .
   init-param
   param-namereadonly/param-name
   param-valuefalse/param-value
   /init-param
 /servlet
 
 
 In the isapi_redirect.log I can see that the request is being passed to the 
 ajp13 connector. The request is well formed. Everything is as it should be. 
 The war file is configured as it was configured with Tomcat 6.0, in terms 
 of its deployment descriptor with the above minor difference. Here is an 
 excerpt from the isapi_redirect log with the request itself preceding 
 what's shown here:
 
 00 00 00  - ManagerRqst  (Tail end of request XML)
 [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 
 pos=0 len=38 max=8192
 [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 00 
 09 46 6F 72 62 69 64 64 65 6E 00 00  - .Forbidden..
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 00 
 0A 74 65 78 74 2F 70 6C 61 69 6E 00  - .text/plain.
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 01 
 30 00 00 00 00 00 00 00 00 00 00 00  - 0...
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (705): status = 403
 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2
 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = 
 [text/plain]
 [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = 
 [0]
 [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
 start_response::jk_isapi_plugin.c (1025): Starting response for URI 
 '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1)
 [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
 start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive
 [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 
 pos=0 len=2 max=8192
 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 05 01 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00  - 
 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
 ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK
 [Fri Feb 06 14:08:35.453 2015] [1128:4744] [debug] 
 HttpExtensionProc::jk_isapi_plugin.c (2317): service() returned OK
 [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] 
 ajp_reset_endpoint::jk_ajp_common.c (810): (ajp13) resetting endpoint with 
 socket 2300
 [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] 
 ajp_done::jk_ajp_common.c (3144): recycling connection pool for worker 
 ajp13

Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden

[RICHARD DOUST]

I have removed the CORS Filter from the web.xml, redeployed, and the behavior 
is the same. Still get the 403 Forbidden return code.

The instructions on that web site say that I should attach source to the jar 
file for Tomcat. It's not clear to me how to do that. How do I select the jar 
file? It's running remotely.

Thanks,
Richard

 On Feb 9, 2015, at 10:47 AM, RICHARD DOUST rdo...@me.com wrote:
 
 Ok. Found the archives for source. Now all I've got to do is figure out how 
 to get Eclipse to look at the source when I'm running Tomcat remotely. I'll 
 review that page you sent the link to.
 
 Richard
 
 On Feb 9, 2015, at 10:14 AM, RICHARD DOUST rdo...@me.com wrote:
 
 We are running 7.0.57. I have not tried to debug yet, but am willing to give 
 it a try. I have gone to the apache site to download the source for that 
 version but can only find 7.0.59. If you can tell me how to get the source 
 for 7.0.57, I'll take it down, otherwise, I'll update the executable and use 
 the source for 7.0.59.
 
 I will try removing the CORS filter from the deployment and see if that 
 changes the behavior. I'll update this thread when I know the results.
 
 Thanks for your input.
 
 Richard
 
 On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko knst.koli...@gmail.com 
 wrote:
 
 2015-02-06 23:30 GMT+03:00 RICHARD DOUST rdo...@me.com 
 mailto:rdo...@me.com:
 Hi,
 
 I've got an application that ran well with Tomcat 6.0, but is causing me 
 problems on Tomcat 7.0. The front end is IIS (listening on port 80, 
 passing requests to the isapi_redirect (1.2.40) filter which is configured 
 to send some urls on to ajp13, then to port 8009 were Tomcat is 
 listening), all running on Windows Server 2003.
 
 I know the isapi filter is working because I've configured mappings to the 
 Tomcat docs and manager web apps and can get to them without any problems 
 (via IIS).
 
 I have a servlet deployed to Tomcat that I'm POSTing to via an 
 XMLHttpRequest in a browser. For the life of me, I cannot get it to 
 respond to me with anything but a 403 and I can't figure out why. It is 
 not a cross-domain request, so a CORS Filter (which is installed in 
 support of a rewrite of the application which is underway) can't be having 
 any effect. I have added an init-param to the servlet definition in the 
 web.xml to make sure that it's not an issue having to do with the fact 
 that it's a POST:
 
 servlet
  ,
  .
  .
  init-param
  param-namereadonly/param-name
  param-valuefalse/param-value
  /init-param
 /servlet
 
 
 In the isapi_redirect.log I can see that the request is being passed to 
 the ajp13 connector. The request is well formed. Everything is as it 
 should be. The war file is configured as it was configured with Tomcat 
 6.0, in terms of its deployment descriptor with the above minor 
 difference. Here is an excerpt from the isapi_redirect log with the 
 request itself preceding what's shown here:
 
 00 00 00  - ManagerRqst  (Tail end of request XML)
 [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from 
 ajp13 pos=0 len=38 max=8192
 [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 
 00 09 46 6F 72 62 69 64 64 65 6E 00 00  - .Forbidden..
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 
 00 0A 74 65 78 74 2F 70 6C 61 69 6E 00  - .text/plain.
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 
 01 30 00 00 00 00 00 00 00 00 00 00 00  - 0...
 [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (705): status = 403
 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2
 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = 
 [text/plain]
 [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] 
 ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] 
 = [0]
 [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
 start_response::jk_isapi_plugin.c (1025): Starting response for URI 
 '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1)
 [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
 start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive
 [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from 
 ajp13 pos=0 len=2 max=8192
 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 05 01 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00  - 
 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
 ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK

IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden

[RICHARD DOUST]

Hi,

I've got an application that ran well with Tomcat 6.0, but is causing me 
problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing 
requests to the isapi_redirect (1.2.40) filter which is configured to send some 
urls on to ajp13, then to port 8009 were Tomcat is listening), all running on 
Windows Server 2003.

I know the isapi filter is working because I've configured mappings to the 
Tomcat docs and manager web apps and can get to them without any problems (via 
IIS). 

I have a servlet deployed to Tomcat that I'm POSTing to via an XMLHttpRequest 
in a browser. For the life of me, I cannot get it to respond to me with 
anything but a 403 and I can't figure out why. It is not a cross-domain 
request, so a CORS Filter (which is installed in support of a rewrite of the 
application which is underway) can't be having any effect. I have added an 
init-param to the servlet definition in the web.xml to make sure that it's not 
an issue having to do with the fact that it's a POST:

servlet
,
.
.
init-param
param-namereadonly/param-name
param-valuefalse/param-value
/init-param
/servlet


In the isapi_redirect.log I can see that the request is being passed to the 
ajp13 connector. The request is well formed. Everything is as it should be. The 
war file is configured as it was configured with Tomcat 6.0, in terms of its 
deployment descriptor with the above minor difference. Here is an excerpt from 
the isapi_redirect log with the request itself preceding what's shown here:

00 00 00  - ManagerRqst  (Tail end of request XML)
[Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 
pos=0 len=38 max=8192
[Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 00 09 
46 6F 72 62 69 64 64 65 6E 00 00  - .Forbidden..
[Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 00 0A 
74 65 78 74 2F 70 6C 61 69 6E 00  - .text/plain.
[Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 01 30 
00 00 00 00 00 00 00 00 00 00 00  - 0...
[Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (705): status = 403
[Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2
[Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = 
[text/plain]
[Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = [0]
[Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
start_response::jk_isapi_plugin.c (1025): Starting response for URI 
'/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1)
[Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] 
start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive
[Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 
pos=0 len=2 max=8192
[Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 05 01 00 00 00 
00 00 00 00 00 00 00 00 00 00 00  - 
[Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] 
ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK
[Fri Feb 06 14:08:35.453 2015] [1128:4744] [debug] 
HttpExtensionProc::jk_isapi_plugin.c (2317): service() returned OK
[Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] 
ajp_reset_endpoint::jk_ajp_common.c (810): (ajp13) resetting endpoint with 
socket 2300
[Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] ajp_done::jk_ajp_common.c 
(3144): recycling connection pool for worker ajp13 and socket 2300

I have a breakpoint set in the servlet's doPost method. It gets hit if I use 
the rewrite which bypasses IIS and goes direct to port 8080 to hit Tomcat 
directly. It does not get hit when the request is sent via IIS. I have no 
insight into what or where the problem might be. Somewhere between ajp13 and 
Tomcat.

The application works without a problem if I hit it from a browser running on 
the same computer as is running IIS and Tomcat. It doesn't work if I hit it 
from a client from outside.

I've been banging my head against this for 2 days. Any help would be 
appreciated.

Thanks.

Re: How to get rid of that Tomcat page? Please help!

[Richard Aubry]

Neven

Thank you very much. Your help was invaluable.

I looked at /etc/hosts and found and entry for the site I was trying to reach. 
I removed that entry and all is fine now. How, when and why that line was added 
to the hosts file is a mystery for me. Thank you again.

Richard Aubry

 Le 2014-11-23 à 03:07, Neven Cvetkovic neven.cvetko...@gmail.com a écrit :
 
 Richard,
 
 My apologies, I misread your email. You did try your website from different
 browsers and different computers, an it works ok. My initial response did
 not assume that.
 
 Firstly, Tomcat is a server product that hosts applications. The page you
 are seeing is the default Tomcat page.
 
 Here are few questions:
 - did you setup any proxy servers?
 - did you search your mac for any installed tomcat product (to make sure it
 is coming from your local box)?
 - did you try different browsers (to make sure it is not a cached page)?
 - check your local /etc/hosts file, is your website listed in that file?
 - what happens if you try curl from command line, e.g. curl
 http://yoursite.com? Do you still see tomcat content?
 - if you do nslookup yoursite.com from your computer and other computers,
 is it the same ip address? Try same with ping yoursite.com
 
 Hope that gives us some more information!
 
 Thanks
 Neven
 
 On Nov 23, 2014 8:51 AM, Neven Cvetkovic neven.cvetko...@gmail.com
 wrote:
 
 Richard,
 
 On Nov 23, 2014 6:04 AM, Richard Aubry aubry...@gmail.com wrote:
 
 A few days ago, when I tried to access a web site that I frequently
 access, I obtained an Apache Tomcat page that said: If you're seeing this
 page via a web browser, it means you've set up Tomcat successfully.
 Congratulations!
 
 
 You are seeing a default Tomcat page (i.e. Root application). It seems
 that the website you frequent uses Tomcat. They probably upgraded Tomcat
 incorrectly and used Tomcat default page.
 
 There is nothing wrong with your computer. You could probably email
 website administrators about the problem. It is also likely the problem is
 going to get fixed by the time you see this message :)
 
 Another thing to try - use a different computer, or your phone to access
 this website.
 
 Good luck!
 
 But I have never set up Tomcat, I don't know what is Tomcat and I just
 want to get rid of that thing and to be able to access that web site again.
 I don't know how that thing took control of my Mac. Since that first time,
 I have never been able to access my web site. It's only happening on my
 Mac; on any other computer I can access the site without problems.
 
 Could someone tell me how to get rid of that?
 
 Richard Aubry
 -
 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

How to get rid of that Tomcat page? Please help!

[Richard Aubry]

A few days ago, when I tried to access a web site that I frequently access, I 
obtained an Apache Tomcat page that said: If you're seeing this page via a web 
browser, it means you've set up Tomcat successfully. Congratulations!

But I have never set up Tomcat, I don't know what is Tomcat and I just want to 
get rid of that thing and to be able to access that web site again. I don't 
know how that thing took control of my Mac. Since that first time, I have never 
been able to access my web site. It's only happening on my Mac; on any other 
computer I can access the site without problems.

Could someone tell me how to get rid of that?

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

mod_jk NetworkError: 400 Bad Request - https://xxx.xx.xxx.xxx

[Charles Richard]

Hi,

I am using Apache 2.2.3 with mod_jk 1.2.31 and Tomcat 6.0.30 .

I have never had issues with using mod_jk to connect my Apache requests to
a tomcat instance before now but I am now running into a situation where
Apache requests going to a tomcat instance on another server are giving me
an 400 Bad Request and I can't seem to get more information on why this
is happening.

I turned on debug log level for mod_jk and I see the following:

[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
service::jk_lb_worker.c (1118): service sticky_session=1 id='empty'
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
get_most_suitable_worker::jk_lb_worker.c (1001): found best worker
w1worker1 (w1worker1) using method 'Request'
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
service::jk_lb_worker.c (1161): service worker=w1worker1 route=w1worker1
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_get_endpoint::jk_ajp_common.c (3096): acquired connection pool slot=0
after 0 retries
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_marshal_into_msgb::jk_ajp_common.c (605): ajp marshaling done
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_service::jk_ajp_common.c (2379): processing w1worker1 with 2 retries
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_send_request::jk_ajp_common.c (1572): (w1worker1) all endpoints are
disconnected.
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
jk_open_socket::jk_connect.c (484): socket TCP_NODELAY set to On
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
jk_open_socket::jk_connect.c (608): trying to connect socket 46 to
172.23.1.132:8009
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
jk_open_socket::jk_connect.c (634): socket 46 [172.23.1.133:37865 -
172.23.1.132:8009] connected

[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_send_request::jk_ajp_common.c (1632): (w1worker1) request body to send
0 - request body to resend 0
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1329): received from ajp13
pos=0 len=19 max=8192
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1329): 04 01 90 00
0B 42 61 64 20 52 65 71 75 65 73 74  - .Bad.Request
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1329): 001000 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00  - 
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_unmarshal_response::jk_ajp_common.c (660): status = 400
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_unmarshal_response::jk_ajp_common.c (667): Number of headers is = 0
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1329): received from ajp13
pos=0 len=2 max=8192
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1329): 05 01 00 00
00 00 00 00 00 00 00 00 00 00 00 00  - 
[Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
ajp_process_callback::jk_ajp_common.c (1943): AJP13 protocol: Reuse is OK

In this example, it's trying to connect to a tomcat on another server
listening to port 8009 (172.23.1.132:8009). From the Apache server, I can
telnet to port 8009 on server 172.23.1.132 so I know the port is listening
and not blocked by a firewall.

I'm not really sure what else to try.

Sorry if this is the wrong forum.

Thanks,
Charles

Re: mod_jk NetworkError: 400 Bad Request - https://xxx.xx.xxx.xxx

[Charles Richard]

On Mon, Jul 21, 2014 at 11:39 AM, Daniel Mikusa dmik...@gopivotal.com
wrote:

 On Mon, Jul 21, 2014 at 10:32 AM, Charles Richard 
 charle...@thelearningbar.com wrote:

  Hi,
 
  I am using Apache 2.2.3 with mod_jk 1.2.31 and Tomcat 6.0.30 .
 
  I have never had issues with using mod_jk to connect my Apache requests
 to
  a tomcat instance before now but I am now running into a situation where
  Apache requests going to a tomcat instance on another server are giving
 me
  an 400 Bad Request and I can't seem to get more information on why this
  is happening.
 
  I turned on debug log level for mod_jk and I see the following:
 
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  service::jk_lb_worker.c (1118): service sticky_session=1 id='empty'
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  get_most_suitable_worker::jk_lb_worker.c (1001): found best worker
  w1worker1 (w1worker1) using method 'Request'
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  service::jk_lb_worker.c (1161): service worker=w1worker1 route=w1worker1
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_get_endpoint::jk_ajp_common.c (3096): acquired connection pool slot=0
  after 0 retries
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_marshal_into_msgb::jk_ajp_common.c (605): ajp marshaling done
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_service::jk_ajp_common.c (2379): processing w1worker1 with 2 retries
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_send_request::jk_ajp_common.c (1572): (w1worker1) all endpoints are
  disconnected.
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  jk_open_socket::jk_connect.c (484): socket TCP_NODELAY set to On
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  jk_open_socket::jk_connect.c (608): trying to connect socket 46 to
  172.23.1.132:8009
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  jk_open_socket::jk_connect.c (634): socket 46 [172.23.1.133:37865 -
  172.23.1.132:8009] connected
 
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_send_request::jk_ajp_common.c (1632): (w1worker1) request body to
 send
  0 - request body to resend 0
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_connection_tcp_get_message::jk_ajp_common.c (1329): received from
 ajp13
  pos=0 len=19 max=8192
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_connection_tcp_get_message::jk_ajp_common.c (1329): 04 01 90
 00
  0B 42 61 64 20 52 65 71 75 65 73 74  - .Bad.Request
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_connection_tcp_get_message::jk_ajp_common.c (1329): 001000 00 00
 00
  00 00 00 00 00 00 00 00 00 00 00 00  - 
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_unmarshal_response::jk_ajp_common.c (660): status = 400
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_unmarshal_response::jk_ajp_common.c (667): Number of headers is = 0
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_connection_tcp_get_message::jk_ajp_common.c (1329): received from
 ajp13
  pos=0 len=2 max=8192
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_connection_tcp_get_message::jk_ajp_common.c (1329): 05 01 00
 00
  00 00 00 00 00 00 00 00 00 00 00 00  - 
  [Mon Jul 21 09:57:20 2014] [16825:47908532024176] [debug]
  ajp_process_callback::jk_ajp_common.c (1943): AJP13 protocol: Reuse is OK
 
  In this example, it's trying to connect to a tomcat on another server
  listening to port 8009 (172.23.1.132:8009). From the Apache server, I
 can
  telnet to port 8009 on server 172.23.1.132 so I know the port is
 listening
  and not blocked by a firewall.
 

 The debug logs are showing that it's connecting as well and if it were not,
 you'd get a definitive error in the logs.  The problem you're seeing is
 different.



 The 400 response is from Tomcat or your app.  What do you see on the Tomcat
 / application side of the logs?  Also, what is originating the request and
 what does the request you are sending look like?  Maybe it's legitimately a
 bad request?

 I have found the issue. I was missing an alias directive in Tomcat as I
did not have an alias setup for the web server hitting Tomcat on a
different server. Hopefully this helps someone else with similar issues.


 Dan


 
  I'm not really sure what else to try.
 
  Sorry if this is the wrong forum.
 
  Thanks,
  Charles
 

tomcat heap gc marksweep outage

[Charles Richard]

Hi,

I'm trying to help out my old company who has no IT staff to look at this.
This might be a bad coding issue but I'm hoping to be able to understand
this issue.

They are using Tomcat 6.0.35 and Java 1.6.0_26 . The application is a Java,
hibernate, c3p0 application, not really sure if it is Spring, Struts or
what the Java framework is.

The issue is the site gets unresponsive almost every day. The monitoring
tool shows that the heap reaches its limit and then the GC marksweep kicks
in.

My knowledge about Garbage Collection is not extensive but my understanding
is that once the heap reaches its limit or close to, the GC kicks in and
this is likely what is rendering the site unresponsive.

So my question is: Is there anything I can do with Tomcat to troubleshoot
this further?

Thanks,
Charles

Re: CorsFilter denying some same-origin requests.

[Richard Hart]

Having re-read the specs I can see that trying to match origins by
resolving to IP addresses is not a good idea.

However, that still leaves us with a problem because Chrome sends an
Origin header for some same-origin requests. The CorsFilter denies
these requests if the origin is not in cors.allowed.origins.  We have
too many possible origins to be able to specify them all in the
deployment descriptor (and we don't want to allow all origins).

One solution would be to treat requests as non-CORS when the Origin
and Host headers match (having pre-appended the request scheme to the
Host header).
Do you think that this is something that Apache would consider
incorporating into the CORS filter? This would be preferable to
maintaining our own copy of the filter indefinitely.

Thanks
Richard

On Mon, Mar 10, 2014 at 3:55 PM, Mark Thomas ma...@apache.org wrote:
 On 10/03/2014 14:30, Richard Hart wrote:
 (Tomcat 7.0.50, Linux)

 Having recently enabled CORS support for our Tomcat-based web app
 using the provided CorsFilter, we have discovered a problem where some
 same-origin (i.e. non-CORS) requests from certain browsers (e.g.
 Chrome) are denied.  This is due to the browser setting the Origin
 header even though the request is non-CORS.  it turns out that this is
 in fact legal according to RFC 6454.

 Given the popularity of Tomcat and Chrome I was surprised to find
 little mention of this problem online.  Has anyone else encountered
 this problem?

 Our planned solution is to fork CorsFilter and and modify it to allow
 requests for which the Origin and Host headers both resolve to the
 same IP address.  However, if somebody has already implemented a
 solution for this problem could you please let us know.

 If the Origin and Host headers don't match (even if they do resolve to
 the same IP address) isn't that a cross-origin request? In which case
 isn't the filter doing what it is meant to?

 Why isn't setting the cors.allowed.origins init parameter sufficient?

 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

CorsFilter denying some same-origin requests.

[Richard Hart]

(Tomcat 7.0.50, Linux)

Having recently enabled CORS support for our Tomcat-based web app
using the provided CorsFilter, we have discovered a problem where some
same-origin (i.e. non-CORS) requests from certain browsers (e.g.
Chrome) are denied.  This is due to the browser setting the Origin
header even though the request is non-CORS.  it turns out that this is
in fact legal according to RFC 6454.

Given the popularity of Tomcat and Chrome I was surprised to find
little mention of this problem online.  Has anyone else encountered
this problem?

Our planned solution is to fork CorsFilter and and modify it to allow
requests for which the Origin and Host headers both resolve to the
same IP address.  However, if somebody has already implemented a
solution for this problem could you please let us know..

Thanks
Richard Hart

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