Re: Tomcat 7.082 not starting in EC2 after doing yum update

2017-10-26 Thread Kiran Badi
Ok this is resolved. It was permission issue. now tomcat runs under its own
user id and for some reason I missed to read tomcat.conf file.

Now it works however server start up is now very slow.

INFO: Server startup in 352544 ms

something which was very fast in earlier version 7.081  and 7.050

Let me check logs tomorrow for finer details.

Thanking you
Kiran Badi


I will

On Thu, Oct 26, 2017 at 11:03 PM, Kiran Badi  wrote:

> Hi,
>
> Couple of hours(3 hrs) back I did yum update to install 7.0.82 version to
> install latest security patch.
>
> Yum update went well. Then tried to install ROOT war, after stopping and
> un deploying existing ROOT.war. Deployment failed saying that ROOT folder
> already exists. So deleted ROOT folder and ROOT.war from the web apps
> folder. After this step, tomcat 7 seems to be not starting for some reason
> and neither its writing to logs anything.
>
>  I think I messed something very badly.
>
> How do I figure this out. Do I need to do clean install again via wget ?
>
> I hate to say that my linux skills are very rusty. so appreciate some help.
>
> [root]# sudo service tomcat7 start
> [root]#  [  OK  ]
> [root]# sudo service tomcat7 status
> [root]# s not running[WARNING]
>
> whenever I try to restart , the only place it writes is tomcat7-initd.log
>
> /usr/sbin/tomcat7: line 40: /usr/share/tomcat7/logs/catalina.out:
> Permission denied
>
> and permissions I have on this folder is
>
> drwxr-xr-x 2 ec2-user ec2-user 12288 Oct 27 02:07 /usr/share/tomcat7/logs/
>
>
>
> Thanking you
> Kiran Badi
>
>
>
>
>
>
>
>
>


Tomcat 7.082 not starting in EC2 after doing yum update

2017-10-26 Thread Kiran Badi
Hi,

Couple of hours(3 hrs) back I did yum update to install 7.0.82 version to
install latest security patch.

Yum update went well. Then tried to install ROOT war, after stopping and un
deploying existing ROOT.war. Deployment failed saying that ROOT folder
already exists. So deleted ROOT folder and ROOT.war from the web apps
folder. After this step, tomcat 7 seems to be not starting for some reason
and neither its writing to logs anything.

 I think I messed something very badly.

How do I figure this out. Do I need to do clean install again via wget ?

I hate to say that my linux skills are very rusty. so appreciate some help.

[root]# sudo service tomcat7 start
[root]#  [  OK  ]
[root]# sudo service tomcat7 status
[root]# s not running[WARNING]

whenever I try to restart , the only place it writes is tomcat7-initd.log

/usr/sbin/tomcat7: line 40: /usr/share/tomcat7/logs/catalina.out:
Permission denied

and permissions I have on this folder is

drwxr-xr-x 2 ec2-user ec2-user 12288 Oct 27 02:07 /usr/share/tomcat7/logs/



Thanking you
Kiran Badi


catalina.authentication

2017-10-26 Thread Keith Brown
In my log file, I keep seeing Unable to login as service principal. (kerberos).
I followed these instructions:
https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html

here is what I did:
I created a DNS entry for my intranet server. "pluto"
Ask my NT admin to create me a domain user (web_user)
Have the Admin create a service principal name HTTP/pluto.site.org
She created a keytab file for me.

in ../Catalina/localhost/app.xml

I put

  



In my  WEB-INF/web.xml

Added  SPNEGO 

And put some security-constraints.

I restrated tomccat (version 8). And i see this message.

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



Re: [OT] is tomcat monitoring the keystore file?

2017-10-26 Thread Mark Thomas
On 26/10/17 20:17, Christopher Schultz wrote:



> So this is relying on the OpenSSLContext.finalize() method to clean-up
> after the native SSL context?

Correct.

> It's been "recommended" to not rely on
> finalizers for quite a long time. Is that advice no longer correct?

Like most general rules there are exceptions. Arguably, this is one of
them. The alternative would require an awful lot of code to replicate
what the JVM is already doing.

I believe there are better options available in Java 9.

> I'm particularly concerned about native memory leaks.

The argument against finalizers is that they might never run as the JVM
could shutdown before they are called. In this case, that doesn't
present a problem.

We'd have a problem if an object could be GC'd without the finializer
running. I'm not aware of any scenarios where that happens.

Mark

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



Re: [OT] classloader issue with bouncycastle

2017-10-26 Thread Chris Cheshire
On Thu, Oct 26, 2017 at 9:42 AM, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chris,
>
> Just curious... why are you using BC and not the JVM-provided crypto
> provider? What JVM are you using?
>

When I first starting looking for examples on doing PGP encryption in
Java, all I found
were (albeit obsolete) guides to doing it with BC.

JVM is OpenJDK 1.8. I first started fiddling with this using 1.6.

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



Re: tomcat 8.5.23 dbcp not honoring autocommit = false?

2017-10-26 Thread Chris Cheshire
On Thu, Oct 26, 2017 at 3:00 PM, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chris,
>
> On 10/16/17 9:43 AM, Chris Cheshire wrote:
>> On Fri, Oct 13, 2017 at 5:00 PM, Christopher Schultz
>>  wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>
>>> When you say you have "autocommit disabled in mysql config" what
>>> do you mean?
>>>
>>
>> /etc/my.cnf : [mysqld] autocommit=0
>>
>> This turns off autocommit off as a default for all connections.
>
> It only affects connections from MySQL's "mysql" command-line client.
> It does not affect e.g. Java-based clients.
>

It's in the [mysqld] section of my.cnf so it is supposed to be at a
server level.

I do have stuff in the [mysql] section that affects the command line client
behaviour only.

>> I need this at a minimum for the mysql client, but in the absence
>> of any other configuration it should be the default for a
>> connection from any client.
>
> The JDBC spec says that all connections are auto-commit unless
> otherwise specified. So if you are creating your own connections or
> using e.g. a connection-pool then you'll have to make sure that you
> configure them to be NOT auto-commit. This is not a setting that you
> can control from the server.
>
> More below.
>

I was doing that anyway in both the pool configuration and when
the connection is grabbed from the pool. I've since changed the code to not
touch the autocommit setting and leave that up to the datasource
(resource config in context.xml)


>>> On 10/13/17 10:17 AM, Chris Cheshire wrote:
 

 As a further test I just took out my explicit rollback in my
 DAOFactory close() method, and swapped back to commons dbcp.
 Added an update that wasn't explicitly committed, and it
 correctly did not get committed when the connection was closed.
 Swapped back to tomcat dbcp and repeated, it got committed
 without an explicit commit statement.

 I'm really puzzled as to why *I* have to explicitly rollback
 on close if autocommit is not enabled, instead of tomcat dbcp
 handling that when commons dbcp appears to do it.
>>>
>>> No connection pool can read your mind. If you begin a transaction
>>> (or never start one), you must either commit or rollback. Merely
>>> calling close() does not explicitly cause either of those to be
>>> called.
>>>
>>
>> And that's just it. If I don't explicitly commit, then why are
>> changes being committed when the connection is closed and returned
>> back to the pool?
>>
 If I do

 daoFactory = new MySQLDAOFactoryImpl(getDataSource());

 // update #1 daoFactory.commit()

 // update #2 daoFactory.close();

 then update #2 is being committed.
