Re: Using JMX to get ONLY running applications

[Amit Pande]

Thanks a lot, Mark for the pointers.

And I apologies if the questions here raise a doubt about lack of homework.

Personally I do try to use Google and/or read and understand documentation
as much as I can. 

Sometimes however I feel (may be wrongly again), documentation is not
enough. E.g. Unless asked here, I would have never known the ³shared²
loader is still supported  (and undocumented) in latest releases. Same is
true with attributes associated with Tomcat Mbeans.


Thanks,
Amit


On 14/07/16 2:18 am, "Mark Thomas"  wrote:

>On 13/07/2016 12:14, Amit Pande wrote:
>> It seems the stateName attribute of MANAGER or WEBMODULE Mbean is NOT
>> getting set correctly if there are any servlet errors.
>> 
>> In particular, when Spring dispatcher servlet is failed to load then the
>> applications state should be STOPPED. However, that does not seem to be
>> the case.
>> 
>> I even checked the SERVLET Mbean as well did not see the expected state.
>> 
>> Is there anything wrong that I am doing ?
>
>Yes.
>
>You are making assumptions based on how you think Tomcat should behave
>rather than reading the documentation that tells you how Tomcat actually
>behaves.
>
>Look in the Context and Host docs for the attribute named:
>failCtxIfServletStartFails
>
>> Is this a BUG ?
>
>No.
>
>> Using Tomcat 8.0.30.
>
>Thanks. Not everyone remembers that.
>
>Mark
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>


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

Asynchronous callback from application deployed in tomcat

[Mohanavelu Subramanian]

Hi All,

Good morning.

Our application is deployed on tomcat. We have apache load balancer and
tomcat container running on separate virtual machines.

We got a requirement to implement asynchronous callback for long running
tasks from client. So, with this feature client would send soap request
with an attribute mode=async and callback endpoint as well . Since mode is
async, Our application will immediately respond to the client with success
message. Then later our will process the request and sends back response to
client on the call back endpoint.

I am little new to this load balancer and tomcat with async callback.

My doubt is, will this callback go through loadbalancer from tomcat when
our application invokes client callback endpoint to deliver the response?

If yes, will there be any problems in  delivering the response to the
client since load balancer and tomcat are on 2 separate Virtual machines?

Thanks in advance.

Best Regards,
Mohan

Re: Disable SSLv3 & TLSv1.0 in Tomcat 7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Varun,

On 7/8/16 2:16 AM, varun gulati wrote:
> Hello Team, Since past few days i have been struggling with
> disabling TLSv1.0 in my Tomcat configuration. Here is the content
> of my server.xml file. I was able to disable SSLv3, and things were
> working fine but somehow not able to disable TLSv1.0. Really
> appreciate your suggestions on how to resolve this vulnerability
> Disabled SSLv3 with below
> config:===
=
>
> 
 maxThreads="150" scheme="https" secure="true" 
> keystoreFile="Keystore_Pathe" keystorePass="*" 
> clientAuth="false" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" 
> ciphers="All Ciphers excluding RC4 Ciphers" /> 
> 
>
>  To disable TLSv1.0 i adopted to below config, fortunately it
> cleared the scans but my site broke on Https: Reffered Link:
> http://tomcat.10.x6.nabble.com/How-to-allow-only-TLS-1-1-connections-t
o-Tomcat-6-0-server-with-https-td4995362.html
>
> 
= maxThreads="150" scheme="https" secure="true" 
> keystoreFile="Keystore_Pathe" keystorePass="*" 
> clientAuth="false" sslProtocol="TLSv1.1"
> sslEnabledProtocols="TLSv1.1" ciphers="All Ciphers excluding RC4
> Ciphers"
> />
=
>
>  Please help me identify if i am missing on anything.

You were very close. You need:

sslProtocol="TLS" (the default)

and

sslEnabledProtocols="TLSv1.1"
or
sslEnabledProtocols="TLSv1.1,TLSv1.2"

Note that using a recent version of Tomcat should already disable
SSLv3 by default... you'd have to specifically re-enable it if you
wanted it.

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

iQIcBAEBCAAGBQJXhsRhAAoJEBzwKT+lPKRYX4QP/jQcDltnUNcFxDGhW27vk5W3
NNXUCLNT7dCVGF0Hp3bdGzibRfHJyNcFsjUBb62i1URrGs8ika4U52i0HWJj+Qkk
h/5dJFiqjRVzOTquNrW7Hubx5QHbMKX2atYc6x2TUHYfGuSJSrrzmdRtgYDyCt9k
j8uIQaZQdJItHUM/1wpEBaU0GOa7bwQYiuHqsZBEnhWdTH8UEbmlPzcxvNSrAbTy
QoSAPLPLU3yehAClu46pmEOhdfgn7vepW+RoqzFvtFAg5Eas3EKItsw22Hd5tItE
8S1A7Yw2uOQh/OoHyb3FPEFoPkfkDs3vXZIMG7wDJy8RmDdib3XMWN/di0BpBmSo
s52GqIHV8Qe0dPz6aTfrAsBGn0/JOmDj4eup0Igz0gmgjnRaMfgLJ/YqjBG9Gj8l
MHIU5SxifBLno9Pk2FSmykL0ZVTLjRLn7MEiP/8fN5C4nfKrWWQ7SXj3rAijEcVK
u2Q12cAPFaHolp56qXYJjfVA2NJCA+45/yJ0mI2PqlS5K7BMkbQWUX6tpMBri7Mz
5e7D16RMNOiP9/LafzHGWiEUTw3tDK0ATqQXbmcFmZylMgcPxjP4lRHlDa+2aviI
Ciyi1C0KOSWGTodPC+P76v0uVg8JO2QfG5ecoEgThLBug8AJL8HhRb5uW20wOj2Q
AG/xrV9Ja9a+OXgbRjne
=dKs3
-END PGP SIGNATURE-

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

Re: A complex issue concerning the application lifecycle, MBeans and Spring

[Guido Jäkel]

Dear Mark,

> We need to find out what is triggering the second, unwanted
> initialization. You'll need to add some logging to your app to capture
> the relevant stack trace. When you have it, post it here.

