Web-fragments when unpackWARs=false

[Rob Gansevles]

Hi,

I am trying to use web-fragments on tomcat8, but get an error and the
webapp does not start when i turn unpacking of wars off.

Is this a supported combination?

I can reproduce the error with a plain new tomcat8 install and a standard
example.

I am using a simple sample war to make sure the issue is not in my own code.

I used webfragment-javaee6-war-3.0.0.war, downloaded from Maven Central
http://search.maven.org/remotecontent?filepath=org/apache/geronimo/samples/javaee6/webfragment-javaee6-war/3.0.0/webfragment-javaee6-war-3.0.0.war

Deploying this war works fine, until i set unpackWARs="false" on localhost
in conf/server.xml

After restart get this error in the logs:

INFO: Deploying web application archive
/crypt/apache/tomcat/trunk/output/build/webapps/webfragment-javaee6-war-3.0.0.war
Oct 09, 2015 10:07:56 AM org.apache.catalina.startup.ContextConfig
processServletContainerInitializers
SEVERE: Failed to process JAR found at URL [/webfragment-javaee6-war-3.0.0]
for ServletContainerInitializers for context with name [{1}]
java.net.MalformedURLException: no !/ in spec
at java.net.URL.(URL.java:619)
at java.net.URL.(URL.java:482)
at java.net.URL.(URL.java:431)
at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:179)
at java.net.JarURLConnection.(JarURLConnection.java:162)
at
sun.net.www.protocol.jar.JarURLConnection.(JarURLConnection.java:81)
at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:41)
at java.net.URL.openConnection(URL.java:971)
at java.net.URL.openStream(URL.java:1037)
at
org.apache.catalina.startup.WebappServiceLoader.parseConfigFile(WebappServiceLoader.java:161)
at
org.apache.catalina.startup.WebappServiceLoader.load(WebappServiceLoader.java:118)
at
org.apache.catalina.startup.ContextConfig.processServletContainerInitializers(ContextConfig.java:1616)
at
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1128)
at
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:771)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:305)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:95)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5080)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:945)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1798)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
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.NullPointerException: no !/ in spec
at sun.net.www.protocol.jar.Handler.parseAbsoluteSpec(Handler.java:170)
at sun.net.www.protocol.jar.Handler.parseURL(Handler.java:150)
at java.net.URL.(URL.java:614)
... 28 more


Is this a (known) bug, I could not find anything on it?

Is there a workaround (except for turning unpacking of wars on)?

Thanks in advance,

Rob

Re: Web-fragments when unpackWARs=false

[Mark Thomas]

On 09/10/2015 09:33, Rob Gansevles wrote:
> Hi,
> 
> I am trying to use web-fragments on tomcat8, but get an error and the
> webapp does not start when i turn unpacking of wars off.
> 
> Is this a supported combination?
> 
> I can reproduce the error with a plain new tomcat8 install and a standard
> example.
> 
> I am using a simple sample war to make sure the issue is not in my own code.
> 
> I used webfragment-javaee6-war-3.0.0.war, downloaded from Maven Central
> http://search.maven.org/remotecontent?filepath=org/apache/geronimo/samples/javaee6/webfragment-javaee6-war/3.0.0/webfragment-javaee6-war-3.0.0.war
> 
> Deploying this war works fine, until i set unpackWARs="false" on localhost
> in conf/server.xml
> 
> After restart get this error in the logs:
> 
> INFO: Deploying web application archive
> /crypt/apache/tomcat/trunk/output/build/webapps/webfragment-javaee6-war-3.0.0.war
> Oct 09, 2015 10:07:56 AM org.apache.catalina.startup.ContextConfig
> processServletContainerInitializers
> SEVERE: Failed to process JAR found at URL [/webfragment-javaee6-war-3.0.0]
> for ServletContainerInitializers for context with name [{1}]
> java.net.MalformedURLException: no !/ in spec
> at java.net.URL.(URL.java:619)
> at java.net.URL.(URL.java:482)
> at java.net.URL.(URL.java:431)
> at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:179)
> at java.net.JarURLConnection.(JarURLConnection.java:162)
> at
> sun.net.www.protocol.jar.JarURLConnection.(JarURLConnection.java:81)
> at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:41)
> at java.net.URL.openConnection(URL.java:971)
> at java.net.URL.openStream(URL.java:1037)
> at
> org.apache.catalina.startup.WebappServiceLoader.parseConfigFile(WebappServiceLoader.java:161)
> at
> org.apache.catalina.startup.WebappServiceLoader.load(WebappServiceLoader.java:118)
> at
> org.apache.catalina.startup.ContextConfig.processServletContainerInitializers(ContextConfig.java:1616)
> at
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1128)
> at
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:771)
> at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:305)
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:95)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5080)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
> at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:945)
> at
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1798)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> 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.NullPointerException: no !/ in spec
> at sun.net.www.protocol.jar.Handler.parseAbsoluteSpec(Handler.java:170)
> at sun.net.www.protocol.jar.Handler.parseURL(Handler.java:150)
> at java.net.URL.(URL.java:614)
> ... 28 more
> 
> 
> Is this a (known) bug, I could not find anything on it?