>>>
>>> I'm curious why you are doing "update #2" without either COMMIT
>>> or ROLLBACK. That seems like ... a mistake.
>>>
>>
>> Correct. This is an example to illustrate a mistake I found in my
>> code. I found a servlet that actually wasn't explicitly committing
>> when it should have been, yet everything it was doing was being
>> committed to the database.
>>
>>> - From the Connection.close() javadoc:
>>>
>>> " It is strongly recommended that an application explicitly
>>> commits or rolls back an active transaction prior to calling the
>>> close method. If the close method is called and there is an
>>> active transaction, the results are implementation-defined. "
>>>
>>
>> If a commit is not being explicitly issued, then the commit
>> behaviour should honor that of the connection, yes?
>
> Yes, but it's more complicated than that. Any change to the
> connection's settings (which happen ALL THE TIME when the connection
> is being returned to a connection pool) will cause an implicit COMMIT.
> That's why it's super important for you to either COMMIT or ROLLBACK
> yourself.
>
> Note that "autocommit = false" doesn't mean "autorollback=true".
> Best-case scenario for you there is that the transaction gets
> committed *later* when another piece of your code grabs a connection
> from the pool, does its work (successfully) and issues a COMMIT.
>
> It's just NOT the pool's job nor the driver's job to clean-up after
> any messes created by your code.


Agreed, however since it was acting differently than the commons
pool I mistakenly attributed the behaviour to tomcat jdbc instead.


>
>>> There *is* an implicit COMMIT executed if the autocommit flag is
>>> flipped for any reason, either true->false or false->true.
>>>
>>> If you have autocommit=false in your  configuration
>>> (which you do), then calling setAutoCommit(false) shouldn't do
>>> anything.
>>>
 If I put in this in the close() method of my DAO Factory

 if (!this.dbConn.getAutoCommit()) { this.dbConn.rollback(); }

 before the close() call, then update #2 is correctly not
 getting committed.
>>>
>>> This is probably the wrong approach: your close() method doesn't
>>> know whether it's 

Re: [OT] is tomcat monitoring the keystore file?

2017-10-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/26/17 12:07 PM, Mark Thomas wrote:
> On 26 October 2017 14:36:03 BST, Christopher Schultz
>  wrote:
>> Mark,
>> 
>> On 10/26/17 8:54 AM, Mark Thomas wrote:
>>> On 26/10/2017 09:31, Johan Compagner wrote:
 Hi,
 
 now with LetsCrypt its easy (and free) to get https up and 
 running even if you just use tomcat But the problem is those 
 certificate must be renewed every 3 months This is easy to do
 in a crontab script (that does the renew and makes a java
 keystore again) So i can generate the pfx constantly just
 fine
 
 But does tomcat monitor that file for changes and will it
 then use the new one without restarting the whole server?
>>> 
>>> Currently, no.
>>> 
>>> We have just added the ability to 9.0.x and 8.5.x to reload the
>>>  certificate file on the fly.
>> 
>> Can you point me to some specific commits that implement that?
>> I've been dragging my feet on the work to reload *everything* and
>> if the cert-reloading has already been done, then it seems that
>> most -- if not all -- the work I expected to do is already done.
> 
> http://svn.apache.org/viewvc?view=revision=1808482
> 
> Mark
> 
>> 
>> One of the reasons I hadn't done it yet was because I wasn't
>> sure about which of the many Tomcat components should warehouse
>> that code... there are so many layers and I don't understand
>> exactly which ones are responsible for what things.
>> 
>> Do these patches include replacing the SSLContext, or only the
>> key material that is being used for the handshake for an
>> existing SSLContext ?
> 
> It provides a new SSLContext that will be used for all new
> connections.

Thanks.

So this is relying on the OpenSSLContext.finalize() method to clean-up
after the native SSL context? It's been "recommended" to not rely on
finalizers for quite a long time. Is that advice no longer correct?

I'm particularly concerned about native memory leaks.

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnyNM8dHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh4Eg/+OJdiVLJp4XhPGvd4
kPvUmebwXez+f6JYFORqurxavbKk/i+4ttA9qls3iezxU/uABUY7LpUaHekFQK2m
dvCHv9/A7tF3lti6vY46UUUzp0t/3eJCBYl5lyQ/HRvNfacfhfTckaAYe/+1BiqB
Sj/75y5S5kV6tCJJMOiDIeitXhD/n8CzlJ6S4ReTVT9zuFNA0dShdH3LXeJJmQL3
RnWsxDZDkBDA9k3cH82tufJgCsez7GKDQBmitIlwNpf3Za4v4+QX4djDe0QdPjT8
WL62TaiDJvSjjIpR/j6eHxu6b7JO0orXyfT2LuiTQg7hPktCU+c1u2ePTUbx1NgF
v0gBXIBlTydbykw5tNPhA5vTEl7fSms45Uf7SJJz+ET8RgeU6G7JsAaAHRe+KKor
Xs8xMJMZyvz7SmW76pdkEVd8H+oYSUODbWVbLxMol3f7dZ7WqjsOt5jDoMHenzch
1A2168LQ3eZqSIRto00AnDVXUhEkIMLe6t9PKb+RGZ1CMEgvY3zqYtbkVIjbchf0
Q9GotkU/aSMLnEgJadY71HRhDGmZfDGx6PJZWG1BTQFHJO5al7hq8vxZhMBJPtiq
KOrbl6ydVVkWxKNjSaN/UAS309SQCrxVv9BYOS54GU5wzrCqo58Y3tTxWdXpXQpD
iSn0i2y+ujRDGFUeUdxuPqFkj3U=
=xwUc
-END PGP SIGNATURE-

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



Re: TomCat service is running but not responding

2017-10-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Darin,

On 10/26/17 10:56 AM, dbol...@dsginc.biz wrote:
> First I notice that we are not able to get to the app through the 
> browser.  The browser will just spin.  Then I try to get to the
> TomCat host manager and never get the login box and it just spins.
> If I restart the TomCat service then I can log into the host
> manager but not able to reach my app through the browser.   If I
> reboot the whole server then I can access tomcat and my app.

That's odd... restarting Tomcat should be enough.

> I see this error alot before I get the warning messaged and then
> server messages

Can you post your  configuration (minus any secrets)?

If you are using BIO you might be locking-up with keepalive timeouts
if you have a lot of disconnects.

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnyMvcdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhnchAAq0RAg5OoLxr8JMrw
nmiS9UXcx7VSvuqJQxwDofrzyUrQLhf8PGfR77IAW51fsKTQvOiaXmGPj99JI6sr
FAAiEQi1GNI/hoIKK2M8CY54W9rV5enIavStKIKiLALWA4ZknVNgcImtevU1Dt/k
oBJMArNM+hi9GHnpThXaESlbn2iyS8W1veUUC05l8gcailQlg3+04hbZ2cgJKsjQ
CmWV9s/7ZsgFGvh1HuzFPmljQWa9XTElv8YNlNHwRtUTiLsFLorC0JZl9GWjuPKy
JZ0wEazsUJdNG7cBMnNarrDRlXmWDl8lQLCdy7IihYvh6xnaO1FicT562s+HdggZ
jMKUJKXtd5t8IJBeRfqmZmcn+8h4SDaowPznxLjHJhYevzbZIWTs3nzDKkXAAgq+
suTf0oKO/2XCKh4P5JXn3KgL3WTJcvzbkvKoxklWS79EOSGJ0zzb6g7sWrndTjtp
UQ2F/IJJ1l+cIFUMDt+K2ZgA6wT11P1WEKkTtrKzc/CT0z9tWF4ccORzKfE7707A
jhElT4dgrzxUfQhnoAHuOqxA5jSRiI6z5JxqgcW/0JkdAPI+TYWnIXq302vxQojL
LA8nciIVNOk6DmF9EDGQ1ZQP1+J1xxjnhO7vsvZbVUvfItFlBgTFPzJVBr9A4rGd
eSYYsGrSOJN5eJTlToNlCHGr8X8=
=1406
-END PGP SIGNATURE-

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