taking remote access, I was able to extract a (hope so) relevant stack trace 
from the logs. You can see the start of init runnning with one of the (in 
comparison to TC6 new) pooled deployer threads. And then the interfering and 
failing catalina-exec-64. From the stack, we see that this is my http call via 
the managers proxy to the MBean. 

And now, you Gurus can start to imagine what's happen internally between the 
two marks - i.e. what make the invocation of  
org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute()  resulting in a 
call of  javax.servlet.GenericServlet.init()  , which sounds -- with my low 
knowlegde -- to me to be the standard servlet entry point and this will raise 
the issue.

By the way: I would expect that even the container state machine should not 
allow to call this init() twice, because it should be for sure already in a 
state called "starting" or what else.



First thing you see is the undeployment. Please ignore the well-known problems 
with the dangling threads. You may advance to the next paragraph and take a 
look at it later.

20160713-161415.617 INFO  
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] [] [HostConfig] 
Undeploying context []
20160713-161415.618 INFO  
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] [] [[/]] Destroying 
Spring FrameworkServlet 'webservices'
20160713-161415.627 INFO  
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] [] [[/]] Closing 
Spring root WebApplicationContext
20160713-161415.701 WARN  
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] [] 
[WebappClassLoaderBase] The web application [ROOT] appears to have started a 
thread named [AsyncAppender-Dispatcher-
Thread-51] but has failed to stop it. This is very likely to create a memory 
leak. Stack trace of thread:
 java.lang.Object.wait(Native Method)
 java.lang.Object.wait(Object.java:502)
 org.apache.log4j.AsyncAppender$Dispatcher.run(AsyncAppender.java:548)
 java.lang.Thread.run(Thread.java:745)
20160713-161415.702 ERROR 
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] [] 
[WebappClassLoaderBase] The web application [ROOT] created a ThreadLocal with 
key of type [org.apache.xmlbeans.impl.
schema.SchemaTypeLoaderImpl$1] (value 
[org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@1542aa40]) and a value 
of type [java.util.ArrayList] (value [[java.lang.ref.SoftReference@15ade4fe]]) 
but fa
iled to remove it when the web application was stopped. Threads are going to be 
renewed over time to try and avoid a probable memory leak.
20160713-161415.703 ERROR 
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] [] 
[WebappClassLoaderBase] The web application [ROOT] created a ThreadLocal with 
key of type [org.apache.axis.utils.XML
Utils.ThreadLocalDocumentBuilder] (value 
[org.apache.axis.utils.XMLUtils$ThreadLocalDocumentBuilder@26a7136c]) and a 
value of type [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl] 
(value [c
om.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl@5cd78952]) but 
failed to remove it when the web application was stopped. Threads are going to 
be renewed over time to try and avoid a probable 
memory leak.
20160713-161415.703 ERROR 
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] [] 
[WebappClassLoaderBase] The web application [ROOT] created a ThreadLocal with 
key of type [org.apache.xmlbeans.impl.
store.Locale$1] (value [org.apache.xmlbeans.impl.store.Locale$1@330e7103]) and 
a value of type [java.lang.ref.SoftReference] (value 
[java.lang.ref.SoftReference@28c8179f]) but failed to remove it when t
he web application was stopped. Threads are going to be renewed over time to 
try and avoid a probable memory leak.
20160713-161415.704 ERROR 
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] [] 
[WebappClassLoaderBase] The web application [ROOT] created a ThreadLocal with 
key of type [org.apache.xmlbeans.impl.
store.CharUtil$1] (value [org.apache.xmlbeans.impl.store.CharUtil$1@36ea5d99]) 
and a value of type [java.lang.ref.SoftReference] (value 
[java.lang.ref.SoftReference@5617df0f]) but failed to remove it wh
en the web application was stopped. Threads are going to be renewed over time 
to try and avoid a probable memory leak.
20160713-161415.704 ERROR 
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] [] 
[WebappClassLoaderBase] The web application [ROOT] created a ThreadLocal with 
key of type [org.apache.xmlbeans.XmlBe
ans$1] (value [org.apache.xmlbeans.XmlBeans$1@16d13aa7]) and a value of type 
[java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@7ecda30d]) 
but failed to remove it when the web application
 was stopped. Threads are going to be renewed over time to try and avoid a 
probable memory leak.
201607

Re: Need help setting up SSL on Tomcat 8

[Daniel Savard]

2016-07-13 15:56 GMT-04:00 Sean Son :

> Thank you for your answer guys. Is there anywhere in the Tomcat config
> files that I would need to specify the DNS name?  Like in Apache we would
> specify the DNS name in a Virtualhost.
>
>
No.

-
Daniel Savard

Re: A complex issue concerning the application lifecycle, MBeans and Spring

[Guido Jäkel]

On 13.07.2016 22:41, Mark Thomas wrote:
> I've been through the MBean descriptor for a web application and as far
> as I can tell, reading of all of the attributes is passive. It might
> return a few unexpected nulls or maybe thrown an exception but it
> shouldn't trigger any additional initialization.
> 
> We need to find out what is triggering the second, unwanted
> initialization. You'll need to add some logging to your app to capture
> the relevant stack trace. When you have it, post it here.
> 
> Mark

Dear Mark,

thank you for your work and feedback! I understand what you mean by "reading is 
passive". I will try to collect some relevant parts from the log files tomorrow 
at work. And I may advance any log level you request for. But I'm not able to 
modify any application, because I'm responsible for operations and not a member 
of the developer staff and have no other tool chain than "vi and javac". In the 
other way round, i may deploy any testing war's you may provide me.

After my email, i did compare the output of the MBean Request between Tomcat6 
and Tomcat8. And i noticed, that there is another model name in the answer and 
there are more attributes.

And I play around with restarting of a bigger app which spend about 3 sec for 
the initialization. I disabled the external monitoring and apply "the" MBean 
request by hand (with wget). I run the tests about 10 times and it was 
reproducible failing with an "early" MBean request and also reproducible 
propper working without. 

Now, may you or anybody else give me a hint how to log what is triggering a 
catalina-exec worker, what are the parameters for this call or what's the 
caller stack to get an idea of the triggering code path.

Tomorrow I also will test, if any other "regular" request to the application 
will raise this race condition during application startup using Tomcat8.


