Re: Fwd: J2EE on Mac
Mighty Tornado ha scritto: Hi, I installed Tomcat on my mac OS X and it's running. I also have Eclipse Europa. Now I don't think I have J2EE installed - How do I do it? You can download different eclipse packages, "Eclipse IDE for Java EE Developers" is more comfortable. I went to Sun's website and it gave me an archive with GlassFish which I don't need. Can somebody please tell me where I can download the latest J2EE for Mac? Seems also to me that is necessary to download all the bundle. You can download it and don't use glassfish. What I need to do to compile servlets with it in Eclipse? You don't need J2EE to develope servelts undex OS X, simply insert (in any way, IE: right-click on you project, select properties, in java build path, libraries) jsp-api.jar and servlet-api.jat that you can find in lib folder inside tomcat installation. If you are building a new project, I think you can use "Dynamic Web Project" in "Web" Category. Edoardo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: J2EE on Mac
Mighty Tornado ha scritto: Hi, I installed Tomcat on my mac OS X and it's running. I also have Eclipse Europa. Now I don't think I have J2EE installed - How do I do it? You can download different eclipse packages, "Eclipse IDE for Java EE Developers" is more comfortable. I went to Sun's website and it gave me an archive with GlassFish which I don't need. Can somebody please tell me where I can download the latest J2EE for Mac? Seems also to me that is necessary to download all the bundle. You can download it and don't use glassfish. What I need to do to compile servlets with it in Eclipse? You don't need J2EE to develope servelts undex OS X, simply insert (in any way, IE: right-click on you project, select properties, in java build path, libraries) jsp-api.jar and servlet-api.jat that you can find in lib folder inside tomcat installation. If you are building a new project, I think you can use "Dynamic Web Project" in "Web" Category. Thank you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
how to make more than one web applications run without context root name on tomcat (Virtual hosting)
I am trying to configure my server(tomcat 5.5.26) in a way that i can access two applications without mentioning their context name. I have googled for it and done the following configuration in my server.xml I have two application, App1 and App2 now i want that both should run with out context name, one i can run with ip and other wiht some virtual host name. fss.secondApp.com and following is the xml files that i created in conf/catalina/www.secondApp.com/ROOT.xml I am able to run the first application App1 with https://123.123.123.123/ but with these setting i m not able to access my application App2 like https://www.secondApp.com/ but if I do https://123.123.123.123/App2, I can see the index page Please suggest something if any one has some idea about it Thanks in advance. -- View this message in context: http://www.nabble.com/how-to-make-more-than-one-web-applications-run-without-context-root-name-on-tomcat-%28Virtual-hosting%29-tp22156656p22156656.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
Fwd: J2EE on Mac
Hi, I installed Tomcat on my mac OS X and it's running. I also have Eclipse Europa. Now I don't think I have J2EE installed - How do I do it? I went to Sun's website and it gave me an archive with GlassFish which I don't need. Can somebody please tell me where I can download the latest J2EE for Mac? What I need to do to compile servlets with it in Eclipse? Thank you.
Re: Authenticating Users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, Wow. On 2/22/2009 8:52 PM, Martin Gainty wrote: >> Alan Chaney wrote: >> >> To summarize >> >> 1. password be case insensitive [I may be able to talk them out of this] > MG>handled from java.lang.String toUpperCase/toUpperCase > http://java.sun.com/javase/6/docs/api/java/lang/String.html He's trying to do a case-insensitive match in the database. Do you suggest executing "SELECT * FROM user" and then uppercasing every username looking for the right one? It's already been pointed out that many databases already perform case-insensitive CHAR/VARCHAR matching /and/ that not all databases have the same functions for performing this on the server-side (which is the only reasonable place to do it). >> 2. username be case insensitive. > MG>leave as case-sensitive What's the matter... you don't like the requirements? >> 3. email address can be used as a synonym for the user name. > MG>store email as a column in your users table Er... he's already got that. Have you been reading? >> 4. Security managed by Tomcat CMS. > MG>use Realm as earlier suggested storing user and role info in users and > user_roles tables > MG>respectively He's already doing that. >> Mark T suggested that I modify DSR appropriately. > MG>DSR is ready for deployment just match your tablenames for users and > user_roles > MG>also match your userNameCol and userCredCol and roleNameCol Not true... he wants to use /either/ username /or/ email address as the user identifier. >> Chris Schultz pointed out correctly that it gets a bit more complicated >> if the pwd must be hashed. > MG>no harm stick into Oracle DB as a Blob column (binary large object) or as > RAW Why would you bother doing that? The digester already provides the hashed password as a string, so putting it into a CHAR field makes more sense. >> I've looked at the code to DSR and it seems to me that the following >> would work. >> >> 1. add an 'alternative' userNameCol (eg altNameCol) and in the >> configuration as above point that at the email column. > MG>good.. > >> 2. in the code, IF the login fails using the 'user_name' then try it >> with the altNameCol. > MG>the result from action class will path you there ..but you're on the right > track.. Huh? >> Defaults could be chosen such that the current configuration setup still >> works (eg the default value for isCaseInsensitive is false) > MG>sensitive stuff like username/password goes in DB > MG>everything else to get the page up and running can go into a flat > file(.properties/stylesheets) Okay, my brain is hurting. What are you talking about? >> Only real gotcha that I can see for making it database independent is >> that the function used to create lower case is not univerally 'lower()' >> (M/SQL appears to be toLower()) so it might be necessary to pass the >> string for the function name as an optional configuration parameter. > MG>I've been working with Oracle recently MySQL last year and Oracle is > case-sensitive > MG>oracle!=ORACLE but MySQL will take upper/lower or camelcase queriesfor > same result If you mean that MySQL performs CHAR and VARCHAR comparisons without regard to case then yes, this is true. You can get case-sensitive matches by casting one of the operands to BINARY CHAR/VARCHAR. >> I realize that many people would advise against the idea of case >> insensitive passwords - however, despite my personal reservations I am >> willing to accept that in the case of this particular application the >> reduction in security is acceptable. > MG>decide on uppercase or lowercase and stick to it.. > >> If hashed pwds are used then there are 3 solutions: >> >> 1. don't allow case insensitive passwords - only user names. > MG>UserNames should be case sensitive AL != al (at least in Oracle) Dude. Read. The. Requirements. Nobody cares how you think things should be. This is a business requirement. You can't simply say "no". >> 2. provide two columns one for lower case versions of the pwd. > MG>not a good idea and violates data normalisation one copy in DB > MG>use uppercase or lower case only for view Two different passwords in the database is not denormalization. Whenever we change password strategies (it's happened twice), we store the old-style password in one column and the new-style password in another. After a while (usually like a year or more), we phase-out the old-style and suspend the logins of all the users who haven't "upgraded" their passwords. I think this is a perfectly reasonable strategy. >> 3. convert all the existing password HASHES to the lower case equivalent, > MG>wont work A (0x41) != a(0x61) ..you can assume tolower is a simple > addition of hex 20 > MG>when the hash algo gets ahold of the character the 0x41 hashes differently > than 0x61 This is a bad assumption as it only works with US-ASCII. This is not even true for the simple Latin charsets that are included in ISO-8859-1. He's talking about usi
Re: How to close open connections after application stop?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin,
On 2/22/2009 10:26 AM, Martin Gainty wrote:
> catch (SQLException sqlEx)
> {
> try
> {
> resultset.close();
> statement.close();
> connection.close();
> }
It's kind of silly to call close() on all these resources in the
exception handles when you're just going to:
> finally
> {
>try
>{
> resultset.close();
> statement.close();
> connection.close();
> }
> catch(java.sql.SQLException excp)
>{
> log.debug("Exception on resultset/statement/connection close
> message="=excp.getMessage());
> }
>} //end finally..
...close them all in the finally block. Also, each close() method should
be surrounded by try/catch blocks and appropriate log messages. Finally,
logging exception stack traces is always helpful.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmiDwQACgkQ9CaO5/Lv0PBHmQCfcUww2dA6wQqlY/1PWpxUGA2b
XpsAn2Bg/V3AVSBWMDcFcax8A6DkUo50
=urPv
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Authenticating Users
> > Martin Gainty wrote: > > Which specific attributes are you seeking that are not in DataSourceRealm? > > >dataSourceName="jdbc/authority" > >userTable="users" userNameCol="user_name" userCredCol="user_pass" > >userRoleTable="user_roles" roleNameCol="role_name"/> > > http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#DataSourceRealm > > > > ? > > > To summarize > > I (or,actually my "marketing dept') have the following requirements. MG>yes I keep forgeting they're running the show these days > 1. password be case insensitive [I may be able to talk them out of this] MG>handled from java.lang.String toUpperCase/toUpperCase http://java.sun.com/javase/6/docs/api/java/lang/String.html > 2. username be case insensitive. MG>leave as case-sensitive > 3. email address can be used as a synonym for the user name. MG>store email as a column in your users table > 4. Security managed by Tomcat CMS. MG>use Realm as earlier suggested storing user and role info in users and user_roles tables MG>respectively > > Mark T suggested that I modify DSR appropriately. MG>DSR is ready for deployment just match your tablenames for users and user_roles MG>also match your userNameCol and userCredCol and roleNameCol > Chris Schultz pointed out correctly that it gets a bit more complicated > if the pwd must be hashed. MG>no harm stick into Oracle DB as a Blob column (binary large object) or as RAW > > I've looked at the code to DSR and it seems to me that the following > would work. > > 1. add an 'alternative' userNameCol (eg altNameCol) and in the > configuration as above point that at the email column. MG>good.. > 2. in the code, IF the login fails using the 'user_name' then try it > with the altNameCol. MG>the result from action class will path you there ..but you're on the right track.. > 3. to make things case insenstive simply convert the username to lower > case and use a 'lower' function on the column value. MG>store all strings as either uppercase or all lowercase your app may not be case-sensitive MG>but Databases are case-sensitive > 4. to make the thing a bit more flexible an additional boolean parameter > 'isCaseInsensitive' could be added to select the behavior has in 3. above. MG>make sure its case sensitive by the time it goes into the DB > Defaults could be chosen such that the current configuration setup still > works (eg the default value for isCaseInsensitive is false) MG>sensitive stuff like username/password goes in DB MG>everything else to get the page up and running can go into a flat file(.properties/stylesheets) > Only real gotcha that I can see for making it database independent is > that the function used to create lower case is not univerally 'lower()' > (M/SQL appears to be toLower()) so it might be necessary to pass the > string for the function name as an optional configuration parameter. MG>I've been working with Oracle recently MySQL last year and Oracle is case-sensitive MG>oracle!=ORACLE but MySQL will take upper/lower or camelcase queriesfor same result > I realize that many people would advise against the idea of case > insensitive passwords - however, despite my personal reservations I am > willing to accept that in the case of this particular application the > reduction in security is acceptable. MG>decide on uppercase or lowercase and stick to it.. > If hashed pwds are used then there are 3 solutions: > > 1. don't allow case insensitive passwords - only user names. MG>UserNames should be case sensitive AL != al (at least in Oracle) > 2. provide two columns one for lower case versions of the pwd. MG>not a good idea and violates data normalisation one copy in DB MG>use uppercase or lower case only for view > 3. convert all the existing password HASHES to the lower case equivalent, MG>wont work A (0x41) != a(0x61) ..you can assume tolower is a simple addition of hex 20 MG>when the hash algo gets ahold of the character the 0x41 hashes differently than 0x61 > but hashed passwords are not my principal concern > > I've downloaded and built 6.0.18 and looked at the DSR code - doesn't > look like a very big job to make the changes that I want so I may have > go tomorrow. As I use 6.0.18 I can easily test it by just patching in > the .class file for DataSourceRealm on my dev. system. MG>yes the DSR example is comprehensive and easy to follow MG>Keep us apprised on how you progress.. MG>Best > Regards MG>MG > Alan > > > > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > _ It’s the same Hotmail®. If by “same” you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_AE_Same_022009
Re: Authenticating Users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan,
On 2/22/2009 4:47 PM, Alan Chaney wrote:
> From my point of view, as I don't use hashed passwords at the moment the
> easiest thing to do is to modify the DataSourceRealm as suggested by
> Mark Thomas. However, I think that the ability to extend the login
> system to use either a user name or an email address would probably be
> useful for other people.
I think it might be easier than you think.
Here's the code for DataSourceRealm's SQL query builder for the
"credential selection" (TC 6.0.16):
// Create the credentials PreparedStatement string
temp = new StringBuffer("SELECT ");
temp.append(userCredCol);
temp.append(" FROM ");
temp.append(userTable);
temp.append(" WHERE ");
temp.append(userNameCol);
temp.append(" = ?");
preparedCredentials = temp.toString();
All you need to do is hack the start() method (which builds the SQL
queries) plus the credentials() method and you should be good to go. You
could create a relatively inelegant system of attributes that
would build a more complex query, or you could just hack the realm and
be done with it.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmh/0gACgkQ9CaO5/Lv0PAYVQCgvDo9FpFQd4zxgmuG66zqNe1y
MlUAn3MmLx8Bb4LScyhXPpfIspcCKygu
=8PUl
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the tomcat server IP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yuval, On 2/21/2009 1:44 PM, Yuval Perlov wrote: > Also, from the socket object you can always call > socket.getLocalAddress() on an outgoing connection. This is useful if > you want to make sure you are getting the IP for a particular network. Aren't we going around in circles, here? The OP can't use getLocalAddress because there are multiple interfaces on the server. There is no reference to the socket to get the local address from. There is no request to get the local address from. Your suggestion to make an outgoing connection won't work, either, because there's no guarantee that the outgoing connection's IP is the "right one". The only way to find out what the correct IP address is to grab the running Connector from memory and interrogate it. This could possibly be done using JMX, but I'm no expert at what parts of Tomcat are available via JMX. I suppose you could also attempt to manually parse the server.xml file looking for the definition. Then again, you might get the wrong connector if multiple are defined. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmh86QACgkQ9CaO5/Lv0PAf/wCfeMZe6952CL21pheyG0KIx8KJ g8sAn1isim1vxPk60bukHIjAw35McV9k =54vn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
Martin Gainty wrote: Which specific attributes are you seeking that are not in DataSourceRealm? http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#DataSourceRealm ? To summarize I (or,actually my "marketing dept') have the following requirements. 1. password be case insensitive [I may be able to talk them out of this] 2. username be case insensitive. 3. email address can be used as a synonym for the user name. 4. Security managed by Tomcat CMS. Mark T suggested that I modify DSR appropriately. Chris Schultz pointed out correctly that it gets a bit more complicated if the pwd must be hashed. I've looked at the code to DSR and it seems to me that the following would work. 1. add an 'alternative' userNameCol (eg altNameCol) and in the configuration as above point that at the email column. 2. in the code, IF the login fails using the 'user_name' then try it with the altNameCol. 3. to make things case insenstive simply convert the username to lower case and use a 'lower' function on the column value. 4. to make the thing a bit more flexible an additional boolean parameter 'isCaseInsensitive' could be added to select the behavior has in 3. above. Defaults could be chosen such that the current configuration setup still works (eg the default value for isCaseInsensitive is false) Only real gotcha that I can see for making it database independent is that the function used to create lower case is not univerally 'lower()' (M/SQL appears to be toLower()) so it might be necessary to pass the string for the function name as an optional configuration parameter. I realize that many people would advise against the idea of case insensitive passwords - however, despite my personal reservations I am willing to accept that in the case of this particular application the reduction in security is acceptable. If hashed pwds are used then there are 3 solutions: 1. don't allow case insensitive passwords - only user names. 2. provide two columns one for lower case versions of the pwd. 3. convert all the existing password HASHES to the lower case equivalent, but hashed passwords are not my principal concern I've downloaded and built 6.0.18 and looked at the DSR code - doesn't look like a very big job to make the changes that I want so I may have go tomorrow. As I use 6.0.18 I can easily test it by just patching in the .class file for DataSourceRealm on my dev. system. Regards Alan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Authenticating Users
Which specific attributes are you seeking that are not in DataSourceRealm? http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#DataSourceRealm ? Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > Date: Sun, 22 Feb 2009 13:47:54 -0800 > From: a...@compulsivecreative.com > To: users@tomcat.apache.org > Subject: Re: Authenticating Users > > Gregor Schneider wrote: > > To the OP: > > > > 1. May I ask what database it is you're using? > > > Postgres - but a more general solution would be nice. > > 2- I'd go for the following solution: > > > > Create a JSP-page accepting the credentials. The username should be > > converted to uppercase. The password should be left as is so that > > case-sensivity here is maintained. > > > > That doesn't actually fit in with the Servlet CMS. I can easily decode > the user name and password by your mechanism. However, then I have to > rather extensively modify my code (covering 3 applications and 4 web > services) to apply the credentials. What I was looking for was a way of > extending what I already have. > > > Don't know if I'm missing something, but to me that looks like a walk > > in the park. > > > See above. The problem is not decoding the password, but making sure > that the container managed security mechanism is maintained. > > So far, the best suggestions that I've had are: > > 1. Modify DataSourceRealm > 2. Use secuirityfilter. > > From my point of view, as I don't use hashed passwords at the moment > the easiest thing to do is to modify the DataSourceRealm as suggested by > Mark Thomas. However, I think that the ability to extend the login > system to use either a user name or an email address would probably be > useful for other people. I'll give it some thought. > > Regards > > Alan > > > > > > > > > > > > > > > > > > Rgds > > > > Gregor > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > _ Windows Live™ Hotmail®…more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_022009
Re: Authenticating Users
Gregor Schneider wrote: To the OP: 1. May I ask what database it is you're using? Postgres - but a more general solution would be nice. 2- I'd go for the following solution: Create a JSP-page accepting the credentials. The username should be converted to uppercase. The password should be left as is so that case-sensivity here is maintained. That doesn't actually fit in with the Servlet CMS. I can easily decode the user name and password by your mechanism. However, then I have to rather extensively modify my code (covering 3 applications and 4 web services) to apply the credentials. What I was looking for was a way of extending what I already have. Don't know if I'm missing something, but to me that looks like a walk in the park. See above. The problem is not decoding the password, but making sure that the container managed security mechanism is maintained. So far, the best suggestions that I've had are: 1. Modify DataSourceRealm 2. Use secuirityfilter. From my point of view, as I don't use hashed passwords at the moment the easiest thing to do is to modify the DataSourceRealm as suggested by Mark Thomas. However, I think that the ability to extend the login system to use either a user name or an email address would probably be useful for other people. I'll give it some thought. Regards Alan Rgds Gregor - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
(function() {
var doLogin = function() {
var uname = doc.byId("name").toLowerCase();
var passw = doc.byId("password").toLowerCase();
//var digest = sha1.digest(uname + ":My Realm:" + passw);
xhr.send(...);
}
return {
login: function() {
doLogin();
return false;
}
}
})();
...
all hidden and private handling of the user name and password. Might
not work without javascript :)
On Feb 22, 2009, at 4:11 PM, Gregor Schneider wrote:
To the OP:
1. May I ask what database it is you're using?
2- I'd go for the following solution:
Create a JSP-page accepting the credentials. The username should be
converted to uppercase. The password should be left as is so that
case-sensivity here is maintained.
Don't know if I'm missing something, but to me that looks like a walk
in the park.
Rgds
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
-
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: Authenticating Users
To the OP: 1. May I ask what database it is you're using? 2- I'd go for the following solution: Create a JSP-page accepting the credentials. The username should be converted to uppercase. The password should be left as is so that case-sensivity here is maintained. Don't know if I'm missing something, but to me that looks like a walk in the park. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to close open connections after application stop?
Mark Thomas ha scritto: Edoardo Panfili wrote: Using this code in destroy() method of a servlet marked as 1 Yep - that is the sort of code you'd need. Using a context listener would be a better solution as Tomcat is free to call destroy() on your Servlet whenever it likes. Thank again (to you and the list) edoardo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to close open connections after application stop?
Edoardo Panfili wrote: > Using this code in destroy() method of a servlet marked as > 1 Yep - that is the sort of code you'd need. Using a context listener would be a better solution as Tomcat is free to call destroy() on your Servlet whenever it likes. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to close open connections after application stop?
Alan Chaney ha scritto:
I don't think so. Let me recap your problem:
When you undeploy an application from tomcat (using the DBCP pooling
mechanism) you can't make STRUCTURAL changes to the database because it
complains that connections are still in use.
This is exactly what one would expect. I've encountered the same
problem. When an application finishes with a database connection it is
returned to the pool. That's exactly what a connection pool is for!
As far as I can see by looking at the tomcat source code the connection
pool is created at startup and remains active until TC shutdown. Once a
connection has been obtained from the pool it may stay 'active' for the
entire duration of the TC session (that is, from TC start to TC stop)
Obviously, depending upon your usage, it is possible for more than one
application in the same container to be reusing the same connection
pool. Your original post indicates that only one app. is using the
database.
It seems to me that:
.
3. As I assume you are using DBCP in Tomcat, carefully read the DBCP
docs, configure your system so that you can directly access the POOLED
connections, keep a list of ALL the connections you use and then shut
them down at the end. This is fraught with difficulty.
Using this code in destroy() method of a servlet marked as
1
seems work
---
try {
Context ambiente = (Context) new
InitialContext().lookup("java:comp/env");
DataSource pool = (DataSource) ambiente.lookup("jdbc/anArchive");
if(pool instanceof org.apache.tomcat.dbcp.dbcp.BasicDataSource){
org.apache.tomcat.dbcp.dbcp.BasicDataSource source =
(org.apache.tomcat.dbcp.dbcp.BasicDataSource) pool;
System.out.println("closing source...");
source.close();
System.out.println("closed.");
// System.out.println("maxIdle:"+source.getMaxIdle());
// source.setMaxIdle(0);
// System.out.println("maxIdle:"+source.getMaxIdle());
}
} catch (Exception e) {
e.printStackTrace();
}
---
"source.setMaxIdle(0);" is not necessary.
also accessToUnderlyingConnectionAllowed="true" in context is not necessary.
Edoardo
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to close open connections after application stop?
Alan Chaney ha scritto:
Edoardo wrote
I have
resultset.close();
statement.close();
connection.close();
in my code.
and
connection = dataSource.getConnection();
seems very close to my
ambiente = (Context) new InitialContext().lookup("java:comp/env");
pool = (DataSource) ambiente.lookup("jdbc/myApp);
Connection conn = pool.getConnection();
there are a lot of debug information in my code and seems that nothing
is going wrong (no exceptions).
but... if you post that it means that I am doing something wrong.
Edoardo
I don't think so. Let me recap your problem:
When you undeploy an application from tomcat (using the DBCP pooling
mechanism) you can't make STRUCTURAL changes to the database because it
complains that connections are still in use.
Yes.
This is exactly what one would expect. I've encountered the same
problem. When an application finishes with a database connection it is
returned to the pool. That's exactly what a connection pool is for!
As far as I can see by looking at the tomcat source code the connection
pool is created at startup and remains active until TC shutdown. Once a
connection has been obtained from the pool it may stay 'active' for the
entire duration of the TC session (that is, from TC start to TC stop)
Obviously, depending upon your usage, it is possible for more than one
application in the same container to be reusing the same connection
pool. Your original post indicates that only one app. is using the
database.
Yes.
It seems to me that:
1. you could just shutdown tomcat! If this is a production site the best
plan would be to write a script which renames the database and does
whatever else you need, test it on a development machine and just find a
'quiet' time to shutdown the site, update the db and restart.
This way is usable (and is the easiest, i need less that 30sec). At the
present time is also usable (not very high traffic) but I'd like to find
a definitive solution.
2. Move the connection pool into your application. Thus shutting down
the application would shutdown the pool.
:-) some times ago the pool was managed by my application with some
custom code, in the new version of the system I rely on tomcat (hope
that this choice is not so bad!)
3. As I assume you are using DBCP in Tomcat, carefully read the DBCP
docs, configure your system so that you can directly access the POOLED
connections, keep a list of ALL the connections you use and then shut
them down at the end. This is fraught with difficulty.
Your assumption is right.
This seems non so easy, but I will try.
Thank you very much for your (and other users) help.
Edoardo
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to close open connections after application stop?
Edoardo wrote
I have
resultset.close();
statement.close();
connection.close();
in my code.
and
connection = dataSource.getConnection();
seems very close to my
ambiente = (Context) new InitialContext().lookup("java:comp/env");
pool = (DataSource) ambiente.lookup("jdbc/myApp);
Connection conn = pool.getConnection();
there are a lot of debug information in my code and seems that nothing
is going wrong (no exceptions).
but... if you post that it means that I am doing something wrong.
Edoardo
I don't think so. Let me recap your problem:
When you undeploy an application from tomcat (using the DBCP pooling
mechanism) you can't make STRUCTURAL changes to the database because it
complains that connections are still in use.
This is exactly what one would expect. I've encountered the same
problem. When an application finishes with a database connection it is
returned to the pool. That's exactly what a connection pool is for!
As far as I can see by looking at the tomcat source code the connection
pool is created at startup and remains active until TC shutdown. Once a
connection has been obtained from the pool it may stay 'active' for the
entire duration of the TC session (that is, from TC start to TC stop)
Obviously, depending upon your usage, it is possible for more than one
application in the same container to be reusing the same connection
pool. Your original post indicates that only one app. is using the database.
It seems to me that:
1. you could just shutdown tomcat! If this is a production site the best
plan would be to write a script which renames the database and does
whatever else you need, test it on a development machine and just find a
'quiet' time to shutdown the site, update the db and restart.
2. Move the connection pool into your application. Thus shutting down
the application would shutdown the pool.
3. As I assume you are using DBCP in Tomcat, carefully read the DBCP
docs, configure your system so that you can directly access the POOLED
connections, keep a list of ALL the connections you use and then shut
them down at the end. This is fraught with difficulty.
Regards
Alan
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to close open connections after application stop?
Martin Gainty ha scritto:
javax.sql.DataSource
dataSource ;
java.sql.Connection connection;
java.sql.Statement statement;
java.sqlResultset resultSet;
code..
try{
connection = dataSource.getConnection();
statement = connection.prepareStatement("SELECT FU FROM BAR");
resultSet = statement.executeQuery();
}
catch (SQLException sqlEx)
{
try
{
resultset.close();
statement.close();
connection.close();
}
catch(java.sql.SQLException excp)
{
log.debug("A SQLException has been produced another Exception on
resultset/statement/connection was produced where the message="=excp.getMessage());
}
}
catch (Exception ex)
{
try
{
resultset.close();
statement.close();
connection.close();
}
catch(java.sql.SQLException excp)
{
log.debug("A General Exception has been produced another SQLException on
resultset/statement/connection was produced where the
message="=excp.getMessage());
}
}
catch(java.sql.SQLException excp)
{
log.debug("SQLException on resultset/statement/connection close
message="=excp.getMessage());
}
}
finally
{
try
{
resultset.close();
statement.close();
connection.close();
}
catch(java.sql.SQLException excp)
{
log.debug("Exception on resultset/statement/connection close
message="=excp.getMessage());
}
} //end finally..
I have
resultset.close();
statement.close();
connection.close();
in my code.
and
connection = dataSource.getConnection();
seems very close to my
ambiente = (Context) new InitialContext().lookup("java:comp/env");
pool = (DataSource) ambiente.lookup("jdbc/myApp);
Connection conn = pool.getConnection();
there are a lot of debug information in my code and seems that nothing
is going wrong (no exceptions).
but... if you post that it means that I am doing something wrong.
Edoardo
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to close open connections after application stop?
javax.sql.DataSource
dataSource ;
java.sql.Connection connection;
java.sql.Statement statement;
java.sqlResultset resultSet;
code..
try
{
connection = dataSource.getConnection();
statement = connection.prepareStatement("SELECT FU FROM BAR");
resultSet = statement.executeQuery();
}
catch (SQLException sqlEx)
{
try
{
resultset.close();
statement.close();
connection.close();
}
catch(java.sql.SQLException excp)
{
log.debug("A SQLException has been produced another Exception on
resultset/statement/connection was produced where the
message="=excp.getMessage());
}
}
catch (Exception ex)
{
try
{
resultset.close();
statement.close();
connection.close();
}
catch(java.sql.SQLException excp)
{
log.debug("A General Exception has been produced another SQLException on
resultset/statement/connection was produced where the
message="=excp.getMessage());
}
}
catch(java.sql.SQLException excp)
{
log.debug("SQLException on resultset/statement/connection close
message="=excp.getMessage());
}
}
finally
{
try
{
resultset.close();
statement.close();
connection.close();
}
catch(java.sql.SQLException excp)
{
log.debug("Exception on resultset/statement/connection close
message="=excp.getMessage());
}
} //end finally..
Martin
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business
of Sender. This transmission is of a confidential nature and Sender does not
endorse distribution to any party other than intended recipient. Sender does
not necessarily endorse content contained within this transmission.
> Date: Sun, 22 Feb 2009 11:25:42 +0100
> From: edoa...@aspix.it
> To: users@tomcat.apache.org
> Subject: How to close open connections after application stop?
>
> Hy,
>
> I have one webapp in Tomcat 6.0.18 with this context:
>
>
>type="javax.sql.DataSource"
>maxActive="8" maxIdle="5" maxWait="300"
>username="myApp" password="passwd"
>driverClassName="org.postgresql.Driver"
>url="jdbc:postgresql://127.0.0.1:5432/myApp"
>removeAbandoned="true"
>removeAbandonedTimeout="30"
>logAbandoned="true"
>/>
>
>
> After application stop (using tomcat manager) I'd like to (drastic
> example) rename the db, but I can't do it because there are open
> connections.
>
> There are no other application using myApp db, but with "ps ax" I can see:
>
> 189 ?? Ss 0:02.67 postgres: myApp myApp 127.0.0.1(49162) idle
>
> Is there a way to close the connection without closing Toncat?
>
> thank you
> Edoardo
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
_
Windows Live™ Hotmail®…more than just e-mail.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_022009
Re: Authenticating Users
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, I was the OP on this one. Mark just made a couple of suggestions. On 2/21/2009 4:06 PM, Mark Thomas wrote: 5. Patch DataSourceRealm 6. Make case sensitivity configurable and contribute your patch back to the ASF. 7. Use securityfilter to write your realm, and not be tied to Tomcat. Had a brief look at 'securityfilter' - however we actually do require container managed security as we have several applications. Other alternative as previously mentioined is acegi. 8. Many databases use case-insensitive string comparisons already. Case-insensitive passwords (probably a bad idea!) Actually, in general, I agree that its a bad idea. However, each case has to be handled in the light of the actual users expectations. In the case of this specific application the users are artists who are generally extremely computer naive. We commonly get support enquiries "I can't log into my account" EVEN THOUGH we have sent them their account names and passwords because they are not correctly capitalizing their usernames or passwords. It is important to keep to keep the case of usernames because, as I said, they are artists, and the capitalization may have significance to them as part of their brand. The information on the site is publically available after it has been published. There is no commercial or sensitive information on the site. will work if you aren't hashing them. If you are, you'll have to lowercase them or something. Exactly. One problem for a general solution is that there are variations in the name of the 'lowercase' function between databases. So far, I've found that Postgres, MySQL and Oracle appear to support 'lower()' but M/SQL has it as tolower() (thanks again MS) If you /are/ hashing them, you'll need to do a password migration where anyone who changes their password gets it lowercased but passwords that existed beforehand are still case-sensitive. You cannot avoid this, now matter what your solution is. In this specific case at the moment we aren't hashing them, but you raise a good general point about hashing which I'll have to think about. Regards Alan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to close open connections after application stop?
Edoardo Panfili ha scritto:
Mark Thomas ha scritto:
Edoardo Panfili wrote:
Hy,
I have one webapp in Tomcat 6.0.18 with this context:
After application stop (using tomcat manager) I'd like to (drastic
example) rename the db, but I can't do it because there are open
connections.
There are no other application using myApp db, but with "ps ax" I can
see:
189 ?? Ss 0:02.67 postgres: myApp myApp 127.0.0.1(49162) idle
Is there a way to close the connection without closing Toncat?
Hmm. If you were managing your own pool then you could call close() on
the pool.
Arguably, if Tomcat creates an context level pool, Tomcat should close
it when the context stops but I don't think it does. That probably calls
for some testing to check behaviour and possibly an enhancement request.
this is my code to retrieve a connection
this is the right one (not so different)
ambiente = (Context) new InitialContext().lookup("java:comp/env");
pool = (DataSource) ambiente.lookup("jdbc/myApp);
Connection conn = pool.getConnection();
..
conn.close(); // this in inside finally
sorry for the wrong post
Edoardo
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to close open connections after application stop?
Edoardo Panfili wrote:
> Mark Thomas ha scritto:
>> Edoardo Panfili wrote:
>>> Hy,
>>>
>>> I have one webapp in Tomcat 6.0.18 with this context:
>>>
>>>
>>> >> type="javax.sql.DataSource"
>>> maxActive="8" maxIdle="5" maxWait="300"
>>> username="myApp" password="passwd"
>>> driverClassName="org.postgresql.Driver"
>>> url="jdbc:postgresql://127.0.0.1:5432/myApp"
>>> removeAbandoned="true"
>>> removeAbandonedTimeout="30"
>>> logAbandoned="true"
>>> />
>>>
>>>
>>> After application stop (using tomcat manager) I'd like to (drastic
>>> example) rename the db, but I can't do it because there are open
>>> connections.
>>>
>>> There are no other application using myApp db, but with "ps ax" I can
>>> see:
>>>
>>> 189 ?? Ss 0:02.67 postgres: myApp myApp 127.0.0.1(49162) idle
>>>
>>> Is there a way to close the connection without closing Toncat?
>>
>> Hmm. If you were managing your own pool then you could call close() on
>> the pool.
>>
>> Arguably, if Tomcat creates an context level pool, Tomcat should close
>> it when the context stops but I don't think it does. That probably calls
>> for some testing to check behaviour and possibly an enhancement request.
> this is my code to retrieve a connection
> ---
> ambiente = (Context) new InitialContext().lookup("java:comp/env");
> pool = (DataSource) ambiente.lookup("jdbc/anArchive");
> Connection conn = pool.getConnection();
> ..
> conn.close(); // this in inside finally
> ---
>
> but If my code is wrong removeAbandoned="true" is a guaranty to have the
> connection closed after few time (30sec). is this right?
Not really. It only closes connections your application has abandoned.
It won't touch the idle ones in the pool.
>> Can you close the connections from the database management tools?
> I'm sorry but: where can I found it? (Do you mean from postgres? can't
> figure how)
Yes. Sorry, I don't know postgres.
> I am searching for that also inside tomcatProbe but can't find it.
I don't think it supports it.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to close open connections after application stop?
Mark Thomas ha scritto:
Edoardo Panfili wrote:
Hy,
I have one webapp in Tomcat 6.0.18 with this context:
After application stop (using tomcat manager) I'd like to (drastic
example) rename the db, but I can't do it because there are open
connections.
There are no other application using myApp db, but with "ps ax" I can see:
189 ?? Ss 0:02.67 postgres: myApp myApp 127.0.0.1(49162) idle
Is there a way to close the connection without closing Toncat?
Hmm. If you were managing your own pool then you could call close() on
the pool.
Arguably, if Tomcat creates an context level pool, Tomcat should close
it when the context stops but I don't think it does. That probably calls
for some testing to check behaviour and possibly an enhancement request.
this is my code to retrieve a connection
---
ambiente = (Context) new InitialContext().lookup("java:comp/env");
pool = (DataSource) ambiente.lookup("jdbc/anArchive");
Connection conn = pool.getConnection();
..
conn.close(); // this in inside finally
---
but If my code is wrong removeAbandoned="true" is a guaranty to have the
connection closed after few time (30sec). is this right?
Can you close the connections from the database management tools?
I'm sorry but: where can I found it? (Do you mean from postgres? can't
figure how)
I am searching for that also inside tomcatProbe but can't find it.
thank you
Edoardo
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: very slow class loading on initial JSP/servlet request after restart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sam, On 2/20/2009 6:44 PM, Sam Hokin wrote: > Thanks, Chris. I ran e2fsck with the -c option, which runs badblocks, > when I tested it earlier. And I just ran badblocks again - 0 bad blocks > found. Did you run badblocks on the array, or on an individual disk? I would expect the disk-level check to be more useful. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmhaVYACgkQ9CaO5/Lv0PD0tACghW7VAUa5yZPZ8B4mxOTFFLCV 8zEAnj4lqIXCfdsbPRBpJrFFCmpk8ftN =f1uv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Record and simulate a web app
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Taylan, On 2/22/2009 8:26 AM, Taylan Develioglu wrote: > Guys, I've been following this thread for a while now, but doesn't > Jmeter already do what you're trying to accomplish here? No. We're not trying to reply requests to the server. We're trying to replay responses /from/ the server. > I've used jmeter's proxy to record and replay http requests/responses > before with success. How do you replay a response? Can you set up the proxy to respond without actually proxying? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmhaQ8ACgkQ9CaO5/Lv0PBxEwCglCM+q1usci/6l5bDObwBoAyl wikAn3k0GmUFs3sqsMktVHShy5NafkvT =gr0E -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 2/21/2009 4:06 PM, Mark Thomas wrote: > 5. Patch DataSourceRealm > > 6. Make case sensitivity configurable and contribute your patch back to > the ASF. 7. Use securityfilter to write your realm, and not be tied to Tomcat. 8. Many databases use case-insensitive string comparisons already. Case-insensitive passwords (probably a bad idea!) will work if you aren't hashing them. If you are, you'll have to lowercase them or something. If you /are/ hashing them, you'll need to do a password migration where anyone who changes their password gets it lowercased but passwords that existed beforehand are still case-sensitive. You cannot avoid this, now matter what your solution is. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmhZ48ACgkQ9CaO5/Lv0PAlOACgrwTelHoTXc0nAbo0+D0rFhez G3YAnjh3JqHj/bLWvFY2vsFFRMTcd7oK =GYQE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS6, Tomcat 6.0, ISAPI redirector 1.2.27 - no log on one server
Rick To redirect requests to a program1. In IIS Manager, expand the local computer, right-click the Web site or directory you want to redirect, and click Properties. 2. Click the Home Directory, Virtual Directory, or Directory tab. 3. Under The content for this source should come from, click A redirection to a URL. In the Redirect to box, type the URL of the program, including any redirect variables needed to pass parameters to the program. For example, to redirect all requests for scripts in a Scripts directory to a logging program that records the requested URL and any parameters passed with the URL, type /Scripts/Logger.exe?URL=$V+PARAMS=$P. $V and $P are redirect variables. 4. Select the The exact URL entered above check box to prevent the Web server from appending the original file name to the destination URL. where $P=If the request contains parameters such as http://www.oldsite.com/cart.asp?id=Blue , then $P would represent all the values after the question mark in the URL, example $P would equal id=Blue (no question mark). where $V=If the request is for http://www.oldsite.com/shopping/cart.asp then $V would contain everything after the server name, eg: /shopping/cart.asp. http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/6b855a7a-0884-4508-ba95-079f38c77017.mspx?mfr=true http://www.mcanerin.com/EN/articles/301-redirect-IIS.asp please feel free to Ping me offline as this is O/T for this list Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > Date: Wed, 21 Jan 2009 19:35:12 -0800 > From: rclar...@yahoo.com > Subject: IIS6, Tomcat 6.0, ISAPI redirector 1.2.27 - no log on one server > To: users@tomcat.apache.org > > I've searched all over the web and on the list to try and find an > answer to my question. We have a similar installation for a DEV, TEST, > STAGE and PROD environments, namely: > > Windows 2003 > Tomcat 6.0 (I don't remember the full version, but it isn't critical to > this post) > isapi_redirect.dll version 1.2.27 > IIS6 > > I've set the system up on all of our boxes -- same configuration, and > it runs on all of them but one production server. On that machine, the > redirector shows in IIS with the green up arrow but no matter what I do > I cannot get any kind of log out of the redirector. IIS is not routing > any traffic to the redirector as far as I can tell from the IIS log. > > I really could use some ideas on what to try at this point to > troubleshoot this problem. I've played around with permissions, changed > configuration settings (tried them in the registry as well as in the > properties file), etc. The exact same configuration is working on 5 > other servers, so I know that the combination is good. I now that I am > missing something, probably simple, but I'm at my wits end. > > Any advice on what to try to get a log out of the redirector would be > very welcome, as I've exhausted my ability to research it. Thank you! > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > _ Windows Live™ Hotmail®…more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_022009
Re: How to close open connections after application stop?
Edoardo Panfili wrote: > Hy, > > I have one webapp in Tomcat 6.0.18 with this context: > > > type="javax.sql.DataSource" > maxActive="8" maxIdle="5" maxWait="300" > username="myApp" password="passwd" > driverClassName="org.postgresql.Driver" > url="jdbc:postgresql://127.0.0.1:5432/myApp" > removeAbandoned="true" > removeAbandonedTimeout="30" > logAbandoned="true" > /> > > > After application stop (using tomcat manager) I'd like to (drastic > example) rename the db, but I can't do it because there are open > connections. > > There are no other application using myApp db, but with "ps ax" I can see: > > 189 ?? Ss 0:02.67 postgres: myApp myApp 127.0.0.1(49162) idle > > Is there a way to close the connection without closing Toncat? Hmm. If you were managing your own pool then you could call close() on the pool. Arguably, if Tomcat creates an context level pool, Tomcat should close it when the context stops but I don't think it does. That probably calls for some testing to check behaviour and possibly an enhancement request. Can you close the connections from the database management tools? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Record and simulate a web app
Guys, I've been following this thread for a while now, but doesn't
Jmeter already do what you're trying to accomplish here?
I've used jmeter's proxy to record and replay http requests/responses
before with success.
Or am I missing something here?
Here's a link to some instructions :
http://jakarta.apache.org/jmeter/usermanual/jmeter_proxy_step_by_step.pd
f
Rgds,
T
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: vrijdag 20 februari 2009 17:07
To: Tomcat Users List
Subject: Re: Record and simulate a web app
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Youssef,
On 2/20/2009 10:45 AM, Youssef Mohammed wrote:
> Yeah I was thinking that the capture code would perfectly fit in some
HTTP
> tunnel so that we can capture the whole thing coming out of the web
server ,
> what do you think ?
Okay, I took a stack trace of my servlet's code right in the middle of
the request (TC 5.5.26) and found this at the top (it's really my first
delve into exactly what code gets executed before application code, so
forgive me if you already knew this):
...blah...blah...blah...
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
74)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:87
4)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc
essConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint
.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow
erWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:689)
The "blah blah blah" part is all application code from there on up.
ApplicationFilterChain.internalDoFilter calls the configured filters in
order, starting with mine (which I of course configured first).
Note that I'm looking at the source for Tomcat 6.0.16 yet running
5.5.26. Stupid, I know, but the architecture hasn't changed /that/ much.
I started at the /bottom/, ignoring the socket stuff, and right there in
Http11Processor.prepareResponse I find this:
headers.setValue("Date").setString(date);
So, Tomcat post-processes the HTTP headers at the Connector level.
Without writing your own /Connector/, you aren't going to be able to
intercept the response properly. I was hoping to get away with a valve.
I suppose you could subclass, say, Http11Processor and, in your
constructor, replace the outputBuffer class with a wrapper for
InternalOutputBuffer.
But this is getting a little messy for me. Since I don't need it, I'm
not too concerned about getting it done. :(
If you figure out a way to capture the response, and determine how how
to uniquely identify requests to match the response you want to return,
I can show you how to write a servlet that can re-play the
previously-saved responses.
Good luck,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkme1R0ACgkQ9CaO5/Lv0PByBwCfay9gRGEJ/R8m5H+iGB3s0lLP
vP8An122DIn2SreN7czoa1+4HMaWeNPZ
=anEz
-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
How to close open connections after application stop?
Hy, I have one webapp in Tomcat 6.0.18 with this context: After application stop (using tomcat manager) I'd like to (drastic example) rename the db, but I can't do it because there are open connections. There are no other application using myApp db, but with "ps ax" I can see: 189 ?? Ss 0:02.67 postgres: myApp myApp 127.0.0.1(49162) idle Is there a way to close the connection without closing Toncat? thank you Edoardo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
