Re: Setting JK_REMOTE_USER help
On 17/06/2010 02:41, Marc Boorshtein wrote: The problem with the Realm system is its designed with the assumption that tomcat is doing the authentication which is not a valid assumption in an environment where the authentication is seperated from authorization. The entire point of container security is that as a coder I don't have to worry about how any of this is implemented. The problem with Tomcat is that all too often it doesn't do what people expect it should do*. p * Or maybe the problem isn't Tomcat. I'm not looking to start a holy war here, but is there anything incorrect in what I said? Tomcat is a servlet container, the servlet Yes. You made a sweeping statement about container managed security which implied that things should just work. Someone has to make them work. As an app developer you might not have to worry about how the bits behind the API work, but some admin has to configure it properly. API is a contract between the container and the developer, the contract specifies how a developer would access role information regardless of the implementation. Since the Realm implementation assumes that Tomcat is doing the authentication and breaks when it isn't Tomcat, isn't that a violation of the contract? No. I don't think it is. Your specific need might not be handled by the Realm implementations supplied with Tomcat, but that's not proof that either design of Realms is flawed or that Tomcat isn't spec compliant. It's open source, so I'm not complaining or demanding anything. I think I know how to do what I need however that doesn't change the facts of the situation that Tomcat does not have the built in capability for a standard realm to simply retrieve user infomation as opposed to authentication AND user retrieval that would enable Tomcat to maintain its compliance while being fronted by Apache. The explanation you provided in your 3rd email doesn't sound like 'simply' to me. You also state that other servlet containers need a 3rd party agent to achieve the desired result. If your complaint is accurate then the other 3 servers you name must also 'violate the contract' because they don't provide what you need out of the box. p signature.asc Description: OpenPGP digital signature
Re: disabling copy of context.xml to conf/Catalina/localhost
On 17/06/2010 00:49, Rajeev Verma wrote: Hi, I am facing a problem which can be solved if I can disable copy of context.xml to conf/Catalina/localhost. Is there some setting to do so? Thanks for the help. What are your exact Tomcat, JVM, OS versions? What is the problem? p signature.asc Description: OpenPGP digital signature
RE: Setting the Right Amount of Memory
If your heap size is right on the edge of your minimum for a Tomcat instance, you may be doing more GC work than is really needed. However, if you're satisfied with the response time and CPU utilization, you should be ok. My thoughts exactly. Just wanted to check it with the community. FYI, with 160 instances of tomcat running at the same time, CPU is still 90% idle even during peak production hours. Now the software vendor is coming along and forcing us to set the heap for each instance to 512MB when 64MB or 96MB works fine. It's unnecessarily expensive and super frustrating. -- Eric Robinson Disclaimer - June 17, 2010 This email and any files transmitted with it are confidential and intended solely for Tomcat Users List. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of . Warning: Although has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Setting the Right Amount of Memory
Just wondering, what tools do you use to manage all the instances? Also, what do you use to look for the OutOfMemory in logs? I am looking at Splunk too. Just shell scripts. We have scripts that... -- set up a new instance and customize it for a new customer -- stops, starts, restarts, optionally clearing the work folders -- analyzes jasper logs for system responsiveness (both realtime and historically) -- synchronizes certain files between instances on different tomcat servers -- watches for OutOfMemory in various logs -- grooms logs periodically -- monitors various logs in realtime ..and so on. Never found anything we couldn't do with bash and cron. -- Eric Robinson Disclaimer - June 17, 2010 This email and any files transmitted with it are confidential and intended solely for Tomcat Users List. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of . Warning: Although has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat unexpected shutdown on Solaris
On 17.06.2010 05:35, Caldarale, Charles R wrote: From: Marco Castillo [mailto:mabcasti...@vdkit.net] Subject: Tomcat unexpected shutdown on Solaris I have checked all the logs and there is no exception displayed, no error, nothing. I look for an error file from java, but there is no one. It happens randomly. Sometimes the Tomcat works for large periods of time, sometimes it shutdowns 5 minutes after it has been started. Does somebody has any idea? Likely one of your webapps (possibly a 3rd-party library) is calling System.exit() - very anti-social behavior. You can use a security manager to prevent it and catch the culprit. ... or you are starting Tomcat with an interactive shell, and the shell is one of those which sends a signal (SIGHUP or similar) to all child processes when you logout (or get logged out by some idleness condition or similar). See man nohup. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authentication of proxy over own module
Sorry I have posted to the wrong conference.
Add the end of this mail youc can find where I have a problem?
2010/6/17 Pid p...@pidster.com
On 16/06/2010 10:08, Petr Hracek wrote:
Sorry my wrong explanation. I have ment the when the request is
authorized/authenticated by my module how the request should be sent to
the
proxy IP address define in apache module:
RewriteRule ^/PAC$ http://192.168.0.23:8080/PACAdmin [P]
RewriteRule ^/PAC/(.*) http://192.168.0.23:8080/PACAdmin/$1 [P]
RewriteRule ^/([^/]+)$ ${foo:$1|/$1} [L]
RewriteRule ^/([^/]+)/(.*) ${foo:$1|/opt/apache/htdocs/ssldocs/$1}/$2
[L]
Location /PAC/
ProxyPass http://192.168.0.23:8080/PACAdmin
ProxyPassReverse http://192.168.0.23:8080/PACAdmin
ProxyPassReverseCookie /PACAdmin /PAC
Order Allow,deny
Allow from all
/Location
Can you explain again what it is you're trying to achieve, please?
p
Best regards
Petr
2010/6/15 basteon bast...@gmail.com
hm, redirect itsn't proxing , as i understood ;) redirect it's wen you
communicate client and target server directly and no proxing anymore.
in case todo proxy in your module there should be server and client
parts, I've not seen your module, maybe it's under NDA, and so on...
but you can have a look at scgi module there client in apache api, but
it working in another way. there...
static apr_status_t
open_socket(apr_socket_t **sock, request_rec *r)
{
//snip
and
rv = apr_socket_connect(*sock, sockaddr);
if (rv) {
//snip
On 15 June 2010 20:49, Petr Hracek phrac...@gmail.com wrote:
That's a good sentence.
You mention:
if you did auth in your own module there should be accepted stream
and
when it passed auth you must sent it through own module to target
server.
May be this is a my problem. When the request is
authorized/authenticated
by
my module how and where I have to sent to the target server.
How can I do it? Redirect?
Thank you in advance
Petr
2010/6/15 basteon bast...@gmail.com
no, about sniffing i meant sniff traffic on the network interface.
I don't know how catch up ReverseProxy requests, but if you did auth
in your own module there should be accepted stream and when it passed
auth you must sent it through own module to target server. or it
should working as proxy you must thinking about sessions
accepted\passed auth, then init auth from own module to target server.
but, why you did it at all? what's purposes on it double auth?
On 15/06/2010, Petr Hracek phrac...@gmail.com wrote:
But I am using ReverseProxy as well, right?
I mean in my own module to sniff traffic when the request is
ReverseProxy
and them going to the target?
How I can catch that request is Reverse Proxy (not defined in Browser
settings)?
Is that any handler for that case and where should I try to catch the
request?
In post_read_request?
Could you please let me more detailly what do you think?
best regards.
Petr
2010/6/14 basteon bast...@gmail.com
I uses reverce proxy, but you can try sniff traffic between proxy
and
target
On 14 June 2010 13:52, Petr Hracek phrac...@gmail.com wrote:
If you mean that RewriteRule should be like that:
RewriteMap foo txt:/opt/apache/conf/foo.map
RewriteRule ^/([^/]+)$ ${foo:$1|/$1} [L]
RewriteRule ^/([^/]+)/(.*) ${foo:$1|/opt/apache/htdocs/
ssldocs/$1}/$2 [L]
RewriteRule ^/PAC$ http://192.168.0.23:8080/PACAdmin [P]
RewriteRule ^/PAC/(.*) http://192.168.0.23:8080/PACAdmin/$1 [P]
Unfortuantelly in this case I see /opt/PAC/htdocs error was not
found
but this is true because of main index is on the machine
192.168.0.23:8080.
Therefore I am receiving HTTP error 404.
Or shall I do?
IfModule mod_authz_host.c
Location /PAC/
ProxyPass http://192.168.0.23:8080/PACAdmin
ProxyPassReverse http://192.168.0.23:8080/PACAdmin
ProxyPassReverseCookie /PACAdmin /PAC
AuthType FOOM
require valid-user
satisfy Any
/Location
/IfModule
Thank you in advance
Petr
2010/6/14 basteon bast...@gmail.com
hm, looks like if there double auth, therefore you should put
client
account trough your module instead of just redirect these client.
On 14 June 2010 11:36, Petr Hracek phrac...@gmail.com wrote:
Yes this is done simillary in my own module but I have an
problem.
When the URL is authorized (successfully) then URL
http://192.168.0.23:8080/PAC is shown as 404 Unknown.
Unfortuntatelly I could not find any reason why it is not found
because
of
URL is a Proxy?
See my apache2 configuration file
Eric mentioned:
Don't constrain your directives to stuff under Directory / if
you
want them to apply to proxy requests. These are never mapped to
a
directory.
But Unfortunatelly I do not understand what shall I do. How
shall
I
defined
my directives.
Any help?
2010/6/14
Re: Tomcat 5.0/6.0, jasper2, log4j and Ant
On 15/06/2010 15:59, Olivier DOREMIEUX wrote: Hello, How to propagate variables to the jasper2 task in ANT? I have log4.properties with a variable, with define the path where the log file are located. OK so far. My variable is visible inside of ant, but doesn't get propagated with jasper2, they are empty. How are you setting it, and how and where are you expecting to read it (in a JSP perhaps)? p Is there something equivalent to sysproperty key=MY_VAR value=myPath/ for jasper2? Any work around? Thanks in advance, Olivier DOREMIEUX - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: Setting JK_REMOTE_USER help
I'm not looking to start a holy war here, but is there anything incorrect in what I said? Tomcat is a servlet container, the servlet Yes. You made a sweeping statement about container managed security which implied that things should just work. Someone has to make them work. As an app developer you might not have to worry about how the bits behind the API work, but some admin has to configure it properly. No argument there. Thats what I started trying to figure out. As I said this is a Commercial Off The Shelf application that was built to the Servlet API specification. I didn't develop the app but given the app is written to the Servlet API there are certain expectations do to how the api is written. API is a contract between the container and the developer, the contract specifies how a developer would access role information regardless of the implementation. Since the Realm implementation assumes that Tomcat is doing the authentication and breaks when it isn't Tomcat, isn't that a violation of the contract? No. I don't think it is. Your specific need might not be handled by the Realm implementations supplied with Tomcat, but that's not proof that either design of Realms is flawed or that Tomcat isn't spec compliant. The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the authentication unless you do a 100% custom realm. This is ultimately how I solved my issue (I make a copy of JNDIRealm and took out the credential check). Why I feel this is an issue with Tomcat's implementation is explained below. It's open source, so I'm not complaining or demanding anything. I think I know how to do what I need however that doesn't change the facts of the situation that Tomcat does not have the built in capability for a standard realm to simply retrieve user infomation as opposed to authentication AND user retrieval that would enable Tomcat to maintain its compliance while being fronted by Apache. The explanation you provided in your 3rd email doesn't sound like 'simply' to me. You also state that other servlet containers need a 3rd party agent to achieve the desired result. If your complaint is accurate then the other 3 servers you name must also 'violate the contract' because they don't provide what you need out of the box. The way WebSphere and Weblogic work (I've not done this integration with JBoss so I can't speak to it) there is a security subsystem that seperates user group retrieval from actual authentication. The reason for this is to allow third party authentication providers to be plugged into the system without changing how the application server retrieves user information. Here's the flow of how WebSphere with SiteMinder integrates: 1. User accesses URL pointing to IHS (an apache variant) 2. SiteMinder agent in IHS authenticates and authorizes the user 3. WebSphere plugin (which would be a peer to mod_jk) forwards the request to WebSphere 4. WebSphere executes a TAI (I forget what the acronym stands for) that is provided by the vendor (in this case CA) validate the request and provide WebSphere with the user's principal. Websphere also exposes its API to the TAI for retrieving user information for building the Principal object. 5. WebSphere executes it's security configuration as it executes the request It is a similar process for Oracle Access Manager and IBM Tivoli Access Manager as well with Oracle Weblogic. The critical point here is that if you swapped out any of the above Web Access Managers (or even replace them with Federation systems like Ping) you don't change how WebSphere RETRIEVES user information and do not need to recode the application. The only portion that gets changed is the third party integration tool. This was the intent of including security components in the Servlet API. So do I think Tomcat needs to support every WAM or Federation system? No, that would be completely unreasonable. Do I think that Tomcat should not require a re-coding of a component that has nothing to do with authentication when changing authentication systems? Yes. I do think that is reasonable. I think its reasonable that if I provide the authentication mechanism that Tomcat should be able to accept it and retrieve the user information without being forced to do the authentication on its own. I want to be clear. I think Tomcat is a great product and like all great products it has it's strengths and weaknesses. Even between the 1/2 hour of coding I had to do to get the solution working, the bit more coding I'll have to do once I move from Basic authentication to form based and the very interesting conversation on this list it still took me less time to do it in tomcat then to get Weblogic setup, installed and configured! Thanks Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Re: Setting JK_REMOTE_USER help
On 17/06/2010 12:34, Marc Boorshtein wrote: I'm not looking to start a holy war here, but is there anything incorrect in what I said? Tomcat is a servlet container, the servlet Yes. You made a sweeping statement about container managed security which implied that things should just work. Someone has to make them work. As an app developer you might not have to worry about how the bits behind the API work, but some admin has to configure it properly. No argument there. Thats what I started trying to figure out. As I said this is a Commercial Off The Shelf application that was built to the Servlet API specification. I didn't develop the app but given the app is written to the Servlet API there are certain expectations do to how the api is written. API is a contract between the container and the developer, the contract specifies how a developer would access role information regardless of the implementation. Since the Realm implementation assumes that Tomcat is doing the authentication and breaks when it isn't Tomcat, isn't that a violation of the contract? No. I don't think it is. Your specific need might not be handled by the Realm implementations supplied with Tomcat, but that's not proof that either design of Realms is flawed or that Tomcat isn't spec compliant. The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the authentication unless you do a 100% custom realm. This is ultimately how I solved my issue (I make a copy of JNDIRealm and took out the credential check). Why I feel this is an issue with Tomcat's implementation is explained below. It's open source, so I'm not complaining or demanding anything. I think I know how to do what I need however that doesn't change the facts of the situation that Tomcat does not have the built in capability for a standard realm to simply retrieve user infomation as opposed to authentication AND user retrieval that would enable Tomcat to maintain its compliance while being fronted by Apache. The explanation you provided in your 3rd email doesn't sound like 'simply' to me. You also state that other servlet containers need a 3rd party agent to achieve the desired result. If your complaint is accurate then the other 3 servers you name must also 'violate the contract' because they don't provide what you need out of the box. The way WebSphere and Weblogic work (I've not done this integration with JBoss so I can't speak to it) there is a security subsystem that seperates user group retrieval from actual authentication. The reason for this is to allow third party authentication providers to be plugged into the system without changing how the application server retrieves user information. So is the problem that Tomcat doesn't provide the same pluggability that the other (full JEE servers) do? Here's the flow of how WebSphere with SiteMinder integrates: 1. User accesses URL pointing to IHS (an apache variant) 2. SiteMinder agent in IHS authenticates and authorizes the user 3. WebSphere plugin (which would be a peer to mod_jk) forwards the request to WebSphere 4. WebSphere executes a TAI (I forget what the acronym stands for) that is provided by the vendor (in this case CA) validate the request and provide WebSphere with the user's principal. Websphere also exposes its API to the TAI for retrieving user information for building the Principal object. 5. WebSphere executes it's security configuration as it executes the request It is a similar process for Oracle Access Manager and IBM Tivoli Access Manager as well with Oracle Weblogic. The critical point here is that if you swapped out any of the above Web Access Managers (or even replace them with Federation systems like Ping) you don't change how WebSphere RETRIEVES user information and do not need to recode the application. The only portion that gets changed is the third party integration tool. This was the intent of including security components in the Servlet API. Because the pluggable 3rd party agent handles that for you? So do I think Tomcat needs to support every WAM or Federation system? No, that would be completely unreasonable. Do I think that Tomcat should not require a re-coding of a component that has nothing to do with authentication when changing authentication systems? Yes. I do think that is reasonable. I think its reasonable that if I provide the authentication mechanism that Tomcat should be able to accept it and retrieve the user information without being forced to do the authentication on its own. Surely that's subjective, it depends entirely on the authentication authorization mechanism you want to use. I wouldn't expect Tomcat to be able to effect authorization when I've authenticated by Internet Telepathy(tm). (To pick a wildly unreasonable alternative) I want to be clear. I think Tomcat is a great product and like all great products it has it's strengths
Help with Log Level in Tomcat 6 Logging
Hello,
Im a newbie to Tomcat logging.
Here is the logging.properties of my Catalina installation:
---
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
# Handler specific properties.
# Describes specific configuration info for Handlers.
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.
4host-manager.org.apache.juli.FileHandler.level = FINE
4host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4host-manager.org.apache.juli.FileHandler.prefix = host-manager.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter
# Facility specific properties.
# Provides extra control for each logger.
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
2localhost.org.apache.juli.FileHandler
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers
= 3manager.org.apache.juli.FileHandler
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers
= 4host-manager.org.apache.juli.FileHandler
# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
#org.apache.catalina.startup.ContextConfig.level = FINE
#org.apache.catalina.startup.HostConfig.level = FINE
#org.apache.catalina.session.ManagerBase.level = FINE
#org.apache.catalina.core.AprLifecycleListener.level=FINE
The problem I have is that in my daily rolling catalina-[data].out I only
get SEVERE level messages.
Given the above configuration, my understanding from reading this (
http://tomcat.apache.org/tomcat-6.0-doc/logging.html) is that FINE for the
FileHandler would log everything above ie. FINE,CONFIG,INFO,WARNINGBut
Im only getting SEVERE written to my daily rolling logfile.
Im not sure how to change this behaviour even after reading through -
http://tomcat.apache.org/tomcat-6.0-doc/logging.html -
and any advice is appreciated.
Thanks
Jon
Re: Setting JK_REMOTE_USER help
Pid wrote: On 17/06/2010 12:34, Marc Boorshtein wrote: I'm not looking to start a holy war here, but is there anything incorrect in what I said? Tomcat is a servlet container, the servlet Yes. You made a sweeping statement about container managed security which implied that things should just work. Someone has to make them work. As an app developer you might not have to worry about how the bits behind the API work, but some admin has to configure it properly. No argument there. Thats what I started trying to figure out. As I said this is a Commercial Off The Shelf application that was built to the Servlet API specification. I didn't develop the app but given the app is written to the Servlet API there are certain expectations do to how the api is written. API is a contract between the container and the developer, the contract specifies how a developer would access role information regardless of the implementation. Since the Realm implementation assumes that Tomcat is doing the authentication and breaks when it isn't Tomcat, isn't that a violation of the contract? No. I don't think it is. Your specific need might not be handled by the Realm implementations supplied with Tomcat, but that's not proof that either design of Realms is flawed or that Tomcat isn't spec compliant. The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the authentication unless you do a 100% custom realm. This is ultimately how I solved my issue (I make a copy of JNDIRealm and took out the credential check). Why I feel this is an issue with Tomcat's implementation is explained below. It's open source, so I'm not complaining or demanding anything. I think I know how to do what I need however that doesn't change the facts of the situation that Tomcat does not have the built in capability for a standard realm to simply retrieve user infomation as opposed to authentication AND user retrieval that would enable Tomcat to maintain its compliance while being fronted by Apache. The explanation you provided in your 3rd email doesn't sound like 'simply' to me. You also state that other servlet containers need a 3rd party agent to achieve the desired result. If your complaint is accurate then the other 3 servers you name must also 'violate the contract' because they don't provide what you need out of the box. The way WebSphere and Weblogic work (I've not done this integration with JBoss so I can't speak to it) there is a security subsystem that seperates user group retrieval from actual authentication. The reason for this is to allow third party authentication providers to be plugged into the system without changing how the application server retrieves user information. So is the problem that Tomcat doesn't provide the same pluggability that the other (full JEE servers) do? Here's the flow of how WebSphere with SiteMinder integrates: 1. User accesses URL pointing to IHS (an apache variant) 2. SiteMinder agent in IHS authenticates and authorizes the user 3. WebSphere plugin (which would be a peer to mod_jk) forwards the request to WebSphere 4. WebSphere executes a TAI (I forget what the acronym stands for) that is provided by the vendor (in this case CA) validate the request and provide WebSphere with the user's principal. Websphere also exposes its API to the TAI for retrieving user information for building the Principal object. 5. WebSphere executes it's security configuration as it executes the request It is a similar process for Oracle Access Manager and IBM Tivoli Access Manager as well with Oracle Weblogic. The critical point here is that if you swapped out any of the above Web Access Managers (or even replace them with Federation systems like Ping) you don't change how WebSphere RETRIEVES user information and do not need to recode the application. The only portion that gets changed is the third party integration tool. This was the intent of including security components in the Servlet API. Because the pluggable 3rd party agent handles that for you? So do I think Tomcat needs to support every WAM or Federation system? No, that would be completely unreasonable. Do I think that Tomcat should not require a re-coding of a component that has nothing to do with authentication when changing authentication systems? Yes. I do think that is reasonable. I think its reasonable that if I provide the authentication mechanism that Tomcat should be able to accept it and retrieve the user information without being forced to do the authentication on its own. Surely that's subjective, it depends entirely on the authentication authorization mechanism you want to use. I wouldn't expect Tomcat to be able to effect authorization when I've authenticated by Internet Telepathy(tm). (To pick a wildly unreasonable alternative) I want to be clear. I think Tomcat is a great product and like all great products it has it's strengths and weaknesses. Even between the 1/2 hour of coding I had to
Re: Help with Log Level in Tomcat 6 Logging
Jonathan Jackson wrote: ... Hi. If it may contribute to less confusion : for as long as I remember, and still in tomcat 6.0.26 e.g., the comment in front of this paragraph at the end of the logging.properties file # For example, set the com.xyz.foo logger to only log SEVERE # messages: #org.apache.catalina.startup.ContextConfig.level = FINE #org.apache.catalina.startup.HostConfig.level = FINE #org.apache.catalina.session.ManagerBase.level = FINE #org.apache.catalina.core.AprLifecycleListener.level=FINE has had a comment totally out of sync with the lines that follow. Unfortunately, I do not know how to rectify it, because Tomcat logging has long been a mysterious area where I fear to walk alone even by day. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting the Right Amount of Memory
On 17/06/2010 08:59, Robinson, Eric wrote: If your heap size is right on the edge of your minimum for a Tomcat instance, you may be doing more GC work than is really needed. However, if you're satisfied with the response time and CPU utilization, you should be ok. My thoughts exactly. Just wanted to check it with the community. FYI, with 160 instances of tomcat running at the same time, CPU is still 90% idle even during peak production hours. Now the software vendor is coming along and forcing us to set the heap for each instance to 512MB when 64MB or 96MB works fine. It's unnecessarily expensive and super frustrating. Time to hit the vendor around the head with the cluebat. If the app is happy with less heap space then increasing it is only going to cause problems - mainly that GC when it happens will take longer and trigger longer pauses. You can mitigate this with GC config (later VMs may make the right choices for you anyway) but all this is just adding unecessary complexity. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP connector to be aware of proxied SSL requests
On 17/06/2010 01:41, Matt Peterson wrote: I can't find any documentation on the order of events for the Connector, so I'm not sure what other decisions get made based on the request attributes, but assume there are others. This is *open* source... Is there another solution to handling proxied SSL requests so that Catalina as well as our apps are aware that the requests are secure??? One possibility is to have two Connectors (1 using the secure, scheme and serverPort attributes for secure and 1 for non-secure) and have the LB connect to the appropriate Connector depending on the request. But this effectively doubles the amount of config needed to be managed (2nd set of config for LB + 2nd connector), which is considerable when dealing with 6 TC clusters each with their own set of LB config. The other option would be to proxy using AJP rather than HTTP (if the load-balancer supports it) since AJP passes SSL info as part of the protocol. If you want to use mixed HTTP/HTTPS in the LB and just HTTP on Tomcat than multiple connectors is usually what I'd recommend. Should I lodge an enhancement request for the Connector to become aware of proxied SSL requests (perhaps via an injected x-forwarded-proto header, ala WebLogic)? You can, not sure how much traction it would get. Both the logic and configuration is non-trivial to ensure only trusted proxies set the header. We try to keep the connector code fairly slick. This feels like more than we would want to add (bearing in mind this is just instinct - I haven't looked at any code at ths point). You might have better luck with an option to defer the redirection with the / to later in the processing chain. That would be simpler to implement but would add some extra processing that currently is bypassed by doing the rediection as early as possible. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
On 17/06/2010 13:26, André Warnier wrote: I must say that, with my limited knowledge of the Tomcat internals taken into consideration, I tend to agree with Marc in this case, if he is right in claiming that the Tomcat Realm mixes authentication with authorization and does not allow to separate the two. That is how Tomcat Realms are designed. This is consistent with the Servlet sepc that leaves the implementation details entirely to the container. If Tomcat required all authentication requests to be made via carrier pigeon then that would be spec complaint providing the correct information was exposed via the API defined in the spec. At the very least, I would expect the Realm to check first if the request already has a user-id, and skip the authentication part in such a case. Easier said than done. The Realms deliberately have no visibility of the request or the response. The Authenticators extract the username and password, pass them to the realm to obtain an authenticated Principal (with roles) and then the Authenitcators populate the attributes that then support the calls in the Servlet API. The way to handle this (probably) is to modify the Authenticators (hopefully just the base class) to check for an already authenticated user. If one is found, use the realms just to get the roles. The implementation for that is already in place. It just needs adding to the interface and the visibility changed. Then you just need to figure out how to merge the existing Principal (that may have roles) with the new one that has the roles from the Realm. Tomcat 7's internal API has deliberately been declared as volatile inthe docs so now is the time to make these changes. Patches welcome. Note this won't get ported back to 6 due to the API changes required. There are many cases out there were Tomcat is only a part of a more complex system, where a network-wide authentication is required, while the authorization part may still be one that only Tomcat can do. A naive linked question : is the Realm a purely Tomcat thing, or is it mandated by the Servlet Spec ? 100% pure Tomcat. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
NewBie! Need Help to configure FTP/Domain...
Hi All, I'm new to TomCat however I have managed to get JDK setup and Tomcat 6 running on Linux 64bit server. I've deployed an app via WAR file and all looks good. So all that remains for me to do is confirgure a domain name to use the server and be able to FTP to the installed app folder. I've been searching and digging but am a bit lost at this stage. If anyone can point me in the right direction it would be great. Thanks Alan
Re: POI/XML issues in server environment
Hi All, Over here from POI where I helped Jorge track things down in Tomcat. I suggested he come over here for help, but he seems to have started at the beginning and is getting the exact same initial questions that were asked on POI User. Here's what was determined. One of the webapps on his production server uses an older XercesImpl Jar in his endorsed directory. This causes a conflict with POI that is not handled very well. I've opened a bugzilla in POI so that we'll eventually have a more informative error message. We'll need to check to see versions of XML Parser implementations active in the JVM to find out what POI OOXML's minimum requirement really is. Any suggestions about how to do that would be very helpful. The thread should be easy enough to find on the POI User list. In it Jorge provided a screenshot of his production server's common/lib and it was packed with jars. No surprise there is a conflict. Regards, Dave On Jun 16, 2010, at 5:05 PM, Terence M. Bandoian wrote: Any possibility that the Excel file was modified (e.g. FTP)? I've used POI in a Tomcat 5.5 webapp on Windows Server and didn't see any problems like this. -Terence Bandoian Jorge Moya wrote: Hello guys. For the past couple of days, I've been working as an intern in a local company and I'd like to mention I'm kind of new with Tomcat and POI. My first task was to update a java code they had to extract information of excel 97-2003 files to the new POI so that I could also extract and work with Excel 2007+ files. I got it working with a local .class test and ant.xml build. I then proceeded to update the webservice app in our server to function along with Tomcat and this is where the problems began that have been bothering me for the past week. Whenever I try to extract .xlsx files I get the following error: org.apache.poi.openxml4j.exceptions.InvalidFormatException: Can't read content types part ! at org.apache.poi.openxml4j.opc.internal.ContentTypeManager.init(ContentTypeManager.java:107) at org.apache.poi.openxml4j.opc.internal.ZipContentTypeManager.init(ZipContentTypeManager.java:56) at org.apache.poi.openxml4j.opc.ZipPackage.getPartsImpl(ZipPackage.java:136) at org.apache.poi.openxml4j.opc.OPCPackage.getParts(OPCPackage.java:585) at org.apache.poi.openxml4j.opc.OPCPackage.open(OPCPackage.java:222) at org.apache.poi.ss.usermodel.WorkbookFactory.create(WorkbookFactory.java:63) at com.msights.core.utils.ExcelFile.loadFile(ExcelFile.java:84) at com.msights.core.utils.GroupLoader.loadFiles(GroupLoader.java:50) at com.msights.core.validation.ValidationModule.run(ValidationModule.java:154) at java.lang.Thread.run(Thread.java:595) Now, I've established a long conversation with the POI userlist and came to the conclusion I'm having some issues with some of the .jar files and classes. This is notably so because I established a local Tomcat environment and I can extract the information just fine. I'm kind of at odds on how I could fix that issues (Tomcat in the server manipulates a couple of webapps) and maybe you guys could offer me a solution. Java version is 1.5.0_18-b02 Windows version is Windows Server 2003 SP2 Tomcat version: 5.5.20 Libraries: *http://bit.ly/casaPs* Shared only has cewcanative.jar Any idea of what's causing the problem? Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help with Log Level in Tomcat 6 Logging
2010/6/17 Jonathan Jackson jonathan.x.jack...@gmail.com: The problem I have is that in my daily rolling catalina-[data].out I only get SEVERE level messages. Given the above configuration, my understanding from reading this ( http://tomcat.apache.org/tomcat-6.0-doc/logging.html) is that FINE for the FileHandler would log everything above ie. FINE,CONFIG,INFO,WARNINGBut Im only getting SEVERE written to my daily rolling logfile. The Tomcat JULI logging is an implementation of java.util.logging (aka JUL), which documentation is here, http://java.sun.com/javase/6/docs/api/java/util/logging/package-summary.html#package_description http://java.sun.com/javase/6/docs/api/java/util/logging/Level.html http://java.sun.com/javase/6/docs/technotes/guides/logging/index.html etc. To make a brief summary, there are two levels where log messages are filtered: a) at the category (aka logger) level If level of a category (if not specified then its parent level is taken) does not match the message, it will be rejected by the logging system and will not be processed at all. That is what these lines are for: org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level org.apache.catalina.core.AprLifecycleListener.level The categories form a hierarchy, and the default level is specified by .level= INFO Note, that the org.apache.catalina.core.ContainerBase.[Catalina].[localhost] category is for the messages logged through Servlet.log() API calls, which I think is rare. Usually applications use commons-logging calls and their category names are different. Thus the defaults (.level=INFO) apply to them. There is no .level= INFO in Tomcat's logging.properties because the defaults are provided by JRE through its logging.properties. But you can always add such a line by yourself, e.g. .level= FINEST will cause a lot of messages being processed b) when writing the message out (aka handler) level If handler level does not match the message, it will be skipped (but may be printed by other handlers). categoryname.handler setting attaches handlers to a category. I think you missed a). By the way, .handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler I hope that those lines were wrapped by the mailing software. You cannot wrap lines in a properties file like that (though you can if you end previous line with '\'). see java.util.Properties JavaDoc. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: POI/XML issues in server environment
On 17/06/2010 14:33, David Fisher wrote: Hi All, Over here from POI where I helped Jorge track things down in Tomcat. I suggested he come over here for help, but he seems to have started at the beginning and is getting the exact same initial questions that were asked on POI User. Here's what was determined. One of the webapps on his production server uses an older XercesImpl Jar in his endorsed directory. This causes a conflict with POI that is not handled very well. I've opened a bugzilla in POI so that we'll eventually have a more informative error message. We'll need to check to see versions of XML Parser implementations active in the JVM to find out what POI OOXML's minimum requirement really is. Any suggestions about how to do that would be very helpful. The thread should be easy enough to find on the POI User list. In it Jorge provided a screenshot of his production server's common/lib and it was packed with jars. No surprise there is a conflict. OK. Useful. Was there some particular aspect of Tomcat / deployment that you had in mind that we could help with? p Regards, Dave On Jun 16, 2010, at 5:05 PM, Terence M. Bandoian wrote: Any possibility that the Excel file was modified (e.g. FTP)? I've used POI in a Tomcat 5.5 webapp on Windows Server and didn't see any problems like this. -Terence Bandoian Jorge Moya wrote: Hello guys. For the past couple of days, I've been working as an intern in a local company and I'd like to mention I'm kind of new with Tomcat and POI. My first task was to update a java code they had to extract information of excel 97-2003 files to the new POI so that I could also extract and work with Excel 2007+ files. I got it working with a local .class test and ant.xml build. I then proceeded to update the webservice app in our server to function along with Tomcat and this is where the problems began that have been bothering me for the past week. Whenever I try to extract .xlsx files I get the following error: org.apache.poi.openxml4j.exceptions.InvalidFormatException: Can't read content types part ! at org.apache.poi.openxml4j.opc.internal.ContentTypeManager.init(ContentTypeManager.java:107) at org.apache.poi.openxml4j.opc.internal.ZipContentTypeManager.init(ZipContentTypeManager.java:56) at org.apache.poi.openxml4j.opc.ZipPackage.getPartsImpl(ZipPackage.java:136) at org.apache.poi.openxml4j.opc.OPCPackage.getParts(OPCPackage.java:585) at org.apache.poi.openxml4j.opc.OPCPackage.open(OPCPackage.java:222) at org.apache.poi.ss.usermodel.WorkbookFactory.create(WorkbookFactory.java:63) at com.msights.core.utils.ExcelFile.loadFile(ExcelFile.java:84) at com.msights.core.utils.GroupLoader.loadFiles(GroupLoader.java:50) at com.msights.core.validation.ValidationModule.run(ValidationModule.java:154) at java.lang.Thread.run(Thread.java:595) Now, I've established a long conversation with the POI userlist and came to the conclusion I'm having some issues with some of the .jar files and classes. This is notably so because I established a local Tomcat environment and I can extract the information just fine. I'm kind of at odds on how I could fix that issues (Tomcat in the server manipulates a couple of webapps) and maybe you guys could offer me a solution. Java version is 1.5.0_18-b02 Windows version is Windows Server 2003 SP2 Tomcat version: 5.5.20 Libraries: *http://bit.ly/casaPs* Shared only has cewcanative.jar Any idea of what's causing the problem? Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: Setting JK_REMOTE_USER help
On 17/06/2010 13:26, André Warnier wrote: Pid wrote: On 17/06/2010 12:34, Marc Boorshtein wrote: I'm not looking to start a holy war here, but is there anything incorrect in what I said? Tomcat is a servlet container, the servlet Yes. You made a sweeping statement about container managed security which implied that things should just work. Someone has to make them work. As an app developer you might not have to worry about how the bits behind the API work, but some admin has to configure it properly. No argument there. Thats what I started trying to figure out. As I said this is a Commercial Off The Shelf application that was built to the Servlet API specification. I didn't develop the app but given the app is written to the Servlet API there are certain expectations do to how the api is written. API is a contract between the container and the developer, the contract specifies how a developer would access role information regardless of the implementation. Since the Realm implementation assumes that Tomcat is doing the authentication and breaks when it isn't Tomcat, isn't that a violation of the contract? No. I don't think it is. Your specific need might not be handled by the Realm implementations supplied with Tomcat, but that's not proof that either design of Realms is flawed or that Tomcat isn't spec compliant. The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the authentication unless you do a 100% custom realm. This is ultimately how I solved my issue (I make a copy of JNDIRealm and took out the credential check). Why I feel this is an issue with Tomcat's implementation is explained below. It's open source, so I'm not complaining or demanding anything. I think I know how to do what I need however that doesn't change the facts of the situation that Tomcat does not have the built in capability for a standard realm to simply retrieve user infomation as opposed to authentication AND user retrieval that would enable Tomcat to maintain its compliance while being fronted by Apache. The explanation you provided in your 3rd email doesn't sound like 'simply' to me. You also state that other servlet containers need a 3rd party agent to achieve the desired result. If your complaint is accurate then the other 3 servers you name must also 'violate the contract' because they don't provide what you need out of the box. The way WebSphere and Weblogic work (I've not done this integration with JBoss so I can't speak to it) there is a security subsystem that seperates user group retrieval from actual authentication. The reason for this is to allow third party authentication providers to be plugged into the system without changing how the application server retrieves user information. So is the problem that Tomcat doesn't provide the same pluggability that the other (full JEE servers) do? Here's the flow of how WebSphere with SiteMinder integrates: 1. User accesses URL pointing to IHS (an apache variant) 2. SiteMinder agent in IHS authenticates and authorizes the user 3. WebSphere plugin (which would be a peer to mod_jk) forwards the request to WebSphere 4. WebSphere executes a TAI (I forget what the acronym stands for) that is provided by the vendor (in this case CA) validate the request and provide WebSphere with the user's principal. Websphere also exposes its API to the TAI for retrieving user information for building the Principal object. 5. WebSphere executes it's security configuration as it executes the request It is a similar process for Oracle Access Manager and IBM Tivoli Access Manager as well with Oracle Weblogic. The critical point here is that if you swapped out any of the above Web Access Managers (or even replace them with Federation systems like Ping) you don't change how WebSphere RETRIEVES user information and do not need to recode the application. The only portion that gets changed is the third party integration tool. This was the intent of including security components in the Servlet API. Because the pluggable 3rd party agent handles that for you? So do I think Tomcat needs to support every WAM or Federation system? No, that would be completely unreasonable. Do I think that Tomcat should not require a re-coding of a component that has nothing to do with authentication when changing authentication systems? Yes. I do think that is reasonable. I think its reasonable that if I provide the authentication mechanism that Tomcat should be able to accept it and retrieve the user information without being forced to do the authentication on its own. Surely that's subjective, it depends entirely on the authentication authorization mechanism you want to use. I wouldn't expect Tomcat to be able to effect authorization when I've authenticated by Internet Telepathy(tm). (To pick a wildly unreasonable alternative) I want to be clear. I think Tomcat is a great product
Re: Setting JK_REMOTE_USER help
On Thu, Jun 17, 2010 at 9:11 AM, Mark Thomas ma...@apache.org wrote: On 17/06/2010 13:26, André Warnier wrote: I must say that, with my limited knowledge of the Tomcat internals taken into consideration, I tend to agree with Marc in this case, if he is right in claiming that the Tomcat Realm mixes authentication with authorization and does not allow to separate the two. That is how Tomcat Realms are designed. This is consistent with the Servlet sepc that leaves the implementation details entirely to the container. If Tomcat required all authentication requests to be made via carrier pigeon then that would be spec complaint providing the correct information was exposed via the API defined in the spec. Yes, it is as long as Tomcat is not combined with Apache or IIS. Once Tomcat offloads the authentication to Apache/IIS there should be a mechanism in place to still continue the authorization framework. At the very least, I would expect the Realm to check first if the request already has a user-id, and skip the authentication part in such a case. Easier said than done. The Realms deliberately have no visibility of the request or the response. The Authenticators extract the username and password, pass them to the realm to obtain an authenticated Principal (with roles) and then the Authenitcators populate the attributes that then support the calls in the Servlet API. The way to handle this (probably) is to modify the Authenticators (hopefully just the base class) to check for an already authenticated user. If one is found, use the realms just to get the roles. The implementation for that is already in place. It just needs adding to the interface and the visibility changed. Then you just need to figure out how to merge the existing Principal (that may have roles) with the new one that has the roles from the Realm. Tomcat 7's internal API has deliberately been declared as volatile inthe docs so now is the time to make these changes. Patches welcome. Note this won't get ported back to 6 due to the API changes required. I'll take a look at the tomcat 7 api and see what I can do. Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: POI/XML issues in server environment
2010/6/16 Jorge Moya jom...@gmail.com: Hello guys. (...) Now, I've established a long conversation with the POI userlist and came to the conclusion I'm having some issues with some of the .jar files and classes. (...) Java version is 1.5.0_18-b02 Windows version is Windows Server 2003 SP2 Tomcat version: 5.5.20 Libraries: *http://bit.ly/casaPs* Shared only has cewcanative.jar You have quite a mess of your libraries. Two different versions of commons-collections, log4j, wsdl4j, maybe others. I hope that Tomcat JARs are from the version that you are saying, and not some random mix. Note, that whatever JAR is listed first by operating system, will be placed first in the URLClassLoader classpath and will thus take precedence. The order provided by OS is arbitrary. (Though you are on Windows, and I think that I heard that NTFS sorts the names). David Fisher wrote: Here's what was determined. One of the webapps on his production server uses an older XercesImpl Jar in his endorsed directory. There are known caveats with XML libraries, starting with what is described in [1]. Some issues curable at Tomcat level were fixed in some later release. 5.5.20 is very old. [1] http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html I would suggest to configure a second Tomcat instance (*), and better of Tomcat 6, and migrate the applications there. If you are faced with such versions mess, it is recommended to keep all webapp libraries in their WEB-INF/lib. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Hi. I must say that, with my limited knowledge of the Tomcat internals taken into consideration, I tend to agree with Marc in this case, if he is right in claiming that the Tomcat Realm mixes authentication with authorization and does not allow to separate the two. Well, he said he's managed to make it work, so it must be possible to separate the two. I got it to work by writing custom code (namely I commented out the bind in the JNDIRealm). Thats OK for my own needs building a POC but I wouldn't use it in production. As far as I could tell, his major complaint was that it didn't just work 'out of the box' (but it needs a 3rd party agent in the other examples). He also threw in a complaint about contract violations which I didn't think was fair, or valid. So apparently you didn't actually READ what I wrote in my previous email. I would suggest you do as it is quite detailed and pinpoints exactly what my complaint is. At the very least, I would expect the Realm to check first if the request already has a user-id, and skip the authentication part in such a case. The Realm doesn't see the request at all. This is what the base problem probably is. The authentication mechanism doesn't have the conext to make decisions There are many cases out there were Tomcat is only a part of a more complex system, where a network-wide authentication is required, while the authorization part may still be one that only Tomcat can do. I don't think the Servlet Spec defines a situation where authentication and authorisation occur separately, but I'm happy to be corrected. No, it doesn't. It just defines an API that should work regardless. The Spec defines some methods of authentication authorization (BASIC, FORM, etc), and some objects associated with the request which describe some properties of an authenticated user principal, and it's roles. It also makes statements about what Containers must provide API wise, but it doesn't say how. Yes. Thats my point. It should be transparent. I (or any developer) that writes my app to the spec should not have to recode their applicatoin because the container doesn't handle a common configuration change such as externalizing authentication. I'd be happy to share how I was able to get this to work...where is the best place, the wiki? Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0 documentation: is classloading description correct?
Caldarale, Charles R chuck.caldar...@unisys.com wrote on 06/16/2010 09:55:19 PM: From: peter_f...@blm.gov [mailto:peter_f...@blm.gov] Subject: Re: Tomcat 6.0 documentation: is classloading description correct? The docs say in one place that the order is one way (WebApp first, then Boot, System and Common, which is as I'd expect) Please document where it says that; make sure not to ignore the sentence: There are exceptions. Also, don't assume that the complete list of exceptions is described in that paragraph rather than the bulleted list. The exceptions it gives are the ones I'd expect - no overriding JRE classes, servlet classes ignored, use of the endorsed override mechanism. I'm really more interested in the non-exceptional case of simply loading my application classes and those from third-party jars such as Apache Commons packages. I need confirmation that that second part of the documentation is in error (or not, of course). All parts of the classloader doc appear to be correct to me, also confirmed by a quick glance at the code. I don't see how that can be the case: When a request to load a class from the web application's WebappX class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking ... All other class loaders in Tomcat 6 follow the usual delegation pattern. But then it says, this, which describes a different search order: Bootstrap classes of your JVM System class loader classes (described above) /WEB-INF/classes of your web application /WEB-INF/lib/*.jar of your web application $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar They can't *both* be right. --Pete You might want to look at the API spec for the class of interest: http://tomcat.apache.org/tomcat-6.0- doc/api/org/apache/catalina/loader/WebappClassLoader.html - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
DefaultServlet and default character encoding
Hi, I have a character encoding problem with the DefaultServlet. We use it to serve static html content, which is encoded in utf-8. The DefaultServlet doesn't set characterset in the response, so the browser looks for a meta-tag describing the encoding. Luckily these are set in our content and the content is displayed correctly. So no problem... ...but if we have the same application behind an apache httpd-server connected with mod_jk, apache httpd thinks it would be better to append a charset to the response. In our case it takes a guess ( I guess ) and appends iso-8859-1 to the content-type header. Which in turn renders the meta-tag inside of the html useless and results in a wrong encoding/display in the browser. I have found an old discussion on this list where this problem was discussed (without the mod_jk part) http://old.nabble.com/DefaultServlet-doesn%27t-set-charset-td18893115.html#a18929527 My Question now is, should I file a bug to enhance DefaultServlet? If so would it be legal to include the patch from that discussion? For the moment I have written a filter, which sets a default encoding, as soon as Response.setContentType(String type) is called and type.startsWith(text/). That works for the moment, but I would prefer the solution described in above thread. Bye Felix - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Connector IIS7 Load balancing Issue (workers.properties)
Hello, I have a situation where my IIS tomcat load balancing configuration between 2 nodes keeps switching in every single request from the same browser. The JSESSIONID changes every time I hit refresh on the browser because it switches between the 2 nodes each time. This was working at some point correctly where once a connection was established with a node, the connection stayed on that node until the browser was closed. Has anyone seen this problem before? Any help would be greatly appreciated. My workers.properties file looks like this: worker.list=loadbalancer,status worker.template.port=8009 worker.template.type=ajp13 worker.template.lbfactor=1 worker.template.ping_mode=A worker.template.socket_timeout=10 worker.template.connection_pool_timeout=600 worker.node1.reference=worker.template worker.node1.host=128.1.1.30 worker.node1.cachesize=10 worker.node2.reference=worker.template worker.node2.host=128.1.2.30 worker.node2.cachesize=10 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=1 worker.status.type=status Thank you, Luis Esquivel
Re: Tomcat 6.0 documentation: is classloading description correct?
2010/6/16 peter_f...@blm.gov: Looking at section 10 of the 6.0 user guide, which describes classloading, the text makes perfect sense and matches the way I understand things work. However the summary at the end of the section Class Loader Definitions looks wrong; it basically says that the search order is... Bootstrap $CLASSPATH WEB-INF/classes WEB-INF/lib/*.jar $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar ...when my understanding is it should be... WEB-INF/classes WEB-INF/lib/*.jar Bootstrap $CLASSPATH $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar So, is the documentation just wrong, or have I misunderstood something? The order is Bootstrap $CLASSPATH WEB-INF/classes WEB-INF/lib/*.jar $CATALINA_BASE/lib $CATALINA_BASE/lib/*.jar $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar as documented. Note, that many Bootstrap and $CLASSPATH classes are loaded at early stages of Tomcat startup sequence, that is before classloading hierarchy itself is created. It would be a mess if those classes were ignored. That is why people should not play with $CLASSPATH, unless in certain very rare cases. If you have some documentation changes in your mind, the patches are welcome. The sources are in webapps/docs/*.xml . Create a Bugzilla issue and attach a diff file there (svn diff or an 'Unified diff' (diff -u)). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 64 bits, Java 6 64 bits and -Djava.library.path
Hi all, I have some strange issues: Enviroment: Windows 2003 R2 64 bits with Tomcat6 6.0.24 and Java6 1.6.0_20 64bits. If I have some libraries that need to be loaded at startup so I've added in catalina.bat: JAVA_OPTS=%JAVA_OPTS% -Djava.library.path=C:\libs, start tomcat with startup.bat, everything ok. After that I've changed service.bat adding at the very end of file: %EXECUTABLE% //US//%SERVICE_NAME% ++JvmOptions -Djava.library.path=C:\libs;..., install widnows service: service.bat install and start tomcat. Tomcat didn't load libraries from java.library.path. So, it's working only if I start tomcat from startup.bat but not if I install it as windows service. Any sugestions? Best regards, Katt -- Katt
Re: NewBie! Need Help to configure FTP/Domain...
Alan Coyne wrote: Hi All, I'm new to TomCat however I have managed to get JDK setup and Tomcat 6 running on Linux 64bit server. I've deployed an app via WAR file and all looks good. So all that remains for me to do is confirgure a domain name to use the server and be able to FTP to the installed app folder. I've been searching and digging but am a bit lost at this stage. If anyone can point me in the right direction it would be great. Hi. Configuring an FTP server under some Linux OS in order to allow the uploading of files to a directory, and doing this securely, is not exactly the purpose of this list. You would better served asking on the help list of your Linux distribution. However, if your purpose is to be able to deploy new/updated Tomcat applications from a remote location, and you can load your applications as war-files, then you do not necessarily need FTP, and could do this via the Tomcat Manager application. Under some Linux(es), this may be a separate package to install, e.g. with Debian there are these packages for Tomcat 5.5 : tomcat5.5 - Servlet and JSP engine tomcat5.5-admin - Java Servlet engine -- admin manager web interfaces tomcat5.5-webapps - Java Servlet engine -- documentation and example web applications where the 2d one would be the one you need. There must be the same available for Tomcat 6.0.x, but not on my system right now. Here is the documentation : http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
On 17/06/2010 15:08, Marc Boorshtein wrote: Hi. I must say that, with my limited knowledge of the Tomcat internals taken into consideration, I tend to agree with Marc in this case, if he is right in claiming that the Tomcat Realm mixes authentication with authorization and does not allow to separate the two. Well, he said he's managed to make it work, so it must be possible to separate the two. I got it to work by writing custom code (namely I commented out the bind in the JNDIRealm). Thats OK for my own needs building a POC but I wouldn't use it in production. As far as I could tell, his major complaint was that it didn't just work 'out of the box' (but it needs a 3rd party agent in the other examples). He also threw in a complaint about contract violations which I didn't think was fair, or valid. So apparently you didn't actually READ what I wrote in my previous email. I would suggest you do as it is quite detailed and pinpoints exactly what my complaint is. Steady now. You might not like my take on it, but I read it. At the very least, I would expect the Realm to check first if the request already has a user-id, and skip the authentication part in such a case. The Realm doesn't see the request at all. This is what the base problem probably is. The authentication mechanism doesn't have the conext to make decisions There are many cases out there were Tomcat is only a part of a more complex system, where a network-wide authentication is required, while the authorization part may still be one that only Tomcat can do. I don't think the Servlet Spec defines a situation where authentication and authorisation occur separately, but I'm happy to be corrected. No, it doesn't. It just defines an API that should work regardless. That's a fairly sweeping statement you've made there. The Spec defines some methods of authentication authorization (BASIC, FORM, etc), and some objects associated with the request which describe some properties of an authenticated user principal, and it's roles. It also makes statements about what Containers must provide API wise, but it doesn't say how. Yes. Thats my point. It should be transparent. It is. You've still got to plug something into the back of the API to make it do what you want. If what you want is something complicated then maybe Tomcat won't do that without modification, as you've found. I (or any developer) that writes my app to the spec should not have to recode their applicatoin because the container doesn't handle a common configuration change such as externalizing authentication. You're talking about having to change your app, but you've only described having to make modifications to a Tomcat internal support class. You seem to be saying that Tomcat has a compliancy issue - IMO the problem with leaving that unchallenged is that it breeds misunderstanding that would land back here sometime later. I don't think it's reasonable to mix an argument about spec compliancy with an point about something that isn't covered by the spec - even if it is a common requirement. I'd be happy to share how I was able to get this to work...where is the best place, the wiki? Yep. p (Enough now.) Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: DefaultServlet and default character encoding
On 17/06/2010 15:23, Felix Schumacher wrote: My Question now is, should I file a bug to enhance DefaultServlet? If so would it be legal to include the patch from that discussion? That is covered by section 5 of the ALv2, so yes it would be legal. Make sure you correctly attribute it. I'd add the link, not the actual patch. Whilst this would be legal the ASF normally goes further and only includes patches that were intentionally contributed. Even if we legally could, we don't want to use someones code of they don't want us to. In this case - having read the thread - I would say that it was definitely a contribution so would have no problem applying the patch. I would add that if the patch had been added to a new bugzilla item, there is a good chance it would be in the code base already. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
You're talking about having to change your app, but you've only described having to make modifications to a Tomcat internal support class. You seem to be saying that Tomcat has a compliancy issue - IMO the problem with leaving that unchallenged is that it breeds misunderstanding that would land back here sometime later. I don't think it's reasonable to mix an argument about spec compliancy with an point about something that isn't covered by the spec - even if it is a common requirement. We can agree to disagree on this one. Either way Tomcat 6 can not support a very common pattern in application deployment. I think it would be valuable for Tomcat to support this model and will work on I'll take a look at the 7 code to see how I can help. Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DefaultServlet and default character encoding
2010/6/17 Felix Schumacher felix.schumac...@internetallee.de: For the moment I have written a filter, which sets a default encoding, as soon as Response.setContentType(String type) is called and type.startsWith(text/). That works for the moment, but I would prefer the solution described in above thread. I know that setting charset in a mime-mapping works, e.g.: mime-mapping extensionhtm/extension mime-typetext/html;charset=iso-8859-1/mime-type /mime-mapping mime-mapping extensionhtml/extension mime-typetext/html;charset=iso-8859-1/mime-type /mime-mapping Note, that it would be better if the mime type set by a HTTP header and the one provided by HTML tag match strictly (case sensitively). Otherwise some browsers will start guessing. IIRC, the HTML spec says that the HTTP header takes precedence, but not all browsers follow it strictly. Also there is AddDefaultCharsetFilter in Tomcat 7. It is similar to what you are doing, see its JavaDoc and source code. apache httpd thinks it would be better to append a charset to the response I wonder, if there is a way to improve your Apache HTTPD configuration. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Resource Annotation has no effect but JNDI Lookup works (JDBC Resource)
@gurkan Chris: actually I don't want to use the resource directly in a servlet or JSP - due to architectural reasons - so is there a way to inject resources into plain java classes? @Pid: Thanks for the Information. I will check out the spec and hope that it is not too much to read ;-) And thanks a again for all the hints -- View this message in context: http://old.nabble.com/Resource-Annotation-has-no-effect-but-JNDI-Lookup-works-%28JDBC-Resource%29-tp28900220p28916019.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector IIS7 Load balancing Issue (workers.properties)
check your windows NLB affinity setting for the cluster, should be set to single. Sounds like it's off. Luis Esquivel wrote: Hello, I have a situation where my IIS tomcat load balancing configuration between 2 nodes keeps switching in every single request from the same browser. The JSESSIONID changes every time I hit refresh on the browser because it switches between the 2 nodes each time. This was working at some point correctly where once a connection was established with a node, the connection stayed on that node until the browser was closed. Has anyone seen this problem before? Any help would be greatly appreciated. My workers.properties file looks like this: worker.list=loadbalancer,status worker.template.port=8009 worker.template.type=ajp13 worker.template.lbfactor=1 worker.template.ping_mode=A worker.template.socket_timeout=10 worker.template.connection_pool_timeout=600 worker.node1.reference=worker.template worker.node1.host=128.1.1.30 worker.node1.cachesize=10 worker.node2.reference=worker.template worker.node2.host=128.1.2.30 worker.node2.cachesize=10 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=1 worker.status.type=status Thank you, Luis Esquivel - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0 documentation: is classloading description correct?
On 17.06.2010 16:37, Konstantin Kolinko wrote: 2010/6/16peter_f...@blm.gov: Looking at section 10 of the 6.0 user guide, which describes classloading, the text makes perfect sense and matches the way I understand things work. However the summary at the end of the section Class Loader Definitions looks wrong; it basically says that the search order is... Bootstrap $CLASSPATH WEB-INF/classes WEB-INF/lib/*.jar $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar ...when my understanding is it should be... WEB-INF/classes WEB-INF/lib/*.jar Bootstrap $CLASSPATH $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar So, is the documentation just wrong, or have I misunderstood something? The order is Bootstrap $CLASSPATH WEB-INF/classes WEB-INF/lib/*.jar $CATALINA_BASE/lib $CATALINA_BASE/lib/*.jar $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar as documented. Note, that many Bootstrap and $CLASSPATH classes are loaded at early stages of Tomcat startup sequence, that is before classloading hierarchy itself is created. It would be a mess if those classes were ignored. That is why people should not play with $CLASSPATH, unless in certain very rare cases. If you have some documentation changes in your mind, the patches are welcome. The sources are in webapps/docs/*.xml . Create a Bugzilla issue and attach a diff file there (svn diff or an 'Unified diff' (diff -u)). I guess part of the confusion comes from the terminology parent and delegating. The classloader used by the webapps is derived from the usual URLClassloader as an extension. In Tomcat land it's parent is the classloader that loads from the common lib directory. The webapp classloader is not delegating first in the sense that it first tries to find classes via it's own super URLClassloader, before asking the parent common loader. The URLClassloader in turn is the one, that first goes down to bootstrap and system/CLASSPATH before checking the configured URLs (WEB-INF). So in Tomcat terminology it's true, that the webapp classloader does only delegate (to common) if it can't find the class, but the webapp loader itself does delegate to bootstrap and system first. (hope that's true and not too confusing ...) Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SOLVED, workaround] Why my web application automatically switchs to https?
Ok, it turned out to be either a bug (or a wrong configuration) of the
environment I was working with (GIS + embedded Jetty).
So, I ended up working around it. I write it down; hope it can be useful
for someone else.
The workaround is Jetty specific, but the same approach can be used with
Tomcat.
I've ended up applying a Filter, to manipulate the wrong request object
coming from the container.
Here are the few lines of code for the filter:
public class PlainHttpFilter implements Filter {
public void init(FilterConfig filterConfig) throws ServletException {
this.filterConfig = filterConfig;
}
public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain) throws IOException, ServletException {
// Begin workaround
Request jettyRequest =
Request.getRequest((HttpServletRequest)request);
jettyRequest.setScheme(http);
// End workaround
chain.doFilter(jettyRequest, response);
}
public void destroy() {
this.filterConfig = null;
}
}
where the jettyRequest is an instance of org.mortbay.jetty.Request; just
use the Tomcat implementation of HttpServletRequest
http://api.dpml.net/javax/servlet/2.5/javax/servlet/http/HttpServletRequest.html?is-external=true.
Luca
Il 11/06/2010 18:03, Pid ha scritto:
On 11/06/2010 15:53, Luca Fagioli wrote:
Il 11/06/2010 16:01, Caldarale, Charles R ha scritto:
From: Pid [mailto:p...@pidster.com]
Subject: Re: Why my web application automatically switchs to https?
Exact Tomcat, JVM, OS versions?
Are you using HTTPD/IIS as well?
Does the HTML contain hardcoded URLs?
Are you using a framework like Struts?
And are you running Tomcat under Eclipse or some other IDE? (Those
often use their own configurations, ignoring what you've specified.)
Which web.xml was changed? (Modifying the one in tomcat's conf
directory would be a mistake.)
Post the complete WEB-INF/web.xml from your webapp.
- Chuck
Thank you guys,
but the problem starts to be even more complicated. The application i've
started to working with is running in the Sterling Integrator (Gentran
Integration Suite) environment, and turned out that its servlet
container is not Tomcat, but Jetty.
I'm in a big trouble, i think. I've posted the same question in the
Jetty users list, but less traffic out there.
By the way, this is the web.xml of the application:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application
2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd;
web-app
display-nameCedacri Web/display-name
filter
filter-nameSessionExpiredFilter/filter-name
filter-classcom.innovery.cedacri.servlets.SessionExpiredFilter/filter-class
/filter
filter-mapping
filter-nameSessionExpiredFilter/filter-name
url-pattern/*/url-pattern
/filter-mapping
servlet
servlet-namedispatcherAN/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherANAGRAFICA/servlet-class
/servlet
servlet
servlet-namedispatcherSE/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherSERVERS/servlet-class
/servlet
servlet
servlet-namedispatcherIN/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherINCOMING/servlet-class
/servlet
servlet
servlet-namedispatcherOU/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherOUTGOING/servlet-class
/servlet
servlet
servlet-namedispatcherOUI/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherOUTGOINGISTITUTI/servlet-class
/servlet
servlet
servlet-namedispatcherCO/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherCONFIGURAZIONI/servlet-class
/servlet
servlet
servlet-namedispatcherDE/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherDEPOSITO/servlet-class
/servlet
servlet
servlet-namedispatcherRE/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherRECUPERO/servlet-class
/servlet
servlet
servlet-namedispatcherFI/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherFILIALI/servlet-class
/servlet
servlet
servlet-namedispatcherII/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherINCOMINGISTITUTI/servlet-class
/servlet
servlet
servlet-namedispatcherTJ/servlet-name
servlet-classcom.innovery.cedacri.servlets.RequestDispatcherTEMPLATEJCL/servlet-class
/servlet
servlet
servlet-nameLogout/servlet-name
servlet-classcom.innovery.cedacri.servlets.Logout/servlet-class
/servlet
servlet-mapping
servlet-namedispatcherAN/servlet-name
url-pattern/dispatcherAN/url-pattern
/servlet-mapping
servlet-mapping
servlet-namedispatcherSE/servlet-name
url-pattern/dispatcherSE/url-pattern
/servlet-mapping
servlet-mapping
servlet-namedispatcherIN/servlet-name
url-pattern/dispatcherIN/url-pattern
/servlet-mapping
servlet-mapping
servlet-namedispatcherOU/servlet-name
url-pattern/dispatcherOU/url-pattern
/servlet-mapping
Re: Connector IIS7 Load balancing Issue (workers.properties)
On 17.06.2010 16:33, Luis Esquivel wrote: Hello, I have a situation where my IIS tomcat load balancing configuration between 2 nodes keeps switching in every single request from the same browser. The JSESSIONID changes every time I hit refresh on the browser because it switches between the 2 nodes each time. This was working at some point correctly where once a connection was established with a node, the connection stayed on that node until the browser was closed. Has anyone seen this problem before? Any help would be greatly appreciated. My workers.properties file looks like this: worker.list=loadbalancer,status worker.template.port=8009 worker.template.type=ajp13 worker.template.lbfactor=1 worker.template.ping_mode=A worker.template.socket_timeout=10 worker.template.connection_pool_timeout=600 worker.node1.reference=worker.template worker.node1.host=128.1.1.30 worker.node1.cachesize=10 worker.node2.reference=worker.template worker.node2.host=128.1.2.30 worker.node2.cachesize=10 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=1 worker.status.type=status Versions of the redirector and Tomcat? This configuration looks very outdated. You should do yourself a favour and switch to a recent version of the redirector and also have an extended look at the example configuration that comes with the source download. To make load balancing work, each Tomcat needs to have an individual jvmRoute set in server.xml and the workers in the balancers need to have names equal to the jvmRoute of the Tomcat they are pointing to. Here the worker names are node1 and node2, so those values should be set as jvmRoute in the respective server.xml. Apart from that look at the redirector logs whether there are errors reported there. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: disabling copy of context.xml to conf/Catalina/localhost
Thanks for the response pid. I am using Tomcat 6.0.26 with java 1.6 on Windows XP. I have two applications (application AU and AC) under same webapps. AC does not have a context.xml though AU has. There is a dependency between AU and AC and AC need to be started first at start up. When I deployed both the applications first time it worked fine. AC started first and then AU. Also context.xml of AU was copied to conf/Catalina/localhost. Now when I shutdown tomcat and start it again tomcat tries to start AU first and it fails, becuase it need AC to be up. There are two options I have: 1) Disable copy of context.xml to conf/Catalina/localhost 2) Add a blank context.xml for AC One more thing, this was working fine on Tomcat 6.0.18. Thanks for your help. Raj On Wed, Jun 16, 2010 at 4:49 PM, Rajeev Verma r.v.raj...@gmail.com wrote: Hi, I am facing a problem which can be solved if I can disable copy of context.xml to conf/Catalina/localhost. Is there some setting to do so? Thanks for the help. Regards, Raj -- Thanks and Regards, Rajeev Verma Cell: 602 326 8615
RE: Setting the Right Amount of Memory
Time to hit the vendor around the head with the cluebat. If the app is happy with less heap space then increasing it is only going to cause problems - mainly that GC when it happens will take longer and trigger longer pauses. You can mitigate this with GC config (later VMs may make the right choices for you anyway) but all this is just adding unnecessary complexity. I agree completely. I wish the vendor accepted feedback like this. Unfortunately if you try to show them a better way, they tend to get defensive and think of you as a troublemaker. :-( -- Eric Robinson Disclaimer - June 17, 2010 This email and any files transmitted with it are confidential and intended solely for Tomcat Users List. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of . Warning: Although has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Issues changing log4j levels for tomcat web apps
Hi Everyone, This question might be a little off topic, but I thought since it involved tomcat web apps, I figured someone might know the answer. I have Liferay EE 5.2.6 running on top of tomcat 6.0.26. Liferay has an admin GUI page to allows me to change log level settings for different packages. The issue I'm facing is changing the log levels seems to only take effect on the ROOT web apps. All the other plugin web apps do not seem to response to the new log levels. I checked on Liferay support forums and found that others are also facing this problem (http://www.liferay.com/community/forums/-/message_boards/message/492284 1) Is this really Liferay's specific problem or is it Tomcat issue in general? In plain vanilla Tomcat, are the web apps loaded in a WebAppClassLoader and ROOT web app is loaded by StandardClassLoader? If so, I assume this is really just an issue with Tomcat right? How do I get around this problem? In a previous project I worked with, we relied on DB change notification to relay the new log level to all tomcat web apps. However, I don't want to consider that solution because it requires design changes and it has its own set of problem. Any pointers would be much appreciated! Thanks in advance! Regards, - Jeffrey Nguyen
Re: Resource Annotation has no effect but JNDI Lookup works (JDBC Resource)
Then you have to use InitialContext # lookup(java:/comp/env/_Resource_Id_In_your_web_Xml). As we said, if you want to inject dependencies to your classes, those classes must be known by the container. --Gurkan From: marble4u marco.blev...@energy4u.org To: users@tomcat.apache.org Sent: Thu, June 17, 2010 6:37:56 PM Subject: Re: Resource Annotation has no effect but JNDI Lookup works (JDBC Resource) @gurkan Chris: actually I don't want to use the resource directly in a servlet or JSP - due to architectural reasons - so is there a way to inject resources into plain java classes? @Pid: Thanks for the Information. I will check out the spec and hope that it is not too much to read ;-) And thanks a again for all the hints -- View this message in context: http://old.nabble.com/Resource-Annotation-has-no-effect-but-JNDI-Lookup-works-%28JDBC-Resource%29-tp28900220p28916019.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0 documentation: is classloading description correct?
Ok, the problem is my misunderstanding of the process here. I thought WebAppClassLoader always checked WEB-INF/lib before delegating; I see that it actually delegates to the System loader first, then checks WEB-INF/lib, and finally delegates to its own parent. So my comment earlier about they can't both be right was of course wrong - not only *can* they be both right, they *are* :) This explains the technical problem I've been chasing; I'll have it fixed in a jiffy now. Thanks all. --Pete Konstantin Kolinko knst.koli...@gmail.com wrote on 06/17/2010 08:37:56 AM: 2010/6/16 peter_f...@blm.gov: Looking at section 10 of the 6.0 user guide, which describes classloading, the text makes perfect sense and matches the way I understand things work. However the summary at the end of the section Class Loader Definitions looks wrong; it basically says that the search order is... Bootstrap $CLASSPATH WEB-INF/classes WEB-INF/lib/*.jar $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar ...when my understanding is it should be... WEB-INF/classes WEB-INF/lib/*.jar Bootstrap $CLASSPATH $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar So, is the documentation just wrong, or have I misunderstood something? The order is Bootstrap $CLASSPATH WEB-INF/classes WEB-INF/lib/*.jar $CATALINA_BASE/lib $CATALINA_BASE/lib/*.jar $CATALINA_HOME/lib $CATALINA_HOME/lib/*.jar as documented. Note, that many Bootstrap and $CLASSPATH classes are loaded at early stages of Tomcat startup sequence, that is before classloading hierarchy itself is created. It would be a mess if those classes were ignored. That is why people should not play with $CLASSPATH, unless in certain very rare cases. If you have some documentation changes in your mind, the patches are welcome. The sources are in webapps/docs/*.xml . Create a Bugzilla issue and attach a diff file there (svn diff or an 'Unified diff' (diff -u)). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues changing log4j levels for tomcat web apps
On 17.06.2010 19:44, Jeffrey Nguyen (jeffrngu) wrote: This question might be a little off topic, but I thought since it involved tomcat web apps, I figured someone might know the answer. I have Liferay EE 5.2.6 running on top of tomcat 6.0.26. Liferay has an admin GUI page to allows me to change log level settings for different packages. The issue I'm facing is changing the log levels seems to only take effect on the ROOT web apps. All the other plugin web apps do not seem to response to the new log levels. I checked on Liferay support forums and found that others are also facing this problem (http://www.liferay.com/community/forums/-/message_boards/message/492284 1) Is this really Liferay's specific problem or is it Tomcat issue in general? In plain vanilla Tomcat, are the web apps loaded in a WebAppClassLoader and ROOT web app is loaded by StandardClassLoader? If so, I assume this is really just an issue with Tomcat right? How do I get around this problem? In a previous project I worked with, we relied on DB change notification to relay the new log level to all tomcat web apps. However, I don't want to consider that solution because it requires design changes and it has its own set of problem. Any pointers would be much appreciated! Thanks in advance! The root context isn't special with respect to class loading. Each context has its own webapp classloader. What that means with respect to log configuration depends on the log frameworks used by the web applications, and how the frameworks are deployed. Often the webapps for example use log4j and each webapp contains a copy of the log4j jar file. That means each webapp would have its own copy of log4j and a completely independent configuration. If log4j would instead be deployed *only* via a shared loader (like the common loader), then all webapps would share a single instance and a single configuration. You can force log4j (example) to use a common configuration for all instances during startup by using the -Dlog4j.configuration=SOMEURL commandline parameter, but that doesn't help with later dynamic changes. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP connector to be aware of proxied SSL requests
Hello Matt, I think the RemoteIpValve does what you need : it looks at http headers filled in the request by preceding network components (layer 7 load balancer, ssl accelerator, etc) such as 'x-forwarded-for' to get the real ip address and 'x-forwarded-proto' to get the http/https protocol. A concept of internal/trusted incoming proxies is used to decide weither the http headers can be trusted or not. Configuration is detailed in the javadocs : http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html The documentation of RemoteIpValve has been enhanced in Tomcat 7 to integrate the content of the java doc. I wrote a blog post in french to explain how it works with detailed diagrams here : http://blog.xebia.fr/2009/11/13/tomcat-ssl-communications-securisees-et-x-forwarded-proto/ Basically, if you want to trust http header x-forwarded-for and x-forwarded-proto coming from LB/web-server 192.168.0.10 and 192.168.0.11, the valve configuration will look like : Server ... ... Service name=Catalina Connector ... / Engine ... !-- Process X-Forwarded-For to get remote address and X-Forwarded-Proto to identify SSL requests -- Valve className=org.apache.catalina.valves.RemoteIpValve internalProxies=192\.168\.0\.10, 192\.168\.0\.11 protocolHeader=X-Forwarded-Proto / !-- AccessLogValve must be declared after RemoteIpValve to get the remote address and the scheme https/http -- Valve className=org.apache.catalina.valves.AccessLogValve directory=logs pattern=common prefix=access_log. resolveHosts=false suffix=.txt / ... /Host /Engine /Service /Server Please note that you can simplify the configuration omitting 'internalProxies' attribute and rely on the default that trusts all the class A, B C private IP addresses. Hope this helps, Cyrille -- Cyrille Le Clerc clecl...@xebia.fr http://blog.xebia.fr On Thu, Jun 17, 2010 at 2:41 AM, Matt Peterson matt.peter...@une.edu.au wrote: Hi All, We have a hardware load balancer terminating SSL requests before making a plain-text connection with Tomcat. So that all contexts are aware that the request is actually a secure request, we have implemented the RemoteIpValve with a LB injected header. This works well for our apps. However, we have noticed that there is some processing of the request happening within the connector, before the valves are processed. In particular, the redirecting to URLs with a trailing slash. Because this processing is occurring before the valves are processed the Connector still thinks that the original request was a non-secure one, even though it was not. The result is that requests to https://domain.name/context are redirected to http://domain.name/context/ instead of to https://domain.name/context/. This is not major, because our LB then redirects from http://domain.name/context/ to https://domain.name/context/ and all is good (except for the extra redirect). I can't find any documentation on the order of events for the Connector, so I'm not sure what other decisions get made based on the request attributes, but assume there are others. Is there another solution to handling proxied SSL requests so that Catalina as well as our apps are aware that the requests are secure??? One possibility is to have two Connectors (1 using the secure, scheme and serverPort attributes for secure and 1 for non-secure) and have the LB connect to the appropriate Connector depending on the request. But this effectively doubles the amount of config needed to be managed (2nd set of config for LB + 2nd connector), which is considerable when dealing with 6 TC clusters each with their own set of LB config. Should I lodge an enhancement request for the Connector to become aware of proxied SSL requests (perhaps via an injected x-forwarded-proto header, ala WebLogic)? Cheers, Matt. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HTTP connector to be aware of proxied SSL requests
This is *open* source... Thx Capt. Obvious - very helpful ;-) OK, so I now understand why it was chosen to perform the redirection in the Connector rather than in a Valve; to remove unnecessary processing keeping the redirect response as efficient as possible. I might lodge an enhancement for the connector to have the redirect configurable so that it can be disabled via an element attribute. The redirecting can then be done as a valve instead. We are using an F5 LB which does not support AJP. So that option will not work for us. The other option of using multiple HTTP Connectors is doable, but adds a lot of config management overhead (and points of possible failure/error) which is not very popular with those responsible for that management. But that is an internal issue which I need to deal with if this prob is deemed to be worth the worry. Out of interest, what are some of the security risks around non-trusted proxies injecting the x-forwarded-* headers? Thanks for your help, Matt. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, 17 June 2010 10:28 PM To: Tomcat Users List Subject: Re: HTTP connector to be aware of proxied SSL requests On 17/06/2010 01:41, Matt Peterson wrote: I can't find any documentation on the order of events for the Connector, so I'm not sure what other decisions get made based on the request attributes, but assume there are others. This is *open* source... Is there another solution to handling proxied SSL requests so that Catalina as well as our apps are aware that the requests are secure??? One possibility is to have two Connectors (1 using the secure, scheme and serverPort attributes for secure and 1 for non-secure) and have the LB connect to the appropriate Connector depending on the request. But this effectively doubles the amount of config needed to be managed (2nd set of config for LB + 2nd connector), which is considerable when dealing with 6 TC clusters each with their own set of LB config. The other option would be to proxy using AJP rather than HTTP (if the load-balancer supports it) since AJP passes SSL info as part of the protocol. If you want to use mixed HTTP/HTTPS in the LB and just HTTP on Tomcat than multiple connectors is usually what I'd recommend. Should I lodge an enhancement request for the Connector to become aware of proxied SSL requests (perhaps via an injected x-forwarded-proto header, ala WebLogic)? You can, not sure how much traction it would get. Both the logic and configuration is non-trivial to ensure only trusted proxies set the header. We try to keep the connector code fairly slick. This feels like more than we would want to add (bearing in mind this is just instinct - I haven't looked at any code at ths point). You might have better luck with an option to defer the redirection with the / to later in the processing chain. That would be simpler to implement but would add some extra processing that currently is bypassed by doing the rediection as early as possible. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HTTP connector to be aware of proxied SSL requests
Hi Cyrille, We have the RemoteIpValve implemented already, thanks. The behaviour we are seeing is occurring in the Connector, before the request even reaches the valves. In this case, the request never reaches the valves as the redirect is done within the connector. Cheers, Matt. -Original Message- From: Cyrille Le Clerc [mailto:clecl...@xebia.fr] Sent: Friday, 18 June 2010 8:30 AM To: Tomcat Users List; Matthew Peterson Subject: Re: HTTP connector to be aware of proxied SSL requests Hello Matt, I think the RemoteIpValve does what you need : it looks at http headers filled in the request by preceding network components (layer 7 load balancer, ssl accelerator, etc) such as 'x-forwarded-for' to get the real ip address and 'x-forwarded-proto' to get the http/https protocol. A concept of internal/trusted incoming proxies is used to decide weither the http headers can be trusted or not. Configuration is detailed in the javadocs : http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html The documentation of RemoteIpValve has been enhanced in Tomcat 7 to integrate the content of the java doc. I wrote a blog post in french to explain how it works with detailed diagrams here : http://blog.xebia.fr/2009/11/13/tomcat-ssl-communications-securisees-et-x-forwarded-proto/ Basically, if you want to trust http header x-forwarded-for and x-forwarded-proto coming from LB/web-server 192.168.0.10 and 192.168.0.11, the valve configuration will look like : Server ... ... Service name=Catalina Connector ... / Engine ... !-- Process X-Forwarded-For to get remote address and X-Forwarded-Proto to identify SSL requests -- Valve className=org.apache.catalina.valves.RemoteIpValve internalProxies=192\.168\.0\.10, 192\.168\.0\.11 protocolHeader=X-Forwarded-Proto / !-- AccessLogValve must be declared after RemoteIpValve to get the remote address and the scheme https/http -- Valve className=org.apache.catalina.valves.AccessLogValve directory=logs pattern=common prefix=access_log. resolveHosts=false suffix=.txt / ... /Host /Engine /Service /Server Please note that you can simplify the configuration omitting 'internalProxies' attribute and rely on the default that trusts all the class A, B C private IP addresses. Hope this helps, Cyrille -- Cyrille Le Clerc clecl...@xebia.fr http://blog.xebia.fr On Thu, Jun 17, 2010 at 2:41 AM, Matt Peterson matt.peter...@une.edu.au wrote: Hi All, We have a hardware load balancer terminating SSL requests before making a plain-text connection with Tomcat. So that all contexts are aware that the request is actually a secure request, we have implemented the RemoteIpValve with a LB injected header. This works well for our apps. However, we have noticed that there is some processing of the request happening within the connector, before the valves are processed. In particular, the redirecting to URLs with a trailing slash. Because this processing is occurring before the valves are processed the Connector still thinks that the original request was a non-secure one, even though it was not. The result is that requests to https://domain.name/context are redirected to http://domain.name/context/ instead of to https://domain.name/context/. This is not major, because our LB then redirects from http://domain.name/context/ to https://domain.name/context/ and all is good (except for the extra redirect). I can't find any documentation on the order of events for the Connector, so I'm not sure what other decisions get made based on the request attributes, but assume there are others. Is there another solution to handling proxied SSL requests so that Catalina as well as our apps are aware that the requests are secure??? One possibility is to have two Connectors (1 using the secure, scheme and serverPort attributes for secure and 1 for non-secure) and have the LB connect to the appropriate Connector depending on the request. But this effectively doubles the amount of config needed to be managed (2nd set of config for LB + 2nd connector), which is considerable when dealing with 6 TC clusters each with their own set of LB config. Should I lodge an enhancement request for the Connector to become aware of proxied SSL requests (perhaps via an injected x-forwarded-proto header, ala WebLogic)? Cheers, Matt. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Application stops responding, jk worker in error state
Hello: I have Tomcat 6.0.26 running behind Apache and am using the JK Connector to communicate between them. My application stops responding on occasion. I added the jk status page to the web server and checked it when the application becomes non-responsive. The tomcat worker has this info: Worker Status for tomcat Type Hostname Address:Port Connection Pool Timeout Connect Timeout Prepost Timeout Reply Timeout Retries Recovery Options Max Packet Size ajp13 localhost 127.0.0.1:8009 600 0 0 0 2 0 State Acc Err CE RE Wr Rd Busy Max LR LE ERR 6 (0/sec) 2 0 0 4.8K (7 /sec) 12K (18 /sec) 0 2 663 Fri, 18 Jun 2010 00:06:17 CDT Note the state is ERR. Does this mean the worker crashed or does it mean my application is locked up? Any ideas how to diagnose this? Thanks, Neil -- Neil Aggarwal, (281)846-8957 FREE trial: Virtualmin VPS with unmetered bandwidth http://UnmeteredVPS.net/virtualmin - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
