RE: Heap not expanding beyond -Xms512m
I agree, it's always a good idea to let the JVM do what it is supposed to do instead of creating a growing overhead. The only exception to that rule is if you think you'll reach 1024 MB, but as you say yourself, 512 seems to do fine as -Xms. btw, here is an article that goes into detail (ratio's etc.) using jvm 1.4.2 http://java.sun.com/docs/hotspot/gc1.4.2/index.html Q -Original Message- From: Dale, Matt [mailto:[EMAIL PROTECTED] Sent: 20 April 2005 15:24 To: Tomcat Users List Subject: RE: Heap not expanding beyond -Xms512m This is expected behaviour. The heap will not grow if the memory required can be gained through a garbage collection. The heap will only grow if after a garbage collection it still cannot allocate the required memory or is over a certain percentage (I forget what the default is). I would suggest that you don't in fact need 512MB if your app runs fine with no OOM in 512MB. If you really want to use the full 1GB the you'll have to use -Xms as you suggested. Ta Matt -Original Message- From: Guillaume Lahitette [mailto:[EMAIL PROTECTED] Sent: 20 April 2005 13:54 To: tomcat-user@jakarta.apache.org Subject: Heap not expanding beyond -Xms512m Hello Tomcat-oids, I'd really appreciate any help with this...Thanks in advance. We've been running performance tests against Tomcat 4.1.26 on Linux and Windows. We've tuned heap sizes to -Xms512m -Xmx1024m. Monitoring the JVM memory usage with a daemon thread calling Runtime.getRuntime().freeMemory() / totalMemory() / maxMemory(), we've noticed memory was never expanded beyond 512MB. Instead, when usage was getting close to 512MB, we could see the garbage collector kick in. We never got OOM errors. Can anyone share experiences about this? Do I have to use -Xms1024m -Xmx1024m (which seems to defeat the purpose of having ms and mx...)? Guillaume - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Heap not expanding beyond -Xms512m
Ooops, I meant -Xmx512 ;) -Original Message- From: Quinten Verheyen Sent: 20 April 2005 15:32 To: 'Tomcat Users List' Subject: RE: Heap not expanding beyond -Xms512m I agree, it's always a good idea to let the JVM do what it is supposed to do instead of creating a growing overhead. The only exception to that rule is if you think you'll reach 1024 MB, but as you say yourself, 512 seems to do fine as -Xms. btw, here is an article that goes into detail (ratio's etc.) using jvm 1.4.2 http://java.sun.com/docs/hotspot/gc1.4.2/index.html Q -Original Message- From: Dale, Matt [mailto:[EMAIL PROTECTED] Sent: 20 April 2005 15:24 To: Tomcat Users List Subject: RE: Heap not expanding beyond -Xms512m This is expected behaviour. The heap will not grow if the memory required can be gained through a garbage collection. The heap will only grow if after a garbage collection it still cannot allocate the required memory or is over a certain percentage (I forget what the default is). I would suggest that you don't in fact need 512MB if your app runs fine with no OOM in 512MB. If you really want to use the full 1GB the you'll have to use -Xms as you suggested. Ta Matt -Original Message- From: Guillaume Lahitette [mailto:[EMAIL PROTECTED] Sent: 20 April 2005 13:54 To: tomcat-user@jakarta.apache.org Subject: Heap not expanding beyond -Xms512m Hello Tomcat-oids, I'd really appreciate any help with this...Thanks in advance. We've been running performance tests against Tomcat 4.1.26 on Linux and Windows. We've tuned heap sizes to -Xms512m -Xmx1024m. Monitoring the JVM memory usage with a daemon thread calling Runtime.getRuntime().freeMemory() / totalMemory() / maxMemory(), we've noticed memory was never expanded beyond 512MB. Instead, when usage was getting close to 512MB, we could see the garbage collector kick in. We never got OOM errors. Can anyone share experiences about this? Do I have to use -Xms1024m -Xmx1024m (which seems to defeat the purpose of having ms and mx...)? Guillaume - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
odd problem when using a build that calls a build w/ the deploy task
Hi, ran into something odd:
- buildfile A (build-A.xml) contains deploy task, running the task works w/o
any problems :
!-- ... --
target name=deploy depends=war
deploy url=${tomcat.manager.url}
username=${tomcat.manager.username}
password=${tomcat.manager.password}
war=${dist.dir}/webapp.war
path=/${name}
update=true /
/target
!-- ... --
Now comes the strange part ...
- buildfile B wants to call A's deploy task, remark : it's located in another
dir, more specific the dir above, so :
!-- ... --
target name=master
ant antfile=build-A.xml target=all dir=subdir /
/target
!-- ... --
Question : does this work ?
Answer : Nope, it results in a java.io.FileNotFoundException: dist\webapp.war
(The system cannot find the path specified)
Question : Why ?
Answer : Because the deploy task searches for dist in the dir of build B.
Question : Why ?
Answer : I don't know ... ;-)
It is strange because the deploy task is the only one who has a problem with
this. In reality build file B is a master build file that calls a 'all' target,
and buildfile A contains the whole standard deployment shabang - none of them
fail except this specific task.
I would say it's worth checking out.
Obviously this prob is solved by using an absolute path, but it speaks for
itself it shouldn't be configured like that.
Any thoughts ?
Kind regards,
Q
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: odd problem when using a build that calls a build w/ the deploy task
Found it, the dist.dir property was set to dist, it should have been set to
${basedir}/dir, all other relative dirs had the latter convention, which
explains everything.
-Original Message-
From: Quinten Verheyen
Sent: 18 April 2005 16:43
To: Tomcat Users List
Subject: odd problem when using a build that calls a build w/
the deploy
task
Hi, ran into something odd:
- buildfile A (build-A.xml) contains deploy task, running the
task works w/o any problems :
!-- ... --
target name=deploy depends=war
deploy url=${tomcat.manager.url}
username=${tomcat.manager.username}
password=${tomcat.manager.password}
war=${dist.dir}/webapp.war
path=/${name}
update=true /
/target
!-- ... --
Now comes the strange part ...
- buildfile B wants to call A's deploy task, remark : it's
located in another dir, more specific the dir above, so :
!-- ... --
target name=master
ant antfile=build-A.xml target=all dir=subdir /
/target
!-- ... --
Question : does this work ?
Answer : Nope, it results in a
java.io.FileNotFoundException: dist\webapp.war (The system
cannot find the path specified)
Question : Why ?
Answer : Because the deploy task searches for dist in the
dir of build B.
Question : Why ?
Answer : I don't know ... ;-)
It is strange because the deploy task is the only one who has
a problem with this. In reality build file B is a master
build file that calls a 'all' target, and buildfile A
contains the whole standard deployment shabang - none of
them fail except this specific task.
I would say it's worth checking out.
Obviously this prob is solved by using an absolute path, but
it speaks for itself it shouldn't be configured like that.
Any thoughts ?
Kind regards,
Q
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
how to solve undeploy locking issue
Hi, I'm resending this issue, I still have the locked jar situation when executing the catalina undeploy task, it only occurs when my web.xml was pointing to resources in that jar. Temporarily I'm using alternative approaches (overwriting files, catalina stop+start), but they don't guarantee it works all the time. A couple of weeks ago, I brought this up on this list and was advised to test it against Tomcat 5.5.9. I did and the problem still occurred, so I checked non-Tomcat possible causes first, like the resource's lifecycle management (done by Spring framework), but it all seems to point at Tomcat or rather the Tomcat's undeploy task. What goes wrong is very simple, the undeploy task removes the war file, but not the expanded dir because one if it's jars could not be removed. I believe the reason is that the context is removed before the resources had the time to be destroyed, resulting in a trapped situation, but I'm not sure, I could be wrong. The log lines below (v5.5.9) aren't helping me enough : 2005-04-15 09:16:21,561 INFO [org.springframework.web.servlet.DispatcherServlet] - Servlet 'momagw' configured successfully // EXECUTING UNDEPLOY TASK 2005-04-15 09:17:13,873 INFO [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/momagw]] - Closing WebApplicationContext of Spring FrameworkServlet 'momagw' 2005-04-15 09:17:13,873 INFO [org.springframework.web.context.support.XmlWebApplicationContext] - Closing application context [WebApplicationContext for namespace 'momagw-servlet'] 2005-04-15 09:17:13,873 INFO [org.springframework.beans.factory.support.DefaultListableBeanFactory] - Destroying singletons in factory 2005-04-15 09:17:13,873 INFO [org.springframework.beans.factory.support.DefaultListableBeanFactory] - Destroying inner beans in factory 2005-04-15 09:17:13,873 INFO [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/momagw]] - Closing Spring root WebApplicationContext 2005-04-15 09:17:13,873 INFO [org.springframework.web.context.support.XmlWebApplicationContext] - Closing application context [org.springframework.web.context.support.XmlWebApplicationContext;hashCode=31116492] 2005-04-15 09:17:13,873 INFO [org.springframework.beans.factory.support.DefaultListableBeanFactory] - Destroying singletons in factory 2005-04-15 09:17:13,889 INFO [org.springframework.beans.factory.support.DefaultListableBeanFactory] - Destroying inner beans in factory 2005-04-15 09:17:13,889 INFO [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/momagw]] - Shutting down Log4J 15-Apr-2005 09:17:13 org.apache.catalina.startup.HostConfig checkResources INFO: Undeploying context [/momagw] 15-Apr-2005 09:17:21 org.apache.catalina.startup.ContextConfig applicationWebConfig INFO: Missing application web.xml, using defaults only StandardEngine[Catalina].StandardHost[localhost].StandardContext[/momagw] Regards, Q - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Locked jar during Ant undeploy on Tomcat 5.5.3
Hi, could someone please help me with this ? It's really time-consuming and I'm making no progress. To recap, my web.xml file points to configuration files IN a jar file (located under WEB-INF/lib), I know for certain that it causes the jar to be locked when I try to undeploy (catalina task) my application. The war is removed, but the directory remains, only with that one jar in it. Example web.xml : !-- UNDEPLOY DOES NOT WORK -- context-param param-namecontextConfigLocation/param-name param-value classpath*:be/ringring/momaframework/applicationContext.xml classpath*:be/ringring/momaframework/dataAccessContext-local.xml /WEB-INF/applicationContext.xml /param-value /context-param !-- UNDEPLOY WORKS -- context-param param-namecontextConfigLocation/param-name param-value /WEB-INF/applicationContext.xml /param-value /context-param I could use some assistance :-) Regards, Quinten -Original Message- From: Quinten Verheyen Sent: 31 March 2005 18:01 To: Tomcat Users List Subject: RE: Locked jar during Ant undeploy on Tomcat 5.5.3 Hi, I'm experiencing a similar problem, I read the Tomcat docs and this thread first before submitting. In my case, on freshly unzipped Tomcat versions 5.0.25, 5.0.28 and 5.5.4 the catalina ant task 'undeploy' encounters a locked jar-file situation. I suspect the jar-file is locked because the webapp's web.xml file specifies configuration files from that jar-file (n.b. for Spring context loading). The Tomcat production version I want to undeploy on is 5.0.25. Also, the logs indicated Tomcat tries to redeploy the webapp after executing the undeploy task : INFO: Server startup in 12359 ms 31-Mar-2005 17:07:37 org.apache.catalina.core.ContainerBase log INFO: Removing web application at context path /mywebapp 31-Mar-2005 17:07:46 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /mywebapp from URL file:C:\webservers\jakarta-tomcat-5.0.28\webapps\mywebapp 31-Mar-2005 17:07:46 org.apache.catalina.startup.ContextConfig applicationConfig INFO: Missing application web.xml, using defaults only StandardEngine[Catalina].StandardHost[localhost].StandardConte xt[/mywebapp] Various options seem open to me, I want to try this list first because I can imagine this problem is common and goes beyond simple configuration errors ... Kind regards, Q -Original Message- From: Derek Mahar [mailto:[EMAIL PROTECTED] Sent: 14 October 2004 20:15 To: tomcat-user@jakarta.apache.org Subject: Re: Locked jar during Ant undeploy on Tomcat 5.5.3 Thank you for pointing out these redundant attributes. I applied these changes to the context, but got the same results. If I have time, I'll put together a small application that demonstrates the problem and send that to you. If the issue is real, then I think there will be someone to provide a webapp. Yes, and that person's me! :) I just sent a test WAR that demonstrates the problem directly to your Gmail address. As I'm using Gmane, and Gmane does not allow attachments, I could not attach the WAR to this message. Derek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Locked jar during Ant undeploy on Tomcat 5.5.3
There have been several locking issues resolved in later versions of Tomcat. (See http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html.) Does the problem exist on the current level (5.5.9)? - Chuck Yes it does, the following is showing in the tomcat logs : 2005-04-08 15:34:35,785 INFO [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/momagw]] - Closing WebApplicationContext of Spring FrameworkServlet 'momagw' 2005-04-08 15:34:35,800 INFO [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/momagw]] - Closing Spring root WebApplicationContext 2005-04-08 15:34:35,800 INFO [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/momagw]] - Shutting down Log4J 08-Apr-2005 15:34:35 org.apache.catalina.startup.HostConfig checkResources INFO: Undeploying context [/momagw] 08-Apr-2005 15:34:40 org.apache.catalina.startup.ContextConfig applicationWebConfig INFO: Missing application web.xml, using defaults only StandardEngine[Catalina].StandardHost[localhost].StandardContext[/momagw] This missing web.xml eludes me, but it happened on 5.0.28 and 5.5.4 also. Regards, Quinten 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Locked jar during Ant undeploy on Tomcat 5.5.3
I did some more fine-grained testing and it seems this is not a tomcat issue, if I point to a test xml configuration file that contains nothing except the expected root node the jar is still locked. So either I'm missing something or this is a Spring problem, I'll post it in their mailing list. If I'm right, I won't have to post this issue here anymore ... Regards, Q -Original Message- From: Quinten Verheyen Sent: 08 April 2005 15:40 To: Tomcat Users List Subject: RE: Locked jar during Ant undeploy on Tomcat 5.5.3 There have been several locking issues resolved in later versions of Tomcat. (See http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html.) Does the problem exist on the current level (5.5.9)? - Chuck Yes it does, the following is showing in the tomcat logs : 2005-04-08 15:34:35,785 INFO [org.apache.catalina.core.ContainerBase.[Catalina].[localhost] .[/momagw]] - Closing WebApplicationContext of Spring FrameworkServlet 'momagw' 2005-04-08 15:34:35,800 INFO [org.apache.catalina.core.ContainerBase.[Catalina].[localhost] .[/momagw]] - Closing Spring root WebApplicationContext 2005-04-08 15:34:35,800 INFO [org.apache.catalina.core.ContainerBase.[Catalina].[localhost] .[/momagw]] - Shutting down Log4J 08-Apr-2005 15:34:35 org.apache.catalina.startup.HostConfig checkResources INFO: Undeploying context [/momagw] 08-Apr-2005 15:34:40 org.apache.catalina.startup.ContextConfig applicationWebConfig INFO: Missing application web.xml, using defaults only StandardEngine[Catalina].StandardHost[localhost].StandardConte xt[/momagw] This missing web.xml eludes me, but it happened on 5.0.28 and 5.5.4 also. Regards, Quinten 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: URL encoding/decoding of UTF-8 characters
Indeed, I had the same problem on 5.0.25 once, use this filter in your web.xml to have UTF-8 encoding for all requests. filter filter-nameencodingFilter/filter-name filter-classfilters.SetCharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-nameencodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping Regards, Q -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: 06 April 2005 17:15 To: Tomcat Users List Subject: Re: URL encoding/decoding of UTF-8 characters It is a lack of agreed standard problem. You can force Tomcat to use UTF-8 encoding by setting the URIEncoding parameter on the connector. There are some other parameters that you can set as well. See http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/http.html Mark Steve Bosman wrote: I raised this on the struts mailing list and had no joy there, but since then I've found out that it appears to be a tomcat specific problem. The struts 1.1. application I am working on has some frameset stuff (which I personally hate, but some things you are forced to live with), occasionally frames within the frameset are set with parameters in the URL which is output using html:rewrite (normally as the result of failed actions). If a parameter has UTF-8 characters, e.g. 5--2005 this is encoded as this: /foo.do?date=5-%D0%B0%D0%BF%D1%80-2005 By the time the date arrives in my ActionForm the value is now 5-?-2005. I have tried this on weblogic, websphere and oc4j and it returns the correct string using those servers. This application is running on tomcat 5.0.28 and what I would like to know is: is this a struts problem, a tomcat problem or my problem and if so does anyone have suggestions as to how to fix it? thanks for any help, Steve Bosman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Locked jar during Ant undeploy on Tomcat 5.5.3
Hi, I'm experiencing a similar problem, I read the Tomcat docs and this thread first before submitting. In my case, on freshly unzipped Tomcat versions 5.0.25, 5.0.28 and 5.5.4 the catalina ant task 'undeploy' encounters a locked jar-file situation. I suspect the jar-file is locked because the webapp's web.xml file specifies configuration files from that jar-file (n.b. for Spring context loading). The Tomcat production version I want to undeploy on is 5.0.25. Also, the logs indicated Tomcat tries to redeploy the webapp after executing the undeploy task : INFO: Server startup in 12359 ms 31-Mar-2005 17:07:37 org.apache.catalina.core.ContainerBase log INFO: Removing web application at context path /mywebapp 31-Mar-2005 17:07:46 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /mywebapp from URL file:C:\webservers\jakarta-tomcat-5.0.28\webapps\mywebapp 31-Mar-2005 17:07:46 org.apache.catalina.startup.ContextConfig applicationConfig INFO: Missing application web.xml, using defaults only StandardEngine[Catalina].StandardHost[localhost].StandardContext[/mywebapp] Various options seem open to me, I want to try this list first because I can imagine this problem is common and goes beyond simple configuration errors ... Kind regards, Q -Original Message- From: Derek Mahar [mailto:[EMAIL PROTECTED] Sent: 14 October 2004 20:15 To: tomcat-user@jakarta.apache.org Subject: Re: Locked jar during Ant undeploy on Tomcat 5.5.3 Thank you for pointing out these redundant attributes. I applied these changes to the context, but got the same results. If I have time, I'll put together a small application that demonstrates the problem and send that to you. If the issue is real, then I think there will be someone to provide a webapp. Yes, and that person's me! :) I just sent a test WAR that demonstrates the problem directly to your Gmail address. As I'm using Gmane, and Gmane does not allow attachments, I could not attach the WAR to this message. Derek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Authentication - Best practice
What's insecure about using a realm ? Security level is dependant on the realm type (e.g. jdbc/jndi can be used to), no ? -Original Message- From: Rajaneesh [mailto:[EMAIL PROTECTED] Sent: 12 January 2005 12:13 To: 'Tomcat Users List' Subject: RE: Authentication - Best practice Try http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html for Simple Authentication. Is there any reason why you are going to Realm specifically. If the application security is least of concern then it would be ok. Else it would be better to go for other security soln. Regards Rajaneesh -Original Message- From: VAN DER MARLIERE FREDERIC [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 12, 2005 4:34 PM To: tomcat-user@jakarta.apache.org Subject: Authentication - Best practice Hi all. For the web-application I'm developping, I need the user to authenticate himself. I read tomcat documentation and found the realms. My question is: are there best pratice on how to use realm? Thanks. Fred. Ce message et toutes les pieces jointes (ci-apres le message) sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite.Tout message electronique est susceptible d'alteration. Le CREDIT DU NORD et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. This message and any attachments ( the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited.E-mails are susceptible to alteration. Neither CREDIT DU NORD nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Authentication - Best practice
Ah ok, in that case I'm not worried ;-) The security level aimed for should be dependant on the application/client types of the company, there are a lot of (mostly small) companies who do not want more security then HTTP Basic authentication simply because none of the applications they develop need it. ps thank you for the link -Original Message- From: Rajaneesh [mailto:[EMAIL PROTECTED] Sent: 12 January 2005 12:29 To: 'Rajaneesh'; 'Tomcat Users List' Subject: RE: Authentication - Best practice Ok! I found the link... It is here. java.sun.com/developer/Books/certification/scwcd_9.pdf Regards Rajaneesh -Original Message- From: Rajaneesh [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 12, 2005 4:57 PM To: 'Tomcat Users List' Subject: RE: Authentication - Best practice Hi, It uses Base64 for sending the data. Heard that Base64 data is easily compramised compared to SSL. Please correct me if I am wrong. Regards Rajaneesh -Original Message- From: Quinten Verheyen [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 12, 2005 4:48 PM To: Tomcat Users List Subject: RE: Authentication - Best practice What's insecure about using a realm ? Security level is dependant on the realm type (e.g. jdbc/jndi can be used to), no ? -Original Message- From: Rajaneesh [mailto:[EMAIL PROTECTED] Sent: 12 January 2005 12:13 To: 'Tomcat Users List' Subject: RE: Authentication - Best practice Try http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html for Simple Authentication. Is there any reason why you are going to Realm specifically. If the application security is least of concern then it would be ok. Else it would be better to go for other security soln. Regards Rajaneesh -Original Message- From: VAN DER MARLIERE FREDERIC [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 12, 2005 4:34 PM To: tomcat-user@jakarta.apache.org Subject: Authentication - Best practice Hi all. For the web-application I'm developping, I need the user to authenticate himself. I read tomcat documentation and found the realms. My question is: are there best pratice on how to use realm? Thanks. Fred. Ce message et toutes les pieces jointes (ci-apres le message) sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite.Tout message electronique est susceptible d'alteration. Le CREDIT DU NORD et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. This message and any attachments ( the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited.E-mails are susceptible to alteration. Neither CREDIT DU NORD nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
char encoding bug in tomcat 5.0.25 ?
Hi, *maybe* I'm experiencing a bug in Tomcat 5.0.25, but this is pure
assumption, please help me with this troublesome character encoding problem.
The test page below gets a request parameter and shows it in a textarea. The
goal is to test if special characters are translated wrongly .. (would actually
occur if encoding/decoding set isn't the same). The problem is in Tomcat 5.0.25
the character 'é' is translated into é, in Tomcat 4.1.29 it stays the same.
Note: when providing the paramter as a get, it works.
test.jsp
%@ page pageEncoding=utf-8 language=java %
%
request.setCharacterEncoding(utf-8);
String text = request.getParameter(text);
if (text == null) {
text = ;
}
%
html
head
meta http-equiv=Content-Type content=text/html; charset=utf-8
titletest page/title
/head
body
FORM name=test method=POST
textarea name=text%=text%/textarea
input type=submit /
/form
/body
/html
Thx in advance,
Quinten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: char encoding bug in tomcat 5.0.25 ?
I tried that option already, doesn't make a difference ..
%@ page pageEncoding=utf-8 contentType=text/html; charset=UTF-8
language=java %
or
%@ page pageEncoding=utf-8 language=java %
%@ page contentType=text/html; charset=UTF-8 %
Q
-Original Message-
From: Allistair Crossley [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 10:03
To: Tomcat Users List
Subject: RE: char encoding bug in tomcat 5.0.25 ?
you-re missing a page directive
%@ page contentType=text/html; charset=UTF-8 %
-Original Message-
From: Quinten Verheyen [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 08:28
To: Tomcat Users List (E-mail)
Subject: char encoding bug in tomcat 5.0.25 ?
Hi, *maybe* I'm experiencing a bug in Tomcat 5.0.25, but this
is pure assumption, please help me with this troublesome
character encoding problem.
The test page below gets a request parameter and shows it in
a textarea. The goal is to test if special characters are
translated wrongly .. (would actually occur if
encoding/decoding set isn't the same). The problem is in
Tomcat 5.0.25 the character 'é' is translated into é, in
Tomcat 4.1.29 it stays the same.
Note: when providing the paramter as a get, it works.
test.jsp
%@ page pageEncoding=utf-8 language=java %
%
request.setCharacterEncoding(utf-8);
String text = request.getParameter(text);
if (text == null) {
text = ;
}
%
html
head
meta http-equiv=Content-Type content=text/html; charset=utf-8
titletest page/title
/head
body
FORM name=test method=POST
textarea name=text%=text%/textarea
input type=submit /
/form
/body
/html
Thx in advance,
Quinten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE
---
QAS Ltd.
Developers of QuickAddress Software
a href=http://www.qas.com;www.qas.com/a
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---
/FONT
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: char encoding bug in tomcat 5.0.25 ?
It was me who posted that :)
I looked into the example servlet filter you gave me, in the end it just calls
request.setCharacterEncoding(String) .. why would that call be applied to form
post data and the one in the JSP not ?
Q
-Original Message-
From: Allistair Crossley [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 10:48
To: Tomcat Users List
Subject: RE: char encoding bug in tomcat 5.0.25 ?
oh yes sorry, it's because you need to set request encoding
on your form post. use a servlet filter. there was a post
within the past week where I posted the full code of such a filter.
-Original Message-
From: Quinten Verheyen [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 09:16
To: Tomcat Users List
Subject: RE: char encoding bug in tomcat 5.0.25 ?
I tried that option already, doesn't make a difference ..
%@ page pageEncoding=utf-8 contentType=text/html;
charset=UTF-8 language=java %
or
%@ page pageEncoding=utf-8 language=java %
%@ page contentType=text/html; charset=UTF-8 %
Q
-Original Message-
From: Allistair Crossley [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 10:03
To: Tomcat Users List
Subject: RE: char encoding bug in tomcat 5.0.25 ?
you-re missing a page directive
%@ page contentType=text/html; charset=UTF-8 %
-Original Message-
From: Quinten Verheyen [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 08:28
To: Tomcat Users List (E-mail)
Subject: char encoding bug in tomcat 5.0.25 ?
Hi, *maybe* I'm experiencing a bug in Tomcat 5.0.25, but this
is pure assumption, please help me with this troublesome
character encoding problem.
The test page below gets a request parameter and shows it in
a textarea. The goal is to test if special characters are
translated wrongly .. (would actually occur if
encoding/decoding set isn't the same). The problem is in
Tomcat 5.0.25 the character 'é' is translated into é, in
Tomcat 4.1.29 it stays the same.
Note: when providing the paramter as a get, it works.
test.jsp
%@ page pageEncoding=utf-8 language=java %
%
request.setCharacterEncoding(utf-8);
String text = request.getParameter(text);
if (text == null) {
text = ;
}
%
html
head
meta http-equiv=Content-Type content=text/html;
charset=utf-8
titletest page/title
/head
body
FORM name=test method=POST
textarea name=text%=text%/textarea
input type=submit /
/form
/body
/html
Thx in advance,
Quinten
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE
---
QAS Ltd.
Developers of QuickAddress Software
a href=http://www.qas.com;www.qas.com/a
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---
/FONT
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: char encoding bug in tomcat 5.0.25 ?
Well, I tested the page on the following tomcat versions :
4.1.29 : OK
4.1.31 : OK
5.0.25 : NOK
5.0.28 : OK
5.5.4 with compt. : OK
So it seems a tomcat bug, if someone could confirm this ?
I am currently looking in tomcat bugzilla for this ...
Q
-Original Message-
From: Quinten Verheyen
Sent: 15 December 2004 11:35
To: Tomcat Users List
Subject: RE: char encoding bug in tomcat 5.0.25 ?
It was me who posted that :)
I looked into the example servlet filter you gave me, in the
end it just calls request.setCharacterEncoding(String) .. why
would that call be applied to form post data and the one in
the JSP not ?
Q
-Original Message-
From: Allistair Crossley [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 10:48
To: Tomcat Users List
Subject: RE: char encoding bug in tomcat 5.0.25 ?
oh yes sorry, it's because you need to set request encoding
on your form post. use a servlet filter. there was a post
within the past week where I posted the full code of such a filter.
-Original Message-
From: Quinten Verheyen [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 09:16
To: Tomcat Users List
Subject: RE: char encoding bug in tomcat 5.0.25 ?
I tried that option already, doesn't make a difference ..
%@ page pageEncoding=utf-8 contentType=text/html;
charset=UTF-8 language=java %
or
%@ page pageEncoding=utf-8 language=java %
%@ page contentType=text/html; charset=UTF-8 %
Q
-Original Message-
From: Allistair Crossley [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 10:03
To: Tomcat Users List
Subject: RE: char encoding bug in tomcat 5.0.25 ?
you-re missing a page directive
%@ page contentType=text/html; charset=UTF-8 %
-Original Message-
From: Quinten Verheyen [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 08:28
To: Tomcat Users List (E-mail)
Subject: char encoding bug in tomcat 5.0.25 ?
Hi, *maybe* I'm experiencing a bug in Tomcat 5.0.25, but this
is pure assumption, please help me with this troublesome
character encoding problem.
The test page below gets a request parameter and shows it in
a textarea. The goal is to test if special characters are
translated wrongly .. (would actually occur if
encoding/decoding set isn't the same). The problem is in
Tomcat 5.0.25 the character 'é' is translated into é, in
Tomcat 4.1.29 it stays the same.
Note: when providing the paramter as a get, it works.
test.jsp
%@ page pageEncoding=utf-8 language=java %
%
request.setCharacterEncoding(utf-8);
String text = request.getParameter(text);
if (text == null) {
text = ;
}
%
html
head
meta http-equiv=Content-Type content=text/html;
charset=utf-8
titletest page/title
/head
body
FORM name=test method=POST
textarea name=text%=text%/textarea
input type=submit /
/form
/body
/html
Thx in advance,
Quinten
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE
---
QAS Ltd.
Developers of QuickAddress Software
a href=http://www.qas.com;www.qas.com/a
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---
/FONT
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: char encoding bug in tomcat 5.0.25 ?
Aha, this explains a lot. I know what to do, one final thing for me before changing to 5.0.28 is testing the servlet filter option on 5.0.25. Thx. -Original Message- From: Allistair Crossley [mailto:[EMAIL PROTECTED] Sent: 15 December 2004 13:11 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? Your code is calling request.setChar... sure, but then the request ends when the page is finished displaying. Clicking your form submit generates a NEW request which has nothing to do with the previous request.setChar.. call. There is loads of character encoding information in the JSP Specification ... here is some stuff .. When you post a form, the request encoding is applied to the request The request character encoding is the character encoding in which parameters in an incoming request are interpreted. It is primarily managed as the ServletRequest object's characterEncoding property. The JSP specification doesn't provide functionality to handle the request character encoding directly. To control the request character encoding from JSP pages without embedded Java code, the JSTL fmt:requestEncoding can be used. (or use a servlet-filter). When you get data from a response The response character encoding is the character encoding of the response generated from a JSP page, if that response is in the form of text. It is primarily managed as the javax.servlet.ServletResponse object's characterEncoding property. The JSP container determines an initial response character encoding along with the initial content type for a JSP page and calls ServletResponse.setContent- Type() with this information before processing the page. JSP pages can set initial content type and initial response character encoding using the contentType attribute of the page directive. The initial response content type is set to the TYPE value of the contentType attribute of the page directive. If the page doesn't provide this attribute, the initial content type is text/html for JSP pages in standard syntax and text/xml for JSP documents in XML syntax. The initial response character encoding is set to the CHARSET value of the contentType attribute of the page directive. If the page doesn't provide this attribute or the attribute doesn't have a CHARSET value, the initial response character encoding is determined as follows: * For documents in XML syntax, it is UTF-8. * For JSP pages in standard syntax, it is the character encoding specified by the pageEncoding attribute of the page directive or by a JSP configuration element page-encoding whose URL pattern matches the page. Only the character encoding specified for the requested page is used; the encodings of files included via the include directive are not taken into consideration. If there's no such specification, no initial response character encoding is passed to ServletResponse. setContentType() - the ServletResponse object's default, ISO-8859-1, is used. -Original Message- From: Quinten Verheyen [mailto:[EMAIL PROTECTED] Sent: 15 December 2004 11:44 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? Well, I tested the page on the following tomcat versions : 4.1.29 : OK 4.1.31 : OK 5.0.25 : NOK 5.0.28 : OK 5.5.4 with compt. : OK So it seems a tomcat bug, if someone could confirm this ? I am currently looking in tomcat bugzilla for this ... Q -Original Message- From: Quinten Verheyen Sent: 15 December 2004 11:35 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? It was me who posted that :) I looked into the example servlet filter you gave me, in the end it just calls request.setCharacterEncoding(String) .. why would that call be applied to form post data and the one in the JSP not ? Q -Original Message- From: Allistair Crossley [mailto:[EMAIL PROTECTED] Sent: 15 December 2004 10:48 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? oh yes sorry, it's because you need to set request encoding on your form post. use a servlet filter. there was a post within the past week where I posted the full code of such a filter. -Original Message- From: Quinten Verheyen [mailto:[EMAIL PROTECTED] Sent: 15 December 2004 09:16 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? I tried that option already, doesn't make a difference .. %@ page pageEncoding=utf-8 contentType=text/html; charset=UTF-8 language=java % or %@ page pageEncoding=utf-8 language=java % %@ page contentType=text/html; charset=UTF-8 % Q -Original Message- From: Allistair Crossley [mailto:[EMAIL PROTECTED] Sent: 15
RE: char encoding bug in tomcat 5.0.25 ?
and it does btw ;-) -Original Message- From: Quinten Verheyen Sent: 15 December 2004 13:53 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? Aha, this explains a lot. I know what to do, one final thing for me before changing to 5.0.28 is testing the servlet filter option on 5.0.25. Thx. -Original Message- From: Allistair Crossley [mailto:[EMAIL PROTECTED] Sent: 15 December 2004 13:11 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? Your code is calling request.setChar... sure, but then the request ends when the page is finished displaying. Clicking your form submit generates a NEW request which has nothing to do with the previous request.setChar.. call. There is loads of character encoding information in the JSP Specification ... here is some stuff .. When you post a form, the request encoding is applied to the request The request character encoding is the character encoding in which parameters in an incoming request are interpreted. It is primarily managed as the ServletRequest object's characterEncoding property. The JSP specification doesn't provide functionality to handle the request character encoding directly. To control the request character encoding from JSP pages without embedded Java code, the JSTL fmt:requestEncoding can be used. (or use a servlet-filter). When you get data from a response The response character encoding is the character encoding of the response generated from a JSP page, if that response is in the form of text. It is primarily managed as the javax.servlet.ServletResponse object's characterEncoding property. The JSP container determines an initial response character encoding along with the initial content type for a JSP page and calls ServletResponse.setContent- Type() with this information before processing the page. JSP pages can set initial content type and initial response character encoding using the contentType attribute of the page directive. The initial response content type is set to the TYPE value of the contentType attribute of the page directive. If the page doesn't provide this attribute, the initial content type is text/html for JSP pages in standard syntax and text/xml for JSP documents in XML syntax. The initial response character encoding is set to the CHARSET value of the contentType attribute of the page directive. If the page doesn't provide this attribute or the attribute doesn't have a CHARSET value, the initial response character encoding is determined as follows: * For documents in XML syntax, it is UTF-8. * For JSP pages in standard syntax, it is the character encoding specified by the pageEncoding attribute of the page directive or by a JSP configuration element page-encoding whose URL pattern matches the page. Only the character encoding specified for the requested page is used; the encodings of files included via the include directive are not taken into consideration. If there's no such specification, no initial response character encoding is passed to ServletResponse. setContentType() - the ServletResponse object's default, ISO-8859-1, is used. -Original Message- From: Quinten Verheyen [mailto:[EMAIL PROTECTED] Sent: 15 December 2004 11:44 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? Well, I tested the page on the following tomcat versions : 4.1.29 : OK 4.1.31 : OK 5.0.25 : NOK 5.0.28 : OK 5.5.4 with compt. : OK So it seems a tomcat bug, if someone could confirm this ? I am currently looking in tomcat bugzilla for this ... Q -Original Message- From: Quinten Verheyen Sent: 15 December 2004 11:35 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? It was me who posted that :) I looked into the example servlet filter you gave me, in the end it just calls request.setCharacterEncoding(String) .. why would that call be applied to form post data and the one in the JSP not ? Q -Original Message- From: Allistair Crossley [mailto:[EMAIL PROTECTED] Sent: 15 December 2004 10:48 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? oh yes sorry, it's because you need to set request encoding on your form post. use a servlet filter. there was a post within the past week where I posted the full code of such a filter. -Original Message- From: Quinten Verheyen [mailto:[EMAIL PROTECTED] Sent: 15 December 2004 09:16 To: Tomcat Users List Subject: RE: char encoding bug in tomcat 5.0.25 ? I tried that option already, doesn't make a difference
RE: setting encoding scheme POST data via container
;
this.filterConfig = null;
}
/**
* Select and set (if specified) the character encoding
to be used to
* interpret request parameters for this request.
*
* @param request The servlet request we are processing
* @param result The servlet response we are creating
* @param chain The filter chain we are processing
*
* @exception IOException if an input/output error occurs
* @exception ServletException if a servlet error occurs
*/
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
// Select and set (if needed) the character encoding
to be used
String encoding = selectEncoding(request);
if (encoding != null)
request.setCharacterEncoding(encoding);
// Pass control on to the next filter
chain.doFilter(request, response);
}
/**
* Place this filter into service.
*
* @param filterConfig The filter configuration object
*/
public void init(FilterConfig filterConfig) throws
ServletException {
this.filterConfig = filterConfig;
this.encoding = filterConfig.getInitParameter(encoding);
}
// --
Protected Methods
/**
* Select an appropriate character encoding to be used,
based on the
* characteristics of the current request and/or filter
initialization
* parameters. If no character encoding should be set, return
* codenull/code.
* p
* The default implementation unconditionally returns the
value configured
* by the strongencoding/strong initialization
parameter for this
* filter.
*
* @param request The servlet request we are processing
*/
protected String selectEncoding(ServletRequest request) {
return (this.encoding);
}
}
-Original Message-
From: Quinten Verheyen [mailto:[EMAIL PROTECTED]
Sent: 14 December 2004 10:34
To: Tomcat Users List
Subject: setting encoding scheme POST data via container
Hi, is there a way to specify the encoding character scheme
used for form POST data on the container level ?
On a JSP level, this is done like this :
FORM name=test method=POST
encType=application/x-www-form-urlencoded; charset=UTF-8
accept-charset=UTF-8../FORM
ps I use Tomcat 5.0.25 on Windows 2000 ..
Thx in advance,
Q
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE
---
QAS Ltd.
Developers of QuickAddress Software
a href=http://www.qas.com;www.qas.com/a
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---
/FONT
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
setting encoding scheme POST data via container
Hi, is there a way to specify the encoding character scheme used for form POST data on the container level ? On a JSP level, this is done like this : FORM name=test method=POST encType=application/x-www-form-urlencoded; charset=UTF-8 accept-charset=UTF-8../FORM ps I use Tomcat 5.0.25 on Windows 2000 .. Thx in advance, Q - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
automated (un)deployment
Hi, in tomcat 4.1.29, what is the best approach to replace a deployed war (wich is expanded) via the manager webapp ? Also, what's the best choice between 1) automated deployment settings via the host element e.g. 'liveDeploy' or 2) the manager webapp deploy/install functions ? Kind regards, Quinten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: is reloading the web context sufficient ?
What version of Tomcat are you referring to? Tomcat 4.1.x or Tomcat 5.0.x? Tomcat 5.0.25 to be exact ;) -Original Message- From: David Rees [mailto:[EMAIL PROTECTED] Sent: 07 September 2004 21:48 To: Tomcat Users List Subject: Re: FW: is reloading the web context sufficient ? Quinten Verheyen wrote: I would simply like to know how on-going HTTP traffic is handled when the classes get reloaded, either by the reloadable attribute in the context or by the Manager webapp reload function. What version of Tomcat are you referring to? Tomcat 4.1.x or Tomcat 5.0.x? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: basic authentification with IIS (tomcat 5.x) [FOUND]
Hi Philippe, are you absolutely forced to use IIS and Tomcat together or do you have a choice ? -Original Message- From: Philippe Lonchampt [mailto:[EMAIL PROTECTED] Sent: 07 September 2004 22:32 To: [EMAIL PROTECTED] Subject: Re: basic authentification with IIS (tomcat 5.x) [FOUND] I've found : have to disable windows athentication in security in IIS. - Original Message - From: Philippe Lonchampt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 06, 2004 9:20 PM Subject: basic authentification with IIS (tomcat 5.x) Hello all, I don't understand how to use the tomcat 5.x basic authentification with IIS (ajp13) : it works when using tomcat alone, but with IIS the answer is always 401.1 Not authorized. It seems like IIS don't let Tomcat manage the authentification ? I've read somewhere in this list that it has to do with the ajp.jar library, but I don't understand what to do with it, the topic is not clear for me. I have done all the tomcat conf in the right way (web.xml, server.xml and tomcat-users.xml) since it works with tomcat alone. Thanks in advance. Philippe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
is reloading the web context sufficient ?
Hi, I'm wondering about strategies for having a production (Tomcat) webserver that hosts a lot of applications (in one web context) and needs to be running 24/7. The main issue is not to lose any traffic coming in/out. Is reloading a web context via the manager app for every change made to class-files, lib's etc. a good option ? I mean, does this have any implications on internet traffic getting lost at the moment the reload occurs ? The same reasoning would apply for deploying/undeploying through the admin webapp. My guess is that the safe way is handling this through clustering (DNS round robin), and having 2 tomcat containers running with the same web context, but only one of them would be accessed at a time. Fill me in if I'm wrong. Quinten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: is reloading the web context sufficient ?
Yes, you are right, it's confusing the way I said it. What I meant was : one web context that contains a lot of custom class-files. Normally, I would agree with you that each application should have it's own context, but there are some reasons why this approach isn't taken : 1) the system we work with expects only one specific web context to be used 2) every application uses common functionality + configuration setup anyway (e.g. database config) 3) I'm talking about hundred's of mostly small applications, imho confuring a separate web context for each would be overkill. Of course, the advantage of having a separate context for each app would be the total non-intrusion when reloading a specific context :s -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 07 September 2004 15:10 To: Tomcat Users List Subject: RE: is reloading the web context sufficient ? Hi, In the Tomcat world, one web application = one web context. So please clarify what you mean by a lot of applications (in one web context). Yoav Shapira Millennium Research Informatics -Original Message- From: Quinten Verheyen [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 07, 2004 6:15 AM To: Tomcat Users List Subject: is reloading the web context sufficient ? Hi, I'm wondering about strategies for having a production (Tomcat) webserver that hosts a lot of applications (in one web context) and needs to be running 24/7. The main issue is not to lose any traffic coming in/out. Is reloading a web context via the manager app for every change made to class-files, lib's etc. a good option ? I mean, does this have any implications on internet traffic getting lost at the moment the reload occurs ? The same reasoning would apply for deploying/undeploying through the admin webapp. My guess is that the safe way is handling this through clustering (DNS round robin), and having 2 tomcat containers running with the same web context, but only one of them would be accessed at a time. Fill me in if I'm wrong. Quinten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: is reloading the web context sufficient ?
To clarify and remove the confusion I'm making ;) webapp.root / WEB-INF / classes / [package] I would simply like to know how on-going HTTP traffic is handled when the classes get reloaded, either by the reloadable attribute in the context or by the Manager webapp reload function. Quinten -Original Message- From: Quinten Verheyen Sent: 07 September 2004 15:30 To: Tomcat Users List Subject: RE: is reloading the web context sufficient ? Yes, you are right, it's confusing the way I said it. What I meant was : one web context that contains a lot of custom class-files. Normally, I would agree with you that each application should have it's own context, but there are some reasons why this approach isn't taken : 1) the system we work with expects only one specific web context to be used 2) every application uses common functionality + configuration setup anyway (e.g. database config) 3) I'm talking about hundred's of mostly small applications, imho confuring a separate web context for each would be overkill. Of course, the advantage of having a separate context for each app would be the total non-intrusion when reloading a specific context :s -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 07 September 2004 15:10 To: Tomcat Users List Subject: RE: is reloading the web context sufficient ? Hi, In the Tomcat world, one web application = one web context. So please clarify what you mean by a lot of applications (in one web context). Yoav Shapira Millennium Research Informatics -Original Message- From: Quinten Verheyen [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 07, 2004 6:15 AM To: Tomcat Users List Subject: is reloading the web context sufficient ? Hi, I'm wondering about strategies for having a production (Tomcat) webserver that hosts a lot of applications (in one web context) and needs to be running 24/7. The main issue is not to lose any traffic coming in/out. Is reloading a web context via the manager app for every change made to class-files, lib's etc. a good option ? I mean, does this have any implications on internet traffic getting lost at the moment the reload occurs ? The same reasoning would apply for deploying/undeploying through the admin webapp. My guess is that the safe way is handling this through clustering (DNS round robin), and having 2 tomcat containers running with the same web context, but only one of them would be accessed at a time. Fill me in if I'm wrong. Quinten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: usage tomcat5w ?
Nobody who can explain this tomcat5w.exe or refer to documentation about it ? -Original Message- From: Quinten Verheyen Sent: 02 September 2004 19:23 To: Tomcat Users List Subject: RE: usage tomcat5w ? --- Unless the context's reloadable attr is set to true, Tomcat won't reload *any* classes until a context (re)start. --- The directory containing those classes isn't part of any web root context (where you could indeed set the 'reloadable' attribute, but that's not advised on production environments). The root is just given as a classpath param in the tomcat5w.exe program. So I assume it's part of the Tomcat ClassLoader because any new/updated class in that root gets picked up by the container without any reload/restart. I have to say I can't find much documentation about that tomcat5w.exe. --- Generally speaking, it's best for the long-term to follow the spec's and Tomcat's guidelines for where to put things. That simplifies upgrades and makes it easier to determine whether a problem lies in the container's code or yours. That said, there are a million ways to run a shop, half of which are right. Sometimes it's necessary to deviate from the norm. --- I personally don't see any reason to deviate from the tomcat dev standard convention, in this case I guess it's done to avoid container restart. But that's a pretty weak argument if one can deploy/undeploy webapps remotely through the manager app, don't you think ? Thanks for the feedback btw, Quinten -Original Message- From: QM [mailto:[EMAIL PROTECTED] Sent: 02 September 2004 19:03 To: Tomcat Users List Subject: Re: usage tomcat5w ? On Thu, Sep 02, 2004 at 03:44:52PM +0200, Quinten Verheyen wrote: : we have Tomcat 5 installed and there is something that troubles me. : Some guys have modified the classpath via the tomcat5w.exe (Java tab) and put : all their applications in a directory outside of tomcat. It isn't even a web : root, just a root for class files. : They did this so they don't have to restart Tomcat for every class change and : to put their application class files anywhere they want. Unless the context's reloadable attr is set to true, Tomcat won't reload *any* classes until a context (re)start. : This bugs me. They just change the classpath known by Tomcat at startup (like : bootstrap) but isn't this against all design logic ? Generally speaking, it's best for the long-term to follow the spec's and Tomcat's guidelines for where to put things. That simplifies upgrades and makes it easier to determine whether a problem lies in the container's code or yours. That said, there are a million ways to run a shop, half of which are right. Sometimes it's necessary to deviate from the norm. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: usage tomcat5w ?
--- Of course those are not dynamic changes and can not be used for serious 24x7 servers --- Indeed, but the thing is ... they ARE used for serious 24x7 servers. They thought something like this : 1) application logic does not really need web functionalities 2) so we don't use a web context and put all classes in the tomcat CP And everybody was happy. The reason why they actually use a tomcat container is because they want easy interaction with other (tomcat) webservers on other machines. There are 2 ways I see here : - either follow their approach - or use a web context in combination with a well-secured manager webapp I'm still doubting :) -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: 03 September 2004 09:44 To: Tomcat Users List Subject: Re: usage tomcat5w ? Quinten Verheyen wrote: Nobody who can explain this tomcat5w.exe or refer to documentation about it ? Well, your question was too political :). How will someone configure the Tomcat really has nothing to do with tomcat5w. Exactly the same can be done manually editing the registry, customizing batch scripts, etc... Of course those are not dynamic changes and can not be used for serious 24x7 servers. Regards, MT. : This bugs me. They just change the classpath known by Tomcat at startup (like : bootstrap) but isn't this against all design logic ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: usage tomcat5w ?
--- Still, what this has to do with the tomcat5w.exe? It's a GUI service config helper, and you a talking about webserver implementation strategies. --- The fact that their approach uses that GUI to modify the tomcat classpath (wich has an impact on implementation strategy) led me to wanting to know more about the good/bad things of such an approach, that's all. -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: 03 September 2004 10:24 To: Tomcat Users List Subject: Re: usage tomcat5w ? Quinten Verheyen wrote: --- Of course those are not dynamic changes and can not be used for serious 24x7 servers --- Indeed, but the thing is ... they ARE used for serious 24x7 servers. Still, what this has to do with the tomcat5w.exe? It's a GUI service config helper, and you a talking about webserver implementation strategies. Regards, MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
usage tomcat5w ?
Hi, we have Tomcat 5 installed and there is something that troubles me. Some guys have modified the classpath via the tomcat5w.exe (Java tab) and put all their applications in a directory outside of tomcat. It isn't even a web root, just a root for class files. They did this so they don't have to restart Tomcat for every class change and to put their application class files anywhere they want. This bugs me. They just change the classpath known by Tomcat at startup (like bootstrap) but isn't this against all design logic ? It's nice not to have to restart Tomcat (production webserver needs to run 24/24), but one can accomplish that with the admin/manager applications also (assuming it's secure enough). Or this not done or is it ? Regards, Verheyen Quinten Software Engineer Rue Gabrielle Petitstraat 4/6 1080 Brussel Tel : +0032 (0)2 502 85 00 Fax : +0032 (0)2 502 76 07 Gsm : +0032 (0)494 81 04 81 E-mail : mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] The process of intelligent conduct is essentially a process of selection from among various alternatives; intelligence is largely a matter of selectivity. Delayed reaction is necessary to intelligent contact. - Mead G.H.
RE: usage tomcat5w ?
--- Unless the context's reloadable attr is set to true, Tomcat won't reload *any* classes until a context (re)start. --- The directory containing those classes isn't part of any web root context (where you could indeed set the 'reloadable' attribute, but that's not advised on production environments). The root is just given as a classpath param in the tomcat5w.exe program. So I assume it's part of the Tomcat ClassLoader because any new/updated class in that root gets picked up by the container without any reload/restart. I have to say I can't find much documentation about that tomcat5w.exe. --- Generally speaking, it's best for the long-term to follow the spec's and Tomcat's guidelines for where to put things. That simplifies upgrades and makes it easier to determine whether a problem lies in the container's code or yours. That said, there are a million ways to run a shop, half of which are right. Sometimes it's necessary to deviate from the norm. --- I personally don't see any reason to deviate from the tomcat dev standard convention, in this case I guess it's done to avoid container restart. But that's a pretty weak argument if one can deploy/undeploy webapps remotely through the manager app, don't you think ? Thanks for the feedback btw, Quinten -Original Message- From: QM [mailto:[EMAIL PROTECTED] Sent: 02 September 2004 19:03 To: Tomcat Users List Subject: Re: usage tomcat5w ? On Thu, Sep 02, 2004 at 03:44:52PM +0200, Quinten Verheyen wrote: : we have Tomcat 5 installed and there is something that troubles me. : Some guys have modified the classpath via the tomcat5w.exe (Java tab) and put : all their applications in a directory outside of tomcat. It isn't even a web : root, just a root for class files. : They did this so they don't have to restart Tomcat for every class change and : to put their application class files anywhere they want. Unless the context's reloadable attr is set to true, Tomcat won't reload *any* classes until a context (re)start. : This bugs me. They just change the classpath known by Tomcat at startup (like : bootstrap) but isn't this against all design logic ? Generally speaking, it's best for the long-term to follow the spec's and Tomcat's guidelines for where to put things. That simplifies upgrades and makes it easier to determine whether a problem lies in the container's code or yours. That said, there are a million ways to run a shop, half of which are right. Sometimes it's necessary to deviate from the norm. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: usage tomcat5w ?
Hi Mandar, take a look at http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html. Quinten -Original Message- From: Mandar Shirgaokar [mailto:[EMAIL PROTECTED] Sent: 02 September 2004 19:29 To: Tomcat Users List Subject: RE: usage tomcat5w ? hi, Where and how do I set the context's reloadable attr to true so that Tomcat reloads *any* classes until a context (re)start. Please me in this issue, Thanks, Sincerely, Mandar Quinten Verheyen [EMAIL PROTECTED] wrote: --- Unless the context's reloadable attr is set to true, Tomcat won't reload *any* classes until a context (re)start. --- The directory containing those classes isn't part of any web root context (where you could indeed set the 'reloadable' attribute, but that's not advised on production environments). The root is just given as a classpath param in the tomcat5w.exe program. So I assume it's part of the Tomcat ClassLoader because any new/updated class in that root gets picked up by the container without any reload/restart. I have to say I can't find much documentation about that tomcat5w.exe. --- Generally speaking, it's best for the long-term to follow the spec's and Tomcat's guidelines for where to put things. That simplifies upgrades and makes it easier to determine whether a problem lies in the container's code or yours. That said, there are a million ways to run a shop, half of which are right. Sometimes it's necessary to deviate from the norm. --- I personally don't see any reason to deviate from the tomcat dev standard convention, in this case I guess it's done to avoid container restart. But that's a pretty weak argument if one can deploy/undeploy webapps remotely through the manager app, don't you think ? Thanks for the feedback btw, Quinten -Original Message- From: QM [mailto:[EMAIL PROTECTED] Sent: 02 September 2004 19:03 To: Tomcat Users List Subject: Re: usage tomcat5w ? On Thu, Sep 02, 2004 at 03:44:52PM +0200, Quinten Verheyen wrote: : we have Tomcat 5 installed and there is something that troubles me. : Some guys have modified the classpath via the tomcat5w.exe (Java tab) and put : all their applications in a directory outside of tomcat. It isn't even a web : root, just a root for class files. : They did this so they don't have to restart Tomcat for every class change and : to put their application class files anywhere they want. Unless the context's reloadable attr is set to true, Tomcat won't reload *any* classes until a context (re)start. : This bugs me. They just change the classpath known by Tomcat at startup (like : bootstrap) but isn't this against all design logic ? Generally speaking, it's best for the long-term to follow the spec's and Tomcat's guidelines for where to put things. That simplifies upgrades and makes it easier to determine whether a problem lies in the container's code or yours. That said, there are a million ways to run a shop, half of which are right. Sometimes it's necessary to deviate from the norm. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat manager reload, start and stop functionality
Thank you David for the info. I use Tomcat 4.1.29, and I have 2 servers running so in case of a start/stop clustering will definitely be a go .. Regards, Quinten -Original Message- From: David Rees [mailto:[EMAIL PROTECTED] Sent: 26 January 2004 23:03 To: Tomcat Users List Subject: Re: Tomcat manager reload, start and stop functionality On Mon, January 26, 2004 1at 2:54 am, Quinten Verheyen wrote: I have a question about some tasks of the manager app of Tomcat. * The Reload-task doesn't stop and start the webapp, but I wonder how it exactly works. Because when I am transferring a new jar-file on the server and a Reload is run on the context, I need to know how this can affect the HTTP requests entering that context at that exact moment the reload is running. I know we are talking about less than a sec. here in most cases, but imagine thousands and thousands of SMS messages coming in via HTTP requests to that context. How is this handled ? With timeout and try again ? Please explain this if someone would be so kind .. * The second question involves the same matter, but with the stop and start task. The context is not active after running the stop (only for a very short time but still) so any HTTP request will fail (I guess a 404 or something). Is there a way to work around this ? Some kind of delay option or something.. to tell that any HTTP request is put into a pool and then run again on the context when it is active (after the start). Or are there better ways to assure nothing gets lost .. (ps of course using jsp's ensures not needing the start and stop, but suppose we're using servlets). What version of Tomcat are you talking about? TC 4.1.X handles reloads without dropping any requests, any new requests that come in during the reload will wait until the context is finished reloading. TC 5.0.X replaces the reload function in TC 4 with a stop/start, so it behaves as you've described in your second scenario above. To work around this, you will need to cluster multiple Tomcat instances (at least two). When it is time to reload a context in one TC instance, you will need to configure your load balancer to stop sending requests to that instance, restart that instance, and then reconfigure your load balancer again to resume sending requests to the TC instance. You will need to repeat for each TC instance. This can be done using Apache/mod_jk as the load balancer. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat manager reload, start and stop functionality
Hi, I have a question about some tasks of the manager app of Tomcat. * The Reload-task doesn't stop and start the webapp, but I wonder how it exactly works. Because when I am transferring a new jar-file on the server and a Reload is run on the context, I need to know how this can affect the HTTP requests entering that context at that exact moment the reload is running. I know we are talking about less than a sec. here in most cases, but imagine thousands and thousands of SMS messages coming in via HTTP requests to that context. How is this handled ? With timeout and try again ? Please explain this if someone would be so kind .. * The second question involves the same matter, but with the stop and start task. The context is not active after running the stop (only for a very short time but still) so any HTTP request will fail (I guess a 404 or something). Is there a way to work around this ? Some kind of delay option or something.. to tell that any HTTP request is put into a pool and then run again on the context when it is active (after the start). Or are there better ways to assure nothing gets lost .. (ps of course using jsp's ensures not needing the start and stop, but suppose we're using servlets). I looked it the tomcat docs, but there wasn't really an in-depth explanation about this .. Thx in advance :-) Verheyen Quinten Software Engineer Rue Gabrielle Petitstraat 4/6 1080 Brussel Tel : +0032 (0)2 502 85 00 Fax : +0032 (0)2 502 76 07 Gsm : +0032 (0)494 81 04 81 E-mail : mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] Politicians' Syllogism : step 1 : we must do something. step 2 : this is something. step 3 : therefore we must do it.
RE: Tomcat manager reload, start and stop functionality
nobody ? :-) -Original Message- From: Quinten Verheyen Sent: 26 January 2004 09:55 To: [EMAIL PROTECTED] Subject: Tomcat manager reload, start and stop functionality Hi, I have a question about some tasks of the manager app of Tomcat. * The Reload-task doesn't stop and start the webapp, but I wonder how it exactly works. Because when I am transferring a new jar-file on the server and a Reload is run on the context, I need to know how this can affect the HTTP requests entering that context at that exact moment the reload is running. I know we are talking about less than a sec. here in most cases, but imagine thousands and thousands of SMS messages coming in via HTTP requests to that context. How is this handled ? With timeout and try again ? Please explain this if someone would be so kind .. * The second question involves the same matter, but with the stop and start task. The context is not active after running the stop (only for a very short time but still) so any HTTP request will fail (I guess a 404 or something). Is there a way to work around this ? Some kind of delay option or something.. to tell that any HTTP request is put into a pool and then run again on the context when it is active (after the start). Or are there better ways to assure nothing gets lost .. (ps of course using jsp's ensures not needing the start and stop, but suppose we're using servlets). I looked it the tomcat docs, but there wasn't really an in-depth explanation about this .. Thx in advance :-) Verheyen Quinten Software Engineer Rue Gabrielle Petitstraat 4/6 1080 Brussel Tel : +0032 (0)2 502 85 00 Fax : +0032 (0)2 502 76 07 Gsm : +0032 (0)494 81 04 81 E-mail : mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] Politicians' Syllogism : step 1 : we must do something. step 2 : this is something. step 3 : therefore we must do it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
