RE: [External] Re: Security Headers Implementation in Tomcat 6.x version

[Shaik, Mohammad N.]

Hi Olaf & Chris,

By placing HTTPD 2.x server in front of Tomcat 6, is it possible to hide Tomcat 
6 from external world? I just don’t want people to find out that I am using 
Tomcat 6, instead I want them to know that I am using httpd 2.x server. Is this 
possible?

I just need Apache HTTPD server to take care of headers and let Tomcat do rest 
of the stuff (which it is already doing in my case). Do I still need to 
configure anything other than headers in my case?


Regards,
Mohammad

-Original Message-
From: Olaf Kock [mailto:tom...@olafkock.de]
Sent: 31 May 2017 16:38
To: Tomcat Users List 
Subject: [External] Re: Security Headers Implementation in Tomcat 6.x version

Am 29.05.2017 um 13:34 schrieb Shaik, Mohammad N.:
> Hello Olaf,
>
> Thanks for your response!
>
> Based on your inputs, we are thinking to put Apache httpd in front of Tomcat 
> 6 server, since our header configuration is going to be static.
>
> Can you please help us in identifying which version of Apache HTTP Server we 
> can use for Tomcat 6 version? Also, it will be great if you can share some 
> guidelines on how to implement Apache in front of Tomcat.

For completeness sake I'd like to answer a few of these questions, rather 
briefly. It seems that you're deep into implementing Christopher's solution of 
compiling the newer filters for Tomcat 6.

Every current Apache httpd is fine, no version restriction. Especially:
Choose one that will get updates for quite a while, not like the outdated 
Tomcat version you're running. Read on mod_proxy, mod_proxy_ajp, mod_jk and 
mod_proxy_http, which are all keywords on the connection between Apache and 
tomcat. Once you've set this up, setting the headers is a matter of adding the 
"Header" directive to httpd's configuration. I understand though, that setting 
up the connection can be some task if you've never done that. Especially if 
you're using https, and also refer to it in your webapp's code (e.g. to 
validate client certs) - but as you give no clue you're doing that, I'm 
assuming you don't and the setup would be easy.

Anyway, feel free to utilize the newer code - I just wanted this information to 
be in this thread as well. However, once you're done with
it: Utilize even more newer code and prepare to migrate away from your 
discontinued tomcat version.

Olaf



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




This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy.
__

www.accenture.com

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

A question about websocket API-- Annotation ServerEndpoint

[王琳]

Hi friend:
 i have a question. use Tomcat 8.5.15
@ServerEndpoint API has 'value' summary. This value mapping url.When the url 
has parameter,use {}.
for example:
@ServerEndpoint(value = 
"/websocket/fmsWebsocket/{userId}/{companyId}/{groupId}")

js:var url = "ws://192.168.0.6:8080/note/websocket/fmsWebsocket/1/1/1";

My question is when {userId} is null or {companyId} is null or {groupId} is 
null . How  write @ ServerEndpoint(value=??).
and
js: var url = "ws://192.168.0.6:8080/note/websocket/fmsWebsocket///1";
is right?

Thank you very much!

A question about websocket API-- Annotation ServerEndpoint

[王琳]

Hi friend:
 i have a question. use Tomcat 8.5.15
@ServerEndpoint API has 'value' summary. This value mapping url.When the url 
has parameter,use {}.
for example:
@ServerEndpoint(value = 
"/websocket/fmsWebsocket/{userId}/{companyId}/{groupId}")

js:var url = "ws://192.168.0.6:8080/note/websocket/fmsWebsocket/1/1/1";

My question is when {userId} is null or {companyId} is null or {groupId} is 
null . How  write @ ServerEndpoint(value=??).
and
js: var url = "ws://192.168.0.6:8080/note/websocket/fmsWebsocket///1";
is right?

Thank you very much!

Re: Tomcat 8/NIO performance discrepancies

[Astrat Goe]