Re: tomcat 8.5.23 dbcp not honoring autocommit = false?

2017-10-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris and Keiichi,

On 10/17/17 5:31 PM, Chris Cheshire wrote:
> On Tue, Oct 17, 2017 at 3:44 AM, Keiichi Fujino
>  wrote:
>> Hi
>> 
>> You have set
>> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory". In other
>> words, you do not use (tomcat)DBCP, you are using Tomcat
>> jdbc-pool.
> 
> That's what I meant sorry. Was comparing to commons-dbcp and went 
> dyslexic on the acronyms.
> 
>> 
>> In DBCP, the default of rollbackOnReturn attribute is true. 
>> However, in Tomcat jdbc-pool, the default of rollbackOnReturn(
>> and commitOnReturn ) attribute are false.
>> 
>> see: 
>> http://commons.apache.org/proper/commons-dbcp/configuration.html 
>> http://tomcat.apache.org/tomcat-8.5-doc/jdbc-pool.html
>> 
>> 
> 
> Now that explains it entirely. Thank you so much!
> 
> Part of this is me failing to RTFM entirely, and then part is the
> nature of configuration references - if you don't know what you are
> looking for it is easy to miss important details. It would be
> helpful if that page explained some of the fundamental differences
> from a usage perspective (not just implementation improvements) but
> that's another story.

I didn't realize that these two libraries had different default
semantics. IMO, Tomcat's jdbc-pool behaves _correctly_ in that it
doesn't issue an unnecessary ROLLBACK on every connection returned to
the pool.

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnyMUcdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFij4w//Q5tGBgwdcXsT9k/V
Raop4RalDLSeJNhTDY2FIMpDNHnvcq45BrOqkO3GhukyuNxpn/aJrUsE6ucbXN/3
jeb32JDEJ5f8FK5A6t9ZCeEG84p5BNDEfQUJEJQA5G67tBrhYzGfbW0t4X4qMyuM
l/xrVBLVP9JCLdjWUg/VnTyYhNKZGkIHYXzX5QtmZtjTRH+OBzCTuTT4B54WhkWM
MIFn5WYXxOnP6/+nR4f4rcV8VPKiJOoYuTv+dxt/Ih4IiGPNh+xUIzNS+lCTiagK
rsWDq51pqkH05nHdJTZ2+aZJEs/mFWXaCyjU3BOvIEPaUKaBJgjxjGBrIL1Tb/a9
jVEU3WrRJ3jNSNGYeN9kBfaL2dtB4W/H1btk1WAu39IuAdD/ZEcr8VgyIbteP6ar
StHXm2g5xt88X8ndgIo/2jdZisZ8LBNFksZ5yMXRuJckw3FN/YeLzHbe3gbPFXtv
K4xMFlI8OZFqr89EuNzzQjsris0gy6k3EFfQGz5tJDK7yiTNIEBfQbjGj9eFyYoA
7V2f7HvUIVmiNnRpCdg0CihdOypzIrXAZePOYTJGzkER0pUlGqt4ue4+6o5i8GSf
lap1sScK7Q6FiOGAvtQ3ZE+WMXvUFqGrs//O0pIi67KwXXHu+WsDV7av1BupZ0/F
hFkomQ3hHYAJoDoEJJHkn7jRXpY=
=zG27
-END PGP SIGNATURE-

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



Re: tomcat 8.5.23 dbcp not honoring autocommit = false?

2017-10-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

On 10/16/17 9:43 AM, Chris Cheshire wrote:
> On Fri, Oct 13, 2017 at 5:00 PM, Christopher Schultz 
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
> 
>> When you say you have "autocommit disabled in mysql config" what
>> do you mean?
>> 
> 
> /etc/my.cnf : [mysqld] autocommit=0
> 
> This turns off autocommit off as a default for all connections.

It only affects connections from MySQL's "mysql" command-line client.
It does not affect e.g. Java-based clients.

> I need this at a minimum for the mysql client, but in the absence
> of any other configuration it should be the default for a
> connection from any client.

The JDBC spec says that all connections are auto-commit unless
otherwise specified. So if you are creating your own connections or
using e.g. a connection-pool then you'll have to make sure that you
configure them to be NOT auto-commit. This is not a setting that you
can control from the server.

More below.

>> On 10/13/17 10:17 AM, Chris Cheshire wrote:
>>> 
>>> 
>>> As a further test I just took out my explicit rollback in my 
>>> DAOFactory close() method, and swapped back to commons dbcp.
>>> Added an update that wasn't explicitly committed, and it
>>> correctly did not get committed when the connection was closed.
>>> Swapped back to tomcat dbcp and repeated, it got committed
>>> without an explicit commit statement.
>>> 
>>> I'm really puzzled as to why *I* have to explicitly rollback
>>> on close if autocommit is not enabled, instead of tomcat dbcp
>>> handling that when commons dbcp appears to do it.
>> 
>> No connection pool can read your mind. If you begin a transaction
>> (or never start one), you must either commit or rollback. Merely
>> calling close() does not explicitly cause either of those to be
>> called.
>> 
> 
> And that's just it. If I don't explicitly commit, then why are
> changes being committed when the connection is closed and returned
> back to the pool?
> 
>>> If I do
>>> 
>>> daoFactory = new MySQLDAOFactoryImpl(getDataSource());
>>> 
>>> // update #1 daoFactory.commit()
>>> 
>>> // update #2 daoFactory.close();
>>> 
>>> then update #2 is being committed.
>> 
>> I'm curious why you are doing "update #2" without either COMMIT
>> or ROLLBACK. That seems like ... a mistake.
>> 
> 
> Correct. This is an example to illustrate a mistake I found in my
> code. I found a servlet that actually wasn't explicitly committing
> when it should have been, yet everything it was doing was being
> committed to the database.
> 
>> - From the Connection.close() javadoc:
>> 
>> " It is strongly recommended that an application explicitly
>> commits or rolls back an active transaction prior to calling the
>> close method. If the close method is called and there is an
>> active transaction, the results are implementation-defined. "
>> 
> 
> If a commit is not being explicitly issued, then the commit
> behaviour should honor that of the connection, yes?

Yes, but it's more complicated than that. Any change to the
connection's settings (which happen ALL THE TIME when the connection
is being returned to a connection pool) will cause an implicit COMMIT.
That's why it's super important for you to either COMMIT or ROLLBACK
yourself.

Note that "autocommit = false" doesn't mean "autorollback=true".
Best-case scenario for you there is that the transaction gets
committed *later* when another piece of your code grabs a connection
from the pool, does its work (successfully) and issues a COMMIT.

It's just NOT the pool's job nor the driver's job to clean-up after
any messes created by your code.

>> There *is* an implicit COMMIT executed if the autocommit flag is 
>> flipped for any reason, either true->false or false->true.
>> 
>> If you have autocommit=false in your  configuration
>> (which you do), then calling setAutoCommit(false) shouldn't do
>> anything.
>> 
>>> If I put in this in the close() method of my DAO Factory
>>> 
>>> if (!this.dbConn.getAutoCommit()) { this.dbConn.rollback(); }
>>> 
>>> before the close() call, then update #2 is correctly not
>>> getting committed.
>> 
>> This is probably the wrong approach: your close() method doesn't
>> know whether it's better to call commit() or rollback(), so it
>> should do neither.
> 
> I realise this too, however I have to have it in otherwise if an 
> exception is thrown, then work is being committed regardless of the
> fact that I have autocommit turned OFF in 3 levels, all  the way
> back to the mysqld configuration.