with greetings

Guido


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

Re: Using JMX to get ONLY running applications

[Mark Thomas]

On 13/07/2016 12:14, Amit Pande wrote:
> It seems the stateName attribute of MANAGER or WEBMODULE Mbean is NOT
> getting set correctly if there are any servlet errors.
> 
> In particular, when Spring dispatcher servlet is failed to load then the
> applications state should be STOPPED. However, that does not seem to be
> the case.
> 
> I even checked the SERVLET Mbean as well did not see the expected state.
> 
> Is there anything wrong that I am doing ?

Yes.

You are making assumptions based on how you think Tomcat should behave
rather than reading the documentation that tells you how Tomcat actually
behaves.

Look in the Context and Host docs for the attribute named:
failCtxIfServletStartFails

> Is this a BUG ?

No.

> Using Tomcat 8.0.30.

Thanks. Not everyone remembers that.

Mark


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

Re: A complex issue concerning the application lifecycle, MBeans and Spring

[Mark Thomas]

On 13/07/2016 15:20, Jäkel, Guido wrote:
> But if there is a certain request to some MBean while the App is
> starting, there will be a request to the application (via
> catalina-exec). And then, as a race condition, the initialization of
> the Spring framework, esp. the bean wiring will fail with lots of
> exceptions because this is not thread-safe.
> 
> If this additional (failing) request is processed fast enough, the
> application will be usable due to initialization via the normal
> servlet lifecycle request. But if it's as a race condition in the
> other way round, the application will be not usable afterwards.

I've been through the MBean descriptor for a web application and as far
as I can tell, reading of all of the attributes is passive. It might
return a few unexpected nulls or maybe thrown an exception but it
shouldn't trigger any additional initialization.

We need to find out what is triggering the second, unwanted
initialization. You'll need to add some logging to your app to capture
the relevant stack trace. When you have it, post it here.

Mark

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

Re: Why does the Rfc6265CookieProcessor handle the version 1 cookie?

[Mark Thomas]

On 13/07/2016 07:28, Kyohei Nakamura wrote:
> Hi all,
> 
> The documentation of the Cookie Processor says that the
> Rfc6265CookieProcessor is based on the RFC6265.
> The RFC6265 specification does not allow the Version attribute in the
> Cookie header.
> However the Rfc6265CookieProcessor handles the version 1 cookie ($Version=1).
> I think the Rfc6265CookieProcessor should complies with the RFC6265
> specification that does not allow the Version attribute.
> 
> Why does the Rfc6265CookieProcessor handle the version 1 cookie?

The CookieProcessor implementation determines how Tomcat writes
Set-Cookie headers, not how it reads them.

To provide backwards compatibility for clients that send RFC2109
compliant cookies, Rfc6265CookieProcessor reads them using RFC2019
parsing rules.

Mark


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

Re: Need help setting up SSL on Tomcat 8

[Sean Son]

Thank you for your answer guys. Is there anywhere in the Tomcat config
files that I would need to specify the DNS name?  Like in Apache we would
specify the DNS name in a Virtualhost.

On Wed, Jul 13, 2016 at 7:56 AM, Ognjen Blagojevic <
ognjen.d.blagoje...@gmail.com> wrote:

> Sean,
>
> On 12.7.2016 14:49, Sean Son wrote:
>
>> Hello thank you for your response. I am currently only accessing the
>> server using IP address only. We do not have a DNS record set up for the
>> server as of yet. It will be something like webapp.example.com
>>
>
> Once there is a DNS record in place, and you access your server using
> FQDN, your error will be gone.
>
> If you are the only one who access the server, and you find that warning
> particularly annoying, you may enter FQDN and IP address in hosts file, and
> access server using FQDN, before your DNS admins do their job.
>
> -Ognjen
>
>

[ANN] Apache Tomcat 8.5.4 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.4.

This is the first stable release of the 8.5.x branch. Tomcat 8.x users
should now use 8.5.x releases in preference to 8.0.x releases.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and Java Authentication Service Provider Interface for
Containers technologies.

Apache Tomcat 8.5.x is intended to replace 8.0.x and includes new
features pulled forward from the 9.0.x branch. The notable changes since
8.5.3 include:

- Correct a regression in the embedded packaging

- Add the ability to control the degree of concurrency when processing
  HTTP/2 connections

- Update to Tomcat Native 1.2.8

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 5.x, 6.x, 7.x and 8.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

[ANN] Apache Tomcat 9.0.0.M9 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.0.M9.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.0.M9 is a milestone release of the 9.0.x branch and
has been made to provide users with early access to the new features in
Apache Tomcat 9.0.x so that they may provide feedback. The notable
changes compared to 9.0.0.M8 include:

- Fix the embedded packaging

- Make it easier to inject custom keystores (for embedded users)

- Update tc-native to 1.2.8

- Add support for wildcard host names and aliases

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 5.x, 6.x, 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

Re: Tomcat 8.0 : Custom server.xml path

[Violeta Georgieva]

Hi,

2016-07-12 12:03 GMT+03:00 Amit Pande :
>
> Any thoughts on this ?

You may try using catalina.base
https://github.com/apache/tomcat/blob/trunk/RUNNING.txt#L84
https://github.com/apache/tomcat/blob/trunk/RUNNING.txt#L230

Regards,
Violeta

>
> On 11/07/16 1:15 pm, "Amit Pande"  wrote:
>
> >Hello all,
> >
> >
> >We have a custom cluster deployment scenario which requires to put config
> >files on a shared disk.
> >
> >With reference to above requirement, we need to put server.xml (and
> >possibly other files from TOMCAT_DIR\conf) on the shared disk.
> >
> >Is there any way to do this ? Possible to do in catalina.properties like:
> >
> >
> >Conf.dir = 
> >
> >
> >Appreciate your help here.
> >
> >Thanks,
> >Amit
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: A complex issue concerning the application lifecycle, MBeans and Spring

[tomcat]

On 13.07.2016 16:33, Jäkel, Guido wrote:

Dear André,

thank you for quickly announcing your idea for an workaround. But you right see 
the limits, and the more important

impact of disabling the connectors is that it will also disable the traffic to 
all the other running applications (and we have a
bunch of it on each of our Tomcats)


