How to configure JNDI resource
Hi all, I've a question about how to configure a datasource to be accessed via JNDI. I have a datasource configured in server.xml (In Server/GlobalNamingResources/Resource). In the documentation http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Resource_Definitions it says that that a resource/datasource can be declared in the context element of a webapp like this: Context ... ... Resource name=jdbc/EmployeeDB auth=Container type=javax.sql.DataSource description=Employees Database for HR Applications/ ... /Context Also it is written that it is possible to declare a resource inside web.xml: resource-ref descriptionEmployees Database for HR Applications/description res-ref-namejdbc/EmployeeDB/res-ref-name res-ref-typejavax.sql.DataSource/res-ref-type res-authContainer/res-auth /resource-ref My question is: 1) is it enough to declare the needed resource inside web.xml or 2) do I have to declare it also in the context element for accessing it via JNDI? And, if 2) is correct what is the use to declare a resouce in the webapps web.xml when it has been already declared in the context element of the webapp? Regards, Abid - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Question about context.xml
Hello, I'm sure this question has been posted in the past already, but when searching for Tomcat 6 context.xml (or similar) I didn't find anything which described my question. My question is about the several possibility to declare context elements for configuring JNDI resources in Tomcat 6 configuration. In Tomcat 6 documentation (http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#conte xt.xml%20configuration) there are described to ways to configure JNDI resources for a webapp: * in $CATALINA_BASE$/conf/server.xml * in META-INF/context.xml for each webapp AFAIK there is an additional possibilities two configure JNDI resources: * in $CATALINA_BASE$/conf/Catalina/localhost/name-of-web-app.xml Is that correct? And why is there a context.xml in $CATALINA_BASE/conf and what is it for? Would be happy if someone could help me out with this. Best regards, Abid - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Re: Ignore http header if-modified-since
Thanks a lot. I logged all header modifications using a filter and found the root cause. It is a class called AbstractResourceProcessor from the Apache Shale framework. When requesting a resource which is actually located inside a jar, it sets the last-modified header using java.text.SimpleDateFormat format = new SimpleDateFormat(EEE, dd MMM HH:mm:ss zzz); without specifying any locale. This naturally results in a date formatted according to the server's locale. So it seems I'll have to use a filter which converts the date back to the englisch locale format. Best regards, Abid -Ursprüngliche Nachricht- Von: Len Popp [mailto:len.p...@gmail.com] Gesendet: Freitag, 18. Dezember 2009 17:13 An: Tomcat Users List Betreff: Re: Ignore http header if-modified-since Add some debugging code to your app to find the point where the Last-Modified header is added. Call HttpServletResponse.containsHeader to see if the header has been set. -- Len On Fri, Dec 18, 2009 at 10:47, Abid Hussain abid.huss...@dilax.com wrote: OK, it seems that tomcat is working correctly. Still I would like to get the root cause of my problem which is again: The last-modified response header is delivered in the locale of the server. E.g. if this locale is polish or germen, the header is delivered in polish resp. german format which is not correct and causes misbehaviour. Naturally I just can set the locale to en_US to get the desired header format. But this is not the root cause of the problem. The question is: How can the format of this header can be set (or overridden) to the server's locale? I tried the following: * Asked Google: Nothing found. * Searched for occurences of last-modified in the source code of my application: Nothing found. * Looked if the methods HttpServletResponse.setHeader() or HttpServletResponse.addHeader() are used with the last-modified somewhere in my application: Nothing found. * Looked if one of the configured filters modify the header: Nothing found. * Looked if any valves are used: None. Anybody got an idea how I can investigate further? Regards, Abid -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Freitag, 18. Dezember 2009 13:56 An: Tomcat Users List Betreff: Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since Mark Thomas wrote: On 18/12/2009 09:36, André Warnier wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Abid, On 12/17/2009 12:08 PM, Abid Hussain wrote: I used the startup parameters -Duser.language=en -Duser.region=US This caused Tomcat to deliver the Last-Modified in the correct format. That solved the problem, no 404 anymore, thanks. So it seems to be a bug in tomcat...? I would say so. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1 Tomcat's behavior seems to ignore the specification, here. Would you care to share your Tomcat version with us? So far, I haven't seen anything that demonstrates Tomcat is generating this header. It looks like an app issue to me. My testing with trunk, 6.0.x and 6.0.20 all show the correct format being used. I think that once this is confirmed, it may be worth raising its visibility a bit for the Tomcat developers. As always before reporting an error, I'd highly recommend generating a simple as possible test case that demonstrates the issue on a clean Tomcat install. I can't repeat this and at the moment it looks like an application issue. Any bug report that can't be repeated is just going to get closed as WORKSFORME. For a confirmation of what Mark says above, I ran some tests. This Tomcat 5.5 is a pretty vanilla version, with just the standard example apps and not much more, on my Windows workstation. Versions are not the latest ones, I know. INFO: Starting Servlet Engine: Apache Tomcat/5.5.26 Platform : Windows XP, German Java : java version 1.6.0_06 Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing) Tomcat running as service, stopped and restarted before each test below A) Platform default Tomcat startup parameters as per tomcat5w.exe : -Dcatalina.home=C:\Tomcat5.5 -Dcatalina.base=C:\Tomcat5.5 -Djava.endorsed.dirs=C:\Tomcat5.5\common\endorsed -Djava.io.tmpdir=C:\Tomcat5.5\temp -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=C:\Tomcat5.5\conf\logging.properties (platform default) Request: (Request-Line) GET /RELEASE-NOTES.txt HTTP/1.1 Host localhost:8180 User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
AW: Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since
Hi,
I'm using Tomcat 6.0.20, installed on a german Windows XP.
I'm quite sure that the cause is tomcat's code. When I use e.g. for
startup polish locale:
-Duser.language=pl
-Duser.region=PL
Tomcat delivers the Last-Modified header in polish:
Pt, 18 gru 2009 08:33:49 GMT
The Date header is always in correct format, no matter what locale is
configured:
Fri, 18 Dec 2009 08:33:49 GMT
I tested this with Firebug.
Best regards,
Abid
-Ursprüngliche Nachricht-
Von: Christopher Schultz [mailto:ch...@christopherschultz.net]
Gesendet: Donnerstag, 17. Dezember 2009 22:18
An: Tomcat Users List
Betreff: Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Abid,
On 12/17/2009 12:08 PM, Abid Hussain wrote:
I used the startup parameters
-Duser.language=en
-Duser.region=US
This caused Tomcat to deliver the Last-Modified in the correct format.
That solved the problem, no 404 anymore, thanks.
So it seems to be a bug in tomcat...?
I would say so.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1
Tomcat's behavior seems to ignore the specification, here. Would you
care to share your Tomcat version with us?
Looking at the DefaultServlet, it looks like it ultimately uses
org.apache.naming.resources.ResourceAttributes.getLastModifiedHttp(),
which explicitly uses a US locale, though it doesn't specify en_US:
/**
* HTTP date format.
*/
protected static final SimpleDateFormat format =
new SimpleDateFormat(EEE, dd MMM HH:mm:ss zzz,
Locale.US);
...
/**
* @return Returns the lastModifiedHttp.
*/
public String getLastModifiedHttp() {
if (lastModifiedHttp != null)
return lastModifiedHttp;
Date modifiedDate = getLastModifiedDate();
if (modifiedDate == null) {
modifiedDate = getCreationDate();
}
if (modifiedDate == null) {
modifiedDate = new Date();
}
synchronized (format) {
lastModifiedHttp = format.format(modifiedDate);
}
return lastModifiedHttp;
}
Locale.US yields en_US on my system (LC_CTYPE=en_US.UTF-8). I tried
messing with LC_TYPE and I see that:
$ LC_CTYPE=en_US java LocaleTest
Locale.default = en_US
Locale.US = en_US
$ LC_CTYPE=de_DE java LocaleTest
Locale.default = de_DE
Locale.US = en_US
So, it looks like Locale.US always means en_US, though it wouldn't hurt
to be explicit about the language, here.
If Response.setDateHeader is called, you get this:
public void setDateHeader(String name, long value) {
if (isCommitted())
return;
// Ignore any call from an included servlet
if (included) {
return;
}
if (format == null) {
format = new
SimpleDateFormat(DateTool.HTTP_RESPONSE_DATE_HEADER,
Locale.US);
format.setTimeZone(TimeZone.getTimeZone(GMT));
}
setHeader(name, FastHttpDateFormat.formatDate(value, format));
}
So, it looks like Tomcat 6.0.20 does things properly, at least when it
comes to DefaultServlet and Response.setDateFormat. Oddly enough, these
SimpleDateFormat objects are being created all the time even though the
Response object is not guaranteed to be threadsafe... why not simply
re-use the DateFormat object forever since it's always the same thing?
Are you sure that this date header is coming from Tomcat's code?
Again my other question: How can I instruct tomcat not to put the
Last-Modified Header into the response at all? Do I have to use a
filter or can it be done by configuration? Or is is somehow not
recommended fiddle with the headers?
It doesn't look like DefaultServlet has any options for this, so you'll
have to do it with a filter or valve. If it's really Tomcat's code that
is the problem, you almost certainly will need a Valve since the code
might not be wrappable via a filter. I think it would be most
interesting to see where that header is being set... I suspect this code
hasn't changed for quite a while.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksqn/YACgkQ9CaO5/Lv0PBbeQCfYlW2uiVT4j0T1QMF+MLwVjLX
EpkAmwf3lUMQZc6ikfVA64r8w9PD3jAk
=vIOz
-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
AW: Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since
Hi again, It seems that Mark is right. I just tried it with another webapp and also in a clean installation and the headers are correct there, even if the locale is set to polish. Have to investigate further what causes the misspelled header. There aren't any filters in my webapp that modify the headers. Best regards, Abid -Ursprüngliche Nachricht- Von: Mark Thomas [mailto:ma...@apache.org] Gesendet: Freitag, 18. Dezember 2009 11:36 An: Tomcat Users List Betreff: Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since On 18/12/2009 09:36, André Warnier wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Abid, On 12/17/2009 12:08 PM, Abid Hussain wrote: I used the startup parameters -Duser.language=en -Duser.region=US This caused Tomcat to deliver the Last-Modified in the correct format. That solved the problem, no 404 anymore, thanks. So it seems to be a bug in tomcat...? I would say so. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1 Tomcat's behavior seems to ignore the specification, here. Would you care to share your Tomcat version with us? So far, I haven't seen anything that demonstrates Tomcat is generating this header. It looks like an app issue to me. My testing with trunk, 6.0.x and 6.0.20 all show the correct format being used. I think that once this is confirmed, it may be worth raising its visibility a bit for the Tomcat developers. As always before reporting an error, I'd highly recommend generating a simple as possible test case that demonstrates the issue on a clean Tomcat install. I can't repeat this and at the moment it looks like an application issue. Any bug report that can't be repeated is just going to get closed as WORKSFORME. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since
OK, it seems that tomcat is working correctly. Still I would like to get the root cause of my problem which is again: The last-modified response header is delivered in the locale of the server. E.g. if this locale is polish or germen, the header is delivered in polish resp. german format which is not correct and causes misbehaviour. Naturally I just can set the locale to en_US to get the desired header format. But this is not the root cause of the problem. The question is: How can the format of this header can be set (or overridden) to the server's locale? I tried the following: * Asked Google: Nothing found. * Searched for occurences of last-modified in the source code of my application: Nothing found. * Looked if the methods HttpServletResponse.setHeader() or HttpServletResponse.addHeader() are used with the last-modified somewhere in my application: Nothing found. * Looked if one of the configured filters modify the header: Nothing found. * Looked if any valves are used: None. Anybody got an idea how I can investigate further? Regards, Abid -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Freitag, 18. Dezember 2009 13:56 An: Tomcat Users List Betreff: Re: AW: Re: AW: RE: RE: Ignore http header if-modified-since Mark Thomas wrote: On 18/12/2009 09:36, André Warnier wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Abid, On 12/17/2009 12:08 PM, Abid Hussain wrote: I used the startup parameters -Duser.language=en -Duser.region=US This caused Tomcat to deliver the Last-Modified in the correct format. That solved the problem, no 404 anymore, thanks. So it seems to be a bug in tomcat...? I would say so. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1 Tomcat's behavior seems to ignore the specification, here. Would you care to share your Tomcat version with us? So far, I haven't seen anything that demonstrates Tomcat is generating this header. It looks like an app issue to me. My testing with trunk, 6.0.x and 6.0.20 all show the correct format being used. I think that once this is confirmed, it may be worth raising its visibility a bit for the Tomcat developers. As always before reporting an error, I'd highly recommend generating a simple as possible test case that demonstrates the issue on a clean Tomcat install. I can't repeat this and at the moment it looks like an application issue. Any bug report that can't be repeated is just going to get closed as WORKSFORME. For a confirmation of what Mark says above, I ran some tests. This Tomcat 5.5 is a pretty vanilla version, with just the standard example apps and not much more, on my Windows workstation. Versions are not the latest ones, I know. INFO: Starting Servlet Engine: Apache Tomcat/5.5.26 Platform : Windows XP, German Java : java version 1.6.0_06 Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing) Tomcat running as service, stopped and restarted before each test below A) Platform default Tomcat startup parameters as per tomcat5w.exe : -Dcatalina.home=C:\Tomcat5.5 -Dcatalina.base=C:\Tomcat5.5 -Djava.endorsed.dirs=C:\Tomcat5.5\common\endorsed -Djava.io.tmpdir=C:\Tomcat5.5\temp -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=C:\Tomcat5.5\conf\logging.properties (platform default) Request: (Request-Line)GET /RELEASE-NOTES.txt HTTP/1.1 Host localhost:8180 User-AgentMozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language en-gb,en;q=0.5 Accept-Encoding gzip,deflate Accept-CharsetISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive300 Connectionkeep-alive If-Modified-Since Mon, 28 Jan 2008 20:38:54 GMT If-None-Match W/7697-1201552734000 Cache-Control max-age=0 Response: (Status-Line) HTTP/1.1 304 Not Modified ServerApache-Coyote/1.1 Etag W/7697-1201552734000 Date Fri, 18 Dec 2009 11:37:58 GMT B) Adding explicit DE startup parameters Tomcat startup parameters as per tomcat5w.exe : -Dcatalina.home=C:\Tomcat5.5 -Dcatalina.base=C:\Tomcat5.5 -Djava.endorsed.dirs=C:\Tomcat5.5\common\endorsed -Djava.io.tmpdir=C:\Tomcat5.5\temp -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=C:\Tomcat5.5\conf\logging.properties -Duser.language=de -Duser.region=DE Request : (Request-Line)GET /RELEASE-NOTES.txt HTTP/1.1 Host localhost:8180 User-AgentMozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language en-gb,en;q=0.5
AW: RE: Ignore http header if-modified-since
Hallo, unfortunately it is a 404. And the 404 is only delivered when the request header contains if-modified-since. If not the request is respondec correctly. This behaviour is reproducable. Below you find an example of failed and successful request. The GET URL is in both cases http://localhost:8080/mywebapp/faces/static/META-INF/progressbar/script.js -- Failed Request (means tomcat responds with 404): Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,en-us;q=0.8,de;q=0.6,en;q=0.4,fr-fr;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=262FAFFC220AF50656BC67C1C1DD1331 If-Modified-Since: Do, 17 Dez 2009 11:11:29 GMT Cache-Control: max-age=0 -- Response: Server: Apache-Coyote/1.1 Content-Type: text/html Content-Length: 1093 Date: Thu, 17 Dec 2009 11:24:38 GMT -- Successful: Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,en-us;q=0.8,de;q=0.6,en;q=0.4,fr-fr;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=262FAFFC220AF50656BC67C1C1DD1331 Cache-Control: max-age=0 -- Response: Server: Apache-Coyote/1.1 Last-Modified: Do, 17 Dez 2009 11:11:29 GMT Content-Type: text/javascript Transfer-Encoding: chunked Date: Thu, 17 Dec 2009 11:24:53 GMT Does anybody have an explanation for this? Best regards, Abid -Ursprüngliche Nachricht- Von: Looijmans, Mike [mailto:mike.looijm...@oce.com] Gesendet: Mittwoch, 16. Dezember 2009 15:48 An: Tomcat Users List Betreff: RE: Ignore http header if-modified-since I assume you mean 304 (Not modified) instead of 404 (Not found). Simplest I can think of is to NOT put the last-modified header in your response. Then the browser won't send you an if-modified-since back. On the other hand, if you can put a datestamp on the response - e.g. a file date or by reading it from a DB or so - provide the proper response and you get client-side caching for (almost) free, which can seriously reduce load on a server. M. -Original Message- From: Abid Hussain [mailto:abid.huss...@dilax.com] Sent: woensdag 16 december 2009 14:11 To: users Subject: Ignore http header if-modified-since Hallo, when processing ajax-requests Tomcat sometimes responds with a 404 instead of delivering XML. This seems to happen when the http header if-modified-since in the request doesn't somehow contain the right value. At least, if the request doesn't contain this header, tomcat responds correctly. Is it possible to instruct tomcat to simply ignore this header so that the correct response will be delivered, whatever is contained in this header? Best regards, Abid (EOF) This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. - 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
AW: Re: AW: RE: Ignore http header if-modified-since
Hi, the file is contained in a jar (which is naturally in classpath) and inside this jar contained in the following path: jar-file/META-INF/progressbar/script.js Best regards, Abid -Ursprüngliche Nachricht- Von: Pid [mailto:p...@pidster.com] Gesendet: Donnerstag, 17. Dezember 2009 14:20 An: users@tomcat.apache.org Betreff: Re: AW: RE: Ignore http header if-modified-since On 17/12/2009 11:26, Abid Hussain wrote: Hallo, unfortunately it is a 404. And the 404 is only delivered when the request header contains if-modified-since. If not the request is respondec correctly. This behaviour is reproducable. Below you find an example of failed and successful request. The GET URL is in both cases http://localhost:8080/mywebapp/faces/static/META-INF/progressbar/scrip t.js The file is actually in a META-INF directory? p -- Failed Request (means tomcat responds with 404): Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,en-us;q=0.8,de;q=0.6,en;q=0.4,fr-fr;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=262FAFFC220AF50656BC67C1C1DD1331 If-Modified-Since: Do, 17 Dez 2009 11:11:29 GMT Cache-Control: max-age=0 -- Response: Server: Apache-Coyote/1.1 Content-Type: text/html Content-Length: 1093 Date: Thu, 17 Dec 2009 11:24:38 GMT -- Successful: Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,en-us;q=0.8,de;q=0.6,en;q=0.4,fr-fr;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=262FAFFC220AF50656BC67C1C1DD1331 Cache-Control: max-age=0 -- Response: Server: Apache-Coyote/1.1 Last-Modified: Do, 17 Dez 2009 11:11:29 GMT Content-Type: text/javascript Transfer-Encoding: chunked Date: Thu, 17 Dec 2009 11:24:53 GMT Does anybody have an explanation for this? Best regards, Abid -Ursprüngliche Nachricht- Von: Looijmans, Mike [mailto:mike.looijm...@oce.com] Gesendet: Mittwoch, 16. Dezember 2009 15:48 An: Tomcat Users List Betreff: RE: Ignore http header if-modified-since I assume you mean 304 (Not modified) instead of 404 (Not found). Simplest I can think of is to NOT put the last-modified header in your response. Then the browser won't send you an if-modified-since back. On the other hand, if you can put a datestamp on the response - e.g. a file date or by reading it from a DB or so - provide the proper response and you get client-side caching for (almost) free, which can seriously reduce load on a server. M. -Original Message- From: Abid Hussain [mailto:abid.huss...@dilax.com] Sent: woensdag 16 december 2009 14:11 To: users Subject: Ignore http header if-modified-since Hallo, when processing ajax-requests Tomcat sometimes responds with a 404 instead of delivering XML. This seems to happen when the http header if-modified-since in the request doesn't somehow contain the right value. At least, if the request doesn't contain this header, tomcat responds correctly. Is it possible to instruct tomcat to simply ignore this header so that the correct response will be delivered, whatever is contained in this header? Best regards, Abid (EOF) This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. - 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 - 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
AW: RE: RE: Ignore http header if-modified-since
Hi, this is interesting. As you see in my example (i put it again below), tomcat itself delivers the Last-Modified (Do, 17 Dez 2009 11:11:29 GMT) in a different locale (german) as the Date Header (Thu, 17 Dec 2009 11:24:53 GMT). So maybe the simplest way is to prevent tomcat from putting the Last-Modified Header into the response. Do I have to use a Filter to do so or can this be done by another way (by configuration, ...)? Best regards, Abid -- Successful Request: Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,en-us;q=0.8,de;q=0.6,en;q=0.4,fr-fr;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=262FAFFC220AF50656BC67C1C1DD1331 Cache-Control: max-age=0 -- Response: Server: Apache-Coyote/1.1 Last-Modified: Do, 17 Dez 2009 11:11:29 GMT Content-Type: text/javascript Transfer-Encoding: chunked Date: Thu, 17 Dec 2009 11:24:53 GMT -Ursprüngliche Nachricht- Von: Looijmans, Mike [mailto:mike.looijm...@oce.com] Gesendet: Donnerstag, 17. Dezember 2009 15:03 An: Tomcat Users List Betreff: RE: RE: Ignore http header if-modified-since This header is invalid: Last-Modified: Do, 17 Dez 2009 11:11:29 GMT This is not according to spec, Dez should be Dec. Maybe tomcat chokes on it. -Original Message- From: Abid Hussain [mailto:abid.huss...@dilax.com] Sent: donderdag 17 december 2009 12:26 To: users Subject: AW: RE: Ignore http header if-modified-since Hallo, unfortunately it is a 404. And the 404 is only delivered when the request header contains if-modified-since. If not the request is respondec correctly. This behaviour is reproducable. Below you find an example of failed and successful request. The GET URL is in both cases http://localhost:8080/mywebapp/faces/static/META-INF/progressb ar/script.js -- Failed Request (means tomcat responds with 404): Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,en-us;q=0.8,de;q=0.6,en;q=0.4,fr-fr;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=262FAFFC220AF50656BC67C1C1DD1331 If-Modified-Since: Do, 17 Dez 2009 11:11:29 GMT Cache-Control: max-age=0 -- Response: Server: Apache-Coyote/1.1 Content-Type: text/html Content-Length: 1093 Date: Thu, 17 Dec 2009 11:24:38 GMT -- Successful: Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,en-us;q=0.8,de;q=0.6,en;q=0.4,fr-fr;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=262FAFFC220AF50656BC67C1C1DD1331 Cache-Control: max-age=0 -- Response: Server: Apache-Coyote/1.1 Last-Modified: Do, 17 Dez 2009 11:11:29 GMT Content-Type: text/javascript Transfer-Encoding: chunked Date: Thu, 17 Dec 2009 11:24:53 GMT Does anybody have an explanation for this? Best regards, Abid -Ursprüngliche Nachricht- Von: Looijmans, Mike [mailto:mike.looijm...@oce.com] Gesendet: Mittwoch, 16. Dezember 2009 15:48 An: Tomcat Users List Betreff: RE: Ignore http header if-modified-since I assume you mean 304 (Not modified) instead of 404 (Not found). Simplest I can think of is to NOT put the last-modified header in your response. Then the browser won't send you an if-modified-since back. On the other hand, if you can put a datestamp on the response - e.g. a file date or by reading it from a DB or so - provide the proper response and you get client-side caching for (almost) free, which can seriously reduce load on a server. M. -Original Message- From: Abid Hussain [mailto:abid.huss...@dilax.com] Sent: woensdag 16 december 2009 14:11 To: users Subject: Ignore http header if-modified-since Hallo, when processing ajax-requests Tomcat sometimes responds with a 404 instead of delivering XML. This seems to happen when the http header if-modified-since in the request doesn't somehow contain the right value. At least, if the request doesn't contain this header, tomcat responds correctly. Is it possible to instruct tomcat to simply ignore this header so that the correct response will be delivered, whatever is contained in this header? Best regards, Abid (EOF) This message and attachment(s) are intended solely for use by the addressee and may
AW: Re: AW: RE: RE: Ignore http header if-modified-since
I used the startup parameters -Duser.language=en -Duser.region=US This caused Tomcat to deliver the Last-Modified in the correct format. That solved the problem, no 404 anymore, thanks. So it seems to be a bug in tomcat...? Again my other question: How can I instruct tomcat not to put the Last-Modified Header into the response at all? Do I have to use a filter or can it be done by configuration? Or is is somehow not recommended fiddle with the headers? Best regards, Abid -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 17. Dezember 2009 15:59 An: Tomcat Users List Betreff: Re: AW: RE: RE: Ignore http header if-modified-since Abid Hussain wrote: Hi, this is interesting. As you see in my example (i put it again below), tomcat itself delivers the Last-Modified (Do, 17 Dez 2009 11:11:29 GMT) in a different locale (german) as the Date Header (Thu, 17 Dec 2009 11:24:53 GMT). That sounds to me like a bug. Maybe the easiest fix is to set an eglish-language locale when you start Tomcat. If this is under Linux, try the following : - open a console window on the server and enter locale -a this will give you a list of installed locales. Maybe do locale -a | grep en_ to limit the list. Then, pick one of the list that contains utf8 and en, like maybe en_us.utf8 Then, in the tomcat bin directory, find the script setenv.sh, or create it if it does not exist, and add a line : export LANG=en_us.utf8 The restart Tomcat and try again. Do the headers now look different ? - 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
Ignore http header if-modified-since
Hallo, when processing ajax-requests Tomcat sometimes responds with a 404 instead of delivering XML. This seems to happen when the http header if-modified-since in the request doesn't somehow contain the right value. At least, if the request doesn't contain this header, tomcat responds correctly. Is it possible to instruct tomcat to simply ignore this header so that the correct response will be delivered, whatever is contained in this header? Best regards, Abid - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Re: Response logging
Thanks for the link, I will try the filter in my application. Best regards, Abid -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Montag, 14. Dezember 2009 19:56 An: Tomcat Users List Betreff: Re: Response logging -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Abid, On 12/14/2009 11:09 AM, Abid Hussain wrote: I would like to log the complete responses (including the body) from the incoming ajax requests. [snip] Does anybody if there is any tomcat-built-in or external tool which can log every response tomcat sends out? I don't believe that there is anything built-in. Someone recently asked about how to do this, and I wrote a filter that can capture the response, including headers, etc. I posted it to this list, and you can read the whole thread here: http://markmail.org/message/fumpfuspt7a3nesz Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksmijcACgkQ9CaO5/Lv0PCKvgCfZLj0KG00UEWHj1qHeRI98lcl J5YAn1siZfrMrrKUetSFJmHeQ2d9PInr =s55q -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
Response logging
Hello everybody, for testing some ajax components on my local tomcat (in a JSF application) I would like to log the complete responses (including the body) from the incoming ajax requests. I already configured a org.apache.catalina.valves.AccessLogValve for logging the incoming requests. But there seems to be no valve for logging the responses. Does anybody if there is any tomcat-built-in or external tool which can log every response tomcat sends out? Best regards, Abid - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: retrieving two different objects from session (should be thesame)
Hi again, sorry for delay and thanks for help. Chuck has been absolutely right - it was a concurrency issue. As he said, it's better to store needed objects in the request than in the session. The problem is, I need an object being available for several requests, so I have to store it in the session. Now I have to find a way to store objects in session avoiding any concurrency issues... Regards, Abid Caldarale, Charles R schrieb: From: Abid Hussain [mailto:[EMAIL PROTECTED] Subject: Re: retrieving two different objects from session (should be thesame) so this means, it's specified behaviour that there is no guarantee, having an object placed in session would be the same after retrieving it after some time...? No, the object will be the same, unless the session is persisted and reloaded (what Mark T was asking about earlier), or clustering is being used. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
retrieving two different objects from session (should be the same)
Hi everybody, I'm using tomcat 5.5.9 and am encountering a strange behaviour. I'm not sure, if it may be a tomcat issue... I'm putting an object (called form) into the user's session using session.setAttribute() and retrieving it again (after the user has done some actions) using session.getAttribute(). Now look at my log messages: Before putting the object into session: Put form ([EMAIL PROTECTED]) in session (42A90C9AAEE86B81C916F093AAD69452) After retrieving it from session: Form ([EMAIL PROTECTED]) has been submitted, got it from session (42A90C9AAEE86B81C916F093AAD69452) As you see the results from calling form.toString() are not the same. I've neither overriden toString() nor hashCode() - the methods from java.lang.Object are being used. It seems that this behaviour only occurs in productive system. In my local system it didn't come up. Anybody got an idea, how this can happen? Does tomcat modify the objects in session somehow...? Best regards, Abid -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: retrieving two different objects from session (should be the same)
Hi, thanks for help. As far as I know, persisting sessions is only used when stopping and restarting tomcat, which didn't happen in my case. So, this shouldn't be the reason...? If it's important for this issue, I can have a look in the server.xml. This would take some time, cause I've no rights to access the tomcat directore in productive system. Regards, Abid Mark Thomas schrieb: Abid Hussain wrote: Anybody got an idea, how this can happen? Does tomcat modify the objects in session somehow...? Do you have any session persistence configured? Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: retrieving two different objects from session (should be thesame)
Hi again, I'm not sure if I got the point. I would have thought that it doesn't matter if concurrent requests come in, cause: 1. There's only one request which ends up in the servlet where the described behaviour came up. The other requests which are generated by the browser wouldn't be delegated to the servlet, cause they are only requesting static resources (like pictures, etc.). 2. The webapp is normally used by a few users at the same time. 3. Whatever the number of requests is, the session stays the same, shouldn't it? Regards, Abid Caldarale, Charles R schrieb: From: Abid Hussain [mailto:[EMAIL PROTECTED] Subject: Re: retrieving two different objects from session (should be thesame) So, this shouldn't be the reason...? Are you properly synchronizing accesses to the session for concurrent requests? Browsers will almost always generate multiple concurrent requests for the same session whenever the page being displayed has anything embedded in it (e.g., style sheets, pictures). - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: retrieving two different objects from session (should be thesame)
Hi, The result of HttpServletRequest.getSession gives you a SessionFacade which is not guaranteed to be the same as the one given to another thread accessing the same session (right?). You could synchronize using an object stored /in/ the session, but then you have to worry about that object being replaced, etc. so this means, it's specified behaviour that there is no guarantee, having an object placed in session would be the same after retrieving it after some time...? Regards, Abid -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
multiple webapps on single tomcat?
Hi everybody, I am planning to set up a couple (2-5) of webapps. I've encountered some problems in the past when running multiple webapps on a single tomcat, cause they somehow interfered with each other (frankly, I never unterstood why). My question is: Is there a best practice for running several webapps on a single tomcat instance in terms of not interfering with each other? Or is it principally better to run every webapp in it's own tomcat instance? Would be thankful for any advices. Regards, Abid -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple webapps on single tomcat?
Thanks for help. So am I right saying that no conflicts between webapps can occur when 1. using tomcat 5.x... - all wepapps only use their WEB-INF/lib as directory for libraries and - none of the webapps uses libraries from $CATALINA_HOME/common/lib resp. $CATALINA_HOME/shared/lib 2. using tomcat 6... - none of the webapps uses libraries from $CATALINA_HOME/lib? Both points are meant except the usage of standard libraries like servlet-api, jsp-api etc., which are naturally needed by all webapps. Regards, Abid Roland Brassous (SILOGIC) schrieb: Hi, in order to start Bests practises, i think about these rules... Libraries - Be care of [Tomcat directory]\shared\classes or [Tomcat directory]\shared\lib contents - Be care of [Tomcat directory]\common\classes, [Tomcat directory]\common\classes\endorsed and [Tomcat directory]\common\classes\lib contents I think about conflict Context definition - Each context are defined in a separate configuration file ( [Tomcat directory]\conf\Catalina\localhost\ perhaps is a good start... Hassan Schroeder a écrit : On Mon, Feb 25, 2008 at 5:46 AM, Abid Hussain [EMAIL PROTECTED] wrote: My question is: Is there a best practice for running several webapps on a single tomcat instance ... Tomcat is made for this. Install your webapps per the documentation (and Servlet Spec) and they won't interfere with each other. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using a dll in a webapp
Hi everybody, I want to establish a connection to a serial port from my webapp by using the javax.comm package which uses the win32com.dll (on windows systems). In most cases, it seems to be the common way to place the dll in the jre/bin directory. But I want to have all needed libraries in my webapp directory. Therefore, I resolve the path of the dll in my webapp: String win32com = new File(this.getClass().getClassLoader().getResource(win32com.dll).toURI()).getPath(); Now, I add the path to the java.library.path property: System.setProperty(java.library.path, System.getProperty(java.library.path) + File.pathSeparator + win32com); When I now output the java.library.path on the console (using System.getProperty(java.library.path)) the dll is in the path. Now, I try to load the dll: System.loadLibrary(win32com.dll); And this fails. The Error message is: java.lang.UnsatisfiedLinkError: no win32com.dll in java.library.path I wonder how it's possible that the dll seems not to be in the java.library.path although I just added it - has anybody an idea? Thanks a lot for helping. Best regards, Abid -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using a dll in a webapp - Fixed!
Hi again, I think I solved the problem. Like I wrote, using System.loadLibrary(win32com.dll); didn't work, neither did CommDriver commDriver = (CommDriver) Class.forName(com.sun.comm.Win32Driver).newInstance(); commDriver.initialize(); But initializing the driver using Class clazz = this.getClass().getClassLoader().loadClass(com.sun.comm.Win32Driver); CommDriver driver = (CommDriver) clazz.newInstance(); driver.initialize(); worked!! The driver did initialize correctly and the connection to the serial port was established! Maybe the problem came up because Tomcat uses it's own classloader. Now It is even not necessary anymore to set the java.library.path. The win32com.dll is located in the WEB-INF/lib directory. 2 ways place the dll in jre\bin add folder where win32com.dll is located to LD_LIBRARY_PATH in jvm.cfg? restart The reason why I didn't want to do so, is because I wanted all the needed stuff to be in the webapp directory, so that anyone can deploy the webapp remotely via the Tomcat-Manager and doesn't have to bother about setting path variables and doing other things on the machine where the server is running. However, thanks a lot for helping me. I'm glad that it was easier than I thought. Best regards, Abid M- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. - Original Message - From: Abid Hussain [EMAIL PROTECTED] To: users@tomcat.apache.org Sent: Friday, December 15, 2006 9:03 AM Subject: using a dll in a webapp Hi everybody, I want to establish a connection to a serial port from my webapp by using the javax.comm package which uses the win32com.dll (on windows systems). In most cases, it seems to be the common way to place the dll in the jre/bin directory. But I want to have all needed libraries in my webapp directory. Therefore, I resolve the path of the dll in my webapp: String win32com = new File(this.getClass().getClassLoader().getResource(win32com.dll).toURI()).getPath(); Now, I add the path to the java.library.path property: System.setProperty(java.library.path, System.getProperty(java.library.path) + File.pathSeparator + win32com); When I now output the java.library.path on the console (using System.getProperty(java.library.path)) the dll is in the path. Now, I try to load the dll: System.loadLibrary(win32com.dll); And this fails. The Error message is: java.lang.UnsatisfiedLinkError: no win32com.dll in java.library.path I wonder how it's possible that the dll seems not to be in the java.library.path although I just added it - has anybody an idea? Thanks a lot for helping. Best regards, Abid -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat doesn't deliver page on first call
Hi everybody, After restarting Tomcat (5.0.28), it doesn't deliver the requested jsp-page on the first calls. I have to hit about 5-8 times the reload-button until tomcat delivers the requested page (e.g. index.jsp). Also this problem sometimes turns up when calling servlets for the first time after restart, even when tomcat is running already for about 10 minutes. Is this a normal behavior? Is there anything to do in the configuration files (server.xml, etc.) about this? Maybe this Problem is because the machine where tomcat is running on (1 GHZ CPU, 512MB RAM) is not powerful enough? Has anyone an idea about this? Best Regards, Abid -- Abid Hussain Mail: [EMAIL PROTECTED] Web: http://www.abid76.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