The mysqld configuration is not relevant, here. Are you able to run
your code through a debugger to see when the COMMIT is happening?

> This behaviour does not happen with commons dbcp, only tomcat dbcp.
> There is a difference in default behaviour between the two pools
> when a transaction is not explicitly committed or rolled back when
> a connection is closed and returned to the pool.

Can you create a SSCCE test-case which demonstrates 

Problem with KeyStore.load() after upgrading from 8.5.11 to 8.5.23

2017-10-26 Thread Felipe Jaekel
Hi,

I have a webapp where the user can upload a PFX file to digitally sign PDF
files. After upgrading from 8.5.11(TomEE 7.0.3) to 8.5.23(TomEE
7.0.5-SNAPSHOT) I'm getting this exception:

java.security.UnrecoverableKeyException: failed to decrypt safe contents
entry: javax.crypto.BadPaddingException: pad block corrupted

First I tough it was something related to the upload process, but even
after pointing to a local PFX file and hardcoding the password I still get
this exception on 8.5.23.

ks = KeyStore.getInstance(KeyStore.getDefaultType());
ks.load(new FileInputStream("/home/fjaekel/Desktop/anima.pfx"),
"anima".toCharArray());

Tested with OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)  and
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode).

Any ideias?

Thanks

*Stacktrace:*
java.io.IOException: keystore password was incorrect
at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2015)
at sun.security.provider.KeyStoreDelegator.engineLoad(
KeyStoreDelegator.java:238)
at sun.security.provider.JavaKeyStore$DualFormatJKS.
engineLoad(JavaKeyStore.java:70)
at java.security.KeyStore.load(KeyStore.java:1445)
at br.com.pacsweb.util.SignatureInterop.(SignatureInterop.java:38)
at br.com.pacsweb.service.AssinaturaLaudoService.persist(
AssinaturaLaudoService.java:40)
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.openejb.core.interceptor.ReflectionInvocationContext$
Invocation.invoke(ReflectionInvocationContext.java:205)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(
ReflectionInvocationContext.java:186)
at org.apache.openejb.monitoring.StatsInterceptor.record(
StatsInterceptor.java:181)
at org.apache.openejb.monitoring.StatsInterceptor.invoke(
StatsInterceptor.java:100)
at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext$
Invocation.invoke(ReflectionInvocationContext.java:205)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(
ReflectionInvocationContext.java:186)
at org.apache.openejb.core.interceptor.InterceptorStack.
invoke(InterceptorStack.java:85)
at org.apache.openejb.core.stateless.StatelessContainer._
invoke(StatelessContainer.java:252)
at org.apache.openejb.core.stateless.StatelessContainer.
invoke(StatelessContainer.java:212)
at org.apache.openejb.core.ivm.EjbObjectProxyHandler.
synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(
EjbObjectProxyHandler.java:260)
at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(
EjbObjectProxyHandler.java:89)
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(
BaseEjbProxyHandler.java:347)
at br.com.pacsweb.service.AssinaturaLaudoService$$
LocalBeanProxy.persist(br/com/spdata/pacsweb/service/
AssinaturaLaudoService.java)
at br.com.pacsweb.page.ImpressaoLaudoController.assinar(
ImpressaoLaudoController.java:156)
at br.com.pacsweb.page.ImpressaoLaudoController$$
OwbNormalScopeProxy0.assinar(br/com/spdata/pacsweb/page/
ImpressaoLaudoController.java)
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.el.parser.AstValue.invoke(AstValue.java:247)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:267)
at org.apache.webbeans.el22.WrappedMethodExpression.invoke(
WrappedMethodExpression.java:52)
at org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpressio
n.invoke(ContextAwareTagMethodExpression.java:96)
at org.apache.myfaces.application.ActionListenerImpl.processAction(
ActionListenerImpl.java:74)
at javax.faces.component.UICommand.broadcast(UICommand.java:120)
at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1174)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:365)
at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1660)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:864)
at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(
InvokeApplicationExecutor.java:42)
at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(
LifecycleImpl.java:196)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(
LifecycleImpl.java:143)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(

Re: TomCat service is running but not responding

2017-10-26 Thread DBolken
I do see a lot of these messages in the C:\Program Files\Apache Software 
Foundation\Tomcat 8.523\logs\catalina.2017-10-26.log


26-Oct-2017 09:21:56.927 WARNING [localhost-startStop-2] 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads 
The web application [WebSmart-api] appears to have started a thread named 
[AS400ConnectionPoolMaintenanceThread] but has failed to stop it. This is 
very likely to create a memory leak. Stack trace of thread:
 java.lang.Object.wait(Native Method)
 com.ibm.as400.access.PoolMaintenance.run(PoolMaintenance.java:79)
26-Oct-2017 09:21:56.927 WARNING [localhost-startStop-2] 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads 
The web application [WebSmart-api] appears to have started a thread named 
[AS400 Read Daemon-11] but has failed to stop it. This is very likely to 
create a memory leak. Stack trace of thread:
 java.net.SocketInputStream.socketRead0(Native Method)
 java.net.SocketInputStream.socketRead(Unknown Source)
 java.net.SocketInputStream.read(Unknown Source)

Darin Bolken | Programmer/Systems Support
Dakota Supply Group | P (701) 237-9440, Ext: 8878 | F (701) 237-6504
2601 3rd Ave N | Fargo, ND 58102

dakotasupplygroup.com



From:   "James H. H. Lampert" 
To: Tomcat Users List 
Date:   10/20/2017 11:18 AM
Subject:Re: TomCat service is running but not responding



On 10/20/17, 7:50 AM, André Warnier (tomcat) wrote:
. . .
> Then also tell a bit more about the "stop responding" aspect. What
> exactly happens when you try to access tomcat, in the browser ?
> Are you not getting any answer at all, no mater how long you wait ?
> Are you gettin an error page ?
> Are you getting a blank page ?

And are there any messages (especially Java stack traces) in the 
"catalina.out" log file that might indicate that something has gone 
horribly wrong?

--
JHHL

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




Re: [OT] is tomcat monitoring the keystore file?

2017-10-26 Thread Mark Thomas
On 26 October 2017 14:36:03 BST, Christopher Schultz 
 wrote:
>Mark,
>
>On 10/26/17 8:54 AM, Mark Thomas wrote:
>> On 26/10/2017 09:31, Johan Compagner wrote:
>>> Hi,
>>> 
>>> now with LetsCrypt its easy (and free) to get https up and
>>> running even if you just use tomcat But the problem is those
>>> certificate must be renewed every 3 months This is easy to do in
>>> a crontab script (that does the renew and makes a java keystore
>>> again) So i can generate the pfx constantly just fine
>>> 
>>> But does tomcat monitor that file for changes and will it then
>>> use the new one without restarting the whole server?
>> 
>> Currently, no.
>> 
>> We have just added the ability to 9.0.x and 8.5.x to reload the 
>> certificate file on the fly.
>
>Can you point me to some specific commits that implement that? I've
>been dragging my feet on the work to reload *everything* and if the
>cert-reloading has already been done, then it seems that most -- if
>not all -- the work I expected to do is already done.

http://svn.apache.org/viewvc?view=revision=1808482

Mark

>
>One of the reasons I hadn't done it yet was because I wasn't sure
>about which of the many Tomcat components should warehouse that
>code... there are so many layers and I don't understand exactly which
>ones are responsible for what things.
>
>Do these patches include replacing the SSLContext, or only the key
>material that is being used for the handshake for an existing
>SSLContext
>?

It provides a new SSLContext that will be used for all new connections.

Mark



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



Re: is tomcat monitoring the keystore file?

2017-10-26 Thread James H. H. Lampert

On 26/10/2017 09:31, Johan Compagner wrote:
. . .

But does tomcat monitor that file for changes and will it then use
the new one without restarting the whole server?


On 10/26/17, 5:54 AM, Mark Thomas replied:

Currently, no.

We have just added the ability to 9.0.x and 8.5.x to reload the
certificate file on the fly.

. . .

I was wondering about that myself; I know from experience that it 
definitely does NOT hot-switch to a new keystore when running on an 
AS/400, but wasn't sure about other platforms.


--
JHHL

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



Re: TomCat service is running but not responding

2017-10-26 Thread tomcat

Hi.
I will continue top-posting, because in this particular case it seems easier. Apologies 
for that, it is against the list rules.


Looking at the log below, there is not much I can tell you, except this :

Log messages where the text starts with "org.restlet.engine" mean that they do not come 
from any tomcat code.

Tomcat code messages will always start with "org.apache.catalina.."
(like some of the other messages below)

Basically, it seems to indicate that the error starts with an application which you are 
running under tomcat, but which is not itself part of tomcat.

We can generally not help you with that, because we do not know this 
application.
You should probably contact the support of that application, to find out what causes these 
messages.


With a fair bit of guessing, it looks like your tomcat application is itself (as a client) 
trying to access some other application on another server (or even maybe on the same one), 
and that it is at that level that something is blocking.

There is a http URL in that log. Is that the hostname of your own server ?


On 26.10.2017 16:56, dbol...@dsginc.biz wrote:

First I notice that we are not able to get to the app through the browser.  The 
browser
will just spin.  Then I try to get to the TomCat host manager and never get the 
login box
and it just spins.  If I restart the TomCat service then I can log into the 
host manager
but not able to reach my app through the browser. If I reboot the whole server 
then I can
access tomcat and my app.



I see this error alot before I get the warning messaged and then server messages


26-Oct-2017 09:02:57.481 INFO [http-nio-9080-exec-33]
org.restlet.engine.http.connector.HttpClientHelper.start Starting the default 
HTTP client
26-Oct-2017 09:03:00.820 INFO [http-nio-9080-exec-32]
org.restlet.engine.log.LogFilter.afterHandle 2017-10-26  09:03:00
172.16.2.226
-172.16.2.2269080GET
/WebSmart-api/categoryList
  
application=b2b=1=en_US=guest=dsgweb.dsginc.biz=024617=LLEMKE=Customer=Y=0=2
200-05232255 http://dsgweb.dsginc.biz:9080    
Restlet-Framework/2.0.7-
*26-Oct-2017 09:03:00.820 SEVERE [http-nio-9080-exec-32]
org.restlet.engine.http.adapter.ServerAdapter.commit An exception occured 
writing the
response entity*
* org.apache.catalina.connector.ClientAbortException: java.io.IOException: An 
established
connection was aborted by the software in your host machine
*


26-Oct-2017 09:49:57.993 WARNING [http-nio-9080-exec-29]
org.restlet.engine.http.HttpServerHelper.handle Error while handling an HTTP 
server call:
26-Oct-2017 09:49:57.993 INFO [http-nio-9080-exec-29]
org.restlet.engine.http.HttpServerHelper.handle Error while handling an HTTP 
server call
  java.lang.IllegalStateException: Cannot call sendError() after the response 
has been
committed
 at 
org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:457)