In the first instance I want to have a fix for the issue. But nevertheless, 
maybe this lead me to a suitable workaround if I

think about it in the background.




Well, here is a little variation of the idea then :
The purpose of the monitoring is normally to verify that the applications are 
responding,
right ? (*)
And the fact that the applications are responding, does not depend on the 
Connector
through which such requests come in, right ?
So why not define an additional Connector, on a different port, for usage 
*only* by the
monitoring system, and disable only /that/ Connector while you are doing your 
application
update ?

(*) I mean, if you want to verify that the connection is working, then you can 
just do a
"ping" kind of test.


Dear André,

So why? It's because want to modify a complex, multi-staged and well-working 
platform as a last resort only. The monitoring does a lot more than to verify 
that the applications are running, it's uses a bunch of the data available via 
the MBeans for a control dashboard.

It's was my mistake to use the term workaround ...



Guido,

I understand what you are saying, and indeed it would be better to correct the real 
problem, rather than looking for (temporary) workarounds.
I was just trying to be pragmatic, and offer some ideas for a possible temporary solution, 
in case this stops you from deploying a more recent version of tomcat (and in case this 
really bothers you).


But even with my limited knowledge, when I look at the description that you provided, I 
have the impression that this may be some very specific problem of your installation.
(I am regularly watching this list, and I do not recall seeing any other mention of a 
problem related to yours, over many months).


It may also be one for which providing a simple test case may be somewhat 
difficult.
(Because for instance it seems rather timing-dependent; and because we also don't know if 
you have complete control over your monitoring/dashboard code).


So it may be some time, before one of the real tomcat developers (which I am not), has a 
chance to dig deeper into this and maybe find the problem in tomcat, /if/ it is a problem 
in tomcat. (You mentioned yourself something not being really thread-safe; maybe that is 
part of the problem).


In that sense, even if the Connector-idea which I mentioned, does indeed block your whole 
dashboard, then at least it would block /only/ that dashboard and only during a short 
time, and not the rest of the applications.


But it is of course your privilege to pursue whatever path you find best for a solution, 
and you can do what you want with my suggestions.

(including putting them in the Gulli with a Dekkel drauf)

Grüsse
André



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

Re: [OT] mod-jk + ssl: requests are not forward to tomcat correctly

[tomcat]

On 13.07.2016 16:34, Anthony Biacco wrote:

On Mon, Jul 11, 2016 at 5:39 PM, Wayne Li  wrote:


Probably the quickest : download these files, install them on your

server, and change the above links.
Like : create a sub-directory "/js" of your webapp, and install them there.
Then change the above links to : href="js/jquery.mobile-1.4.5.min.css"

Yes. It works. Thanks.

It is okay for now. but, if I do not want host these files, what should I
do? Can you point a direction for me please?




If you must not host these files, use CDNjs, i.e.
https://cdnjs.com/libraries/jquery-mobile



But then Rainer's previous point would still be valid.



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

Re: mod-jk + ssl: requests are not forward to tomcat correctly

[Anthony Biacco]

On Mon, Jul 11, 2016 at 5:39 PM, Wayne Li  wrote:

> > Probably the quickest : download these files, install them on your
> server, and change the above links.
> Like : create a sub-directory "/js" of your webapp, and install them there.
> Then change the above links to : href="js/jquery.mobile-1.4.5.min.css"
>
> Yes. It works. Thanks.
>
> It is okay for now. but, if I do not want host these files, what should I
> do? Can you point a direction for me please?
>


If you must not host these files, use CDNjs, i.e.
https://cdnjs.com/libraries/jquery-mobile

-Tony

RE: A complex issue concerning the application lifecycle, MBeans and Spring

[Jäkel , Guido]

>> Dear André,
>>
>> thank you for quickly announcing your idea for an workaround. But you right 
>> see the limits, and the more important
>impact of disabling the connectors is that it will also disable the traffic to 
>all the other running applications (and we have a
>bunch of it on each of our Tomcats)
>>
>> In the first instance I want to have a fix for the issue. But nevertheless, 
>> maybe this lead me to a suitable workaround if I
>think about it in the background.
>>
>
>Well, here is a little variation of the idea then :
>The purpose of the monitoring is normally to verify that the applications are 
>responding,
>right ? (*)
>And the fact that the applications are responding, does not depend on the 
>Connector
>through which such requests come in, right ?
>So why not define an additional Connector, on a different port, for usage 
>*only* by the
>monitoring system, and disable only /that/ Connector while you are doing your 
>application
>update ?
>
>(*) I mean, if you want to verify that the connection is working, then you can 
>just do a
>"ping" kind of test.

Dear André,

So why? It's because want to modify a complex, multi-staged and well-working 
platform as a last resort only. The monitoring does a lot more than to verify 
that the applications are running, it's uses a bunch of the data available via 
the MBeans for a control dashboard.

It's was my mistake to use the term workaround ...

Guido

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

Re: A complex issue concerning the application lifecycle, MBeans and Spring

[tomcat]

On 13.07.2016 15:51, Jäkel, Guido wrote:



So it would appear that if the Connectors are disabled, the monitoring system 
is not able
to reach Tomcat, and the problem does not occur then.

So would it not be possible to create some little piece of software, which would
temporarily "suspend" or "disable" the Connectors, while the application update 
is taking
place, and then re-enable them when it's done ?

Of course, if the application update is also going though the Connectors, this 
may be a
problem..


Dear André,

thank you for quickly announcing your idea for an workaround. But you right see 
the limits, and the more important impact of disabling the connectors is that 
it will also disable the traffic to all the other running applications (and we 
have a bunch of it on each of our Tomcats)

In the first instance I want to have a fix for the issue. But nevertheless, 
maybe this lead me to a suitable workaround if I think about it in the 
background.



Well, here is a little variation of the idea then :
The purpose of the monitoring is normally to verify that the applications are responding, 
right ? (*)
And the fact that the applications are responding, does not depend on the Connector 
through which such requests come in, right ?
So why not define an additional Connector, on a different port, for usage *only* by the 
monitoring system, and disable only /that/ Connector while you are doing your application 
update ?


