RE: setclasspath scripts
I contributed the patch for the Unix scripts (because they mattered to me). The windows scripts were a low priority because it was assumed that people running Tomcat from them (as opposed to running it as a service or the start menu items) would be developers and would have a full JDK. See: http://issues.apache.org/bugzilla/show_bug.cgi?id=32081 On Mon, 2005-07-11 at 14:22, Fenlason, Josh wrote: Then why the difference between the Unix and Windows setclasspath scripts? Thanks. , Josh. -Original Message- From: Yoav Shapira [mailto:[EMAIL PROTECTED] Sent: Monday, July 11, 2005 1:18 PM To: 'Tomcat Developers List' Subject: RE: setclasspath scripts Hey, Yeah: 5.5 requires only the JRE, not JDK. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Fenlason, Josh [mailto:[EMAIL PROTECTED] Sent: Monday, July 11, 2005 2:11 PM To: tomcat-dev@jakarta.apache.org Subject: setclasspath scripts In Tomcat 5.5.9 setclasspath.sh, tools.jar is only conditionally added to the classpath. if [ $1 = debug -o $1 = javac ] ; then CLASSPATH=$JAVA_HOME/lib/tools.jar fi setclasspath.bat unconditionally add tools.jar to the classpath. set CLASSPATH=%JAVA_HOME%\lib\tools.jar In Tomcat 5.0.30 setclasspath.sh and setclasspath.bat tools.jar is unconditionally added to the classpath. Is there a reason why this changed, and only on Unix, between releases? Thanks. , Josh. - 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] -- Ben Souther F.W. Davison Co. CONFIDENTIALITY NOTICE: This e-mail message, and any accompanying documents, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or copying is prohibited. If you are not the intended recipient, please contact our office by email or by telephone at (508) 747-7261 and immediately destroy all copies of the original message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Change Log app
Can anyone tell me what app this project uses for maintaining the changlog? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Change Log app
Thanks On Thu, 2005-03-31 at 10:03, Yoav Shapira wrote: Hi, No app. Committers individually and manually update the changelog when they make changes. Yoav -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: Thursday, March 31, 2005 9:44 AM To: Tomcat Developers List Subject: [OT] Change Log app Can anyone tell me what app this project uses for maintaining the changlog? - 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: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Al, I read it thoroughly. Remy Maucharat didn't mention the platform he had tested on until the 7th post and by then Yoav Shapira had already stated that he tested it as well (with no mention of the platform). They also agreed that the case would be re-opened if you could help them to reproduce the problem. My criticism is that you mentioned a developer from the users list who also claimed to have problems shutting down Tocmat which would seem to bolster your case -- except that he never mentioned whether or not he was starting his own threads in his application. You did not, however, mention that I tested on the exact same distribution that you're having problems on with a fresh download of TC and it ran fine. If you're serious about getting to the root of the problem, which I think you are, it's important that all facts are on the table -- even the ones that don't support your argument. -Ben On Thu, 2005-02-03 at 01:43, Al Sutton wrote: Ben, Please re-read my email. It is discussing the initial response I received from the -dev list, and then addressing the issue raised about it being distribution specific. My critisism was that the bug was initially closed when the only attempt to re-produce it I was made aware of was made on a completely different platform and that it initially appeared that the -dev list did not have developers that were willing to investigate the problem. Regards, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 22:25 To: Tomcat Developers List Subject: RE: DO NOT REPLY [Bug 9] - Shutdown script down not work On Wed, 2005-02-02 at 16:54, Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. Just for the record, I tested on FC2 and posted the shell session on the users list. You responded to my email before writing this message. I've also stated that I'm willing to upgrade both the kernel and the JDK to test under an environment that is closer to yours. Please don't omit these details when when writing to either list. At the very least, it's dishonest, at worst it's misleading and could cause people to waste time repeating things that have already been done. -Ben - 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: RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
I have since made a post with what I beleive to be potential fixes to resolve the problem. I saw that post. All other bantering aside, it's good you found the problem. I hope you will add your findings to the bug report so someone else with a similar problem doesn't have to retrace all of your steps before finding the solution. I realize you were insulted by the tone of the initial responses you received. I wasn't taking sides on that issue. I just wanted to make sure that, in spite of hurt feelings, all the details were accurately reported in every discussion so that someone else researching the same issue six months from now doesn't miss an important detail. Again, I'm glad you found the problem. Congrats :-D -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
On Wed, 2005-02-02 at 16:54, Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. Just for the record, I tested on FC2 and posted the shell session on the users list. You responded to my email before writing this message. I've also stated that I'm willing to upgrade both the kernel and the JDK to test under an environment that is closer to yours. Please don't omit these details when when writing to either list. At the very least, it's dishonest, at worst it's misleading and could cause people to waste time repeating things that have already been done. -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Case insensitive URLs: Issue #32806
This is a continuation of the discussion here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=32806
Ben, I understand the example you posted as comment #8 but I
feel this is best handled in release notes. You should dedicate a
section to migration notes and discuss this and many other concerns.
I'm sure case-sensitivity is only one of many potential concerns with
migrating or upgrading Tomcat. Aside from the example you gave (caused
by migration) are there any other security concerns?
Thank you,
Gili
To be honest with you, I don't know. I, personally, prefer case
sensitive environments. With the exception of IIS, I've never had to
work with an app server that wasn't case-sensitive. When I type 'a', I
mean 'a', not ('a' or 'A'). For that reason, I've never researched the
issue.
Since the naming convention in Java depends on case-sensitivity, I
suspect that the majority of Servlet/JSP developers feel the same way.
Pursue it if you like but I suspect it will fall on deaf ears, both here
and with the Spec group.
When in Rome. ;)
-Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Case insensitive URLs: Issue #32806
Just like code-formatters fix bad style they should handle case sensitivity all over the place to make sure people use the same casing everywhere. Bad style is not a compiler error :) In a language intended to be cross platform case-sensitivity is not a matter of style. For better or worse, Unix looks for files in a case-sensitive manner. If a developer is serious about being able to write once and run anywhere then making sure the search strings are written in the proper case is not a subjective issue. I'm sure we could go back and forth for days and never come to an agreement. I'm also sure that no one else on this list would appreciate us doing so here, so I'm dropping out now. Good-Luck (sort of ;) - Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to add variables into WEB-INF/web.xml or META-INF/*.* ?
I should want to add variables like ODBC name into %Tomcat-webapps%/WEB_INF/web.xml. How can you do it? How do you use it in java code (jsp, servlet, basic class). You will want to read up on context initialization parameters and servlet initialization parameters. For a context init param (application wide) you would enter something like this in your web.xml file: context-param param-name welcome-message /param-name param-value The value of this message is stored in a context init param /param-value /context-param Then to retrieve the parameter from a servlet: getServletContext().getInitParameter(welcome-message)); or from a JSP: %=application.getInitParameter(welcome-message)% If you're interested, there is an example app you can download at: http://simple.souther.us look for Simple Context Init Params - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to add variables into WEB-INF/web.xml or META-INF/*.* ?
One more thing... This question belongs in the Tomcat User's List. The dev list is for people who are building Tomcat. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[doc] First App - Example App
Hello, The Example App link at the end of the First App tutorial http://jakarta.apache.org/tomcat/tomcat-5.5-doc/appdev/sample is a bit misleading when viewed off the Apache site from the web. When you click on it, it displays an Apache directory listing. From there, you can drill into the src directory to get the servlet code but when you try to drill into the web directory the index.html page gets shown and leads the viewer into thinking that this is a working app. It's not. When you click on the To a servlet link you see a 404 error and when you click on the To a JSP page link you see the JSP code (which looks like the output from a JSP page displayed as text because there are no JSP scriptlet tags in it). I understand that the intent is for the viewer install TC, follow the entire tutorial and actually deploy the examples to his/her own machine, and then run it from there, but a casual surfer (or worse a struggling newbie) will just see this as a non-working app with broken links. Has anyone considered building the app, WARing it up, and putting an index.html page at http://jakarta.apache.org/tomcat/tomcat-5.5-doc/appdev/sample/ with a link to the war file and some basic instructions for either running or unpacking the file to get to the src that goes with the tutorial? If this is a good idea, I'd be willing to build the war files and HTML pages. - Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.5.4 ?
One way to make things more consistent without affecting performance would be for the deployer not to deploy apps with spaces in the context path. This would be a lot easier to debug than the current behavior and may prevent this bug from being reported again. On Tue, 2004-10-26 at 08:45, Shapira, Yoav wrote: Hi, Looks like a RESOLVED-WONTFIX ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 5:06 PM To: Tomcat Developers List Subject: Re: 5.5.4 ? Yes, I had tested it a little earlier, and it doesn't work. The path would apparently have to be encoded in the same way as the URL. OK, let me know if I can help. Quite frankly, I'm not sure we're going to do this, since the encoding on the client side is quite unpredictable. Other than helping out and trying to learn the code, I have no interest in seeing this one resolved. IMHO: it's a little absurd to have to support spaces in a context path since a browser will never send a URL with a space in it. -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.4 ?
On Mon, 2004-10-25 at 11:48, Remy Maucherat wrote: Shapira, Yoav wrote: Hi, What are the plans for 5.5.4 ? I want to resolve (either fix or invalid, whatever) Bugzilla 31090 I should have fixed that one, but I'm not sure, so someone needs to test it. Just tested with: jakarta-tomcat-5-bin-20041024.tar.gz and the problem still exists. I can test build from the CVS head tonight and test if you think it's different. -Ben (space in context name makes session IDs crap, 31372 (AuthenticatorBase#register method), the couple of doc items, and So that there are no surprises, I'm -1 for the patch proposed in the bug report. possibly 31656 (make Tomcat build with Struts 1.2). This week looks lighter at work so next weekend seems like something good to shoot for. Is it actually better ? ;) (= faster startup, for example) How about Saturday, October 30th (cut time TBD) for the 5.5.4 release? Ok. Rmy - 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: 5.5.4 ?
Yes, I had tested it a little earlier, and it doesn't work. The path would apparently have to be encoded in the same way as the URL. OK, let me know if I can help. Quite frankly, I'm not sure we're going to do this, since the encoding on the client side is quite unpredictable. Other than helping out and trying to learn the code, I have no interest in seeing this one resolved. IMHO: it's a little absurd to have to support spaces in a context path since a browser will never send a URL with a space in it. -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: DefaultServlet and getOutputStream() / getWriter()
Steffen,
Compile, run, and view the output from this program.
I think you'll see the difference :o)
public class Loop{
public static void main(String[] args){
System.out.println(Try-Catch inside loop:);
for(int i = 0; i 10; i++){
try{
System.out.println(String.valueOf(i));
if(i == 5) i = i / 0;
}catch(Exception e){
e.printStackTrace();
}
}
System.out.println(\nLoop inside try-catch);
try{
for(int i = 0; i 10; i++){
System.out.println(String.valueOf(i));
if(i == 5) i = i /0;
}
}catch(Exception e){
e.printStackTrace();
}
}
}
On Tue, 2004-10-12 at 13:43, Steffen Heil wrote:
Hi
The rewritten while{} patch you suggested definitely changed behavior
significantly, as I and others pointed out ;)
hm, no.
Sorry to say that, but I think, you didn't review the code for that
statement:
One example taken from DefaultServlet.java, lines 2030 to 2054:
IOException exception = null;
long bytesToRead = end - start + 1;
char buffer[] = new char[input];
int len = buffer.length;
while ( (bytesToRead 0) (len = buffer.length)) {
try {
len = reader.read(buffer);
if (bytesToRead = len) {
writer.write(buffer, 0, len);
bytesToRead -= len;
} else {
writer.write(buffer, 0, (int) bytesToRead);
bytesToRead = 0;
}
} catch (IOException e) {
exception = e;
len = -1;
}
if (len buffer.length)
break;
}
return exception;
THIS IS EQUAL TO:
IOException exception = null;
long bytesToRead = end - start + 1;
char buffer[] = new char[input];
int len = buffer.length;
try {
while ( (bytesToRead 0) (len = buffer.length)) {
len = reader.read(buffer);
if (bytesToRead = len) {
writer.write(buffer, 0, len);
bytesToRead -= len;
} else {
writer.write(buffer, 0, (int) bytesToRead);
bytesToRead = 0;
}
if (len buffer.length)
break;
}
} catch (IOException e) {
exception = e;
len = -1;
}
return exception;
OR EVEN:
long bytesToRead = end - start + 1;
char buffer[] = new char[input];
int len = buffer.length;
try {
while ( (bytesToRead 0) (len = buffer.length)) {
len = reader.read(buffer);
if (bytesToRead = len) {
writer.write(buffer, 0, len);
bytesToRead -= len;
} else {
writer.write(buffer, 0, (int) bytesToRead);
bytesToRead = 0;
}
}
return null;
} catch (IOException e) {
return e;
}
I am very sure about this.
And I also do NOT understand, why the exception is reported as result and
not really thrown.
The caller always uses:
IOException exception = null;
while ( (exception == null) (ranges.hasMoreElements()) ) {
exception = copyRange(istream, ostream, currentRange.start,
currentRange.end);
...
}
ostream.println();
ostream.print(-- + mimeSeparation + --);
// Rethrow any exception that has occurred
if (exception != null)
throw exception;
Whereas it would absolutely make more sense to me NOT to catch the Exception
but rather use:
try {
while ( ranges.hasMoreElements() ) {
copyRange(istream, ostream, currentRange.start,
currentRange.end);
...
}
} finally {
// if nessesary, put code to ensure istream is closed here.
ostream.println();
ostream.print(-- + mimeSeparation + --);
}
This is what try-finally is all about, isn't it?
I agree, that I am new to this and I might be wrong, but this leads me back
right to where I started. Whom to ask to understand the existing code?
When you're looking at the code, keep in mind that Tomcat's DefaultServlet
(like virtually every other Tomcat component) can be extended or wrapped.
Such wrappers or extenders could call getWriter first.
Ok, I forgot about includes and such.
I'm happy you're looking at the code. If
Re: AW: AW: DefaultServlet and getOutputStream() / getWriter()
This is the code that I saw (from the beginning of this discussion on
the user's list).
begin quote--
PS: Since I am already sending another mail, let me append a pending
question:
I often see code like this in the servlet:
while (...) {
try {
...
} catch ( ... ) {
...
}
}
which could be replaced with
try {
while (...) {
...
}
} catch ( ... ) {
...
}
which is faster in my imagination.
Is there a reason or is my imagination false?
end quote--
If the discussion has moved on to something else, then I apologize for
wasting your time.
-Ben
On Tue, 2004-10-12 at 15:31, Steffen Heil wrote:
Hi
Compile, run, and view the output from this program.
I think you'll see the difference :o)
Sorry, but did you actually read the code it posted?
I KNOW that there CAN be a difference in semantics.
YOUR code has different semantics.
BUT in the code I POSTED there is NONE !
So, please read it first.
Regards,
Steffen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: DefaultServlet and getOutputStream() / getWriter()
Martin,
The question wasn't which is better?. The question was are the two
functionally the same? which as you've pointed out, they're not.
Steffen,
Looking at the (longer) code example that you posted, I can see that in
both cases there is logic to stop the iteration if there is a problem.
So, in this case, you may be correct.
I think the larger point that Yoav and Remmy were both trying to make is
that evaluating a newcomer's re-factored code is as time consuming as
refactoring it themselves. If it means getting a bug fixed or a MAJOR
performance gain, then it's worth it but to risk overlooking something
subtle and breaking a core component for a small gain in efficiency or
just to neaten the code is not worth the risk.
On Tue, 2004-10-12 at 16:08, Martin Gainty wrote:
Ben
In the first case the while contains the logic and doesnt allow the program
to exit until until the while condition goes false..
In the second case the try/catch allows the exception to propagate up to the
caller as soon as the exception is caught
Personally I would use the 2nd approach..
Good Catch!!!
Martin-
- Original Message -
From: Ben Souther [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 12, 2004 3:42 PM
Subject: Re: AW: AW: DefaultServlet and getOutputStream() / getWriter()
This is the code that I saw (from the beginning of this discussion on
the user's list).
begin quote--
PS: Since I am already sending another mail, let me append a pending
question:
I often see code like this in the servlet:
while (...) {
try {
...
} catch ( ... ) {
...
}
}
which could be replaced with
try {
while (...) {
...
}
} catch ( ... ) {
...
}
which is faster in my imagination.
Is there a reason or is my imagination false?
end quote--
If the discussion has moved on to something else, then I apologize for
wasting your time.
-Ben
On Tue, 2004-10-12 at 15:31, Steffen Heil wrote:
Hi
Compile, run, and view the output from this program.
I think you'll see the difference :o)
Sorry, but did you actually read the code it posted?
I KNOW that there CAN be a difference in semantics.
YOUR code has different semantics.
BUT in the code I POSTED there is NONE !
So, please read it first.
Regards,
Steffen
-
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: Javabeans.
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html On Wednesday 24 December 2003 12:13 pm, geek J wrote: I configured Tomcat 4.0 with Java 1.4.1. I need to work JSP with Javabeans. In that case where I need to place all my class files in Tomcat package and where I need to place all my JSP files.? -- Ben Souther F.W. Davison Company, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Urgent !! Help needed regarding Tomcat web server !!
how can i set Path CLASSPATH variable? Go here: http://java.sun.com/docs/books/tutorial/getStarted/cupojava/index.html Once you learn how to set up your classpath, make sure you add servlet.jar to it. Servlet.jar can be found in the TOMCAT_HOME/common/lib directory. Good luck On Thursday 11 December 2003 07:47 am, you wrote: Hi All, I am using TOMCAT for jsp/servlet deployment. When I am compiling a servlet class it gives an exception that javax.servlet.* not found. javax.servlet.http.* not found. What should i do to remove this exception, so that java file gets compile successfully. how can i set Path CLASSPATH variable? I am using WindowXP. pls help me asap. Refards Gyan __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.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: PB when build TC5 from cvs
FYI: I found this message while googling for the same problem with the build breaking just after 12/06/2003 on my linux box. Upgrading ANT from vs 1.5.1 to the latest (1.6beata3) fixed it. I traced the problem back a little bit and found that the generated_web.xml file in the examples app was present but empty. I didn't dig much further. Maybe the instructions at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/building.html will need to specify a more recent version of ANT? Re: PB when build TC5 from cvs * From: jean-frederic clere * Subject: Re: PB when build TC5 from cvs * Date: Tue, 11 Nov 2003 05:07:55 -0800 Remy Maucherat wrote: jean-frederic clere wrote: Hi, I have the following error: +++ build-webapps-precompile: [jasper2] 11-Nov-2003 12:09:04 org.apache.jasper.JspC processFile [jasper2] SEVERE: ERROR-the file '/jsp2/tagfiles/products.jsp' generated the following general exception: [jasper2] org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: XML parsing error on file /WEB-INF/jsp/debug-taglib.tld: (line 307, col 39) [jasper2] at org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:210) [jasper2] at org.apache.jasper.compiler.TldLocationsCache.getLocation(TldLocationsCache.java:181) +++ Any hints? I did upgrade from CVS, and it works for me (on Windows, with the 1.4.2_02 JDK). The products example did get compiled correctly, and runs OK (precompiled). Maybe it's a Unix problem ? I have removed all sources and check out them (again) from cvs, now it builds Ok. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[patch] jsp:getProperty tag prints null to page when object is null.
In version 4x and earlier, a jsp:getProperty tag will print a zero length
string to the page if the bean's property value is null.
In version 5x it prints the string null.
I don't know if this is a bug or an intentional change but I know it will
cause headaches for developers moving existing apps to version 5.
The attached patch applies to
org.apache.jasper.runtime.JspRuntimeLibrary.java
Thank you,
Ben Souther
--- JspRuntimeLibrary.java Thu Dec 4 20:51:54 2003
+++ JspRuntimeLibrary.java.fixed Thu Dec 4 20:19:01 2003
@@ -426,6 +426,7 @@
//---
// __begin toStringMethod
public static String toString(Object o) {
+if(o == null) return ;
return String.valueOf(o);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