26-Oct-2017 09:49:57.977 INFO [http-nio-9080-exec-29]
org.restlet.engine.log.LogFilter.afterHandle 2017-10-26  09:49:57
172.16.2.226
-172.16.2.2269080GET
/WebSmart-api/categoryList
  
application=b2b=1=en_US=guest=dsgweb.dsginc.biz=master=Y=0=3
200-01261011 http://dsgweb.dsginc.biz:9080    
Restlet-Framework/2.0.7-
26-Oct-2017 09:49:57.993 SEVERE [http-nio-9080-exec-29]
org.restlet.engine.http.adapter.ServerAdapter.commit An exception occured 
writing the
response entity
  org.apache.catalina.connector.ClientAbortException: java.io.IOException: An 
established
connection was aborted by the software in your host machine
 at 
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:356)


*Darin Bolken*| /Programmer/Systems Support/
Dakota Supply Group| *P *(701) 237-9440, *Ext: *8878| *F *(701) 237-6504
2601 3rd Ave N| Fargo, ND 58102
*_
_**_dakotasupplygroup.com_* 



From: André Warnier (tomcat) 
To: users@tomcat.apache.org
Date: 10/20/2017 09:48 AM
Subject: Re: TomCat service is running but not responding
--



On 20.10.2017 15:46, dbol...@dsginc.biz wrote:
 > I have a TomCat 8.5.23 service running on a Windows 2008 server.  The 
service would be
 > running fine but it periodically stops responding until I reboot the server. 
 I tried
 > restarting the service but it does not always respond again.  I am not sure 
what logs I
 > can look at or if it is the app that I am running on the service.  I looked 
through the
 > Wiki but with no luck.

Hi.
Under Windows, assuming the default installation as a Service, all of tomcat 
should be
under one directory (assuming the default again, something like "Program Files 
/ Apache ..
/ tomcat").
Locate the subdirectory "logs" under 

Re: TomCat service is running but not responding

2017-10-26 Thread DBolken
First I notice that we are not able to get to the app through the browser. 
 The browser will just spin.  Then I try to get to the TomCat host manager 
and never get the login box and it just spins.  If I restart the TomCat 
service then I can log into the host manager but not able to reach my app 
through the browser.   If I reboot the whole server then I can access 
tomcat and my app.



I see this error alot before I get the warning messaged and then server 
messages


26-Oct-2017 09:02:57.481 INFO [http-nio-9080-exec-33] 
org.restlet.engine.http.connector.HttpClientHelper.start Starting the 
default HTTP client
26-Oct-2017 09:03:00.820 INFO [http-nio-9080-exec-32] 
org.restlet.engine.log.LogFilter.afterHandle 2017-10-26 09:03:00 
172.16.2.226-   172.16.2.2269080GET 
/WebSmart-api/categoryList 
application=b2b=1=en_US=guest=dsgweb.dsginc.biz=024617=LLEMKE=Customer=Y=0=2
 
200 -   0   5232255 http://dsgweb.dsginc.biz:9080 
Restlet-Framework/2.0.7 -
26-Oct-2017 09:03:00.820 SEVERE [http-nio-9080-exec-32] 
org.restlet.engine.http.adapter.ServerAdapter.commit An exception occured 
writing the response entity
 org.apache.catalina.connector.ClientAbortException: java.io.IOException: 
An established connection was aborted by the software in your host machine



26-Oct-2017 09:49:57.993 WARNING [http-nio-9080-exec-29] 
org.restlet.engine.http.HttpServerHelper.handle Error while handling an 
HTTP server call: 
26-Oct-2017 09:49:57.993 INFO [http-nio-9080-exec-29] 
org.restlet.engine.http.HttpServerHelper.handle Error while handling an 
HTTP server call
 java.lang.IllegalStateException: Cannot call sendError() after the 
response has been committed
at 
org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:457)



26-Oct-2017 09:49:57.977 INFO [http-nio-9080-exec-29] 
org.restlet.engine.log.LogFilter.afterHandle 2017-10-26 09:49:57 
172.16.2.226-   172.16.2.2269080GET 
/WebSmart-api/categoryList 
application=b2b=1=en_US=guest=dsgweb.dsginc.biz=master=Y=0=3
 
200 -   0   1261011 http://dsgweb.dsginc.biz:9080 
Restlet-Framework/2.0.7 -
26-Oct-2017 09:49:57.993 SEVERE [http-nio-9080-exec-29] 
org.restlet.engine.http.adapter.ServerAdapter.commit An exception occured 
writing the response entity
 org.apache.catalina.connector.ClientAbortException: java.io.IOException: 