(*) I mean, if you want to verify that the connection is working, then you can just do a 
"ping" kind of test.




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

Re: Tomcat Embedded and Web Fragments

[l.pe...@senat.fr]

On 13/07/2016 15:57, Violeta Georgieva wrote:

Hi,

2016-07-07 15:07 GMT+03:00 l.pe...@senat.fr :

Hi.

I am using Tomcat embedded, for integration tests.

I do not find how to let it take in account web-fragments of included

jars. Is there a specific config ? Does anyone have a working example ?


Take a look at the Tomcat's tests
https://github.com/apache/tomcat/blob/trunk/test/org/apache/catalina/startup/TestContextConfig.java

Thank you !

I moved on to other tasks, but there is clearly a solution in these tests.

Ludovic

|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|


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

Re: Tomcat Embedded and Web Fragments

[Violeta Georgieva]

Hi,

2016-07-07 15:07 GMT+03:00 l.pe...@senat.fr :
>
> Hi.
>
> I am using Tomcat embedded, for integration tests.
>
> I do not find how to let it take in account web-fragments of included
jars. Is there a specific config ? Does anyone have a working example ?


Take a look at the Tomcat's tests
https://github.com/apache/tomcat/blob/trunk/test/org/apache/catalina/startup/TestContextConfig.java

Regards,
Violeta


> I am using version 8.0.36.
>
> Thanks in advance,
>
> Ludovic
>
>
> |
> | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> |
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

RE: A complex issue concerning the application lifecycle, MBeans and Spring

[Jäkel , Guido]

>So it would appear that if the Connectors are disabled, the monitoring system 
>is not able
>to reach Tomcat, and the problem does not occur then.
>
>So would it not be possible to create some little piece of software, which 
>would
>temporarily "suspend" or "disable" the Connectors, while the application 
>update is taking
>place, and then re-enable them when it's done ?
>
>Of course, if the application update is also going though the Connectors, this 
>may be a
>problem..

Dear André,

thank you for quickly announcing your idea for an workaround. But you right see 
the limits, and the more important impact of disabling the connectors is that 
it will also disable the traffic to all the other running applications (and we 
have a bunch of it on each of our Tomcats)

In the first instance I want to have a fix for the issue. But nevertheless, 
maybe this lead me to a suitable workaround if I think about it in the 
background.

Greetings

Guido

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

Re: A complex issue concerning the application lifecycle, MBeans and Spring

[tomcat]

On 13.07.2016 15:20, Jäkel, Guido wrote:

Dear Developers,

I have an elaborate issue migrating from Tomcat 6.0.41 to 8.0.36 (currently 
using java 8.0.66 on Gentoo Linux, but this is not of importance I think): It 
is related to the build-in manager application used as a jmxproxy. And to 
initialization of the Spring framework during an application lifecycle. But in 
core, I think it's not related to the manager app and it's proxy feature 
itself. But to some MBean or lifecycle implementation details.

First of all: In principle, all works well. If i start the tomcat from the 
scratch, all applications will proper initialize and work as expected. If I 
restart any application by different triggers (manager, touching the WAR or a 
sensitive file inside the docroot and so on), it will be undeployed and 
deployied again - all as usual.

But if there is a certain request to some MBean while the App is starting, 
there will be a request to the application (via catalina-exec). And then, as a 
race condition, the initialization of the Spring framework, esp. the bean 
wiring will fail with lots of exceptions because this is not thread-safe.

If this additional (failing) request is processed fast enough, the application 
will be usable due to initialization via the normal servlet lifecycle request. 
But if it's as a race condition in the other way round, the application will be 
not usable afterwards.

The point now is: This requests to the MBeans are done requently (ever 10s) by 
our monitoring system. And about 90% of the automatic deployments done by the 
CI system now will fail by this race condition in spite of the deployed apps 
are well-done. Without any modification, the same application is able to start 
by chance of no concurrent request to the MBean or (of course) by disabling the 
Monitoring or factical preventing it's request also by a restart of the whole 
tomcat, because the connectors are disabled until all apps are up as you'll 
know.

This never happens with tomcat 6 used for many years. Therefore, there must be 
some regression with an MBean that will allow to route a request to a 
not-fully-started application. I happens with all our well-established 
applications which use the Spring framework -- regardess if deployed via the CI 
because of normal, slightly modification or even with unchanged versions 
running in production on Tomcat6. I can't give information about the behavior 
on Tomcat7.

I think I was able to narrow it down to a specific MBean readout: If I send the request 
".../manager/jmxproxy?qry=Catalina:j2eeType=Servlet,WebModule=*,*" before the Deployer 
logs "[StandardContext] Reloading Context with name [foo] is completed", then it will 
trigger an unwanted, additional thread.

It sounds like it points into the right direction because the MBean related to 
the Servlet is offering e.g. information about the containers lifecycle state.

May you fix it or did you see any workaround? If you need any more details, 
please ask about. Thank you in advance for your support.




Hi.
The explanation above, as well as the underlying issue, are way over my level of knowledge 
of Tomcat and/or Java.


But, as a possible (and possibly temporary) workaround, and focusing on this 
bit :

"Without any modification, the same application is able to start by chance of no 
concurrent request to the MBean or (of course) by disabling the Monitoring or factical 
preventing it's request also by a restart of the whole tomcat, because the connectors are 
disabled until all apps are up as you'll know."


So it would appear that if the Connectors are disabled, the monitoring system is not able 
to reach Tomcat, and the problem does not occur then.


So would it not be possible to create some little piece of software, which would 
temporarily "suspend" or "disable" the Connectors, while the application update is taking 
place, and then re-enable them when it's done ?


Of course, if the application update is also going though the Connectors, this may be a 
problem..





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

A complex issue concerning the application lifecycle, MBeans and Spring

[Jäkel , Guido]

Dear Developers,

I have an elaborate issue migrating from Tomcat 6.0.41 to 8.0.36 (currently 
using java 8.0.66 on Gentoo Linux, but this is not of importance I think): It 
is related to the build-in manager application used as a jmxproxy. And to 
initialization of the Spring framework during an application lifecycle. But in 
core, I think it's not related to the manager app and it's proxy feature 
itself. But to some MBean or lifecycle implementation details.

