Re: tomcat catalina.out getting bombed with debug messages on maven-proxy deploy
Unless I'm missing something somewhere else, catalina.sh specifies that logging.properties is the java.util.logging configuration file used. I suppose changing the jre properties file is an option, though if that works it leaves a big questions as to why this is the case. Is anyone else having this issue? I think pretty much anyone using maven-proxy should be experiencing this. If you are using maven-proxy on Tomcat 5.5 and are *not* experiencing this, I'd be interested to know if you are using the compatibility package and jdk1.4.2 or not. It appears that much of the DEBUG messages are coming from XML parsing, and the xerces jars are part of the compatibility package. Brad On Feb 24, 2006, at 7:52 PM, Glen Mazza wrote: Brad O'Hearne wrote: This is a real incredible nuisance. It appears that Tomcat is using java.util.logging, so I altered all the log levels in conf/ logging.properties to WARNING, and I'm still getting DEBUG messages Since you're using java.util.logging, have you tried the logging.properties within the JAVA_HOME/jre/lib directory? That might work. Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat catalina.out getting bombed with debug messages on maven-proxy deploy
This is a real incredible nuisance. It appears that Tomcat is using
java.util.logging, so I altered all the log levels in
conf/logging.properties to WARNING, and I'm still getting DEBUG messages
like crazy. hundreds, maybe thousands of them, I believe coming from
some XML parsing code. Does anyone know how and where to shut these
off? I now have the Tomcat logging.properties file and my
log4j.properties file set, and they appear to be having no effect at all.
Help! Thanks
Brad
Brad O'Hearne wrote:
Here is my log4j.properties file:
log4j.rootLogger=INFO, R
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=${catalina.home}/logs/tomcat.log
log4j.appender.R.MaxFileSize=10MB
log4j.appender.R.MaxBackupIndex=10
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
log4j.logger.org.apache.catalina=INFO, R
It was my understanding the under the rules of Log4j inheritance, all
loggers would inherit from the first non-null ancestor starting with
the parent and working toward the root. I believe that this means that
I should only be getting INFO level messages, no?
Brad
Rob Gregory wrote:
Please post your log4j.properties file - it sounds like your root
logger is
too general.
Rob
-Original Message-----
From: Brad O'Hearne [mailto:[EMAIL PROTECTED] Sent: 24 February
2006 19:35
To: Tomcat Users List
Subject: tomcat catalina.out getting bombed with debug messages on
maven-proxy deploy
I have a vanilla installation of Tomcat 5.5 (with logging added, and
log4j.properties rootLogger set to level INFO), which starts up
cleanly, and writes maybe 15 lines to catalina.out -- no more. I then
deploy the maven-proxy-webapp.war, and catalina.out gets immediately
bombed with DEBUG level messages. It appears that most of the
messages are coming from the commons.digester and digester packages.
Does this problem lie in Tomcat, or in the web app? How do I filter
the LOG level for this information?
Thanks!
Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk set up, running, no errors in log, but no connections between Tomcat / httpd
Well, it appears I have Tomcat and httpd set up and running mod_jk without any errors in the logs. I have used the tomcat auto-config for mod_jk, and httpd is including it into the httpd.conf file. Logs look clean. But mod_jk.log is completely empty, and when I do a netstat, I see the following: [EMAIL PROTECTED] jk]# netstat -vatn | grep 80 tcp0 0 127.0.0.1:8005 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:8009 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN The first and second lines are obviously Tomcat listening for shutdown and ajp connections, and the third one is apache listening for http. But I thought (based on several documents I read online) that I was supposed to see connections between tomcat and apache. Is this correct? If so, where should I be looking next to debug, as I see no errors in the logs? Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat catalina.out getting bombed with debug messages on maven-proxy deploy
Here is my log4j.properties file:
log4j.rootLogger=INFO, R
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=${catalina.home}/logs/tomcat.log
log4j.appender.R.MaxFileSize=10MB
log4j.appender.R.MaxBackupIndex=10
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
log4j.logger.org.apache.catalina=INFO, R
It was my understanding the under the rules of Log4j inheritance, all
loggers would inherit from the first non-null ancestor starting with the
parent and working toward the root. I believe that this means that I
should only be getting INFO level messages, no?
Brad
Rob Gregory wrote:
Please post your log4j.properties file - it sounds like your root logger is
too general.
Rob
-Original Message-
From: Brad O'Hearne [mailto:[EMAIL PROTECTED]
Sent: 24 February 2006 19:35
To: Tomcat Users List
Subject: tomcat catalina.out getting bombed with debug messages on
maven-proxy deploy
I have a vanilla installation of Tomcat 5.5 (with logging added, and
log4j.properties rootLogger set to level INFO), which starts up cleanly,
and writes maybe 15 lines to catalina.out -- no more. I then deploy the
maven-proxy-webapp.war, and catalina.out gets immediately bombed with
DEBUG level messages. It appears that most of the messages are coming
from the commons.digester and digester packages. Does this problem lie
in Tomcat, or in the web app? How do I filter the LOG level for this
information?
Thanks!
Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tomcat catalina.out getting bombed with debug messages on maven-proxy deploy
I have a vanilla installation of Tomcat 5.5 (with logging added, and log4j.properties rootLogger set to level INFO), which starts up cleanly, and writes maybe 15 lines to catalina.out -- no more. I then deploy the maven-proxy-webapp.war, and catalina.out gets immediately bombed with DEBUG level messages. It appears that most of the messages are coming from the commons.digester and digester packages. Does this problem lie in Tomcat, or in the web app? How do I filter the LOG level for this information? Thanks! Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: default Tomcat 5.5 won't shutdown cleanly (Was: After adding mod_jk, tomcat won't shutdown cleanly)
No worries. /etc/hosts issue. B Brad O'Hearne wrote: Vanilla Tomcat (with the jdk1.4 compatibility jars added), and vanilla server.xml. Apache httpd isn't even started yet. I just installed a fresh copy of Tomcat direct from the tar file, and while it starts up, shutdown hangs. Brad Fenlason, Josh wrote: Are you using the native apr connector? , Josh. -Original Message----- From: Brad O'Hearne [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 11:50 AM To: Tomcat Users List Subject: default Tomcat 5.5 won't shutdown cleanly (Was: After adding mod_jk, tomcat won't shutdown cleanly) I guess I have to alter my original assertion. Vanilla tomcat 5.5 isn't shutting down cleanly (default server.xml). Are there known causes for this? Anything in particular that I need to check? Brad Brad O'Hearne wrote: Ok, it appears I may have mod_jk running properly. However, now when I try to shutdown tomcat, I get the following: Using CATALINA_BASE: /opt/apache-tomcat-5.5.12 Using CATALINA_HOME: /opt/apache-tomcat-5.5.12 Using CATALINA_TMPDIR: /opt/apache-tomcat-5.5.12/temp Using JRE_HOME: /usr/java/j2sdk1.4.2_10 Created MBeanServer with ID: 1f436f5:1099d0fba63:-8000:cvs.cvs:1 But it never returns. It just sits there, indefinitely. The java process never quits, and is still hung out there. My erver.xml is below. Is there a known problem with shutdowns after adding mod_jk? Any workarounds? Brad: server.xml: className="org.apache.catalina.core.AprLifecycleListener" /> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleList ener" /> className="org.apache.catalina.storeconfig.StoreConfigLifecycleLis tener"/> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" /> appBase="/srv/tomcat/webapps/cvs.mydomain.lcl/docs" autoDeploy="true" deployOnStartup="true" unpackWARs="true" deployXML="false" /> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] W - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: default Tomcat 5.5 won't shutdown cleanly (Was: After adding mod_jk, tomcat won't shutdown cleanly)
Vanilla Tomcat (with the jdk1.4 compatibility jars added), and vanilla server.xml. Apache httpd isn't even started yet. I just installed a fresh copy of Tomcat direct from the tar file, and while it starts up, shutdown hangs. Brad Fenlason, Josh wrote: Are you using the native apr connector? , Josh. -Original Message- From: Brad O'Hearne [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 11:50 AM To: Tomcat Users List Subject: default Tomcat 5.5 won't shutdown cleanly (Was: After adding mod_jk, tomcat won't shutdown cleanly) I guess I have to alter my original assertion. Vanilla tomcat 5.5 isn't shutting down cleanly (default server.xml). Are there known causes for this? Anything in particular that I need to check? Brad Brad O'Hearne wrote: Ok, it appears I may have mod_jk running properly. However, now when I try to shutdown tomcat, I get the following: Using CATALINA_BASE: /opt/apache-tomcat-5.5.12 Using CATALINA_HOME: /opt/apache-tomcat-5.5.12 Using CATALINA_TMPDIR: /opt/apache-tomcat-5.5.12/temp Using JRE_HOME: /usr/java/j2sdk1.4.2_10 Created MBeanServer with ID: 1f436f5:1099d0fba63:-8000:cvs.cvs:1 But it never returns. It just sits there, indefinitely. The java process never quits, and is still hung out there. My erver.xml is below. Is there a known problem with shutdowns after adding mod_jk? Any workarounds? Brad: server.xml: className="org.apache.catalina.core.AprLifecycleListener" /> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleList ener" /> className="org.apache.catalina.storeconfig.StoreConfigLifecycleLis tener"/> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" /> appBase="/srv/tomcat/webapps/cvs.mydomain.lcl/docs" autoDeploy="true" deployOnStartup="true" unpackWARs="true" deployXML="false" /> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] W - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
default Tomcat 5.5 won't shutdown cleanly (Was: After adding mod_jk, tomcat won't shutdown cleanly)
I guess I have to alter my original assertion. Vanilla tomcat 5.5 isn't shutting down cleanly (default server.xml). Are there known causes for this? Anything in particular that I need to check? Brad Brad O'Hearne wrote: Ok, it appears I may have mod_jk running properly. However, now when I try to shutdown tomcat, I get the following: Using CATALINA_BASE: /opt/apache-tomcat-5.5.12 Using CATALINA_HOME: /opt/apache-tomcat-5.5.12 Using CATALINA_TMPDIR: /opt/apache-tomcat-5.5.12/temp Using JRE_HOME: /usr/java/j2sdk1.4.2_10 Created MBeanServer with ID: 1f436f5:1099d0fba63:-8000:cvs.cvs:1 But it never returns. It just sits there, indefinitely. The java process never quits, and is still hung out there. My erver.xml is below. Is there a known problem with shutdowns after adding mod_jk? Any workarounds? Brad: server.xml: className="org.apache.catalina.mbeans.ServerLifecycleListener" /> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleList ener" /> className="org.apache.catalina.storeconfig.StoreConfigLifecycleLis tener"/> value="30"/> appBase="/srv/tomcat/webapps/cvs.mydomain.lcl/docs" autoDeploy="true" deployOnStartup="true" unpackWARs="true" deployXML="false" /> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] W - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
After adding mod_jk, tomcat won't shutdown cleanly
Ok, it appears I may have mod_jk running properly. However, now when I try to shutdown tomcat, I get the following: Using CATALINA_BASE: /opt/apache-tomcat-5.5.12 Using CATALINA_HOME: /opt/apache-tomcat-5.5.12 Using CATALINA_TMPDIR: /opt/apache-tomcat-5.5.12/temp Using JRE_HOME: /usr/java/j2sdk1.4.2_10 Created MBeanServer with ID: 1f436f5:1099d0fba63:-8000:cvs.cvs:1 But it never returns. It just sits there, indefinitely. The java process never quits, and is still hung out there. My erver.xml is below. Is there a known problem with shutdowns after adding mod_jk? Any workarounds? Brad: server.xml: className="org.apache.catalina.mbeans.ServerLifecycleListener" /> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleList ener" /> className="org.apache.catalina.storeconfig.StoreConfigLifecycleLis tener"/> value="30"/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which direction: mod_jk or mod_proxy_ajp? (was: why use mod_jk?)
Josh, Thanks a lot for your answer. I am using Apache 2.2.x. Now onto my next question. Bill Barker suggested the httpd.conf / mod_proxy_ajp directive side of the equation. Doesn't there have to be a connector in tomcat's server.xml which will allow listening for the ajp protocol? Is there documentation on this somewhere? Brad On Feb 24, 2006, at 8:07 AM, Fenlason, Josh wrote: That depends if you want to use Apache 2.0.x, Apache 2.2.x, or some other web server (i.e. IIS). If you're planning on using Apache 2.2.x, mod_proxy_ajp is the way to go. For anything else, mod_jk is the way to go. , Josh. -Original Message----- From: Brad O'Hearne [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 9:02 AM To: Tomcat Users List Subject: Which direction: mod_jk or mod_proxy_ajp? (was: why use mod_jk?) I suppose this question deserved its own thread. Before I spend any more time trying to get this configured, I would like to know what is the best way to proceed: mod_jk or mod_proxy_ajp? Thanks, Brad On Feb 24, 2006, at 7:49 AM, Brad O'Hearne wrote: Jess, Thanks for the reply. Responses below: On Feb 24, 2006, at 6:51 AM, Jess Holle wrote: If you're using Apache 1.3.x or 2.0.x, mod_jk is pretty simple overall. No, you don't want to even try in-process stuff and, yes, if you have a firewall in between Apache and Tomcat that drops idle connections you should read carefully (this is covered by the docs). The only big complaint I have is that the mod_jk docs don't make it terribly clear (or didn't last I checked) exactly how to set jvmRoute in Tomcat and how extraordinarily critical this is when doing load balancing. The Tomcat docs don't make this terribly clear either -- apart from a comment in server.xml. Most everyone I know who tries mod_jk load balancing gets hung up on this one point unless/until I give them a detailed explanation. Apart from the lack of clear/obvious information on this in the mod_jk docs (which should include it considering most folk won't think to check both mod_jk and Tomcat docs), this is actually very simple as well, though. None of the configuration steps in and of itself are difficult. Building mod_jk is not difficult. Editing configuration files is not difficult. Its after you've put it all together, exactly as noted on a hodge-podge of Googled URLs, and it doesn't work, and one cryptic line in a log file, and the right connections not being made between apache and tomcat, which send you into hours of trial and error. With regards to your comments above, I didn't tangle with load balancing at all, and apache and tomcat reside on the same box, no firewall between them. Yes, you'd think this would be simple. I am looking forward to mod_proxy_ajp as it is supposed be a tiny bit faster. You say you are "looking forward to mod_proxy_ajp" -- does this mean its not available yet, or you just aren't using it yet? While I am glad to learn now of mod_proxy_ajp, I guess this kind of adds to my frustration a bit -- what is the way to go now and why: mod_proxy_ajp or mod_jk? Thanks for your help. Brad -- Jess Holle Brad O'Hearne wrote: mod_proxy_ajp? Yet another twist. Its just hard for me to believe that "how do I integrate tomcat and apache httpd?" is such a mystery / unknown. This seems like it would be question #1 on any Tomcat FAQ. So where can I found out more about mod_proxy_ajp. Is there a Tomcat resource which explains the configuration of it? Brad Bill Barker wrote: "Brad O'Hearne" <[EMAIL PROTECTED]> wrote in message news: [EMAIL PROTECTED] After wasting time trying to configure mod_jk, I thought I'd just wipe my mind free and just play dumb for a moment. If Apache can proxy requests using mod_proxy, what is the benefit of using mod_jk as an integration technique between httpd and tomcat, if integration is *not* in-process, which I understand is not recommended for Tomcat 5.5? Actually, in-process with mod_jk is only supported (and, I use the term lightly :) for TC 3.3.x. For any higher versions it doesn't work at all. You've managed to grasp the deep, dark plan of the Tomcat developers: It is expected that people will migrate to mod_proxy_ajp with Httpd 2.2+, and mod_jk is expected to move to supporting IIS/SunOne only (and, the later only if somebody steps up with interest :). Brad --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional co
Re: why use mod_jk?
Question below: On Feb 24, 2006, at 2:05 AM, Bill Barker wrote: "Brad O'Hearne" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] mod_proxy_ajp? Yet another twist. Its just hard for me to believe that "how do I integrate tomcat and apache httpd?" is such a mystery / unknown. This seems like it would be question #1 on any Tomcat FAQ. So where can I found out more about mod_proxy_ajp. Is there a Tomcat resource which explains the configuration of it? Nope, since it all under the Httpd project :). You can start with: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html, and then move on to http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html. The simplest configuration looks like: ProxyPass /myapp ajp://localhost:8009/myapp Ok, I understand what it is trying to do here. But I assume there is a connector that has to be loaded in Tomcat to enable listening for the ajp protocol on port 8009, no? Is there documentation about this anywhere? Brad Brad Bill Barker wrote: "Brad O'Hearne" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] After wasting time trying to configure mod_jk, I thought I'd just wipe my mind free and just play dumb for a moment. If Apache can proxy requests using mod_proxy, what is the benefit of using mod_jk as an integration technique between httpd and tomcat, if integration is *not* in- process, which I understand is not recommended for Tomcat 5.5? Actually, in-process with mod_jk is only supported (and, I use the term lightly :) for TC 3.3.x. For any higher versions it doesn't work at all. You've managed to grasp the deep, dark plan of the Tomcat developers: It is expected that people will migrate to mod_proxy_ajp with Httpd 2.2+, and mod_jk is expected to move to supporting IIS/SunOne only (and, the later only if somebody steps up with interest :). Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Which direction: mod_jk or mod_proxy_ajp? (was: why use mod_jk?)
I suppose this question deserved its own thread. Before I spend any more time trying to get this configured, I would like to know what is the best way to proceed: mod_jk or mod_proxy_ajp? Thanks, Brad On Feb 24, 2006, at 7:49 AM, Brad O'Hearne wrote: Jess, Thanks for the reply. Responses below: On Feb 24, 2006, at 6:51 AM, Jess Holle wrote: If you're using Apache 1.3.x or 2.0.x, mod_jk is pretty simple overall. No, you don't want to even try in-process stuff and, yes, if you have a firewall in between Apache and Tomcat that drops idle connections you should read carefully (this is covered by the docs). The only big complaint I have is that the mod_jk docs don't make it terribly clear (or didn't last I checked) exactly how to set jvmRoute in Tomcat and how extraordinarily critical this is when doing load balancing. The Tomcat docs don't make this terribly clear either -- apart from a comment in server.xml. Most everyone I know who tries mod_jk load balancing gets hung up on this one point unless/until I give them a detailed explanation. Apart from the lack of clear/obvious information on this in the mod_jk docs (which should include it considering most folk won't think to check both mod_jk and Tomcat docs), this is actually very simple as well, though. None of the configuration steps in and of itself are difficult. Building mod_jk is not difficult. Editing configuration files is not difficult. Its after you've put it all together, exactly as noted on a hodge-podge of Googled URLs, and it doesn't work, and one cryptic line in a log file, and the right connections not being made between apache and tomcat, which send you into hours of trial and error. With regards to your comments above, I didn't tangle with load balancing at all, and apache and tomcat reside on the same box, no firewall between them. Yes, you'd think this would be simple. I am looking forward to mod_proxy_ajp as it is supposed be a tiny bit faster. You say you are "looking forward to mod_proxy_ajp" -- does this mean its not available yet, or you just aren't using it yet? While I am glad to learn now of mod_proxy_ajp, I guess this kind of adds to my frustration a bit -- what is the way to go now and why: mod_proxy_ajp or mod_jk? Thanks for your help. Brad -- Jess Holle Brad O'Hearne wrote: mod_proxy_ajp? Yet another twist. Its just hard for me to believe that "how do I integrate tomcat and apache httpd?" is such a mystery / unknown. This seems like it would be question #1 on any Tomcat FAQ. So where can I found out more about mod_proxy_ajp. Is there a Tomcat resource which explains the configuration of it? Brad Bill Barker wrote: "Brad O'Hearne" <[EMAIL PROTECTED]> wrote in message news: [EMAIL PROTECTED] After wasting time trying to configure mod_jk, I thought I'd just wipe my mind free and just play dumb for a moment. If Apache can proxy requests using mod_proxy, what is the benefit of using mod_jk as an integration technique between httpd and tomcat, if integration is *not* in-process, which I understand is not recommended for Tomcat 5.5? Actually, in-process with mod_jk is only supported (and, I use the term lightly :) for TC 3.3.x. For any higher versions it doesn't work at all. You've managed to grasp the deep, dark plan of the Tomcat developers: It is expected that people will migrate to mod_proxy_ajp with Httpd 2.2+, and mod_jk is expected to move to supporting IIS/SunOne only (and, the later only if somebody steps up with interest :). Brad --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why use mod_jk?
Jess, Thanks for the reply. Responses below: On Feb 24, 2006, at 6:51 AM, Jess Holle wrote: If you're using Apache 1.3.x or 2.0.x, mod_jk is pretty simple overall. No, you don't want to even try in-process stuff and, yes, if you have a firewall in between Apache and Tomcat that drops idle connections you should read carefully (this is covered by the docs). The only big complaint I have is that the mod_jk docs don't make it terribly clear (or didn't last I checked) exactly how to set jvmRoute in Tomcat and how extraordinarily critical this is when doing load balancing. The Tomcat docs don't make this terribly clear either -- apart from a comment in server.xml. Most everyone I know who tries mod_jk load balancing gets hung up on this one point unless/until I give them a detailed explanation. Apart from the lack of clear/obvious information on this in the mod_jk docs (which should include it considering most folk won't think to check both mod_jk and Tomcat docs), this is actually very simple as well, though. None of the configuration steps in and of itself are difficult. Building mod_jk is not difficult. Editing configuration files is not difficult. Its after you've put it all together, exactly as noted on a hodge-podge of Googled URLs, and it doesn't work, and one cryptic line in a log file, and the right connections not being made between apache and tomcat, which send you into hours of trial and error. With regards to your comments above, I didn't tangle with load balancing at all, and apache and tomcat reside on the same box, no firewall between them. Yes, you'd think this would be simple. I am looking forward to mod_proxy_ajp as it is supposed be a tiny bit faster. You say you are "looking forward to mod_proxy_ajp" -- does this mean its not available yet, or you just aren't using it yet? While I am glad to learn now of mod_proxy_ajp, I guess this kind of adds to my frustration a bit -- what is the way to go now and why: mod_proxy_ajp or mod_jk? Thanks for your help. Brad -- Jess Holle Brad O'Hearne wrote: mod_proxy_ajp? Yet another twist. Its just hard for me to believe that "how do I integrate tomcat and apache httpd?" is such a mystery / unknown. This seems like it would be question #1 on any Tomcat FAQ. So where can I found out more about mod_proxy_ajp. Is there a Tomcat resource which explains the configuration of it? Brad Bill Barker wrote: "Brad O'Hearne" <[EMAIL PROTECTED]> wrote in message news: [EMAIL PROTECTED] After wasting time trying to configure mod_jk, I thought I'd just wipe my mind free and just play dumb for a moment. If Apache can proxy requests using mod_proxy, what is the benefit of using mod_jk as an integration technique between httpd and tomcat, if integration is *not* in-process, which I understand is not recommended for Tomcat 5.5? Actually, in-process with mod_jk is only supported (and, I use the term lightly :) for TC 3.3.x. For any higher versions it doesn't work at all. You've managed to grasp the deep, dark plan of the Tomcat developers: It is expected that people will migrate to mod_proxy_ajp with Httpd 2.2+, and mod_jk is expected to move to supporting IIS/SunOne only (and, the later only if somebody steps up with interest :). Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why use mod_jk?
mod_proxy_ajp? Yet another twist. Its just hard for me to believe that "how do I integrate tomcat and apache httpd?" is such a mystery / unknown. This seems like it would be question #1 on any Tomcat FAQ. So where can I found out more about mod_proxy_ajp. Is there a Tomcat resource which explains the configuration of it? Brad Bill Barker wrote: "Brad O'Hearne" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] After wasting time trying to configure mod_jk, I thought I'd just wipe my mind free and just play dumb for a moment. If Apache can proxy requests using mod_proxy, what is the benefit of using mod_jk as an integration technique between httpd and tomcat, if integration is *not* in-process, which I understand is not recommended for Tomcat 5.5? Actually, in-process with mod_jk is only supported (and, I use the term lightly :) for TC 3.3.x. For any higher versions it doesn't work at all. You've managed to grasp the deep, dark plan of the Tomcat developers: It is expected that people will migrate to mod_proxy_ajp with Httpd 2.2+, and mod_jk is expected to move to supporting IIS/SunOne only (and, the later only if somebody steps up with interest :). Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuring mod_jk, and the notion of "webapps"
Vanessa,
Thanks for the resource. However, as I've been told, in-process/JNI
is/will be deprecated and isn't recommended with Tomcat 5.5 and Apache
2.x, and it appears that this particular configuration is trying to do
that. Perhaps I've heard wrong. But I guess the confusion underscores
the lack of documentation surrounding this area of Tomcat.
Brad
Vanessa Campos wrote:
Brad,
I found a good how-to that helped me put mod_jk to work.
www.howtoforge.com/apache2_tomcat5_mod_jk
It's very simple, and it works.
--- Brad O'Hearne <[EMAIL PROTECTED]> escreveu:
I have been having trouble getting mod_jk to work. After having
Googled
and read various information on configuring mod_jk (that's the
first
problem -- we need good documentation without having to Google), I
settled on this link which is a pretty good HOWTO:
http://www.meritonlinesystems.com/docs/apache_tomcat_redhat.html
The problem is, once I got everything setup, things didn't work as
expected. Before going into a long diatribe about all the potential
issues, what I checked, etc., I want to inquire about the notion of
this
document's advice about your "webapp", as mentioned in http.conf
and
server.xml configuration, and as shown in step 5 of this HOWTO, in
directory creation. The document instructs you to create the
appropriate
application directories as follows:
mkdir /home/tomcat/webapps
mkdir /home/tomcat/webapps/{YOUR_DOMAIN}
mkdir /home/tomcat/webapps/{YOUR_DOMAIN}/logs
mkdir /home/tomcat/webapps/{YOUR_DOMAIN}/{YOUR_APPLICATION}
mkdir /home/tomcat/webapps/{YOUR_DOMAIN}/{YOUR_APPLICATION}/WEB-INF
mkdir
/home/tomcat/webapps/{YOUR_DOMAIN}/{YOUR_APPLICATION}/WEB-INF/classes
In the httpd.conf, the virtualHost directive setup recommended is
as
follows:
ServerAdmin [EMAIL PROTECTED]
ServerName {YOUR_DOMAIN}
DocumentRoot /home/tomcat/webapps/{YOUR_DOMAIN}/{YOUR_APPLICATION}
ErrorLog /home/tomcat/webapps/{YOUR_DOMAIN}/logs/error_log
CustomLog /home/tomcat/webapps/{YOUR_DOMAIN}/logs/access_log
common
JkMount /*.jsp wrkr
JkMount /servlet/* wrkr
# Deny direct access to WEB-INF
AllowOverride None
deny from all
and in configuring the Tomcat context, the configuration
recommended is as follows:
I don't get the {YOUR_APPLICATION} part of this. Basically, I have
a domain, and from it, I will be serving the contents of one or
more web applications.
These web applications of course are WAR files. The directory
creation instructions look as if you would be creating the exploded
WAR structure manually, and the virtual
host configuration and context configuration appear to be
addressing a particular WAR. This doesn't make sense to me. All I
want to do is forward all requests with a particular
prefix to Tomcat, regardless of the web application, and based upon
the prefix, tomcat will determine which web application will
respond (just as if you were using Tomcat without
Apache httpd).
Can someone give me a heads up on how to configure this? Thanks!
Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Vanessa Campos
[EMAIL PROTECTED]
ICQ 35381281
"Efetivamente, para o homem, enquanto homem, nada tem valor a menos que ele possa
executa-lo com entusiasmo" Max Weber
___
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
why use mod_jk?
After wasting time trying to configure mod_jk, I thought I'd just wipe my mind free and just play dumb for a moment. If Apache can proxy requests using mod_proxy, what is the benefit of using mod_jk as an integration technique between httpd and tomcat, if integration is *not* in-process, which I understand is not recommended for Tomcat 5.5? Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat documentation
Suppose I wanted to completely rewrite (or write) 100% of the Tomcat documentation. Other than reading source code, are there any other resources (design docs, diagrams, etc.) available to use as reference or is this information just held inside the heads of developers? Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The bottomless pit of mod_jk
Pardon any show of frustration here, but I wanted to know if there is any real definitive reference on configuring mod_jk. I've burned 3 full days Googling, endless configuration file editing, tailing logs, etc., and there just seems to be problem after problem. I've worked off of several apparently comprehensive HOW-TOs that are out there, and each one seems to have their set of problems -- either they aren't current to the latest versions of httpd and/or tomcat, or there are other issues present. Is there an official Tomcat resource which tells how to configure mod_jk on the most recent version of Tomcat and Httpd? Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
where can I find server.xml documentation?
Where can I find comprehensive documentation on the contents of the server.xml file? Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Configuring mod_jk, and the notion of "webapps"
I have been having trouble getting mod_jk to work. After having Googled
and read various information on configuring mod_jk (that's the first
problem -- we need good documentation without having to Google), I
settled on this link which is a pretty good HOWTO:
http://www.meritonlinesystems.com/docs/apache_tomcat_redhat.html
The problem is, once I got everything setup, things didn't work as
expected. Before going into a long diatribe about all the potential
issues, what I checked, etc., I want to inquire about the notion of this
document's advice about your "webapp", as mentioned in http.conf and
server.xml configuration, and as shown in step 5 of this HOWTO, in
directory creation. The document instructs you to create the appropriate
application directories as follows:
mkdir /home/tomcat/webapps
mkdir /home/tomcat/webapps/{YOUR_DOMAIN}
mkdir /home/tomcat/webapps/{YOUR_DOMAIN}/logs
mkdir /home/tomcat/webapps/{YOUR_DOMAIN}/{YOUR_APPLICATION}
mkdir /home/tomcat/webapps/{YOUR_DOMAIN}/{YOUR_APPLICATION}/WEB-INF
mkdir /home/tomcat/webapps/{YOUR_DOMAIN}/{YOUR_APPLICATION}/WEB-INF/classes
In the httpd.conf, the virtualHost directive setup recommended is as
follows:
ServerAdmin [EMAIL PROTECTED]
ServerName {YOUR_DOMAIN}
DocumentRoot /home/tomcat/webapps/{YOUR_DOMAIN}/{YOUR_APPLICATION}
ErrorLog /home/tomcat/webapps/{YOUR_DOMAIN}/logs/error_log
CustomLog /home/tomcat/webapps/{YOUR_DOMAIN}/logs/access_log common
JkMount /*.jsp wrkr
JkMount /servlet/* wrkr
# Deny direct access to WEB-INF
AllowOverride None
deny from all
and in configuring the Tomcat context, the configuration recommended is as
follows:
I don't get the {YOUR_APPLICATION} part of this. Basically, I have a domain, and from it, I will be serving the contents of one or more web applications.
These web applications of course are WAR files. The directory creation instructions look as if you would be creating the exploded WAR structure manually, and the virtual
host configuration and context configuration appear to be addressing a
particular WAR. This doesn't make sense to me. All I want to do is forward all
requests with a particular
prefix to Tomcat, regardless of the web application, and based upon the prefix,
tomcat will determine which web application will respond (just as if you were
using Tomcat without
Apache httpd).
Can someone give me a heads up on how to configure this? Thanks!
Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does mod_jk work with Tomcat 5.5?
Francis, That's just it though. The file *is* there, named exactly right, is has the same permissions and is owned by the same owner as all the other modules. Is there something else, perhaps another file, that its looking for? Brad Francis Galiegue wrote: 2006/2/21, Brad O'Hearne <[EMAIL PROTECTED]>: [...] mod_jk does work with tomcat5, we've been using it here for at least 8 months. Anyway, this error: Syntax error on line 207 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/jakarta-tomcat-connectors-jk-1.2.14-linux-sles9-x 86_64-worker.so into server: /etc/httpd/modules/jakarta-tomcat-connectors-jk-1.2 .14-linux-sles9-x86_64-worker.so: cannot open shared object file: ---> No such file or directory <--- ... just tells what's wrong: the file is not there. It's probably installed somewhere else, just locate it and update the path. -- Francis Galiegue, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] One2team - 12bis rue de la Pierre Levée, 75011 Paris - 0143381980 "When it comes to performance, weight is everything" - Tiff Needell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Does mod_jk work with Tomcat 5.5?
I downloaded the mod_jk binary for my distribution, and the filename was: jakarta-tomcat-connectors-jk-1.2.14-linux-sles9-x86_64-worker.so I placed the file in the httpd modules subdirectory, I then added the load directive in my httpd.conf file using the following line: LoadModule mod_jk modules/jakarta-tomcat-connectors-jk-1.2.14-linux-sles9-x86_64-worker.so When I restarted apache, I received the following output: Starting httpd: Syntax error on line 207 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/jakarta-tomcat-connectors-jk-1.2.14-linux-sles9-x 86_64-worker.so into server: /etc/httpd/modules/jakarta-tomcat-connectors-jk-1.2 .14-linux-sles9-x86_64-worker.so: cannot open shared object file: No such file o r directory Any ideas? Does mod_jk work with Tomcat 5.5? Thanks Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuring mod_jk with apache / tomcat
Bump. Does anyone have any idea on these? I need to get Tomcat configured with apache. Thanks! Brad On Feb 16, 2006, at 8:00 PM, Brad O'Hearne wrote: I am trying to get the Tomcat connector configured to connect tomcat and apache and I have two questions: 1) I downloaded the binary distribution for linux, and the filename was: jakarta-tomcat-connectors-jk-1.2.14-linux-sles9-x86_64- worker.so. Is this supposed to be mod_jk? 2) What kind of workers.properties should I have? There is no sample in the http/conf or tomcat/conf directory. Thanks, Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
configuring mod_jk with apache / tomcat
I am trying to get the Tomcat connector configured to connect tomcat and apache and I have two questions: 1) I downloaded the binary distribution for linux, and the filename was: jakarta-tomcat-connectors-jk-1.2.14-linux-sles9-x86_64-worker.so. Is this supposed to be mod_jk? 2) What kind of workers.properties should I have? There is no sample in the http/conf or tomcat/conf directory. Thanks, Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: Re: JAASRealm, Tomcat 5.5 getting HTTP error page 403 Access denied
Carsten,
This is a confirmed bug -- I've just spent a couple days wrestling with
it myself. It is a logged bug and fixed on the trunk.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37044
Brad
Carsten Schiller wrote:
Jukka Uusisalo <[EMAIL PROTECTED]> wrote on 20.10.2005
17:37:31:
Carsten Schiller wrote:
Hello!
We are trying to implement a login/security environment using Tomcat
5.5's
JAASRealm and Struts as a MVC-Framework.
After Login ,which fails with error "HTTP Status 403 - Access to the
requested ressource has been denied", we can navigate manually to our
output.jsp and use
...
<%= request.getUserPrincipal %> ,
...
<%= request.isUserInRole("administrator") %>
...
Admin present!
These return correct username, (true) for isUserInRole, and the logic
tag
also works...
BUT
Our problem is: We protected *.do in our web.xml to be only accessible
by
users in role "administrator", which fails as described above.
Why does the login fail, but we still get a valid Subject with
Principals,
and can access the roles on the output.jsp?
We are stuck now for over a week, reading tutorials, asking google,
but
with no success... Any Ideas would be appreciated!
Hi,
I think resources that does not require authentication, like your
output.jsp, should return null from request.getUserPrincipal().
But what kind of JAAS loginmodule you have? Does that login module
work correctly?
- Jukka -
Hi Jukka,
what you mention is the same we thought and so we were wondering how it
could be, that our authentication resulted in an "HTTP 403" error and
checking the role on our output.jsp returned the correct role of the user.
The tag as well as <%=
request.getUserPrincipal()%> returned the needed informations (username
and role) and not as expected (AFTER a failed login) "null".
Our JAAS login-module is selfwritten and we debugged it on every little
code.
I append it for inspection...
We tested the authentication with a JNDIRealm, which works fine and there
we don't get "HTTP 403" errors for correct username/password combinations
(were using the same LDAP server).
Greetings Carsten
SimpleLoginModule.java
[code]
import java.util.Map;
import java.util.Set;
import javax.naming.NamingEnumeration;
import javax.naming.directory.Attribute;
import javax.naming.directory.Attributes;
import javax.naming.directory.DirContext;
import javax.security.auth.Subject;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.spi.LoginModule;
import javax.security.auth.login.*;
import java.security.Principal;
public class SimpleLoginModule implements LoginModule
{
private static final int NOT_AUTHENTICATED = 0;
private static final int AUTHENTICATED = 1;
private static final int AUTHENTICATE_COMMITTED = 2;
private static final String SERVERURL="vm-kallisto-04";
private static final String DOMAIN="dc=ikom,dc=de";
protected String username = null;
protected String password = null;
protected int state;
protected Principal sp;
protected Subject sub;
protected DirContext ctx;
protected String userDN;
protected GroupPrincipal einRollenPrincipal;
protected CallbackHandler cbh = null;
public boolean abort()
{
System.out.println("Login.abort()");
sub = null;
sp = null;
state = NOT_AUTHENTICATED;
return true;
}
public boolean commit()
{
System.out.println("Login.commit()");
if (state < AUTHENTICATED) {
return false;
}
if (sp == null) {
return false;
}
try
{
Attributes myAttributes = ctx.getAttributes(userDN,new
String[]{"cn","authorizationRole"});
Attribute user = myAttributes.get("cn");
Attribute rollen = myAttributes.get("authorizationRole");
System.out.println("LDAPuser: "+user);
NamingEnumeration alleWerte = rollen.getAll();
if (!sub.getPrincipals().contains(sp))
{
sub.getPrincipals().add(sp);
}
while (alleWerte.hasMore())
{
String eineRolle = alleWerte.next().toString();
sub.getPrincipals().add(new GroupPrincipal(eineRolle));
System.out.println("Fuege GROUPPrincipal hinzu: " +
eineRolle);
}
}
catch (Exception e)
{
//System.out.println("Fehler bei Commit: "+e);
return false;
}
state = AUTHENTICATE_COMMITTED;
System.out.println("Login.commit()::true");
return true;
}
public void initialize(Subject s,CallbackHandler ch, Map shared, Map
options)
{
System.out.println("Login.initialize()");
state = NOT_AUTHENTICATED;
sub = s;
System.out.println("Subject-Name: "+ sub.toString());
this.cbh = ch;
}
public boolean login() throws LoginException {
System.out.println("Login.
Re: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization
Chuck, The JAASRealm takes whatever user principal you have and the role principal you have added to the subject, and creates a new GenericPrincipal class, containing both your user principal and your role principal. I do not think it populates your custom user principal with roles. The problem is in the request.getUserPrincipal () method, which pulls the user principal out of the wrapper. The hasRole wants a GenericPrincipal containing the roles. So since the method is getting your custom user principal, not the wrapper that the realm has created, you have to populate your custom user principal with the roles. Btw, it appears that this was already logged as bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=37044 B On Oct 20, 2005, at 9:25 PM, Caldarale, Charles R wrote: From: Brad O'Hearne [mailto:[EMAIL PROTECTED] Subject: Re: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization So in the JAAS login module, what you would have to do is instantiate a user principal that is a subclass of GenericPrinicipal for your user principal, then add your role principals to that user principal, and then add the user principal and all the role principals to the subject. No, you don't need to go through those steps yourself, since the JAASRealm will do it for you. What an ugly hack though. I guess I don't see the ugliness - that's what subclassing is for. Would be nice if the behavior were actually documented... - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization
Right, but I think you are missing what I am saying. The hasRole() method takes two parameters: a Principal (which is going to be the custom user principal returned from the request.getUserPrincipal() method), and a String role name. Roles aren't being passed to the hasRole method, only the user principal and the role that it is looking for. In the JAAS login module, when you authenticate you add your user principal and role principals separately to the subject. The user principal does not contain roles. Its the realm that combines those after pulling them from the subject after the fact. So in the JAAS login module, what you would have to do is instantiate a user principal that is a subclass of GenericPrinicipal for your user principal, then add your role principals to that user principal, and then add the user principal and all the role principals to the subject. And then, of course, the same thing would happen all over again in the realm code after exiting. Yes that could be done. What an ugly hack though. Depending on what the dev list comes back with, I may give it a try. It explains, however, the behavior I had in Tomcat 5.0.28. In 5.0.28, I couldn't get my user principal out of the request -- instead, the request.getUserPrincipal() method returned a GenericPrincipal. However, role authorization worked. So It really looks probably that someone added code to the getUserPrincipal() method to return the custom user principal, and broke role authorization. Alasa regression test that escaped... :-) B On Oct 20, 2005, at 9:09 PM, Caldarale, Charles R wrote: From: Brad O'Hearne [mailto:[EMAIL PROTECTED] Subject: Re: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization If you wanted to try to game the authorization, you'd have to take your role principal, shove it into the user principal, then let the realm shove both of those again into another GenericPrincpal that wrapped it. No, that's wrappering. What I suggested was declaring your custom principal as a subclass of GenericPrincipal so the JAASRealm code could use it directly. I thought about that too, but I don't know enough about the other source code to know if it is safe and would affect things elsewhere in code. The rules of subclassing make this perfectly safe. The rest of the code may be using your object, but the other code can only refer to it via the methods declared in the superclass GenericPrincipal; whatever customization you've made is invisible to the rest of Tomcat. You would also have the freedom of overriding the GenericPrincipal methods to suit your needs. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization
Charles, I addressed this at the bottom of my email. It might be a hack that would work, but you would effectively be duplicating what the JAASRealm is doing already. The JAASRealm takes the user principal and role principal, and shoves them into a GenericPrinicipal. If you wanted to try to game the authorization, you'd have to take your role principal, shove it into the user principal, then let the realm shove both of those again into another GenericPrincpal that wrapped it. Then it would get your custom user principal, and the authorization might work. I thought about that too, but I don't know enough about the other source code to know if it is safe and would affect things elsewhere in code. It is clear from these methods that assumptions are being made based on class types. Such a hack would almost certainly be broken if any changes were made to this part of the code. B Caldarale, Charles R wrote: From: Brad O'Hearne [mailto:[EMAIL PROTECTED] Subject: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization When this statement executes, principal is not a GenericPrincipal, by merits of the request's getUserPrincipal() method executed prior to calling this method -- it is instead a custom user principal. What happens if you have your custom principal extend GenericPrincipal? It appears that all the interesting fields are marked as protected, so you should be able to set them in a subclass. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization
All,
I have discovered a bug in role authorization when using a JAASRealm and
custom user / role principals. In a nutshell, successful authentication in
the JAASRealm over a custom JAAS login module results in the JAASRealm
pulling the user principal and role principals out of the authenticated
subject and wrapping them inside a GenericPrincipal object. The generic
principle object is then stored in the request. Then, when permissions are
being checked in RealmBase.hasResourcePermission(), the following line of
code is executed to retrieve the user principal:
Principal principal = request.getUserPrincipal();
This method didn't return the wrapping generic principle, it returned my
custom user principle. The code for the requests getUserPrincipal() method is
as follows:
public Principal getUserPrincipal() {
if (userPrincipal instanceof GenericPrincipal) {
return ((GenericPrincipal) userPrincipal).getUserPrincipal();
} else {
return (userPrincipal);
}
}
Everything looks great so far, until you get to the logic which actually
checks the permissions. The RealmBase.hasRole() method starts with this block
of code (with an interesting opening comment):
// Should be overriten in JAASRealm - to avoid pretty inefficient
conversions
if ((principal == null) || (role == null) ||
!(principal instanceof GenericPrincipal))
return (false);
When this statement executes, principal is not a GenericPrincipal, by merits
of the request's getUserPrincipal() method executed prior to calling this
method -- it is instead a custom user principal. This causes the third part
of the if condition to be true, causing the method to return false, and the
method to fail, and authorization to fail. So in other words, whenever a
custom principal is used, role authorization should be failing, and since
this is in RealmBase, not the JAASRealm subclass, I am assuming that anyone
with a custom principal isn't able to authorize any roles properly.
The quick response might be to just use a GenericPrincipal type as your custom
principle. But this doesn't make sense either, because the hasRole method is
seeking the roles within the GenericPrincpal object (the user principal)
which must contain all the roles. This is what is done by the Realm code
already. The problem is that the hasRole method needs the GenericPrincipal
wrapper that contains the roles, NOT the custom user principal which does not
contain the roles.
It would be great if I am missing something But if not, I don't know if where
you want to consider the culprit for the bug, but it is certainly a bug, and
it breaks authorization. Please let me know what the options are for getting
this bug fixed, as it prevents container managed security in Tomcat using
JAAS.
Thanks,
Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.12 -- Roles being "lost" and causing authorization to fail
Hey all,
I just got a JAASRealm working in Tomcat, successfully authenticating against
my loging module. In my login module, I am successfully storing a role
principal "manager" inside the authenticated subject, which Tomcat logging
confirms. Immediately after authentication, Tomcat then tries to authorize
the request to forward to the expected URL, which is protected by container
managed security (i.e. web.xml) and allowing access to role user "manager".
The problem is that even though I am successfully storing the role principal
for the manager role in my subject, Tomcat's RealmBase is not finding the
role, and authorization is failing, hence the request errors out. The log is
below, can anyone help me out with why this is failing?
Thanks,
Brad
20-10 13:59:06,322 DEBUG (JAASRealm.java:authenticate:393) -JAAS LoginContext
created for username "brado"
20-10 13:59:06,324 DEBUG (JAASRealm.java:createPrincipal:476) -Checking
Principal "Principal:
name=brado" [com.redbarnsoftware.web.security.UserPrincipal]
20-10 13:59:06,325 DEBUG (JAASRealm.java:createPrincipal:482) -Principal
"brado" is a valid user class. We will use this as the user Principal.
20-10 13:59:06,326 DEBUG (JAASRealm.java:createPrincipal:476) -Checking
Principal "Principal:
name=manager" [com.redbarnsoftware.web.security.RolePrincipal]
20-10 13:59:06,327 DEBUG (JAASRealm.java:createPrincipal:489) -Adding role
Principal "manager" to this user Principal's roles
20-10 13:59:06,341 DEBUG (JAASRealm.java:authenticate:402) -Username "brado"
successfully authenticated as Principal "{1}" -- Subject was created too
20-10 13:59:06,358 DEBUG (CoyoteAdapter.java:parseSessionCookiesId:410) -
Requested cookie session id is 43C9C12A1726C5075DD45209A3967014
20-10 13:59:06,359 DEBUG (SingleSignOn.java:invoke:342) -Process request for
'/iocaine/'
20-10 13:59:06,360 DEBUG (SingleSignOn.java:invoke:353) - Checking for SSO
cookie
20-10 13:59:06,361 DEBUG (SingleSignOn.java:invoke:373) - Checking for cached
principal for 91F06522EDD456D4AD2B0269570839A1
20-10 13:59:06,368 DEBUG (SingleSignOn.java:invoke:388) - No cached principal
found, erasing SSO cookie
20-10 13:59:06,369 DEBUG (RealmBase.java:findSecurityConstraints:461) -
Checking constraint 'SecurityConstraint[iocaine]' against
GET //WEB-INF/jsp/index.jsp --> true
20-10 13:59:06,370 DEBUG (RealmBase.java:findSecurityConstraints:505) -
Checking constraint 'SecurityConstraint[iocaine]' against
GET //WEB-INF/jsp/index.jsp --> true
20-10 13:59:06,371 DEBUG (RealmBase.java:findSecurityConstraints:571) -
Checking constraint 'SecurityConstraint[iocaine]' against
GET //WEB-INF/jsp/index.jsp --> true
20-10 13:59:06,372 DEBUG (RealmBase.java:findSecurityConstraints:628) -
Checking constraint 'SecurityConstraint[iocaine]' against
GET //WEB-INF/jsp/index.jsp --> true
20-10 13:59:06,373 DEBUG (RealmBase.java:hasUserDataPermission:847) - User
data constraint has no restrictions
20-10 13:59:06,680 DEBUG (SingleSignOn.java:register:576) -Registering sso id
'1F6A37C1E95F8026BB25A6420E6B6B3A' for user 'brado' with auth type 'FORM'
20-10 13:59:06,698 DEBUG (SingleSignOn.java:associate:431) -Associate sso id
1F6A37C1E95F8026BB25A6420E6B6B3A with session
StandardSession[43C9C12A1726C5075DD45209A3967014]
20-10 13:59:06,703 DEBUG (RealmBase.java:hasResourcePermission:737) -
Checking roles Principal: name=brado
20-10 13:59:06,704 DEBUG (RealmBase.java:hasResourcePermission:766) -No role
found: manager
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.12 common/lib jars and classpath
I just configured a JAASRealm and a login module for it that authenticates users. I've gotten that to work just fine. But in the process I discovered something very strange. My loging module relies on mail.jar, the JavaMail API. I put my login module and its dependency jars into the common/lib directory to be loaded there, but I was getting NoSuchProviderException when trying to create a store using the "imap" protocol. I know for a fact my mail.jar was being loaded, because Tomcat found and executed classes successfully which were contained within the mail.jar. After spending hours with logs and API docs, I finally just put mail.jar on Tomcat's classpath, and it resolved the problem. Stranger still, all worked fine without putting mail.jar in the classpath in Tomcat 5.0.28. Can anyone shed light on why putting this Jar on the literal Tomcat classpath would have a different effect than putting jars into common/lib? I am guessing that this has something to do with other resources (property files and the like) which might be contained in the jar. The reason this is a concern for me, is that it leads me to believe that there's no point in placing jars into any of the directories governed by Tomcat's classloader hierarchy, but rather that I ought to place all jars on the classpath? Help! I need to get to the bottom of this problem! Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAASRealm, Tomcat 5.5 getting HTTP error page 403 Access denied
I'm presently waist deep in my own JAASRealm / JAAS login module /
single signon implementation myself, so I'm sorry I can't answer your
question directly at the moment. But after I'm through this, I'm
going to put together a FAQ and examples and put them up on a
website. JAAS authentication and single signon is too important for
there to be confusion surrounding it. Hopefully next week I'll be
able to do this.
Brad
On Oct 20, 2005, at 8:37 AM, Jukka Uusisalo wrote:
Carsten Schiller wrote:
Hello!
We are trying to implement a login/security environment using
Tomcat 5.5's JAASRealm and Struts as a MVC-Framework.
After Login ,which fails with error "HTTP Status 403 - Access to
the requested ressource has been denied", we can navigate manually
to our output.jsp and use ...
<%= request.getUserPrincipal %> , ...
<%= request.isUserInRole("administrator") %> ...
Admin present!
These return correct username, (true) for isUserInRole, and the
logic tag also works... BUT
Our problem is: We protected *.do in our web.xml to be only
accessible by users in role "administrator", which fails as
described above. Why does the login fail, but we still get a valid
Subject with Principals, and can access the roles on the output.jsp?
We are stuck now for over a week, reading tutorials, asking
google, but with no success... Any Ideas would be appreciated!
Hi,
I think resources that does not require authentication, like your
output.jsp, should return null from request.getUserPrincipal().
But what kind of JAAS loginmodule you have? Does that login module
work correctly?
- Jukka -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it even possible to retrieve a custom user principal? (Was: Tomcat user principal)
Mark,
Thanks so much for your help. That is very enlightening, and I'll
consider doing the same, depending on whether I get a response about
this from my post on the Tomcat dev mailing list. One complication of
mine is that I've implemented single-signon, and need that behavior as
well. I have a couple of responses (and one important question) below.
Mark Benussi wrote:
Brad,
From my understanding of j_security_check (Which I used to use) it
integrated seamlessly with JAAS. However:
1) You will not be able to get at the Principal to place in the session if
you let Tomcat do the work. It will still fail in the way it is doing at the
moment i.e. JAAS works but the request.getUserPrincipal() is not your class
and its associated Roles.
Ok, this is consistent with the behavior I am seeing. JAAS is working on
my end, but I can't get at my user principal at all. This seems very
bizarre to me. It defeats a major purpose of implementing (and then
being required to specify in the server.xml's realm configuration) a
custom user principal. More than that, it would be weird to have lack of
complete support of JAAS, which is *the* authentication/authorization
API for the Java platform, be a security deal-killer for using Tomcat.
2) The j_security_check is a very basic validation. It doesn't really help
if you want to let them know that the user name was ok but the password was
wrong or that the user_name doesn't exists, which is why I write a custom
call to JAAS via the LoginContext. See
if (le instanceof UnknownUserNameException) {
throw (UnknownUserNameException) le;
} else if (le instanceof UserPasswordException) {
throw (UserPasswordException) le;
} else {
throw new SystemException(le);
}
I am following that you are performing your own authentication as the result of a post from your login form. I also see that you are putting the subject into the session. I presume this is so you can retrieve not only your user principal, but role principals as well for authorization. Correct me if I am wrong, but doesn't going this route prevent you from using *any* container-managed security?
Thanks again for your help. If you could answer this one last question, that
would be great!
Brad
I get a bit scared of making these sweeping statements as there are people
on this list that know infinitely more than me but myself and people like
Wendy Smoak went through this a while back and when I published my thoughts
I didn't get any grumbles.
Hell maybe Apache have reworked this.
-Original Message-
From: Brad O'Hearne [mailto:[EMAIL PROTECTED]
Sent: 18 October 2005 15:31
To: Tomcat Users List
Subject: Re: Is it even possible to retrieve a custom user principal? (Was:
Tomcat user principal)
Mark,
Thanks for the response. In the code below, are you manually calling
JAAS, rather than via the j_security_check mechanism? The proper way
to access the authentication mechanism in Tomcat is to post to
j_security_check from a login form -- I wasn't sure from your post
below whether you were referring to this or to executing the below
code within a servlet.
In my case, I'm JAAS is being invoked as a result of posting to
j_security_check. This is why I'm confused as to the "place the JAAS
subject in the session" part of it. I could just be missing the boat,
but I do not see that I have access to the session in my JAAS login
module. If you know of a way to access the session from within a JAAS
login module, that is the code I need to see. I should have been more
clear about this before.
Thanks for your help Mark.
Brad
On Oct 18, 2005, at 1:30 AM, Mark Benussi wrote:
Hate publishing my code.
I have a struts form that takes the user name and password.
// Create a new CallbackHandler
JAASCallbackHandler callbackHandler = new JAASCallbackHandler
("username",
"password");
Subject jaasSubject = null;
LoginContext context = null;
try {
context = new LoginContext("IBTJAAS", callbackHandler);
context.login();
// Retrieve the authenticated subject
jaasSubject = context.getSubject();
} catch (LoginException le) {
if (le instanceof UnknownUserNameException) {
throw (UnknownUserNameException) le;
} else if (le instanceof UserPasswordException) {
throw (UserPasswordException) le;
} else {
throw new SystemException(le);
}
}
// Now place the JAAS subject in the session.
-Original Message-
From: Brad O'Hearne [mailto:[EMAIL PROTECTED]
Sent: 17 October 2005 23:06
To: Tomcat Users List
Subject: Re: Is it even possible to retrieve a custom user
principal? (Was:
Tomcat user principal)
Mark,
Thanks a ton for the reply. I almost want to reply with "you're
kidding,
right?", as I am kind of speechless that using JAAS (which I am), the
Java platform's st
Re: Is it even possible to retrieve a custom user principal? (Was: Tomcat user principal)
Mark,
Thanks for the response. In the code below, are you manually calling
JAAS, rather than via the j_security_check mechanism? The proper way
to access the authentication mechanism in Tomcat is to post to
j_security_check from a login form -- I wasn't sure from your post
below whether you were referring to this or to executing the below
code within a servlet.
In my case, I'm JAAS is being invoked as a result of posting to
j_security_check. This is why I'm confused as to the "place the JAAS
subject in the session" part of it. I could just be missing the boat,
but I do not see that I have access to the session in my JAAS login
module. If you know of a way to access the session from within a JAAS
login module, that is the code I need to see. I should have been more
clear about this before.
Thanks for your help Mark.
Brad
On Oct 18, 2005, at 1:30 AM, Mark Benussi wrote:
Hate publishing my code.
I have a struts form that takes the user name and password.
// Create a new CallbackHandler
JAASCallbackHandler callbackHandler = new JAASCallbackHandler
("username",
"password");
Subject jaasSubject = null;
LoginContext context = null;
try {
context = new LoginContext("IBTJAAS", callbackHandler);
context.login();
// Retrieve the authenticated subject
jaasSubject = context.getSubject();
} catch (LoginException le) {
if (le instanceof UnknownUserNameException) {
throw (UnknownUserNameException) le;
} else if (le instanceof UserPasswordException) {
throw (UserPasswordException) le;
} else {
throw new SystemException(le);
}
}
// Now place the JAAS subject in the session.
-Original Message-
From: Brad O'Hearne [mailto:[EMAIL PROTECTED]
Sent: 17 October 2005 23:06
To: Tomcat Users List
Subject: Re: Is it even possible to retrieve a custom user
principal? (Was:
Tomcat user principal)
Mark,
Thanks a ton for the reply. I almost want to reply with "you're
kidding,
right?", as I am kind of speechless that using JAAS (which I am), the
Java platform's standard authentication/authorization API, doesn't
allow
one to use a custom principal. It seems like a major hole in Tomcat
security flexibility. I suppose I'll float on over the developer
list to
find out more about whether this is a planned change or not, and how
much trouble it would be to add it.
As for your workaround, where can I set the session? My JAAS login
module doesn't have access to the session, I don't believe, which is
where my user principal is created. If I had my principal in the
session, then the default isUserInRole() should work as is, I'll just
retrieve my custom user principal out of the session for other
custom data.
Mark, where can I add my user principal to the session?
Brad
Mark Benussi wrote:
If you're implementing JAAS... no. No idea about the rest. Its not
supported
in Tomcat (But should be). Stick it in the session, and then you
have to
override the Tomcat HttpRequestProcessor (isUserInRole()) to get your
Principal out of the session and call the validation.
-Original Message-
From: Brad O'Hearne [mailto:[EMAIL PROTECTED]
Sent: 17 October 2005 22:25
To: Brad O'Hearne
Cc: Tomcat Users List
Subject: Is it even possible to retrieve a custom user principal?
(Was:
Tomcat user principal)
Hello,
As this has become a bit of a roadblock in implementing security, I'd
like to ask anyone out there two things:
1) Is it even possible to use a custom user princpal within a
realm that
is retrievable within a servlet (via presumably the request or
otherwise) in Tomcat?
2) If the answer to #1 is yes, how is this done? Does anyone have a
working code snippet that demonstrates this?
Thanks, I'm about to head to the developer list to ask this
question, as
its pretty crucial for our security implementation.
Brad
Brad O'Hearne wrote:
Response below:
Wendy Smoak wrote:
From: "Brad O'Hearne" <[EMAIL PROTECTED]>
I would have expected that designation of the user class name
would
have resulted in my being returned the class I specified for the
user class name from the requestion.getUserPrincpal() method,
but it
doesn't.
What version of Tomcat are you using? As far as I know, it
works the
way you want on 5.0.28. I remember trying it with and without the
class name, and writing that comment to remind myself.
Could this be it?
http://issues.apache.org/bugzilla/show_bug.cgi?id=37044
I am using 5.0.28, and I'm not seeing the expected behavior.
Hmmm.was there anything else that has to be done to be able to
access your own custom user principal?
Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTE
Re: Is it even possible to retrieve a custom user principal? (Was: Tomcat user principal)
Mark, Thanks a ton for the reply. I almost want to reply with "you're kidding, right?", as I am kind of speechless that using JAAS (which I am), the Java platform's standard authentication/authorization API, doesn't allow one to use a custom principal. It seems like a major hole in Tomcat security flexibility. I suppose I'll float on over the developer list to find out more about whether this is a planned change or not, and how much trouble it would be to add it. As for your workaround, where can I set the session? My JAAS login module doesn't have access to the session, I don't believe, which is where my user principal is created. If I had my principal in the session, then the default isUserInRole() should work as is, I'll just retrieve my custom user principal out of the session for other custom data. Mark, where can I add my user principal to the session? Brad Mark Benussi wrote: If you're implementing JAAS... no. No idea about the rest. Its not supported in Tomcat (But should be). Stick it in the session, and then you have to override the Tomcat HttpRequestProcessor (isUserInRole()) to get your Principal out of the session and call the validation. -Original Message- From: Brad O'Hearne [mailto:[EMAIL PROTECTED] Sent: 17 October 2005 22:25 To: Brad O'Hearne Cc: Tomcat Users List Subject: Is it even possible to retrieve a custom user principal? (Was: Tomcat user principal) Hello, As this has become a bit of a roadblock in implementing security, I'd like to ask anyone out there two things: 1) Is it even possible to use a custom user princpal within a realm that is retrievable within a servlet (via presumably the request or otherwise) in Tomcat? 2) If the answer to #1 is yes, how is this done? Does anyone have a working code snippet that demonstrates this? Thanks, I'm about to head to the developer list to ask this question, as its pretty crucial for our security implementation. Brad Brad O'Hearne wrote: Response below: Wendy Smoak wrote: From: "Brad O'Hearne" <[EMAIL PROTECTED]> I would have expected that designation of the user class name would have resulted in my being returned the class I specified for the user class name from the requestion.getUserPrincpal() method, but it doesn't. What version of Tomcat are you using? As far as I know, it works the way you want on 5.0.28. I remember trying it with and without the class name, and writing that comment to remind myself. Could this be it? http://issues.apache.org/bugzilla/show_bug.cgi?id=37044 I am using 5.0.28, and I'm not seeing the expected behavior. Hmmm.was there anything else that has to be done to be able to access your own custom user principal? Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is it even possible to retrieve a custom user principal? (Was: Tomcat user principal)
Hello, As this has become a bit of a roadblock in implementing security, I'd like to ask anyone out there two things: 1) Is it even possible to use a custom user princpal within a realm that is retrievable within a servlet (via presumably the request or otherwise) in Tomcat? 2) If the answer to #1 is yes, how is this done? Does anyone have a working code snippet that demonstrates this? Thanks, I'm about to head to the developer list to ask this question, as its pretty crucial for our security implementation. Brad Brad O'Hearne wrote: Response below: Wendy Smoak wrote: From: "Brad O'Hearne" <[EMAIL PROTECTED]> I would have expected that designation of the user class name would have resulted in my being returned the class I specified for the user class name from the requestion.getUserPrincpal() method, but it doesn't. What version of Tomcat are you using? As far as I know, it works the way you want on 5.0.28. I remember trying it with and without the class name, and writing that comment to remind myself. Could this be it? http://issues.apache.org/bugzilla/show_bug.cgi?id=37044 I am using 5.0.28, and I'm not seeing the expected behavior. Hmmm.was there anything else that has to be done to be able to access your own custom user principal? Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat user principal
Response below: Wendy Smoak wrote: From: "Brad O'Hearne" <[EMAIL PROTECTED]> I would have expected that designation of the user class name would have resulted in my being returned the class I specified for the user class name from the requestion.getUserPrincpal() method, but it doesn't. What version of Tomcat are you using? As far as I know, it works the way you want on 5.0.28. I remember trying it with and without the class name, and writing that comment to remind myself. Could this be it? http://issues.apache.org/bugzilla/show_bug.cgi?id=37044 I am using 5.0.28, and I'm not seeing the expected behavior. Hmmm.was there anything else that has to be done to be able to access your own custom user principal? Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat user principal
Wendy, Thanks for the reply. Here is my realm setup in my Tomcat server.xml: appName="imap" userClassNames="com.redbarnsoftware.web.security.UserPrincipal" roleClassNames="com.redbarnsoftware.web.security.RolePrincipal" debug="99" /> I would have expected that designation of the user class name would have resulted in my being returned the class I specified for the user class name from the requestion.getUserPrincpal() method, but it doesn't. Like I mentioned, I get back Tomcat's GenericPrincipal. I need to get back my own custom principal, (i.e. the com.redbarnsoftware.web.security.UserPrincipal listed in the realm config), or at least have a way to get to it. Surely there's got to be a way to do this. Any thoughts? Brad Wendy Smoak wrote: From: "Brad O'Hearne" <[EMAIL PROTECTED]> I am using the JAASRealm for Tomcat 5.x, and in my JAAS module, I am storing my own Principal subclass as the user principal. In my subsequent servlets, when I invoke the request.getUserPrincipal() method, I am not returned my user principal, but I am instead returned a GenericPrincipal. This sounds vaguely familiar... no guarantees that this applies to your situation, but when I was working out how to get Tomcat to use our campus Kerberos server, I left this comment in the code: /* Hand off to the JAASRealm superclass to authenticate the user. This will use the Krb5LoginModule configured in jaas.conf. With no 'userClassNames' in the , it will return a GenericPrincipal. Alternately, if you use userClassNames="javax.security.auth.kerberos.KerberosPrincipal", you will get back a KerberosPrincipal instead.*/ What does your look like? If you haven't already, try listing your class in 'userClassNames' and see if you get the right return value. More info here: http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatJAASRealm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat user principal
I am using the JAASRealm for Tomcat 5.x, and in my JAAS module, I am storing my own Principal subclass as the user principal. In my subsequent servlets, when I invoke the request.getUserPrincipal() method, I am not returned my user principal, but I am instead returned a GenericPrincipal. It appears that this GenericPrincipal is wrapping my user principal class. I have encountered two problems in particular with this: 1) Even though the getClass().getName() method on the GenericPrincipal returns GenericPrinple, if I try casting it to this type, I receive a ClassCastException, so the only type I can work with is the standard Principal interface. 2) There is no way to get at my user principal. Basically what I am trying to do is populate a custom user Principal implementation in my JAAS module, and retrieve my custom user principal again from within my servlet class. Does anyone know how to do this in Tomcat? Thanks, Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