An established connection was aborted by the software in your host machine
at 
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:356)


Darin Bolken | Programmer/Systems Support
Dakota Supply Group | P (701) 237-9440, Ext: 8878 | F (701) 237-6504
2601 3rd Ave N | Fargo, ND 58102

dakotasupplygroup.com



From:   André Warnier (tomcat) 
To: users@tomcat.apache.org
Date:   10/20/2017 09:48 AM
Subject:Re: TomCat service is running but not responding



On 20.10.2017 15:46, dbol...@dsginc.biz wrote:
> I have a TomCat 8.5.23 service running on a Windows 2008 server.  The 
service would be
> running fine but it periodically stops responding until I reboot the 
server.  I tried
> restarting the service but it does not always respond again.  I am not 
sure what logs I
> can look at or if it is the app that I am running on the service.  I 
looked through the
> Wiki but with no luck.

Hi.
Under Windows, assuming the default installation as a Service, all of 
tomcat should be 
under one directory (assuming the default again, something like "Program 
Files / Apache .. 
/ tomcat").
Locate the subdirectory "logs" under that, and find the recent files. That 
is what you 
should look at, first of all.  All "events" there have a date/time stamp, 
so you should 
locate something around the time when tomcat "stops responding". If you 
find such lines 
with the prefix "warning" or "error", copy and paste it here for someone 
to have a quick look.

Then also tell a bit more about the "stop responding" aspect. What exactly 
happens when 
you try to access tomcat, in the browser ?
Are you not getting any answer at all, no mater how long you wait ?
Are you gettin an error page ?
Are you getting a blank page ?

Note that this list strips most kinds of attachments, so it is better to 
copy and paste 
whatever text you get, directly in your messages to the list.


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




Re: Tomcat 7.0: compression="on" or compression="force" running on Java 1.8.0_151 causes content encoding errors in browsers

2017-10-26 Thread Johan Compagner
They (oracle) first introduced this in Java9..
Its something that they don't expect that certain things are reused/cached
i believe

Now they backported that same bug also to java 8,
i think they already fixed it for the next java8 version:

https://bugs.openjdk.java.net/browse/JDK-8189789



On 26 October 2017 at 16:19, Jörg Schubert  wrote:

> Am 26.10.2017 um 15:36 schrieb Jörg Schubert:
>
>>
>> Hello,
>>
>> We have a very stange problem. Since updating java 8 to build 151
>> (x86-64), tomcat is producing illegal compressed responses - sometimes.
>> Firefox and Chrome are complaining about content encoding errors. Firefox
>> error message is: an invalid or unknown form of compression was used.
>>
>> Tested with tomcat 7.0.56 ant tomcat 7.0.82 on debian stretch and ubuntu
>> artful. The debian system is running on openvz kernel 2.6.32-46-pve (system
>> locale en_US.UTF-8). Ubuntu is running kernel 4.13.0-16 with locale
>> de_DE.UTF-8.
>>
>> Tomcat's manager,docs and demo pages are working.
>> A lot of pages of Psi-Probe 
>> (Version 2.3.0 and current HEAD) are failing.
>> Also failing is a webservice result redirected over
>> org.apache.camel.component.servlet.CamelHttpTransportServlet from apache
>> camel 2.20.
>>
>> Going back to oracle jdk 1.8.0_144 or openjdk 1.8.0_141 resolves that
>> issue.
>>
>> A tcpdump of a failed Psi-Probe page is attached. My knowledge about HTTP
>> ist limited. Could anyone take a look at it?
>>
>>
>> Thank You and with best regards,
>>
>> Joerg
>>
>>
>> --
>> *
>> Jörg Schubert
>> cebacus Ingenieurgesellschaft mbH
>> Friedgartenstr. 50-52
>> 32429 Minden, Germany
>>
>> Phone: +49-(0571)-9561953
>> Fax: +49-(0571)-9561929
>> e-mail:jschub...@cebacus.de
>> *
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
> Some additional information:
>
> - No problems  with Tomcat 8.5.23 using standard connector with
> compression="on".
>
> - Problem occurs on Tomcat7 with standard connector, ssl connector and
> http11nio
>
>
>


-- 
Johan Compagner
Servoy


Re: Tomcat 7.0: compression="on" or compression="force" running on Java 1.8.0_151 causes content encoding errors in browsers

2017-10-26 Thread Jörg Schubert

Am 26.10.2017 um 15:36 schrieb Jörg Schubert:


Hello,

We have a very stange problem. Since updating java 8 to build 151 (x86-64), 
tomcat is producing illegal compressed responses - sometimes. Firefox and 
Chrome are complaining about content encoding errors. Firefox error message 
is: an invalid or unknown form of compression was used.


Tested with tomcat 7.0.56 ant tomcat 7.0.82 on debian stretch and ubuntu 
artful. The debian system is running on openvz kernel 2.6.32-46-pve (system 
locale en_US.UTF-8). Ubuntu is running kernel 4.13.0-16 with locale de_DE.UTF-8.


Tomcat's manager,docs and demo pages are working.
A lot of pages of Psi-Probe  (Version 
2.3.0 and current HEAD) are failing.
Also failing is a webservice result redirected over 
org.apache.camel.component.servlet.CamelHttpTransportServlet from apache camel 
2.20.


Going back to oracle jdk 1.8.0_144 or openjdk 1.8.0_141 resolves that issue.

A tcpdump of a failed Psi-Probe page is attached. My knowledge about HTTP ist 
limited. Could anyone take a look at it?



Thank You and with best regards,

Joerg


--
*
Jörg Schubert
cebacus Ingenieurgesellschaft mbH
Friedgartenstr. 50-52
32429 Minden, Germany

Phone: +49-(0571)-9561953
Fax: +49-(0571)-9561929
e-mail:jschub...@cebacus.de
*


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


Some additional information:

- No problems  with Tomcat 8.5.23 using standard connector with 
compression="on".

- Problem occurs on Tomcat7 with standard connector, ssl connector and http11nio




Re: [OT] classloader issue with bouncycastle

2017-10-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

Just curious... why are you using BC and not the JVM-provided crypto
provider? What JVM are you using?

- -chris

On 10/18/17 10:56 AM, Chris Cheshire wrote:
> Using bouncy castle v1.58, Tomcat 8.5, java 1.8.
> 
> I have the unlimited security policy files installed, the BC jars
> in my WEB-INF/lib directory and in order to register the BC
> provider, I do
> 
> static { Security.addProvider(new BouncyCastleProvider()); }
> 
> in a utility class that handles the keyring 
> setup/encryption/decryption methods for me. This works great until
> I update the jar that contains my utility class and reload the
> webapp. Then I get an exception thrown from it being unable to
> locate the BC provider.
> 
> mypackage.crypto.CryptoException: 
> org.bouncycastle.openpgp.PGPException: exception on setup: 
> java.security.NoSuchAlgorithmException: class configured for 
> MessageDigest (provider: BC) cannot be found. at
> mypackage.crypto.PGPUtils.decrypt(PGPUtils.java:304)
> ~[mypackage.jar:na] at
> mypackage.web.action.user.priv.settings.View.view(View.java:139) 
> ~[classes/:na] at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_141] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
ava:62)
>
> 
~[na:1.8.0_141]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
orImpl.java:43)
>
> 
~[na:1.8.0_141]
> at java.lang.reflect.Method.invoke(Method.java:498)
> ~[na:1.8.0_141] at
> net.sourceforge.stripes.controller.DispatcherHelper$6.intercept(Dispat
cherHelper.java:456)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionC
ontext.java:176)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> mypackage.web.interceptors.AuthenticateInterceptor.intercept(Authentic
ateInterceptor.java:41)
>
> 
[classes/:na]
> at
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionC
ontext.java:173)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.interc
ept(BeforeAfterMethodInterceptor.java:113)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionC
ontext.java:173)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionCont
ext.java:86)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.DispatcherHelper.invokeEventHandler
(DispatcherHelper.java:454)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.DispatcherServlet.invokeEventHandle
r(DispatcherServlet.java:278)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.DispatcherServlet.service(Dispatche
rServlet.java:160)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) 
> [servlet-api.jar:na] at
> net.sourceforge.stripes.controller.DynamicMappingFilter$2.doFilter(Dyn
amicMappingFilter.java:464)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilte
r.java:260)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.DynamicMappingFilter.doFilter(Dynam
icMappingFilter.java:451)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:193)
>
> 
[catalina.jar:8.5.23]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:166)
>
> 
[catalina.jar:8.5.23]
> at
> org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.ja
va:176)
>
> 
[urlrewritefilter-4.0.3.jar:4.0.3]
> at
> org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145
)
>
> 
[urlrewritefilter-4.0.3.jar:4.0.3]
> at
> org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewrit
er.java:92)
>
> 
[urlrewritefilter-4.0.3.jar:4.0.3]
> at
> org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewrite
Filter.java:394)
>
> 
[urlrewritefilter-4.0.3.jar:4.0.3]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:193)
>
> 
[catalina.jar:8.5.23]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:166)
>
> 
[catalina.jar:8.5.23]
> at
> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCha
racterEncodingFilter.java:108)
>
> 
[catalina.jar:8.5.23]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:193)
>
> 
[catalina.jar:8.5.23]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:166)
>
> 
[catalina.jar:8.5.23]
> at
> ch.qos.logback.classic.helpers.MDCInsertingServletFilter.doFilter(MDCI
nsertingServletFilter.java:51)
>
> 
[logback-classic-1.0.9.jar:na]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:193)
>
> 

