Re: request.getUserPrincipal() is null but StandardSession.principal is set
2015-01-26 15:10 GMT+03:00 Thomas Strauß t.stra...@srs-management.de: -Ursprüngliche Nachricht- Von: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Gesendet: Montag, 26. Januar 2015 13:01 An: Tomcat Users List Betreff: Re: request.getUserPrincipal() is null but StandardSession.principal is set The stacktrace above does not have FormAuthenticatorValve, so there is no wonder that request has not been authenticated yet. There is the following change for 7.0.22 in the changelog file: [quote] Correct a regression with the fix for 51653 that broke custom error pages for 4xx responses from the Authenticators. Error handling and request listeners are now handled in the StandardHostValve to ensure they wrap all Context level activity. (markt) [/quote] Yes, maybe obvious for you, and is clear now for me, but the side effect, that authentication is no longer available to a request listener would have saved me some hours. Anyway, thanks for helping out. I will rewrite the listener to a filter then, as I see no other possibility here. Generally Filter is a better defined interface. People have different expectations on RequestListener behaviour. (A recent discussion was in https://issues.apache.org/bugzilla/show_bug.cgi?id=57314 ) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple instances?
Hi guys, thank for your informations regarding the Wiki, I've finally
managed to create my account ^^ (later is better than never as we said over
there :D) and as expected to add a new entry on the FAQ/HowTo I need to be
whitelisted or granted to edit mode, so if a moderator could add me it
would be nice.
PS: I've found something bizarre on the systemd init process regarding
Tomcat, if I set the CONNECTOR_PORT variable to something (let said 8081)
on the /etc/sysconfig/tomcat-${SERVICE_NAME} it is not use but rather
overrided by the tomcat server.xml file.
Until now, nothing strange, the weird part is that if I disable the
HTTP-BIO or AJP-BIO connectors values on this file tomcat load the unit
without binding any network port at all.
Shouldn't it be suppose tu use the one specified by the CONNECTOR_PORT
variable or did I missed something?
2014-12-23 20:47 GMT+01:00 Christopher Schultz ch...@christopherschultz.net
:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Billy,
On 12/19/14 1:37 PM, Billy Bones wrote:
For sure, do I need an account or something special?
You can sign-up yourself.
Could you send me the wiki link?
http://wiki.apache.org/tomcat/
Choose login at the top of the page and then choose the you can
create one now at the bottom of the page login page.
Once you have an account, I think you'll need to be white-listed to
actually make modifications. Just email a moderator or the whole list
to request write access to the Wiki.
- -chris
2014-12-19 17:05 GMT+01:00 Christopher Schultz
ch...@christopherschultz.net
:
Billy,
On 12/19/14 4:46 AM, Billy Bones wrote:
hum OK many thanks for your hints, I got it, I understand
what is going on now. Ok, I now have a clean and multiple
instances running !!
Thanks to everyone!
@Mark Eggers: CentOS systemd units are not quite so far from
the Fedora ones. Personally I do love the way fedora and
CentOS are working but I have to confess that sometimes, and
especially with tomcat everything is a pain in the ass as
they scatter the components everywhere in the system without
any (apparent) logics.
WTH with all this /usr/share/blabla ??
@Christopher: Many thanks for your advices, obviously it make
more sens to keep the catalina_base and derivate the
catalina_home. I love this method!!
Once again, many thanks to everyone, I now have a clean and
working server!
Great. Care to post your systemd script template to the wiki? It
will likely help others trying to do the same thing.
-chris
2014-12-18 19:46 GMT+01:00 Mark Eggers
its_toas...@yahoo.com.invalid:
On 12/18/2014 10:07 AM, Christopher Schultz wrote:
Billy,
On 12/18/14 9:25 AM, Billy Bones wrote:
Ok s, here is a small update.
I've finally found what does this SERVICE_NAME mean,
indeed you have to copy the original unit, then add
the Systemd's directive named Environment like this:
Environment=SERVICE_NAME=YOUROWNSERVICENAMEHERE
then you will copy the default tomcat config file
found on the /etc/sysconfig directory.
And as you supposed it Cristophe and Daniel, you then
have to copy the whole CATALINA_{HOME/BASE} or update
the previous config file to point out to another
tomcat installation.
You should not have to copy the whole CATALINA_HOME.
Instead, create a CATALINA_BASE (which is basically
just a few directories and a few configuration files)
for each service and then set the CATALINA_BASE
environment variable to point to each one for each
service, set CATALINA_HOME to point to where the full
installation of Tomcat is (with no web applications
installed in it), and each service should operate
independently.
So you should be able to have something like this:
SERVICE_NAME=tomcat-one
CATALINA_HOME=/opt/apache-tomcat-7.0.57
CATALINA_BASE=/opt/tomcat/tomcat-one
SERVICE_NAME=tomcat-two
CATALINA_HOME=/opt/apache-tomcat-7.0.57
CATALINA_BASE=/opt/tomcat/tomcat-two
Then you configure /opt/tomcat/tomcat-(one|two) to have
the configuration and applications you want.
You should be able to start tomcat-one and tomcat-two
independently of each other. I don't know exactly what
systemd does with all of this, but once you end up
calling catalina.sh with the right environment
variables set, Tomcat will do the right thing.
-chris
Fedora 21 has a relatively nice systemd script for Tomcat.
It's designed for running multiple Tomcat instances.
If you have a copy of Fedora 21 and yumdownloader (by
installing yum-utils), you can take a look at the system
with:
mkdir Temp cd Temp yumdownloader tomcat.noarch rpm2cpio
tomcat-7.0.54-3.fc21.noarch.rpm | cpio -idmv
All of the files are then accessible in the Temp directory.
I've never liked how Fedora / RedHat / CentOS scatter the
components all over the landscape. I'm thinking of adapting
the Fedora systemd scripts to work with Tomcats installed
under a
RE: Tomcat 7.0.57 and application META-INF/context.xml
From: Jose Monreal [mailto:jmonr...@gmail.com] Subject: Tomcat 7.0.57 and application META-INF/context.xml When I deploy my application myApp-1.2.war to Tomcat, instead of taking the context /my/app/context/1.2 that's specified in META-INF/context.xml under the path attribute of Context key, it takes the name of my war, so it gets deployed under the context myApp-1.2. Read the doc: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html In particular, this part under Naming: the context path may not be defined in a META-INF/context.xml embedded in the application, and this under the description of path: This attribute must only be used when statically defining a Context in server.xml. In all other circumstances, the path will be inferred from the filenames used for either the .xml context file or the docBase. What configuration am I missing? That described in the docs. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.57 and application META-INF/context.xml
That's what we've been doing, I thought that there would be a plug-in or option to solve this issue. Best regards, José Saludos cordiales, José Ignacio Monreal Bailey | Ingeniero Civil en Computación *Cuidemos del medio ambiente. Por favor no imprimas este e-mail si no es necesario.* On Mon, Jan 26, 2015 at 12:01 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Jose Monreal [mailto:jmonr...@gmail.com] Subject: Re: Tomcat 7.0.57 and application META-INF/context.xml So from what you and documentation are saying, there's no way for tomcat to use the path described in the META-INF/context.xml of my application. Correct. The simplest thing to do is just change the name of your .war file (or directory) to my#app#context#1.2, since the # symbols will be treated as slashes when deploying the webapp. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.57 and application META-INF/context.xml
Thanks Chuck. So from what you and documentation are saying, there's no way for tomcat to use the path described in the META-INF/context.xml of my application. Thanks! Saludos cordiales, José Ignacio Monreal Bailey | Ingeniero Civil en Computación *Cuidemos del medio ambiente. Por favor no imprimas este e-mail si no es necesario.* On Mon, Jan 26, 2015 at 11:19 AM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Jose Monreal [mailto:jmonr...@gmail.com] Subject: Tomcat 7.0.57 and application META-INF/context.xml When I deploy my application myApp-1.2.war to Tomcat, instead of taking the context /my/app/context/1.2 that's specified in META-INF/context.xml under the path attribute of Context key, it takes the name of my war, so it gets deployed under the context myApp-1.2. Read the doc: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html In particular, this part under Naming: the context path may not be defined in a META-INF/context.xml embedded in the application, and this under the description of path: This attribute must only be used when statically defining a Context in server.xml. In all other circumstances, the path will be inferred from the filenames used for either the .xml context file or the docBase. What configuration am I missing? That described in the docs. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple instances?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Billy,
On 1/26/15 8:57 AM, Billy Bones wrote:
PS: I've found something bizarre on the systemd init process
regarding Tomcat, if I set the CONNECTOR_PORT variable to something
(let said 8081) on the /etc/sysconfig/tomcat-${SERVICE_NAME} it is
not use but rather overrided by the tomcat server.xml file.
That's not surprising, since Tomcat uses the contents of server.xml to
configure the connectors, and does not look at any environment
variables for anything.
Where is CONNECTOR_PORT documented? I suspect it's something supported
by the systemd scripts simply to differentiate between various Tomcat
servers but doesn't have any bearing on the actual runtime
configuration. Remember that Tomcat can bind to an arbitrary number of
ports, so having a single CONNECTOR_PORT doesn't really make much sense.
Until now, nothing strange, the weird part is that if I disable
the HTTP-BIO or AJP-BIO connectors values on this file tomcat load
the unit without binding any network port at all.
That's expected behavior: it's possible that Tomcat is coming up with
no Connectors configured, and that some other software component will
then configure the connectors after the server is running. Think of an
embedded use-case and it becomes easier to understand how this would
not be an error.
Shouldn't it be [using] the one specified by the CONNECTOR_PORT
variable or did I missed something?
No, Tomcat doesn't use environment variables for anything. The launch
scripts use a handful of environment variables to set up various
system properties when launching the JVM, and Tomcat uses those if
necessary.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUxlopAAoJEBzwKT+lPKRYwcUP/0UYgfDJ8XaETTjPkvvN8j08
mqLeXkP+Mr84MCGtBMTytF9XYi1XXE5FdHdXhtWOScoe+IdYtuM42E4/YubJm7g3
V99mVbaiw9O5tFm9lDFYUaNhG3r0jLYmbMNGWxNAoWiCL18RKcVQ6tgu74DpBzgH
XmWaRSB20xAp3iCYP25dRQpwVTmwrCTHeYLOmbeHKqQGRTeA37dQSuisz1SYptgp
iQs/CXlkumHDRRGmXiihcbUQiMmULmmAZUGyjl3jex9eHfQcDXIZ34edBgh5fMwW
w6FMUfUTmqVAeZbceCZdoBDtifNkFUbCr0f3eMNGV4oSHrA7fJv/xxi9kUoLpiuG
5/9j1wK3eOsBKPCVEJkuQ79zQXgI9bOW4/c5mAp3Coq6z8Me8AbYYAuiLhPjaCec
oBtHc13Lr8HqZW/kdJCNgwN1Y4YDxwYwaNODh966M6ZF3Gsk8aZ6a8P2YI7u5jaW
ixMxft7lSpNrQWdwHy4DDlPtuwGk3n8ERaxk8d37YOGRxSjk9jS+9Bgdz/Dxznkd
NQ0IRqwZ9LIuFt/VjYdPPRJDmOm9oIclEDq97aKp2cP3kz7s+JkUBZyLKefynW2Y
A24ha+4d5Mi8RCj6TTkdFm7mB9WpUQhuSFEw79NpsToz5jv0D43ZsiFdehdukOwc
fY8+Fsy+LWIwpbIdpM/N
=9SDP
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7.0.57 and application META-INF/context.xml
From: Jose Monreal [mailto:jmonr...@gmail.com] Subject: Re: Tomcat 7.0.57 and application META-INF/context.xml So from what you and documentation are saying, there's no way for tomcat to use the path described in the META-INF/context.xml of my application. Correct. The simplest thing to do is just change the name of your .war file (or directory) to my#app#context#1.2, since the # symbols will be treated as slashes when deploying the webapp. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_jk Configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 1/25/15 7:38 PM, Chris Arnold wrote: If you won't re-name the web application, I think redirects will be your best bet. If a client requests http(s)://share2.domain.tld/, you should redirect them to https://share2.domain.tld/share/ and then JkMount /share/* worker1. You can redirect using RedirectPermanant or a few other things like having an index.html with an HTTP-EQUIV header in it. At this point, you seem to be able to successfully connect httpd - Tomcat. If you don't want to follow our advice for a more robust configuration, you don't have You know what Chris, I am trying to follow your advice! Forgive me if I am not a tomcat expert like you and others on this list! We aren't trying to look down upon you; it's not about being an expert or not. The best possible setup here is to set up httpd with more than one VirtualHost (and SNI, since you are using HTTPS) with the correct hostnames, etc., and only use JkMount from the share2 VirtualHost. Then, re-name your application from share.war to ROOT.war and re-deploy it into Tomcat. Use JkMount /share/* worker1 and be done with it. If the application can't handle that (try it!), you'll have to make other arrangements. I keep inviting you or anybody else that would, to either contact me off list for all the full links/info or maybe a remote session. The offer still stands for either a off list contact or teamviewer session (I am willing to pay). It's probably not necessary to pay. I know I have a working config on a server that I am trying to upgrade using, what looks like , Apache mod_rewrite and mod_jk but this is expensive and I heard mod_jk is much better. You should not need mod_rewrite to do this. Check to see if the application can be re-named. If it's been written properly, then it can be trivially re-named. If that doesn't work, we'll take a look at other options. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUxlkRAAoJEBzwKT+lPKRYs2UQAMtG4GDCA+QwihpsaRVFvaI/ /AmZzXNUbeadMyleu8ZsavsIpISZCJy4Dn4kssjmt77kcBUx7DnTWUe570DUJ4Tq Ftq59+7X2XfGBjPAOGZgp6Gvz7gV36vp9jhV2X0DyadLW4wFOVfbjQUHiNCyiVOX CL6+z6ykYM8MZd8+9GshfHIH6LH5/F6BFtOsluWOxxgUDjSn9xkEuBj3CBj264Ln IZa2PAqWz7F5VvAFNzrxWVTlFmWzTqhMr4461CSlZ34MVaavdmqerPbizVVV/rpI oiRpFlOnOC+b+8mPteCZzs7yciCD8C9ljicQbYa9+lXUsu8mD88XQkX2JkRilS5U Ru438UkZhMCcC7B4CZX7CD1UblpFhcuf+NUx/LQ69S2n+mTBROYZTlZVIJlwHHV6 XuL4r3kSXscY5uyz8eimNXi55owCHIQJy8KLFTqiyIzFzFQhblLDRVgJfL275t0b 2pidZHYOWkXrzK/SaSgbOVIPmsC7Rc7MK+0B5ikMSLRGxivpXEnWEnULYbUtWo2N zjlIpk7P5w5oL3XXW3Dpf7qTcUrMINJnLdCo6PzQ/z+AE6YEFbSAKmbfkOUnt3yb YC6ebo1Euhs9MePHUG/yE9L81J70KLsodPWIASTKw3mA6yOKKrEC4qHd19M8S9f+ 5DXilt7RPpgVHd6FlklW =4JDw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple instances?
Hi Markt, my wiki alias username is ArKam and my Real username is
GaelTherond, thank you very much.
@Chris: Ok, thanks a lot for your explanations, it's crystal clear to me
now, as you said, it should be something specific to systemd as it reside
under the /etc/sysconfig/tomcat file which is use to set some variables to
start the JVM.
I'm working on a RHEL 7 right now instead of the CentOS from my first mail
as I'm cooking a new PROD server, the two distro use exactly the same
configs.
2015-01-26 16:15 GMT+01:00 Christopher Schultz ch...@christopherschultz.net
:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Billy,
On 1/26/15 8:57 AM, Billy Bones wrote:
PS: I've found something bizarre on the systemd init process
regarding Tomcat, if I set the CONNECTOR_PORT variable to something
(let said 8081) on the /etc/sysconfig/tomcat-${SERVICE_NAME} it is
not use but rather overrided by the tomcat server.xml file.
That's not surprising, since Tomcat uses the contents of server.xml to
configure the connectors, and does not look at any environment
variables for anything.
Where is CONNECTOR_PORT documented? I suspect it's something supported
by the systemd scripts simply to differentiate between various Tomcat
servers but doesn't have any bearing on the actual runtime
configuration. Remember that Tomcat can bind to an arbitrary number of
ports, so having a single CONNECTOR_PORT doesn't really make much sense.
Until now, nothing strange, the weird part is that if I disable
the HTTP-BIO or AJP-BIO connectors values on this file tomcat load
the unit without binding any network port at all.
That's expected behavior: it's possible that Tomcat is coming up with
no Connectors configured, and that some other software component will
then configure the connectors after the server is running. Think of an
embedded use-case and it becomes easier to understand how this would
not be an error.
Shouldn't it be [using] the one specified by the CONNECTOR_PORT
variable or did I missed something?
No, Tomcat doesn't use environment variables for anything. The launch
scripts use a handful of environment variables to set up various
system properties when launching the JVM, and Tomcat uses those if
necessary.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUxlopAAoJEBzwKT+lPKRYwcUP/0UYgfDJ8XaETTjPkvvN8j08
mqLeXkP+Mr84MCGtBMTytF9XYi1XXE5FdHdXhtWOScoe+IdYtuM42E4/YubJm7g3
V99mVbaiw9O5tFm9lDFYUaNhG3r0jLYmbMNGWxNAoWiCL18RKcVQ6tgu74DpBzgH
XmWaRSB20xAp3iCYP25dRQpwVTmwrCTHeYLOmbeHKqQGRTeA37dQSuisz1SYptgp
iQs/CXlkumHDRRGmXiihcbUQiMmULmmAZUGyjl3jex9eHfQcDXIZ34edBgh5fMwW
w6FMUfUTmqVAeZbceCZdoBDtifNkFUbCr0f3eMNGV4oSHrA7fJv/xxi9kUoLpiuG
5/9j1wK3eOsBKPCVEJkuQ79zQXgI9bOW4/c5mAp3Coq6z8Me8AbYYAuiLhPjaCec
oBtHc13Lr8HqZW/kdJCNgwN1Y4YDxwYwaNODh966M6ZF3Gsk8aZ6a8P2YI7u5jaW
ixMxft7lSpNrQWdwHy4DDlPtuwGk3n8ERaxk8d37YOGRxSjk9jS+9Bgdz/Dxznkd
NQ0IRqwZ9LIuFt/VjYdPPRJDmOm9oIclEDq97aKp2cP3kz7s+JkUBZyLKefynW2Y
A24ha+4d5Mi8RCj6TTkdFm7mB9WpUQhuSFEw79NpsToz5jv0D43ZsiFdehdukOwc
fY8+Fsy+LWIwpbIdpM/N
=9SDP
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple instances?
On 26/01/2015 13:57, Billy Bones wrote:
Hi guys, thank for your informations regarding the Wiki, I've finally
managed to create my account ^^ (later is better than never as we said over
there :D) and as expected to add a new entry on the FAQ/HowTo I need to be
whitelisted or granted to edit mode, so if a moderator could add me it
would be nice.
And your wiki user name is ... ?
Mark
PS: I've found something bizarre on the systemd init process regarding
Tomcat, if I set the CONNECTOR_PORT variable to something (let said 8081)
on the /etc/sysconfig/tomcat-${SERVICE_NAME} it is not use but rather
overrided by the tomcat server.xml file.
Until now, nothing strange, the weird part is that if I disable the
HTTP-BIO or AJP-BIO connectors values on this file tomcat load the unit
without binding any network port at all.
Shouldn't it be suppose tu use the one specified by the CONNECTOR_PORT
variable or did I missed something?
2014-12-23 20:47 GMT+01:00 Christopher Schultz ch...@christopherschultz.net
:
Billy,
On 12/19/14 1:37 PM, Billy Bones wrote:
For sure, do I need an account or something special?
You can sign-up yourself.
Could you send me the wiki link?
http://wiki.apache.org/tomcat/
Choose login at the top of the page and then choose the you can
create one now at the bottom of the page login page.
Once you have an account, I think you'll need to be white-listed to
actually make modifications. Just email a moderator or the whole list
to request write access to the Wiki.
-chris
2014-12-19 17:05 GMT+01:00 Christopher Schultz
ch...@christopherschultz.net
:
Billy,
On 12/19/14 4:46 AM, Billy Bones wrote:
hum OK many thanks for your hints, I got it, I understand
what is going on now. Ok, I now have a clean and multiple
instances running !!
Thanks to everyone!
@Mark Eggers: CentOS systemd units are not quite so far from
the Fedora ones. Personally I do love the way fedora and
CentOS are working but I have to confess that sometimes, and
especially with tomcat everything is a pain in the ass as
they scatter the components everywhere in the system without
any (apparent) logics.
WTH with all this /usr/share/blabla ??
@Christopher: Many thanks for your advices, obviously it make
more sens to keep the catalina_base and derivate the
catalina_home. I love this method!!
Once again, many thanks to everyone, I now have a clean and
working server!
Great. Care to post your systemd script template to the wiki? It
will likely help others trying to do the same thing.
-chris
2014-12-18 19:46 GMT+01:00 Mark Eggers
its_toas...@yahoo.com.invalid:
On 12/18/2014 10:07 AM, Christopher Schultz wrote:
Billy,
On 12/18/14 9:25 AM, Billy Bones wrote:
Ok s, here is a small update.
I've finally found what does this SERVICE_NAME mean,
indeed you have to copy the original unit, then add
the Systemd's directive named Environment like this:
Environment=SERVICE_NAME=YOUROWNSERVICENAMEHERE
then you will copy the default tomcat config file
found on the /etc/sysconfig directory.
And as you supposed it Cristophe and Daniel, you then
have to copy the whole CATALINA_{HOME/BASE} or update
the previous config file to point out to another
tomcat installation.
You should not have to copy the whole CATALINA_HOME.
Instead, create a CATALINA_BASE (which is basically
just a few directories and a few configuration files)
for each service and then set the CATALINA_BASE
environment variable to point to each one for each
service, set CATALINA_HOME to point to where the full
installation of Tomcat is (with no web applications
installed in it), and each service should operate
independently.
So you should be able to have something like this:
SERVICE_NAME=tomcat-one
CATALINA_HOME=/opt/apache-tomcat-7.0.57
CATALINA_BASE=/opt/tomcat/tomcat-one
SERVICE_NAME=tomcat-two
CATALINA_HOME=/opt/apache-tomcat-7.0.57
CATALINA_BASE=/opt/tomcat/tomcat-two
Then you configure /opt/tomcat/tomcat-(one|two) to have
the configuration and applications you want.
You should be able to start tomcat-one and tomcat-two
independently of each other. I don't know exactly what
systemd does with all of this, but once you end up
calling catalina.sh with the right environment
variables set, Tomcat will do the right thing.
-chris
Fedora 21 has a relatively nice systemd script for Tomcat.
It's designed for running multiple Tomcat instances.
If you have a copy of Fedora 21 and yumdownloader (by
installing yum-utils), you can take a look at the system
with:
mkdir Temp cd Temp yumdownloader tomcat.noarch rpm2cpio
tomcat-7.0.54-3.fc21.noarch.rpm | cpio -idmv
All of the files are then accessible in the Temp directory.
I've never liked how Fedora / RedHat / CentOS scatter the
components all over the landscape. I'm thinking of adapting
the Fedora systemd scripts to work with Tomcats installed
under a particular user.
The only issue seems to be that
Tomcat 7.0.57 and application META-INF/context.xml
Hi guys, I'm currently using Apache Tomcat 7.0.57 on GNU/Linux 32 bit and OpenJDK-7. I have made a few modifications to the CATALINA_HOME/conf/server.xml file ( fpaste.org/173572/23762142/). Under CATALINA_HOME/conf/Catalina/localhost/ there's only the manager.xml file. When I deploy my application myApp-1.2.war to Tomcat, instead of taking the context /my/app/context/1.2 that's specified in META-INF/context.xml under the path attribute of Context key, it takes the name of my war, so it gets deployed under the context myApp-1.2. What configuration am I missing? I'm deploying with curl, and also tried with the manager-gui. I would like to only use curl. May anyone help me please? Kind regards, José
Re: [OT] Tomcat 8 encoding issues: unable to change the default encoding iso-8859-1 to utf-8 in http header
On 1/25/2015 4:29 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/24/15 7:52 AM, André Warnier wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, ... Morality : in web applications, always specify the content-type (and character set, if applicable) of what you are returning. To André: the word you are looking for is Moral, not Morality. A moral is the essential message of a story, while morality is being able to tell the difference between right and wrong. ;) Thanks for the vocabulary note. I my defense, I would say that this family of English terms is a bit confusing, for a native French-speaker. Oh, English is a cluster-@#$*)% because the sentence structure is insane and the vocabulary has been robbed from every other language in history. I don't envy anyone trying to learn English.. it must seem to chaotic compared to German or Latin-based languages (both of which I have studied, and they have a certain beautiful order to them ... most of the time). You usually have impeccable English (better than most Americans, at least), which is why I went ahead and gave you the short lesson. There are many such things between different - but related - languages, some of them often leading to amusing situations. For example, the word in spanish for suffering from a cold is constipado, which is very close to the french word for being incapable to go to the toilet (constipé). Hah. I would have assumed both of those words were the latter (gastrointestinal distress). And the English adjective embarassed (also imported from the French embarassé(e), and with the same meaning), is very close to the Spanish embarassada, which means pregnant. This all just in case someone was wondering about my interest in character set issues on the WWW.. Just don't be embarrassed. Of pregnant. Or whatever. :) - -chris embarazada -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSp dynamic include in tomcat 8.0.15
On 1/25/2015 4:23 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Srikanth, On 1/24/15 12:03 AM, Srikanth Hugar wrote: When i include jsp:include page=/WEB-INF//countries.jsp / It does not work in tomcat 8.0.15. I think there are too many dots in there. It that just an example? What do you mean it does not work? and my included jsp file contents are something like : div class=txt form:select path=country form:option value=US label=US - UNITED STATES OF AMERICA / ... /form:select /div What could be the problem? That depends on what happens when you try the above. I'm not a JSP expert, but you might need to use %@ include instead of jsp:include if you want to include files from within /WEB-INF/. - -chris From the JavaServer Pages Specification: The %@ include file=... % directive is processed at translation time. The included content is parsed by the JSP container. Only static content may be included. The file attribute is interpreted relative to the current JSP file. The jsp:include page=... / action is processed at request time. The included content is not parsed. Static and dynamic content may be included. The page attribute is interpreted relative to the current JSP page. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Mod_jk Configuration
The best possible setup here is to set up httpd with more than one VirtualHost (and SNI, since you are using HTTPS) with the correct hostnames, etc., and only use JkMount from the share2 VirtualHost. Then, re-name your application from share.war to ROOT.war and re-deploy it into Tomcat. Use JkMount /share/* worker1 and be done with it. If the application can't handle that (try it!), you'll have to make other arrangements. According to: https://wiki.alfresco.com/wiki/Deploying_To_Server that is not even necessary. I understand that link is a years old and talks about tomcat 6 but the general idea is the same. I will try to rename the war and see what happens. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Mod_jk Configuration
If the application can't handle that (try it!), you'll have to make other arrangements. According to: https://wiki.alfresco.com/wiki/Deploying_To_Server that is not even necessary. I understand that link is a years old and talks about tomcat 6 but the general idea is the same. I will try to rename the war and see what happens. No, renaming the war will break everything: https://forums.alfresco.com/forum/end-user-discussions/alfresco-share/tried-set-sharewar-root-webapp-07262012-1228 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_jk Configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 1/26/15 4:52 PM, Chris Arnold wrote: The best possible setup here is to set up httpd with more than one VirtualHost (and SNI, since you are using HTTPS) with the correct hostnames, etc., and only use JkMount from the share2 VirtualHost. Then, re-name your application from share.war to ROOT.war and re-deploy it into Tomcat. Use JkMount /share/* worker1 and be done with it. If the application can't handle that (try it!), you'll have to make other arrangements. According to: https://wiki.alfresco.com/wiki/Deploying_To_Server that is not even necessary. I understand that link is a years old and talks about tomcat 6 but the general idea is the same. I will try to rename the war and see what happens. Yeah, that document is evidently a pack of lies. Specifically, the path and docbase attributes in Context are ignored in META-INF/context.xml files, and you really shouldn't have your Context anywhere else (except in conf/[engine]/[host]/[appname].xml, which behaves almost the same way). Best thing to do is to name the web application the same as where you want it to be deployed and not try to re-write anything. Is there a particular reason you want to map / to /share instead of /share to /share? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUxrsIAAoJEBzwKT+lPKRY7a0QAMllYOS212JVjYb3jNOi1LO7 jNLjA81tHgXYoYCNINdKAS0M1kiwSxFVWuGBtN/WT9QoawXjR1bq01j7q5h0fwRt VPy2cFiusD/scwqEV6QeFyrGm96K9lA9tj3gnbsVz1ZyFWs3YYu5Gfm49yuCUp96 4Frno+x6dChJYA6PSSS4l9UtC90hGAZuIzvDveta4gRV6HYnr3jFlOhTpEuX0aCn MkbujVlb8B/of52C/iHDERUPdnyrb92AFBgF5YGLYtwarrzh+Vsj6xxvnABkZ4XE ppuCVAAMPN2j7DRJCYrD1l5kMTbTCPYNbl99uTbSMhzz+btfuo2AlLkuL6CJtrIe 8n6HZc5dpUdUJN3VTLhk18WzF6wjZImJ0qBywn+tu7jE0RFh/e8lfl5gBbAn/v6/ oApR02gyLF9rrXvmzEl7BepKzsVO8VyRSXTY2OBlbYnNQwr+FSM+3OVUeXYA5dzg zRDaQ3P84fj3owZDlPjKRLdeV586xRmaIuh0Gep5JjmTceFYMkr1gYkqRu8xBgyU z25bokqGgN1MO2j8MxwzB0WUmt99B8kKel/+0NzA9iJztI/Bb/qa9n03SCXd0fSi lewHqQ8AzhpENY+exyZYra+X2if+qBJD6oXP9GQKwkkiC/E3c9VC1omXzqQbiCeX 2I0xYULkViwp68yjEcAX =xaqF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unable to install tomcat on Window 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/26/2015 1:41 PM, Frank Lugalla wrote: Hi Hi Guys I am trying to install Tomcat7 in my computer without success, I have tried to set up and go through every bit where it goes wrong as seen below without much success. After startup, the default web applications included with Tomcat will be available by visiting: http://localhost:8080/ But When I go there I can't seem to find a webpage. Please I am helpless can anyone please help here? [cid:image001.png@01D0397E.82FE70C0] This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp Hi Frank, http://www.catb.org/esr/faqs/smart-questions.html And now I have lots of questions: 1. What exact version of Tomcat 7? 2. Do you have a JRE installed? 3. What version of the JRE do you have installed? a. include if it's 32 or 64 bit b. people often install both on a 64 bit machine 4. Is the JRE executable on your PATH? 5. Are you trying to install the service? 6. Do you have administrator rights to your machine if you're installing the service? 7. Did you try the following? a. download the appropriate zip file matching your JRE (32 or 64 bit) b. Unzip the file in your documents directory c. double-click on startup.bat in apache-tomcat-7.0.xx\bin The list strips most (if not all) attachments. Some of these questions may have been answered by your screen shot, but that was not copied along with your message. Go try item 7 above, and report in text (not HTML, not graphics) what is going on. . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJUxrr7AAoJEEFGbsYNeTwtsZ0H+wV2r70r0qYB8LqrttXfBa9h 9iLNWBEzjTAtRQuKghb6ZC/73VjeAkf80//lY0d5eopYgfI6CwX7FovSegIUBTQ2 BfgdoyN035SGVcDLcAxFu1dOuLbJrzyH5n7Ej+QaOyG/OnMpyXQXGcdLgZu57hou whYSXnyu9/5OYixaLDv8VgIRUCCcZwJW1lFFI4ehJpLbP95kSJRiqahDJnC7pnMl OKAX+sUDHZ85JxsL9YU57ehEReeSyQjItNuunZ/k99Y03AmwQgzZnIfZfMSdlIO6 b4eVwkzn+P+Z8B1yyEuCOsBM7yAAagxbFYCki9b3SbRCuxkTycbZwUR6vc06DGw= =Clx8 -END PGP SIGNATURE- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Unable to install tomcat on Window 7
Hi Hi Guys I am trying to install Tomcat7 in my computer without success, I have tried to set up and go through every bit where it goes wrong as seen below without much success. After startup, the default web applications included with Tomcat will be available by visiting: http://localhost:8080/ But When I go there I can't seem to find a webpage. Please I am helpless can anyone please help here? [cid:image001.png@01D0397E.82FE70C0] This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
Re: Unable to install tomcat on Window 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Frank, On 1/26/15 4:41 PM, Frank Lugalla wrote: I am trying to install Tomcat 7 on my computer without success, I have tried to set up and go through every bit where it goes wrong as seen below without much success. Your screenshot was stripped by the list. Can you explain in text instead? After startup, the default web applications included with Tomcat will be available by visiting: http://localhost:8080/ But When I go there I can’t seem to find a webpage. What do you find instead? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUxroiAAoJEBzwKT+lPKRYMdkP/0BPUYK3MvT9HZRXKCxZIHVO zHCJAwXyoe5V0RQ3l0QGcAPwrDrvhKnn5mEdn2o97VaaXzCgqDEzwmZSOCUFyLUr iZqD9GTPijLeuH4oqg4LRpk2Zzqf2BiIc29Hiyczt9vmMIi8HToY0vgEtv+h3+LY mcQgM1LCXaLOBMIY12Rgq+yn+Ps0VPoq7bz+ff3+a8sEsiXs2DsFOa+D6wznaL7u TSc74w5zauMocfoMUjYxBA4/+aQ8wdr/MFWrI404L5v0SNMuM24l0A0Y3WO5wwaH h7LH7jtzRORCNRbI6fkRkvTt4FVMr0EJQoWbpAaupdjyJmb0J2/JTeCmMYJGQunL SKpDi4E+tUt4sxvu54YrlT2asDGmJFkA0D1vOQrzSRF56Q02QcYCHzSPYRPaRPF2 UdZKt+afsjYzs+AbmW4GhMTsMbKqYv5BnbdK7HiPs61E6YU/bIaKx0boJ9K0Y9+j Rrr1PBrRByMMriS26kQKXyhA9EKnn7eBvK2tH+yuAhPFaPaKbPCla4CQhTAUckjD 11CcGueFrA6dtOpObeX7bRcpsnYiRZIt21tmusGkf3Re9ukYxgOFKl6rXJiumqVZ o5ZNBlVacr32Y3Kzw1W8AEPN7pNKq9NMHT7D4Qo3PtXeW9mTwXirtuFwLUtGUAmV PCRvh7fUhz0JiV8ME7Bx =O3uw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Unable to install tomcat on Window 7
Thanks, Frank Lugalla 314-212-27086 (office) 858-366-5733 (mobile) AMDOCS | EMBRACE CHALLENGE EXPERIENCE SUCCESS -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, January 26, 2015 4:05 PM To: Tomcat Users List Subject: Re: Unable to install tomcat on Window 7 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Frank, Hi Chris It simply says the webpage can not be displayedi went confirmed the port for HTTP to be 8080,I tried to change port shutdown.bat and startup.bat.Still the page wont be displayed.I tried to go check my proxy server settings if anything wrong with setting but still no hope On 1/26/15 4:41 PM, Frank Lugalla wrote: I am trying to install Tomcat 7 on my computer without success, I have tried to set up and go through every bit where it goes wrong as seen below without much success. Your screenshot was stripped by the list. Can you explain in text instead? After startup, the default web applications included with Tomcat will be available by visiting: http://localhost:8080/ But When I go there I can’t seem to find a webpage. What do you find instead? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUxroiAAoJEBzwKT+lPKRYMdkP/0BPUYK3MvT9HZRXKCxZIHVO zHCJAwXyoe5V0RQ3l0QGcAPwrDrvhKnn5mEdn2o97VaaXzCgqDEzwmZSOCUFyLUr iZqD9GTPijLeuH4oqg4LRpk2Zzqf2BiIc29Hiyczt9vmMIi8HToY0vgEtv+h3+LY mcQgM1LCXaLOBMIY12Rgq+yn+Ps0VPoq7bz+ff3+a8sEsiXs2DsFOa+D6wznaL7u TSc74w5zauMocfoMUjYxBA4/+aQ8wdr/MFWrI404L5v0SNMuM24l0A0Y3WO5wwaH h7LH7jtzRORCNRbI6fkRkvTt4FVMr0EJQoWbpAaupdjyJmb0J2/JTeCmMYJGQunL SKpDi4E+tUt4sxvu54YrlT2asDGmJFkA0D1vOQrzSRF56Q02QcYCHzSPYRPaRPF2 UdZKt+afsjYzs+AbmW4GhMTsMbKqYv5BnbdK7HiPs61E6YU/bIaKx0boJ9K0Y9+j Rrr1PBrRByMMriS26kQKXyhA9EKnn7eBvK2tH+yuAhPFaPaKbPCla4CQhTAUckjD 11CcGueFrA6dtOpObeX7bRcpsnYiRZIt21tmusGkf3Re9ukYxgOFKl6rXJiumqVZ o5ZNBlVacr32Y3Kzw1W8AEPN7pNKq9NMHT7D4Qo3PtXeW9mTwXirtuFwLUtGUAmV PCRvh7fUhz0JiV8ME7Bx =O3uw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
RE: Mod_jk Configuration
Yeah, that document is evidently a pack of lies. Specifically, the path and docbase attributes in Context are ignored in META-INF/context.xml files, and you really shouldn't have your Context anywhere else (except in conf/[engine]/[host]/[appname].xml, which behaves almost the same way). Best thing to do is to name the web application the same as where you want it to be deployed and not try to re-write anything. Is there a particular reason you want to map / to /share instead of /share to /share? Ease of use and it worked in a previous installment. I think this goes against what you are saying in the above text but, I just got a reply from the alfresco mailinglist. Here is what was said: The way we got around this was to just tell tomcat to deploy Share at / (ROOT) as well as at /share. To do that, we added the following line to the very end of our tomcat server.xml file (5 lines from the end, just before the line reading “/host”): Context path= debug=0 docBase=share / I don’t know if that’s exactly the right way to go about it, but it’s worked well for us for about 4.5 years now. I still have a concern with this as we have other sites that we need to access at the http://domain.tld level and it seems to me ( I could e understanding his solution wrong) that above solution will point all http(s)://domain.tld requests to /share. Am I misunderstanding his solution? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Application getting stopped with error code 610 038
My tomcat web application stopped working after getting following error. janv. 09, 2015 9:57:16 AM org.apache.tomcat.util.net.AprEndpoint$Poller run Grave: Poller failed with error [610 038] : [APR does not understand this error code] Could you please help with what could be root cause of this error. Thanks Regards, Rahul
request.getUserPrincipal() is null but StandardSession.principal is set
Hi, we have an issue with later and latest Tomcat versions, that prevent us from upgrading to a version later than something like 7.0.22. We use FormBasedAuthentication with a custom realm. This is tested with Tomcat 7.0.57 and JDK 7u76 on Windows. My setup has a login form calling the j_security servlet. The custom realm is called and authentication is successful, a custom principal is returned. Tomcat will then forward to the protected resource, and we catch the request in a RequestListener. The problem is, that request.getUserPrincipal() returns null. The debugger exposes, that the sessionwrapper returned by request.getSession(false) (instance of SessionWrapper, containing StandardSession) has a field principal, that contains the principal returned from my realm. I have seen a discussion on the requirement to return a userprincipal on non protected requests in bugzilla, but the request here is calling for a protected resource. Any idea on why this can happen would be very helpful. Actually, I see it as a bug, that the request is not authenticated but still served. Mit freundlichen Grüßen Thomas Strauß Geschäftsführer Entwicklung SRS PaperDynamix® WE MAKE PAPER WORK T +49 6251 85 424 - 20 | M +49 174 2110912 SRS-Management GmbH | Berliner Ring 103 | D-64625 Bensheim Geschäftsführer: Detlev Homilius, Thomas Strauß HRB 25262 AG Darmstadt Fon +49 6251 85 424-0 | Fax +49 6251 85 424-14 Wir freuen uns auf einen Besuch in unserem Forum auf XING oder Facebook https://www.xing.com/net/prozessoptimierung/ http://www.facebook.com/srs.managementhttp://www.facebook.com/pages/SRS-Management-GmbH/155489571182317?sk=wall
Re: request.getUserPrincipal() is null but StandardSession.principal is set
2015-01-26 11:54 GMT+03:00 Thomas Strauß t.stra...@srs-management.de:
Hi,
we have an issue with later and latest Tomcat versions, that prevent us from
upgrading to a version later than something like 7.0.22.
We use FormBasedAuthentication with a custom realm.
This is tested with Tomcat 7.0.57 and JDK 7u76 on Windows.
My setup has a login form calling the j_security servlet. The custom realm is
called and authentication is successful, a custom principal is returned.
Tomcat will then forward to the protected resource, and we catch the request
in a RequestListener.
The problem is, that request.getUserPrincipal() returns null. The debugger
exposes, that the sessionwrapper returned by request.getSession(false)
(instance of SessionWrapper, containing StandardSession) has a field
principal, that contains the principal returned from my realm.
I have seen a discussion on the requirement to return a userprincipal on non
protected requests in bugzilla, but the request here is calling for a
protected resource.
Any idea on why this can happen would be very helpful. Actually, I see it as
a bug, that the request is not authenticated but still served.
1. Source code = ?
I see that you have it here:
https://stackoverflow.com/questions/28147261/request-getuserprincipal-is-null-but-standardsession-principal-is-set
2. Stacktrace when RequestListener is invoked = ?
When the listener is called? Is it called after authenticator valve or
before it?
3. Try debugging through AuthenticatorBase.invoke()
https://wiki.apache.org/tomcat/FAQ/Developing#Debugging
There is code that copies the principal from session into request
[[[
if (cache) {
...
if (principal != null) {
if (log.isDebugEnabled())
log.debug(We have cached auth type +
session.getAuthType() +
for principal +
session.getPrincipal());
request.setAuthType(session.getAuthType());
request.setUserPrincipal(principal);
}
}
}
}
]]]
4. This does not reproduce in the default configuration. There is a
page in examples webapp that uses FORM authentication.
http://localhost:8080/examples/jsp/security/protected/index.jsp
If you look into index.jsp it will display No user principal could be
identified. when request.getUserPrincipla() is null. It displays the
correct principal name for me.
5. Is your principal a subclass of GenericPrincipal? How do you set it?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
AW: request.getUserPrincipal() is null but StandardSession.principal is set
Hi,
thanks for replying, yes, this question is also posted on SO.
You did actually help me understand the problem better, yet, I cannot resolve
it for the moment.
To summarize my findings: I have a principal set in the protected resource. If
a request is triggered from the protected resource, the request is no longer
equipped with the principal in the listener. When arriving on the jsp, the
principal is set again.
If I set a breakpoint inside the request listener to trigger on a non null
principal, it is never triggered.
Hmmm, shouldn't tomcat provide the generic principal from the session before
the listener is called, when running form authentication?
I gave some details to your questions below.
To (1): is additional source required?
To (2): Here is the stack when the listener triggers:
PortalRequestListener.requestInitialized(ServletRequestEvent) line: 79
StandardContext.fireRequestInitEvent(ServletRequest) line: 6157
StandardHostValve.__invoke(Request, Response) line: 165
StandardHostValve.invoke(Request, Response) line: not available
ErrorReportValve.invoke(Request, Response) line: 103
AccessLogValve.invoke(Request, Response) line: 950
StandardEngineValve.invoke(Request, Response) line: 116
CoyoteAdapter.service(Request, Response) line: 421
Http11Processor(AbstractHttp11Processor).process(SocketWrapperS) line: 1070
Http11Protocol$Http11ConnectionHandler(AbstractProtocol$AbstractConnectionHandler).process(SocketWrapperS,
SocketStatus) line: 611
JIoEndpoint$SocketProcessor.run() line: 314
I checked with all requests coming in, but the stack contents is the same for
all breakpoints.
To (3): I have debugged the FormAuthenticator and found that the request is
actually at some point equipped with the correct principal. So the
authentication actually works to some extent.
I have restructured the main.jsp to do nothing, and it gets displayed properly,
genericPrincipal is set.
If I call from that page a protected resource, that request has no principal
set, but I can see the principal in the session (buried in the StandardSession
object).
Shouldn't the request receive the principal, as it is requesting a protected
resource?
To (5): Yes, it is subclass from GenericPrincipal and created by the realm
(using new) and returned to the caller of authenticate. I see the principal
object with right class name in the debugger at the right place.
Mit freundlichen Grüßen
Thomas Strauß
Geschäftsführer Entwicklung
SRS PaperDynamix®
WE MAKE PAPER WORK
T +49 6251 85 424 - 20 | M +49 174 2110912
SRS-Management GmbH | Berliner Ring 103 | D-64625 Bensheim
Geschäftsführer: Detlev Homilius, Thomas Strauß HRB 25262 AG Darmstadt
Fon +49 6251 85 424-0 | Fax +49 6251 85 424-14
Wir freuen uns auf einen Besuch in unserem Forum auf XING oder Facebook
https://www.xing.com/net/prozessoptimierung/
http://www.facebook.com/srs.management
-Ursprüngliche Nachricht-
Von: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Gesendet: Montag, 26. Januar 2015 11:43
An: Tomcat Users List
Betreff: Re: request.getUserPrincipal() is null but StandardSession.principal
is set
2015-01-26 11:54 GMT+03:00 Thomas Strauß t.stra...@srs-management.de:
Hi,
we have an issue with later and latest Tomcat versions, that prevent us from
upgrading to a version later than something like 7.0.22.
We use FormBasedAuthentication with a custom realm.
This is tested with Tomcat 7.0.57 and JDK 7u76 on Windows.
My setup has a login form calling the j_security servlet. The custom realm is
called and authentication is successful, a custom principal is returned.
Tomcat will then forward to the protected resource, and we catch the request
in a RequestListener.
The problem is, that request.getUserPrincipal() returns null. The debugger
exposes, that the sessionwrapper returned by request.getSession(false)
(instance of SessionWrapper, containing StandardSession) has a field
principal, that contains the principal returned from my realm.
I have seen a discussion on the requirement to return a userprincipal on non
protected requests in bugzilla, but the request here is calling for a
protected resource.
Any idea on why this can happen would be very helpful. Actually, I see it as
a bug, that the request is not authenticated but still served.
1. Source code = ?
I see that you have it here:
https://stackoverflow.com/questions/28147261/request-getuserprincipal-is-null-but-standardsession-principal-is-set
2. Stacktrace when RequestListener is invoked = ?
When the listener is called? Is it called after authenticator valve or before
it?
3. Try debugging through AuthenticatorBase.invoke()
https://wiki.apache.org/tomcat/FAQ/Developing#Debugging
There is code that copies the principal from session into request [[[
if (cache) {
...
if (principal != null) {
if (log.isDebugEnabled())
log.debug(We
Re: request.getUserPrincipal() is null but StandardSession.principal is set
2015-01-26 14:27 GMT+03:00 Thomas Strauß t.stra...@srs-management.de: Hi, thanks for replying, yes, this question is also posted on SO. You did actually help me understand the problem better, yet, I cannot resolve it for the moment. To summarize my findings: I have a principal set in the protected resource. If a request is triggered from the protected resource, the request is no longer equipped with the principal in the listener. When arriving on the jsp, the principal is set again. If I set a breakpoint inside the request listener to trigger on a non null principal, it is never triggered. Hmmm, shouldn't tomcat provide the generic principal from the session before the listener is called, when running form authentication? I gave some details to your questions below. To (1): is additional source required? To (2): Here is the stack when the listener triggers: PortalRequestListener.requestInitialized(ServletRequestEvent) line: 79 StandardContext.fireRequestInitEvent(ServletRequest) line: 6157 StandardHostValve.__invoke(Request, Response) line: 165 StandardHostValve.invoke(Request, Response) line: not available ErrorReportValve.invoke(Request, Response) line: 103 AccessLogValve.invoke(Request, Response) line: 950 StandardEngineValve.invoke(Request, Response) line: 116 CoyoteAdapter.service(Request, Response) line: 421 Http11Processor(AbstractHttp11Processor).process(SocketWrapperS) line: 1070 Http11Protocol$Http11ConnectionHandler(AbstractProtocol$AbstractConnectionHandler).process(SocketWrapperS, SocketStatus) line: 611 JIoEndpoint$SocketProcessor.run() line: 314 I checked with all requests coming in, but the stack contents is the same for all breakpoints. In this mailing list the convention is to respond below the original question: http://tomcat.apache.org/lists.html#tomcat-users - 6. The stacktrace above does not have FormAuthenticatorValve, so there is no wonder that request has not been authenticated yet. There is the following change for 7.0.22 in the changelog file: [quote] Correct a regression with the fix for 51653 that broke custom error pages for 4xx responses from the Authenticators. Error handling and request listeners are now handled in the StandardHostValve to ensure they wrap all Context level activity. (markt) [/quote] Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: request.getUserPrincipal() is null but StandardSession.principal is set
Hi,
the problem is isolated in StandardHostValve Lines 165ff:
boolean errorAtStart = response.isError();
165:if (asyncAtStart || context.fireRequestInitEvent(request)) {
// Ask this Context to process this request
try {
if (!asyncAtStart || asyncDispatching) {
170: context.getPipeline().getFirst().invoke(request, response);
} else {
if (!errorAtStart) {
throw new
IllegalStateException(sm.getString(standardHost.asyncStateError));
}
In line 165, the request is feed into the request listener (no authentication
set here).
In line 170, the pipeline is processed, including the authentication process.
The form based authentication is then setting the userPrincipal.
This is definitely different to earlier versions of the engine. The request
listener cannot be used to handle authentication any more. If this is against
or valid with the spec, I cannot tell for the moment. Yet, it is somewhat
strange, as the request is not fully initialized, when the request initialized
event is fired.
Should I copy this behaviour into bugzilla and open an issue? Should be
mentioned in the release notes, at least...
Mit freundlichen Grüßen
Thomas Strauß
Geschäftsführer Entwicklung
SRS PaperDynamix®
WE MAKE PAPER WORK
T +49 6251 85 424 - 20 | M +49 174 2110912
SRS-Management GmbH | Berliner Ring 103 | D-64625 Bensheim
Geschäftsführer: Detlev Homilius, Thomas Strauß HRB 25262 AG Darmstadt
Fon +49 6251 85 424-0 | Fax +49 6251 85 424-14
Wir freuen uns auf einen Besuch in unserem Forum auf XING oder Facebook
https://www.xing.com/net/prozessoptimierung/
http://www.facebook.com/srs.management
-Ursprüngliche Nachricht-
Von: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Gesendet: Montag, 26. Januar 2015 11:43
An: Tomcat Users List
Betreff: Re: request.getUserPrincipal() is null but StandardSession.principal
is set
2015-01-26 11:54 GMT+03:00 Thomas Strauß t.stra...@srs-management.de:
Hi,
we have an issue with later and latest Tomcat versions, that prevent us from
upgrading to a version later than something like 7.0.22.
We use FormBasedAuthentication with a custom realm.
This is tested with Tomcat 7.0.57 and JDK 7u76 on Windows.
My setup has a login form calling the j_security servlet. The custom realm is
called and authentication is successful, a custom principal is returned.
Tomcat will then forward to the protected resource, and we catch the request
in a RequestListener.
The problem is, that request.getUserPrincipal() returns null. The debugger
exposes, that the sessionwrapper returned by request.getSession(false)
(instance of SessionWrapper, containing StandardSession) has a field
principal, that contains the principal returned from my realm.
I have seen a discussion on the requirement to return a userprincipal on non
protected requests in bugzilla, but the request here is calling for a
protected resource.
Any idea on why this can happen would be very helpful. Actually, I see it as
a bug, that the request is not authenticated but still served.
1. Source code = ?
I see that you have it here:
https://stackoverflow.com/questions/28147261/request-getuserprincipal-is-null-but-standardsession-principal-is-set
2. Stacktrace when RequestListener is invoked = ?
When the listener is called? Is it called after authenticator valve or before
it?
3. Try debugging through AuthenticatorBase.invoke()
https://wiki.apache.org/tomcat/FAQ/Developing#Debugging
There is code that copies the principal from session into request [[[
if (cache) {
...
if (principal != null) {
if (log.isDebugEnabled())
log.debug(We have cached auth type +
session.getAuthType() +
for principal +
session.getPrincipal());
request.setAuthType(session.getAuthType());
request.setUserPrincipal(principal);
}
}
}
}
]]]
4. This does not reproduce in the default configuration. There is a page in
examples webapp that uses FORM authentication.
http://localhost:8080/examples/jsp/security/protected/index.jsp
If you look into index.jsp it will display No user principal could be
identified. when request.getUserPrincipla() is null. It displays the correct
principal name for me.
5. Is your principal a subclass of GenericPrincipal? How do you set it?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
AW: request.getUserPrincipal() is null but StandardSession.principal is set
-Ursprüngliche Nachricht- Von: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Gesendet: Montag, 26. Januar 2015 13:01 An: Tomcat Users List Betreff: Re: request.getUserPrincipal() is null but StandardSession.principal is set In this mailing list the convention is to respond below the original question: http://tomcat.apache.org/lists.html#tomcat-users - 6. Sorry. The stacktrace above does not have FormAuthenticatorValve, so there is no wonder that request has not been authenticated yet. There is the following change for 7.0.22 in the changelog file: [quote] Correct a regression with the fix for 51653 that broke custom error pages for 4xx responses from the Authenticators. Error handling and request listeners are now handled in the StandardHostValve to ensure they wrap all Context level activity. (markt) [/quote] Yes, maybe obvious for you, and is clear now for me, but the side effect, that authentication is no longer available to a request listener would have saved me some hours. Anyway, thanks for helping out. I will rewrite the listener to a filter then, as I see no other possibility here. Best regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_jk Configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 1/26/15 5:36 PM, Chris Arnold wrote: Yeah, that document is evidently a pack of lies. Specifically, the path and docbase attributes in Context are ignored in META-INF/context.xml files, and you really shouldn't have your Context anywhere else (except in conf/[engine]/[host]/[appname].xml, which behaves almost the same way). Best thing to do is to name the web application the same as where you want it to be deployed and not try to re-write anything. Is there a particular reason you want to map / to /share instead of /share to /share? Ease of use and it worked in a previous installment. Okay. If you must rewrite you should be able to do something like this (untested!): RewriteRule ^(/.*) /share/$1 [L] JkMount /share/* worker1 I dunno if that will work, but mod_rewrite runs pretty early/often in the pipeline and I think mod_jk will tolerate that. Note that any response from Tomcat that includes links will have those links still pointing to /foo and not /share/foo which may or may not result in a problem. It may be easier for you to use mod_proxy and do something simpler like this: ProxyPass / ajp://host:port/share Don't forget the ProxyPassReverse if you do that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUxsfQAAoJEBzwKT+lPKRY7IwP/R/4V7v9KoRycFKFpDJzuLnL 3PXkCmWCrnVCPbS0xjsRGNeRkPxBQ9hqgmJpGypaE5lypO9zDP+0FERCC/0aPwnC jd5wXUm/ZlTLQCAWmNzXM/sO55psF1T3ZcVnSDOv6BfdlTOTwLAl/E0edOeGRUI9 iD12Lgh5s7suKd+/aQpVVGLme/VpW/7sw/7fPCxzotuX5yPEzZ7PsngRIQLzH1+H QtBJRX2y6gxd7yr2CktHPiEfEGTGDzhs+EAim8wZBW13G7o7V5STrBbf6Nur75Vg DY/0txpf+hz/oqi0pik08WNWRxlXRkDf+Ae+/oSDUE8oEhmNuYyKdSJHLvpOw7eB PIHFC3aAxtjU2ZKZY8JxT2UM1CJAHyRfqUlVECzJN5VXZFEV7217yQClhwbyAOYq O9a8lrmVFAznvOB6UmFC84J46MJue/f66dKOauTMhrKGrMJBUk95HLDsXSoAT00e TAn3sQyaSypiqn8AJZIQl7KGOGkohHy7wdjzWvJYLeOufWowz9ypg3/QKbI9/AX/ yemW7fT0+vCIrz7IOiY57xsnQR8q3AeyWQkTI/k5XqzpZkZBC8L8/fv7lIgiQfQo 9wuR3kKyF8nfAmnN7WBF+5O/rBwezlIROwcaEisG4plGbumlDPieQn9ryQcXflk7 LM4Yw6Zq18j2qjSL0oy4 =2XTx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_jk Configuration
Yeah, that document is evidently a pack of lies. Specifically, the path and docbase attributes in Context are ignored in META-INF/context.xml files, and you really shouldn't have your Context anywhere else (except in conf/[engine]/[host]/[appname].xml, which behaves almost the same way). Best thing to do is to name the web application the same as where you want it to be deployed and not try to re-write anything. Is there a particular reason you want to map / to /share instead of /share to /share? Ease of use and it worked in a previous installment. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unable to install tomcat on Window 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Frank, On 1/26/15 5:13 PM, Frank Lugalla wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, January 26, 2015 4:05 PM To: Tomcat Users List Subject: Re: Unable to install tomcat on Window 7 It simply says the webpage can not be displayedi went confirmed the port for HTTP to be 8080,I tried to change port shutdown.bat and startup.bat.Still the page wont be displayed.I tried to go check my proxy server settings if anything wrong with setting but still no hope Try launching Tomcat from the command-line like this: C:\path %CATALINA_HOME%\bin\startup.bat run By adding the run argument, Tomcat will run in the foreground with all of the logging output coming to the terminal: you'll be able to see if there are any errors, and when (if) Tomcat stops at some point. Once you launch it, you should be able to access your server at localhost:8080 (assuming a default Connector configuration). If it doesn't work, please post everything that gets spit out on the terminal, starting from the startup.bat run above, back to the list. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUxr7CAAoJEBzwKT+lPKRYdOsP/R138cpiOiis+xPF7lA3LgHf MvWJUSyt093FGLhw9iFp1wPMabc1UewyPfZ82OmA+2wEnC1Nwye0nd63sNqNNiqv FaqEK5mHs2n6qLmUjgAK+dZHISAru9AUdlVy40sazTwAvq1uKUzt2lrA2/bLagfS 4//kPQD6JWl50qQrZGJomKIe/2ASSEjqrOP/+PmJVpmiDnYbMQtd8NCjaSJefynl FyPJlk5L7agadUQZ9zMg+mqw7igFgsAP+30GjO0VLlcUJSwNsN/XAw3rZOkFLIxT iUP/9bk9Klr2/ZdU9GNCy/dZscgImD2ZE+HqedptZtQCLlkcdL/MT/zdNE2Nh2U9 aDg6w0mPDLMb1Xw4/M80yXjnIdilwCetMv3dfgYp5qO4QnzTWZA12GVqIxYius5L +ASg0h5031kfVyBxNyck49+JaleUTjArC9R1OGqmg6Q8SNlLNIrO6JhfKh7JwpFW SUzqiLrEV3jxoZu/AFMGKaF5vsolTNFp3ijWmnPfmpmdkaODc6lMnHx7cjRmJIV+ JgACBxvyAZ0IW9QAzcFUEN88AcG1gc5P8lH4xuW6biksxlQKS9dDHezPkwndqX4d 5kVA6JFX+3Y0WmzX5RV2REvJPVJ44NET3iDKOiJBx4yPrQUud5uWKqV4hr9NMr6v rNHLaeb9PISeAFQLzJ0K =LYZm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
