Re: ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory starting in 7.0.86

[Shawn Heisey]

On 4/17/2018 10:25 AM, Adam Rauch wrote:
> According to the tomcat70 GitHub mirror, a recent change to
> Constants.java switched DBCP_DATASOURCE_FACTORY to
> "org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory", which seems
> suspicious. See
> https://github.com/apache/tomcat70/commit/08b7ca0fae77063202d82e719eb35e4eda881bbf

I've recently been asking the list about pool configurations in Tomcat
7, and I've gotten an education about it as a result.

The info I've received says that Tomcat 7 uses dbcp 1.4.  Version 8
updated to dbcp2.

To me, that looks like an incorrect change for version 7.  I think the
line in the change with the default class name for the factory should be
reverted.

You should be able to work around the problem by defining a factory in
your pools set to "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"
so that the default is not used.  This addition should only be made on
configs for Tomcat 7.

That commit says it was prep work for BZ bug number 50019.  I have put a
note on that bug about this.

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

Thanks,
Shawn


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

Re: ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory starting in 7.0.86

[Mark Thomas]

On 17/04/18 17:25, Adam Rauch wrote:
> Our code retrieves DataSources using JNDI, with code similar to this:
> 
>     new InitialContext().lookup("java:comp/env/jdbc/labkeyDataSource");
> 
> With a simple DataSource definition that doesn't specify a "factory"
> attribute, this code now throws in Tomcat 7.0.86. (It works in 7.0.85,
> 8.0.50, 8.5.30, and 9.0.7.)
> 
> According to the tomcat70 GitHub mirror, a recent change to
> Constants.java switched DBCP_DATASOURCE_FACTORY to
> "org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory", which seems
> suspicious. See
> https://github.com/apache/tomcat70/commit/08b7ca0fae77063202d82e719eb35e4eda881bbf

Yep. That is an error on my part. Explicitly setting the factory is the
work-around.

I'll get that fixed shortly.

Mark


> 
> 
> Root cause stack trace is:
> 
> Caused by: java.lang.ClassNotFoundException:
> org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory
>    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>    at java.lang.Class.forName0(Native Method)
>    at java.lang.Class.forName(Class.java:264)
>    at
> org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:115)
> 
>    ... 26 more
> 
> Thanks,
> Adam
> 
> -
> 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

ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory starting in 7.0.86

[Adam Rauch]

Our code retrieves DataSources using JNDI, with code similar to this:

    new InitialContext().lookup("java:comp/env/jdbc/labkeyDataSource");

With a simple DataSource definition that doesn't specify a "factory" 
attribute, this code now throws in Tomcat 7.0.86. (It works in 7.0.85, 
8.0.50, 8.5.30, and 9.0.7.)


According to the tomcat70 GitHub mirror, a recent change to 
Constants.java switched DBCP_DATASOURCE_FACTORY to 
"org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory", which seems 
suspicious. See 
https://github.com/apache/tomcat70/commit/08b7ca0fae77063202d82e719eb35e4eda881bbf


Root cause stack trace is:

Caused by: java.lang.ClassNotFoundException: 
org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory

   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:264)
   at 
org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:115)

   ... 26 more

Thanks,
Adam

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

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

[Support]

Thank you Olaf!

777 was given as last resort to see if this is really file permissions
issue.

Because of copy/paste and renaming to a dummy folder name, there was an
extra space so please ignore.

testuser is not an actual user but a repository for web files so tomcat
user can access it. The reason why we did not keep www files in %tomcat%
because during upgrades it gets wiped.





Regards,

Usha

Customer Support Engineer
supp...@xcaptor.com
Captivate. Engage.

On Tue, Apr 17, 2018 at 3:53 AM, Olaf Kock  wrote:

> On 16.04.2018 22:06, Support wrote:
>
>> SEVERE: Error initializing static Resources
>>
>> java.lang.IllegalArgumentException: Document base
>> /home/testuser/resources/Raptor
>> does not exist or is not a readable directory
>>
>
> A few things are slightly off of my expectations:
>
> But if you see below folder/permissions even after 777 it still says not a
>> readable directory.
>>
>
> it's quite bad practice to open up to 777
>
> drwxr-xr-x. 4 root root35 Apr 16 14:45 /home/
>> drwxrwxrwx. 3 root tomcat  23 Apr 16 13:26 /home/testuser
>> drwxrwxrwx. 3 root tomcat  20 Apr 16 13:26 /home/ testuser/resources/
>> drwxrwxrwx. 7 root tomcat 170 Apr 16 13:27 /home/testuser
>> /resources/Raptor/
>>
>
> If I change the document base to /user/share/tomcat/webapps this error goes
>>
> away.
>
> * There are weird spaces in the /home/ directories - I'm assuming this
> comes from copy/paste and you rather mean those directories without the
> spaces. But there's a small chance that you're hiding issues through
> copy/paste/anonymize
> * commonly, a directory /home/testuser would belong to a user named
> "testuser", not to root. Is there a reason why it should be owned by root?
> Is "testuser" an actual user account?
> * What is the user account that tomcat is running under? What are the
> permissions/owner on  /usr/share/tomcat/webapps ? (note /usr/ vs /user/ - I
> assume a typo in your statement)
>
> Olaf
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 17 April 2018 at 14:54, Mark Thomas  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

Proper hot deploy technique

[Daryl Stultz]

Hello,


We have a dev environment where we regularly deploy and undeploy applications 
while Tomcat is running. We are on Tomcat 8.5. We stage the application in a 
temporary directory, we are not using war files. We then deploy with a call to 
the manager app like this:


http://tomcat:PASSWORD@localhost:8080/manager/text/deploy?path=/myapp&war=file:/temp/myapp


Somehow Tomcat is failing to take in all the files. The set of files do not 
appear to be related but the all-important classes and web.xml files are 
missing, so the application does not start.


We've decided to change our process a bit by turning on auto deploy and moving 
the temporary directory into the webapps directory. That seems to be working 
but I'm wondering if anyone has seen this problem and what we might be doing 
wrong.


Thanks.


--

Daryl Stultz
Principal Software Developer
_
OpenTempo, Inc
http://www.opentempo.com
mailto:daryl.stu...@opentempo.com

Re: Connection closed error and certificateVerification="required"

[Mark Thomas]

On 17/04/18 11:36, Mark Thomas wrote:
> On 17/04/18 10:14, Richard Tearle wrote:



>> I've also disabled the health check on ESB container, and my tests
>> ran through for an hour, without a connection closed error.
> 
> That is good news. That is a strong indicator that we are on the right
> track. It also explains why I could not reproduce the problem with your
> test case. And finally, it is another example of the debug logging added
> to the I/O layer proving worth while.
> 
> 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

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

Tomcat 8.5 -testOnBorrow

[Kota, Sriraghavi Latha]

Chris,

Thank you for your quick response. We are planning to use the combination of 
one of these below in production. Our application is a high volume application 
with transactions per second of about 20. Just wondering for the recommended 
value for validationInterval.



Option1:

testOnBorrow = true

validationInterval = 30 (5 mins)



Option2:

testOnBorrow = true

validationInterval = 30 (5 mins)

validationQuery = "SELECT 1 from SYSIBM.SYSDUMMY1"



Along with the above option1 or option2 can we add the below parameters also?

testWhileIdle = true

removeAbandoned = true

removeAbandonedTimeOut = 6000 (max response time for our application taken from 
splunk)

max-idle = 2

min-idle = 2

minEvictableIdleTimeMillis = 6 (60 seconds)

timeBetweenEvictionRunsMillis = (5000)


Thanks,
Sri Kota
Scrumbelievables
(904) 954 5113 (W)

RE: testOnBorrow = true

[Kota, Sriraghavi Latha]

Chris,
Thank you for your quick response. We are planning to use the combination of 
one of these below in production. Our application is a high volume application 
with transactions per second of about 20. Just wondering for the recommended 
value for validationInterval.

Option1:
testOnBorrow = true
validationInterval = 30 (5 mins)

Option2: 
testOnBorrow = true
validationInterval = 30 (5 mins)
validationQuery = "SELECT 1 from SYSIBM.SYSDUMMY1"

Along with the above option1 or option2 can we add the below parameters also?
testWhileIdle = true
removeAbandoned = true
removeAbandonedTimeOut = 6000 (max response time for our application taken from 
splunk) max-idle = 2 min-idle = 2 minEvictableIdleTimeMillis = 6 (60 
seconds) timeBetweenEvictionRunsMillis = (5000)

Thanks,
Sri Kota
Scrumbelievables
(904) 954 5113 (W)


> Hello, We are on Tomcat 8.5.23. We are trying to add fix to recover 
> application after database restart.
> 
> Here are our versions:
> 
> Tomcat 8.5.23 DB2 version: 11.1 JDBCDriver: DB2JCC 4.22.9
> 
> Does testonBorrow = true issue a select statement to the database to 
> validate the connection or is that a OPING which is a lightweight RPC?

This depends upon a couple of things. Tomcat 8.5 uses DBCP2 as the default 
connection pool, but you can also use Tomcat's jdbc-pool connection-pool as 
well.

If you are using either of these two pools, then setting testOnBorrow="true" 
without setting a "validationQuery" will use the JDBC driver's isValid() method 
to determine whether or not the connection is okay. It's up to the driver to 
decide how to do that.

If you are using another connection-pool, it will depend upon whatever that 
pool decides to do.

Hope that helps,
- -chris

Re: Connection closed error and certificateVerification="required"

[Mark Thomas]

On 17/04/18 10:14, Richard Tearle wrote:
> On 16 April 2018 at 22:04, Mark Thomas  wrote:



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

The above message are correct but misleading. I'm planning to add
additional debug logging which should clarify things.



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

That is good news. That is a strong indicator that we are on the right
track. It also explains why I could not reproduce the problem with your
test case. And finally, it is another example of the debug logging added
to the I/O layer proving worth while.

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.

Mark


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


-
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  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: ava.lang.IllegalArgumentException: Document base xxxx does not exist or is not a readable directory

[Olaf Kock]

On 16.04.2018 22:06, Support wrote:

SEVERE: Error initializing static Resources

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


A few things are slightly off of my expectations:


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


it's quite bad practice to open up to 777


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



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

away.

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


Olaf

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