Re: Tomcat 8.0.33 Crashed

2017-10-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Atanu,

On 10/26/17 5:23 AM, Mark Thomas wrote:
> On 25/10/2017 13:08, Atanu Pal wrote:
>> Still can you help me explain little more about the root cause?
>> 
>> That will help me to explain it to customer and setup a test 
>> environment for future. Thanks and Regards Atanu Pal 
>> E2Infosystems - Chennai
> 
> Difficult to say but a possible sequence of events is something
> like:
> 
> - thread A adds socket S to poller - thread B closes socket S -
> poller tries of access socket S -> crash

If you switch from the APR connector to NIO does the problem still occur
?

Are you sure you need the APR connector at all? Usually, it's only
used to get access to the OpenSSL crypto engine. Perhaps you can do
TLS offloading onto another device such as a load-balancer?

If the problem goes away when switching connectors, can you try to use
Tomcat 8.5.x with the OpenSSL JSSE provider? That's an NIO connector
with OpenSSL providing the crypto under the hood (so it's actually
fast, unlike the JVM-provided crypto engine).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnx5agACgkQHPApP6U8
pFhufA/+LspuZv9BHOJzcbdF/T7VBTFK+Vp+gidCxDwhSb/hK9MXZ64vDjNixenb
Za8vkm4irDpurYKOWYaz31tiANyIF4kLWw0FUdiCDS2DgFNEyZhmyBjj3wi0C4eY
3e/Ck8947Rc3Ewz3/DLfe9bqQRsRsi4wb3dkWSCgKemWVM9L9sr+ROknOCHr8NMW
tgTgu2/StAKEd8ZI1E6fVA4/7h8bgoKuchlViHJ6+HFHhZkKFMOPNH3AMpYtr0sq
oXSXGGXbQ5EwUFnOCJ/nVWJb8uSaPYnyYfgne4RDR1zD0LJaTESYyrEgDmBa185B
BxNcpUP1FH+9IGjpcf0idZcazxn/r1ZFzL0/tKkEttby8BUyXrdFHa3c3qYs4MwA
p7Y9cdqZ8PtGHXEHZoe5vZxkO6JRCFAWau2+ipPc/ea2kwf7riqeABr7CLVZfRKx
65x3UYuh18zIpI6xSg0V1gVQswccaKq/o7Jim9duf6rkl2p7QcCEPnpUhXHMfRkg
nQopfhwjACyylZiD9dgFOo4JI/7uUoP+cjOSAXNoDy5rVq9CkE0kUoZxkL4z4OdF
j7vhKIHosTvFfMURS2Xlcm1N50TPvkFcTqRTR1mhh+rd+G8F25CMCB8m5nxMD4Rj
PZ4yLiahlFyc4t8KXONFrh9Yg7qHQFIjbdYduv8KOQkv89rCrgg=
=P/D+
-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: compression="on" or compression="force" running on Java 1.8.0_151 causes content encoding errors in browsers

2017-10-26 Thread Jörg Schubert

Hello,

We have a very stange problem. Since updating java 8 to build 151 (x86-64), 
tomcat is producing illegal compressed responses - sometimes. Firefox and Chrome 
are complaining about content encoding errors. Firefox error message is: an 
invalid or unknown form of compression was used.


Tested with tomcat 7.0.56 ant tomcat 7.0.82 on debian stretch and ubuntu artful. 
The debian system is running on openvz kernel 2.6.32-46-pve (system locale 
en_US.UTF-8). Ubuntu is running kernel 4.13.0-16 with locale de_DE.UTF-8.


Tomcat's manager,docs and demo pages are working.
A lot of pages of Psi-Probe  (Version 
2.3.0 and current HEAD) are failing.
Also failing is a webservice result redirected over 
org.apache.camel.component.servlet.CamelHttpTransportServlet from apache camel 2.20.


Going back to oracle jdk 1.8.0_144 or openjdk 1.8.0_141 resolves that issue.

A tcpdump of a failed Psi-Probe page is attached. My knowledge about HTTP ist 
limited. Could anyone take a look at it?



Thank You and with best regards,

Joerg


--
*
Jörg Schubert
cebacus Ingenieurgesellschaft mbH
Friedgartenstr. 50-52
32429 Minden, Germany

Phone: +49-(0571)-9561953
Fax: +49-(0571)-9561929
e-mail:jschub...@cebacus.de
*


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

Re: [OT] is tomcat monitoring the keystore file?

2017-10-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/26/17 8:54 AM, Mark Thomas wrote:
> On 26/10/2017 09:31, Johan Compagner wrote:
>> Hi,
>> 
>> now with LetsCrypt its easy (and free) to get https up and
>> running even if you just use tomcat But the problem is those
>> certificate must be renewed every 3 months This is easy to do in
>> a crontab script (that does the renew and makes a java keystore
>> again) So i can generate the pfx constantly just fine
>> 
>> But does tomcat monitor that file for changes and will it then
>> use the new one without restarting the whole server?
> 
> Currently, no.
> 
> We have just added the ability to 9.0.x and 8.5.x to reload the 
> certificate file on the fly.

Can you point me to some specific commits that implement that? I've
been dragging my feet on the work to reload *everything* and if the
cert-reloading has already been done, then it seems that most -- if
not all -- the work I expected to do is already done.

One of the reasons I hadn't done it yet was because I wasn't sure
about which of the many Tomcat components should warehouse that
code... there are so many layers and I don't understand exactly which
ones are responsible for what things.

Do these patches include replacing the SSLContext, or only the key
material that is being used for the handshake for an existing SSLContext
?

