RE: Upgrading Tomcat from 6.0.14 to 6.0.18 - classpath issue
1) Running with -verbose:class, this is what I get (C:/Work/ExpandView/apache-tomcat-6.0.18 is the tomcat home): Loaded javax.servlet.http.HttpServlet from file:/C:/Work/ExpandView/apache-tomcat-6.0.18/lib/servlet-api.jar 2) This is the content of MyWebApp.xml: WEB-INF/web.xml 3) My webapp is located at \webapps\MyWebApp. 4) These are the files under WEB-INF/lib: activation.jar activemq-all-5.2-SNAPSHOT.jar batik-awt-util.jar batik-dom.jar batik-svggen.jar batik-util.jar batik-xml.jar cewolf.jar commons-beanutils.jar commons-codec-1.3.jar commons-collections-3.1.jar commons-digester.jar commons-fileupload.jar commons-httpclient-3.0-rc3.jar commons-io-1.3.jar commons-lang-2.0.jar commons-logging-1.1.jar commons-pool-1.2.jar commons-validator.jar dialogs-rt.jar displaytag-1.0.jar itext-1.3.jar jakarta-oro.jar jaxp.jar jcommon-0.9.5.jar jdbc2_0-stdext.jar jfreechart-0.9.20.jar jmxtools.jar jsr173_1.0_api.jar jsse.jar jta-1.1.jar org.mortbay.jetty-4.2.17.jar struts.jar strutstest-2.1.3.jar taglibs-datetime.jar tar.jar -- View this message in context: http://www.nabble.com/Upgrading-Tomcat-from-6.0.14-to-6.0.18---classpath-issue-tp21541405p21577511.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
- Original Message From: Michael Ludwig To: Tomcat Users List Sent: Tuesday, January 20, 2009 4:55:16 PM Subject: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) A primitive web app sketch involving Java extensions to a native library (JNI) used up front in a ServletContextListener works when started via bin\startup.bat but doesn't work when installed as a Windows service and started via bin\tomcat6w.exe in the case of 6.0.18 or bin\tomcat5w.exe in the case of 5.5.27, on Windows XP. Hi Michael, I don't know if this is relevant to your problem or not and you didn't mention whether you're x64 or x86 of XP version. I had problem of tomcat startup as service before on x64 (xp or Win03). You need to replace the tomcat*.exe w/ the 64bit version. The included *.exe are 32 bit. Here's where you can get 64bit for tomcat5: http://svn.apache.org/viewvc/tomcat/connectors/trunk/procrun/bin/amd64/ and this is for tomcat6: http://svn.apache.org/viewvc/tomcat/trunk/res/procrun/amd64/ Regards, Tommy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Random Connection Closed Exceptions - Question to the code example
> From: Stefan Riegel [mailto:stefan.rie...@telig.de] > Subject: Re: Random Connection Closed Exceptions - Question > to the code example > > So both code examples are correct, but the one in the > docs minimizes resource usage? Yes - but really only if there is additional processing necessary after the ResultSet has been processed. If you don't have anything else to do after going through the ResultSet, then I would do the close() calls only in the finally block (but I'd certainly put some comments in the try block saying why it's done that way). - 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
Re: Random Connection Closed Exceptions - Question to the code example
Thanks for the explanation. This makes things clearer. So both code
examples are correct, but the one in the docs minimizes resource usage?
All db related code I have written so far looked like this:
try {
// db related code with result set loops and more
// db related code done, first possibility to release db objects
} catch {
// error handling
} finally {
// close and release objects
}
// possibly a lot of other code
So I never felt any needs for releasing the resources already in the try
block. But in any case it was important to learn about the possible
impacts when closing the connection improperly in the try _and_ the
finally block.
Thank You
Stefan
Caldarale, Charles R schrieb:
Which solution are you referring to? If it's the one in the Tomcat docs, that
so far still seems the simplest and most obvious to me. What's not shown in
the example is any additional processing that might be done after going through
the result set; if that processing is extensive, it's good to close the various
DB-related objects as early as possible to make the connection available to
other requests. Likewise, nulling out variables allows GC to reclaim the
object space as early as possible. This should be standard practice in any
server-related programming: minimize resource usage. (This is also why you
should close a ResultSet as early as possible, rather than waiting for some
later action to do so indirectly.)
- Request 1 running in Thread 1 gets a db connection.
- Request 1 closes the db connection.
- The JVM switches the running thread to Thread 2
- Request 2 running in Thread 2 gets a db connection (the same db
connection just closed by Request 1).
- The JVM switches the running thread back to Thread 1
- Request 1 closes the db connection a second time in a finally block.
- The JVM switches the running thread back to Thread 2
- Request 2 Thread 2 tries to use the db connection but fails because
Request 1 closed it.
Looks like the above was written in the bad old days of what was called "green threads",
where all Java threads were actually run by a single native thread. The "green threads"
concept thankfully went the way of the dodo quite a few years ago, and there is now a one-to-one
mapping of Java threads to native threads. The above should be adjusted accordingly, but that
would only change the wording, not the intent of the description.
So I'm still confused about the docs.
I'm confused about you being confused; why do you think the example in the
Tomcat docs is overly complicated?
- 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: problem regarding installation of APR -- make command shows fatal error ..
hey, its solaris 10 sparc on a m5000 box.. any suggestions .. thanks and regards, P. Swami Vivekananda =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Monitor Tomcat
Hello, I am deploying my web application on Tomcat. How do I monitor the tomcat performance? 1. If I am using GNU/Linux environment 2. If I am using Windows XP environment What F/OSS package/software I should install? -- Zaki Akhmad - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Random Connection Closed Exceptions - Question to the code example
> From: Stefan Riegel [mailto:stefan.rie...@telig.de] > Subject: Re: Random Connection Closed Exceptions - Question > to the code example > > Yes, I find the solution somewhat ugly and not very intuitive. Which solution are you referring to? If it's the one in the Tomcat docs, that so far still seems the simplest and most obvious to me. What's not shown in the example is any additional processing that might be done after going through the result set; if that processing is extensive, it's good to close the various DB-related objects as early as possible to make the connection available to other requests. Likewise, nulling out variables allows GC to reclaim the object space as early as possible. This should be standard practice in any server-related programming: minimize resource usage. (This is also why you should close a ResultSet as early as possible, rather than waiting for some later action to do so indirectly.) > - Request 1 running in Thread 1 gets a db connection. > - Request 1 closes the db connection. > - The JVM switches the running thread to Thread 2 > - Request 2 running in Thread 2 gets a db connection (the same db > connection just closed by Request 1). > - The JVM switches the running thread back to Thread 1 > - Request 1 closes the db connection a second time in a finally block. > - The JVM switches the running thread back to Thread 2 > - Request 2 Thread 2 tries to use the db connection but fails because > Request 1 closed it. Looks like the above was written in the bad old days of what was called "green threads", where all Java threads were actually run by a single native thread. The "green threads" concept thankfully went the way of the dodo quite a few years ago, and there is now a one-to-one mapping of Java threads to native threads. The above should be adjusted accordingly, but that would only change the wording, not the intent of the description. > So I'm still confused about the docs. I'm confused about you being confused; why do you think the example in the Tomcat docs is overly complicated? - 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
Re: Random Connection Closed Exceptions - Question to the code example
Hello Flavio,
thank You for your answer but isn't Your code the same as my code below?
I don't see any significant difference.
Regards
Stefan
Flavio Crispim schrieb:
Hi Stefan
I would try this one:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
try {
conn = ... get connection from connection pool ...
stmt = conn.createStatement("select ...");
ResultSet rs = stmt.executeQuery();
... iterate through the result set ...
} catch (SQLException e) {
... deal with errors ...
} finally {
// Always make sure result sets and statements are closed,
// and the connection is returned to the pool
if (stmt != null) {
try { stmt.close(); } catch (SQLException e) { ; }
}
if (conn != null) {
try { conn.close(); } catch (SQLException e) { ; }
}
}
We don´t need to null conn and stmt variables because the sanity check on
finally block.
The resultset will only exist if and only if you already have a statement,
and "A ResultSet object is automatically closed when the Statement object
that generated it is closed, re-executed, or used to retrieve the next
result from a sequence of multiple results. ", thats why it is in a more
restrictive scope w/out close()
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.html
On the race condition:
javadoc on Connection.close() states "Calling the method close on a
Connection object that is already closed is a no-op. ",
see: http://java.sun.com/javase/6/docs/api/java/sql/Connection.html#close()
This race condition should be threated as connection pool´s bug, IMHO.
Flavio Crispim
PS: English isn´t my mother language...
Alan Chaney gravou em 19/01/2009 21:24:43:
Hi Stefan
I went and read the comments more carefully and it seems to me that the
proposed solution is an attempt to avoid a race condition between
issuing the 'close' in
one thread and then it being closed again whilst its being used in
another thread.
If the problem is closing it twice then I can't see why its not just
closed in the 'finally' block, once for each thread.
If it is a concurrency problem then I suspect that the proposed solution
in the docs isn't the right one anyway. I'd suspect that the problem is
more to do with threads not seeing each others memory state properly.
Isn't this is a case of a variable (in this case 'conn') actually being
a reference to an object which is shared between threads?
Because of the JVM memory model it is possible for two threads not to be
properly synchronized - see Doug Lea et.al and 'happens before' .
Personally, I feel that the correct solution is to synchronize access
to the connection object when it is retrieved and closed.
I have to go out now and I don't have any more time to consider this
today, but I'd be interested to hear other people's comments on this
topic.
Regards
Alan Chaney
Stefan Riegel wrote:
Thanks Alan, just to make the thing really clear. You propose code
like this:
public void execute() {
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
Context envContext = null;
try {
Context initContext = new InitialContext();
envContext = (Context)
initContext.lookup("java:/comp/env");
DataSource ds = (DataSource)
envContext.lookup("jdbc/swex");
conn = ds.getConnection();
stmt = conn.createStatement();
rs = stmt.executeQuery("some sql");
// iterate through the result set ...
} catch (SQLException e) {
e.printStackTrace();
} catch (NamingException e) {
e.printStackTrace();
} finally {
if (rs != null) {
try {
rs.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
if (stmt != null) {
try {
stmt.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
if (envContext != null) {
try {
envContext.close();
} catch (NamingException e) {
e.printStackTrace();
}
}
}
For me this looks fine but I'm still confused, why they complicated
things in the example of "properly written code"
http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html?
Hmm... frankly the code in the docs you refer to above seems odd to
me... why repeat in the 'finally' something you
Re: Random Connection Closed Exceptions - Question to the code example
Hello Alan,
unfortunately I'm not very experienced in "thread programming". But as I
understand does the proposed solution in the docs avoid the problem of
closing the connection object of the second thread. Yes, I find the
solution somewhat ugly and not very intuitive.
But the code below should also work. So it looks easier for me. This
sequence...
- Request 1 running in Thread 1 gets a db connection.
- Request 1 closes the db connection.
- The JVM switches the running thread to Thread 2
- Request 2 running in Thread 2 gets a db connection (the same db
connection just closed by Request 1).
- The JVM switches the running thread back to Thread 1
- Request 1 closes the db connection a second time in a finally block.
- The JVM switches the running thread back to Thread 2
- Request 2 Thread 2 tries to use the db connection but fails because
Request 1 closed it.
... cannot happen any more, because the connection gets closed exactly
once (only if it is opened before).
So I'm still confused about the docs. They exist for a long time and I
cannot believe, that no one before me wondered about it. So I guess I'm
missing something. But what?
Alan Chaney schrieb:
Hi Stefan
I went and read the comments more carefully and it seems to me that the
proposed solution is an attempt to avoid a race condition between
issuing the 'close' in
one thread and then it being closed again whilst its being used in
another thread.
If the problem is closing it twice then I can't see why its not just
closed in the 'finally' block, once for each thread.
If it is a concurrency problem then I suspect that the proposed solution
in the docs isn't the right one anyway. I'd suspect that the problem is
more to do with threads not seeing each others memory state properly.
Isn't this is a case of a variable (in this case 'conn') actually being
a reference to an object which is shared between threads?
Because of the JVM memory model it is possible for two threads not to be
properly synchronized - see Doug Lea et.al and 'happens before' .
Personally, I feel that the correct solution is to synchronize access
to the connection object when it is retrieved and closed.
I have to go out now and I don't have any more time to consider this
today, but I'd be interested to hear other people's comments on this topic.
Regards
Alan Chaney
Stefan Riegel wrote:
Thanks Alan, just to make the thing really clear. You propose code
like this:
public void execute() {
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
Context envContext = null;
try {
Context initContext = new InitialContext();
envContext = (Context) initContext.lookup("java:/comp/env");
DataSource ds = (DataSource) envContext.lookup("jdbc/swex");
conn = ds.getConnection();
stmt = conn.createStatement();
rs = stmt.executeQuery("some sql");
// iterate through the result set ...
} catch (SQLException e) {
e.printStackTrace();
} catch (NamingException e) {
e.printStackTrace();
} finally {
if (rs != null) {
try {
rs.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
if (stmt != null) {
try {
stmt.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
if (envContext != null) {
try {
envContext.close();
} catch (NamingException e) {
e.printStackTrace();
}
}
}
For me this looks fine but I'm still confused, why they complicated
things in the example of "properly written code"
http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html?
Hmm... frankly the code in the docs you refer to above seems odd to
me... why repeat in the 'finally' something you've done in the 'try'?
I can see that setting the variables to null would ensure that all
references were released and the objects were made candidates for garbage
collection but that could be done in the finally block anyway at some
convenient point.
Obviously in your code you might not want to obtain and release the
context for every JDBC operation - that would probably be done in some
kind of start-up/shutdown code for your app, and of course your
exception handling may need some more work depending upon the way you
want to present the error
to your users, but I assumed that the issue you are concerned with is
preventing resource leaks.
RE: Upgrading Tomcat from 6.0.14 to 6.0.18 - classpath issue
> From: matyg [mailto:ma...@expand.com] > Subject: Re: Upgrading Tomcat from 6.0.14 to 6.0.18 - classpath issue > > 1) (and as far as I know...) the > javax/servlet/http/HttpServlet class is > located in servlet-api.jar, which located under under > /lib. Make sure that's the *only* place servlet-api.jar is located. You can get that message if the same class exists in multiple locations in a given branch of the classloader tree. Turn on -verbose:class when running Tomcat to see where classes are being loaded from. > 2) The file MyWebApp.xml is located at: > \conf\Catalina\localhost\MyWebApp.xml That's good; what's in it? Also, where is your webapp located? What's in its WEB-INF/lib directory. - 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
RE: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
> From: Michael Ludwig [mailto:mil...@gmx.de] > Subject: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) > > The directory containing these libraries *is* included in PATH. Environment variables are not used by services, so it doesn't really matter what's in PATH. > Likewise, it is included as follows on the Java tab of tomcat5w.exe: > -Djava.library.path=C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug Good; that's where it needs to be. Does the account the Tomcat service runs under have access to the directory of interest? Try setting -verbose:jni in the Java tab of tomcat?w.exe and see if anything interesting is displayed. > And indeed, this works using bin\startup.cmd. We'll presume you meant bin\startup.bat. - 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
UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
A primitive web app sketch involving Java extensions to a native library (JNI) used up front in a ServletContextListener works when started via bin\startup.bat but doesn't work when installed as a Windows service and started via bin\tomcat6w.exe in the case of 6.0.18 or bin\tomcat5w.exe in the case of 5.5.27, on Windows XP. Here's the libraries I need: :: dir /s /b *.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\libdb46d.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\libdbxml24d.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\libdbxml_java24d.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\libdb_java46d.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\xerces-c_2_8D.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\xqilla21d.dll The directory containing these libraries *is* included in PATH. Likewise, it is included as follows on the Java tab of tomcat5w.exe: -Djava.library.path=C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug The error thrown when starting Tomcat 5 or 6 as the service with the app in question is the following: java.lang.UnsatisfiedLinkError: no libdb_java46 in java.library.path I'm checking I *really* have the bin\debug directory in the path by doing the following: System.out.println( System.getProperty( "java.library.path")); ... env = new Environment( envHome, envConf); // triggers the error And I do get the relevant directory in the output. Now there is one subtlety, that you may or may not have noticed: The library I have in my directory is libdb_java46d.dll (note the "d" for "debug version" after the version number), the library name in the error message, however, is "libdb_java46" (the "d" is missing). This had me confused and sent on the wrong tracks at first. But I'm assured by the developers that: The Java API for DB XML begins by first trying to load the release versions of the libraries, and failing that then tries to load the debug versions. If it fails to find both versions then the UnsatisfiedLinkError is thrown listing the release library, even though it did look for the debug library. Java-API in Tomcat 6: libdb_java46.dll UnsatisfiedLinkError (2.4.16+p1) http://forums.oracle.com/forums/thread.jspa?threadID=848389 And indeed, this works using bin\startup.cmd. I tried to run the service using various JVMs, but that didn't dispel the error. What could make the script version succeed and the service version fail with both Tomcat 5.5 and 6? What could I do to find the error? Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: enable-access-log-in-tomcat
2009/1/20 Kaushal Shriyan : > > I am using tomcat-5.5.26, sun-jdk-1.5.0.15 on gentoo linux, I have enabled > the below in server.xml > > directory="logs" prefix="localhost_access_log." > suffix=".txt" > pattern="%h %l %u %t %r %s %b %D %T" resolveHosts="false"/> > > The issue is that i don't see time parameter value in the > /var/log/tomcat-5.5/localhost_access_log.2009-01-20.txt file > Below is the snippet of the local access log > > 172.20.2.111 - - [20/Jan/2009:04:08:40 -0800] "GET > /Trunk/login?sessionExpired=true HTTP/1.1" 200 40005 > > Any clue > In TC 5.5 the only allowed values for the pattern attribute of FastCommonAccessLogValve are "common", "combined" or their exact expansions. You cannot use an arbitrary pattern. Use AccessLogValve class for that. Note, as I see AccessLogValve in 5.5 has optimized support for "common" and "combined" patterns, thus maybe the gain from using the FastCommon* one is not that much. In TC 6.0 both fast and arbitrary patterns are implemented by AccessLogValve class and FastCommonAccessLogValve class is deprecated. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
encodeRedirectURL URL rewrite not working
Hello,
I have two web applications in different context, one servlet will forward
the request to a servlet in the other application using encodeRedirectURL
and sendRedirect. The receiving servlet creates a new session and session
attributes are lost.
Running Tomcat 5.5.17.
Here is the flow:
GET /App1/RedirectServlet HTTP/1.1
Cookie: JSESSIONID=7AFACD0318419C34938B6410BB9A1937
RedirectServlet
response.sendRedirect(response.encodeRedirectURL("/App2/LaunchServlet"));
HTTP/1.x 302 Moved Temporarily
GET /App2/LaunchServlet HTTP/1.1
(no cookie)
HTTP/1.x 200 OK
Set-Cookie: JSESSIONID=BE408BFD3480E29DF2A4278BCA3C1FC6; Path=/App2
The same behavior occurs in Firefox and IE. Cookies are enabled in both
browsers and crossContext="true" in context.xml. Is this a bug in Tomcat or
a problem with my method of redirect?
Thanks,
Greg
enable-access-log-in-tomcat
Hi I am using tomcat-5.5.26, sun-jdk-1.5.0.15 on gentoo linux, I have enabled the below in server.xml The issue is that i don't see time parameter value in the /var/log/tomcat-5.5/localhost_access_log.2009-01-20.txt file Below is the snippet of the local access log 172.20.2.111 - - [20/Jan/2009:04:08:40 -0800] "GET /Trunk/login?sessionExpired=true HTTP/1.1" 200 40005 Any clue Thanks and Regards Kaushal
Re: root context path - war file not unwar'd
Thanks charles, i thought there was an easier way to make a default webapp other than naming it ROOT.war. I will give that a shot to see if it works. Adam On Mon, Jan 19, 2009 at 10:36 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: AD [mailto:straightfl...@gmail.com] > > Subject: root context path - war file not unwar'd > > > > I have an issue where inside a i set the context path > > of "/" to a directory inside webapps (myapp). > > This is bad practice, and gets your webapp deployed twice. Sounds like you > also didn't remove the existing webapps/ROOT directory, so you now have two > webapps fighting to be the default one. Since you're not doing things in > the recommended fashion, no particular behavior is guaranteed. > > What you should be doing: > > 1) Delete the existing webapps/ROOT directory, thereby removing the dummy > default webapp that ships with Tomcat. > > 2) Delete everything under Tomcat's work directory, since that likely is > very confused by now. > > 3) Remove the element from server.xml - it doesn't belong there. > > 4) Rename your webapp to ROOT.war, so it becomes the default webapp. > > 5) If you actually need a element for your webapp, place it in > META-INF/context.xml inside the ROOT.war file, or in > conf/Catalina/[host]/ROOT.xml; in either case, remove the path and docBase > attributes, since they're not allowed. (If your element contained > only path and docBase, you don't need one at all.) > > When redeploying a webapp, don't just randomly delete directories while > Tomcat is running. Use the manager webapp or the appropriate ant script to > do a proper redeployment. > > - 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 > >
Re: PostgreSQL vs MySQL with Tomcat
Wow, this almost reads like a direct quote from MySQL marketing literature. Like marketing literature, it's not necessarily untruthful, but it does describe things selectively. Terence M. Bandoian wrote: I don't have a great deal of experience with Postgres but I have been using MySQL since the days of mSQL and have found it to be fast, reliable, easy to install on both Linux and Windows and straightforward to administer. Anecdotal, but no more so than anyone else's opinion. However, the actual behaviour of MySQL and benchmarks contradict you. It's only fast for queries using the MyISAM table type, and then only with few if any joins. MyISAM means no foreign key constraints (the syntax supports them, but they're ignored) and therefore no referential integrity. It's unreliable - indexes aren't recreated when a column type is changed (such as increasing the range of an integral type), whereas most other database engines recreate them automatically. It may be easy to install the binaries, but administering access and being sure you've locked it down is hard. It provides good support for the ANSI standard and the No it doesn't. By default ANSI SQL support is poor, and many gotchas exist (try Googling for "MySQL Gotchas"). documentation is good in identifying extensions to or deviations from The documentation is poorly organised, incomplete (try finding descriptions of all the InnoDB tuning parameters), and often misleading when describing features MySQL lacks. Note how dismissive the documentation on foreign key constraints and referential integrity was - saying it should be handled in application code - until MySQL added support for it ... the standard. All of the basic tools, from query analysis to command line administration programs, are documented and function reliably. Statement syntax is very well documented. Features include localization, various character sets (UTF-8 and Unicode), data encryption, client/server encryption, stored procedures, triggers, transactions, APIs for a number of programming languages and support for ODBC, JDBC and .NET. Localisation - full text indexes rely on a single stop list (with a slightly dubious one for English compiled in) so you can only support one language at a time without running into difficulty. Transactions - only for the InnoDB table type, rolling back from a transaction that has touched non-InnoDB tables will result in a warning, and screwed data. Configurability is provided mainly through some 250+ system variables which may be set at startup (on the command line or in the options file) or dynamically with the SET statement. I have been very pleased with its performance both administratively and as a programmer and you can't beat the price. Only some of those parameters can be changed dynamically, and not all of them are documented. For instance, changing the minimum length of words that are indexed in a full text index requires a restart. As mentioned above, the documentation on tuning is incomplete and unhelpful, little more than a couple of example mysql.conf files that contradict each other and have few if any comments to describe what each parameter does. -Terence M. Bandoian MySQL encourages bad habits, and commonly adds to the bugginess of PHP applications where MySQL is the de-facto standard for persistence. I'd strongly recommend you try another database engine such as PostgreSQL or Firebird, and compare MySQL for performace, scalability and standards conformance. Chris -- Chris Wareham Senior Software Engineer Visit London Ltd 6th floor, 2 More London Riverside, London SE1 2RR Tel: +44 (0)20 7234 5848 Fax: +44 (0)20 7234 5753 www.visitlondon.com 'Visit London Limited' is registered in England under No.761149; Registered Office: Visit London, 2 More London Riverside, London SE1 2RR. Visit London is the official visitor organisation for London. Visit London is partly funded by Partnership, the Mayor's London Development Agency and London Councils. The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you have received it in error, please notify the sender immediately and then delete the message. If you are not the intended recipient, you must not use, disclose, copy or distribute this email. The views expressed in this e-mail are those of the individual and not of Visit London. We reserve the right to read and monitor any email or attachment entering or leaving our systems without prior notice. Please don't print this e-mail unless you really need to. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Servlet silently dropped
We could diagnose this situation better if you could display/attach the most recent log from $TOMCAT_HOME/log 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. > From: chuck.caldar...@unisys.com > To: users@tomcat.apache.org > Date: Tue, 20 Jan 2009 08:17:27 -0600 > Subject: RE: Servlet silently dropped > > > From: D. Barnhoorn [mailto:d.barnho...@tfe.nl] > > Subject: RE: Servlet silently dropped > > > > Main servlet grabs /** > > I don't think "/**" is a valid mapping, if I'm interpreting the servlet spec > properly. You should be using just "/" for your default (main) servlet. > > > A hanging servlet would mean timeouts for the client I think? > > Yes, a timeout; there wouldn't be a 500, since it's the request processing > thread's responsibility to generate the response. The 500 is sent by Tomcat > typically only if the thread hits an uncaught exception. > > - 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 > _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009
Re: problem regarding installation of APR -- make command shows fatal error ..
Sun Sparc with Solaris 10 - Pswami postet the problem already few hrs ago: http://www.nabble.com/Problem-in-APR-installation.-td21557473.html Howver, got no clue about Solaris. Cheers 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: problem regarding installation of APR -- make command shows fatal error ..
> From: Pswami Vivekananda [mailto:pswami.vivekana...@tcs.com] > i am trying to install tomcat-native-1.1.13 on my apache-tomcat-6.0.16 > server. What OS? > ld: fatal: relocations remain against allocatable but > non-writable sections > collect2: ld returned 1 exit status Nice error! It's going to be a little difficult to debug without knowing a more about your environment. - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Servlet silently dropped
> From: D. Barnhoorn [mailto:d.barnho...@tfe.nl] > Subject: RE: Servlet silently dropped > > Main servlet grabs /** I don't think "/**" is a valid mapping, if I'm interpreting the servlet spec properly. You should be using just "/" for your default (main) servlet. > A hanging servlet would mean timeouts for the client I think? Yes, a timeout; there wouldn't be a 500, since it's the request processing thread's responsibility to generate the response. The 500 is sent by Tomcat typically only if the thread hits an uncaught exception. - 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
problem regarding installation of APR -- make command shows fatal error ..
hey everybody, i am trying to install tomcat-native-1.1.13 on my apache-tomcat-6.0.16 server. the configure file seemed to work alright. but when i started make i got the following error #./configure --with-apr=/usr/local/apr --with-java-home=/usr/jdk/jdk1.5.0_14 it worked fine #make ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libtcnative-1.la' Current working directory /apps/apache-tomcat-6.0.16/bin/tomcat-native-1.1.13-src/jni/native *** Error code 1 The following command caused the error: otarget=`echo all-recursive | sed s/-recursive//`; \ list='src os/unix '; \ for i in $list; do \ if test -f "$i/Makefile"; then \ target="$otarget"; \ echo "Making $target in $i"; \ if test "$i" = "."; then \ made_local=yes; \ target="local-$target"; \ fi; \ (cd $i && make $target) || exit 1; \ fi; \ done; \ if test "$otarget" = "all" && test -z "libtcnative-1.la"; then \ made_local=yes; \ fi; \ if test "$made_local" != "yes"; then \ make "local-$otarget" || exit 1; \ fi make: Fatal error: Command failed for target `all-recursive' any kind of help is appreciated. thanks and regards, P.Swami Vivekananda =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Random Connection Closed Exceptions - Question to the code example
Hi Stefan
I would try this one:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
try {
conn = ... get connection from connection pool ...
stmt = conn.createStatement("select ...");
ResultSet rs = stmt.executeQuery();
... iterate through the result set ...
} catch (SQLException e) {
... deal with errors ...
} finally {
// Always make sure result sets and statements are closed,
// and the connection is returned to the pool
if (stmt != null) {
try { stmt.close(); } catch (SQLException e) { ; }
}
if (conn != null) {
try { conn.close(); } catch (SQLException e) { ; }
}
}
We don´t need to null conn and stmt variables because the sanity check on
finally block.
The resultset will only exist if and only if you already have a statement,
and "A ResultSet object is automatically closed when the Statement object
that generated it is closed, re-executed, or used to retrieve the next
result from a sequence of multiple results. ", thats why it is in a more
restrictive scope w/out close()
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.html
On the race condition:
javadoc on Connection.close() states "Calling the method close on a
Connection object that is already closed is a no-op. ",
see: http://java.sun.com/javase/6/docs/api/java/sql/Connection.html#close()
This race condition should be threated as connection pool´s bug, IMHO.
Flavio Crispim
PS: English isn´t my mother language...
Alan Chaney gravou em 19/01/2009 21:24:43:
> Hi Stefan
>
> I went and read the comments more carefully and it seems to me that the
> proposed solution is an attempt to avoid a race condition between
> issuing the 'close' in
> one thread and then it being closed again whilst its being used in
> another thread.
>
> If the problem is closing it twice then I can't see why its not just
> closed in the 'finally' block, once for each thread.
>
> If it is a concurrency problem then I suspect that the proposed solution
> in the docs isn't the right one anyway. I'd suspect that the problem is
> more to do with threads not seeing each others memory state properly.
> Isn't this is a case of a variable (in this case 'conn') actually being
> a reference to an object which is shared between threads?
> Because of the JVM memory model it is possible for two threads not to be
> properly synchronized - see Doug Lea et.al and 'happens before' .
> Personally, I feel that the correct solution is to synchronize access
> to the connection object when it is retrieved and closed.
>
> I have to go out now and I don't have any more time to consider this
> today, but I'd be interested to hear other people's comments on this
topic.
>
> Regards
>
> Alan Chaney
>
>
> Stefan Riegel wrote:
> > Thanks Alan, just to make the thing really clear. You propose code
> > like this:
> >
> > public void execute() {
> > Connection conn = null;
> > Statement stmt = null;
> > ResultSet rs = null;
> > Context envContext = null;
> > try {
> > Context initContext = new InitialContext();
> > envContext = (Context)
initContext.lookup("java:/comp/env");
> > DataSource ds = (DataSource)
envContext.lookup("jdbc/swex");
> > conn = ds.getConnection();
> > stmt = conn.createStatement();
> > rs = stmt.executeQuery("some sql");
> > // iterate through the result set ...
> > } catch (SQLException e) {
> > e.printStackTrace();
> > } catch (NamingException e) {
> > e.printStackTrace();
> > } finally {
> > if (rs != null) {
> > try {
> > rs.close();
> > } catch (SQLException e) {
> > e.printStackTrace();
> > }
> > }
> > if (stmt != null) {
> > try {
> > stmt.close();
> > } catch (SQLException e) {
> > e.printStackTrace();
> > }
> > }
> > if (conn != null) {
> > try {
> > conn.close();
> > } catch (SQLException e) {
> > e.printStackTrace();
> > }
> > }
> > if (envContext != null) {
> > try {
> > envContext.close();
> > } catch (NamingException e) {
> > e.printStackTrace();
> > }
> > }
> > }
> >
> >
> > For me this looks fine but I'm still confused, why they complicated
> > things in the example of "properly written code"
> >
http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html?
> >
> >
> Hmm... frankly the co
Re: networkaddress.cache.ttl and networkaddress.cache.negative.ttl
Hi, I use -Dsun.net.inetaddr.ttl=3600 and left the negative.ttl as default (10?). Our network runs its own caching dns server. Never had any trouble with it. Ronald. Op dinsdag, 20 januari 2009 om 10:46 uur schreef Tomcat Users List : Dear All, Do any of you guys tune networkaddress.cache.ttl or networkaddress.cache.negative.ttl? If so, what values do you use? -- Kees Jan http://www.kjkoster.org/ kjkos...@gmail.com 06-51838192 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Servlet silently dropped
Chuck, >> One of those servlets stops handling or maybe even >> getting requests that it has a mapping for. >What does a thread dump show in this situation? I will see if I can get access - the machine is more or less a black box for me I'm afraid, and on an internal network that I cannot access directly. Maybe I can setup something on a box inside the net that they can use. I will see what's possible, thanks for the suggestion >> What is odd is that: >> - it's always the same one >Which narrows your focus considerably. True >> - tomcat serves a page for the url, but one from the main servlet >So it appears the mapping is altered? The only dynamic mapping I'm aware of in Tomcat is for JSPs; >are you using them anywhere? The mapping for this one is very static, one very specific url. As are most of the others. Main servlet grabs /** and passes to a binary servlet for binaries. The only direct jsp's are for the 404 and 500 errors, all others get forwarded from one of the servlets. >> - destroy() doesn't get called, so it either escapes the gc >> or gets dropped without any fuss >The destroy() API won't be called unless the entire webapp is stopped, which doesn't appear to be >happening. True, clutching at straws there I think ;) >> - creating a second mapping for the servlet returns the same >> page >How do you do that? The only way I'm aware of is to update web.xml, which will reload the entire >webapp. I added a secondary mapping before starting, which will of course mean the same servlet gets called and not prove a lot. I will try to get some monitoring window to the server so I can grab some more info on the state of the servlet and the vm at the time it occurs. >Tomcat can't log anything when a thread hangs inside a servlet. Again, get a thread dump (or >several). A hanging servlet would mean timeouts for the client I think? Or error 500? danny -- View this message in context: http://www.nabble.com/Servlet-silently-dropped-tp21541015p21560958.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk and IPV_6
Dominik Pospisil wrote: Hello, are there any plans to incorporate fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=43968 ? Yes. Seems that the issue was not fixed in jk-1.2.27. Nope, but that's a good reason to go for 1.2.28 :) Regards -- ^(TM) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mod_jk and IPV_6
Hello, are there any plans to incorporate fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=43968 ? Seems that the issue was not fixed in jk-1.2.27. Thanks, Dominik - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
networkaddress.cache.ttl and networkaddress.cache.negative.ttl
Dear All, Do any of you guys tune networkaddress.cache.ttl or networkaddress.cache.negative.ttl? If so, what values do you use? -- Kees Jan http://www.kjkoster.org/ kjkos...@gmail.com 06-51838192 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