> On Jun 8, 2017, at 4:28 AM, Mark Thomas  wrote:
> 
> On 07/06/17 20:25, Piyush Kumar Nayak wrote:
>> Mark,
>> 
>> It may not be important, but just to be clear, I'm not testing on localhost. 
>> My JMeter and Tomcat are on different machines, with 1 Gbps NIC interfaces 
>> between them.
> 
> I'm aware you were using two machines but that doesn't appear to be a
> significant factor in the observed differences.
> 
>> Can you also please provide some pointers on the following:
>> - How did you disable session on your JSP?
> 
> Look in the index.jsp for the ROOT web application that ships with
> Tomcat for an example. Full details are in the JSP specification.
> 
>> - Did you observe anything that suggests that the client is not closing the 
>> connections?
> 
> Yes. This looks like a JMeter issue. It isn't the first time JMeter has
> given strange results under load. I've switched to ab which I have found
> to be generally much more reliable for these sorts of tests.
> 
> I'm still seeing significant differences in BIO with and without an
> executor.
> 
> I'm still looking for the root cause. I have noticed that without an
> executor I see far fewer keep-alive requests than I'd expect. That could
> explain the difference, or some of it at least.
> 
> Mark
> 
> 
>> I did not specify the implementation for the HTTP sampler that I configured 
>> with JMeter, and it is not set in my jmeter.properties file. So, going by 
>> JMeter's documentation, Apache HttpComponents HttpClient 4.x. should be in 
>> use.
>> 
>> Thanks
>> Piyush.
>> 
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org] 
>> Sent: Wednesday, June 07, 2017 8:27 PM
>> To: Tomcat Users List 
>> Subject: Re: Tomcat 8/NIO performance discrepancies
>> 
>> On 06/06/17 09:10, Piyush Kumar Nayak wrote:
>>> Thanks, Mark.
>>> 
>>> Here are some additional details.
>> 
>> Thanks. These help a lot to make sure we are testing (at least roughly) the 
>> same thing.
>> 
>>> I am using Apache JMeter to inject load. I am using a simple hello-world 
>>> JSP.
>>> 
>>> The test JMX simulates 100 concurrent user threads with a ramp-up of 5 secs 
>>> and uses an HTTP Cookie Manager, that reuses cookies for each user thread.
>> 
>> I've disabled session in the JSP for my test and used a simpler JSP.
>> That should amplify any difference in connector performance.
>> 
>> I'm also testing on localhost.
>> 
>>> I have disabled access log in tomcat. All the other server.xml settings are 
>>> the default.
>>> 
>>> 
>>> The BIO with Executor configuration we are using is:
>>> >>maxThreads="150" minSpareThreads="4"/>
>>> 
>>> >>   connectionTimeout="2"
>>>   redirectPort="8443" />
>> 
>> FYI for anyone following along. That is a non-executor config. The connector 
>> needs to specify the executor it wants to used.
>> 
>> I do see odd behaviour with BIO + executor. It locks up very easily. It 
>> appears that the client isn't closing the connections. I don't see this 
>> problem with BIO but that may be related to how BIO without an executor 
>> handles large numbers of connections.
>> 
>> If I lower the client thread count, the odd behaviour stops and I do see 
>> notably higher throughput with BIO + executor. That is unexpected.
>> 
>> My initial thoughts are maybe a contention issue related to the thread pool. 
>> I'm continuing to investigate. I plan to look at performance first and then 
>> the locking up.
>> 
>> Mark
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: Tomcat 8/NIO performance discrepancies

[Astrat Goe]

> On Jun 8, 2017, at 4:28 AM, Mark Thomas  wrote:
> 
> On 07/06/17 20:25, Piyush Kumar Nayak wrote:
>> Mark,
>> 
>> It may not be important, but just to be clear, I'm not testing on localhost. 
>> My JMeter and Tomcat are on different machines, with 1 Gbps NIC interfaces 
>> between them.
> 
> I'm aware you were using two machines but that doesn't appear to be a
> significant factor in the observed differences.
> 
>> Can you also please provide some pointers on the following:
>> - How did you disable session on your JSP?
> 
> Look in the index.jsp for the ROOT web application that ships with
> Tomcat for an example. Full details are in the JSP specification.
> 
>> - Did you observe anything that suggests that the client is not closing the 
>> connections?
> 
> Yes. This looks like a JMeter issue. It isn't the first time JMeter has
> given strange results under load. I've switched to ab which I have found
> to be generally much more reliable for these sorts of tests.
> 
> I'm still seeing significant differences in BIO with and without an
> executor.
> 
> I'm still looking for the root cause. I have noticed that without an
> executor I see far fewer keep-alive requests than I'd expect. That could
> explain the difference, or some of it at least.
> 
> Mark
> 
> 
>> I did not specify the implementation for the HTTP sampler that I configured 
>> with JMeter, and it is not set in my jmeter.properties file. So, going by 
>> JMeter's documentation, Apache HttpComponents HttpClient 4.x. should be in 
>> use.
>> 
>> Thanks
>> Piyush.
>> 
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org] 
>> Sent: Wednesday, June 07, 2017 8:27 PM
>> To: Tomcat Users List 
>> Subject: Re: Tomcat 8/NIO performance discrepancies
>> 
>> On 06/06/17 09:10, Piyush Kumar Nayak wrote:
>>> Thanks, Mark.
>>> 
>>> Here are some additional details.
>> 
>> Thanks. These help a lot to make sure we are testing (at least roughly) the 
>> same thing.
>> 
>>> I am using Apache JMeter to inject load. I am using a simple hello-world 
>>> JSP.
>>> 
>>> The test JMX simulates 100 concurrent user threads with a ramp-up of 5 secs 
>>> and uses an HTTP Cookie Manager, that reuses cookies for each user thread.
>> 
>> I've disabled session in the JSP for my test and used a simpler JSP.
>> That should amplify any difference in connector performance.
>> 
>> I'm also testing on localhost.
>> 
>>> I have disabled access log in tomcat. All the other server.xml settings are 
>>> the default.
>>> 
>>> 
>>> The BIO with Executor configuration we are using is:
>>> >>maxThreads="150" minSpareThreads="4"/>
>>> 
>>> >>   connectionTimeout="2"
>>>   redirectPort="8443" />
>> 
>> FYI for anyone following along. That is a non-executor config. The connector 
>> needs to specify the executor it wants to used.
>> 
>> I do see odd behaviour with BIO + executor. It locks up very easily. It 
>> appears that the client isn't closing the connections. I don't see this 
>> problem with BIO but that may be related to how BIO without an executor 
>> handles large numbers of connections.
>> 
>> If I lower the client thread count, the odd behaviour stops and I do see 
>> notably higher throughput with BIO + executor. That is unexpected.
>> 
>> My initial thoughts are maybe a contention issue related to the thread pool. 
>> I'm continuing to investigate. I plan to look at performance first and then 
>> the locking up.
>> 
>> Mark
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: Tomcat 8/NIO performance discrepancies

