SV: close pooled conection-by value or by reference
This isnt really related to Tomcat, but I really don't care:
You could make the connection static in the class DatabaseManager, so that
your application only uses one connection against DB. This could (?) cause
problems with Threading and several users accessing at once (I guess...).
Really not sure about this though...
However, to be 100% sure that the connection is closed and the Connection
object is destroyed by the garbage-collector, you should add connection =
null in the class MyMainClass as well, otherwise this class would hold a
copy of this object until your program terminates...
You should consider using a layered approach to programming.
Create a class, DataIO (reading and writing) that has abstract methods for
retrieving data and updating them etc.
Create classes for your data, which act as dataholders. I.e. create a class
MyMainClassData that holds the data retrieved in MyMainClass by the
database. Then create abstract methods for retrieving and manipulating the
data in this object.
Finally you implement these methods in yet another class, DatabaseDataIO
that implements your interface against the database.
The solution would look something like this:
MyMainClass:
public static final void main(String[] args) {
New MyMainClass().doTheStuff(neededArgs);
}
Public void doTheStuff() {
DatabaseDataIO ddio = new DatbaseDataIO();
MyMainClassData data = ddio.getData();
... manipulate data
Ddio.saveData(data);
}
DataIO:
Public abstract MyMainClassData getData();
Public abstract void saveData(MyMainClassData data);
DatabaseDataIO:
Extend and Implement the methods of DataIO
MyMainClassData:
Private fields for every data needed.
Get and set methods for manipulating the data
In this case you could, of course, still use DataBaseManager, but with or
without it, when you find yourself creating the Main-class, you don't have
to worry about whether or not the connection is being closed. You can trust
that the DatabaseDataIO class does this for you.
Hope my late Saturday night writing is understandable.
Öyvind Johansen
ETC ElectricTimeCar
-Opprinnelig melding-
Fra: Tony Smith [mailto:[EMAIL PROTECTED]
Sendt: 23. juli 2005 23:19
Til: Tomcat Users List
Emne: close pooled conection-by value or by reference
I think this is a classic java question: Pass by
reference or by value. I have a DatabaseManager class
which takes care of get conection from connection pool
and release the connectoin. I am not sure about the
release part. Here is my code:
class MyMainClass
public static final void main(String[] args){
Connection connection =
DatabaseManager.getConnection();
//jdbc work.
DatabaseManager.closeConnection(connection);
...
}
public class DatabaseManager {
public static Connection getConnection(){
Connection connection =
getConectionFromDataSource();
return connection;
}
public static void closeConnection(Connection
conn){
if (conn != null){
try{
conn.close();
}catch(SQLException sqle){
sqle.printStackTrace();
}
}
conn = null;
}}
I am not sure if the connection is released
Thanks,
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java processes in tomcat...
Possible reasons (not really sure here): You open a filestream, but you do not close it after use You start a Thread that never finishes (no stop when tomcat runs destroy() on your webapp) You start a ServerSocket listener that doesn't timeout or stop gracefully. Some other reason I do not see. Oyvind Johansen ElectricTimeCar, Norway -Opprinnelig melding- Fra: Gulshan Babajee [mailto:[EMAIL PROTECTED] Sendt: 30. juni 2005 10:35 Til: 'tomcat-user@jakarta.apache.org' Emne: Java processes in tomcat... Hi, I've posted this question sometimes ago, but did not receive any reply. Am sending it again if ever someone has got an answer meanwhile Am actually using tomcat version 5.0.28 on Red Hat Linux 6.2. What i've notice is that each time i compile my java classes, copy them to /WEB-INF/classes dir. and then redeploy my web application consisting of jsp pages, I saw the number of java process increases when I do a 'ps -aux' That is if before compilation of my java classes there were 30 java processes, then after compilation I saw 30 new java processes when I did a 'ps -aux' The problem is that tomcat does not kill the previous java processes that were associated with my old java classes. Subsequently if I do 5 compilation, I'll get (5 x 40) java processes and finally I got an 'OutOfMemoryError'. Can anyone please tell me what's the cause of the above problem and how to resolve it. thanks in advance -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.6/33 - Release Date: 28-06-2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat and Internet Explorers caching
Hello! Our web-application uses a combination of JSP-pages and a controller servlet. When viewing these pages with Internet Explorer weird things tend to happen. I found out that if Internet Explorers caching is set to automatic checking for newer versions on the server everything goes wrong. Instead of sending requests to the servlet, IE just simply takes an answer from its cache, and thus presenting the wrong results. When changing the setting to always the problem disappears. Now, telling every user to change this setting would require almost as much work as convincing them that Firefox and/or Opera are much better. So, are there any ways to tell IE that it shouldn't cache my servlet/jsp-pages? Regards, Øyvind Johansen ElectricTimeCar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and Internet Explorers caching
You may be right, but I think it's just our weird way of combining jsp/servlets with a magnet card reader that takes IE off guard. Heres a typical example: User uses his user card on our magnet card reader. The reader tells our client (which implements IE through an ActiveX control, dont ask why). The reader creates an URL which sends the card information to a servlet as a parameter. Ie /Servler?paramname=paramval. The servlet handles the request and determines where the users should go (1 page for normal users, another for admins etc). When Automaticly is set, this makes IE return the page of the last user that was successfully using the server (in which IE saved these pages in the cache). This means that user A may get the admin interface even though he isn't an administrator. In the web-application log, nothing happens when this behaviour shows itself. The web-app always logs all user-logins, and the lack of this proves that IE simply isn't sending the request to the server... Did it become clearer? -Opprinnelig melding- Fra: Allistair Crossley [mailto:[EMAIL PROTECTED] Sendt: 22. juni 2005 12:09 Til: Tomcat Users List Emne: RE: Tomcat and Internet Explorers caching Hi, Not an answer as such, but all our dev machines (and we do LOTS of changes per 5 minutes) have Automatically switched on, and we don't experience this problem. Like I say, not a solution, but perhaps you are looking in the wrong direction. Cheers, Allistair. -Original Message- From: Øyvind Johansen [mailto:[EMAIL PROTECTED] Sent: 22 June 2005 11:11 To: 'Tomcat Users List' Subject: Tomcat and Internet Explorers caching Hello! Our web-application uses a combination of JSP-pages and a controller servlet. When viewing these pages with Internet Explorer weird things tend to happen. I found out that if Internet Explorers caching is set to automatic checking for newer versions on the server everything goes wrong. Instead of sending requests to the servlet, IE just simply takes an answer from its cache, and thus presenting the wrong results. When changing the setting to always the problem disappears. Now, telling every user to change this setting would require almost as much work as convincing them that Firefox and/or Opera are much better. So, are there any ways to tell IE that it shouldn't cache my servlet/jsp-pages? Regards, Øyvind Johansen ElectricTimeCar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Help/Examples setting up security settings2
The /Simple_JSP part of the URL should be left out. Always start typing from the web-app folder. (because, who knows when you want to rename the webapp?) If you remove the /Simple_JSP part of the URLs in the web.xml, I think it will work, additionally, you should try not setting restricted access on you login/error pages... Øyvind -Opprinnelig melding- Fra: Frank Zammetti [mailto:[EMAIL PROTECTED] Sendt: 15. juni 2005 17:37 Til: tomcat-user@jakarta.apache.org Emne: RE: Help/Examples setting up security settings2 Although I don't think this is the source of your problem, it strikes me as odd to be protecting the root of your webapp when this is where the unprotected page are as well (i.e., login.jsp, login_error.html) I would suggest leaving those two in the root of the webapp, and move environment.jsp and error.jsp to a subdirectory, maybe /Simple_JSP/content or something, then of course update the security constraint to constrain that new directory. Actually, one other thing... the references to the login form and the login error page in the login-config element I believe are relative to the webapp root, so drop the Simple_JSP from the beginning of them so they are /login.jsp and /login_error.jsp respectively. Again, not sure this is the problem, but it could be. Some other things, and this is where hopefully some Tomcat folks more knowledgable than me can help... There seems to be a realm-name element for login-config as well, but I have never used it... does it apply here? I think it may be for basic auth, but I am unsure. Also, there are perhaps some other things you need to do to tell Tomcat to use security... anyone else, does Joseph need to do anything to set up the UserDatabase resource, or is that set up by default? Also, does he need to create a context for his app and perhaps set something to tell Tomcat to use security? This is stuff I am not familiar with, so hopefully someone else reading this can help. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, June 15, 2005 9:31 am, Gagnon, Joseph M \(US SSA\) said: Ah-ha! Everything I had read so far led me to think I needed to put everything under ROOT. I'm glad you guys pointed that out. It makes sense. In the meantime, to make things simpler, I set up another webapp without any of the SPID stuff I was talking about before. It's very simple and contains nothing more than a login page (login.jsp) and login error page (login_error.html), the environment page (environment.jsp) I mentioned before and an error page (error.jsp), specified in the errorPage attribute of the page directive of the JSP files. The new app. sits in [tomcat]\webapps\Simple_JSP (not under ROOT any more) and the web.xml file in the WEB-INF subdirectory has been set up to use the correct path. I also included the security-role element Frank mentioned below. The web-app portion of web.xml looks like this: web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-nameSimple JSP/display-name descriptionSimple JSP Test/description login-config auth-methodFORM/auth-method form-login-config form-login-page/Simple_JSP/login.jsp/form-login-page form-error-page/Simple_JSP/login_error.html/form-error-page /form-login-config /login-config security-role descriptionSecurity Role/description role-namesimple_jsp/role-name /security-role security-constraint web-resource-collection web-resource-nameSimple JSP Test/web-resource-name url-pattern/Simple_JSP/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namesimple_jsp/role-name /auth-constraint /security-constraint /web-app Of course, I set up the simple_jsp role in the tomcat-users.xml file and added that role to my user entry. Now that this is all said and done, I'm still getting behavior that I'm not expecting. If I load my environment file into the browser (http://localhost/Simple_JSP/environment.jsp), it comes up as though there were no security/authentication mechanism to put up a roadblock. The login page is never presented. I was expecting that if I were to request any page from the Simple_JSP area, that before anything is displayed, I would be prompted to provide and user name and password. Isn't that what's supposed to happen? Thanks, Joe -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14,
RE: Help/Examples setting up security settings2
The /Simple_JSP part of the URL should be left out. Always start typing from the web-app folder. (because, who knows when you want to rename the webapp?) If you remove the /Simple_JSP part of the URLs in the web.xml, I think it will work, additionally, you should try not setting restricted access on you login/error pages... Øyvind -Opprinnelig melding- Fra: Frank Zammetti [mailto:[EMAIL PROTECTED] Sendt: 15. juni 2005 17:37 Til: tomcat-user@jakarta.apache.org Emne: RE: Help/Examples setting up security settings2 Although I don't think this is the source of your problem, it strikes me as odd to be protecting the root of your webapp when this is where the unprotected page are as well (i.e., login.jsp, login_error.html) I would suggest leaving those two in the root of the webapp, and move environment.jsp and error.jsp to a subdirectory, maybe /Simple_JSP/content or something, then of course update the security constraint to constrain that new directory. Actually, one other thing... the references to the login form and the login error page in the login-config element I believe are relative to the webapp root, so drop the Simple_JSP from the beginning of them so they are /login.jsp and /login_error.jsp respectively. Again, not sure this is the problem, but it could be. Some other things, and this is where hopefully some Tomcat folks more knowledgable than me can help... There seems to be a realm-name element for login-config as well, but I have never used it... does it apply here? I think it may be for basic auth, but I am unsure. Also, there are perhaps some other things you need to do to tell Tomcat to use security... anyone else, does Joseph need to do anything to set up the UserDatabase resource, or is that set up by default? Also, does he need to create a context for his app and perhaps set something to tell Tomcat to use security? This is stuff I am not familiar with, so hopefully someone else reading this can help. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, June 15, 2005 9:31 am, Gagnon, Joseph M \(US SSA\) said: Ah-ha! Everything I had read so far led me to think I needed to put everything under ROOT. I'm glad you guys pointed that out. It makes sense. In the meantime, to make things simpler, I set up another webapp without any of the SPID stuff I was talking about before. It's very simple and contains nothing more than a login page (login.jsp) and login error page (login_error.html), the environment page (environment.jsp) I mentioned before and an error page (error.jsp), specified in the errorPage attribute of the page directive of the JSP files. The new app. sits in [tomcat]\webapps\Simple_JSP (not under ROOT any more) and the web.xml file in the WEB-INF subdirectory has been set up to use the correct path. I also included the security-role element Frank mentioned below. The web-app portion of web.xml looks like this: web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-nameSimple JSP/display-name descriptionSimple JSP Test/description login-config auth-methodFORM/auth-method form-login-config form-login-page/Simple_JSP/login.jsp/form-login-page form-error-page/Simple_JSP/login_error.html/form-error-page /form-login-config /login-config security-role descriptionSecurity Role/description role-namesimple_jsp/role-name /security-role security-constraint web-resource-collection web-resource-nameSimple JSP Test/web-resource-name url-pattern/Simple_JSP/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namesimple_jsp/role-name /auth-constraint /security-constraint /web-app Of course, I set up the simple_jsp role in the tomcat-users.xml file and added that role to my user entry. Now that this is all said and done, I'm still getting behavior that I'm not expecting. If I load my environment file into the browser (http://localhost/Simple_JSP/environment.jsp), it comes up as though there were no security/authentication mechanism to put up a roadblock. The login page is never presented. I was expecting that if I were to request any page from the Simple_JSP area, that before anything is displayed, I would be prompted to provide and user name and password. Isn't that what's supposed to happen? Thanks, Joe -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14,