First of all: In principle, all works well. If i start the tomcat from the 
scratch, all applications will proper initialize and work as expected. If I 
restart any application by different triggers (manager, touching the WAR or a 
sensitive file inside the docroot and so on), it will be undeployed and 
deployied again - all as usual.

But if there is a certain request to some MBean while the App is starting, 
there will be a request to the application (via catalina-exec). And then, as a 
race condition, the initialization of the Spring framework, esp. the bean 
wiring will fail with lots of exceptions because this is not thread-safe.

If this additional (failing) request is processed fast enough, the application 
will be usable due to initialization via the normal servlet lifecycle request. 
But if it's as a race condition in the other way round, the application will be 
not usable afterwards.

The point now is: This requests to the MBeans are done requently (ever 10s) by 
our monitoring system. And about 90% of the automatic deployments done by the 
CI system now will fail by this race condition in spite of the deployed apps 
are well-done. Without any modification, the same application is able to start 
by chance of no concurrent request to the MBean or (of course) by disabling the 
Monitoring or factical preventing it's request also by a restart of the whole 
tomcat, because the connectors are disabled until all apps are up as you'll 
know.

This never happens with tomcat 6 used for many years. Therefore, there must be 
some regression with an MBean that will allow to route a request to a 
not-fully-started application. I happens with all our well-established 
applications which use the Spring framework -- regardess if deployed via the CI 
because of normal, slightly modification or even with unchanged versions 
running in production on Tomcat6. I can't give information about the behavior 
on Tomcat7.

I think I was able to narrow it down to a specific MBean readout: If I send the 
request ".../manager/jmxproxy?qry=Catalina:j2eeType=Servlet,WebModule=*,*" 
before the Deployer logs "[StandardContext] Reloading Context with name [foo] 
is completed", then it will trigger an unwanted, additional thread.

It sounds like it points into the right direction because the MBean related to 
the Servlet is offering e.g. information about the containers lifecycle state.

May you fix it or did you see any workaround? If you need any more details, 
please ask about. Thank you in advance for your support.


with greetings

Guido

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

Re: Tomcat 8 classloading

[saurabh tiwari]

Thanks a lot Chris.

Thanks,

Saurabh Tiwari
9158483338

On Wed, Jul 13, 2016 at 1:49 PM, chris derham  wrote:

> > Hi There,
> >
> > We are about to upgrade from tomcat-7.0.65 to tomcat-8.0.XX. and this is
> > regarding the loading of same JARs within the different application. to
> > understand the scenario, consider below case
> >
> > Tomcat 8 ---
> > webapps
> > a.war--> lib--> spring.jar
> > b.war--> lib--> spring.jar
> >
> > here b.war is just a copy of a.war and renamed just to differentiate
> hence
> > spring.jar is same for both the applications.
> >
> > My question is
> >
> > 1) will spring.jar loaded twice
>
> yes it will be loaded twice
>
> > 2) how to i make sure to load it only once ( if loaded twice)
>
> This question comes up frequently. Search the mailing list for shared
> class loader to see the details. The upshot is that this can be done
> using shared class loader, however there are real technical issues if
> you do this - class cast exceptions, difficulty performing upgrades to
> individual wars without taking down all of tomcat. The only positive
> is that you might save a few MB of memory cost by having the same jar
> loaded twice in memory.
>
> I've been on this mailing list for ~8 years, and every time this
> issues comes up (about 5 times a year?), the tomcat developers suggest
> that the proposed memory saving isn't not worth the problems that it
> causes..
>
> HTH
>
> Chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Need help setting up SSL on Tomcat 8

[Ognjen Blagojevic]

Sean,

On 12.7.2016 14:49, Sean Son wrote:

Hello thank you for your response. I am currently only accessing the
server using IP address only. We do not have a DNS record set up for the
server as of yet. It will be something like webapp.example.com


Once there is a DNS record in place, and you access your server using 
FQDN, your error will be gone.


If you are the only one who access the server, and you find that warning 
particularly annoying, you may enter FQDN and IP address in hosts file, 
and access server using FQDN, before your DNS admins do their job.


-Ognjen


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

Re: Tomcat 8 classloading

[chris derham]

> Hi There,
>
> We are about to upgrade from tomcat-7.0.65 to tomcat-8.0.XX. and this is
> regarding the loading of same JARs within the different application. to
> understand the scenario, consider below case
>
> Tomcat 8 ---
> webapps
> a.war--> lib--> spring.jar
> b.war--> lib--> spring.jar
>
> here b.war is just a copy of a.war and renamed just to differentiate hence
> spring.jar is same for both the applications.
>
> My question is
>
> 1) will spring.jar loaded twice

yes it will be loaded twice

> 2) how to i make sure to load it only once ( if loaded twice)

This question comes up frequently. Search the mailing list for shared
class loader to see the details. The upshot is that this can be done
using shared class loader, however there are real technical issues if
you do this - class cast exceptions, difficulty performing upgrades to
individual wars without taking down all of tomcat. The only positive
is that you might save a few MB of memory cost by having the same jar
loaded twice in memory.

I've been on this mailing list for ~8 years, and every time this
issues comes up (about 5 times a year?), the tomcat developers suggest
that the proposed memory saving isn't not worth the problems that it
causes..

HTH

Chris

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

Tomcat 8 classloading

[saurabh tiwari]

Hi There,

We are about to upgrade from tomcat-7.0.65 to tomcat-8.0.XX. and this is
regarding the loading of same JARs within the different application. to
understand the scenario, consider below case

Tomcat 8 ---
webapps
a.war--> lib--> spring.jar
b.war--> lib--> spring.jar

here b.war is just a copy of a.war and renamed just to differentiate hence
spring.jar is same for both the applications.

My question is

1) will spring.jar loaded twice
2) how to i make sure to load it only once ( if loaded twice)



Thanks,

Saurabh Tiwari
9158483338

Re: Using JMX to get ONLY running applications

[Amit Pande]

Can someone help here ?

It seems the stateName attribute of MANAGER or WEBMODULE Mbean is NOT
getting set correctly if there are any servlet errors.

In particular, when Spring dispatcher servlet is failed to load then the
applications state should be STOPPED. However, that does not seem to be
the case.