[Astrat Goe]

> On Jun 8, 2017, at 4:28 AM, Mark Thomas  wrote:
> 
> On 07/06/17 20:25, Piyush Kumar Nayak wrote:
>> Mark,
>> 
>> It may not be important, but just to be clear, I'm not testing on localhost. 
>> My JMeter and Tomcat are on different machines, with 1 Gbps NIC interfaces 
>> between them.
> 
> I'm aware you were using two machines but that doesn't appear to be a
> significant factor in the observed differences.
> 
>> Can you also please provide some pointers on the following:
>> - How did you disable session on your JSP?
> 
> Look in the index.jsp for the ROOT web application that ships with
> Tomcat for an example. Full details are in the JSP specification.
> 
>> - Did you observe anything that suggests that the client is not closing the 
>> connections?
> 
> Yes. This looks like a JMeter issue. It isn't the first time JMeter has
> given strange results under load. I've switched to ab which I have found
> to be generally much more reliable for these sorts of tests.
> 
> I'm still seeing significant differences in BIO with and without an
> executor.
> 
> I'm still looking for the root cause. I have noticed that without an
> executor I see far fewer keep-alive requests than I'd expect. That could
> explain the difference, or some of it at least.
> 
> Mark
> 
> 
>> I did not specify the implementation for the HTTP sampler that I configured 
>> with JMeter, and it is not set in my jmeter.properties file. So, going by 
>> JMeter's documentation, Apache HttpComponents HttpClient 4.x. should be in 
>> use.
>> 
>> Thanks
>> Piyush.
>> 
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org] 
>> Sent: Wednesday, June 07, 2017 8:27 PM
>> To: Tomcat Users List 
>> Subject: Re: Tomcat 8/NIO performance discrepancies
>> 
>> On 06/06/17 09:10, Piyush Kumar Nayak wrote:
>>> Thanks, Mark.
>>> 
>>> Here are some additional details.
>> 
>> Thanks. These help a lot to make sure we are testing (at least roughly) the 
>> same thing.
>> 
>>> I am using Apache JMeter to inject load. I am using a simple hello-world 
>>> JSP.
>>> 
>>> The test JMX simulates 100 concurrent user threads with a ramp-up of 5 secs 
>>> and uses an HTTP Cookie Manager, that reuses cookies for each user thread.
>> 
>> I've disabled session in the JSP for my test and used a simpler JSP.
>> That should amplify any difference in connector performance.
>> 
>> I'm also testing on localhost.
>> 
>>> I have disabled access log in tomcat. All the other server.xml settings are 
>>> the default.
>>> 
>>> 
>>> The BIO with Executor configuration we are using is:
>>> >>maxThreads="150" minSpareThreads="4"/>
>>> 
>>> >>   connectionTimeout="2"
>>>   redirectPort="8443" />
>> 
>> FYI for anyone following along. That is a non-executor config. The connector 
>> needs to specify the executor it wants to used.
>> 
>> I do see odd behaviour with BIO + executor. It locks up very easily. It 
>> appears that the client isn't closing the connections. I don't see this 
>> problem with BIO but that may be related to how BIO without an executor 
>> handles large numbers of connections.
>> 
>> If I lower the client thread count, the odd behaviour stops and I do see 
>> notably higher throughput with BIO + executor. That is unexpected.
>> 
>> My initial thoughts are maybe a contention issue related to the thread pool. 
>> I'm continuing to investigate. I plan to look at performance first and then 
>> the locking up.
>> 
>> Mark
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: Tomcat 8/NIO performance discrepancies