If that occurs with the last stable 8.0.x release (8.0.27) then it is a
bug. Please open a Bugzilla issue for this.

> Is there a workaround (except for turning unpacking of wars on)?

If it is a bug then I don't expect that there will be any other workaround.

Mark


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

Re: Web-fragments when unpackWARs=false

[Rob Gansevles]

I submitted bug 58490.

Thanks,

Rob

On Fri, Oct 9, 2015 at 10:38 AM, Mark Thomas  wrote:

> On 09/10/2015 09:33, Rob Gansevles wrote:
> > Hi,
> >
> > I am trying to use web-fragments on tomcat8, but get an error and the
> > webapp does not start when i turn unpacking of wars off.
> >
> > Is this a supported combination?
> >
> > I can reproduce the error with a plain new tomcat8 install and a standard
> > example.
> >
> > I am using a simple sample war to make sure the issue is not in my own
> code.
> >
> > I used webfragment-javaee6-war-3.0.0.war, downloaded from Maven Central
> >
> http://search.maven.org/remotecontent?filepath=org/apache/geronimo/samples/javaee6/webfragment-javaee6-war/3.0.0/webfragment-javaee6-war-3.0.0.war
> >
> > Deploying this war works fine, until i set unpackWARs="false" on
> localhost
> > in conf/server.xml
> >
> > After restart get this error in the logs:
> >
> > INFO: Deploying web application archive
> >
> /crypt/apache/tomcat/trunk/output/build/webapps/webfragment-javaee6-war-3.0.0.war
> > Oct 09, 2015 10:07:56 AM org.apache.catalina.startup.ContextConfig
> > processServletContainerInitializers
> > SEVERE: Failed to process JAR found at URL
> [/webfragment-javaee6-war-3.0.0]
> > for ServletContainerInitializers for context with name [{1}]
> > java.net.MalformedURLException: no !/ in spec
> > at java.net.URL.(URL.java:619)
> > at java.net.URL.(URL.java:482)
> > at java.net.URL.(URL.java:431)
> > at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:179)
> > at java.net.JarURLConnection.(JarURLConnection.java:162)
> > at
> >
> sun.net.www.protocol.jar.JarURLConnection.(JarURLConnection.java:81)
> > at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:41)
> > at java.net.URL.openConnection(URL.java:971)
> > at java.net.URL.openStream(URL.java:1037)
> > at
> >
> org.apache.catalina.startup.WebappServiceLoader.parseConfigFile(WebappServiceLoader.java:161)
> > at
> >
> org.apache.catalina.startup.WebappServiceLoader.load(WebappServiceLoader.java:118)
> > at
> >
> org.apache.catalina.startup.ContextConfig.processServletContainerInitializers(ContextConfig.java:1616)
> > at
> >
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1128)
> > at
> >
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:771)
> > at
> >
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:305)
> > at
> >
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:95)
> > at
> >
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
> > at
> >
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5080)
> > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> > at
> >
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
> > at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
> > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
> > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:945)
> > at
> >
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1798)
> > at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> > 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.NullPointerException: no !/ in spec
> > at sun.net.www.protocol.jar.Handler.parseAbsoluteSpec(Handler.java:170)
> > at sun.net.www.protocol.jar.Handler.parseURL(Handler.java:150)
> > at java.net.URL.(URL.java:614)
> > ... 28 more
> >
> >
> > Is this a (known) bug, I could not find anything on it?
>
> If that occurs with the last stable 8.0.x release (8.0.27) then it is a
> bug. Please open a Bugzilla issue for this.
>
> > Is there a workaround (except for turning unpacking of wars on)?
>
> If it is a bug then I don't expect that there will be any other workaround.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: AW: Problems to configure tomcat as windows service

[Aurélien Terrestris]