I even checked the SERVLET Mbean as well did not see the expected state.

Is there anything wrong that I am doing ? Is this a BUG ? Using Tomcat
8.0.30.

Thanks,
Amit



On 13/07/16 1:05 pm, "Amit Pande"  wrote:

>I managed to use jCOnsole and find Mbean names and attributes to get the
>stateName (STARTED/STOPPED) to see if a web app is available or NOT
>(j2eeType=WebModule).
>
>However, I see the stateName of a web module as STARTED even if there are
>errors in start-up.
>
> SEVERE [localhost-startStop-3]
>org.apache.catalina.core.StandardContext.loadOnStartup Servlet
>[dispatcher] in web application [/testApp] threw load() exception
>
>I still see state for testApp as "STARTED".
>
>How can I accurately know if the application is started without any
>errors ?
>
>Appreciate your help.
>
>Thanks,
>Amit
>
>From: Amit Pande >
>Date: Tuesday, 12 July 2016 9:56 pm
>To: "users@tomcat.apache.org"
>>,
>"users-h...@tomcat.apache.org"
>>
>Subject: Using JMX to get ONLY running applications
>
>Hello all,
>
>I see there are JMX APIs to get the web applications currently deployed
>in Tomcat.
>
>However, I see that even if the applications are failed to deploy, they
>still get listed. Is there any way to get ONLY deployed and RUNNING
>applications ?
>
>Below is sample snippet which gives all the currently deployed apps
>..even if there are some apps which had errors and thus failed to deploy:
>
>
>public List collectAllDeployedApps() throws
>MalformedObjectNameException, AttributeNotFoundException,
>InstanceNotFoundException, MBeanException, ReflectionException {
>List webappNames = new ArrayList<>();
>List servers =  MBeanServerFactory.findMBeanServer(null);
>for (MBeanServer server : servers ) {
>Set names = server.queryNames(new
>ObjectName("Catalina:type=Host,*"), null);
>Set hostNames = new HashSet();
>for (ObjectName on : names) {
>hostNames.add(on.getKeyProperty("host"));
>}
>for (String str : hostNames) {
>ObjectName[] webapps = (ObjectName[]) server
>.getAttribute(new ObjectName("Catalina:type=Host,host=" + str),
>"children");
>for (ObjectName ob : webapps) {
>String[] appSpl = ob.getKeyProperty("name").split("//localhost");
>System.out.println(ob.getKeyPropertyList());
>webappNames.add(appSpl[1]);
>}
>}
>}
>return webappNames;
>}
>}
>
>


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

Re: Facing issue while configuring SSL

[tomcat]

On 13.07.2016 07:02, Devendra Sengar wrote:

File is there and permission is also fine and having proper openssl.cnf.

Any other view?


Really "shooting in the dark" here, since I am neither a Windows nor an SSL 
specialist :
The error message mentions "no such process".  Assuming (and that may be a naive 
assumption) that the error message reflects the reality, could it not be that the handling 
of these SSL keys/cartificates under Windows, requires some background Windows 
"cryptographic service" to be active, and that it is not ?

(or some DLL to be found somewhere, where it isn't)



Thanks,
Devendra

On Tue, Jul 12, 2016 at 9:10 PM, André Warnier (tomcat) 
wrote:


On 12.07.2016 16:33, Harrie Robins wrote:


java.lang.Exception: Unable to load certificate key
conf/localhost-key.pem (error:02001003:system library:fopen:No such process

If I'm correct you are either missing correct rights to this file or it
is not in the given location.
A second possibility is missing password for key file.



Alternatively, searching Google for error:02001003, there are a number of
hits there which point to the same kind of message, most of which seem to
be for Windows and OpenSSL, and most of which mention the need for a proper
"openssl.cnf" in the proper location.
This may or may not be relevant to your problem.




SSLPassword="pass"

Regards,

Harrie

-Original Message-
From: Devendra Sengar [mailto:dssen...@gmail.com]
Sent: dinsdag 12 juli 2016 10:50
To: users@tomcat.apache.org
Subject: Facing issue while configuring SSL

Hi,

This is regarding the configuration of Tomcat SSL using the APR library
on Java 6.

While starting the server I am getting the below error:

SEVERE: Failed to initialize end point associated with ProtocolHandler
["http-apr-443"]
java.lang.Exception: Unable to load certificate key
conf/localhost-key.pem (error:02001003:system library:fopen:No such process)

I am trying to implement SSL using independent libraries for OpenSSL,
Tomcat Native and Apache Portable Runtime.

I have downloaded precompiled versions of OpenSSL and Tomcat Native (see
them attached). I have tried compiling the Apache Portable Runtime using
Visual Studio (find it also attached).

I am running those libraries on either Tomcat 7.0.6 or 7.0.70 64-bit for
Windows (using the 64-bit distro, not the installer one).

We are restricted by our applicatioin to use Oracle Java 6 Updated 115
64-bit.

The versions of the libraries I am using are the latest available online,
again see the binaries attached.

The parameters used in the server.xml file are:

For Tomcat 7.0.6:


For Tomcat 7.0.70



The library files are in the tomcat bin folder as openssl.exe,
tcnative-1.dll and libapr-1.dll.

tcnative-1.dll:

https://drive.google.com/file/d/0ByilOlQCXOkWQ1ZCckhodHBvQk0/view?usp=sharing
openssl.exe:

https://drive.google.com/file/d/0ByilOlQCXOkWQk9KUUJSb3ZqeW8/view?usp=sharing
libapr-1.dll:

https://drive.google.com/file/d/0ByilOlQCXOkWV09NTi0tNWxhZnM/view?usp=sharing


The same certificates files mentioned in the server.xml file were used
and work in a brand new Apache web server.

Please let us know your opinion of what can cause those errors?

Can it be because of a APR dll not compiled properly?

Any other idea?

Thanks,
Devendra


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




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







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

Re: mod_jk errors

[tomcat]

On 12.07.2016 19:44, Wayne Li wrote:

Hi,

I have a servlet/jsp application running on tomcat 7.0.47. There are no
static html files.
Now I am try to use apache 2.4.7 (Ubuntu)
as the front and forward eveything to tomcat. I installed mod_jk using
Ubuntu's software
center.. Things are working. But I have errors in
/var/log/apache2/mod_jk.log:

[Mon Jul 11 20:19:32.261 2016] [1175:140389159810944] [info]
init_jk::mod_jk.c (3365): mod_jk/1.2.37 initialized
[Mon Jul 11 20:19:32.279 2016] [1175:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-manager' in uri map post processing.
[Mon Jul 11 20:19:32.279 2016] [1175:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-status' in uri map post processing.
[Mon Jul 11 20:19:32.386 2016] [1177:140389159810944] [info]
init_jk::mod_jk.c (3365): mod_jk/1.2.37 initialized
[Mon Jul 11 20:19:32.386 2016] [1177:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-manager' in uri map post processing.
[Mon Jul 11 20:19:32.386 2016] [1177:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-status' in uri map post processing.

If I add the following lines, the errors go away:

worker.list=jk-status
worker.jk-status.type=status
worker.jk-status.read_only=true
worker.list=jk-manager
worker.jk-manager.type=status

But the added line read funny. The same thing appears on the left-side of
the equal sign twice.
Are they correct? Do I need these lines? Can I ignore the errors?

Any information would be appreciated. Thanks in advance.



Tutorial :

Apache httpd knows /nothing/ about Tomcat.  Whenever it gets a request, Apache httpd looks 
at the request URI, and then inside itself for an appropriate "handler" to process that 
request (and generate a response for it).
To do that, it passes the request successively through all the "handlers" which it knows 
about (as per its configuration). Each handler gets a chance to look at the request URI, 
and, if it is not "interested", it returns a status "declined" to Apache httpd.

Apache httpd, in such a case, passes the request to the next possible handler, 
and so on.
The last handler in that chain is the Apache httpd "default handler", which always handles 
the request, if nobody else before wanted it.
If some handler in the chain decides that this request URI "is for him", then instead of 
returning "declined", it will compose and return the response to the request.

Apache then returns that response to the client, and stops scanning for more 
handlers.

For Apache httpd, mod_jk is just one such "handler" : it gets every request to look at, 
and decides if it wants to handle it or not. If it decides to handle it, then mod_jk 
passes the request to Tomcat, which handles the request and generates a response, which 
mod_jk then returns to Apache etc.  Apache httpd is totally unaware that it is not mod_jk 
itself which generates the response, and totally unaware that there are, in the 
background, one or more Tomcat "workers" to do the real work.


So, how does mod_jk decide if it wants to handle a request or not ?
That is where the "JkMount" directives come into play.
These are not instructions for Apache, they are for mod_jk.
When Apache reads its configuration and encounters a directive which it does not 
understand, it also passes it through the configured handlers, in case it is of interest 
to one of them. When mod_jk receives such a line, it notes in an internal "URI mapping 
table" that "URI's that look like this, are for me" (later), and they should be handled 
(later) by "tomcat worker x". When it is finished reading the configuration, that table 
thus looks like this :

URI_1 -> worker_a
URI_2 -> worker_a
URI_3 -> worker_b
URI_4 -> worker_c
etc..


On the other side, another configuration table tells mod_jk which are the Tomcats which it 
can use as "workers", to generate responses.

That is the table built from "workers.properties", and it looks like this :
worker_a -> host, port, type, etc..
worker_b -> host, port, type, etc..
worker_c -> internal (to mod_jk)
..

Now, in your Apache configuration, you have these JkMount's :
JkMount /myapp worker_a
JkMount /status worker_c
JkMount /yyy worker>_b

So mod_jk will build it's mapping table accordingly (see above).

When there is a mismatch between the JkMounts (and the "workers" which they mention), and 
the contents of "workers.properties" table (which lists the effective workers), then you 
get the above error messages.

For example, when the line
JkMount /status jk-status
does not find any corresponding active "jk-status" worker in workers.properties.

So you have a choice :
- if you do have an application under Tomcat (or mod_jk itself) which can handle such 
URI's, and you actually want to make this application available, then leave the JkMount, 
but enable the corresponding 

Re: Using JMX to get ONLY running applications

[Amit Pande]

I managed to use jCOnsole and find Mbean names and attributes to get the 
stateName (STARTED/STOPPED) to see if a web app is available or NOT 
(j2eeType=WebModule).

However, I see the stateName of a web module as STARTED even if there are 
errors in start-up.

 SEVERE [localhost-startStop-3] 
org.apache.catalina.core.StandardContext.loadOnStartup Servlet [dispatcher] in 
web application [/testApp] threw load() exception

I still see state for testApp as "STARTED".

How can I accurately know if the application is started without any errors ?

Appreciate your help.

Thanks,
Amit

From: Amit Pande >
Date: Tuesday, 12 July 2016 9:56 pm
To: "users@tomcat.apache.org" 
>, 
"users-h...@tomcat.apache.org" 
>
Subject: Using JMX to get ONLY running applications

Hello all,

I see there are JMX APIs to get the web applications currently deployed in 
Tomcat.

However, I see that even if the applications are failed to deploy, they still 
get listed. Is there any way to get ONLY deployed and RUNNING applications ?

Below is sample snippet which gives all the currently deployed apps ..even if 
there are some apps which had errors and thus failed to deploy:


public List collectAllDeployedApps() throws 
MalformedObjectNameException, AttributeNotFoundException, 
InstanceNotFoundException, MBeanException, ReflectionException {
List webappNames = new ArrayList<>();
List servers =  MBeanServerFactory.findMBeanServer(null);
for (MBeanServer server : servers ) {
Set names = server.queryNames(new 
ObjectName("Catalina:type=Host,*"), null);
Set hostNames = new HashSet();
for (ObjectName on : names) {
hostNames.add(on.getKeyProperty("host"));
}
for (String str : hostNames) {
ObjectName[] webapps = (ObjectName[]) server
.getAttribute(new ObjectName("Catalina:type=Host,host=" + str), "children");
for (ObjectName ob : webapps) {
String[] appSpl = ob.getKeyProperty("name").split("//localhost");
System.out.println(ob.getKeyPropertyList());
webappNames.add(appSpl[1]);
}
}
}
return webappNames;
}
}