Some Web Applications fail to deploy !

2016-05-05 Thread Utkarsh Dave
Hi Tomcat users and owners,

I upgraded to tomcat 7.0.69 from 64 and noticed that some of the web
applications do not get deployed.
After verifying i noticed that with tomcat 7.0.64, manager.log file use to
populated with these additional logs where as it is not seen in new Tomcat.

May 05, 2016 6:26:20 AM org.apache.catalina.core.ApplicationContext log
INFO: Manager: init: Associated with Deployer
'Catalina:type=Deployer,host=localhost'
..
INFO: Manager: install: Installing web application 'XXX' from
'file:/usr/local/webapps/XXX.war'
May 05, 2016 6:28:29 AM org.apache.catalina.core.ApplicationContext log
INFO: Manager: install: Installing web application 'YYY' from
'file:/usr/local/webapps/YYY.war'
May 05, 2016 6:28:32 AM org.apache.catalina.core.ApplicationContext log
INFO: Manager: install: Installing web application 'ZZZ' from
'file:/usr/local/webapps/ZZZ.war'
.
XXX,YYY and ZZZ do not get copied from /usr/local/webapps to Tomcat/webapps
Is this some new functionality we put in or I am missing something.

-Thanks
Utkarsh


Re: Auto-bounce a host or webapp?

2016-05-05 Thread Jerry Malcolm

On 5/5/2016 2:05 PM, David kerber wrote:

On 5/5/2016 2:56 PM, Jerry Malcolm wrote:

I am not using WAR files for my apps.  I simply copy updated files to
the image in \webapps as changes/updates are required.  I have a server
running on my local dev machine.  When I refresh any webapp file (jars,
jsps, etc) the server detects the changes, refreshes, and everything is
good with the new versions running without further intervention.
However, when I do the exact same thing to my remote server (which is an
identical mirror of the local TC) almost every time there is a refresh,
the server webapp stops, and I have to go the manager and restart all of
the web apps.

I'm suspecting that it might have something to do with the upload
speed.  Where I can pretty much instantly replace a jar file locally, it
may take several seconds to replace the same jar file on the remote
machine due to connection speed to the server.  And I assume TC is ok
with 'instant' jar replacements, but doesn't like it when it takes too
long for a jar to finish updating.

Whatever the cause, I've resigned myself to the fact that I'm going to
have to restart the webapps after every upload.  But I'd love to figure
out a way to do that automatically (preferably as part of my ant 'build'
script).  A full refresh can take 20-30 minutes (I have lots of large
web apps...).  I have to wait around for the upload to complete, else
the server will be down until I can come back and around and refresh.

So, is there a way to bounce an entire host programatically at the end
of the upload?  Or is there a way to remotely via a script to bounce all
of the webapps?


I believe the Manager app can force a reload of your webapps, though I 
never use it.


But what about this, to make the process more closely mirror what you 
see locally:  Upload the updated files to a temporary holding spot on 
the remote server, and then after they're all there, move them en-mass 
to the webapps directory.  That final copy will be very fast, and 
would likely allow the server to pick up the changes just like it does 
locally.


Thanks for the info.  I had thought about the option of caching on the 
server and doing a fast copy.  But that will still require code on the 
server to execute the copy from the cache, and somehow the server code 
will need to be triggered by the build/upload process on the build 
machine or otherwise I have to log onto the server desktop and run it 
manually.  My build/upload process is totally automated using ant except 
for this one nagging issue with the webapps.


The manager has the web interface to restart the web apps.  But I have 
20 web apps.  And the manager makes me start each web app one at a time 
and wait for the page to reload before going to next app. Cumbersome at 
best.


Any other suggestions?

Thanks.

Jerry

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



Re: Do I need a keystore?

2016-05-05 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew,

On 5/5/16 9:09 PM, Matthew Herzog wrote:
> You said, "the http-bio-8443 endpoint is an HTTP connector, not an
> AJP13 connector."
> 
> This is confusing to me because all the tutorials I have read don't
> say anything about commenting out the line in server.xml that
> reads:
> 
> 

Usually tutorials are written to get you started quickly, and don't
want to explain what's really going on.

Read the documentation for "redirectPort" on this page:
https://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html
(or this page)
https://tomcat.apache.org/tomcat-8.0-doc/config/http.html

The redirectPort has meaning, but it's not the meaning you were
thinking. The real port being used above is 8009. You can set the
redirect port to 12345 and you will still use port 8009 to connect to
your AJP connector.

In your case, it appears you are not even using your AJP connector, so
its configuration is essentially meaningless.

> I had assumed port 8443 was analogous to port 443. Bad assumption
> on my part.

8443 is traditionally the port used by non-privileged processes to
listen for HTTPS requests. That's why you'll likely see a  somewhere in your
configuration. In order to use TLS (the modern name for what used to
be called SSL), you definitely need to have a keystore.

