Re: Generic Types support in Tomcat?
To be honest, I never tried it with 5.5.9 I just concluded it from the release notes and other posts on this mailing list. AFAIK, tomcat uses the Eclipse JDT compiler by default to compile JSPs. Maybe you have configured tomcat to use Suns javac? Bjørn T Johansen wrote: So how is this affecting the use of Tomcat 5.5.9? I am using Java 5 features with Tomcat 5.5.9 without any problems, so what do I need to do to discover Tomcat 5.5.9 shortcomings with respect to Java 5? Regards, BTJ Christoph Kutzinski wrote: What's what story? Java 5 features are not supported in latest tomcat stable (5.5.9), but are in the latest alphas (5.5.10-5.5.12) Just as I said in my previous mail. Seak, Teng-Fong wrote: I've received an announcement mail telling that 5.5.12 is in alpha phase! So what's this story? Actually, I'm more interested in using the new for loop in Java5 than using generic. Christoph Kutzinski wrote: Hi, it is only since 5.5.10 5.5.10 was already released, but it is only supposed to be alpha. I.e. not recommended for production use. I have no idea, when the next stable tomcat version will be released Christoph - 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: Generic Types support in Tomcat?
To be clear: You are using Java 5 features (generics, for-each loop etc.) in JSPs? Bjørn T Johansen wrote: Nope, I am just using the default installation and configurations... BTJ Christoph Kutzinski wrote: To be honest, I never tried it with 5.5.9 I just concluded it from the release notes and other posts on this mailing list. AFAIK, tomcat uses the Eclipse JDT compiler by default to compile JSPs. Maybe you have configured tomcat to use Suns javac? Bjørn T Johansen wrote: So how is this affecting the use of Tomcat 5.5.9? I am using Java 5 features with Tomcat 5.5.9 without any problems, so what do I need to do to discover Tomcat 5.5.9 shortcomings with respect to Java 5? Regards, BTJ Christoph Kutzinski wrote: What's what story? Java 5 features are not supported in latest tomcat stable (5.5.9), but are in the latest alphas (5.5.10-5.5.12) Just as I said in my previous mail. Seak, Teng-Fong wrote: I've received an announcement mail telling that 5.5.12 is in alpha phase! So what's this story? Actually, I'm more interested in using the new for loop in Java5 than using generic. Christoph Kutzinski wrote: Hi, it is only since 5.5.10 5.5.10 was already released, but it is only supposed to be alpha. I.e. not recommended for production use. I have no idea, when the next stable tomcat version will be released Christoph - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generic Types support in Tomcat?
You should start a new discussion thread. I cannot see how this is even remotely related to generic types and Tomcat. Santosh Asbe wrote: Hi all, A] I am using tomcat 4.1.30 ( 32 bit) with Apache 2.0.46 ( this is standard apache which comes with RHEL 3.0). I am currently using RHEL 32 bit without RAID confiuration. Now i am planning to move to 64 bit RHEL 3.0 with RAID configuration but he the new Apache of RHEL 3.0 and same tomcat 4.1.30 ( 32 bit). I am facing a problem with mod_jk. I feel it is 32 bit complied mod_jk. Can anyone help me with the solution B] Also my tomcat goes into hang state . So i have set an parameter LD_ASSUME_KERNEL=2.4.21. That is my Linux kernel version. Is this ok. where do i set this parameter. i have set it in the catalina.sh. C] Sometime when the tomcat is started it spwans more than one processes. And then during shudown it creates problems. Also sometimes the list of open files goes beyond 1024. that is he ulimit. due to which he tomcat doesnot respond. D] I am currently using 4.1.30 version of tomcat. Are there any fixes or upgrades for this tomcat. Can you inform me the link for the same. Thanks in advance. regards, Santosh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generic Types support in Tomcat?
What's what story? Java 5 features are not supported in latest tomcat stable (5.5.9), but are in the latest alphas (5.5.10-5.5.12) Just as I said in my previous mail. Seak, Teng-Fong wrote: I've received an announcement mail telling that 5.5.12 is in alpha phase! So what's this story? Actually, I'm more interested in using the new for loop in Java5 than using generic. Christoph Kutzinski wrote: Hi, it is only since 5.5.10 5.5.10 was already released, but it is only supposed to be alpha. I.e. not recommended for production use. I have no idea, when the next stable tomcat version will be released Christoph - 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: Generic Types support in Tomcat?
Hi, it is only since 5.5.10 5.5.10 was already released, but it is only supposed to be alpha. I.e. not recommended for production use. I have no idea, when the next stable tomcat version will be released Christoph Seak, Teng-Fong wrote: Well, after many many hours' search (seems like not a hot subject), I finally came to this mail archive. But before getting here, I've already come across a similar page at http://blog.taragana.com/index.php/archive/how-to-run-javac-15-or-beyond-compiler-for-jsp-compilation-in-tomcat-55-with-generics-enabled-and-other-15-only-features/2/ I've put all those JSP parameters in the web.xml and of course it didn't work (or else I wouldn't be here). This thread said it's for Tomcat 5.5.10 (ie, in the future) but that page just said it's for Tomcat 5.5, and then http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html only say it's for Tomcat 5.5 too. So, is it possible to use Java 5 syntax in JSP in Tomcat 5.5.9? TIA - 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: Problems with utf-8 encoding - continue
Jilles van Gurp wrote: Oracle on the other hand cannot insert strings larger than 4KB with setString so you need to use setCharacterStream. FYI: This is common knowledge that used to be right, but isn't anymore. With the Oracle 10g JDBC driver you can set arbitrary length strings with setString http://www.oracle.com/technology/sample_code/tech/java/codesnippet/jdbc/clob10g/handlingclobsinoraclejdbc10g.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat/jvm shutdown very slow after enabling JMX remote management...
You should only set the JMX JAVA_OPTS for startup. If you use the same JAVA_OPTS for shutdown, the shutdown-VM will unsuccessfully try to start a JMX server on port . That's what taking so long. Joe R. Lindsay wrote: If found an old post mentioning the same issue, but no resolution or others. My config is pretty vanilly except for setting the JMX options as part of the normal Tomcat startup (CATALINA_OPTS)... export CATALINA_OPTS=$CATALINA_OPTS -Dcom.sun.management.jmxremote.port= export CATALINA_OPTS=$CATALINA_OPTS -Dcom.sun.management.jmxremote.authenticate=false export CATALINA_OPTS=$CATALINA_OPTS -Dcom.sun.management.jmxremote.ssl=false Shutdown of tomcat takes a very long time when jmx is enabled, even if I use manager to shutdown the individual webapps. With jmx disabled, shutdown times are normalhas anyone else seen or resolved this? -Original Message- From: Paul ANDERSON [EMAIL PROTECTED] Subject: RE: Shutdown not working under SLES8 and FC2 Date: Mon, 21 Feb 2005 11:08:01 GMT Raw Message Prev Next Prev by Thread Next by Thread I have had the same problem of Tomcat not terminating and having to be killed by hand. It occurred with Tomcat 5.0.27, JDK1.4.2, RH Enterprise Linux 3 when I enabled JMX via jk2 configuration. I tried 5.0.28 but the same happened using jk2, so I put JMX on a back burner. Now I'm using 5.5.7, JDK1.4.2_06 and the same thing happens - but again, only when mx.enabled is true. Uname -a gives: 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686 i686 i386 GNU/Linux The problem seems to happen even with a clean distro - all it takes is for jk2.properties to be modified to start JMX support, with the MX jars in common/lib. Fortunately it happens every time on ./shutdown.sh so I hope someone can shed some light on it. I'd like to use JMX even without JDK1.5 - maybe using jsvc is a workaround. I don't want to force a process kill as normal procedure, in case some cleanup is skipped such as session persistence. Paul - 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: The process tomcat {pid 1488.0000 } is leaking handles
This Peregrine Get Answers application is probably leaking file handles. Ask their support. [EMAIL PROTECTED] wrote: We have a server running Peregrine Get Answers which use TOMCAT as part of its installation We are seeing (via task manager) a slow build up of handles for the tomcat app.. Has anyone come across this before? This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments.. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons.. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC.Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised and regulated by the Financial Services Authority. - 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: The process tomcat {pid 1488.0000 } is leaking handles
I think, I'm not quite getting it:
You (your organisation) bought Get Answers and Tomcat is used as a
part of it. I.e. Tomcat can be considered as part of Get Answers. Right?
Then Peregrine has the responsibility to fix any errors which occur in
this combination.
[EMAIL PROTECTED] wrote:
I have and they put it down to being the Tomcat application - not much use
at all!
On task manager it does indicate that tomcat is at fault..
-Original Message-
From: Christoph Kutzinski [mailto:[EMAIL PROTECTED]
Sent: 13 September 2005 11:40
To: Tomcat Users List
Subject: Re: The process tomcat {pid 1488. } is leaking handles
This Peregrine Get Answers application is probably leaking file
handles. Ask their support.
[EMAIL PROTECTED] wrote:
We have a server running Peregrine Get Answers which use TOMCAT as part of
its installation
We are seeing (via task manager) a slow build up of handles for the tomcat
app..
Has anyone come across this before?
This e-mail and any attachments are confidential and intended solely
for the addressee and may also be privileged or exempt from disclosure
under applicable law. If you are not the addressee, or have received
this e-mail in error, please notify the sender immediately, delete it
from your system and do not copy, disclose or otherwise act upon any
part of this e-mail or its attachments..
Internet communications are not guaranteed to be secure or virus-free.
The Barclays Group does not accept responsibility for any loss arising
from unauthorised access to, or interference with, any Internet
communications by any third party, or from the transmission of any
viruses. Replies to this e-mail may be monitored by the Barclays
Group for operational or business reasons..
Any opinion or other information in this e-mail or its attachments
that does not relate to the business of the Barclays Group is personal
to the sender and is not given or endorsed by the Barclays Group.
Barclays Bank PLC.Registered in England and Wales (registered no.
1026167).
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom.
Barclays Bank PLC is authorised and regulated by the Financial Services
Authority.
-
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]
This e-mail and any attachments are confidential and intended solely
for the addressee and may also be privileged or exempt from disclosure
under applicable law. If you are not the addressee, or have received
this e-mail in error, please notify the sender immediately, delete it
from your system and do not copy, disclose or otherwise act upon any
part of this e-mail or its attachments..
Internet communications are not guaranteed to be secure or virus-free.
The Barclays Group does not accept responsibility for any loss arising
from unauthorised access to, or interference with, any Internet
communications by any third party, or from the transmission of any
viruses. Replies to this e-mail may be monitored by the Barclays
Group for operational or business reasons..
Any opinion or other information in this e-mail or its attachments
that does not relate to the business of the Barclays Group is personal
to the sender and is not given or endorsed by the Barclays Group.
Barclays Bank PLC.Registered in England and Wales (registered no. 1026167).
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom.
Barclays Bank PLC is authorised and regulated by the Financial Services
Authority.
-
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: The process tomcat {pid 1488.0000 } is leaking handles
I could think of quite a number of reasons, why handle are leaked.
Without further knowing the application I could only guess.
Since Tomcat is widely used and I haven't heard of handles leaked by
tomcat (itself) here on the list, I would strongly suspect the Get
Answers application as the source of the problem.
Most of the time not tomcat is the problem, but the web-application
deployed to tomcat.
[EMAIL PROTECTED] wrote:
You are quite getting it. Im pushing it back onto Peregrine as they should
be looking into it but in the mean time i thought id pose the question on
this forum...speaking to my server support area - they have seen the same
problem on other servers running tomcat
-Original Message-
From: Christoph Kutzinski [mailto:[EMAIL PROTECTED]
Sent: 13 September 2005 12:14
To: Tomcat Users List
Subject: Re: The process tomcat {pid 1488. } is leaking handles
I think, I'm not quite getting it:
You (your organisation) bought Get Answers and Tomcat is used as a
part of it. I.e. Tomcat can be considered as part of Get Answers. Right?
Then Peregrine has the responsibility to fix any errors which occur in
this combination.
[EMAIL PROTECTED] wrote:
I have and they put it down to being the Tomcat application - not much use
at all!
On task manager it does indicate that tomcat is at fault..
-Original Message-
From: Christoph Kutzinski [mailto:[EMAIL PROTECTED]
Sent: 13 September 2005 11:40
To: Tomcat Users List
Subject: Re: The process tomcat {pid 1488. } is leaking handles
This Peregrine Get Answers application is probably leaking file
handles. Ask their support.
[EMAIL PROTECTED] wrote:
We have a server running Peregrine Get Answers which use TOMCAT as part of
its installation
We are seeing (via task manager) a slow build up of handles for the tomcat
app..
Has anyone come across this before?
This e-mail and any attachments are confidential and intended solely
for the addressee and may also be privileged or exempt from disclosure
under applicable law. If you are not the addressee, or have received
this e-mail in error, please notify the sender immediately, delete it
from your system and do not copy, disclose or otherwise act upon any
part of this e-mail or its attachments..
Internet communications are not guaranteed to be secure or virus-free.
The Barclays Group does not accept responsibility for any loss arising
from unauthorised access to, or interference with, any Internet
communications by any third party, or from the transmission of any
viruses. Replies to this e-mail may be monitored by the Barclays
Group for operational or business reasons..
Any opinion or other information in this e-mail or its attachments
that does not relate to the business of the Barclays Group is personal
to the sender and is not given or endorsed by the Barclays Group.
Barclays Bank PLC.Registered in England and Wales (registered no.
1026167).
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom.
Barclays Bank PLC is authorised and regulated by the Financial Services
Authority.
-
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]
This e-mail and any attachments are confidential and intended solely
for the addressee and may also be privileged or exempt from disclosure
under applicable law. If you are not the addressee, or have received
this e-mail in error, please notify the sender immediately, delete it
from your system and do not copy, disclose or otherwise act upon any
part of this e-mail or its attachments..
Internet communications are not guaranteed to be secure or virus-free.
The Barclays Group does not accept responsibility for any loss arising
from unauthorised access to, or interference with, any Internet
communications by any third party, or from the transmission of any
viruses. Replies to this e-mail may be monitored by the Barclays
Group for operational or business reasons..
Any opinion or other information in this e-mail or its attachments
that does not relate to the business of the Barclays Group is personal
to the sender and is not given or endorsed by the Barclays Group.
Barclays Bank PLC.Registered in England and Wales (registered no.
1026167).
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom.
Barclays Bank PLC is authorised and regulated by the Financial Services
Authority.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
Re: Tomcat autoDeploy problem on Unix
Do you create the WAR file on Windows and deploy to Solaris? Have you checked that the system clocks are in sync? Have you checked that the file attributes are ok on Solaris? Have you tried to touch the war file? Olena Mitovska wrote: Hi, We have Tomcat 5.5.7 installed on Solaris 9 and the autoDeploy option doesn't work. We have to restart the server every time we redeploy the application so that changes will be seen, and it is unacceptable for us since it is a production server. Here is the excerpt from our server.xml where we enabled autoDeploy option. - Host appBase=webapps autoDeploy=true name=localhost unpackWARs=true xmlNamespaceAware=false xmlValidation=false and for every application the Context element have attribute reloadable=true. The same settings work fine in windows environment so we tend to think it is specific Unix problem. Can you, please ,advise, how we can redeploy application without having to restart the server every time. Olena - 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: Viewing PDF in Internet Explorer
[EMAIL PROTECTED] wrote: I should have been more clear in stating my problem. I am using a Reporting software with Tomcat. The Reporting servlet receives the report request, passes it to the Reporting Server (lives where the data is), and the Reporting Server sends it back to the client (servlet). The output HTML is automatically generated, and apparently the following is happening with PDF (the Excel plug-in works fine). A JSP-Page (or Servlet) like % response.setContentType(application/pdf); % results in the Content-Type-Header Content-Type: application/pdf;charset=ISO-8859-1 which is not allowed according to HTTP-RFCs. The charset may only be appended when the Content-Type is text/*. Just a wild guess: Have tried to set the character encoding? response.setCharacterEncoding(null) or () Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java 1.4.2_08 and up breaks Jstl
Hi Martyn,
I have 2 suggestions.
I) I suspect that the 2 dots in the value *might* be the problem.
I.e. have you tried this: c:out value=${person.language} /
II) You are using Jakarta Taglibs JSTL. Have you upgraded this to the
latest stable version? This could be an incompability between an older
JSTL implementation and newer JDKs.
I don't know if Jakarta Taglibs has dependencies on other libraries.
If it has, you should upgrade them as well.
I'm especially thinking about Commons Beanutils. This looks like it
*could* be a beanutils problem.
Christoph
Martyn Hiemstra wrote:
Hi All
First of all my jsp file looks like this
Contents Jsp File:
%@ page language=java %
%@ page contentType=text/html; charset=UTF-8 %
%@ taglib uri=http://java.sun.com/jstl/fmt; prefix=fmt %
%@ taglib uri=http://java.sun.com/jstl/core; prefix=c %
c:out value=${person.language.localeName} /
The error occures on the line with the person.language.localeName.
Person is a object in the session. The code prints the locale name the
person has chosen.
System
Debian Sarge
Tomcat:
Tomcat 5.0.27 (I have also tried 5.0.28)
Java
I have Java j2sdk 1.4.2_05 installed under /opt/j2sdk1.4.2_05. I have
created a sym link from /opt/java to /opt/j2sdk1.4.2_05.
I have JAVA_HOME point to /opt/java.
This runs perfectly. I then install j2sdk 1.4.2_08 under /opt and then
have /opt/java point to /opt/j2sdk1.4.2_08.
I stop tomcat. Wait and check to see that no occurance is running in the
memory anymore. I then start up tomcat. When calling the same jsp file
that worked with the previous version of Java I get this error in the
catalina.out:
2005-08-11 11:37:06 StandardWrapperValve[jsp]: Servlet.service() for
servlet jsp threw exception
javax.servlet.jsp.JspException: An error occurred while evaluating
custom action attribute value with value
${person.language.localeName}: Unable to find a value for language
in object of class com.jatse.api.User using operator . (null)
at
org.apache.taglibs.standard.lang.jstl.Evaluator.evaluate(Evaluator.java:146)
at
org.apache.taglibs.standard.lang.jstl.Evaluator.evaluate(Evaluator.java:166)
at
org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.evaluate(ExpressionEvaluatorManager.java:112)
at
org.apache.taglibs.standard.tag.el.fmt.SetLocaleTag.evaluateExpressions(SetLocaleTag.java:141)
at
org.apache.taglibs.standard.tag.el.fmt.SetLocaleTag.doStartTag(SetLocaleTag.java:101)
at
org.apache.jsp.index_jsp._jspx_meth_fmt_setLocale_0(index_jsp.java:146)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:100)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at com.jatse.website.filters.PersonFilter.doFilter(PersonFilter.java:42)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
com.jatse.website.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:128)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
Re: persistence with sessions distributable attribute
Nishant Deshpande wrote:
The SessionListener can check if the attribute implements
Serializable, not if it actually is serializable.
i.e. Nothing to stop people from storing objects which implement
serializable but will barf when actually are serialized.
That is not exactly true.
Look at my example. It tries to write the attribute into a dummy
ObjectOutputstream. If the attribute is not serializable (at that
moment) an exception will be thrown.
This does not save you, of course, from situation where someone puts an
empty HashMap via setAttribute and later puts a not serializable Object
into the map. But doing this (changing an session attribute after the
setAttribute call) isn't recommended anyway, since AFAIK Tomcats session
replication works this way that session are only updated on the remote
nodes if a setAttribute was called.
But another question: you are talking about people putting objects
into the session. Isn't it you - i.e. your webapplication - who is
putting session attributes? You should have enough control over your own
application to ensure that your session attributes are serializable,
shouldn't you?
So - I want to catch each time there is a serialization exception and
log it etc etc.. and even perhaps just drop that object and continue
rather than just drop the serialization for the whole session (this is
what appears to be current behaviour)
Yes, this is apparently the current behaviour. I'm not sure if I like
it, too. I guess it is implemented this way, because if one session
isn't serializable the probability is very high that other sessions are
not serializable, either.
So if you want to change this behaviour, you will probably have to
implement your own PersistanceManager.
On 8/18/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
Question: why do you want to catch errors during serialization.
If you want to check that your attributes are serializable, you can use
a SessionListener as I have shown. I can not think of any other reason
why one would want to catch serialization exceptions.
Nishant Deshpande wrote:
Thanks for the input.
Any idea how I can *catch* errors during serialization? I am guessing
I will have to create my own PersistanceManager and override some
functions..
Has anyone done this (or any other method of doing this)?
On 8/17/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
I didn't say that distributables don't have to implement
java.io.Serializable. In fact they have to.
I just had the impression (from your first post) that you thought by
putting an non-serializable Attribute into a HashMap, the attribute
would become serializable, too.
Example:
If you want to put a java.net.Socket into the session the session won't
be distributable because Socket isn't Serializable.
But if you put the Socket object into a java.util.HashMap (which
implements Serializable) and put the map into the session, the session
still wouldn't be distributable. This is because to serialize the
session the HashMap and ALL its fields must be serialized. Because the
Socket object is now part of the map, this won't work.
Serializable is just a marker interface, i.e. the class just
declares that is it serializable.
You should read the Java Tutorial (somewhere in the JDK docs).
There is explained what Serialization really means.
Christoph
Lintang JP wrote:
I'm referring to this document on :
http://www.onjava.com/pub/a/onjava/2004/04/14/clustering.html?page=2
The words Serializable here would mean for session replication, right ?
CMIIW.
On 8/17/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
Hi Nishant,
where did you read that distributable will *enforce* serializability?
AFAIK distributable only means that your sessions can be distributed
to different tomcat nodes (i.e. a cluster). It doesn't enforce anything,
you have to make sure that your session attributes are serializable by
yourself.
I've done this for my testing environment with a SessionListener:
public class SessionListener implements HttpSessionListener,
HttpSessionAttributeListener {
private ObjectOutputStream stream = new ObjectOutputStream(new
OutputStream() {
public void write(int b) {}
});
public void attributeAdded(HttpSessionBindingEvent evt) {
if (LOCAL_DEBUG) {
// try to serialize attribute
Object o = evt.getValue();
synchronized (stream) {
try {
stream.writeObject(o);
} catch (IOException e) {
System.err.println(evt.getName() + is not serializable: +
e.getMessage());
e.printStackTrace();
}
}
}
}
...
}
I disable LOCAL_DEBUG in the production environment, because trying to
serialize every attribute is probably to expensive under heavy load.
@Lintang:
That wouldn't help any. If you put your attributes (which are not
serializable) into a HashMap (which CAN (!) be serializable) the
resulting object (map + attribute) still wouldn't be serializable.
Serializable is more than just implementing the java.io.Serializable
interface.
greetings,
Christoph
Lintang JP
Re: persistence with sessions distributable attribute
Question: why do you want to catch errors during serialization.
If you want to check that your attributes are serializable, you can use
a SessionListener as I have shown. I can not think of any other reason
why one would want to catch serialization exceptions.
Nishant Deshpande wrote:
Thanks for the input.
Any idea how I can *catch* errors during serialization? I am guessing
I will have to create my own PersistanceManager and override some
functions..
Has anyone done this (or any other method of doing this)?
On 8/17/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
I didn't say that distributables don't have to implement
java.io.Serializable. In fact they have to.
I just had the impression (from your first post) that you thought by
putting an non-serializable Attribute into a HashMap, the attribute
would become serializable, too.
Example:
If you want to put a java.net.Socket into the session the session won't
be distributable because Socket isn't Serializable.
But if you put the Socket object into a java.util.HashMap (which
implements Serializable) and put the map into the session, the session
still wouldn't be distributable. This is because to serialize the
session the HashMap and ALL its fields must be serialized. Because the
Socket object is now part of the map, this won't work.
Serializable is just a marker interface, i.e. the class just
declares that is it serializable.
You should read the Java Tutorial (somewhere in the JDK docs).
There is explained what Serialization really means.
Christoph
Lintang JP wrote:
I'm referring to this document on :
http://www.onjava.com/pub/a/onjava/2004/04/14/clustering.html?page=2
The words Serializable here would mean for session replication, right ?
CMIIW.
On 8/17/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
Hi Nishant,
where did you read that distributable will *enforce* serializability?
AFAIK distributable only means that your sessions can be distributed
to different tomcat nodes (i.e. a cluster). It doesn't enforce anything,
you have to make sure that your session attributes are serializable by
yourself.
I've done this for my testing environment with a SessionListener:
public class SessionListener implements HttpSessionListener,
HttpSessionAttributeListener {
private ObjectOutputStream stream = new ObjectOutputStream(new
OutputStream() {
public void write(int b) {}
});
public void attributeAdded(HttpSessionBindingEvent evt) {
if (LOCAL_DEBUG) {
// try to serialize attribute
Object o = evt.getValue();
synchronized (stream) {
try {
stream.writeObject(o);
} catch (IOException e) {
System.err.println(evt.getName() + is not serializable: +
e.getMessage());
e.printStackTrace();
}
}
}
}
...
}
I disable LOCAL_DEBUG in the production environment, because trying to
serialize every attribute is probably to expensive under heavy load.
@Lintang:
That wouldn't help any. If you put your attributes (which are not
serializable) into a HashMap (which CAN (!) be serializable) the
resulting object (map + attribute) still wouldn't be serializable.
Serializable is more than just implementing the java.io.Serializable
interface.
greetings,
Christoph
Lintang JP wrote:
hi Nishant,
You might want to put all your session variable inside HashMap or other
datatypes that implements Serializable, rather than put it just in a
single
variable. Refer to the javadocs, what are those Serializable data types
are.
Or maybe you can build your own class with something like this :
public class StoredSessionValue implements Serializable {
// your session variable goes here
// your setter and getter method for those variables goes here
}
You did right on your distributable/ tags.
On 8/17/05, Nishant Deshpande [EMAIL PROTECTED] wrote:
Hoping for some help from the tomcat experts on this list.
I want to ensure all objects stored in sessions are serializable.
I read that I can put the distributable/ tag in my web.xml file to
'enforce' this.
But I don't see any enforcing happening. I assumed it would throw
exceptions at runtime when I did 'setAttribute(xxx,
SomeNonSerializableObject)'.
I have put 'distributable' in
web.xml: web-app ... distributable/ ... /web-app
I also have the following in server.xml:
DefaultContext reloadable=true allowLinking=true
Loader className=org.apache.catalina.loader.DevLoader
reloadable=true debug=1/
Manager className=org.apache.catalina.session.PersistentManager
pathname=/cv/data/tmp debug=5 saveOnRestart=true
distributable=true
Store className=org.apache.catalina.session.FileStore
directory=/cv/data/tmp
debug=5/
/Manager
/DefaultContext
Am I missing something? How is the serializability enforced?
Also another question: the serialization does not happen in the
directory i specify for Store above, rather it happens in the
$CATALINA_HOME/work/Catalina/* directories. Any ideas about this one?
Thanks,
Nishant
-
To unsubscribe, e-mail
Re: persistence with sessions distributable attribute
Hi Nishant,
where did you read that distributable will *enforce* serializability?
AFAIK distributable only means that your sessions can be distributed
to different tomcat nodes (i.e. a cluster). It doesn't enforce anything,
you have to make sure that your session attributes are serializable by
yourself.
I've done this for my testing environment with a SessionListener:
public class SessionListener implements HttpSessionListener,
HttpSessionAttributeListener {
private ObjectOutputStream stream = new ObjectOutputStream(new
OutputStream() {
public void write(int b) {}
});
public void attributeAdded(HttpSessionBindingEvent evt) {
if (LOCAL_DEBUG) {
// try to serialize attribute
Object o = evt.getValue();
synchronized (stream) {
try {
stream.writeObject(o);
} catch (IOException e) {
System.err.println(evt.getName() + is not serializable: +
e.getMessage());
e.printStackTrace();
}
}
}
}
...
}
I disable LOCAL_DEBUG in the production environment, because trying to
serialize every attribute is probably to expensive under heavy load.
@Lintang:
That wouldn't help any. If you put your attributes (which are not
serializable) into a HashMap (which CAN (!) be serializable) the
resulting object (map + attribute) still wouldn't be serializable.
Serializable is more than just implementing the java.io.Serializable
interface.
greetings,
Christoph
Lintang JP wrote:
hi Nishant,
You might want to put all your session variable inside HashMap or other
datatypes that implements Serializable, rather than put it just in a single
variable. Refer to the javadocs, what are those Serializable data types are.
Or maybe you can build your own class with something like this :
public class StoredSessionValue implements Serializable {
// your session variable goes here
// your setter and getter method for those variables goes here
}
You did right on your distributable/ tags.
On 8/17/05, Nishant Deshpande [EMAIL PROTECTED] wrote:
Hoping for some help from the tomcat experts on this list.
I want to ensure all objects stored in sessions are serializable.
I read that I can put the distributable/ tag in my web.xml file to
'enforce' this.
But I don't see any enforcing happening. I assumed it would throw
exceptions at runtime when I did 'setAttribute(xxx,
SomeNonSerializableObject)'.
I have put 'distributable' in
web.xml: web-app ... distributable/ ... /web-app
I also have the following in server.xml:
DefaultContext reloadable=true allowLinking=true
Loader className=org.apache.catalina.loader.DevLoader
reloadable=true debug=1/
Manager className=org.apache.catalina.session.PersistentManager
pathname=/cv/data/tmp debug=5 saveOnRestart=true
distributable=true
Store className=org.apache.catalina.session.FileStore
directory=/cv/data/tmp
debug=5/
/Manager
/DefaultContext
Am I missing something? How is the serializability enforced?
Also another question: the serialization does not happen in the
directory i specify for Store above, rather it happens in the
$CATALINA_HOME/work/Catalina/* directories. Any ideas about this one?
Thanks,
Nishant
-
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: persistence with sessions distributable attribute
I didn't say that distributables don't have to implement
java.io.Serializable. In fact they have to.
I just had the impression (from your first post) that you thought by
putting an non-serializable Attribute into a HashMap, the attribute
would become serializable, too.
Example:
If you want to put a java.net.Socket into the session the session won't
be distributable because Socket isn't Serializable.
But if you put the Socket object into a java.util.HashMap (which
implements Serializable) and put the map into the session, the session
still wouldn't be distributable. This is because to serialize the
session the HashMap and ALL its fields must be serialized. Because the
Socket object is now part of the map, this won't work.
Serializable is just a marker interface, i.e. the class just
declares that is it serializable.
You should read the Java Tutorial (somewhere in the JDK docs).
There is explained what Serialization really means.
Christoph
Lintang JP wrote:
I'm referring to this document on :
http://www.onjava.com/pub/a/onjava/2004/04/14/clustering.html?page=2
The words Serializable here would mean for session replication, right ?
CMIIW.
On 8/17/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
Hi Nishant,
where did you read that distributable will *enforce* serializability?
AFAIK distributable only means that your sessions can be distributed
to different tomcat nodes (i.e. a cluster). It doesn't enforce anything,
you have to make sure that your session attributes are serializable by
yourself.
I've done this for my testing environment with a SessionListener:
public class SessionListener implements HttpSessionListener,
HttpSessionAttributeListener {
private ObjectOutputStream stream = new ObjectOutputStream(new
OutputStream() {
public void write(int b) {}
});
public void attributeAdded(HttpSessionBindingEvent evt) {
if (LOCAL_DEBUG) {
// try to serialize attribute
Object o = evt.getValue();
synchronized (stream) {
try {
stream.writeObject(o);
} catch (IOException e) {
System.err.println(evt.getName() + is not serializable: +
e.getMessage());
e.printStackTrace();
}
}
}
}
...
}
I disable LOCAL_DEBUG in the production environment, because trying to
serialize every attribute is probably to expensive under heavy load.
@Lintang:
That wouldn't help any. If you put your attributes (which are not
serializable) into a HashMap (which CAN (!) be serializable) the
resulting object (map + attribute) still wouldn't be serializable.
Serializable is more than just implementing the java.io.Serializable
interface.
greetings,
Christoph
Lintang JP wrote:
hi Nishant,
You might want to put all your session variable inside HashMap or other
datatypes that implements Serializable, rather than put it just in a
single
variable. Refer to the javadocs, what are those Serializable data types
are.
Or maybe you can build your own class with something like this :
public class StoredSessionValue implements Serializable {
// your session variable goes here
// your setter and getter method for those variables goes here
}
You did right on your distributable/ tags.
On 8/17/05, Nishant Deshpande [EMAIL PROTECTED] wrote:
Hoping for some help from the tomcat experts on this list.
I want to ensure all objects stored in sessions are serializable.
I read that I can put the distributable/ tag in my web.xml file to
'enforce' this.
But I don't see any enforcing happening. I assumed it would throw
exceptions at runtime when I did 'setAttribute(xxx,
SomeNonSerializableObject)'.
I have put 'distributable' in
web.xml: web-app ... distributable/ ... /web-app
I also have the following in server.xml:
DefaultContext reloadable=true allowLinking=true
Loader className=org.apache.catalina.loader.DevLoader
reloadable=true debug=1/
Manager className=org.apache.catalina.session.PersistentManager
pathname=/cv/data/tmp debug=5 saveOnRestart=true
distributable=true
Store className=org.apache.catalina.session.FileStore
directory=/cv/data/tmp
debug=5/
/Manager
/DefaultContext
Am I missing something? How is the serializability enforced?
Also another question: the serialization does not happen in the
directory i specify for Store above, rather it happens in the
$CATALINA_HOME/work/Catalina/* directories. Any ideas about this one?
Thanks,
Nishant
-
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: Java 1.4.2_08 and up breaks Jstl
It would probably help, if you would describe what you did (i.e. what is your source code, your environment, tomcat version , etc.) and what does mean the bug happens (i.e. error messages, stack traces, etc.) Now we have just the analogue of My car works on road a but not on road b. Do you know what is wrong? Christoph Martyn Hiemstra wrote: Hi Do you have a link to a Sun Bugparade entry describing the problem? No I don't. I have performed a test of my own. I have installed j2sdk 1.4.2_05 and j2sdk 1.4.2_08 and j2sdk 1.4.2_09. I have installed these to the /opt directory. I have my JAVA_HOME pointed to /opt/java. First I point /opt/java to /opt/j2sdk1.4.2_09 and restart tomcat. The bug happens again. I then point /opt/java to /opt/j2sdk1.4.2_08. I restart tomcat and the same bug occures. I then point /opt/j2sdk1.4.2_05 to /opt/java, restart tomcat and BINGO no bug. Apparently versions java 2 sdk 1.4.2_09 and java 2 sdk 1.4.2_08 cause the bug to occure just as in the forum thread. I have tried a different tomcat version but no luck. Any ideas anybody? Maybe a configuration change that has occured in the new java versions? Martyn Hi, I'm not convinced by that forum thread. It's very hard to believe that there is such a severe bug in Java 1.4.2_06 *that isn't fixed yet* Do you have a link to a Sun Bugparade entry describing the problem? Christoph Martyn Hiemstra wrote: Hi All I have found a Bug in Java 1.4.2_08 and Java 1.4.2_09. Goto this address to read about it: http://forum.java.sun.com/thread.jspa?threadID=599301tstart=0 The new versions will break your jstl code and create errors in the log and create blank pages. I have tried a new Tomcat version, no luck. I had it running on another server but that server is running on Java 1.4.2_05. So just a tip. Dont install Java 1.4.2_08 or higher. It will kill your application if your using jstl. Martyn - 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: Java 1.4.2_08 and up breaks Jstl
Hi, I'm not convinced by that forum thread. It's very hard to believe that there is such a severe bug in Java 1.4.2_06 *that isn't fixed yet* Do you have a link to a Sun Bugparade entry describing the problem? Christoph Martyn Hiemstra wrote: Hi All I have found a Bug in Java 1.4.2_08 and Java 1.4.2_09. Goto this address to read about it: http://forum.java.sun.com/thread.jspa?threadID=599301tstart=0 The new versions will break your jstl code and create errors in the log and create blank pages. I have tried a new Tomcat version, no luck. I had it running on another server but that server is running on Java 1.4.2_05. So just a tip. Dont install Java 1.4.2_08 or higher. It will kill your application if your using jstl. Martyn - 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: tomcat exception of broken pipes
AFAIK these exceptions occur if someone requests a resource (HTML-Page, image, ...) and then closes the connection before all data was sent. I.e. click the stop-button or click on a different Hyperlink. AFAIK one can do nothing to prevent these Exceptions in the log. [EMAIL PROTECTED] wrote: Hi All, Any inputs/suggestions please.. Best regards, --Shashi From: Shashidhar Vutukuru (WT01 - Computing Systems Storage) Sent: Wednesday, August 10, 2005 3:08 PM To: 'tomcat-user@jakarta.apache.org' Subject: tomcat exception of broken pipes hi, I click and browse through some of the features in application, often I get the following error in the catalina.out. I really do not understand the cause of the problem. the error is : Aug 10, 2005 2:10:28 AM org.apache.jk.server.JkCoyoteHandler action SEVERE: Error in action code java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:654) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:435) at org.apache.coyote.Response.action(Response.java:222) at org.apache.coyote.Response.finish(Response.java:343) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:314) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:387) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java: 615) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool .java:666) at java.lang.Thread.run(Thread.java:534) Any help or pointers would be of immense help. Thanks in advance. --shashi Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generic Types support in Tomcat?
FYI: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html Tomcat 5.5.10 ... Update to JDT from Eclipse 3.1, with support for Java 5 However 5.5.10 is still alpha Christoph Patrick Thomas wrote: Thanks Chuck, I definitely wouldn't have noticed that without the pointer. Oh well, I guess I'll stick to casting and iterators for a few more months ;) On 8/8/05, Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Patrick Thomas [mailto:[EMAIL PROTECTED] Subject: Generic Types support in Tomcat? Easiest part of this question is simply does tomcat (5.5.7) support using generic types in JSP files? Some pertinent paragraphs from: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html --- The servlet which implements Jasper is configured using init parameters in your global $CATALINA_BASE/conf/web.xml. # compilerSourceVM - What JDK version are the source files compatible with? (Default JDK 1.4) # compilerTargetVM - What JDK version are the generated files compatible with? (Default JDK 1.4) The Java compiler from Eclipse JDT in included as the default compiler. It is an advanced Java compiler which will load all dependencies from the Tomcat class loader, which will help tremendously when compiling on large installations with tens of JARs. On fast servers, this will allow sub-second recompilation cycles for even large JSP pages. This new compiler will be updated to support the Java 5 syntax as soon as possible. --- I don't know when as soon as possible might be. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [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: How to turn off perssitent sessions in Tomcat 4.1?
Only put objects into the session that are serializable. This is a best practice anyway. Tomcat complains about CoyoteRequestFacade not being serializable because it isn't. If you need data from the request (parameter, attributes etc.) in your session then extract them and put them alone into the session. Or you could simply ignore the error messages at startup. [EMAIL PROTECTED] wrote: Can any one help me out in this issue? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 04, 2005 11:27 AM To: tomcat-user@jakarta.apache.org Subject: RE: How to turn off perssitent sessions in Tomcat 4.1? I am waiting for a good response. Can any body help me out in this? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 03, 2005 6:01 PM To: tomcat-user@jakarta.apache.org Subject: RE: How to turn off perssitent sessions in Tomcat 4.1? Hi Edgar, Thanks for the reply. But I am using Tomcat 4.1.29 and I tried this option (I mean, pathname= in Manager element of server.xml) in Tomcat 4.1.29, which is not successful. Is there any way to turn off session persistence in Tomcat 4.1 itself or I need to upgrade to Tomcat 5.0. In order to avoid the exception we have to make all the objects that is put in session to be serializable, right no?. I am using struts framework. So by default all form beans are serializable and all primitive data types are also serializable. Why Tomcat complains about CoyoteRequestFacade is not serializable? Please clarify my doubts. Advance thanks to all of u !!! -Original Message- From: Edgar Alves [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 03, 2005 5:00 PM To: Tomcat Users List Subject: Re: How to turn off perssitent sessions in Tomcat 4.1? Hi, On Tomcat 5.5 you can turn persistent session loading off by setting the SessionManager pathname attribute to . Hope that helps. -- Edgar Alves [EMAIL PROTECTED] wrote: Hi, I am using Apache+Tomcat 4.1.29 for running my application. When I am restarting Tomcat I am getting persistent session loading exception like this: 2004-03-11 13:52:18 StandardManager[] IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.coyote.tomcat4.CoyoteRequestFacade java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.coyote.tomcat4.CoyoteRequestFacade at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1278) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845 ) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:164 6 ) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845 ) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:164 6 ) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at org.apache.catalina.session.StandardSession.readObject(StandardSession. j ava:1369) I am not using clustering. I want to turn off the session persistence in Tomcat 4.1.29? I have tried so many options with StandardManager in server.xml. But I was not successful. Please help me out in this? Regards AK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session ID's
That wouldn't make much sense IMO. What about links to external hosts or to different contexts on the same host? It would be a security hole to give them your session id. (One could handle this partly by only applying the rewrite to relative URLs) What about links to images, css, javascript files? They would get the session id and therefore unnecessarily not be cached by the users browser. I'm curious: do you know how PHP handles these issues? Christoph Charles P. Killmer wrote: I was hoping there was a configuration setting that would tack the session id onto every hyperlink at runtime, much as PHP does. Charles -Original Message- From: Derrick Koes [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 9:20 AM To: Tomcat Users List Subject: RE: Session ID's Use HttpServletResponse.encodeURL(String url) -Original Message- From: Charles P. Killmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 10:04 AM To: Tomcat Users List Subject: Session ID's Is there a configuration setting such that every local URL will be encoded with a session id if one is present? I have developed a site that uses cookies to hold the session id and am getting complaints from users that do not have cookies enabled. Thanks Charles - 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: restarting tomcat in production
Agreed, and if you have any session information and the session can't be (for whatever reason) be de/serialized, it would indeed be a very bad idea to restart tomcat. Christoph Robert Harper wrote: The best practice is to find the leak and fix it. Restarting is a cover up to a problem that may cause bigger problems down the road as the project scope increases. You can do this but it only hides the real problem and if someone replicates you site and forgets to write or enable the script, then the problem will resurface and you will have to start the discovery process all over again. Robert S. Harper Information Access Technology, Inc. -Original Message- From: Ron Heeb [mailto:[EMAIL PROTECTED] Sent: Monday, July 25, 2005 2:16 PM To: tomcat-user@jakarta.apache.org Subject: restarting tomcat in production hi, i'm looking for some feedback on whether or not it's a normal procedure to regularly restart tomcat. we have some memory leak somewhere that forces us to restart the process every 6-8 days but we're thinking that just putting in a script to restart daily would prevent this and may not be a bad idea to do even if there wasn't any leak. any response appreciated. thanks in advance...ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to set index.faces as welcome-file
Create a dummy index.faces file. I did it this wy with Struts and index.do so I assume it should work with faces, too. hth, Christoph Marten Lehmann wrote: Hello, I tried to put the following into web.xml: welcome-file-list welcome-fileindex.faces/welcome-file /welcome-file-list But obviously, this doesn't work, because there is no file index.faces, but index.jsp. However, if the index.jsp isn't called through index.faces, the FacesContext isn't used. How can I achieve this as expected? I don't want to use the plain old workaround with an index.html containing a refresh. Regards Marten - 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: What commands to run in the Tomcat Debug Mode on Linux
Wendy Smoak wrote: I'm also unsure of the difference between 'run' and 'start'. If you just type 'catalina.bat' with no parameters, it prints out a usage statement that lists 'jpda start' but not 'run jpda'. Since it lists both 'run -security' and 'start -security' separately I have to wonder if 'run jpda' is even a valid option. run jpda does not work. But jpda run works fine , I use it all the time. Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with refreshing JSP
Travis Stevens wrote: The other thing to note about reloading JSPs is that tomcat 5.5 seems to copy ones web context directory into its own webapps directory. Any changes to the original JSPs will not show up unless you physically copy the JSP from the original directory to the webapps directory. I haven't observed this behavior with my Tomcat 5.5. Maybe you have set antiResourceLocking=true or something like this. In this case I think tomcat will copy all the files. Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection pool
Start a new discussion thread instead of hijacking this one. And if you do that: give more information. What have you done so far? have you read the documentation? What are the error messages, if you already at that point? etc. etc. Sridhar wrote: Can anyone help how to create Connection Pool in Tomcat 5.0 with a Oracle9i database. This is very urgnet... - 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: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
Hi, my Tomcat 5.5.9 has the commons-logging-api.jar in the bin directory. Did you look there, too? John Pedersen wrote: I am still stuck with this one (shouldn't have posted it on a Saturday morning!). I don't think it is my web.xml giving the problem - I am looking into possible problems with missing or conflicting jar files Reading through the release notes again for Tomcat 5.5.9, there is a listing of the libraries included: = Bundled APIs: = A standard installation of Tomcat 5.5 makes all of the following APIs available for use by web applications (by placing them in common/lib or shared/lib): * commons-el.jar (Commons Expression Language 1.0) * commons-logging-api.jar (Commons Logging API 1.0.x) * jasper-compiler.jar (Jasper 2 Compiler) * jasper-compiler-jdt.jar (Eclipse JDT Java compiler) * jasper-runtime.jar (Jasper 2 Runtime) * jsp-api.jar (JSP 2.0 API) * naming-common.jar (JNDI Context implementation) * naming-factory.jar (JNDI object factories for J2EE ENC support) * naming-factory-dbcp.jar (DataSource implementation based on commons-dbcp) * naming-resources.jar (JNDI DirContext implementations) * servlet-api.jar (Servlet 2.4 API) I seem to be missing: commons-logging-api.jar (Commons Logging API 1.0.x) naming-common.jar (JNDI Context implementation) from my Tomcat installation (Windows 2000, I used the windows installer jakarta-tomcat-5.5.9.exe) Why should this be the case? Where can I download these files from? Thanks, John - 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: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
This is what happens in JSPService.java around line 249:
try {
boolean precompile = preCompile(request);
serviceJspFile(request, response, jspUri, null, precompile);
} catch (RuntimeException e) {
throw e;
} catch (ServletException e) {
throw e;
} catch (IOException e) {
throw e;
} catch (Throwable e) {
throw new ServletException(e); line 249
}
You should get the Tomcat sources and set a breakpoint at line 249. When
you know the real throwable that is catched there, you will probably get
it clue what is happening.
Christoph
Christoph Kutzinski wrote:
Hi,
my Tomcat 5.5.9 has the commons-logging-api.jar in the bin directory.
Did you look there, too?
John Pedersen wrote:
I am still stuck with this one (shouldn't have posted it on a Saturday
morning!).
I don't think it is my web.xml giving the problem - I am looking into
possible problems with missing or conflicting jar files
Reading through the release notes again for Tomcat 5.5.9, there is a
listing of the libraries included:
=
Bundled APIs:
=
A standard installation of Tomcat 5.5 makes all of the following APIs
available
for use by web applications (by placing them in common/lib or
shared/lib):
* commons-el.jar (Commons Expression Language 1.0)
* commons-logging-api.jar (Commons Logging API 1.0.x)
* jasper-compiler.jar (Jasper 2 Compiler)
* jasper-compiler-jdt.jar (Eclipse JDT Java compiler)
* jasper-runtime.jar (Jasper 2 Runtime)
* jsp-api.jar (JSP 2.0 API)
* naming-common.jar (JNDI Context implementation)
* naming-factory.jar (JNDI object factories for J2EE ENC support)
* naming-factory-dbcp.jar (DataSource implementation based on
commons-dbcp)
* naming-resources.jar (JNDI DirContext implementations)
* servlet-api.jar (Servlet 2.4 API)
I seem to be missing:
commons-logging-api.jar (Commons Logging API 1.0.x)
naming-common.jar (JNDI Context implementation)
from my Tomcat installation (Windows 2000, I used the windows
installer jakarta-tomcat-5.5.9.exe)
Why should this be the case? Where can I download these files from?
Thanks,
John
-
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: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
John Pedersen wrote: Christoph, I think there may be a little delay with the mailing list. The problem is solved. For reference, yes, I too have the commons-logging-api.jar in the bin directory! Wonder why it was put there - that seems a little inconsistent, but I don't know enough about Tomcat to judge the matter. That is exactly what I thought when I found it in bin: What the h*ll does the jar do in here? ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Depreciated?
I assume that you mean by req a HttpServletRequest. Why do you think that getSession(boolean) is deprecated? I've found no clue that it is. Christoph Christopher Molnar wrote: I understand HttpSession session=req.getSession(true); has been depreciated. What is correct to use in place of HttpSession ? Thanks, -Chris - 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: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
Your message was not bounced, I already got the first one (then the
second and then this one).
Please check the list before reposting.
John Pedersen wrote:
Bounced twice...
-- Forwarded message --
From: John Pedersen [EMAIL PROTECTED]
Date: 16-Jul-2005 08:03
Subject: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
To: tomcat-user@jakarta.apache.org
Hi,
I had an app that was working - then I upgraded to Tomcat 5.5.9, and Java 1.5.
Now I get a javax.servlet.ServletException:
javax/servlet/jsp/tagext/TagLibraryValidator when I try to start the
app. I have followed all the google links for this problem and trawled
through the docs - I'm stuck!
I use one page to declare my taglibs, and this is included in all the
other pages:
%@ taglib prefix=spring uri=http://www.springframework.org/tags; %
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
If I delete the second line, the app starts fine, although of course
all the c: tags aren't evaluated. So it seems that the problem is only
associated with the standard tags.
Here is what I have at the top of my web.xml (I have tried variations!):
!DOCTYPE web-app PUBLIC
-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd;
web-app
...
Here are the jar files I have in web-app\myApp\lib:
activation.jar
commons-collections.jar
commons-dbcp.jar
commons-fileupload.jar
commons-logging.jar
commons-pool.jar
cos.jar
itext-1.1.4.jar
jstl.jar
junit.jar
log4j-1.2.9.jar
mail.jar
mysql-connector-java-3.1.8-bin.jar
spring.jar
standard.jar
swissEph.jar
and the jar files I have in {tomcat-home}\common\lib:
commons-el.jar
jasper-compiler-jdt.jar
jasper-compiler.jar
jasper-runtime.jar
jsp-api.jar
naming-factory-dbcp.jar
naming-factory.jar
naming-resources.jar
servlet-api.jar
Inside the standard jar, in c.tld:
descriptionJSTL 1.1 core library/description
display-nameJSTL core/display-name
tlib-version1.1/tlib-version
short-namec/short-name
urihttp://java.sun.com/jsp/jstl/core/uri
...
If anyone can help me solve this one, I'll be very relieved,
Thanks,
John Pedersen
-
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: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
I get these responses, too. I wonder if someone has already informed a
list administrator about this.
Regarding your original question:
I've no clues so far, but you should post the complete stacktrace of the
exception. Maybe the source of the error will get clearer then.
Christoph
John Pedersen wrote:
Sorry - I should have checked the list. But I just got a response
telling me that the email I sent to the list was undeliverable...
John
On 16/07/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
Your message was not bounced, I already got the first one (then the
second and then this one).
Please check the list before reposting.
John Pedersen wrote:
Bounced twice...
-- Forwarded message --
From: John Pedersen [EMAIL PROTECTED]
Date: 16-Jul-2005 08:03
Subject: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
To: tomcat-user@jakarta.apache.org
Hi,
I had an app that was working - then I upgraded to Tomcat 5.5.9, and Java 1.5.
Now I get a javax.servlet.ServletException:
javax/servlet/jsp/tagext/TagLibraryValidator when I try to start the
app. I have followed all the google links for this problem and trawled
through the docs - I'm stuck!
I use one page to declare my taglibs, and this is included in all the
other pages:
%@ taglib prefix=spring uri=http://www.springframework.org/tags; %
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
If I delete the second line, the app starts fine, although of course
all the c: tags aren't evaluated. So it seems that the problem is only
associated with the standard tags.
Here is what I have at the top of my web.xml (I have tried variations!):
!DOCTYPE web-app PUBLIC
-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd;
web-app
...
Here are the jar files I have in web-app\myApp\lib:
activation.jar
commons-collections.jar
commons-dbcp.jar
commons-fileupload.jar
commons-logging.jar
commons-pool.jar
cos.jar
itext-1.1.4.jar
jstl.jar
junit.jar
log4j-1.2.9.jar
mail.jar
mysql-connector-java-3.1.8-bin.jar
spring.jar
standard.jar
swissEph.jar
and the jar files I have in {tomcat-home}\common\lib:
commons-el.jar
jasper-compiler-jdt.jar
jasper-compiler.jar
jasper-runtime.jar
jsp-api.jar
naming-factory-dbcp.jar
naming-factory.jar
naming-resources.jar
servlet-api.jar
Inside the standard jar, in c.tld:
descriptionJSTL 1.1 core library/description
display-nameJSTL core/display-name
tlib-version1.1/tlib-version
short-namec/short-name
urihttp://java.sun.com/jsp/jstl/core/uri
...
If anyone can help me solve this one, I'll be very relieved,
Thanks,
John Pedersen
-
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: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
John Pedersen wrote: Here is what I have at the top of my web.xml (I have tried variations!): !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app I haven't paid attention to this before. You do use JSTL 1.1, don't you? JSTL 1.1 requires a Servlet 2.4 container. Have you tried to make your web.xml 2.4 compliant? Other idea: have you deleted all the compiled JSPs after switching to Tomcat 5.5 /JDK 5.0? Christoph Here is the complete stack trace: ERROR[cessor24]: framework.web.servlet.DispatcherServlet 11485 - Could not complete request javax.servlet.ServletException: javax/servlet/jsp/tagext/TagLibraryValidator at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:97) at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250) at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:928) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:705) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625) at org.springframework.web.servlet.FrameworkServlet.serviceWrapper(FrameworkServlet.java:386) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:346) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Unknown Source) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with refreshing JSP
Rob Hills wrote: Hi Rahul, On 12 Jul 2005 at 8:19, Rahul Joshi wrote: It is Tomcat that has these compiled files which it continues to read from work/Catalina/localhost/ instead of the new ones. The questions is how do we make Tomcat clear or over-write these stored compiled files. If you set the Reloadable attribute of your application's Context element to True you will find that Tomcat will recompile any JSP file shortly after it changes ( see http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html ). As described in the documentation, this can slow down the performance of your application so it's best to switch it off on a production server. Actually reloadable=true makes tomcat watch for changes in /WEB-INF/classes/ and /WEB-INF/lib (see again http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html ) which is indeed a costly operation. Watching for changes to the JSPs is done somewhere else. If memory fails me not, it is in the server.xml file: an attribute of the JSPServlet element. Watching for JSP changes is not that costly. Unless you have a very high traffic site you can safely use it for your production site, too. Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 Memory (not in catalina.sh anymore).
Hi, the Tomcat FAQ describes how to adjust the memory settings. Christoph Dave Morrow wrote: Hi all. I recently updated to Tomcat 5.5 All is well, with one exception. In prior releases (4.1) I could edit the catalina.sh script to adjust the memory settings. Where would I do this in 5.5? David A. Morrow Technical Systems Lead Autodata Solutions Company [EMAIL PROTECTED] http://www.autodata.net Tel: (519) 951-6079 Fax: (519) 451-6615 Freedom is just another word for nothing left to lose- Janis Joplin This message has originated from Autodata Solutions. The attached material is the Confidential and Proprietary Information of Autodata Solutions. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please delete this message and notify the Autodata system administrator at [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles
This is a Struts/Tiles related question, you should ask in the Struts
mailing lists.
Dewitte Rémi wrote:
Hi !
I make a definition in which i put a list of tiles to include but I can't
achieve to do this eg :
in my tiles-defs.xml :
definition name=page1-def extends=baseDef
put name=page value=1/
putList name=listQuestions
add value=/Q/firstName.jsp/
add value=/Q/lastName.jsp/
/putList
/definition
And in my template, i don't know how to iterate in listQuestions in order to
include /Q/firstName.jsp and /Q/lastName.jsp.
A start :
tiles:importAttribute/
c:out value=${listQuestions}/
c:forEach items=${listQuestions} var=question
What to do to include question !
/c:forEach
Maybe it's not possible...
Thanks.
Rémi
-
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: Where are my tomcat icons in Eclipse 3.1? How to use Tomcat with Maven and Eclipse 3.1?
Are you referring to the Sysdeo Tomcat launcher? This is an external plugin, not part of a fresh Eclise install, you have to install it manually. Otherwise: the tutorial is about the WTP. Have you installed it properly with all dependencies? In that case you can start your project with the projects context menu: run on server (or something like this. I don't have WTP here) hth Christoph Siegfried Heintze wrote: Is there a more appropriate place to ask questions on tomcat and eclipse? I googled for some eclipse forums and found some, but they would not let me post to them. Anyway, I noticed that eclipse 3.0.1 has some nice little icons for starting and stopping eclipse. Under preferences it also has an entry for tomcat. Both these icons/buttons and the tree control entry under preferences are missing in Eclipse 3.1. This makes it very difficult to follow the tutorial on using maven with eclipse at http://www.eclipse.org/webtools/jst/components/j2ee/scenarios/MavenEclipseIn tegration.html . Can anyone tell me how to get these features in eclipse 3.1? Thanks, Siegfried - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is tc-5.5.9 as stable as 5.0.28?
I've never heard about unstabilities in 5.5.9. I use it in my development environment for some time without any issues (however I'm still using 5.0.19 in production). One question: if you're happy with 5.0.28 why switch to 5.5.9? Never change a running system (unless you have very good reasons to to so) Zsolt Koppany wrote: Hi, we ship our application with tc-5.0.28 and it is stable. Is 5.5.9 as stable as 5.0.28? If yes we would like to move to that version. We are happy with 5.0.28 and think to move to 5.5.9 because the built in java compiler (eclipse). Zsolt - 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: invalidated session
Yes, you shouldn't rely on finalizers to clean-up session objects. Better do it in your listener. Len Popp wrote: I'm pretty sure that the finalizers are only called when garbage collection reclaims the objects, and that will be some time after the session is invalidated. Possibly a very long time after, if Tomcat isn't busy and isn't using much memory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Single Sign on to access another webapp.
Check this for a way to implement this with Tomcat (you must use 5.5 ore higher, though): http://weblogs.java.net/blog/wholder/archive/2005/02/session_session.html Or this is a solution I found with an external authentication server: http://www.developertutorials.com/tutorials/java/single-sign-on/page4.html hth, Christoph Ben Bookey wrote: Dear List, We are using Tomcat 4.1.xx. We are NOT using the built in security framework which comes with TC. In the login.jsp page the user/password is validated by an external organisation wide process, which returns simply true or false. If the user is valid, the user is forwarded to the application JSP pages. The user can not access the application pages at will, because the pages check to see if a particular session flag is checked. Now my problem. I have been asked to assess if single sign On (SSO) could be used to create a URL link to another similar webapp's JSP page (TC with no security framework), where the user doesnt need to login for a second time. There is not so much info. about SSO around, but from what I gather it persists login info. inside a session which is passed between web applications. My first problem is that my application never knows what the password is. Can anyone see a possibilty of using SSO for me, allowing direct access to another webapps JSP page with out re-login ? Would really appreciate any help on this. Especially ones with info. more than simply No ;-) kind regards, Ben p.s. might be that the 2nd app has to create a web-service or something to provide the information for us!! - 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: generate image by servlet for large amount of requests
Yes, a good idea would be not to hijack someone elses discussion thread and start a new one instead. Then probably more people will read your question. Regarding your original question: no idea Tony Smith wrote: Any ideas? --- Tony Smith [EMAIL PROTECTED] wrote: Let's think about maps.yahoo.com. I do not know how they handle millions of request and generate the map pictures quickly. If I use a servlet, in the post or get method I use: BufferedImage mapImage = myTookKit.generateMap(String address); response.setContentType(image/png); OutputStream os = response.getOutputStream(); ImageIO.write(buffer, png, os); os.close(); Is servlet a good choice? If I use servlet, is the code above good enough to handle hundreds of request? Is the choice of BufferedImage a good one? What special technique I need to implement myTookKit to make it faster? I am thinking about JNI. Thanks, __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: Make webapp jars downloadable
Write a Servlet that streams the JAR content to the Webstart clients and point to the servlet in the JNLP files. Andrea Aime wrote: Hi, I have the following problem: I'm deploying a web app that exposes web services and allows the client to install a web started client. Now, the client and the web application share a lot of jars, so I would like to make the jars in web-inf/lib downloadable, so that the web start can access them. At the moment I've put the jars both in web-inf/lib and in the root, but this basically doubles the size of my application. This is not very nice since I have to upload it to a test server on my ISP and the upload connection is not very fast (ADSL line). Any solution? Best regards Andrea Aime - 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: Can't rename a file using renameTo()
Hi, I would guess that there is a security policy in JBoss that prevents JBoss (and its integrated Tomcat) from writing outside some special directories (e.g. its working directory and the temp directory). There is surely a way to lessen this security restriction, but that is obviously a JBoss question. You should ask for more help in a JBoss forum/mailing list (or probably just reading the JBoss configuration documentation would help, too) Christoph Kam Lung Leung wrote: Hi Jason, Thank you for the information. It is a long paragraph. I checked the /SomeDirectory again, and it is the same name. I was able to create directory with the mkdir -p /SomeDirectory/firstSubdirectory/secondSubdirectory and manually created a file by this command touch /SomeDirectory/firstSubdirectory/secondSubdirectory/newFile . The Servlet was able to create directories under the /SomeDirectory directory. For example, the Servlet was able to create /SomeDirectory/firstSubdirectory/secondSubdirectory directories. But the Servlet can’t rename the file named oldFile under the /tmp directory to /SomeDirectory/firstSubdirectory/secondSubdirectory/newFile. The Servlet did created all directories under the /SomeDirectory by not able to move the oldFile to the that directory. The same code work fines what it run without the Jboss running in the same server. Kam Jason Bainbridge [EMAIL PROTECTED] wrote: On 6/21/05, Kam Lung Leung [EMAIL PROTECTED] wrote: Hi, I have a servlet, Servlet-A, that rename a file from /tmp/oldFile to /someDirectory/newFile. The Servlet-A runs fine when it runs by itself in a Red Hat Linux 7.2 server that has jakarta-tomcat-4.1.30 running. However, it false to rename the /tmp/oldFile to /someDirectory/newFile when the Servlet-A run (within the jakarta-tomcat-4.1.30) in a Red Hat Linux 7.2 server box that also has jboss-3.2.1_tomcat-4.1.24 running. I thought it may be privilege issue so I set the /someDirectory directory with chmod –R 777 and run Tomcat as a root user. But, it is still false to rename the /tmp/oldFile file to the /someDirectory/newFile. The strange thing is that the Servlet-A was able to write the oldFile to the /tmp directory but can not rename the oldFile to the /someDirectory directory that was allowed for writing for ALL user levels. Can this be Jboss prevented the rename operation. I used the canRead and canWrite to check allowable action by the File. It turns out that the Servlet-A can read and write the /tmp/ oldFile. But the Servlet-A can't read or write the /someDirectory/newFile. The strangest thing is that when the Servlet-A runs in a Red Hat Linux 7.2 server that has ONLY jakarta-tomcat-4.1.30 running, the condition of canRead and canwrite are the same. Meaning that the Servlet-A was able to read, and write the oldFile. But can't read, and write the newFile. However, the renameTo() method returned true and the Servlet-A was able to rename the /tmp/oldFile into /someDirectory/newFile. It took me a few reads to even come close to following all that but is it possibly that you are trying to copy a subdirectory within /tmp to a subdirectory of /someDirectory that doesn't exist? -- Jason Bainbridge http://kde.org - [EMAIL PROTECTED] Personal Site - http://jasonbainbridge.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: Is Tomcat is an application server ?
There only relevant question here is: How is a application server defined? As Richard Mixon already pointed out, there are many definitions under which Tomcat IS an application server. For many others however application server is equivalent to full J2EE application server (or something like this). In this definition Tomcat is surely no application server. For me however an application server is just what the word says: A server that serves applications. And that is what Tomcat can do. just my 2 Euro cents, Christoph Werner van Mook (RY/ETM) wrote: IMHO : Tomcat is a web application server, not an application server. It is true you can extend tomcat and make it work like an application server. Tomcat and just Tomcat is no application server. It's like saying that an engine is a car. Which is not true! You can extend this engine and build things around it that will make the complete thing you have build a car. But the engine still is an engine and not a car. You could also have build a motorbike which uses an engine. An application server can use a web front end hosted by tomcat but it is not a requirement. An application server can also have native clients (written in any programming language). An application server has standard ejb support. If you have build a web application with tomcat than you have build yourself a j2ee application without using an application server, which is perfectly legal. Regards Werner van Mook - 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]
Register custom CharsetProvider by a webapplication
Hi, I'm trying to install a custom CharsetProvider (UTF7) with my web application (i.e. deliver a JAR with a META-/services/java.nio.charset.spi.CharsetProvider entry in WEB-INF/lib) However the CharsetProvider isn't recognized when it comes to parsing (i.e. calling javax.mail.Part.getContent()) If I place the JAR into JRE/lib/ext it works. The API of CharsetProvider (http://java.sun.com/j2se/1.5.0/docs/api/java/nio/charset/spi/CharsetProvider.html) says: Charset providers may be installed in an instance of the Java platform as extensions, that is, jar files placed into any of the usual extension directories. Providers may also be made available by adding them to the applet or application class path or by some other platform-specific means. Charset providers are looked up via the current thread's context class loader. I interpret it this way: If the JAR is in the classpath (specifically: if it is found by the current context class loader) the Charsetprovider should be automatically recognized. I checked that the context classloader immediately before calling Part.getContent() is the webapp-classloader, so the JARs in WEB-INF/lib should be visible. So is there any solution to this other than placing the JAR in an extension directory? Could this be a Tomcat bug or is this expected behaviour due to the speciality of the webapp classloaders? (I tried to understand the implifications of Tomcats classloading at http://jakarta.apache.org/tomcat/tomcat-5.5-doc/class-loader-howto.html but couldn't figure it out by myself) Thank you, Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SV: Compression doesn't work :(
How are you testing that nothing is compressed? E.g. which browser? smmarrt wrote: No, Tomcat treats this value in bytes. :( yvind Johansen : Without knowing the proper way to configure compression, it looks like you have configured it to not compressing anything smaller than 2048kbyte? But I could be wrong on this... yvind Johansen ElectricTimeCar 2802 Gjvik, Norway -Opprinnelig melding- Fra: smmarrt [mailto:[EMAIL PROTECTED] Sendt: 19. juni 2005 14:59 Til: Tomcat Users List Emne: Compression doesn't work :( I try setting compression-related properties on Connector, but it doesn't compress anything :( Connector port=8080 maxHttpHeaderSize=8192 maxThreads=250 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true compression=on compressionMinSize=2048 / No pages are compressed (nor static, nor servlets) - 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: isRequestedSessionIdFromURL() returns false
Michael Jouravlev wrote: Hi, I hope am I in the right mail-list with this question. I guess that if I use Tomcat, then HttpRequest.isRequestedSessionIdFromURL() is implemented by Tomcat. I have a request, which contains *both* session ID in cookie *and* session ID in the rewritten URL. isRequestedSessionIdFromCookie() return true, but isRequestedSessionIdFromURL() returns false. It seems that isRequestedSessionIdFromURL() should return true. Is this a bug? Interesting question. The Servlet 2.3 spec says: public boolean isRequestedSessionIdFromURL() Checks whether the requested session ID came in as part of the request URL. Returns: true if the session ID came in as part of a URL; otherwise, false I would interpret it this way: if the session id, which should be used was extracted from the URL, then return true. If however the cookie contains the same id and was checked first (which is default I think) then the requested session id came from the cookie! Imagine what would happen if always both would be checked and URL and cookie would contain 2 different ids. Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Out of memory
Hi, first: You should start a new discussion thread, if you have a new question instead of answering to an existing one. Readers may not see your question if you don't. -XX:+UseAdaptiveSizePolicy works good for me (with Java 5.0). Just give the VM a very big maximum heap size and the gc algorithm will determine for itself how much of the memory it needs. Here is more info: http://java.sun.com/developer/JDCTechTips/2005/tt0216.html#2 hth, Christoph David Wall wrote: This is no doubt a java-related question, but it seems that with virtual memory, my JVM should never run out of memory (aside from a nasty bug and lack of swap disk space). Is there a way to allow my web application to have as much memory as the OS will give it, yet not have the JVM attempt to consume all that space before the GC reclaims the space? I'd like the JVM to start with 64M, max out around 1GB in terms of holding the memory, yet allow it to use more memory when it needs it, and then have it attempt to release that memory so as not to cause swapping once the high memory need has disappeared. Can this be done? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat keeps growing in size on Win32
Tomcat really uses File.deleteOnExit()? This method has a known memory leak (not only on win32) for quite some time. See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817 Ed Hamilton wrote: Thanks, Robson, for the reply. I have all the latest versions of everything: Tomcat: 5.5.9 JDSK: 1.5.0.03 JDBC: 3.18a Isapi Redirector: 1.2.13 There is no website/database activity, just tomcat running. I believe it's related to the other posting I made about every-10-seconds-tomcat-scans-directories. I believe I have it narrowed down to java.io.File.DeleteOnExit that tomcat uses in executePartialPut in DefaultServlet.java. Apparently, this java routine has a known problem on Win32 systems. I've been asked by one of the tomcat guys to get some hard evidence, but I don't have time to tear the tomcat source code apart looking for this and was hoping some of the other users out there are seeing the same problem. Regards all, Ed - 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: tomcat does not like cmdline args of wget?
Are there any special chars in theUser and/or thePass that could possibly escaped in the URL and/or by the shell? E.g. Umlauts, Whitespace, %, ... Or are you really literally writing wget http://theUser:[EMAIL PROTECTED]/someURL ? Holger Klawitter wrote: QM wrote: On Mon, Jun 13, 2005 at 11:04:03AM +0200, Holger Klawitter wrote: : what might be the reasion that : wget http://theUser:[EMAIL PROTECTED]/someURL : is working, whereas : wget --http-user=theUser --http-passwd=thePass http://theHost/someURL : yields Authorization failed (401)? (I also tried --cookies=on) I don't know off the top of my head, but you could (temporarily) enable RequestDumperValve and compare the two requests. There is one indeed interesting difference, both requests end up with a different (each one is reproducable) auth string: INFO: header=authorization=Basic **F0OjE1c***emxl INFO: header=authorization=Basic **VyOjI3Y***ZQ== (** and *** is manual masking) Am I right to assume wget to be the culprit? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat does not like cmdline args of wget?
Holger Klawitter wrote: Christoph Kutzinski wrote: wget --http-user=theUser --http-passwd=thePass http://theHost/someURL vs. wget http://theUser:[EMAIL PROTECTED]/someURL with BASIC auth Or are you really literally writing wget http://theUser:[EMAIL PROTECTED]/someURL of course not :-) Why, not? It is always a good idea to start testing the simple things ;) There was no shell escaping involved (username and password both matched [a-zA-Z0-9]* and escaping would affect both access patterns the same way, wouldn't it?) Not necessarily. If the password would contain %20 for example, this would probably be interpreted as a space in wget http://theUser:[EMAIL PROTECTED]/someURL, but as %20 in wget --http-user=theUser --http-passwd=thePass http://theHost/someURL I have no more ideas. Currently sounds like a wget problem to me, too. But I cannot imagine that wget should have such a big error. (I just tried it here without problems) Have you tried the same with other browsers? You could google for problems with wget authentication. Maybe others have found similar problems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDumperValve stuff in my logs
Open your server.xml, search for RequestDumperValve, comment out the element, restart Tomcat, done. Anthony Smith wrote: How can I get this type of stuff to stop printing in my catalina_log files: 2005-06-10 00:00:14 RequestDumperValve[Standalone]: header=3Daccept-charset=3Diso-8859-1,*,utf-8 2005-06-10 00:00:14 RequestDumperValve[Standalone]: header=3Daccept-encoding=3Dgzip 2005-06-10 00:00:14 RequestDumperValve[Standalone]: header=3Daccept-encoding=3Dgzip 2005-06-10 00:00:14 RequestDumperValve[Standalone]: header=3Dconnection=3Dclose 2005-06-10 00:00:14 RequestDumperValve[Standalone]: header=3Dconnection=3Dclose 2005-06-10 00:00:14 RequestDumperValve[Standalone]: header=3Dcontent-length=3D48 2005-06-10 00:00:14 RequestDumperValve[Standalone]: header=3Dcontent-length=3D48 2005-06-10 00:00:14 RequestDumperValve[Standalone]: header=3Dcontent-type=3Dapplication/x-www-form-urlencoded;charset=3DUTF- 8= 2005-06-10 00:00:14 RequestDumperValve[Standalone]: header=3Dcontent-type=3Dapplication/x-www-form-urlencoded;charset=3DUTF- 8= 2005-06-10 00:00:14 RequestDumperValve[Standalone]: header=3Duser-agent=3DBW-HTTPClient/5.2 Anthony Smith Programmer Analyst International Technologies 901-263-8953 Having education and talent doesn't make you better than the world... it makes you responsible for it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: .pst file type unknown in tomcat
Hi, filext.com ist usually useful in such cases: http://filext.com/detaillist.php?extdetail=pstSubmit3=Go%21 application/winframe is suggested at the bottom of the page. HTH, Christoph Marot Laurent wrote: I don't know what to put in the mime-type attribute mime-mapping extensionpss/extension mime-type?/mime-type /mime-mapping -Message d'origine- De : George Sexton [mailto:[EMAIL PROTECTED] Envoyé : lundi 30 mai 2005 22:44 À : 'Tomcat Users List' Objet : RE: .pst file type unknown in tomcat .pst file mime type is not decalred by default in web.xml So, why don't you declare it? George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Marot Laurent [mailto:[EMAIL PROTECTED] Sent: Monday, May 30, 2005 2:33 PM To: Tomcat Users List Subject: .pst file type unknown in tomcat Hi all, I'm trying to manage .pst files stored on my Tomcat server. But unfortunately when i click on a pst file link it opens the file in a pop-up (an of course content is not readable). How could i pevent tomcat from serving the file this way but better propose do save it on user's local disk ? .pst file mime type is not decalred by default in web.xml Thanks a lot Laurent - 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: HttpSessionListener
Hi Randy,
Randy George wrote:
Hi Will and Christopher,
Good thought. I shut down Tomcat and started it again with a clean
set of logs:
localhost.2005-05-25.log
.
.
May 25, 2005 11:22:17 AM org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: contextInitialized()
May 25, 2005 11:27:45 AM org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: sessionCreated('BD963D7E6AACE0E2387F37919BB277FC')
I interpret this to show that the listener element in web.xml is
initialized and later a sessionCeated() method was actually called:
.
.
public synchronized void sessionCreated (HttpSessionEvent se) {
System.out.println(sessionCreated +sessionCount);
sessionCount++;
}
However, there is no entry in the stout log so whatever sessionCreated
method is called it is not the one registered?
listener
listener-classcom.test.SessionCounter/listener-class
/listener
Yes that is my thought, too. There is a SessionListener initialized but
apparently not yours. You should put a log statement into the
constructor of your listener and make sure.
You didn't answer my question about deployment: do you deploy your
application on the development and the production box in the same way.
If not, you should try to do it in the same way on the devel box as you
do on the prod box and look if the problem appears on the prod box, too.
Another idea: the name (com.test.SessionCounter) of your listenere is
not very unique. Maybe there is a conflcit with an existing class in
Tomcats shared or common folder on the production system. Are there any
other applications installed on the production tomcat?
I also just noticed that the Tomcat WebApp Manager is showing only 0's for
sessions regardless of how many sessions are started?
That is really strange. Are you sure that you are hitting the production
tomcat with your tests? Any other log entries which could confirm that?
greetings,
Christoph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpSessionListener
I suspect that the Listener class is not found on the production server. You should check your deployment. Are you deplyoing via WAR files in both cases? Randy George wrote: Hi Jacob, Thanks for the reply. My situation is a little more straightforward than the replication cluster you are dealing with. In my case the first server is simply the development environment and the second server is the production deployment server. The two environments use identical OS and Tomcat so I am baffled at why HttpSessionListener will only work on the server used for development. Thanks Randy -Original Message- From: Jacob Champlin [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 25, 2005 8:51 AM To: tomcat-user@jakarta.apache.org Subject: Re: HttpSessionListener Randy, I don't believe you have session replication set up in your cluster. This is why when a session is created it only calls your HttpSessionListener on one box. The second box will only get the session if its replicated over to that box. However! I tried to do the same thing and I was getting server lockups when it a cluster. The HttpSessionListener would work fine on a single box, but in a cluster both servers would lock up. It is my belief that there is some concurrency issue in Tomcat/Session Replication/HttpSessionListeners. However, I never found anything firm, as is usually the case with concurrency issues. Well I would love to hear if you get this working. Jacob Champlin EMO Corporation - 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: How do I handle International Characters
Lutz Zetzsche wrote: Hi Harry, Am Montag, 9. Mai 2005 20:53 schrieb Harry Mantheakis: Browsers should (and mostly do, I think) respect the encoding you specify when setting the response content-type (and the meta-tag content-type) so you can simply assume (in your filter) that your form-data will be in UTF-8. Clients still need to, of course, set their browsers to display the relevant charsets correctly. As far as HTML forms are concerned, you can force the browser to submit them to the server using a particular charset by adding the accept-charset attribute to the form tag, i.e.: form accept-charset=utf-8 ... ... /form http://www.w3.org/TR/REC-html40/interact/forms.html#adef-accept-charset This does however not work with Internet Explorer. I had this problem in the past. IE insists on using the page charset and ignores the accept-charset attribute. There were some more information at this URL (http://ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html), but it is currently not available. HTH Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java class is reloaded automatically?
Hi, are you debugging Tomcat when this happens? Then this is maybe related to class hotswapping Christoph Kent Tong wrote: Hi, I notice that in Tomcat 5.5 changes to my Java class take effects without reloading the app. The content is not marked as reloadable. There is no message in the console saying the app is reloaded. It is like the classloader is loading the new java class automatically. At the same time I can't find any doc describing this behavior. Any idea? Thanks! - 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: Off-topic question: Does Hibernate have a mailing list?
Why is the forum quiet? I count more than 30 new posts today. Guy Katz wrote: try http://www.hibernate.org/20.html -Original Message- From: Behrang Saeedzadeh [mailto:[EMAIL PROTECTED] Sent: Thursday, April 14, 2005 7:01 PM To: Tomcat Users List Subject: Off-topic question: Does Hibernate have a mailing list? Hi all Does anyone know if Hibernate have a mailing list or not? The Hibernate's forum is very quiet... Best Regards, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Garbage Collection
Calling System.gc() is considered to be a bad thing since this would trigger a major garbage collection which would take relatively long, compared with a minor collection. Besides this: Tomcat knows that it has nothing to do in right this moment. But does that mean that is always a good idea to make a GC now? No, maybe one millisecond later a new request will arrive and if Tomcat is then in GC, it is busy and cannot handle the request. I think this is the reason why Tomcat doesn't call the GC itself. Christoph Durfee, Bernard wrote: Right, my question was whether or not Tomcat would call System.gc() to 'suggest' to the JVM that garbage collection take place. Tomcat itself is the best authority as to how busy it is. Since Tomcat has been around for a long time I figured that this might have been implemented at some point. Bernard Durfee -Original Message- From: Pete Guyatt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 3:33 PM To: Tomcat Users List Subject: RE: Garbage Collection Hi There, Tomcat does not control the garbage collection, it is up to the JVM to decide if and when a garbage collection is performed. The only way you can request a garbage collection is by using the System.gc() method, which the JVM can ignore. For more information on this Topic read the documentation for the JVM that you are using. Pete -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: 12 April 2005 20:12 To: Tomcat Users List Subject: Garbage Collection How is garbage collection controlled in Tomcat 5.5? I ran a bit of an experiment by profiling Tomcat 5.5.7 while running a web application. I ran a load test against the application that finished with the allocated object size just below the heap size. If it grew any more, garbage collection would run. So the load test was done and with Tomcat idle, the garbage collector never ran. It would seem like a good time to run the garbage collector. As is stands now the next person to hit the application will push the heap size over the limit and they will have to wait for garbage collection. Seems like Tomcat should either attempt to trigger the garbage collector when idle. Bernard Durfee - 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: Garbage Collection
If you know that no or only few users are currently logged in, you can trigger System.gc() yourself. I think Tomcat has no reliable way to know how busy its webapps currently are. Durfee, Bernard wrote: I'd rather have a major garbage collection kick off with no users logged in vs. 100 users logged in. My application pulls data from a database and generates charts on the fly. Both of those operations require object creation. So my heap usage grows over time. My usage trends tend to be bunched, rather than constant. So in my case, more predictable garbage collection would be a great benefit. Bernard Durfee -Original Message- From: Christoph Kutzinski [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 4:32 PM To: Tomcat Users List Subject: Re: Garbage Collection Calling System.gc() is considered to be a bad thing since this would trigger a major garbage collection which would take relatively long, compared with a minor collection. Besides this: Tomcat knows that it has nothing to do in right this moment. But does that mean that is always a good idea to make a GC now? No, maybe one millisecond later a new request will arrive and if Tomcat is then in GC, it is busy and cannot handle the request. I think this is the reason why Tomcat doesn't call the GC itself. Christoph Durfee, Bernard wrote: Right, my question was whether or not Tomcat would call System.gc() to 'suggest' to the JVM that garbage collection take place. Tomcat itself is the best authority as to how busy it is. Since Tomcat has been around for a long time I figured that this might have been implemented at some point. Bernard Durfee -Original Message- From: Pete Guyatt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 3:33 PM To: Tomcat Users List Subject: RE: Garbage Collection Hi There, Tomcat does not control the garbage collection, it is up to the JVM to decide if and when a garbage collection is performed. The only way you can request a garbage collection is by using the System.gc() method, which the JVM can ignore. For more information on this Topic read the documentation for the JVM that you are using. Pete -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: 12 April 2005 20:12 To: Tomcat Users List Subject: Garbage Collection How is garbage collection controlled in Tomcat 5.5? I ran a bit of an experiment by profiling Tomcat 5.5.7 while running a web application. I ran a load test against the application that finished with the allocated object size just below the heap size. If it grew any more, garbage collection would run. So the load test was done and with Tomcat idle, the garbage collector never ran. It would seem like a good time to run the garbage collector. As is stands now the next person to hit the application will push the heap size over the limit and they will have to wait for garbage collection. Seems like Tomcat should either attempt to trigger the garbage collector when idle. Bernard Durfee - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Garbage Collection
BTW: If you are worried about gc pause time: have you trid the concurrent mark sweep garbage collector? Christoph Kutzinski wrote: If you know that no or only few users are currently logged in, you can trigger System.gc() yourself. I think Tomcat has no reliable way to know how busy its webapps currently are. Durfee, Bernard wrote: I'd rather have a major garbage collection kick off with no users logged in vs. 100 users logged in. My application pulls data from a database and generates charts on the fly. Both of those operations require object creation. So my heap usage grows over time. My usage trends tend to be bunched, rather than constant. So in my case, more predictable garbage collection would be a great benefit. Bernard Durfee -Original Message- From: Christoph Kutzinski [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 4:32 PM To: Tomcat Users List Subject: Re: Garbage Collection Calling System.gc() is considered to be a bad thing since this would trigger a major garbage collection which would take relatively long, compared with a minor collection. Besides this: Tomcat knows that it has nothing to do in right this moment. But does that mean that is always a good idea to make a GC now? No, maybe one millisecond later a new request will arrive and if Tomcat is then in GC, it is busy and cannot handle the request. I think this is the reason why Tomcat doesn't call the GC itself. Christoph Durfee, Bernard wrote: Right, my question was whether or not Tomcat would call System.gc() to 'suggest' to the JVM that garbage collection take place. Tomcat itself is the best authority as to how busy it is. Since Tomcat has been around for a long time I figured that this might have been implemented at some point. Bernard Durfee -Original Message- From: Pete Guyatt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 3:33 PM To: Tomcat Users List Subject: RE: Garbage Collection Hi There, Tomcat does not control the garbage collection, it is up to the JVM to decide if and when a garbage collection is performed. The only way you can request a garbage collection is by using the System.gc() method, which the JVM can ignore. For more information on this Topic read the documentation for the JVM that you are using. Pete -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: 12 April 2005 20:12 To: Tomcat Users List Subject: Garbage Collection How is garbage collection controlled in Tomcat 5.5? I ran a bit of an experiment by profiling Tomcat 5.5.7 while running a web application. I ran a load test against the application that finished with the allocated object size just below the heap size. If it grew any more, garbage collection would run. So the load test was done and with Tomcat idle, the garbage collector never ran. It would seem like a good time to run the garbage collector. As is stands now the next person to hit the application will push the heap size over the limit and they will have to wait for garbage collection. Seems like Tomcat should either attempt to trigger the garbage collector when idle. Bernard Durfee - 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] - 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: [ANN] Tomcat 5.5.9 voted stable
Yoav Shapira wrote: Please note that while all core features have been tested and voted stable, there is a known issue in this build related to the clustering module. The fix for this issue is available by itself at Bugzilla, and will be included in subsequent Tomcat releases. Again, this issue only impacts users of Tomcat's native clustering module. Where can I find information about this issue? I found nothing in the release notes. greetings, Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: One request per session
Hi, are you tying to prevent one user to only make one request at a time? Then a ServletFilter may serve your needs. Here : http://www.onjava.com/pub/a/onjava/2004/03/24/loadcontrol.html is a possible solution to restrict requests from one user. I haven't tried it myself yet, but the article sounds quite reasonable. HTH, Christoph Brij Naald wrote: Hi, i'm trying to test a locking system for servlets. I've made a chain of servlets which include each other: Servlet1 -- Servlet2 -- Servlet3 When Thread1 is in Servlet2, it puts a lock on Servlet1. That way if there is a new Request, this request (on thread2) wants to start with servlet1. Since there is a lock on it, it has to wait. When Thread1 gets into servlet3 it releases the lock, and Tread2 can start with Servlet1. This is what i've made already. (if there are any questions about this already, please ask!) Now I wanted to test it like this: To test the lock, a thread in servlet2 sleeps for 20 seconds. So thread1 first executes servlet1, then goes to servlet2, waits for 20 seconds and then goes on to servlet3. While thread1 is in servlet2 i have the time to start a new request. Now what do I see: The first request starts with servlet1, then goes to servlet2 and starts waiting 20 seconds. Now I push on the 'previous'-button of my browser, and make a new request. This second thread must wait since servlet1 is locked. This works. But now the problem: when the first thread has waited 20 seconds, it doesn't go to servlet3 anymore. -- Is there somekind of functionality that only one request per session is allowed or something like that? Thanks! _ - 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]
Validator 0.5.5 doesn't have this bug anymore (Re: OT - Beware of Firefox + HTML Validator Extension)
Good point, I stumbled upon this, too. Thinking this was a Firefox bug, I even filed a bug report against it. Note: The latest version of HTML Validator (0.5.5) fixed this bug. At least no more problems in my case. greetings, Christoph Harry Mantheakis wrote: I thought I should share this with any web-app developers on this list. I recently installed the HTML Validator extension in Firefox. This caused me no-end of troubles because HTML Validator (on Windows XP) was firing off rogue secondary requests (!) whenever I was selecting any of my form submit buttons. Then I read this blog entry, and realised who the culprit was: http://ronin.keyboardsamurais.de/evil_firefox_extensions.html I uninstalled the HTML Validator extension and everything was fine again. Kudos to the LiveHTTPHeaders extension which showed the double requests being generated - though at first it made me think I had a faulty mouse! http://livehttpheaders.mozdev.org/ HTH somebody who may be pulling their hair out. Harry Mantheakis London, UK - 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: Tomcat5.0.x - Proxy (pippoProxy)
I have no experience with it. But this article might be helpful for you: http://www.javaworld.com/javaworld/jw-02-2005/jw-0228-pippo.html Acácio Furtado Costa wrote: Hi list, Does anyone know about Pippo Proxy?. This is a 100% pure Java HTTP proxy designed and implemented for TomCat. IF so, Is it using in production environment ? what a result ? and about a security? Thanks Acacio Furtado Costa Pesquisa e Tecnologia GIA - Magnesita S/A ((0xx31) 3368-1349 * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 java.lang.outOfMemory
Solution a: Increase the heap memory further Solution b: Decrease the memory usage of your application Francesco Pellegrini wrote: Hi all, I have an environment with Tomcat 5.0.19 and java 1.4.02, on windows 2000 server platform. Tomcat 5 was installed with Services. I have changed in catalina.bat : set CATALINA_OPTS= -server -Xmx1200m -Xms1200m -Xss256k Usually the sistem works fine, but when I try to find a lot of data (in the database) using jsp, i got this error: javax.servlet.ServletException org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextI mpl.java:867) org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImp l.java:800) org.apache.jsp.pannelli.telematica.visconsumi_jsp._jspService(visconsumi_jsp .java:810) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:3 11) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) root cause java.lang.OutOfMemoryErrorHow can I solve this issue?Thanks in advanceFrancesco. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using new JDK 5.0 language features with Tomcat 5.5?
AFAIK the eclipse JDT compiler, that is used per default to compile the JSPs, doesn't support JDK 5.0 features. So you mustn't use these features in JSPs or change the JSP compiler. Christoph Petr Jiricka wrote: Hello list, is it safe to use the new JDK 5.0 language features, e.g. annotations and generic types, with Tomcat 5.5? Do people do this in practice? Was this tested extensively? Are there any known issues in this area? Please let me know your experience with using new JDK 5.0 constructs with Tomcat. The reason I am asking is because the J2EE 1.4 specification mandates JDK 1.4 as the baseline, and all compliant servers must work reliably with JDK 1.4. There is no such requirement for JDK 5.0, so any applications that exploit the new JDK 5.0 constructs are technically non-portable and non-compliant with J2EE 1.4. Thanks Petr - 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: Using new JDK 5.0 language features with Tomcat 5.5?
Rodrigo Avila wrote: since we're talking about that... I have a system running *perfectly* using Tomcat 5.0.28 and Java 1.4.2_07. But I think in migrate this system to Java 1.5.0_01 using Tomcat 1.5.7, in an Production server. My question is: have any problem in make this migration? What is the group opinion? Restrictions? Problems in using an newer jre in an production server? We are using Java 1.5.0 with Tomcat 5.0.28 in a production environment since november. We didn't have any problems since then. At least related to the JDK ;-) Actually we had some problems which I suspected to be related to the JDK, but switching back to 1.4.2_05 didn't fix it, so we stayed with 1.5.0. We hope to make the jump to Tomcat 5.5 in the near future, too. Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.8 release timeframe?
5.5.8 is already released, but it is marked as alpha. Andy Kriger wrote: I've read the FAQ regarding 'when it's ready' and I haven't seen anything about this in the mailing list archives, however, I still need to be able to answer this question for my boss. We started up the 5.5 path with .4, which had a bug with POST and basic auth that required upgrading to .7 which has a bug with DataSources not closing connections that is fixed in .8 - can anyone give a timeframe for a 5.5.8 release? A rough scale would be fine - days? weeks? months? Even a guesstimate based on experience with how long previous alpha's took to release would help me ease my boss's concerns. thx andy - 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: Getting other Sessions
Hi, looks to me that this was included in a previous version of the API, but was removed for security reasons: http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpSessionContext.html Therefore the only way to get all sessions is probably a SessionListener. HTH Christoph Dale, Matt wrote: Hi, That doesn't answer Joseph's question. It tells him how to access the objects in his own session but not how to access other peoples sessions. I would be interested to see how this is done as well. Ta Matt -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: 23 February 2005 09:17 To: 'Tomcat Users List' Subject: AW: Getting other Sessions Hi, HttpSession.getAttributeNames() should do what you want! From the javadoc: getAttributeNames public java.util.Enumeration getAttributeNames() Returns an Enumeration of String objects containing the names of all the objects bound to this session. Cheers Bernhard -Ursprüngliche Nachricht- Von: Joseph Shraibman [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 23. Februar 2005 05:18 An: tomcat-user@jakarta.apache.org Betreff: Getting other Sessions I want to make an admin page in my application. I needs to be able to get access to all the current Session objects to access their attributes. Is this possible? - 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] Any opinions expressed in this E-mail may be those of the individual and not necessarily the company. This E-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this E-mail in error and that any use or copying is strictly prohibited. If you have received this E-mail in error please notify the beCogent postmaster at [EMAIL PROTECTED] Unless expressly stated, opinions in this email are those of the individual sender and not beCogent Ltd. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. - 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: Problem with HTTPServletRequest
Hi, Peter Monz wrote: Hi All, I have quite a problem with HTTPServletReuquest in some Servlets sometimes. Sometimes if I access HTTPServletRequest in Servlet I get only a null-Pointer and my Servlet crashes. But I can see in a HTTP-trace, created with a spy programm that the date will be sent from the browser to the apache server. -- Is there a konw problem? Someone told me that happens because I use the post- and the get-method at same time: e.g.: form action=/servlet/test?send=y method=post input type=text size=20 name=test2 /form if you suspect this to be the problem, why you don't try it with only post? e.g.: form action=/servlet/test method=post input type=hidden name=send value=y input type=text size=20 name=test2 /form Greetings Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpSession usage
Pawson, David wrote: Which then raises the question, do I (can I) check that a user has cookies enabled? HttpSession sess = request.getSession(true); if( sess.isNew() ) logger.info(pNew Session/p); else logger.info(pExisting Session/p); Hi, check the API. You can probably use: request.|*isRequestedSessionIdFromCookie http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpServletRequest.html#isRequestedSessionIdFromCookie%28%29*() HTH Christoph | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is tomcat (java) so memory intensive?
Philippe Deslauriers wrote: I am using Tomcat 5.0.19 on Windows XP SP2, J2SDK 1.4.2_03. I have a serious memory problem with Tomcat, it just EAT memory without explanation, until OOM error occurs. The Java.exe process in the windows task manager reports using between 95Mb and 105Mb after the startup of the webapp. I do not use Xms Xmx options in dev mode. You do know that the VM will only allocate 64 mb for heap if you don't use the Xmx option, do you? After the 64 mb are used up the vm will throw an oom error. How much memory does the taskmanager report before the oom error happens? Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leak with Javac and Tomcat v. 4.0.28
Dakota Jack wrote: I was going to update my Tomcat from 4.0.19 because it says there is a javac leak in the RELEASE-NOTES. However, I noticed that 4.0.28 says the same thing. Is it fixed/ Jack AFAIK this is no Tomcat issue but a JDK/Javac issue which was fixed in Sun JDK 1.4. See: http://www.apache.de/dist/jakarta/tomcat-5/v5.0.29/RELEASE-NOTES HTH Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chirag: Can Tomcat Server be surfed from the Machine where the Server it is running
Chirag wrote: I think tomcat-5.5.2 cannot work in JDK1.4 Am I correct I mean as per this page http://apache.mirrors.hoobly.com/jakarta/tomcat-5/v5.5.4/README.html It says though it is of version 5.5.4 that it requires Tomcat 5.5 requires JRE 5.0 by default You can install a compatibility package to make it run on JDK 1.4 See: http://apache.mirrors.hoobly.com/jakarta/tomcat-5/v5.5.4/RELEASE-NOTES - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session expiry and SessionListener problems with cluster
Hi,
yes I already did know what this parameter means (though I only realised
it after reading the source code ;), so the behaviour I described makes
probably sense in this context.
But my concern is the following:
If a cluster completely fails, i.e. all nodes on the cluster crash
(which is not so unlikely with small 2-3 node clusters), the session
data is completely lost even if I can restart all nodes immediately.
In our case we have a cluster of just 2 nodes and we want to use a
tomcat session replication (among other points) to be able to update the
webapps without killing all user session on a node. So we would first
stop Tomcat A, update its webapp, restart tomcat A and then the same for
Tomcat B. If Tomcat B would now die while Tomcat A is down all session
information would be lost.
I wanted to know if there is a way to handle this kind of situation.
TIA
Christoph
PS: do you have any information regarding point b?
Filip Hanik - Dev wrote:
expireSessionsOnShutdown=false - on shutdown - expire sessions locally, but
do not propagate to the cluster
expireSessionsOnShutdown=true - on shutdown - expire sessions locally, and
propagate to the cluster
stupid name for the variable, I agree
- Original Message -
From: Christoph Kutzinski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 09, 2004 8:00 AM
Subject: Session expiry and SessionListener problems with cluster
Hi,
I'm just playing with the Tomcat 5.5.4 cluster and encountered 2 oddities:
a) If have left expireSessionsOnShutdown=false in the configuration
I understand that this will expire the session in the local node but
leave it alive in the other cluster nodes.
However I found out that the session will expire in the local node on
shutdown even if there are no other nodes in the cluster. So the session
will be lost after restart.
Is this expected behaviour or a bug?
b) I implemented a session listerner for attributes.
I noticed that the attributeAdded event from DeltaManager always return
null as the value of the event where the normal session manager will
return the value of the attribute added. Sourcecode:
public void attributeAdded(HttpSessionBindingEvent evt) {
// == null with DeltaManager, != null otherwise
Object value = evt.getValue();
// != null in both cases
Object value1 = evt.getSession().getAttribute(evt.getName());
}
Is this a bug?
Thanks in advance,
Christoph
-
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]
Session expiry and SessionListener problems with cluster
Hi,
I'm just playing with the Tomcat 5.5.4 cluster and encountered 2 oddities:
a) If have left expireSessionsOnShutdown=false in the configuration
I understand that this will expire the session in the local node but
leave it alive in the other cluster nodes.
However I found out that the session will expire in the local node on
shutdown even if there are no other nodes in the cluster. So the session
will be lost after restart.
Is this expected behaviour or a bug?
b) I implemented a session listerner for attributes.
I noticed that the attributeAdded event from DeltaManager always return
null as the value of the event where the normal session manager will
return the value of the attribute added. Sourcecode:
public void attributeAdded(HttpSessionBindingEvent evt) {
// == null with DeltaManager, != null otherwise
Object value = evt.getValue();
// != null in both cases
Object value1 = evt.getSession().getAttribute(evt.getName());
}
Is this a bug?
Thanks in advance,
Christoph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Sessions...is this a Tomcat bug?
Gabriel Belingueres wrote: Hi, I just discovered a weird thing: I have a Tomcat 4.1.12 running in my machine, which is called ale2000, and I test my app using http://localhost:8080/xx as the url (not the machine name configured in Windows) When some of the html page make a request to the app, using http://ale2000:8080/xx, Tomcat creates other session object, instead of reusing the same session originally created when I call it the first time using http://localhost:8080/xx Is this behavior correct? Doesn't it better to create other session based on different IP addresses, instead of different machine names? IMO this is correct. Cookies are attached to server names instead of IPs. Imagine what would happen if you have multiple virtual servers on a machine and session cookies would be per ip (=the same for all servers) instead per server. HTH Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