OK good that it's finally working.
There is a weakness in the documentation since it duplicates a big part of
the original procrun doc, and it would more readable to just give a short
explanation and give a link as you suggest. You can ask for an improvement
in the bug database ( http://tomcat.apache.org/bugreport.html) but I'm not
sure they will spend time on it as there is no "real" mistake in the doc.

regards


2015-10-09 9:15 GMT+02:00 Arno Schäfer :

> Aurélien,
>
> > still investigating for you in the documentation (
> http://commons.apache.org/proper/commons-daemon/procrun.html ), can you
> try again with --ServiceUser & --ServicePassword instead of --User &
> --Password ?
>
> thanks for that hint. I try it and it works now. :-)
> I miss the point, that my start mode 'jvm' was excluded, but no
> alternative is described in the tomcat documentation.
> Perhaps it will be a good idea to integrate a link to the original procrun
> documentation, when it is more up to date and complete. I didn't recognize
> til today, that this is a separate project.
>
> Thanks for your patience,
> best regards
> Arno
>
>

FarmWarDeployer in a dynamically changing cluster

[Gintautas Sulskus]

Hi,

suppose I have a Tomcat 8 cluster coordinated via multicast.
If I understand it right, any newly started server will be picked up
automatically and any down servers will eventually be dropped out from the
cluster.

I was wondering, how does FarmWarDeployer cope with this dynamics?
Say I have two Tomcat 8 servers T1 and T2 running some apps. Then, a third
server T3 joins the cluster. Does T3 get synced in terms of applications or
do I have to deploy these apps myself?

I believe I have read somewhere in Tomcat documentation that this is the
case. It was very laconic though.

Thanks!

Best Wishes,
Gin

AW: AW: Problems to configure tomcat as windows service

[Arno Schäfer]

Aurélien,

> still investigating for you in the documentation ( 
> http://commons.apache.org/proper/commons-daemon/procrun.html ), can you try 
> again with --ServiceUser & --ServicePassword instead of --User & --Password ?

thanks for that hint. I try it and it works now. :-)
I miss the point, that my start mode 'jvm' was excluded, but no alternative is 
described in the tomcat documentation.
Perhaps it will be a good idea to integrate a link to the original procrun 
documentation, when it is more up to date and complete. I didn't recognize til 
today, that this is a separate project.

Thanks for your patience,
best regards
Arno

Re: Demand CLIENT-CERT only on certain pages but demand SSL in all pages

[Gael Abadin]

@Mark Thomas:

I have been going through the documentation on

https://docs.oracle.com/cd/E19798-01/821-1841/bncbk/index.html

trying to come up with a set of security constraints that allow me to force
SSL without asking for a client certificate except on a single login page,
but there is nothing there suggesting a configuration where I can force SSL
without asking for a client certificate: Once I set the CONFIDENTIAL
transport guarantee and the CLIENT-CERT auth method I will be asked for a
client cert when I land on a SSL page, no matter what.

I think I am getting something wrong. Please, can you be more specific on
the solution you suggest?



2015-10-06 16:52 GMT+02:00 Mark Thomas :

> On 06/10/2015 15:46, George Stanchev wrote:
> > Mark,
> >
> > What are the possible issues with renegotiation? We're on NIO
> connectors, is there anything known?
>
> NIO should be fine. We've seen odd issues on OSX we haven't been able to
> track down.
>
> Mark
>
> >
> > George
> >
> > -Original Message-
> > From: Mark Thomas [mailto:ma...@apache.org]
> > Sent: Monday, October 05, 2015 8:32 AM
> > To: Tomcat Users List
> > Subject: Re: Demand CLIENT-CERT only on certain pages but demand SSL in
> all pages
> >
> > On 05/10/2015 12:05, Gael Abadin wrote:
> >> Hello, fellow users.
> >>
> >> I've been trying to configure tomcat to request client certificate
> >> authentication on a single page, while serving every other SSL page
> >> without requesting a client certificate (before or after
> >> authentication). Depending on the configuration I use, one of 2 things
> >> happen: either I get a request for a client certificate on ANY HTTPS
> >> page I visit first, or I do not get a request at all, never, even when
> >> I launch the browser and go straight to the protected page
> (/my-app-name/public/login/login.xhtml).
> >>
> >> Am I doing something wrong or is this kind of configuration just not
> >> possible?
> >
> > That should be possible but you'll need two security constraints. One to
> require TLS everywhere and one for the pages where you require
> authentication.
> >
> > You may also hit issues with which connectors support renegotiation
> (don't use APR).
> >
> > Mark
> >
> >>
> >> Here is my web.xml security constraint and login config (I've also
> >> tried ommitin ):
> >>
> >>   
> >> 
> >>   Protected Context
> >>   /public/login/*
> >> 
> >> 
> >>   CONFIDENTIAL
> >> 
> >>   
> >>   
> >> CLIENT-CERT
> >>   
> >>
> >>
> >> And here is my server.xml config (I've also tried clientAuth="false"
> >> and
> >> clientAuth="true"):
> >>
> >>   >> shutdown="SHUTDOWN">
> >>>> className="org.apache.catalina.startup.VersionLoggerListener"/>
> >>
> >>   
> >>>> className="org.apache.catalina.core.AprLifecycleListener"/>
> >>   
> >>   
> >>   
> >>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
> >>>>
> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
> >>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
> >> />
> >>
> >>   
> >>  >> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> >> name="UserDatabase" pathname="conf/tomcat-users.xml"
> >> type="org.apache.catalina.UserDatabase"/>
> >>   
> >>
> >>   
> >>
> >>  >> redirectPort="443"/>
> >>
> >>  >> port="443" protocol="org.apache.coyote.http11.Http11Protocol"
> >> scheme="https" secure="true" sslProtocol="TLS"/>
> >>
> >> 
> >>
> >> 
> >>   
> >>  >> resourceName="UserDatabase"/>
> >>   
> >>>> unpackWARs="true">
> >>  >> directory="logs" pattern="%h %l %u %t %r %s %b"
> >> prefix="localhost_access_log." suffix=".txt"/>
> >>  >> reloadable="true" source="org.eclipse.jst.jee.server:cividas-core-web"/>
> >>   
> >> 
> >>   
> >> 
> >>
> >> It is my first Tomcat SSL client cert set up so I must be missing
> >> something. Hope you may help me see it :-)
> >>
> >> Cheers,
> >>
> >
> >
> > -
> > 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
>
>


-- 



.

Alberto Gael Abadin Martinez
Junior Developer

[image: IMATIA]

www.imatia.com

*Tel: *+34 986 342 774 ext 4531

*Email: *gael.aba...@imatia.com
Edificio CITEXVI
Fonte das Abelleiras, s/n - Local 27
36310 Vigo (Pontevedra)
España

.



.

Este 

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

Just for the record, https.protocols is a property used by the 
HttpsUrlConnection class. If your app is using a client that doesn't rely on 
the internal Oracle HTTP client, it's better to use " jdk.tls.client.protocols" 
which is read directly by the socket/SSL classes. Apache Http Client is one 
client that does use sockets directly instead of HttpsUrlConnection.


Also, I want to mention that we have finally been able to isolate a really 
nasty problem with Java SSL implementation and Windows's SSPI based SChannel 
acting as a server. The issue we ran into is very similar as to what the OP 
reported, that’s why I asked him a while ago on a separate thread about 
keystores if the server is IIS-based. The issue that we ran into might sound 
esoteric but our product ran into it very often. We have a configuration where 
we lock our intracomponent communication via 2way SSL. We have Java 
Tomcat-based server components that talk to IIS based native components via web 
services over HTTP which we secure with 2way SSL. When we upgraded to JRE 8 we 
started getting those connection resets in Tomcat when we enabled the 2way SSL. 
Those were on the Java->IIS calls that work over regular SSL. On the java side, 
if you turn on the ssl debug on, you'd see connection reset IOException thrown, 
and on the Windows side, you'd see " The following fatal alert was generated: 
20. The internal error state is 960." In the System event log. This error is " 
TLS1_ALERT_BAD_RECORD_MAC" from SSPI. A search in Oracle's bug database found a 
close resemblance to this issue: 
https://bugs.openjdk.java.net/browse/JDK-8068812. But the reporter couldn't 
reproduce it and also was against another Oracle component Java Web Download or 
something like this. So we started working with Oracle but the intermittent and 
hard-to-reproduce nature of this issue hampered the investigation. As the OP 
mentioned below, there are apocryphal reports for this all over the web but 
people cannot troubleshoot it very well. Anyway here are my findings. In order 
for the issue to arise all those conditions must be met:

[1] The client must start with ClientHello TLSv1.2
[2] The server must respond with ServerHello TLSv1 (so the server should not 
have TLS1.2 enabled)
[3] The cipher key exchange must NOT be ECDHE. I have not tried DHE as I could 
not make Windows take it. According to this doc [1] it should have several DHE 
key exchange ciphers available but I could not make it work. RSA key exchange 
exhibits the issue. I have been using “TLS_RSA_WITH_AES_256_CBC_SHA” to 
reproduce.
[4] The initial connection must not be 2way-SSL
[5] The server must upgrade the connection after encrypted payload is read. In 
case of IIS, it has 2way SSL setting on a Virtual Directory. The initial 
handshake is not 2way SSL, once the HTTP request is read, it determines that 
the requested resource (/gsoap) is 2way SSL-protected and upgrades the 
connection to 2way SSL.
[6] The server must kill the connection abruptly when error happens. This is 
important as if the server terminates the connection gracefully and keeps it 
around Java is able to recover since it reuses the cached connection. IIS does 
exactly this.
[7] The server must be Windows 7, Win2k8, Win2k8-R2, Win8. Might be other 
versions affected but bug is not evident on Win2k12 or Win2k12-R2 or Win10. 
Perhaps it was fixed, perhaps those versions support TLSv1.2

It might sound complicated but it is not, it is very common. All you have to do 
is to have a Virtual Directory in IIS that requires 2way SSL and is set to 
"want". RSA-based key exchanges are one of the most commonly used ciphers. The 
Windows platforms we tested with are still widely used in the enterprises while 
the adoption rate of win2k12+ is still lagging (from our experience with our 
customers). And you have equal "chance" of cipher support between Windows 
servers and Java 8 clients to land on RSA based cipher (which exhibits the 
issue) or ECDHE key exchange that is ok. Again, it might sound too complicated 
but it was blocker for us to ship our product.

For us, to work around this issue is for the 2way SSL to turn off TLSv1.2 (via 
"-Djdk.tls.client.protocols=TLSv1" or RSA key exchange algorithm (via the java 
security properties) on affected systems which fixes it.

I have a lot more technical details that I am not sharing here. I have sent 
them to Oracle so hopefully that gets resolved, but my guess is that is really 
an SSPI/SChannel issue in which case someone needs to work with Microsoft and I 
don't know if my company can do that. It boils down to - when all these 
conditions are met, is Java creating a bad MAC or SChannel fails to verify that 
MAC correctly on SSL handshake step X.

Hopefully this can help someone else, as we have spent quite a bit of time on 
this issue.

George


TL;DR: There is a nasty bug in Java or Windows when calling SSPI-based app over 
2way SSL that you can work around by turning off TLSv1.2 or RSA 

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

One more clarification: on point [6] below I stated that Java is able to 
recover with a retry on a cached connection. Unfortunately that is only valid 
for higher level classes like HttpUrlConnection which makes 1 retry on 
IOException (and only on a GET and some other conditions). The lower-level 
sockets just throw and that’s it...

-Original Message-
From: George Stanchev [mailto:gstanc...@serena.com] 
Sent: Friday, October 09, 2015 10:40 AM
To: Tomcat Users List
Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

Just for the record, https.protocols is a property used by the 
HttpsUrlConnection class. If your app is using a client that doesn't rely on 
the internal Oracle HTTP client, it's better to use " jdk.tls.client.protocols" 
which is read directly by the socket/SSL classes. Apache Http Client is one 
client that does use sockets directly instead of HttpsUrlConnection.


Also, I want to mention that we have finally been able to isolate a really 
nasty problem with Java SSL implementation and Windows's SSPI based SChannel 
acting as a server. The issue we ran into is very similar as to what the OP 
reported, that’s why I asked him a while ago on a separate thread about 
keystores if the server is IIS-based. The issue that we ran into might sound 
esoteric but our product ran into it very often. We have a configuration where 
we lock our intracomponent communication via 2way SSL. We have Java 
Tomcat-based server components that talk to IIS based native components via web 
services over HTTP which we secure with 2way SSL. When we upgraded to JRE 8 we 
started getting those connection resets in Tomcat when we enabled the 2way SSL. 
Those were on the Java->IIS calls that work over regular SSL. On the java side, 
if you turn on the ssl debug on, you'd see connection reset IOException thrown, 
and on the Windows side, you'd see " The following fatal alert was generated: 
20. The internal error state is 960." In the System event log. This error is " 
TLS1_ALERT_BAD_RECORD_MAC" from SSPI. A search in Oracle's bug database found a 
close resemblance to this issue: 
https://bugs.openjdk.java.net/browse/JDK-8068812. But the reporter couldn't 
reproduce it and also was against another Oracle component Java Web Download or 
something like this. So we started working with Oracle but the intermittent and 
hard-to-reproduce nature of this issue hampered the investigation. As the OP 
mentioned below, there are apocryphal reports for this all over the web but 
people cannot troubleshoot it very well. Anyway here are my findings. In order 
for the issue to arise all those conditions must be met:

[1] The client must start with ClientHello TLSv1.2 [2] The server must respond 
with ServerHello TLSv1 (so the server should not have TLS1.2 enabled) [3] The 
cipher key exchange must NOT be ECDHE. I have not tried DHE as I could not make 
Windows take it. According to this doc [1] it should have several DHE key 
exchange ciphers available but I could not make it work. RSA key exchange 
exhibits the issue. I have been using “TLS_RSA_WITH_AES_256_CBC_SHA” to 
reproduce.
[4] The initial connection must not be 2way-SSL [5] The server must upgrade the 
connection after encrypted payload is read. In case of IIS, it has 2way SSL 
setting on a Virtual Directory. The initial handshake is not 2way SSL, once the 
HTTP request is read, it determines that the requested resource (/gsoap) is 
2way SSL-protected and upgrades the connection to 2way SSL.
[6] The server must kill the connection abruptly when error happens. This is 
important as if the server terminates the connection gracefully and keeps it 
around Java is able to recover since it reuses the cached connection. IIS does 
exactly this.
[7] The server must be Windows 7, Win2k8, Win2k8-R2, Win8. Might be other 
versions affected but bug is not evident on Win2k12 or Win2k12-R2 or Win10. 
Perhaps it was fixed, perhaps those versions support TLSv1.2

It might sound complicated but it is not, it is very common. All you have to do 
is to have a Virtual Directory in IIS that requires 2way SSL and is set to 
"want". RSA-based key exchanges are one of the most commonly used ciphers. The 
Windows platforms we tested with are still widely used in the enterprises while 
the adoption rate of win2k12+ is still lagging (from our experience with our 
customers). And you have equal "chance" of cipher support between Windows 
servers and Java 8 clients to land on RSA based cipher (which exhibits the 
issue) or ECDHE key exchange that is ok. Again, it might sound too complicated 
but it was blocker for us to ship our product.

For us, to work around this issue is for the 2way SSL to turn off TLSv1.2 (via 
"-Djdk.tls.client.protocols=TLSv1" or RSA key exchange algorithm (via the java 
security properties) on affected systems which fixes it.

I have a lot more technical details that I am not sharing here. I have sent 
them to Oracle so 

Re: Monitoring Connections

[Jamie Jackson]

Here's the stack trace dump:
https://gist.github.com/jamiejackson/ca2a49d2c8afac496067

FWIW, I've been trying to come up with a reliable test case to trigger the
problem, but I haven't nailed it yet. I've suspected that it's related to
file (large or slow) HTTP file uploads, and that's what I was running at
the time, which helps to explain the java.net.SocketInputStream.socketRead0
 traces.

Thanks,
Jamie

On Fri, Oct 9, 2015 at 7:32 AM, Jamie Jackson  wrote:

> Thanks, so far, everyone.
>
> I do already have a JVM monitoring tool in action--FusionReactor. I'm not
> very familiar with some of the other offerings, but FR has seemed
> full-featured to me, so I'm going to continue with FR until I find out
> if/that it's missing some key aspect.
>
> I managed to trigger the problem on my load test server yesterday, and
> grabbed a stack trace from FR. Sometimes, the problem identified by a stack
> trace is obvious (to me), but I didn't spot anything in this one, at a
> glance.
>
> I"ll post the stack trace once I get back to work, and we can start there.
>
> Thanks,
> Jamie
>
> On Thu, Oct 8, 2015 at 3:25 PM, Leon Rosenberg 
> wrote:
>
>> On Wed, Oct 7, 2015 at 11:59 PM, Aurélien Terrestris <
>> aterrest...@gmail.com>
>> wrote:
>>
>> > Hi Jamie,
>> > 
>> >
>> > If you enjoy live monitoring, you need to have a look on Christopher's
>> > presentation (
>> >
>> >
>> http://events.linuxfoundation.org/sites/events/files/slides/Monitoring%20Apache%20Tomcat%20with%20JMX.pdf
>> > ) who posts many answers to this mailing list.
>> >
>> >
>> > or if you want to go deeper, try MoSKito (http://www.moskito.org)
>>
>> regards
>> Leon
>>
>>
>> >
>> >
>>
>
>

Re: is there already a case for web-fragment.xml in the war and then unpack=false option to not extract the war?

[Johan Compagner]

a case is created:

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



On 22 September 2015 at 11:37, Mark Thomas  wrote:

> On 22/09/2015 10:25, Johan Compagner wrote:
> > Hi,
> >
> > when we have a webfragment in our war  to enable i think that absolute
> > ordering
> > we get this exception?:
>
> Tomcat version?
>
> Mark
>
>
> >
> > 21-Sep-2015 14:15:11.355 SEVERE [localhost-startStop-1]
> >
> org.apache.catalina.startup.ContextConfig.processServletContainerInitializers
> > Failed to process JAR found at URL [/post_install_test] for
> > ServletContainerInitializers for context with name [{1}]
> >  java.net.MalformedURLException: no !/ in spec
> >   at java.net.URL.(Unknown Source)
> >   at java.net.URL.(Unknown Source)
> >   at java.net.URL.(Unknown Source)
> >   at java.net.JarURLConnection.parseSpecs(Unknown Source)
> >   at java.net.JarURLConnection.(Unknown Source)
> >   at sun.net.www.protocol.jar.JarURLConnection.(Unknown Source)
> >   at sun.net.www.protocol.jar.Handler.openConnection(Unknown Source)
> >   at java.net.URL.openConnection(Unknown Source)
> >   at java.net.URL.openStream(Unknown Source)
> >   at
> org.apache.catalina.startup.WebappServiceLoader.parseConfigFile(WebappServiceLoader.java:156)
> >   at
> org.apache.catalina.startup.WebappServiceLoader.load(WebappServiceLoader.java:113)
> >   at
> org.apache.catalina.startup.ContextConfig.processServletContainerInitializers(ContextConfig.java:1597)
> >   at
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1125)
> >   at
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:768)
> >   at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:303)
> >   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:5069)
> >   at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> >   at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:724)
> >   at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:700)
> >   at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:697)
> >   at
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:919)
> >   at
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1704)
> >   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
> Source)
> >   at java.util.concurrent.FutureTask.run(Unknown Source)
> >   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
> >   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
> >   at java.lang.Thread.run(Unknown Source)
> > Caused by: java.lang.NullPointerException: no !/ in spec
> >   at sun.net.www.protocol.jar.Handler.parseAbsoluteSpec(Unknown
> Source)
> >   at sun.net.www.protocol.jar.Handler.parseURL(Unknown Source)
> >   ... 29 more
> >
> >
> > if we say to tomcat8 to not extract the war (unpack=false)
> >
> >
> > This is completely outside of the application itself because it is
> > trying to start it. when unpack is default (true) then it works fine.
> >
> >
> > so in our WEB-INF/web.xml we have:
> >
> >
> >   
> > servoy_ngclient
> >   
> >
> >
> >
> > and then in the WEB-INF/lib/ngclient.jar/META-INF/web-fragement.xml
> >
> >
> > http://java.sun.com/xml/ns/javaee;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> > http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd; version="3.0">
> >   servoy_ngclient
> > 
> >
> >
> > If we remove that ordering and/or the web-fragement.xml then it starts
> > working again
> >
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Johan Compagner
Servoy

Re: Monitoring Connections

[Jamie Jackson]

Thanks, so far, everyone.

I do already have a JVM monitoring tool in action--FusionReactor. I'm not
very familiar with some of the other offerings, but FR has seemed
full-featured to me, so I'm going to continue with FR until I find out
if/that it's missing some key aspect.

I managed to trigger the problem on my load test server yesterday, and
grabbed a stack trace from FR. Sometimes, the problem identified by a stack
trace is obvious (to me), but I didn't spot anything in this one, at a
glance.

I"ll post the stack trace once I get back to work, and we can start there.

Thanks,
Jamie

On Thu, Oct 8, 2015 at 3:25 PM, Leon Rosenberg 
wrote:

> On Wed, Oct 7, 2015 at 11:59 PM, Aurélien Terrestris <
> aterrest...@gmail.com>
> wrote:
>
> > Hi Jamie,
> > 
> >
> > If you enjoy live monitoring, you need to have a look on Christopher's
> > presentation (
> >
> >
> http://events.linuxfoundation.org/sites/events/files/slides/Monitoring%20Apache%20Tomcat%20with%20JMX.pdf
> > ) who posts many answers to this mailing list.
> >
> >
> > or if you want to go deeper, try MoSKito (http://www.moskito.org)
>
> regards
> Leon
>
>
> >
> >
>

JDBC PoolExhaustedException

[Nathan Boyce]

Does the tomcat jdbc pool use its own executor or does it share the executor 
that's calling it?  Reason I ask is the pool size is set to 320 but only 84 
show busy.  The default tomcatThreadPool executor has been removed from this 
config and executor with the name AJPThreadPool has been added for the ajp 
connections. The ajp thread pool is maxing out but unable to tell is it's the 
cause or effect. 

Server.xml config 
 

Error
org.apache.tomcat.jdbc.pool.PoolExhaustedException: [ajp-693] Timeout: Pool 
empty. Unable to fetch a connection in 10 seconds, none available[size:320; 
busy:84; idle:0; lastwait:1].


Apache Tomcat Version 7.0.55

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

Re: Tomcat bad char issue with new cluster

[Saurav Maulick]

Hi Christopher,

On Thu, Oct 8, 2015 at 5:11 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Saurav,
>
> On 10/8/15 4:45 PM, Saurav Maulick wrote:
> > URIEncoding setting is present in both the HTTP Connector and AJP
> > Connector.
>
> ... and what is the value of that attribute?
>

Please see the Connector Values




 


>
> >  is not present in the conf/web.xml.
>
> Where? The working or non-working nodes? Or both?
>

 is not present in the both the working and non working nodes.

>
> The real question is "what is making the working nodes work". The
> you'll have the answer to the question "what do I need to do to my
> non-working nodes to make them work".
>
> It might end up being something simple like LC_CTYPE environment
> variable on one system versus the other. It *should not* be something
> like that -- there is configuration available everywhere for setting
> the character encoding of the data being handled, but things like
> database drivers might default to using the local default encoding.
>
> > when I try to add  it gives HTTP Status 404" error (please
> > see the below  code
> >
> > 
> >
> > SetCharacterEncoding
> >
> >
> > org.apache.catalina.filters.SetCharacterEncodingFilter filter-class>
> >
> >  
> >
> > encoding
> >
> > UTF-8
> >
> > 
> >
> > 
> >
> >
> >
> > 
> >
> > SetCharacterEncoding
> >
> > /*
> >
> > /
>
> /* and / are the same, logically.
>
> It's possible that mapping to "/" will do horrible things. Have you
> looked at the log files when you start up with this configuration?
>
> You should remove "/" and leave "/*".
>
> > 
> >
> > For database we have created a request to DB team to get more
> > information about that, but as this is a very complex tool and tool
> > itself creates database connection, it is very hard to identify the
> > exact table.
>
> Okay... what about using the tool on a working server, and then trying
> to load the data on a non-working server? Or entering data on a
> non-working server and looking at the data from a working server?
>

We have one Application server and multiple nodes.

>
> - -chris
>
> > On Wed, Oct 7, 2015 at 11:52 AM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Saurav,
> >
> > On 10/6/15 9:37 AM, Saurav Maulick wrote:
>  Please find my answer below
> 
> 
>  *Two new clusters or two new nodes added to an existing
>  cluster?*
> 
>  Two Nodes
> 
> 
>  *What is the difference between the conf/server.xml on a
>  "working" server and one of these new servers that is
>  misbehaving?*
> 
>  No difference. Apart from Server port –Configuration,
>  non-SSL HTTP/1.1Connector port Configuration, AJP 1.3
>  Connector port Configuration, and jvmRoute Configuration
> 
> 
>  *Identical WAR files deployed to all servers?*
> 
>  Yes all the nodes have identical WAR file
> >
> > The problem here is usually with the  URIEncoding
> > setting (probably should be UTF-8 these days) or with clients who
> > send a content-type header without specifying the character
> > encoding, leaving the server to default to ISO-8851-1 (instead of
> > UTF-8, which ought to be the default these days).
> >
> > Tomcat 8 uses UTF-8 as the default  URIEncoding, unless
> > the system property org.apache.catalina.STRICT_SERVLET_COMPLIANCE
> > is set to true. Tomcat 5.5 *always* uses ISO-8859-1 as the
> > default. http://tomcat.apache.org/tomcat-8.0-doc/config/http.html
> > http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
> >
> > Mikel was asking about  in Tomcat's conf/web.xml because
> > it's typical these days to use a SetCharacterEncodingFilter to
> > override the HTTP-spec-defined requirement that ISO-8859-1 be used
> > when the client does not specify a character set.
> > http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#Set_Charact
> er
> >
> >
> _Encoding_Filter
> > http://tomcat.apache.org/tomcat-5.5-doc/config/filter.html#Set_Charact
> er
> >
> >
> _Encoding_Filter
> >
> > Finally, you should double-check your database connection
> > configuration. If you have the character set incorrect, there, you
> > can break data in both directions from the database.
> >
> > Can you tell if the characters are broken for GET vs POST
> > requests? Can you check to see if this is an input or output
> > problem? You can check the string in the database to see if the
> > error is present there?
> >
> > Have a read through this document; it will help you look at all
> > the places where there might be a problems:
> > http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8
> >
> > -chris
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools -