Re: Viewing Tomcat DB connection statement cache size via JMX MBeans

[Keiichi Fujino]

2016-07-01 13:18 GMT+09:00 Manisha Sapiah :

> Hi,
>
> I want to know, is there any way to get Tomcat DB connection statement
> cache size via JMX MBeans. Thanks in advance.
>
>
Which DB Connnection Pool do you use? DBCP or Tomcat jdbc-pool.
If you use the Tomcat jdbc-pool, such a feature does not exist.
The StatementCache Interceptor does not have MBean information.
If you need this feature, it needs to implement the MBean for
StatementCache Interceptor.



> Manisha
>
> --
> Keiichi.Fujino
>

Re: tomcat 7 connection pool validation interval

[Keiichi Fujino]

2016-06-30 23:32 GMT+09:00 Nir Dweck :

> I am using tomcat connection  pool (tomcat 7) in my application (java
> application) to connect to a remote Oracle DB on an Azure machine. My
> connection pool configuration is as follow:
>
> PoolProperties p = new PoolProperties();
> p.setUrl(connString);
> p.setUsername(user);
> p.setPassword(password);
> p.setDriverClassName("oracle.jdbc.OracleDriver");
> p.setValidationQuery("SELECT 1 from dual");
> p.setValidationInterval(1 * 6/2);
> p.setTimeBetweenEvictionRunsMillis(1 * 6/2);
> p.setTestOnBorrow(true);
> p.setTestWhileIdle(true);
> p.setMinIdle(10);
> p.setInitialSize(10);
> However looking at the capture file, I see that the connections are not
> checked every 30 seconds as I expected. One connection is checked
> correctly, the others are checked after 3 times the configuration (180
> second). then again only some of the connections are checked and after a
> while it seems to stable on twice the configuration period (every 60
> seconds).
>
> I tested it with different configured time and different pool size, all
> had a instability period in which each time only part of the connections
> were checked and eventually it stabled on checks of all the connections
> every twice the configured time.
> What am I missing?
> Thanks,
>

I reproduced this.