> It should be relatively easy to add a component that watches for 
> changes to the cert file (or any of the other files) and trigger a 
> reload as required. I suggest opening an enhancement request in 
> Bugzilla.

+1

> Whether it is a whole new component or just something that gets
> added to the existing back ground processing framework for an
> existing component is TBD.
> 
> If you'd like to work on a patch to implement this, pop over to the
> dev list and we'll point you in the right direction.

- -chris

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnx5MMACgkQHPApP6U8
pFjxfw//aKlCe4jMAFdLP1djFjcmlO3vfmrFaf+mHdhLS4c6WMSk4+yIxzUsowDx
TeKpdGOK02RTVRg1MC9AB5Y00H5bs5ztuOOdYMODS4qMzKm69NJTURuAraWJ1hbi
vvn+8Yg77P8/6MDBwoooh3z96WpDENbP3ROZan3reWf2ViBPBbVyoNbNb1pESvow
ZKFzP6fntKc1ecqOxmXPj3Uu0R0pul4FF16CSz6JD2T90Ws9Rf8vAqd54F/RKngn
2WrKtTr08F2kZoSo+qI6O21dUcbEWh8gvtaLtPNMo4YpIqZsE7mXfU3ZDSEKLK+q
pQPQluICNt+5QPaYIKIqy20t2mAFS/K2QSnIdkGqJuEt4wXYuZ45x3rck5VpC8tJ
P9+NcQmS2hUqeJKjWDLX98W6H5BsEAsX6gGZP9beA7RsBOk+7TmL+MRGf+BOI3Cy
dJ845nM3ecnhlz7OtIvJopC87QM0LpWKAtbKkqHLShzo4lXgaDzcyCOb6m/ozGGG
mhesNbX5fDZfUI4dMR95Wgp5Xpvf2drYszvWCnl/cgtEYc+anUh47ADNIc8h6KnF
KLXBOAV+MuVEWFIi1HfCWrpwoIYQQGNTsYlBSEvNsBUd20IGQ25+xII4ERtXKXbA
fw2OHtgqtF2KtHsIwLXFaMHJN+EXIRPbMY/Fwu04A5utGN6iVfw=
=yrp/
-END PGP SIGNATURE-

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



Re: TLD scanning performance question

2017-10-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Markus,

On 10/25/17 10:53 AM, i...@flyingfischer.ch wrote:
> 
>> 
>> Yes, it's the SecureRandom initialization that is killing you.
>> Being a virtual server, it likely has no direct source of true
>> randomness so it needs to pull from whatever the hypervisor is
>> willing to provide.
>> 
>> You'll need to ask your virtualization vendor for how to get
>> access to more entropy, or switch to a less-secure random source
>> (e.g. /dev/urandom on *NIX-like systems).
>> 
> Install haveged and your boot up problems will be gone.

This /might/ be bad advice. Since this is a virtualized environment,
the "hardware events" are all hand-wavy fictional kinds of things. So
the dubious nature of haveged is then further blurred by the effects
of not having direct hardware access.

YMMV

- From the man page: "The output of the HAVEGE random number generator
should be verified on any installation before the haveged is put into
production."

Good advice.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnx4+UACgkQHPApP6U8
pFh14w//S4uI34pfkeqfpLOen/3v491a8vI3UB7Fvng461RKgZZzKFOTZOJSWJzo
dOI70IsO9oQklaJm8PBgExoaEHuBOIjNUI/CH4QH2PUBNyOZhDe4st89CMJvkEik
M3Gig/try50dVuNKY3Fwt+xmViqRorr9iVfa+c0yy/vRM6gOy74dnU37Jmcc3e6B
4oJ5TRT4oO6saKQFQxAm3NYk+xcBs+dkkqC/bT6cP9OrnKoDoCKqyTomxGb0k5zx
a2y4Lx3+DaMfC1hQw55AwTfy9XL81hQk+X8kEakccUMonxXqThRrVFbfORBAogHc
ntClV+N0m/b5ujUZubauk7c2VIdmF1x6GBJeBpHm1ALOoOv6IYc6Mm3XeeoS2X1/
5o1O+x1QKWqAPlArF1ny3QPJ0ycnHynu3GgehdRdkgN5FRDGyaCo/k19h0rk5c0r
3urDZBIbxDNwYFO6kdeL9Xzzr1WLjtU0c53nWmAFj4Vw/GHUR1fqT9G4FDeEIgqE
+YLBn2rmULmUFRIwIjj7J/w5ZT6bGMb2edxT6bDwyDjEbbFyq/gegyDIyQBwcGOL
zlSQ0RrTVO25QQxEEa24HIo/9wvw3xaRYdvMidGdbeD2dsMnhbtz2OKCFsnbTVJn
X4ilvpMwP1zPTGZf9kzyh4qV4uonGMzVYOGrtGzK34VLRvCF4VE=
=fSwK
-END PGP SIGNATURE-

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



Re: is tomcat monitoring the keystore file?

2017-10-26 Thread Mark Thomas
On 26/10/2017 09:31, Johan Compagner wrote:
> Hi,
> 
> now with LetsCrypt its easy (and free) to get https up and running even if
> you just use tomcat
> But the problem is those certificate must be renewed every 3 months
> This is easy to do in a crontab script (that does the renew and makes a
> java keystore again)
> So i can generate the pfx constantly just fine
> 
> But does tomcat monitor that file for changes and will it then use the new
> one without restarting the whole server?

Currently, no.

We have just added the ability to 9.0.x and 8.5.x to reload the
certificate file on the fly. It should be relatively easy to add a
component that watches for changes to the cert file (or any of the other
files) and trigger a reload as required. I suggest opening an
enhancement request in Bugzilla.

Whether it is a whole new component or just something that gets added to
the existing back ground processing framework for an existing component
is TBD.

If you'd like to work on a patch to implement this, pop over to the dev
list and we'll point you in the right direction.

Mark


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



Re: release plan for tomcat 7.x for java9

2017-10-26 Thread Mark Thomas
On 26/10/2017 02:49, Mukarram Baig wrote:
> hello good folks!
> 
> I see that the endorsed directory related problem in tomcat 7.x for running
> in java 9 has been fixed by the patch by rjung in
> https://github.com/apache/tomcat70/commit/e7ae8664922cd54fabe847527bad614bcd5ce301#diff-da184cf589a25174c11dc3f4dbaeb0b4
> 
> 
> Do we know the approximate date by when we can expect a new release for 7.x
> series that has this change?

Releases tend to be monthly with the process starting with trunk at the
beginning of the month and the other releases following afterwards. So
best guess, middle to end November.

As an aside, there are a bunch of other changes in Tomcat 7 related to
smoother running on Java 9as well. The remaining TODOs relate to Commons
Daemon - that is where the current focus is.

Mark


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



Re: Tomcat 8.0.33 Crashed

2017-10-26 Thread Mark Thomas
On 25/10/2017 13:08, Atanu Pal wrote:
> Still can you help me explain little more about the root cause?
> 
> That will help me to explain it to customer and setup a test
> environment for future.
> Thanks and Regards
> Atanu Pal
> E2Infosystems - Chennai

Difficult to say but a possible sequence of events is something like:

- thread A adds socket S to poller
- thread B closes socket S
- poller tries of access socket S -> crash

Mark

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



is tomcat monitoring the keystore file?

2017-10-26 Thread Johan Compagner
Hi,

now with LetsCrypt its easy (and free) to get https up and running even if
you just use tomcat
But the problem is those certificate must be renewed every 3 months
This is easy to do in a crontab script (that does the renew and makes a
java keystore again)
So i can generate the pfx constantly just fine

But does tomcat monitor that file for changes and will it then use the new
one without restarting the whole server?


-- 
Johan Compagner
Servoy