mod_jk not working !!
m trying to do a setup of tomcat clustering in which one tomcat is on port 8080 and other one is on 8081. i have downloaded the tomcat-connector in the modules folder of my apache.i built it using build-unix.sh by downloading the script from net as it was nt already there in the downloaded tomcat-connector. it buit mod_jk.so which i have placed inside modules folder as /usr/local/apache2/modules/mod_jk.so then i created workers.properties file and gave the description of workers there .and included it in httpd.cong file . still when i type http://localhost/jsp-pages which are in my webapps / it is not passing requast to tomcat which is holding the js pages. you may hav a look at the conf files to get a better fel of the problem ! the link is http://www.coderanch.com/t/581294/Tomcat/Tomcat-Clustering#2648034
Re: jk 1.2.36 throwing 503/sendfull/cping errors
On 05/24/2012 09:40 PM, Anthony J. Biacco wrote: I'm still puzzled as to why this behavior just changed between .35 and .36 OK, but if you follow the recommended configuration by making sure that workers which are members of lb are not listed inside worker.list, does it works? Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user switching or application interacting with container based authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dirk, On 5/24/12 4:51 PM, dirk ooms wrote: > changing a user object in the session is something i already did. I misspoke: SF stores the /user principal/ in the session. When you change that, the identity of the current user (roles and all) changes. Note that this is *not* container-managed security. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk++21oACgkQ9CaO5/Lv0PAd7ACff4eeBaBZVryXqmG3/Shj62hJ /hIAn3thz6husf/WnbJ4HYwCxNW+J82J =mWc5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user switching or application interacting with container based authentication
> > > > How about your barcode (or card or whatever) idea, to allow users to switch > id on-the-fly > ? I am curious as to how you implement that. after some user has logged in in a 'normal/standard' way (using e.g. form-based, container-managed), there is a text input field in the header of the secured web page. if another user scans his personal barcode which could be e.g. a hash of his username and his hashed password into this field, there will be a switch to this new user (just by setting its 'user object' in the session). to validate this hash, the application just loops over the limited number of users of that specific (small) company to find a match. the container is no longer involved in authorization, the existing session is reused by the new user. this method has the advantage that one can only switch between users of the same 'company/shop' and that someone of that company must have logged in in a standard way before any user switching becomes possible. dirk > > - > 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: user switching or application interacting with container based authentication
dirk ooms wrote: Chris, Andre, thanks for sharing your thoughts, it helped me to see things more clear. changing a user object in the session is something i already did. the problem with this was (and which was triggering my initial question) is that a new user could have access rights to more functionality than the first user, but that the access to this functionality is blocked by the container because of the role based security constraints i have defined in web.xml (the container does not know that there is a new user with other roles, so it still applying the access rules of the first user). anyway to move forward i decided to use the container-managed authentication just as yes/no to obtain access to the complete application and to move authorization to the application itself. How about your barcode (or card or whatever) idea, to allow users to switch id on-the-fly ? I am curious as to how you implement that. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user switching or application interacting with container based authentication
Chris, Andre, thanks for sharing your thoughts, it helped me to see things more clear. changing a user object in the session is something i already did. the problem with this was (and which was triggering my initial question) is that a new user could have access rights to more functionality than the first user, but that the access to this functionality is blocked by the container because of the role based security constraints i have defined in web.xml (the container does not know that there is a new user with other roles, so it still applying the access rules of the first user). anyway to move forward i decided to use the container-managed authentication just as yes/no to obtain access to the complete application and to move authorization to the application itself. thanks, dirk On Thu, 2012-05-24 at 10:37 -0400, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dirk, > > On 5/23/12 7:01 PM, dirk ooms wrote: > > any hint on fast-user-switching or > > applications-interacting-with-container-based-authentication are > > very welcome. > > We use securityfilter for AAA and the user is stored in the session: > you can just replace the user object and boom: you are a new user. We > support "user impersonation" in this way and allows administrators to > masquerade as another user and then go back to their original login. > > Switching to securityfilter may not be a great plan for you, though > it's not terribly hard to do. But, its a possibility. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk++R7gACgkQ9CaO5/Lv0PBVSQCePHZUW/l2Ybdcqegu206zfY+g > 6rIAniyLbfpW0m96AeietxvHYXysOW7r > =ROLF > -END PGP SIGNATURE- > > - > 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: jk 1.2.36 throwing 503/sendfull/cping errors
> > You have the worker app-03 referenced both as a worker in its own right, > and as a balanced > worker. Isn't this a bit strange ? > Normally, if it is accessed via the balancer, you do not list it in workers.list. I have it in the list because sometimes I reference a specific worker in the jkmount and sometimes the balancer. Maybe I'll have a balancer with app-01 and app-02 and under normal circumstances access the a balancer, but then maybe I'll need to test something and I want to send things to just app-01. So I'll point the jkmount to app-01. If I take it out of the worker.list I can't do that. In this particular environment's config I quoted it doesn't apply since I only have one worker, but in my prod environment it's like above with multiple workers. FWIW, if I point the jkmount to the specific worker (app-03) and not the loadbalancer it works. If I take the worker out of the worker.list as your suggest and point my jkmount to the loadbalancer works, but then I can't point jkmount to a specific worker, I'll get a 500 error and "Could not find a worker for worker name=app-03" So to get it to work under the previous behavior, I'd have to have 2 workers. 1 worker entry if I want to use it directly (and put into the worker.list) and 1 worker entry if I want to use it in the loadbalancer. So basically I'm changing my config (which seems kind of wacky) to: worker.list=jkstatus,app-03-standalone,loadbalancer worker.app-03.host=127.0.0.1 worker.app-03.reference=worker.template worker.app-03-standalone.host=127.0.0.1 worker.app-03-standalone.reference=worker.template worker.jkstatus.type=status worker.loadbalancer.sticky_session=1 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=app-03 I'm still puzzled as to why this behavior just changed between .35 and .36 -Tony > See http://tomcat.apache.org/connectors-doc/reference/workers.html, > "balance_workers" > > > > > - > 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: jk 1.2.36 throwing 503/sendfull/cping errors
Anthony J. Biacco wrote: Please point out the workers.properties config line from my OP that's incorrect. I didn't change configs at all from 1.2.32->1.2.35->1.2.36. How could the config all of a sudden be incorrect with 1.2.36? The changelog doesn't mention anything about deprecated or changed parameters. I don't know if it has anything to do with your problem, but workers.properties settings are: worker.list=jkstatus,app-03,loadbalancer <- worker.template.port=8009 worker.template.type=ajp13 worker.template.lbfactor=1 worker.template.connection_pool_timeout=30 worker.template.connect_timeout=3 worker.template.recovery_options=4 worker.template.reply_timeout=31000 worker.template.socket_timeout=20 worker.template.socket_connect_timeout=5000 worker.template.ping_mode=A worker.template.ping_timeout=2 worker.app-03.host=127.0.0.1 worker.app-03.reference=worker.template worker.jkstatus.type=status worker.loadbalancer.sticky_session=1 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=app-03 <- You have the worker app-03 referenced both as a worker in its own right, and as a balanced worker. Isn't this a bit strange ? Normally, if it is accessed via the balancer, you do not list it in workers.list. See http://tomcat.apache.org/connectors-doc/reference/workers.html, "balance_workers" - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: jk 1.2.36 throwing 503/sendfull/cping errors
> > 1.2.32 and 1.2.35 work fine. > > > > [Wed May 23 15:56:32 2012] [32504:1138178368] [debug] > > jk_open_socket::jk_connect.c (609): trying to connect socket 22 to > > 0.0.0.0:0 > > Connecting to 0.0.0.0:0 ? > Yeah, I balked at that too. > > [Wed May 23 15:56:32 2012] [32504:1138178368] [debug] > > jk_open_socket::jk_connect.c (635): socket 22 [errno=107] connected > > getsockname fails with errno=107 (ENOTCONN) > Fix your config. Please point out the workers.properties config line from my OP that's incorrect. I didn't change configs at all from 1.2.32->1.2.35->1.2.36. How could the config all of a sudden be incorrect with 1.2.36? The changelog doesn't mention anything about deprecated or changed parameters. -Tony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Shared data source (Bug 49543)
Exactly, I had no way of knowing because the documentation of ResourceLink does not inform these "details". :) Konstantin was perfect in his description in bugzilla. On Thu, May 24, 2012 at 12:06 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Robert, > > On 5/24/12 10:57 AM, Robert Anderson wrote: > > Chris, > > > > Basically, the ResourceLink documentation doesn't say that to > > enable shared pool with different credentials: > > > > 1) You have to add tomcat-jdbc.jar in Tomcat 6.0 classpath; > > > > 2) You have to put the attributes in global resource definition: > > factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" and > > alternateUsernameAllowed="true". > > Gotcha: you didn't know that this was an example only relevant to > tomcat-jdbc (not that you should have -- I didn't know, either). I > thought you were already using tomcat-jdbc and I believe the docs > there are accurate. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk++ToIACgkQ9CaO5/Lv0PDFHQCgrXsXmL3C/Cc3a74Lt8ul8Ton > RyQAn0WwW4ZfQVJz3s8pHHh/ulBm7vwX > =XrXd > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: memory leak in tomcat
Is this the same server with the Wicket app you posted about earlier ? If so, you have a Wicket app that is storing the SessionFactoryObjectFactory on a page as a class member. Wicket stores each page a user has been to in the user's session. If the page has class members, then it serializes them and stores them too. I have seen this kind of thing happen many times before causing big memory usage. Remove the Wicket app and run the Eclipse Memory Analyzer. Thanks, Warren Bell On 5/24/12 5:42 AM, Konstantin Kolinko wrote: > 2012/5/24 Christian Kaufhold : >> Hi, >> >> I have a leaking Tomcat App >> I checked the heap with the Eclipse Memory Analyser >> and it says >> >> The classloader/component *"org.apache.catalina.loader.WebappClassLoader @ >> 0x94532f50"* >> occupies *376.421.152 (79,51%)* bytes. The memory is accumulated in one >> instance of >> *"java.util.HashMap$Entry[]"* loaded by *""*. >> > > So the memory is used for something useful? That is not a "memory > leak". It is just a web application requiring a lot of memory. > > WebappClassLoader is the classloader that is used to load the classes > of your webapp. Of course, it remembers every class that it loaded > (to satisfy repeated class.forName() calls) and every class that it > loads has a reference it it (via getClass().getClassLoader()). > > There may be many classes, but I do not think that the classloader > itself is responsible for 300 Mb of memory. > >> and the data that is in the entries of the gigantic Map is >> org.hibernate.impl.SessionFactoryObjectFactory >> > > That would be a hibernate question. I have no clue what that class is about. > > 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: user switching or application interacting with container based authentication
André Warnier wrote: dirk ooms wrote: Andre, thanks for your thoughts on this. i agree that this issue brings me to 'a loop of increasing contradictions'. it's probably good to go one step back and explain the real-life requirement: we have an application that is used by many small companies, each company has its own data and can have multiple users (typically 1 to 5). within a company there is a requirement to switch users in a fast way (e.g. using a badge or a fingerprint). think of a restaurant having 1 computer and several waiters. we want to trace what is done by which waiter and there is also an incentive for the waiter to switch users because his fee will be based on his logged activities. my reasoning was: i'll keep the standard proven AAA mechanism for the initial log in, but allow fast user switching within a company where there is more trust between users (which is security-wise probably a weak statement). still there is a need for some type of authentication because the users can have different roles. but this indeed leads to conflicts between the standard and the proprietary authentication/authorization mechanism. my current reasoning is: i need to keep a standard proven AAA mechanism also for fast user switching. correct? but how do i tackle this given that we now have form/container-based authentication. do i need a parallel standard container-based mechanism? what mechanism exists that allows to authenticate by scanning a barcode (i.e. a single (possibly long) string)? any pointer/suggestion will be much appreciated. So, if I understand correctly : - the first level of authentication is, say, by company, and is meant basically to avoid some unauthorised people accessing the website of each customer - the second level of authentication is within this company's dedicated website, and is meant to distinguish between different "actors" within that website. - and within the website, there is an incentive for the actors to use their own id, and not someone else's when they do something As far as the "within the one website" thing is concerned, the other suggestions that you have received seem the way to go. How you really integrate that into each action that these people do, I don't know really. But I would imagine that you could have some kind of applet within your web pages, which reads a barcode from a barcode reader, and adds what it has read as a POST parameter, before it submits the form to the server. And then on the server, you pick up this special parameter, and switch the userPrincipal on-the-fly, as they say. As far as the first-level authentication is concerned, here is maybe a bit of lateral thinking : If you put an Apache httpd front-end in front of Tomcat, then you could install some form of standard authentication at the Apache httpd level, which protects that website "in general" with the "company login". Then only if that authentication succeeds, you would proxy the calls to Tomcat (using mod_jk for instance). But Tomcat would know nothing about this front-end authentication, and would not need to know. Similarly, Apache httpd would never know - nor need to know - when the user at the Tomcat level changes. I think such a scheme would keep things nicely separated, and simplify the whole design. Upon further thinking, of course you would not necessarily need an Apache httpd front-end for this, and could do this all within Tomcat. The container-level authentication comes first, before your webapp is even called. So that is your Tomcat-level authentication, by company. Then you could still have some servlet filter (which runs after the container-level authentication) to pick up this special POST parameter and do your "application-level" authentication. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user switching or application interacting with container based authentication
dirk ooms wrote: Andre, thanks for your thoughts on this. i agree that this issue brings me to 'a loop of increasing contradictions'. it's probably good to go one step back and explain the real-life requirement: we have an application that is used by many small companies, each company has its own data and can have multiple users (typically 1 to 5). within a company there is a requirement to switch users in a fast way (e.g. using a badge or a fingerprint). think of a restaurant having 1 computer and several waiters. we want to trace what is done by which waiter and there is also an incentive for the waiter to switch users because his fee will be based on his logged activities. my reasoning was: i'll keep the standard proven AAA mechanism for the initial log in, but allow fast user switching within a company where there is more trust between users (which is security-wise probably a weak statement). still there is a need for some type of authentication because the users can have different roles. but this indeed leads to conflicts between the standard and the proprietary authentication/authorization mechanism. my current reasoning is: i need to keep a standard proven AAA mechanism also for fast user switching. correct? but how do i tackle this given that we now have form/container-based authentication. do i need a parallel standard container-based mechanism? what mechanism exists that allows to authenticate by scanning a barcode (i.e. a single (possibly long) string)? any pointer/suggestion will be much appreciated. So, if I understand correctly : - the first level of authentication is, say, by company, and is meant basically to avoid some unauthorised people accessing the website of each customer - the second level of authentication is within this company's dedicated website, and is meant to distinguish between different "actors" within that website. - and within the website, there is an incentive for the actors to use their own id, and not someone else's when they do something As far as the "within the one website" thing is concerned, the other suggestions that you have received seem the way to go. How you really integrate that into each action that these people do, I don't know really. But I would imagine that you could have some kind of applet within your web pages, which reads a barcode from a barcode reader, and adds what it has read as a POST parameter, before it submits the form to the server. And then on the server, you pick up this special parameter, and switch the userPrincipal on-the-fly, as they say. As far as the first-level authentication is concerned, here is maybe a bit of lateral thinking : If you put an Apache httpd front-end in front of Tomcat, then you could install some form of standard authentication at the Apache httpd level, which protects that website "in general" with the "company login". Then only if that authentication succeeds, you would proxy the calls to Tomcat (using mod_jk for instance). But Tomcat would know nothing about this front-end authentication, and would not need to know. Similarly, Apache httpd would never know - nor need to know - when the user at the Tomcat level changes. I think such a scheme would keep things nicely separated, and simplify the whole design. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: memory leak in tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 5/24/12 8:42 AM, Konstantin Kolinko wrote: > 2012/5/24 Christian Kaufhold : >> Hi, >> >> I have a leaking Tomcat App I checked the heap with the Eclipse >> Memory Analyser and it says >> >> The classloader/component >> *"org.apache.catalina.loader.WebappClassLoader @ 0x94532f50"* >> occupies *376.421.152 (79,51%)* bytes. The memory is accumulated >> in one instance of *"java.util.HashMap$Entry[]"* loaded by >> *""*. >> > > So the memory is used for something useful? That is not a "memory > leak". It is just a web application requiring a lot of memory. > > WebappClassLoader is the classloader that is used to load the > classes of your webapp. Of course, it remembers every class that > it loaded (to satisfy repeated class.forName() calls) and every > class that it loads has a reference it it (via > getClass().getClassLoader()). > > There may be many classes, but I do not think that the classloader > itself is responsible for 300 Mb of memory. It may, if the ClassLoader holds references to Class objects (it does) that contain static members with lots of data (not so sure about this part). >> and the data that is in the entries of the gigantic Map is >> org.hibernate.impl.SessionFactoryObjectFactory > > That would be a hibernate question. I have no clue what that class > is about. +1 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk++T9YACgkQ9CaO5/Lv0PAwAQCfZSz67ALyFrRfZaVYs6Tjoee7 Q4UAnA/Q2vIjecxXPEW+BzsN7GeSJQk3 =zQcP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Shared data source (Bug 49543)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert, On 5/24/12 10:57 AM, Robert Anderson wrote: > Chris, > > Basically, the ResourceLink documentation doesn't say that to > enable shared pool with different credentials: > > 1) You have to add tomcat-jdbc.jar in Tomcat 6.0 classpath; > > 2) You have to put the attributes in global resource definition: > factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" and > alternateUsernameAllowed="true". Gotcha: you didn't know that this was an example only relevant to tomcat-jdbc (not that you should have -- I didn't know, either). I thought you were already using tomcat-jdbc and I believe the docs there are accurate. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk++ToIACgkQ9CaO5/Lv0PDFHQCgrXsXmL3C/Cc3a74Lt8ul8Ton RyQAn0WwW4ZfQVJz3s8pHHh/ulBm7vwX =XrXd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: maxParameterCount with Tomcat 5.5.23
For my Red Hat delivered Tomcat, changes to the connector attribute were ignored. However, I did find a fix that works. In tomcat5.conf, after all other settings are added to JAVA_OPTS, add the value you desire for max parameter count like this: # RH KB 100383 # Override default max parameter count of 512 JAVA_OPTS="$JAVA_OPTS -Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=1" The Red Hat KB article references JBoss run script, but the above works fine for standalone Tomcat. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Friday, May 11, 2012 3:51 PM To: Tomcat Users List Subject: RE: maxParameterCount with Tomcat 5.5.23 > From: Haenni, Tia [mailto:thae...@burnsmcd.com] > Subject: RE: maxParameterCount with Tomcat 5.5.23 > I read some posts where it was apparently ignored and the default used > instead. It would be interesting to know who's publishing such garbage. > Can you confirm that setting maxParameterCount in the connector > attribute will override the default? Not on a Tomcat mangled by Red Hat - you're on your own with that. If you use a real Tomcat, it will certainly work. - 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
Re: Shared data source (Bug 49543)
Chris, Basically, the ResourceLink documentation doesn't say that to enable shared pool with different credentials: 1) You have to add tomcat-jdbc.jar in Tomcat 6.0 classpath; 2) You have to put the attributes in global resource definition: factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" and alternateUsernameAllowed="true". Cheers, Robert On Thu, May 24, 2012 at 11:46 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Robert, > > On 5/24/12 7:50 AM, Robert Anderson wrote: > > Now it's working! Follows the script: > > So, how does your "script" deviate from the Tomcat documentation? It > seems that you followed the docs and now it works. Right? > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEUEARECAAYFAk++ScsACgkQ9CaO5/Lv0PAy4ACWNsbvFopO5tY0s0SXCDfnmXEb > 7wCfTJA3lvlqkl7hXrAcVB70EREQ7EU= > =ssa2 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Shared data source (Bug 49543)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert, On 5/24/12 7:50 AM, Robert Anderson wrote: > Now it's working! Follows the script: So, how does your "script" deviate from the Tomcat documentation? It seems that you followed the docs and now it works. Right? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk++ScsACgkQ9CaO5/Lv0PAy4ACWNsbvFopO5tY0s0SXCDfnmXEb 7wCfTJA3lvlqkl7hXrAcVB70EREQ7EU= =ssa2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user switching or application interacting with container based authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 5/23/12 7:06 PM, chris derham wrote: > We had an app where support staff can login, and then on a special > form enter the username of the person to impersonate and their own > password (to prevent abuse), and the system then allows them to > impersonate the user. Worked well for viewing exactly what the user > was seeing when reporting issues. To do this we used acegi security > - has built in support for impersonation. NB: ACEGI is now called "Spring Security". - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk++R/gACgkQ9CaO5/Lv0PAgXwCgtJy6H3IQ/zTXXAGE8NTfmYMN nSEAnjDvGCXJBkvAyP4dTtCNgGq0Bnp/ =xMMQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user switching or application interacting with container based authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dirk, On 5/23/12 7:01 PM, dirk ooms wrote: > any hint on fast-user-switching or > applications-interacting-with-container-based-authentication are > very welcome. We use securityfilter for AAA and the user is stored in the session: you can just replace the user object and boom: you are a new user. We support "user impersonation" in this way and allows administrators to masquerade as another user and then go back to their original login. Switching to securityfilter may not be a great plan for you, though it's not terribly hard to do. But, its a possibility. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk++R7gACgkQ9CaO5/Lv0PBVSQCePHZUW/l2Ybdcqegu206zfY+g 6rIAniyLbfpW0m96AeietxvHYXysOW7r =ROLF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: encrypt the database password
yes, there is, search http://tomcat.markmail.org for the same org.apache.tomcat.util.digester.PROPERTY_SOURCE is a system property where you can add the code that digests properties in server.xml This code can 'decode' your encoded properties - Original Message - > From: "Bill Wang" > To: "Tomcat Users List" > Sent: Wednesday, May 23, 2012 11:34:10 PM > Subject: encrypt the database password > > Hi All, > > There is a tomcat server with some database setup. > > cd apache-tomcat-6.0.29/conf > cat server.xml > >driverClassName="oracle.jdbc.driver.OracleDriver" > > factory="oracle.jdbc.pool.OracleDataSourceFactory" > maxActive="20" > maxIdle="10" maxWait="-1" name="jdbc/abc" > password="abcADMIN" > type="oracle.jdbc.pool.OracleDataSource" > > url="jdbc:oracle:thin:@localhost:1521:mydb" user="abc" /> > > > So which the plain password, end user may get the password directly. > > > How can create encrypted password within server.xml > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Shared data source (Bug 49543)
2012/5/24 Robert Anderson : > Sorry, for the wall of text. :) > > "IIRC there is no support for getConnection(username, password) in > Apache Commons DBCP pool at all, and it was a new feature in Tomcat > JDBC pool at that time." > > Yes, it is the problem. I've lost many hours following an example in > documentation about ResourceLink and DataSource that does not work as > expected/described. > I added it to Bugzilla. https://issues.apache.org/bugzilla/show_bug.cgi?id=53289 > Now it's working! Follows the script: > 1) ... > 2) ... > 3) ... Thank you. It is good to have a working example. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: memory leak in tomcat
2012/5/24 Christian Kaufhold : > Hi, > > I have a leaking Tomcat App > I checked the heap with the Eclipse Memory Analyser > and it says > > The classloader/component *"org.apache.catalina.loader.WebappClassLoader @ > 0x94532f50"* > occupies *376.421.152 (79,51%)* bytes. The memory is accumulated in one > instance of > *"java.util.HashMap$Entry[]"* loaded by *""*. > So the memory is used for something useful? That is not a "memory leak". It is just a web application requiring a lot of memory. WebappClassLoader is the classloader that is used to load the classes of your webapp. Of course, it remembers every class that it loaded (to satisfy repeated class.forName() calls) and every class that it loads has a reference it it (via getClass().getClassLoader()). There may be many classes, but I do not think that the classloader itself is responsible for 300 Mb of memory. > and the data that is in the entries of the gigantic Map is > org.hibernate.impl.SessionFactoryObjectFactory > That would be a hibernate question. I have no clue what that class is about. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: memory leak in tomcat
Christian Kaufhold wrote: Hi, I have a leaking Tomcat App I checked the heap with the Eclipse Memory Analyser and it says The classloader/component *"org.apache.catalina.loader.WebappClassLoader @ 0x94532f50"* occupies *376.421.152 (79,51%)* bytes. The memory is accumulated in one instance of *"java.util.HashMap$Entry[]"* loaded by *""*. and the data that is in the entries of the gigantic Map is org.hibernate.impl.SessionFactoryObjectFactory Does anyone know why this? One giant leap in the dark and totally-uneducated guess : due to some logical or configuration error, this application creates a new session at each request, and they never time out ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
memory leak in tomcat
Hi, I have a leaking Tomcat App I checked the heap with the Eclipse Memory Analyser and it says The classloader/component *"org.apache.catalina.loader.WebappClassLoader @ 0x94532f50"* occupies *376.421.152 (79,51%)* bytes. The memory is accumulated in one instance of *"java.util.HashMap$Entry[]"* loaded by *""*. and the data that is in the entries of the gigantic Map is org.hibernate.impl.SessionFactoryObjectFactory Does anyone know why this? Christian ** Class Name Shallow Heap Retained Heap - java.util.HashMap$Entry[64] @ 0xaa9314c0 272 339.906.832 [image: \] - *table* java.util.HashMap @ 0xaa931498 40 339.906.872 [image: .][image: \] - *map* org.hibernate.util.FastHashMap @ 0x94e4bc98 16 339.906.888 [image: .][image: .][image: \] - *INSTANCES* class org.hibernate.impl.SessionFactoryObjectFactory @ 0x759319f8 24 339.907.088 [image: .][image: .][image: .][image: \] - *[1788]* java.lang.Object[5120] @ 0x95148470 20.496 375.206.992 [image: .][image: .][image: .][image: .][image: \] - *elementData* java.util.Vector @ 0x94538998 24 375.207.016 [image: .][image: .][image: .][image: .][image: .][image: \] - *classes* org.apache.catalina.loader.WebappClassLoader @ 0x94532f50 176 376.421.152 [image: .][image: .][image: .][image: .][image: .][image: .][image: +] - *contextClassLoader* java.lang.Thread @ 0x94e1ac60 Thread-10 *Thread* 112 7.112 [image: .][image: .][image: .][image: .][image: .][image: .][image: +] - *contextClassLoader* de.bfd.tools.ConnectionPool$ConnPoolMultiCaster @ 0x94e1ad00 Thread-9 » 136 592 [image: .][image: .][image: .][image: .][image: .][image: .][image: +] - *contextClassLoader* java.lang.Thread @ 0x9bb7b548 Keep-Alive-Timer» 112 168 [image: .][image: .][image: .][image: .][image: .][image: .][image: +] - *classloader* java.security.ProtectionDomain @ 0x9453a160»
Re: Shared data source (Bug 49543)
Hi,
Now it's working! Follows the script:
1) Tomcat 6.0.35: copy tomcat-jdbc.jar to CATALINA_HOME/lib. Tomcat 7.0.x
is ready.
2) Create a global resource in CATALINA_HOME/conf/server.xml. Attributes
in bold *MUST *be present:
3) Create a context.xml for apps;
The attribute "name" need not possess the same value of the attribute
"global".
--> CATALINA_HOME/conf/Catalina/localhost/app1.xml (shared connection with
different credential)
--> CATALINA_HOME/conf/Catalina/localhost/app2.xml (shared connection with
default credential)
4) JSP to test this feature (in both CATALINA_HOME/webapps/app1 and
CATALINA_HOME/webapps/app2):
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
<%@ page session="false" import="javax.naming.*, java.sql.*, javax.sql.*" %>
http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
Test shared data source
<%
Context ctx = null;
DataSource ds = null;
Connection c = null;
Statement stm = null;
ResultSet rs = null;
try {
ctx = new InitialContext();
ds = (DataSource)ctx.lookup("java:comp/env/jdbc/pgserver");
c = ds.getConnection();
stm = c.createStatement();
rs = stm.executeQuery("select current_user");
rs.next();
%>
Current user: <%= rs.getString(1) %>
<%
} catch (Exception e) {
%>
Error: <%= e.getMessage() %>
<%
} finally {
if (rs!=null) try { rs.close(); } catch (Exception ignore){}
if (stm!=null) try { stm.close(); } catch (Exception ignore){}
if (c!=null) try { c.close();} catch (Exception ignore){}}
%>
5) App1 output:
Current user: userapp1
6) App2 output:
Current user: globaluser
Thanks and I hope this script can help others with the same problem.
Cheers,
Robert
On Wed, May 23, 2012 at 8:38 PM, Robert Anderson wrote:
> Sorry, for the wall of text. :)
>
>
> "IIRC there is no support for getConnection(username, password) in
> Apache Commons DBCP pool at all, and it was a new feature in Tomcat
> JDBC pool at that time."
>
> Yes, it is the problem. I've lost many hours following an example in
> documentation about ResourceLink and DataSource that does not work as
> expected/described.
>
>
> Best regards,
>
> Robert
>
> On Wed, May 23, 2012 at 8:26 PM, Konstantin Kolinko <
> knst.koli...@gmail.com> wrote:
>
>> 2012/5/24 Robert Anderson :
>> >
>> > 2. You need to set alternateUsernameAllowed="
>> >>
>> >> true" on Tomcat JDBC pool [1]
>> >> Otherwise arguments in ds.getConnection(user,password) method on that
>> >> datasource are ignored.
>> >
>> >
>> > Good, I'll test it. Anyway, the following description and example in
>> > documentation is not valid (
>> > tomcat.apache.org/tomcat-6.0-doc/config/context.html#Resource_Links,
>> > tomcat.apache.org/tomcat-7.0-doc/config/context.html#Resource_Links):
>> >
>> > "When the attribute
>> > factory="org.apache.naming.factory.DataSourceLinkFactory" the resource
>> link
>> > can be used with two additional attributes to allow a shared data
>> source to
>> > be used with different credentials. When these two additional attributes
>> > are used in combination with the javax.sql.DataSource type, different
>> > contexts can share a global data source with different credentials.
>> Under
>> > the hood, what happens is that a call to
>> > getConnection()<
>> http://download.oracle.com/javase/6/docs/api/javax/sql/DataSource.html#getConnection%28%29
>> >is
>> > simply translated to a call getConnection(username,
>> > password)<
>> http://download.oracle.com/javase/6/docs/api/javax/sql/DataSource.html#getConnection%28java.lang.String,%20java.lang.String%29
>> >on
>> > the global data source. This is an easy way to get code to be
>> > transparent to what schemas are being used, yet be able to control
>> > connections (or pools) in the global configuration. "
>> >
>> >
>> > ...
>> > > >global="sharedDataSource"
>> >type="javax.sql.DataSource"
>> >username="bar"
>> >password="barpass"
>> >
>> >...
>> > ...
>> >
>> >
>> >
>> > ...
>> > > >name="appDataSource"
>> >global="sharedDataSource"
>> >type="javax.sql.DataSource"
>> >factory="org.apache.naming.factory.DataSourceLinkFactory"
>> >username="foo"
>> >password="foopass"
>> > ...
>> >
>> >
>> > ...
>> > > >name="appDataSource"
>> >global="sharedDataSource"
>> >type="javax.sql.DataSource"
>> > ...
>> >
>> >
>> >
>> >
>> > That way, just does not work.
>> >
>>
>> Can you be more specific? You are just citing a wall of text and it is
>> hard to digest.
>>
>> Can you open an issue in Bugzilla?
>>
>> IIRC there is no support for getConnection(username, password) in
>> Apache Commons DBCP pool at all, and it was a new feature in Tomcat
>> JDBC pool at that time.
>>
>> Is it the problem, or something else is wrong?
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> -
Re: user switching or application interacting with container based authentication
Andre, thanks for your thoughts on this. i agree that this issue brings me to 'a loop of increasing contradictions'. it's probably good to go one step back and explain the real-life requirement: we have an application that is used by many small companies, each company has its own data and can have multiple users (typically 1 to 5). within a company there is a requirement to switch users in a fast way (e.g. using a badge or a fingerprint). think of a restaurant having 1 computer and several waiters. we want to trace what is done by which waiter and there is also an incentive for the waiter to switch users because his fee will be based on his logged activities. my reasoning was: i'll keep the standard proven AAA mechanism for the initial log in, but allow fast user switching within a company where there is more trust between users (which is security-wise probably a weak statement). still there is a need for some type of authentication because the users can have different roles. but this indeed leads to conflicts between the standard and the proprietary authentication/authorization mechanism. my current reasoning is: i need to keep a standard proven AAA mechanism also for fast user switching. correct? but how do i tackle this given that we now have form/container-based authentication. do i need a parallel standard container-based mechanism? what mechanism exists that allows to authenticate by scanning a barcode (i.e. a single (possibly long) string)? any pointer/suggestion will be much appreciated. dirk > > Without going into the technique itself, from your description above it looks > to me as if > this is a scenario so different from what a standard AAA mechanism is > designed to achieve, > that you are going to find yourself getting into a loop of increasing > contradictions, if > you try to fit this into the standard authentication mechanisms. > (In other words : you are going to be using code that has been carefully > designed and > perfected to do things well in one scenario, and try to do something else > with it. I > would expect all kinds of side-effects, and an endless series of patches upon > patches to > avoid them). > > Maybe the first question to ask : why do you need the user to be > authenticated /to the > servlet container/ in the first place ? when, and for what, do you use the > return values > of getUserPrincipal() and/or isUserInRole() ? (I mean really, deep down) > > If you rethink the above, imagining that the user-id is just a request > parameter like any > other parameter (*), and that Tomcat itself has no knowledge of an > authenticated > user, what breaks down ? > > > > (*) which according to your own explanation above, you are going to have to > do at some > point anyway. > > > > - > 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: Tomcat 7. MX4J
HI Vadzim,
as you like a hot HTTP-JMX access use
http://www.jolokia.org/
chili...
Peter
Am 23.05.2012 um 00:06 schrieb Vadzim Mikhalenak:
> On Wed, May 23, 2012 at 12:31 AM, Konstantin Kolinko > wrote:
>
>> 2012/5/22 Vadzim Mikhalenak :
>>> Hello Christopher,
>>> *
>>> *
>>> Thank you for the reply! Yes, link
>>> http://tomcat.apache.org/tomcat-5.5-doc/monitoring.html is for version
>> 5.5
>>> but we are migrating from version 6 (sorry for the confusion) but the
>>> configuration above was valid for version 6
>>>
>>
>> It works (or at least tries to start, to my surprise) in Tomcat 6 with
>> this particular AJP/1.3 connector implementation, but it is not
>> documented and not supported. Other connectors do not support those
>> attributes and this one was removed from Tomcat 7.
>>
>> Tomcat 6 and 7 use JMX support provided by JRE and if you need http
>> access to it, the common way is to use "JMXProxy" servlet that is part
>> of the manager webapp.
>>
>> It is all is documented
>> http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html
>>
>> http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Using_the_JMX_Proxy_Servlet
>>
>> or see the same docs for Tomcat 7.
>>
>>
>>
>>> >> handler.list="mx"
>>> mx.enabled="true"
>>> mx.httpHost="${JMX.HOST}"
>>> mx.httpPort="${JMX.PORT}"
>>> protocol="AJP/1.3" />
>>>
>>>
>>> *
>>> *
>>> and gave us opportunity to manage JMX beans using http://
>>> ${JMX.HOST}:${JMX.PORT} (please see
>>>
>> http://logback.qos.ch/manual/images/chapters/jmxConfigurator/mx4j_jetty.gif
>>> )
>>> In version 7 I couldn't see any possibility to do it.
>>> I've noticed that in Connector class of version 6
>>> if ("AJP/1.3".equals(protocol)) {
>>> setProtocolHandlerClassName
>>> ("org.apache.jk.server.JkCoyoteHandler");
>>>
>>> org.apache.jk.server.JkCoyoteHandler used JkMain which used JkMX where
>>> HttpAdapter from mx4j-tool.jar was used.
>>>
>>> but in version 7
>>> else if ("AJP/1.3".equals(protocol)) {
>>> setProtocolHandlerClassName
>>> ("org.apache.coyote.ajp.AjpAprProtocol");
>>>
>>>
>>>
>>> So do we have possibility to manage JMX beans in version 7 as we could in
>>> version 6? (please see
>>>
>> http://logback.qos.ch/manual/images/chapters/jmxConfigurator/mx4j_jetty.gif
>>> )
>>>
>>
>> Please
>> 1. Post your response below the text that you are replying to (aka "do
>> not top-post")
>> 2. Do not cross-post questions between users@ and dev@ lists.
>>
>> This one belongs to users@.
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>> Hi,
>
> Thanks for the reply.
> I know about JMX Proxy Servlet but it was more preferable to use MX4J page
> and I thought there is simple way to configure it (as it was configured in
> 6 version).
> I'll be looking for solution to get mx4j page working.
> Thanks again for your help!
> Sorry for the trouble.
>
> Best regards,
> Vadim.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user switching or application interacting with container based authentication
dirk ooms wrote: Hello, we are running a web application with form based authentication. we now have a requirement to switch between users (for subsets of users) with a minimum of user interaction (log out and log in providing username & password is way too much work for the user). so i was thinking of providing each user with a badge with a unique barcode (a hash of username&password?) which they can scan into a dedicated field in the webpage and which will trigger the user switch. note that this barcode field will only be available once a person has logged in in the normal way (form based), so the user switch request is received within an authenticated session. the difficult part of the story is how can i tell the 'container based authentication' that the current session is transferred to another user with possibly other roles OR how can i create a new session for the new user (so applying the correct authorization and providing a HttpServletRequest returning the correct values of getUserPrincipal() and isUserInRole()). the application is able to retrieve the user and its roles, but how can the application inform the container about this. i've been googling and reading for hours now and i'm a bit lost (understatement) on how to proceed with this. it could also be the case that there are much better scenario's than the one i have in mind. any hint on fast-user-switching or applications-interacting-with-container-based-authentication are very welcome. Without going into the technique itself, from your description above it looks to me as if this is a scenario so different from what a standard AAA mechanism is designed to achieve, that you are going to find yourself getting into a loop of increasing contradictions, if you try to fit this into the standard authentication mechanisms. (In other words : you are going to be using code that has been carefully designed and perfected to do things well in one scenario, and try to do something else with it. I would expect all kinds of side-effects, and an endless series of patches upon patches to avoid them). Maybe the first question to ask : why do you need the user to be authenticated /to the servlet container/ in the first place ? when, and for what, do you use the return values of getUserPrincipal() and/or isUserInRole() ? (I mean really, deep down) If you rethink the above, imagining that the user-id is just a request parameter like any other parameter (*), and that Tomcat itself has no knowledge of an authenticated user, what breaks down ? (*) which according to your own explanation above, you are going to have to do at some point anyway. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