I found the following code in the
org.apache.tomcat.jdbc.pool.ConnectionPool.
===
protected static class PoolCleaner extends TimerTask {
// snip

@Override
public void run() {
ConnectionPool pool = this.pool.get();
if (pool == null) {
stopRunning();
} else if (!pool.isClosed() &&
(System.currentTimeMillis() - lastRun) > sleepTime) {
lastRun = System.currentTimeMillis();
try {
// snip
===
Regardless of the scheduled PoolCleaner, (System.currentTimeMillis() -
lastRun) > sleepTime) is called.

Since PoolCleaner has been scheduled by the Timer#scheduleAtFixedRate,
This code probably is necessary in order to avoid a continuous calling of
PoolCleaner when the previous task was delayed.
However, This code causes the unintended skip of PoolCleaner.

I plan to fix the followings if there is no objection.
-Remove the "System.currentTimeMillis() - lastRun) > sleepTime".
-The scheduleAtFixedRate method changes to the schedule method.




>
> Nir
>
> --
> Keiichi.Fujino
>

RE: Servlet overridden by Apache Tomcat welcome page?

[Caldarale, Charles R]

> From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID] 
> Subject: Re: Servlet  overridden by Apache Tomcat welcome 
> page?

> I just played with Eclipse Neon (newest release). It does copy over a
> Tomcat configuration into your workspace, and then runs Tomcat from that
> (sort of like RUNNING.txt).

I thought there was some way to disable such obnoxiousness, but I don't 
remember the details.

> That being said, Eclipse does not handle ROOT well at all by default. If
> I tell Maven to have a final name of ROOT, then Eclipse edits the
> workspace server.xml with:
> 
> path="/ROOT"
>reloadable="true"
>source="org.eclipse.jst.jee.server:CSEFive"/>
> 

Clearly broken.  (Also, there is no  attribute of "source".)

> If I name things normally, then the application comes up as CSEFive, and
> the portion of server.xml reads as follows:
> 
> docBase="CSEFive"
>path="/CSEFive"
>reloadable="true"
>source="org.eclipse.jst.jee.server:CSEFive"/>
> 

Other than the source attribute, at least that's legal.

> The only way that I know of to manage this from within Eclipse is the
> following:

> Right-mouse click on the project, and go the the following in the drop
> down menu:

> Properties->Web Project Settings

> Change the Context root to /

Strictly speaking, this isn't correct; the default webapp must have an empty 
path string.

> Run your project from within Eclipse, and it will come up as
> http://localhost:8080/

That's an accident, since the path attribute is not valid.

> Eclipse will rewrite the server.xml in your workspace to:
> 
> docBase="CSEFive"
>path="/"
>reloadable="true"
>source="org.eclipse.jst.jee.server:CSEFive"/>
> 

The path attribute is illegal.  You would think after this number of years, 
Eclipse would at least get the syntax right.

> In any case, once you move out of an Eclipse-controlled Tomcat,

Which seems to be highly desirable, given the mess Eclipse is making.

> the WAR file needs to be named ROOT.war (case matters, even on Windows).

As Hassan previously noted.

> You'll need to move Tomcat's default ROOT web application to another
> location.

Or just delete it.

> In short, it's an Eclipse artifact.

A seriously broken artifact.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Servlet overridden by Apache Tomcat welcome page?

[Mark Eggers]

Paul and Chuck,
On 7/3/2016 4:14 PM, Caldarale, Charles R wrote:
>> From: Paul Roubekas [mailto:paul@orthogroup.holdings] Subject: Re:
>> Servlet  overridden by Apache Tomcat welcome
>> page?
> 
>> After making the above suggested changes the desired behavior goes 
>> away.  Now instead of my application's landing page I get the
>> tomcat welcome page.
> 
> You appear to have ignored what Hassan S said earlier in this thread;
> I'll repeat it here:
> 
> "Assuming a default installation, you should see the index.jsp page 
> associated with the *default context*, which in Tomcat is named ROOT
> (case sensitive).
> 
> "You need to move or delete the existing ROOT and rename your own WAR
> file (or directory) to ROOT."
> 
> I suspect you did not delete the existing ROOT directory.
> 
>> I am using Eclipse Mars.2  Is it possible I simply implemented the
>> suggestions incorrectly?  Below is what eclipse did to the
>> server.xml file.
> 
>> > path="/ROOT##000" reloadable="true" 
>> source="org.eclipse.jst.jee.server:ROOT##000">
> 
> I'm not an Eclipse user, but any IDE that blindly updates
> configuration files without your explicit permission sounds extremely
> dangerous.  Others may have suggestions about how to stop such bad
> behavior.  You really, really do not want to put any 
> elements in server.xml.
> 
> - Chuck

I just played with Eclipse Neon (newest release). It does copy over a
Tomcat configuration into your workspace, and then runs Tomcat from that
(sort of like RUNNING.txt).

That being said, Eclipse does not handle ROOT well at all by default. If
I tell Maven to have a final name of ROOT, then Eclipse edits the
workspace server.xml with:





CSEFive is my actual application.

If I name things normally, then the application comes up as CSEFive, and
the portion of server.xml reads as follows:





The only way that I know of to manage this from within Eclipse is the
following:

Right-mouse click on the project, and go the the following in the drop
down menu:

Properties->Web Project Settings

Change the Context root to /

Run your project from within Eclipse, and it will come up as
http://localhost:8080/

Eclipse will rewrite the server.xml in your workspace to:





In any case, once you move out of an Eclipse-controlled Tomcat, the WAR
file needs to be named ROOT.war (case matters, even on Windows).

You'll need to move Tomcat's default ROOT web application to another
location.

In short, it's an Eclipse artifact.

. . . just my two cents
/mde/



signature.asc
Description: OpenPGP digital signature

RE: Servlet overridden by Apache Tomcat welcome page?

[Caldarale, Charles R]

> From: Paul Roubekas [mailto:paul@orthogroup.holdings] 
> Subject: Re: Servlet  overridden by Apache Tomcat welcome 
> page?

> After making the above suggested changes the desired behavior goes
> away.  Now instead of my application's landing page I get the tomcat
> welcome page.

You appear to have ignored what Hassan S said earlier in this thread; I'll 
repeat it here:

"Assuming a default installation, you should see the index.jsp page
associated with the *default context*, which in Tomcat is named
ROOT (case sensitive).

"You need to move or delete the existing ROOT and rename your
own WAR file (or directory) to ROOT."

I suspect you did not delete the existing ROOT directory.

> I am using Eclipse Mars.2  Is it possible I simply
> implemented the suggestions incorrectly?  Below is what eclipse did to
> the server.xml file.

>  path="/ROOT##000" reloadable="true"
> source="org.eclipse.jst.jee.server:ROOT##000">

I'm not an Eclipse user, but any IDE that blindly updates configuration files 
without your explicit permission sounds extremely dangerous.  Others may have 
suggestions about how to stop such bad behavior.  You really, really do not 
want to put any  elements in server.xml.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-- 
The people that bring you Usque .

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

Re: Servlet overridden by Apache Tomcat welcome page?

[Paul Roubekas]

On 7/3/2016 5:21 PM, Paul Roubekas wrote:
> On 7/3/2016 4:41 PM, Mark Thomas wrote:
>> On 03/07/2016 18:37, Paul Roubekas wrote:
>>
>>> Changes that need to be made to the server.xml file
>>> The below list of changes are for the conf/server.xml file.  A new XML
>>> element needs to be added to the  XML stanza.
>>> Within the  element stands a  element needs to be added. 
>>> The path= attribute for the  element needs to be blank. 
>>> The docbase= attribute needs to be equal to the .WAR file root
>>> directory.  In this example Abc_Website03.  I'm not sure
>>> the debug= attribute needs to be in the context element.  But I wasn't
>>> going to spend time testing it.  I am also not sure
>>> if the reloadable= attribute is required. But once again in the interest
>>> of saving time it was not tested with the reloadable= attribute removed.
>>> .
>>> .
>>> .
>>>  >> unpackWARs="true" autoDeploy="true">
>>>
>>> >> reloadable="true">
>> That is very bad advice. It will result in double deployment of that web
>> application.
>>
>> If you want to deploy a web application as the default web application,
>> name it ROOT.war (ROOT if a directory) as per the docs. [1]
>>
>> If you want to retain some version identified in the name, use a Context
>> Version, e.g. ROOT##my-version-string.war
>>
>> Mark
>>
>>
>> [1] http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Naming
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> Thank you very much for the correction Mark.  I will change my
> implementation and notes.  I did not run across the link you gave me
> during my research.
>
>
After making the above suggested changes the desired behavior goes
away.  Now instead of my application's landing page I get the tomcat
welcome page. I am using Eclipse Mars.2  Is it possible I simply
implemented the suggestions incorrectly?  Below is what eclipse did to
the server.xml file.

  


-- 
The people that bring you Usque .

Re: Servlet overridden by Apache Tomcat welcome page?

[Paul Roubekas]

On 7/3/2016 4:41 PM, Mark Thomas wrote:
> On 03/07/2016 18:37, Paul Roubekas wrote:
>
>> Changes that need to be made to the server.xml file
>> The below list of changes are for the conf/server.xml file.  A new XML
>> element needs to be added to the  XML stanza.
>> Within the  element stands a  element needs to be added. 
>> The path= attribute for the  element needs to be blank. 
>> The docbase= attribute needs to be equal to the .WAR file root
>> directory.  In this example Abc_Website03.  I'm not sure
>> the debug= attribute needs to be in the context element.  But I wasn't
>> going to spend time testing it.  I am also not sure
>> if the reloadable= attribute is required. But once again in the interest
>> of saving time it was not tested with the reloadable= attribute removed.
>> .
>> .
>> .
>>  > unpackWARs="true" autoDeploy="true">
>>
>> > reloadable="true">
> That is very bad advice. It will result in double deployment of that web
> application.
>
> If you want to deploy a web application as the default web application,
> name it ROOT.war (ROOT if a directory) as per the docs. [1]
>
> If you want to retain some version identified in the name, use a Context
> Version, e.g. ROOT##my-version-string.war
>
> Mark
>
>
> [1] http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Naming
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
Thank you very much for the correction Mark.  I will change my
implementation and notes.  I did not run across the link you gave me
during my research.


-- 
The people that bring you Usque .

Re: Tomcat 7 and SHA-1

[Greg Beresnev]

Thanks folks, appreciate your time and suggestions!
On 3 Jul 2016 3:44 a.m., "Christopher Schultz" 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Daniel,
>
> On 7/1/16 6:28 PM, Daniel Savard wrote:
> > 2016-07-01 16:21 GMT-04:00 Christopher Schultz
> >  >> :
> >
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >>
> >> Greg,
> >>
> >> On 7/1/16 3:03 AM, Greg Beresnev wrote:
> >>> Thanks Daniel - any idea which cipher in particular needs to
> >>> be absent in order for the SHA-1-based
> >>> connection/authentication was rejected/failed?
> >>
> >> I'm afraid Daniel may have confused the issue, because the
> >> certificate-signing algorithm is completely independent of any
> >> cipher suites that you may use for the encrypted TLS connection.
> >>
> >> FWIW, at $work, we typically filter-out anything that looks like
> >> this:
> >>
> >> NULL|_anon_|_DHE_|EXPORT|RC4|MD5|SHA$
> >>
> >> But there's no way I know of to reject the local server
> >> certificate if it doesn't meet some kind of criteria.
> >>
> >> I checked, and Nagios's check_http utility does NOT have a check
> >> for anything about a certificate other than it's expiration date.
> >> This seems like a good thing to add to that tool (along with
> >> complaining about support for certain protocols like SSLv3).
> >>
> >> There are other tools you could use, such as Mark's suggestion
> >> of using Qualys's ssltest site.
> >>
> >>
> > In fact, to enforce SHA-2 (which is the same as SHA-256) you just
> > have to switch to TLSv1.2 and nothing less. As per the RFC 5246
> > https://tools.ietf.org/html/rfc5246 SHA-2 is mandatory, paragraph
> > 1.2.
>
> I think you are misreading that RFC: there is no requirement in
> TLSv1.2 that certificates must be signed using SHA-2.
>
> What it says is that all new cipher suites defined by TLSv1.2 use
> SHA256, not that the old cipher suites cannot be used.
>
> For example, Microsoft.com will happily establish a TLSv1.2 connection
> using any of the following ciphers:
>
> SSL_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> TLS_RSA_WITH_AES_128_CBC_SHA
>
> For example (ECDHE-RSA-AES128-SHA is what OpenSSL calls
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA):
>
> $ openssl s_client -cipher ECDHE-RSA-AES128-SHA \
>   -connect microsoft.com:443
> [...]
> - ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES128-SHA
>
> > Chris, you are right, the cipher suite is something different from
> > the HMAC for the certificate itself. However, if the user wants to
> > ban the SHA-1 from the negociated symmetric encryption algorithm,
> > he will have to set a proper cipher suite to exclude anything
> > without SHA-256 and more from the accepted ciphers. You have to
> > experiment with the openssl cipher command to find out a proper
> > combination.
>
> There are hashing algorithms supported which are neither SHA-1 nor
> SHA-256, so everyone should be aware of that, too. Obvious examples
> are the other SHA-2 hashes (SHA384, SHA512). I thought there were
> others, but it appears I was thinking of PGP (RIPEMD-160 came to
> mind). Section 7.4.1.4.1 defines the signature algorithms to be NULL,
> MD5, SHA1, SHA224, SHA256, SHA384, and SHA512.
>
> Greg only mentioned that he wants to enforce the use of
> better-than-SHA1 certificate-signing algorithms, presumably for both
> server certificates as well as client certificates. The easiest way to
> do that is to revoke all certificates that used SHA-1 as the signing
> algorithm, or, better yet, revoke the certificate that was used to
> sign all of those client-certificates and create a new certificate to
> sign using the SHA256 algorithm.
>
> Mark's suggestion of using the X509UsernameRetrieverClassName is
> probably the best way to implement this, because you can just extend
> the default X509UsernameRetriever, check the certificate for whatever
> requirements you have, and then delegate the "real work" to the
> superclass (which is pretty trivial, since it's just grabbing the CN
> from the certificate).
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXd/1tAAoJEBzwKT+lPKRYxs0P/021QUjfxCbjsHWmhZeUW2NV
> BBKcDx6X4bdZDWLe9m39KW8ryufSFusxIAmq0h4k7KQ8B2i7tfqZqrOkyjzXE4DV
> 6YB0KYvPujnQzPW75GjQeWq3xPqp/iM4pwIaNHwliTlQDrVT5azcKym6b0jXIcp1
> GM+bxdXFgy1L3E4sGiR0Ip5h8c45T0OTLLvFGn6MpKTnpeNsmFtqtAFZ6zmrIwUA
> +zGfpZC7YOKMgbeBSQx2b5C+08UHi7kCy3DiXOpwjmdYfYv5OHxLgy0hRGpjPW2v
> EZqnLpvuTWNBB7VqYju8jIUxg7IjkgjVQ+0Bat5ucBO6GgAZ7VzvHMD0cTPmyTj+
> ASOFITX59YPY1N4hGz+dGhUE/0mTxsUuVmGFlkmtL3HkDBe0hYLij2RSO4KCsW9x
> HyW2OlwF+ORLMG8nSdkiwVFHcZ6kB+k+wa+JGWQrU7yU12CvjJ80QiY9c9MJEw0r
> 

Re: Servlet overridden by Apache Tomcat welcome page?

[Mark Thomas]

On 03/07/2016 18:37, Paul Roubekas wrote:

> Changes that need to be made to the server.xml file
> The below list of changes are for the conf/server.xml file.  A new XML
> element needs to be added to the  XML stanza.
> Within the  element stands a  element needs to be added. 
> The path= attribute for the  element needs to be blank. 
> The docbase= attribute needs to be equal to the .WAR file root
> directory.  In this example Abc_Website03.  I'm not sure
> the debug= attribute needs to be in the context element.  But I wasn't
> going to spend time testing it.  I am also not sure
> if the reloadable= attribute is required. But once again in the interest
> of saving time it was not tested with the reloadable= attribute removed.
> .
> .
> .
>   unpackWARs="true" autoDeploy="true">
> 
>  reloadable="true">

That is very bad advice. It will result in double deployment of that web
application.

If you want to deploy a web application as the default web application,
name it ROOT.war (ROOT if a directory) as per the docs. [1]

If you want to retain some version identified in the name, use a Context
Version, e.g. ROOT##my-version-string.war

Mark


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

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

Re: Servlet overridden by Apache Tomcat welcome page?

[Paul Roubekas]

On 7/2/2016 4:24 PM, Paul Roubekas wrote:
> Servlet  overridden by Apache Tomcat welcome page?
>
>  
>
> Not sure I am using the proper name for what I am calling the "Apache
> Tomcat welcome page".  What I am calling the "Apache Tomcat welcome
> page" is the page that comes up when http://localhost:8080 is entered as
> the address on an internet browser.
>
>  
>
> Windows 7 (development workstation)
>
> Fedora 23 (web server)
>
> Apache Tomcat 7.0.68
>
> Apache TomEE 1.7.4
>
> Eclipse Mars 2 (4.5.2)
>
>  
>
> I have a single instance of Tomcat.  CATALINA_BASE is not used, just
> CATALINA_HOME.  The WEB-INF/web.xml has been configured as follows.
>
>  
>
> 
>
> http://www.w3.org/2001/XMLSchema-instance;
> xmlns="http://java.sun.com/xml/ns/javaee;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; id="WebApp_ID"
> version="3.0">
>
>  
>
> 
>
> 
>
> 
>
> Abc
>
> 
>
>The web site for Abc software
>
> 
>
>  
>
> 
>
> 
>
> 
>
> 
>
>HomeServlet
>
>software.Abc.website.HomeServlet
>
>1
>
>  
>
>  
>
> 
>
>  
>
>HomeServlet
>
>/AbcLandingPage
>
>  
>
>  
>
>  
>
>  
>
>  Protect Donation page
>
>  /DonateServlet
>
>  GET
>
>  POST   
>
>  
>
>  
>
>  CONFIDENTIAL
>
>  
>
>   
>
>  
>
>
>
> 
>
> 
>
> 
>
>  
>
> 
>
> 
>
> 
>
> 
>
> AbcLandingPage
>
> index.html
>
> index.htm
>
> index.jsp
>
> 
>
> 
>
>  
>
> As per these instructions
> (http://wiki.metawerx.net/wiki/HowToUseAServletAsYourMainWebPage) this
> configuration should result in the HomeServlet being the first page
> rendered when the URL http://myDomain.com is entered as the destination
> address in an internet browser.  But these instructions are generic for
> the Java Servlet 2.4 specification.  In this
> (http://wiki.apache.org/tomcat/HowTo#How_do_I_override_the_default_home_page_loaded_by_Tomcat.3F)FAQ
> for Tomcat it is suggest that meta tag refresh be used.  It seems the
> Tomcat meta tag refresh instruction were written before the Java Servlet
> 2.4 specification was written because other research
> (https://en.wikipedia.org/wiki/Meta_refresh) points out that the use of
> the meta tag refresh method is gone out of use because it can prevent
> the end user from being able to use the back button successfully and it
> is considered as one of the Un-ethical SEO process by the Search
> Engines.  The current version of the Java Servlet Specification is 3.0.
> (https://jcp.org/aboutJava/communityprocess/final/jsr315/index.html). 
>
>  
>
> Question 1) Is my assumption correct that the reason my web.xml is not
> working is because the Tomcat/Tomee welcome page is specified in such a
> way that it takes precedence over the web.xml settings in my websites
> .WAR file?
>
>  
>
> Question 2) Is there a way to have my .WAR file WEB-INF/web.xml take
> precedence over the Tomcat welcome page without uninstalling the Tomcat
> welcome page?

*For the sake of people who may search the forum archives, the answer is
provided below.*

There are changes that need to be made to the web.xml file and to the
server.xml file for this to work.

Changes that need to be made to the web.xml file.
The below list of changes are for the WEB-INF/web.xml file not the
server level conf/web.xml file.  A prerequisite is that the 
and  are in the  XML stanza.  The
 XML element is not required for the task at hand.  It
was added
so the first user, after a tomee restart, did not experience poor
performance.

   HomeServlet
   software.abc.website.HomeServlet
   1
 

A  XML stanza needs to be made also.  The
 in this  stanza must agree with the
 in the  stanza. The  does not need
to match the .  The  tag must
match the  tag in the  stanza.

 
   HomeServlet
   /AbcLandingPage
 

A  stanza must also be added.  The 
entries are processed in the order listed.  The value for the
 must match the value for the  in the
 stanza earlier in the configuration file. In
this example the value is AbcLandingPage.


AbcLandingPage
index.html
index.htm
index.jsp


A complete web.xml file is listed below.

http://www.w3.org/2001/XMLSchema-instance;
xmlns="http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; id="WebApp_ID"
version="3.0">




Abc

   The web site for Abc software






   HomeServlet
   software.abc.website.HomeServlet
   1
 


 
   HomeServlet
   /AbcLandingPage
 

 
 
 Protect Donation page
 

Re: WebSockets

[Mark Thomas]

On 03/07/2016 11:04, Martin Funk wrote:
> Hi,
> 
> I'm into my first steps of using the WebSocket API.
> Things are quite nice so far, WebSockets, used the right way, might open up
> a complete new type of WebApplications.
> 
> I've got a question though, is there a way to configure Tomcat to announce
> the annotated ServerEndpoints, it comes across while starting the server,
> in the catalina log?

No. That does not appear to be logged at any level.

What are you trying to achieve?

Mark


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

Re: tomcat 7 connection pool validation interval

[Phil Steitz]

On 7/1/16 11:35 PM, Nir Dweck wrote:
> -Original Message-
> From: Phil Steitz [mailto:phil.ste...@gmail.com] 
> Sent: Friday, July 01, 2016 9:16 PM
> To: users@tomcat.apache.org
> Subject: Re: tomcat 7 connection pool validation interval
>
> On 7/1/16 7:14 AM, Nir Dweck wrote:
>> -Original Message-
>> From: Phil Steitz [mailto:phil.ste...@gmail.com]
>> Sent: Thursday, June 30, 2016 6:57 PM
>> To: Tomcat Users List
>> Subject: Re: tomcat 7 connection pool validation interval
>>
>>
>>
> On Jun 30, 2016, at 9:32 AM, Nir Dweck  wrote:
>
> I am using tomcat connection  pool (tomcat 7) in my application (java 
> application) to connect to a remote Oracle DB on an Azure machine. My 
> connection pool configuration is as follow:
>
>PoolProperties p = new PoolProperties();
>p.setUrl(connString);
>p.setUsername(user);
>p.setPassword(password);
>p.setDriverClassName("oracle.jdbc.OracleDriver");
>p.setValidationQuery("SELECT 1 from dual");
>p.setValidationInterval(1 * 6/2);
>p.setTimeBetweenEvictionRunsMillis(1 * 6/2);
>p.setTestOnBorrow(true);
>p.setTestWhileIdle(true);
>p.setMinIdle(10);
>p.setInitialSize(10);
> However looking at the capture file, I see that the connections are not 
> checked every 30 seconds as I expected. One connection is checked 
> correctly, the others are checked after 3 times the configuration (180 
> second). then again only some of the connections are checked and after a 
> while it seems to stable on twice the configuration period (every 60 
> seconds).
>
> I tested it with different configured time and different pool size, all 
> had a instability period in which each time only part of the connections 
> were checked and eventually it stabled on checks of all the connections 
> every twice the configured time.
> What am I missing?
> Thanks,
 Most likely the connections not being tested are checked out to clients 
 when the pool maintenance runs.  Assuming you are using the default DBCP 
 pool, >>only idle connections (meaning waiting in the pool)  are tested by 
 the maintenance thread.
 Phil
>>> No, all connection are idle, but still looking at wireShark the validation 
>>> query is sent every twice the TimeBetweenEvictionRunsMillis.
>> I am sorry I should have been more clear.  The term, "idle" is a little 
>> confusing here.  I should have said connections are only checked when they 
>> are not >checked out to client threads.  A connection can be "idle" from the 
>> DB standpoint but still checked out to a client.  A connection that is 
>> checked out to a >client will not be tested by the pool maintenance thread.  
>> Are there clients using the pool while you are running this test?
>> I notice now a parameter not supported by DBCP, so I guess you must be using 
>> the tomcat-jdbc pool.  It looks to me like it defines "idle" the same way 
>> DBCP does - in other words above statements are true for that pool too.
>> It is also possible that setting validationInterval to a value <= 
>> timeBetweenEvictionRuns may cause some validations to be suppressed, since 
>> the former is a >max frequency.
>> Phil
> Hi Phil,
> I understood you correctly, none of the connections are held by any client. 
> All are idle in the pool. I tried also setting timeBetweenEvictionRuns to 
> half validationInterval, but still, the best I get is that the connections 
> are validated in half the frequency I requested (every 2 * 
> validationInterval). And yes I am using tomcat-jdbc pool.

Sorry I misunderstood you.  Try going the other way - making sure
that validationInterval >> timeBetweenEvictionRuns, or get rid of
the validationInterval parameter altogether.  The validationInterval
setting is designed to *suppress* excess validation - i.e., to make
sure that connections are not validated too frequently.  See the
description of this parameter in [1].

Phil
[1]
https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Tomcat_JDBC_Enhanced_Attributes

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

Re: Servlet overridden by Apache Tomcat welcome page?

[Hassan Schroeder]

On Sat, Jul 2, 2016 at 1:24 PM, Paul Roubekas  wrote:

> What I am calling the "Apache Tomcat welcome
> page" is the page that comes up when http://localhost:8080 is entered as
> the address on an internet browser.

Assuming a default installation, you should see the index.jsp page
associated with the *default context*, which in Tomcat is named
ROOT (case sensitive).

You need to move or delete the existing ROOT and rename your
own WAR file (or directory) to ROOT.

HTH,
-- 
Hassan Schroeder  hassan.schroe...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
Consulting Availability : Silicon Valley or remote

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

WebSockets

[Martin Funk]

Hi,

I'm into my first steps of using the WebSocket API.
Things are quite nice so far, WebSockets, used the right way, might open up
a complete new type of WebApplications.

I've got a question though, is there a way to configure Tomcat to announce
the annotated ServerEndpoints, it comes across while starting the server,
in the catalina log?

Have fun,

Martin