(I suppose you could use NULL authentication and/or key exchange and
yes, I guess you could use a pre-shared key, but I don't believe
Tomcat currently supports such setups, and obviously using NULL
authentication and/or key exchange pretty much means that you aren't
using encryption, so there's no point in using HTTPS at that point.)

But, really: don't run Tomcat as root. If there's a reason you think
you should be (or need to be) running Tomcat as root, let us know and
we'll tell you how to fix that so you don't need to run as root anymore.

Hope that helps,
- -chris

> On Thu, May 5, 2016 at 5:28 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Matthew,
> 
> On 5/5/16 5:05 PM, Matthew Herzog wrote:
 when I run the startup script
 
 /usr/bin/java -Djava.security.egd=file:/dev/./urandom 
 -Djava.awt.headless=true -Xmx512m -XX:MaxPermSize=256m 
 -XX:+UseConcMarkSweepGC -classpath 
 /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-ju
li.
>
 
jar:/usr/share/java/commons-daemon.jar
 
 
> -Dcatalina.base=/usr/share/tomcat
> -Dcatalina.home=/usr/share/tomcat
 -Djava.endorsed.dirs=
 -Djava.io.tmpdir=/var/cache/tomcat/temp 
 -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.prop
ert
>
 
ies
 
 
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
 org.apache.catalina.startup.Bootstrap start
 
 I see the following error.
 
 SEVERE: Failed to initialize end point associated with 
 ProtocolHandler ["http-bio-8443"]
 
 java.io.FileNotFoundException: /root/.keystore (No such file
 or directory) So if I change my ajp config from
 
 >>> /> to
 
 >>> />
 
 will I be able to avoid the keystore work? I'm doing a proof
 of concept so my cluster will never be exposed to the
 Internet.
> 
> You are confused about a few things:
> 
> 1. It's never good to run as root. Stop doing that.
> 
> 2. The "redirectPort" attribute doesn't have any effect on what
> ports Tomcat binds to.
> 
> 3. The http-bio-8443 endpoint is an HTTP connector, not an AJP13 
> connector.
> 
> 4. If you want to enable TLS, then yes, you will need a keystore.
> 
> So, if you don't need HTTPS, then disable whatever connector you
> have that looks kind of like this:
> 
> 
> 
> -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 - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlcsHHoACgkQ9CaO5/Lv0PBKhQCgsJu9C2UMC96ZGNdP5NB3OwpV
+qoAnA7gObq81vvSAtQg49aTwjZw7oN6
=TA7w
-END PGP SIGNATURE-

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



Re: Do I need a keystore?

2016-05-05 Thread Matthew Herzog
Firstly, thanks.

You said, "the http-bio-8443 endpoint is an HTTP connector, not an AJP13
connector."

This is confusing to me because all the tutorials I have read don't say
anything about commenting out the line in server.xml that reads:



I had assumed port 8443 was analogous to port 443. Bad assumption on my
part.

On Thu, May 5, 2016 at 5:28 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Matthew,
>
> On 5/5/16 5:05 PM, Matthew Herzog wrote:
> > when I run the startup script
> >
> > /usr/bin/java -Djava.security.egd=file:/dev/./urandom
> > -Djava.awt.headless=true -Xmx512m -XX:MaxPermSize=256m
> > -XX:+UseConcMarkSweepGC -classpath
> > /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.
> jar:/usr/share/java/commons-daemon.jar
> >
> >
> - -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat
> > -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp
> > -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.propert
> ies
> >
> >
> - -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> > org.apache.catalina.startup.Bootstrap start
> >
> > I see the following error.
> >
> > SEVERE: Failed to initialize end point associated with
> > ProtocolHandler ["http-bio-8443"]
> >
> > java.io.FileNotFoundException: /root/.keystore (No such file or
> > directory) So if I change my ajp config from
> >
> > 
> > to
> >
> > 
> >
> > will I be able to avoid the keystore work? I'm doing a proof of
> > concept so my cluster will never be exposed to the Internet.
>
> You are confused about a few things:
>
> 1. It's never good to run as root. Stop doing that.
>
> 2. The "redirectPort" attribute doesn't have any effect on what ports
> Tomcat binds to.
>
> 3. The http-bio-8443 endpoint is an HTTP connector, not an AJP13
> connector.
>
> 4. If you want to enable TLS, then yes, you will need a keystore.
>
> So, if you don't need HTTPS, then disable whatever connector you have
> that looks kind of like this:
>
>
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlcruwwACgkQ9CaO5/Lv0PDwTgCgkTa+TGbqw9WX0ttjVPShmKlr
> z24AnRnkDLeXVQcOxNVBU0EdHKxVB+Yw
> =KyZE
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
"I am no Einstein."
-- Albert Einstein


RE: BackupManager Heterogeneous Environment / Functionality?

2016-05-05 Thread Decker, Richard M


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, May 05, 2016 4:26 PM
To: Tomcat Users List 
Subject: Re: BackupManager Heterogeneous Environment / Functionality?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Richard,

On 5/5/16 3:29 PM, Decker, Richard M wrote:
> I'm trying to configure & demo an Apache Tomcat [v8] cluster env, that 
> supports different apps functioning on different systems.
> 
> Basically, I'm trying to setup an environment where an app can be on 
> only 1 or 2 (deployed or running) out of the 3 Tomcat systems in the 
> cluster. However, this does not seem to work for me, as I can't get 
> away from the 404s when Apache HTTPD goes to a random (round robin) 
> Tomcat system, that does not have the application (running or 
> deployed) on it.

The one thing you forgot to post was your JkMounts from httpd.conf (or 
similar). Can you post those? I believe this can be entirely solved with a 
slightly more complicated configuration.

Chris, 

Thanks for the quick reply. The info you requested is below. The config is 
identical (minus machine names) on the 2 apache httpd systems.

[httpd.conf] equivalent - All JkUn/Mounts


# All requests go to tomcattest by default
JkMount /* acttomcattest
# examples:
# Static files in the examples webapp are served by apache
#Alias /examples /tomcat/webapps/examples
# here we serve the generic default page via apache instead of tomcat
JkUnMount / tomcattest
JkUnMount /index.html tomcattest
JkUnMount /logo.gif  tomcattest
# Serve gif using httpd
#JkUnMount /*.gif  tomcattest


JkMount /status statustest


> This happens with both new & cached sessions. I can bring an entire 
> Tomcat system down, and it works as designed, but not for (stopped or 
> undeployed) single applications. I'm really not sure how Tomcat and 
> Apache are supposed to communicate with each other in this regard; so 
> they know what apps are deployed/running on each system. Is this even 
> possible?

Yep. You just need to tell your load-balancer about which applications can be 
found where.

So you're suggesting that I list every app in the apache/httpd config, or just 
those that won't be deployed across the whole (3 system) env?  Sound promising 
, but problematic of having to restart the Apache service, whenever a change is 
made.

> According to the link below, it should work...
> 
> http://tomcat.apache.org/tomcat-8.0-doc/config/cluster-manager.html
>
>
>
> 
The org.apache.catalina.ha.session.BackupManager also replicates
> deltas but only to one backup node. The location of the backup node is 
> known to all nodes in the cluster. It also supports heterogeneous 
> deployments, so the manager knows at what locations the web 
> application is deployed.
> 
>  Env - Top Down 
> 
> [Load Balancer] - (Sticky Sessions) | [HTTPD1] - [HTTPD2] - (Load 
> Balanced, Sticky Sessions) | [Tomcat1] - [Tomcat2] - [Tomcat3] -
> (BackupManager)

Okay.

>  Config 
> 
> [HTTPD] worker.list=tomcattest, statustest
> 
> worker.tomcat1.type=ajp13 worker.tomcat1.host=tomcat1 
> worker.tomcat1.port= #worker.tomcat1.lbfactor=5
> 
> worker.tomcat2.type=ajp13 worker.tomcat2.host=tomcat2 
> worker.tomcat2.port= #worker.tomcat2.lbfactor=5
> 
> worker.tomcat3.type=ajp13 worker.tomcat3.host=tomcat3 
> worker.tomcat3.port= #worker.tomcat3.lbfactor=5
> 
> worker.tomcattest.type=lb
> worker.tomcattest.balance_workers=tomcat1,tomcat2,tomcat3
> worker.tomcattest.sticky_session=True # lb methods: [R]equest, 
> [S]ession, [T]raffic, [B]usiness worker.tomcattest.method=R 
> worker.statustest.type=status

If you define more than one lb worker, you can do this in a more nuanced way. 
For example:

worker.tomcat1.host=tomcat1
worker.tomcat1.port=

worker.tomcat2.host=tomcat2
worker.tomcat2.port=

worker.tomcat3.host=tomcat3
worker.tomcat3.port=

worker.app-a.type=lb
worker.app-a.balance_workers=tomcat1,tomcat2
worker.app-a.sticky_session=True

worker.app-a.type=lb
worker.app-a.balance_workers=tomcat2,tomcat3
worker.app-a.sticky_session=True

Then, in httpd.conf:

JkMount /app-a/*   app-a
JkMount /app-b/*   app-b

I think I follow you here.

You can just deploy the applications wherever you want them.

Now, how do you deploy them everywhere but then allow one of them to be taken 
out of service without taking-down the whole Tomcat instance?

Tomcat app manager - stopping the application. Or removing/deleting/ 
undeploying the application itself while Tomcat is (hot) running. This will 
most likely break the config for Apache <-> Tomcat though?

There are several ways of doing that which I'll summarize, here. Let's start a 
new thread if you want to ask about how to do this in further detail.

1. Deploy a ROOT application on each Tomcat node that will return a "failure" 
status 

Re: Do I need a keystore?

2016-05-05 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew,

On 5/5/16 5:05 PM, Matthew Herzog wrote:
> when I run the startup script
> 
> /usr/bin/java -Djava.security.egd=file:/dev/./urandom 
> -Djava.awt.headless=true -Xmx512m -XX:MaxPermSize=256m 
> -XX:+UseConcMarkSweepGC -classpath 
> /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.
jar:/usr/share/java/commons-daemon.jar
>
> 
- -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat
> -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp 
> -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.propert
ies
>
> 
- -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> org.apache.catalina.startup.Bootstrap start
> 
> I see the following error.
> 
> SEVERE: Failed to initialize end point associated with
> ProtocolHandler ["http-bio-8443"]
> 
> java.io.FileNotFoundException: /root/.keystore (No such file or
> directory) So if I change my ajp config from
> 
>  
> to
> 
> 
> 
> will I be able to avoid the keystore work? I'm doing a proof of
> concept so my cluster will never be exposed to the Internet.

You are confused about a few things:

1. It's never good to run as root. Stop doing that.

2. The "redirectPort" attribute doesn't have any effect on what ports
Tomcat binds to.

3. The http-bio-8443 endpoint is an HTTP connector, not an AJP13
connector.

4. If you want to enable TLS, then yes, you will need a keystore.

So, if you don't need HTTPS, then disable whatever connector you have
that looks kind of like this:

   

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

iEYEARECAAYFAlcruwwACgkQ9CaO5/Lv0PDwTgCgkTa+TGbqw9WX0ttjVPShmKlr
z24AnRnkDLeXVQcOxNVBU0EdHKxVB+Yw
=KyZE
-END PGP SIGNATURE-

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



Re: BackupManager Heterogeneous Environment / Functionality?

2016-05-05 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Richard,

On 5/5/16 3:29 PM, Decker, Richard M wrote:
> I'm trying to configure & demo an Apache Tomcat [v8] cluster env, 
> that supports different apps functioning on different systems.
> 
> Basically, I'm trying to setup an environment where an app can be 
> on only 1 or 2 (deployed or running) out of the 3 Tomcat systems
> in the cluster. However, this does not seem to work for me, as I
> can't get away from the 404s when Apache HTTPD goes to a random
> (round robin) Tomcat system, that does not have the application
> (running or deployed) on it.

The one thing you forgot to post was your JkMounts from httpd.conf (or
similar). Can you post those? I believe this can be entirely solved
with a slightly more complicated configuration.

> This happens with both new & cached sessions. I can bring an
> entire Tomcat system down, and it works as designed, but not for
> (stopped or undeployed) single applications. I'm really not sure
> how Tomcat and Apache are supposed to communicate with each other
> in this regard; so they know what apps are deployed/running on each
> system. Is this even possible?

Yep. You just need to tell your load-balancer about which applications
can be found where.

> According to the link below, it should work...
> 
> http://tomcat.apache.org/tomcat-8.0-doc/config/cluster-manager.html
>
>
>
> 
The org.apache.catalina.ha.session.BackupManager also replicates
> deltas but only to one backup node. The location of the backup
> node is known to all nodes in the cluster. It also supports 
> heterogeneous deployments, so the manager knows at what locations 
> the web application is deployed.
> 
>  Env - Top Down 
> 
> [Load Balancer] - (Sticky Sessions) | [HTTPD1] - [HTTPD2] - (Load 
> Balanced, Sticky Sessions) | [Tomcat1] - [Tomcat2] - [Tomcat3] - 
> (BackupManager)

Okay.

>  Config 
> 
> [HTTPD] worker.list=tomcattest, statustest
> 
> worker.tomcat1.type=ajp13 worker.tomcat1.host=tomcat1 
> worker.tomcat1.port= #worker.tomcat1.lbfactor=5
> 
> worker.tomcat2.type=ajp13 worker.tomcat2.host=tomcat2 
> worker.tomcat2.port= #worker.tomcat2.lbfactor=5
> 
> worker.tomcat3.type=ajp13 worker.tomcat3.host=tomcat3 
> worker.tomcat3.port= #worker.tomcat3.lbfactor=5
> 
> worker.tomcattest.type=lb 
> worker.tomcattest.balance_workers=tomcat1,tomcat2,tomcat3 
> worker.tomcattest.sticky_session=True # lb methods: [R]equest, 
> [S]ession, [T]raffic, [B]usiness worker.tomcattest.method=R 
> worker.statustest.type=status

If you define more than one lb worker, you can do this in a more
nuanced way. For example:

worker.tomcat1.host=tomcat1
worker.tomcat1.port=

worker.tomcat2.host=tomcat2
worker.tomcat2.port=

worker.tomcat3.host=tomcat3
worker.tomcat3.port=

worker.app-a.type=lb
worker.app-a.balance_workers=tomcat1,tomcat2
worker.app-a.sticky_session=True

worker.app-a.type=lb
worker.app-a.balance_workers=tomcat2,tomcat3
worker.app-a.sticky_session=True

Then, in httpd.conf:

JkMount /app-a/*   app-a
JkMount /app-b/*   app-b

You can just deploy the applications wherever you want them.

Now, how do you deploy them everywhere but then allow one of them to
be taken out of service without taking-down the whole Tomcat instance?

There are several ways of doing that which I'll summarize, here. Let's
start a new thread if you want to ask about how to do this in further
detail.

1. Deploy a ROOT application on each Tomcat node that will return a
"failure" status whenever you request /app-a/* or /app-b/* (etc.).
Maybe the ROOT web application ALWAYS returns an error status.

2. Use the mod_jk status worker to set the activation status of one of
the Tomcat nodes to "DIS" (disabled). This will send requests without
a session identifier to other nodes in the balancer. Set it to "STO"
and it will cause *all* requests to be sent to other nodes.

The first method is more fault-tolerant and lazy, since you don't have
to tell mod_jk when nodes will be going down. The second method is a
little more work, but it also means that you can drain nodes before
scheduled maintenance, which is nice.

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

iEYEARECAAYFAlcrukwACgkQ9CaO5/Lv0PA1QwCgroEfkUXGfhJnGVWu4PlWES4v
mqAAnA3+F9TGgC1jLbGD7SOh5/4JkJAS
=KvPU
-END PGP SIGNATURE-

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



Do I need a keystore?

2016-05-05 Thread Matthew Herzog
when I run the startup script

/usr/bin/java -Djava.security.egd=file:/dev/./urandom
-Djava.awt.headless=true -Xmx512m -XX:MaxPermSize=256m
-XX:+UseConcMarkSweepGC -classpath
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
-Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp
-Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
org.apache.catalina.startup.Bootstrap start

I see the following error.

SEVERE: Failed to initialize end point associated with ProtocolHandler
["http-bio-8443"]

java.io.FileNotFoundException: /root/.keystore (No such file or directory)
So if I change my ajp config from


to



will I be able to avoid the keystore work? I'm doing a proof of concept so
my cluster will never be exposed to the Internet.

-- 
"I am no Einstein."
-- Albert Einstein


Re: Tomcat connector settings

2016-05-05 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael,

On 5/5/16 3:28 PM, Michael Fox wrote:
> Please confirm that to configure the passthrough with an external 
> HTTPS and an internal HTTP, I would set Apache to listen to SSL on 
> port 8443 and Tomcat on port 8080, with a line inside the Virtual 
> Host directive of
> 
> ProxyPass /myapp http://DNS_hostname:8080/myapp ProxyPassReverse
> /myapp http://DNS_hostname:8080/myapp

If DNS_hostname is the hostname of your Tomcat server, then yes, this
is correct. If the web server and Tomcat are on the same host, then
you can use "localhost" which should speed things up.

I'm guessing that the powers-that-be are using the web server
elsewhere, so they'll have to use the IP address (or hostname) of
wherever Tomcat is running in the URLs above.

Note that there is no requirement to use port 8080 -- you can use
anything you'd like -- but 8080 is somewhat traditional and also
happens to be the default configuration shipped with Tomcat.

> In the Tomcat server.xml file, inside the Host directive, I will 
> place  />

Good.

> In the file /etc/httpd/conf/workers.properties,
> worker.worker1.host should be set to DNS_hostname and
> worker.worker1.port is set to 8080.

Nope. You don't need a workers.properties file at all. That's for us
you want to use mod_jk and the AJP13 protocol as a proxying protocol.
Since you are using HTTP, you don't need any of that stuff.

(At worst, it will be confusing, since Tomcat will be listening on
:8080 for HTTP connections, not AJP13 connections.)

> With this setup, the URL for accessing the Tomcat application via
> the Apache server would be https://DNS_hostname/myapp

If Tomcat is on DNS_hostname, then this is probably wrong. If
DNS_hostname points to the host where the reverse-proxy (web server)
is, then you are correct.

Here's the ASCII-art picture:

Client --- HTTPS:443 ---> web server --- HTTP:8080 --> Tomcat

If you wanted to use AJP13 with mod_jk (or mod_proxy_ajp), it would
look like this:

Client --- HTTPS:443 ---> web server --- AJP13:8009 --> Tomcat

(8009 is the default port setting for AJP13 in a Tomcat configuration.)

- From the client perspective, the URL should be
https://publichostname/myapp. From the web server's perspective, the
URL should be http://tomcat.internal.hostname:8080/myapp

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

iEYEARECAAYFAlcrsg8ACgkQ9CaO5/Lv0PBXzQCfaL/Dy/GqKA/7t0WSex8ZzPb8
iaAAn2TwoF3N89NHiEQEimZ+VjDA4Y4+
=DMoV
-END PGP SIGNATURE-

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



Re: Failed to read schema document 'classpath:/schema/shibboleth-2.0-services.xsd'

2016-05-05 Thread Violeta Georgieva
Hi,


2016-05-05 20:51 GMT+03:00 Hilbert, Colin :
>
> Hi,
>
> On 5/5/16, 1:48 PM, "Hilbert, Colin"  wrote:
>
> >Hello,
> >
> >Thank you for checking up on this.  In the meantime, is there a different
> >way you recommend I add these to the class path other than moving the
> >jars?
> >
> >Colin
> >
> >
> >On 4/27/16, 4:06 AM, "Violeta Georgieva"  wrote:
> >
> >>Hi,
> >>
> >>
> >>2016-04-26 22:49 GMT+03:00 Hilbert, Colin :
> >>>
> >>> Tomcat version 7.0.69
> >>> Also happens on 7.0.68 and 7.0.67
> >>>
> >>> I don¹t get this error on 7.0.65
> >>>
> >>> I have deployed an idp.war on tomcat
> >>> The idp.war has a service.xml file that looks like this at the
> >>>beginning:
> >>>
> >>>
> >>>  >>>   xmlns:attribute-afp="urn:mace:shibboleth:2.0:afp"
> >>>
> >>xmlns:attribute-authority="urn:mace:shibboleth:2.0:attribute:authority"
> >>>   xmlns:attribute-resolver="urn:mace:shibboleth:2.0:resolver"
> >>>   xmlns:profile="urn:mace:shibboleth:2.0:idp:profile-handler"
> >>>   xmlns:relyingParty="urn:mace:shibboleth:2.0:relying-party"
> >>>   xmlns:resource="urn:mace:shibboleth:2.0:resource"
> >>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >>>   xsi:schemaLocation="urn:mace:shibboleth:2.0:services
> >>classpath:/schema/shibboleth-2.0-services.xsd
> >>>   urn:mace:shibboleth:2.0:afp
> >>classpath:/schema/shibboleth-2.0-afp.xsd
> >>>
> >>>urn:mace:shibboleth:2.0:attribute:authority
> >>classpath:/schema/shibboleth-2.0-attribute-authority.xsd
> >>>   urn:mace:shibboleth:2.0:resolver
> >>classpath:/schema/shibboleth-2.0-attribute-resolver.xsd
> >>>
> >>>urn:mace:shibboleth:2.0:idp:profile-handler
> >>classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd
> >>>   urn:mace:shibboleth:2.0:relying-party
> >>classpath:/schema/shibboleth-2.0-relying-party.xsd
> >>>   urn:mace:shibboleth:2.0:resource
> >>classpath:/schema/shibboleth-2.0-resource.xsd²>
> >>>
> >>> The stack complains that it cannot find the first schemaLocation
listed
> >>but if I go to the deployed idp folder in tomcat idp/WEB-INF/lib/ there
> >>are
> >>jars there, one of which is shibboleth-common-1.2.1.jar
> >>>
> >>> Which has the path /schema/ containing all those listed
schemaLocations
> >>from the service.xml
> >>>
> >>> I can move all the jars from idp/WE-INF/lib/ to tomcat7.0.69/lib/ and
> >>>the
> >>exception goes away but I haven¹t had to do this prior to .67
> >>>
> >>> Can anyone shed some light on this?
> >>
> >>
> >>I think that this is related to the following feature [1].
> >>I'll check that.
> >>
> >>Regards,
> >>Violeta
> >>
> >>[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=56777
> >
> >
> >-
> >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
> Sorry for the top post.  I didn’t understand what I was doing.

Please follow the discussion [1] on the dev list.

Regards,
Violeta

[1] http://marc.info/?t=14617548634=1=2

> Colin.
>


BackupManager Heterogeneous Environment / Functionality?

2016-05-05 Thread Decker, Richard M
ASF Tomcat Members,

I'm trying to configure & demo an Apache Tomcat [v8] cluster env, that supports 
different apps functioning on different systems. Basically, I'm trying to setup 
an environment where an app can be on only 1 or 2 (deployed or running) out of 
the 3 Tomcat systems in the cluster. However, this does not seem to work for 
me, as I can't get away from the 404s when Apache HTTPD goes to a random (round 
robin) Tomcat system, that does not have the application (running or deployed) 
on it. This happens with both new & cached sessions. I can bring an entire 
Tomcat system down, and it works as designed, but not for (stopped or 
undeployed) single applications. I'm really not sure how Tomcat and Apache are 
supposed to communicate with each other in this regard; so they know what apps 
are deployed/running on each system. Is this even possible? According to the 
link below, it should work...

http://tomcat.apache.org/tomcat-8.0-doc/config/cluster-manager.html
The org.apache.catalina.ha.session.BackupManager also replicates deltas but 
only to one backup node. The location of the backup node is known to all nodes 
in the cluster. It also supports heterogeneous deployments, so the manager 
knows at what locations the web application is deployed.


Env - Top Down


[Load Balancer] - (Sticky Sessions)
|
[HTTPD1] - [HTTPD2] - (Load Balanced, Sticky Sessions)
|
[Tomcat1] - [Tomcat2] - [Tomcat3] - (BackupManager)

--
Stats
--

[HTTPD] X 2
Server version: Apache/2.4.18 (Unix)
Server built:   Dec 21 2015 14:42:09

[Tomcat] X 3
Server version: Apache Tomcat/8.0.33
Server built:   Mar 18 2016 20:31:49
Server number:  8.0.33.0
OS Name:Linux
OS Version: 3.10.0-327.4.4.el7.x86_64
Architecture:   amd64
JVM Version:1.8.0_77-b03
JVM Vendor: Oracle Corporation

[Linux] X 3 Tomcat Systems
IPv6/IPv4 Group Memberships
Interface   RefCnt Group
--- -- -
lo  1  all-systems.mcast.net
eth01  228.0.0.4
eth01  all-systems.mcast.net
eth11  all-systems.mcast.net


Config


[HTTPD]
worker.list=tomcattest, statustest

worker.tomcat1.type=ajp13
worker.tomcat1.host=tomcat1
worker.tomcat1.port=
#worker.tomcat1.lbfactor=5

worker.tomcat2.type=ajp13
worker.tomcat2.host=tomcat2
worker.tomcat2.port=
#worker.tomcat2.lbfactor=5

worker.tomcat3.type=ajp13
worker.tomcat3.host=tomcat3
worker.tomcat3.port=
#worker.tomcat3.lbfactor=5

worker.tomcattest.type=lb
worker.tomcattest.balance_workers=tomcat1,tomcat2,tomcat3
worker.tomcattest.sticky_session=True
# lb methods: [R]equest, [S]ession, [T]raffic, [B]usiness
worker.tomcattest.method=R
worker.statustest.type=status

[tomcat] X3 - server.xml

























-
Cluster Basics
-

All your session attributes must implement java.io.Serializable - Done

Uncomment the Cluster element in server.xml - Done

If you have defined custom cluster valves, make sure you have the 
ReplicationValve defined as well under the Cluster element in server.xml - N/A

If your Tomcat instances are running on the same machine, make sure the 
Receiver.port attribute is unique for each instance, in most cases Tomcat is 
smart enough to resolve this on it's own by autodetecting available ports in 
the range 4000-4100 - N/A

Make sure your web.xml has the  element - Done

If you are using mod_jk, make sure that jvmRoute attribute is set at your 
Engine  and that the jvmRoute 
attribute value matches your worker name in workers.properties - Done

Make sure that all nodes have the same time and sync with NTP service! - Done

Make sure that your loadbalancer is configured for sticky session mode - Done



Thanks for reading!




RE: Tomcat connector settings

2016-05-05 Thread Michael Fox
Chris,

Thanks for your explanations and help!

Please confirm that to configure the passthrough with an external HTTPS and an 
internal HTTP, I would set Apache to listen to SSL on port 8443 and Tomcat on 
port 8080, with a line inside the Virtual Host directive of

ProxyPass /myapp http://DNS_hostname:8080/myapp ProxyPassReverse /myapp 
http://DNS_hostname:8080/myapp


In the Tomcat server.xml file, inside the Host directive, I will place


In the file /etc/httpd/conf/workers.properties, worker.worker1.host should be 
set to DNS_hostname and worker.worker1.port is set to 8080.


With this setup, the URL for accessing the Tomcat application via the Apache 
server would be
https://DNS_hostname/myapp

Best,
Mike

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, May 4, 2016 12:50 PM
To: Tomcat Users List 
Subject: Re: Tomcat connector settings

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael,

On 5/2/16 10:20 AM, Michael Fox wrote:
> I ultimately want to have a Tomcat application protected  by our 
> university's system for authentication, which is SiteMinder.  They 
> have told me that they can't protect Tomcat directly, but if user 
> communications can be passed through a web server then they can 
> protect the server with SiteMinder.

No problem.

> I have a working Tomcat application if I uncomment the non-SSL
> HTTP/1.1 protocol in the Tomcat, but I believe I need all 
> communication to pass through the Apache web server.  Let me know if 
> you need more information and, if so, what that would be.

You can use HTTP, HTTPS, or AJP as the communication mechanism between the web 
server and Tomcat.

AJP works great with Apache httpd, but may be more complicated to get set up 
with other web servers. HTTP is, by definition, always supported. You want them 
to set up the web server as a "reverse-proxy", and just give them the URL of 
your base application.
The configuration in httpd for using HTTP as the protocol is fairly
simple:

ProxyPass /myapp http://internal.ip:8080/myapp ProxyPassReverse /myapp 
http://internal.ip:8080/myapp

You'll want to enable the standard HTTP connector (it was enabled by
default) and if you aren't using AJP (like you are NOT in this example), then 
you'll want to enable the RemoteIPValve:
https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Val
ve

That "valve" takes information from the HTTP headers coming from the web server 
and makes sure that things like the base URL match what the client is seeing 
from the outside world (e.g. they won't see URLs for 
http://internal.ip:8080/etc.).

On the web server, you can use whatever protocol you want for your clients. 
HTTPS is a good choice. Using HTTPS on the web server has no impact on whether 
or not you want to use HTTP or HTTPS internally on your private network. If you 
want to use HTTPS internally (also not a bad idea, especially if you don't 100% 
trust everyone who has access to your network), change the httpd configuration 
to this:

ProxyPass /myapp http://internal.ip:8443/myapp ProxyPassReverse /myapp 
http://internal.ip:8443/myapp

You will, of course, have to configure a secure  on port
8443 for that purpose, including a TLS certificate, etc. If you always expect 
to use a secure connection, then disable the non-secure
: anyone coming to your web site using cleartext HTTP can be 
redirected by the web server to HTTPS so Tomcat itself only has to be providing 
an HTTPS connection.

Hope that helps,
- -chris

> -Original Message- From: Christopher Schultz 
> [mailto:ch...@christopherschultz.net] Sent: Friday, April 29, 2016
> 9:14 PM To: Tomcat Users List  Subject:
> Re: Tomcat connector settings
> 
> Michael,
> 
> On 4/29/16 4:25 PM, Michael Fox wrote:
>> I have an Apache web server(2.4.6) which is accessible at http or  
>> https at DNS_hostname, and a Tomcat server (9.0.0.M1)with an 
>> application available at DNS_hostname:8080/app_name.
> 
>> I then disabled the non-SSL HTTP/1.1 connector on port 8080 and 
>> enabled HTTP/2 in the Tomcat server.xml, using the certificate key 
>> file and certificate where generated using the openssl
>> (1.0.2g) commands and used on the Apache web server.
> 
>> The Apache ssl.conf file is set to listen on port 8443 for https, and 
>> the only virtual host is set for IP_address:8443 and servername set 
>> to DNS_hostname
> 
>> In the file /etc/httpd/conf/workers.properties,
>> worker.worker1.host is set to DNS_hostname and worker.worker1.port is 
>> set to 8443.
> 
>> Netstat -tamp shows httpd listening on port 8443 and java listening 
>> on port 8009.
> 
>> Are these settings proper and correct?
> 
> It doesn't look like it.
> 
>> What should the URL look like in order to access the Tomcat 
>> application via Apache?
> 
> That depends upon what you are actually trying to do.
> 
>> Any help and/or guidance would most appreciated.
> 
> You have 

Re: Auto-bounce a host or webapp?

2016-05-05 Thread David kerber

On 5/5/2016 2:56 PM, Jerry Malcolm wrote:

I am not using WAR files for my apps.  I simply copy updated files to
the image in \webapps as changes/updates are required.  I have a server
running on my local dev machine.  When I refresh any webapp file (jars,
jsps, etc) the server detects the changes, refreshes, and everything is
good with the new versions running without further intervention.
However, when I do the exact same thing to my remote server (which is an
identical mirror of the local TC) almost every time there is a refresh,
the server webapp stops, and I have to go the manager and restart all of
the web apps.

I'm suspecting that it might have something to do with the upload
speed.  Where I can pretty much instantly replace a jar file locally, it
may take several seconds to replace the same jar file on the remote
machine due to connection speed to the server.  And I assume TC is ok
with 'instant' jar replacements, but doesn't like it when it takes too
long for a jar to finish updating.

Whatever the cause, I've resigned myself to the fact that I'm going to
have to restart the webapps after every upload.  But I'd love to figure
out a way to do that automatically (preferably as part of my ant 'build'
script).  A full refresh can take 20-30 minutes (I have lots of large
web apps...).  I have to wait around for the upload to complete, else
the server will be down until I can come back and around and refresh.

So, is there a way to bounce an entire host programatically at the end
of the upload?  Or is there a way to remotely via a script to bounce all
of the webapps?


I believe the Manager app can force a reload of your webapps, though I 
never use it.


But what about this, to make the process more closely mirror what you 
see locally:  Upload the updated files to a temporary holding spot on 
the remote server, and then after they're all there, move them en-mass 
to the webapps directory.  That final copy will be very fast, and would 
likely allow the server to pick up the changes just like it does locally.



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



Auto-bounce a host or webapp?

2016-05-05 Thread Jerry Malcolm
I am not using WAR files for my apps.  I simply copy updated files to 
the image in \webapps as changes/updates are required.  I have a server 
running on my local dev machine.  When I refresh any webapp file (jars, 
jsps, etc) the server detects the changes, refreshes, and everything is 
good with the new versions running without further intervention.  
However, when I do the exact same thing to my remote server (which is an 
identical mirror of the local TC) almost every time there is a refresh, 
the server webapp stops, and I have to go the manager and restart all of 
the web apps.


I'm suspecting that it might have something to do with the upload 
speed.  Where I can pretty much instantly replace a jar file locally, it 
may take several seconds to replace the same jar file on the remote 
machine due to connection speed to the server.  And I assume TC is ok 
with 'instant' jar replacements, but doesn't like it when it takes too 
long for a jar to finish updating.


Whatever the cause, I've resigned myself to the fact that I'm going to 
have to restart the webapps after every upload.  But I'd love to figure 
out a way to do that automatically (preferably as part of my ant 'build' 
script).  A full refresh can take 20-30 minutes (I have lots of large 
web apps...).  I have to wait around for the upload to complete, else 
the server will be down until I can come back and around and refresh.


So, is there a way to bounce an entire host programatically at the end 
of the upload?  Or is there a way to remotely via a script to bounce all 
of the webapps?


Thx.

Jerry


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



Re: Failed to read schema document 'classpath:/schema/shibboleth-2.0-services.xsd'

2016-05-05 Thread Hilbert, Colin
Hi,

On 5/5/16, 1:48 PM, "Hilbert, Colin"  wrote:

>Hello,
>
>Thank you for checking up on this.  In the meantime, is there a different
>way you recommend I add these to the class path other than moving the
>jars?
>
>Colin
>
>
>On 4/27/16, 4:06 AM, "Violeta Georgieva"  wrote:
>
>>Hi,
>>
>>
>>2016-04-26 22:49 GMT+03:00 Hilbert, Colin :
>>>
>>> Tomcat version 7.0.69
>>> Also happens on 7.0.68 and 7.0.67
>>>
>>> I don¹t get this error on 7.0.65
>>>
>>> I have deployed an idp.war on tomcat
>>> The idp.war has a service.xml file that looks like this at the
>>>beginning:
>>>
>>>
>>> >>   xmlns:attribute-afp="urn:mace:shibboleth:2.0:afp"
>>>
>>xmlns:attribute-authority="urn:mace:shibboleth:2.0:attribute:authority"
>>>   xmlns:attribute-resolver="urn:mace:shibboleth:2.0:resolver"
>>>   xmlns:profile="urn:mace:shibboleth:2.0:idp:profile-handler"
>>>   xmlns:relyingParty="urn:mace:shibboleth:2.0:relying-party"
>>>   xmlns:resource="urn:mace:shibboleth:2.0:resource"
>>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>>   xsi:schemaLocation="urn:mace:shibboleth:2.0:services
>>classpath:/schema/shibboleth-2.0-services.xsd
>>>   urn:mace:shibboleth:2.0:afp
>>classpath:/schema/shibboleth-2.0-afp.xsd
>>>
>>>urn:mace:shibboleth:2.0:attribute:authority
>>classpath:/schema/shibboleth-2.0-attribute-authority.xsd
>>>   urn:mace:shibboleth:2.0:resolver
>>classpath:/schema/shibboleth-2.0-attribute-resolver.xsd
>>>
>>>urn:mace:shibboleth:2.0:idp:profile-handler
>>classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd
>>>   urn:mace:shibboleth:2.0:relying-party
>>classpath:/schema/shibboleth-2.0-relying-party.xsd
>>>   urn:mace:shibboleth:2.0:resource
>>classpath:/schema/shibboleth-2.0-resource.xsd²>
>>>
>>> The stack complains that it cannot find the first schemaLocation listed
>>but if I go to the deployed idp folder in tomcat idp/WEB-INF/lib/ there
>>are
>>jars there, one of which is shibboleth-common-1.2.1.jar
>>>
>>> Which has the path /schema/ containing all those listed schemaLocations
>>from the service.xml
>>>
>>> I can move all the jars from idp/WE-INF/lib/ to tomcat7.0.69/lib/ and
>>>the
>>exception goes away but I haven¹t had to do this prior to .67
>>>
>>> Can anyone shed some light on this?
>>
>>
>>I think that this is related to the following feature [1].
>>I'll check that.
>>
>>Regards,
>>Violeta
>>
>>[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=56777
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

Sorry for the top post.  I didn’t understand what I was doing.

Colin.



Re: Failed to read schema document 'classpath:/schema/shibboleth-2.0-services.xsd'

2016-05-05 Thread Hilbert, Colin
Hello,

Thank you for checking up on this.  In the meantime, is there a different
way you recommend I add these to the class path other than moving the jars?

Colin


On 4/27/16, 4:06 AM, "Violeta Georgieva"  wrote:

>Hi,
>
>
>2016-04-26 22:49 GMT+03:00 Hilbert, Colin :
>>
>> Tomcat version 7.0.69
>> Also happens on 7.0.68 and 7.0.67
>>
>> I don¹t get this error on 7.0.65
>>
>> I have deployed an idp.war on tomcat
>> The idp.war has a service.xml file that looks like this at the
>>beginning:
>>
>>
>> >   xmlns:attribute-afp="urn:mace:shibboleth:2.0:afp"
>>
>xmlns:attribute-authority="urn:mace:shibboleth:2.0:attribute:authority"
>>   xmlns:attribute-resolver="urn:mace:shibboleth:2.0:resolver"
>>   xmlns:profile="urn:mace:shibboleth:2.0:idp:profile-handler"
>>   xmlns:relyingParty="urn:mace:shibboleth:2.0:relying-party"
>>   xmlns:resource="urn:mace:shibboleth:2.0:resource"
>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>   xsi:schemaLocation="urn:mace:shibboleth:2.0:services
>classpath:/schema/shibboleth-2.0-services.xsd
>>   urn:mace:shibboleth:2.0:afp
>classpath:/schema/shibboleth-2.0-afp.xsd
>> 
>>urn:mace:shibboleth:2.0:attribute:authority
>classpath:/schema/shibboleth-2.0-attribute-authority.xsd
>>   urn:mace:shibboleth:2.0:resolver
>classpath:/schema/shibboleth-2.0-attribute-resolver.xsd
>> 
>>urn:mace:shibboleth:2.0:idp:profile-handler
>classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd
>>   urn:mace:shibboleth:2.0:relying-party
>classpath:/schema/shibboleth-2.0-relying-party.xsd
>>   urn:mace:shibboleth:2.0:resource
>classpath:/schema/shibboleth-2.0-resource.xsd²>
>>
>> The stack complains that it cannot find the first schemaLocation listed
>but if I go to the deployed idp folder in tomcat idp/WEB-INF/lib/ there
>are
>jars there, one of which is shibboleth-common-1.2.1.jar
>>
>> Which has the path /schema/ containing all those listed schemaLocations
>from the service.xml
>>
>> I can move all the jars from idp/WE-INF/lib/ to tomcat7.0.69/lib/ and
>>the
>exception goes away but I haven¹t had to do this prior to .67
>>
>> Can anyone shed some light on this?
>
>
>I think that this is related to the following feature [1].
>I'll check that.
>
>Regards,
>Violeta
>
>[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=56777


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



antiClickJackingUri syntax in HTTP header security filter definition

2016-05-05 Thread Ruan van Tonder
Good day

We are running Apache Tomcat 7.0.64 on Windows Server 2012 R2. Currently we 
have an issue where an application page which we are using is being framed by 
another and due to the default settings in the HTTP header security filter is 
not being allowed to be displayed in Internet Explorer/

I have attempted to add the referring URI into the HTTP header security config 
via the antiClickJackingUri parameter in the web.xml file located in 
Tomcat\conf\ e.g:


httpHeaderSecurity

org.apache.catalina.filters.HttpHeaderSecurityFilter
true

antiClickJackingEnabled
true


antiClickJackingOption
ALLOW-FROM


antiClickJackingUri
http://savanttools.com/test-frame/*


blockContentTypeSniffingEnabled
false



I wanted to confirm the syntax to be used for the URI as I am not able to find 
any specification in the documentation. Using the above syntax does not work.

Interestingly when using ALLOW-FROM 
http://savanttools.com/test-frame/  in the application specific 
web.xml it does seem to work (at least when disabling the HTTP header security 
at the top level web.xml.

Does anybody please have any advice or experience in this regard?

Thanks in advance
Ruan van Tonder



Re: Getting confusing websocket error message on Tomcat 7

2016-05-05 Thread Mark Thomas
On 04/05/2016 20:24, Jason Ricles wrote:
> I am trying to send a file over a websocket in binary and keep getting
> this error
> 
> "code [1009], reason [No async message support and buffer too small.
> Buffer size: [800,000], Message size: [131,170]]"
> 
> I am confused since it is saying the buffer size is too small but the
> size is 800,000 and the message size is 131,170. What could be causing
> this issue?

Compression? 131170 is the payload size (i.e. the compressed message).
The buffer needs to be big enough for the uncompressed message. That
error message was written before compression support was added. If this
is what is going on, the message looks like it could stand some improvement.

Mark


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