[Mark Thomas]

On 07/06/17 20:25, Piyush Kumar Nayak wrote:
> Mark,
> 
> It may not be important, but just to be clear, I'm not testing on localhost. 
> My JMeter and Tomcat are on different machines, with 1 Gbps NIC interfaces 
> between them.

I'm aware you were using two machines but that doesn't appear to be a
significant factor in the observed differences.

> Can you also please provide some pointers on the following:
> - How did you disable session on your JSP?

Look in the index.jsp for the ROOT web application that ships with
Tomcat for an example. Full details are in the JSP specification.

> - Did you observe anything that suggests that the client is not closing the 
> connections?

Yes. This looks like a JMeter issue. It isn't the first time JMeter has
given strange results under load. I've switched to ab which I have found
to be generally much more reliable for these sorts of tests.

I'm still seeing significant differences in BIO with and without an
executor.

I'm still looking for the root cause. I have noticed that without an
executor I see far fewer keep-alive requests than I'd expect. That could
explain the difference, or some of it at least.

Mark


> I did not specify the implementation for the HTTP sampler that I configured 
> with JMeter, and it is not set in my jmeter.properties file. So, going by 
> JMeter's documentation, Apache HttpComponents HttpClient 4.x. should be in 
> use.
> 
> Thanks
> Piyush.
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Wednesday, June 07, 2017 8:27 PM
> To: Tomcat Users List 
> Subject: Re: Tomcat 8/NIO performance discrepancies
> 
> On 06/06/17 09:10, Piyush Kumar Nayak wrote:
>> Thanks, Mark.
>>
>> Here are some additional details.
> 
> Thanks. These help a lot to make sure we are testing (at least roughly) the 
> same thing.
> 
>> I am using Apache JMeter to inject load. I am using a simple hello-world JSP.
>>
>> The test JMX simulates 100 concurrent user threads with a ramp-up of 5 secs 
>> and uses an HTTP Cookie Manager, that reuses cookies for each user thread.
> 
> I've disabled session in the JSP for my test and used a simpler JSP.
> That should amplify any difference in connector performance.
> 
> I'm also testing on localhost.
> 
>> I have disabled access log in tomcat. All the other server.xml settings are 
>> the default.
>>
>>
>> The BIO with Executor configuration we are using is:
>> > maxThreads="150" minSpareThreads="4"/>
>>
>> >connectionTimeout="2"
>>redirectPort="8443" />
> 
> FYI for anyone following along. That is a non-executor config. The connector 
> needs to specify the executor it wants to used.
> 
> I do see odd behaviour with BIO + executor. It locks up very easily. It 
> appears that the client isn't closing the connections. I don't see this 
> problem with BIO but that may be related to how BIO without an executor 
> handles large numbers of connections.
> 
> If I lower the client thread count, the odd behaviour stops and I do see 
> notably higher throughput with BIO + executor. That is unexpected.
> 
> My initial thoughts are maybe a contention issue related to the thread pool. 
> I'm continuing to investigate. I plan to look at performance first and then 
> the locking up.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

RE: Tomcat 8/NIO performance discrepancies

[Piyush Kumar Nayak]

Mark,

It may not be important, but just to be clear, I'm not testing on localhost. My 
JMeter and Tomcat are on different machines, with 1 Gbps NIC interfaces between 
them.

Can you also please provide some pointers on the following:
- How did you disable session on your JSP?
- Did you observe anything that suggests that the client is not closing the 
connections?
I did not specify the implementation for the HTTP sampler that I configured 
with JMeter, and it is not set in my jmeter.properties file. So, going by 
JMeter's documentation, Apache HttpComponents HttpClient 4.x. should be in use.

Thanks
Piyush.

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, June 07, 2017 8:27 PM
To: Tomcat Users List 
Subject: Re: Tomcat 8/NIO performance discrepancies

On 06/06/17 09:10, Piyush Kumar Nayak wrote:
> Thanks, Mark.
> 
> Here are some additional details.

Thanks. These help a lot to make sure we are testing (at least roughly) the 
same thing.

> I am using Apache JMeter to inject load. I am using a simple hello-world JSP.
> 
> The test JMX simulates 100 concurrent user threads with a ramp-up of 5 secs 
> and uses an HTTP Cookie Manager, that reuses cookies for each user thread.

I've disabled session in the JSP for my test and used a simpler JSP.
That should amplify any difference in connector performance.

I'm also testing on localhost.

> I have disabled access log in tomcat. All the other server.xml settings are 
> the default.
> 
> 
> The BIO with Executor configuration we are using is:
>  maxThreads="150" minSpareThreads="4"/>
> 
> connectionTimeout="2"
>redirectPort="8443" />

FYI for anyone following along. That is a non-executor config. The connector 
needs to specify the executor it wants to used.

I do see odd behaviour with BIO + executor. It locks up very easily. It appears 
that the client isn't closing the connections. I don't see this problem with 
BIO but that may be related to how BIO without an executor handles large 
numbers of connections.

If I lower the client thread count, the odd behaviour stops and I do see 
notably higher throughput with BIO + executor. That is unexpected.

My initial thoughts are maybe a contention issue related to the thread pool. 
I'm continuing to investigate. I plan to look at performance first and then the 
locking up.

Mark

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


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

Re: Custom Webapp loading..

[Hassan Khan]

Thanks a lot Violeta

Adding the following code , It did the trick for embedded tomcat program...
List filterdJarfiles = getAppJarFilesAlone(folderName);

WebResourceRoot resources = new StandardRoot(contextNew);
for(File jf:filterdJarfiles){
   String st =
jf.getAbsolutePath().substring(0,jf.getAbsolutePath().lastIndexOf(File.separator));
   resources.addPreResources(new DirResourceSet(resources,
"/WEB-INF/lib",
 st, "/"));
}

contextNew.setResources(resources);
CustomLoader loader= new
CustomLoader(contextNew.getParentClassLoader(),contextNew);
contextNew.setLoader(loader);

But required to set the loader though..


Thanks a lot...

Hassan

On Fri, Jun 2, 2017 at 6:40 AM, Violeta Georgieva 
wrote:

> Hi,
>
> 2017-06-01 18:26 GMT+03:00 Hassan Khan :
> >
> > Any pointers to the problem .. pls... Have extended webapploader and use
>
> Instead of extending the class loader you might consider the new Web
> Application Resources feature:
> http://tomcat.apache.org/tomcat-8.5-doc/config/resources.html
>
> Regards,
> Violeta
>
> > the below function for adding jar in tomcat 6... for tomcat 8.5 the jar
> are
> > loading but not getting included in the classpath somehow...
> > /**
> >  * reflectively add a jar to the classloader. This only works when
> > called after super.start() has completed.
> >  */
> > private void addJar(final File jarRealFile) {
> > try {
> > final String jarPath = getFilePathRelativeToBase(
> jarRealFile);
> > final JarFile jarFile = new JarFile(jarRealFile);
> > final ClassLoader cl = getClassLoader();
> > if (cl instanceof WebappClassLoader) {
> > final WebappClassLoader wcl = (WebappClassLoader) cl;
> > final Class clazz = WebappClassLoader.class;
> > final Method addJar = clazz.getDeclaredMethod("addJar",
> new
> > Class[]{String.class, JarFile.class, File.class});
> > addJar.setAccessible(true);
> > addJar.invoke(wcl, jarPath, jarFile, jarRealFile);
> > }
> > log("added jar " + jarRealFile.getCanonicalPath());
> > }
> > catch (IOException e) {
> > log("Exception accessing jar file: " + jarRealFile + ": " +
> > e.getMessage());
> > }
> > catch (SecurityException e) {
> > log("Exception finding method in WebappClassLoader to add jar
> > file: " + jarRealFile + ": " + e.getMessage());
> > }
> > catch (NoSuchMethodException e) {
> > log("Exception finding method in WebappClassLoader to add jar
> > file: " + jarRealFile + ": " + e.getMessage());
> > }
> > catch (IllegalArgumentException e) {
> > log("Exception calling method in WebappClassLoader to add jar
> > file: " + jarRealFile + ": " + e.getMessage());
> > }
> > catch (IllegalAccessException e) {
> > log("Exception calling method in WebappClassLoader to add jar
> > file: " + jarRealFile + ": " + e.getMessage());
> > }
> > catch (InvocationTargetException e) {
> > log("Exception calling method in WebappClassLoader to add jar
> > file: " + jarRealFile + ": " + e.getMessage());
> > }
> > }
> >
> > Thanks
> >
> >
> >
> >
> > On Wed, May 31, 2017 at 5:13 PM, Hassan Khan 
> > wrote:
> >
> > > So the precise exception is Only a type can be imported. ABC resolves
> to a
> > > package..
> > >
> > > Stacktrace is :
> > > at org.apache.jasper.compiler.DefaultErrorHandler.javacError(
> > > DefaultErrorHandler.java:102)
> > > at org.apache.jasper.compiler.ErrorDispatcher.javacError(
> > > ErrorDispatcher.java:212)
> > > at org.apache.jasper.compiler.JDTCompiler.generateClass(
> > > JDTCompiler.java:457)
> > > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:377)
> > > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:349)
> > > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:333)
> > > at org.apache.jasper.JspCompilationContext.compile(
> > > JspCompilationContext.java:600)
> > > at org.apache.jasper.servlet.JspServletWrapper.service(
> > > JspServletWrapper.java:368)
> > > at org.apache.jasper.servlet.JspServlet.serviceJspFile(
> > > JspServlet.java:385)
> > > at org.apache.jasper.servlet.JspServlet.service(JspServlet.
> java:329)
> > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
> > > at org.apache.catalina.core.ApplicationFilterChain.
> internalDoFilter(
> > > ApplicationFilterChain.java:231)
> > > at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> > > ApplicationFilterChain.java:166)
> > > at org.apache.catalina.core.ApplicationDispatcher.invoke(
> > > ApplicationDispatcher.java:728)
> > > at 

Is there a tomcat SP valve for ADFS IdP??

[ken edward]

Hello,

I have an Idp (my ADFS) and I have a tomcat server with a simple j2ee
web application.  I know I can stand up a keycloak sever, and use an
SP adapter for tomcat, BUT is there a way to simply install a tomcat
SP valve/libs that would talk to the IdP and bypass having to install
the keycloak server ? Kinda like this picketlink implementation (which
just merged with keycloak, but which is in a state of merger):

https://dzone.com/articles/saml-single-sign-on-with-tomcat-and-picketlink

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

Re: Tomcat 8/NIO performance discrepancies

[Mark Thomas]

On 7 June 2017 17:33:02 BST, Christopher Schultz  
wrote:
>Mark,
>
>On 6/7/17 10:57 AM, Mark Thomas wrote:
>> I do see odd behaviour with BIO + executor. It locks up very
>> easily. It appears that the client isn't closing the connections. I
>> don't see this problem with BIO but that may be related to how BIO
>> without an executor handles large numbers of connections.
>
>Was one of those BIOs supposed to be an "NIO"?

No. The second BIO should have been BIO without an executor.

Mark

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

Re: Tomcat 8/NIO performance discrepancies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/7/17 10:57 AM, Mark Thomas wrote:
> I do see odd behaviour with BIO + executor. It locks up very
> easily. It appears that the client isn't closing the connections. I
> don't see this problem with BIO but that may be related to how BIO
> without an executor handles large numbers of connections.

Was one of those BIOs supposed to be an "NIO"?

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

iQIcBAEBCAAGBQJZOCq+AAoJEBzwKT+lPKRYguwQAIgksfcD9loUKPQoR5LZsjgg
0VNrWVSmn5o4enqjIA5RLOt55XzflK7H4drBN2IB/QfJ/5Z40d9HYAHh9x5xdFst
kyY+3kFveS0GG8lxcutsl2sr2zetV9D7/vYsjfBcvgTB+5SPcwlL9oQjk0SKSO1I
lA6pQCTdEvNfXl+gYuY9SJnDQz6SXxsLXGjUNu7CN5xesjoTGyDdX43DwhGRmrRC
rn00X2sYOlELr2jQ6K7jEPKNM0O2gkIBqlbrYOMY4hbas8K9UI+m4apsk+jPoFeG
iSGUIl7bgLIymawFyWcjhAjkjm6qrzEorBkKbO+HqSr85SsvtyfCax39RmtzqTR/
VQZka/0NFSO57pScAeWz1hZxC92Iyxj6o3LLtWtm2vWFzyw8t9QhSMvtHxok5Moj
hENhDaz+bOv5s+yWjrvWJB7zHOD8mmjrZka8tmvTdcqoESFggXG1yYPwb3NrPHoc
p7/Sy97g21t8lCbPV2LUfa8mpEf0L6I98SpwxJ3dGuXS3r9FqdsTPPEIOXjD/fsv
/0GkupemYMk9AycIbCapK1xklj3qUDKuCsePtl3A/InZlPxiKMhQ357xz/sH1AT7
ZPCoItvp+gsEGb01moIX1TwaxQ8ubiXtHYgXAAAHhVeMUIrEmuW8b7nC4DXyMJUe
cmSZQy23IkBUaqVDcY/d
=gPB6
-END PGP SIGNATURE-

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

Re: Should Tomcat continue to support SSI?

[Emmanuel Bourg]

Le 7/06/2017 à 16:51, Christopher Schultz a écrit :

> What about separating SSI out into a separate (sub?) project and
> removing it from Tomcat core?

+1, I was about to suggest this as well.

Emmanuel Bourg

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

Re: Tomcat 8/NIO performance discrepancies

[Mark Thomas]

On 06/06/17 09:10, Piyush Kumar Nayak wrote:
> Thanks, Mark.
> 
> Here are some additional details.

Thanks. These help a lot to make sure we are testing (at least roughly)
the same thing.

> I am using Apache JMeter to inject load. I am using a simple hello-world JSP.
> 
> The test JMX simulates 100 concurrent user threads with a ramp-up of 5 secs 
> and uses an HTTP Cookie Manager, that reuses cookies for each user thread.

I've disabled session in the JSP for my test and used a simpler JSP.
That should amplify any difference in connector performance.

I'm also testing on localhost.

> I have disabled access log in tomcat. All the other server.xml settings are 
> the default.
> 
> 
> The BIO with Executor configuration we are using is:
>  maxThreads="150" minSpareThreads="4"/>
> 
> connectionTimeout="2"
>redirectPort="8443" />

FYI for anyone following along. That is a non-executor config. The
connector needs to specify the executor it wants to used.

I do see odd behaviour with BIO + executor. It locks up very easily. It
appears that the client isn't closing the connections. I don't see this
problem with BIO but that may be related to how BIO without an executor
handles large numbers of connections.

If I lower the client thread count, the odd behaviour stops and I do see
notably higher throughput with BIO + executor. That is unexpected.

My initial thoughts are maybe a contention issue related to the thread
pool. I'm continuing to investigate. I plan to look at performance first
and then the locking up.

Mark

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

Re: Should Tomcat continue to support SSI?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/7/17 4:58 AM, Mark Thomas wrote:
> Hi all,
> 
> One of the topics of discussion at TomcatCon was the features that
> have been removed in Tomcat 9 / could be removed in future Tomcat
> versions. One of those features was support for Server Side
> Includes.
> 
> The last meaningful change to the SSI code was ~4 years ago to fix
> this bug against Tomcat 7: 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=55176
> 
> There are several possible reasons for the lack of changes to this
> code. It could be that the SSI code is stable and folks are using
> it without issue. It could also be that no-one is using the code at
> all. If it is the latter, then in makes sense to remove it in
> Tomcat 9.
> 
> So, is anyone using SSI?

What about separating SSI out into a separate (sub?) project and
removing it from Tomcat core?

That way, a standard installation would no longer ship with it, but
users could add it if they wanted to.

It appears that everything is already well-encapsulated and the
filter/servlet could be moved to a separate (distribution) package.

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

iQIcBAEBCAAGBQJZOBLlAAoJEBzwKT+lPKRYccMP/3WdnmKvbuEBq7KHLVxAfbkU
GhEYgFQmEp6qR4376MNGGCPWRoBnItQlvqSddMVCuV8D6ROVhFPAjcjByoFeg7d5
hwBjAI8qVKulF2EJZSupPcl6LyKlvvQYlko25UiYRSxmhCP4RA7YAucf6plVoG65
m0RZjrdXjD9Ky8JN6WpLpm8wjcdCPTeZRodOmxHdqSGe5Nz2DBZSyWBeyw7tbbuZ
Y/zf4rb11nkCT0X1FLjAkop8llZcGEMGl8gtA5tZrPM9cQFQBAXPamDO0czJxEwL
ZuMePgTOKXZFdEwTon7sA01sldr3BZeus07SIbBMF2vO+VselfxTXRHVvHEdEwTq
tfTYKraZLDJHOqwutSuS/fNtUI1W6rl5MUWPggNeuRW/51U+oGncQEEptKjw5FLo
iN/MxXe60mw6+KCp3enWAlnQVw+i7MDCy6Ak1eJDuyUQfwalMBoGkqkWuJPzjUQh
hKQd00M71zeZM24AHz5NXcZ91eDz717PFCjBzHtlo1HwBUPYb1rSJSh83T1YXMzc
tNAy5RmOvWD9EcPyy8OWLJnULWp/leQg5ilVZZgFtzK7lfUPeVfGpcFtJntF7VwS
NbMR2zb+ZS8VZppdlGWXNx8F0TlpQSPyLxZpIZTyUZ5u8e7u9/mJJ3ryQcM0GuLu
tIlotwxLw8WZVIhRqkUu
=cVR/
-END PGP SIGNATURE-

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

Java9 modules and web applications

[Enrico Olivelli]

Hi, I am going to study how to migrate my web applications to java9.
I did not find and explicit document on this subject.
My first problem is:
Web applications are packaged in wars ( or exploded wars), which is the
relation with modules? The classes in web-inf/classes and in webinf/lib are
considered modules (automatic?)

I am using tomcat embedded, I think I will need to use tomcat jars as
automatic modules, does anyone already started to deal with this kind of
problems?

Thanks
Enrico
-- 


-- Enrico Olivelli

Should Tomcat continue to support SSI?

[Mark Thomas]

Hi all,

One of the topics of discussion at TomcatCon was the features that have
been removed in Tomcat 9 / could be removed in future Tomcat versions.
One of those features was support for Server Side Includes.

The last meaningful change to the SSI code was ~4 years ago to fix this
bug against Tomcat 7:
https://bz.apache.org/bugzilla/show_bug.cgi?id=55176

There are several possible reasons for the lack of changes to this code.
It could be that the SSI code is stable and folks are using it without
issue. It could also be that no-one is using the code at all. If it is
the latter, then in makes sense to remove it in Tomcat 9.

So, is anyone using SSI?

Thanks,

Mark

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

Re: Change of status code for ClientAbortExceptions - bug?

[Mark Thomas]

On 06/06/17 23:11, Konstantin Kolinko wrote:
> 2017-06-07 0:10 GMT+03:00 Mark Thomas :
>> On 06/06/17 15:08, Thomas Eliassen wrote:
>>>
>>> Is there some way to avoid having it logged as a 500 in the access log then?
>>
>> At the moment, no. And my preference is to avoid creating new
>> configuration options unless we have to.
>>
>>> ClientAbortExceptions are so frequent that it really pollutes the access 
>>> logs, drowns out 500s actually caused by the server side application, and 
>>> makes monitoring and debugging based on the access logging a lot harder.
>>
>> Fair point.
>>
>>> I'll also note that e.g. Jetty logs a 200 on ClientAbortExceptions.
>>
>> I've been looking at RFC 7231 in more detail.
>>
>> None of the status codes are ideal. Of course, they are intended for the
>> client which in this case is never going to see the status code anyway
>> but still...
>>
>> The general description of 2xx codes looks to be appropriate:
>> "... the client's request was successfully received, understood, and
>> accepted."
>>
>> 200 doesn't seem right since:
>> "...  the request has succeeded."
>>
>> 202 could be better since:
>> "... the request has been accepted for processing, but the processing
>> has not been completed."
>> but the intention behind 202 is very different so using it in this case
>> seems wrong.
>>
>> None of the other 2xx codes seem to be a match at all.
>>
>> The 4xx codes are another possibility:
>> "... 4xx (Client Error) class of status code indicates that the client
>> seems to have erred."
>>
>> Of those only 400 is a possible match.
>> "... the server cannot or will not process the request due to something
>> that is perceived to be a client error."
>>
>> The 5xx codes are also possible:
>> "... the server is aware that it has erred or is incapable of performing
>> the requested method"
>>
>> With 500 being the best match in that case:
>> "... the server encountered an unexpected condition that prevented it
>> from fulfilling the request."
>>
>> You have already explained why using 500 is a problem. 400 suffers from
>> a similar issue. Which brings us back to 200 which doesn't seem right
>> either.
>>
>> I think we are going to have to choose a "least bad" option here. Given
>> that Tomcat has used 200 in the past and that there is the option to add
>> %{javax.servlet.error.exception}r to the access log I think reverting
>> the change to the status code is the best (well, least bad) option here.
>>
>> I'll get that done shortly.
> 
> I think that it makes sense to log the status code that was actually
> sent on the first line of the response.
> 
> If "200" was sent to browser, it is better to log "200", not "500".

Note: It is possible that no status code was sent e,g, if the client
disconnected before the response was committed.

The restored behaviour is that the access log will contain whatever
status code the application set.

> 
> As an idea:
> 
> In Apache HTTPD there is an option in their access log format to log
> connection status: "%X"
> 
> http://httpd.apache.org/docs/2.4/mod/mod_log_config.html#formats
> 
> "%X":
> Connection status when response is completed:
> X = Connection aborted before the response completed.
> + = Connection may be kept alive after the response is sent.
> - = Connection will be closed after the response is sent.

That is an excellent idea. I'll add a BZ entry for that.

Mark

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