You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@apache.org on 2001/02/11 20:27:32 UTC
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime JspWriterImpl.java
costin 01/02/11 11:27:32
Modified: src/share/org/apache/jasper/runtime JspWriterImpl.java
Log:
Fix the System.getProperty("line.separator") problem in JspWriter.
( it was causing most of the failures in the nightly tests for sandboxed
tomcat ).
This adds another dependency between jasper and tomcat.util ( the first is
tomcat.util.log, now tomcat.util.compat ). Since both packages are completely
standalone and can be bundled with jasper, I don't think it'll be a problem.
( of course, a better solution would be to have the general-purpose tools
in a org.apache.util.{log,compat}, there is no reason to keep them in tomcat )
Revision Changes Path
1.5 +17 -4 jakarta-tomcat/src/share/org/apache/jasper/runtime/JspWriterImpl.java
Index: JspWriterImpl.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspWriterImpl.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JspWriterImpl.java 2000/06/30 20:21:03 1.4
+++ JspWriterImpl.java 2001/02/11 19:27:32 1.5
@@ -1,7 +1,7 @@
/*
- * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspWriterImpl.java,v 1.4 2000/06/30 20:21:03 costin Exp $
- * $Revision: 1.4 $
- * $Date: 2000/06/30 20:21:03 $
+ * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspWriterImpl.java,v 1.5 2001/02/11 19:27:32 costin Exp $
+ * $Revision: 1.5 $
+ * $Date: 2001/02/11 19:27:32 $
*
* ====================================================================
*
@@ -72,6 +72,7 @@
import javax.servlet.jsp.JspWriter;
import org.apache.jasper.Constants;
+import org.apache.tomcat.util.compat.*;
/**
* Write text to a character-output stream, buffering characters so as
@@ -382,7 +383,19 @@
}
- static String lineSeparator = System.getProperty("line.separator");
+ static String lineSeparator;
+ static {
+ Jdk11Compat jdk11Compat=Jdk11Compat.getJdkCompat();
+ try {
+ lineSeparator = (String)jdk11Compat.doPrivileged( new Action() {
+ public Object run() throws Exception {
+ return System.getProperty("line.separator");
+ }
+ });
+ } catch( Exception ex ) {
+ lineSeparator="\r\r";
+ }
+ }
/**
* Write a line separator. The line separator string is defined by the
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime JspWriterImpl.java
Posted by Stephane Bailliez <ba...@noos.fr>.
----- Original Message -----
From: <cm...@yahoo.com>
[...]
> Someone who needs only jasper can take the utils and jasper package.
> ( duplicating some of the classes in 2 package may have negative impact on
> class loading - it may throw "Sealing" exceptions )
My apologize for my intervention in this discussion, but I second you on
that.
Here are my reasons:
I have been playing a lot lastly with jaxp1.1 and crimson who had the good
idea (but surprising at the beginning) to do package sealing. This caused
lots of problems in my development environment because a lot of people are
packaging the jars a little bit like: "put everything we can inside it to
deliver only a single jar".
For instance it was impossible to run Resin 1.1.4 with crimson. Why ?
Because the w3c and sax interfaces were buried into Resin.
Right now if you want to use the latest xalan and xerces, you'll have 2
times jaxp, 2 times dom and 2 times sax. You want to try jaxp1.1ea2..mmm you
have to play with the classpath order instead of simply 'replacing' it.
If you look at the existing JMS providers and that you want to try them all
you can be pretty sure you don't need all interfaces around jms ... each of
them has interfaces packaged into the jar. If you mix all JMS providers, you
end up with the full necessary classpath to compile whatever you're doing
with jms.
Another tricky thing, I was using XT for XSL transformation and another web
module was using the old sax.jar in an applet. The lib repository was a
single .lib directory with all jars and each module was referencing its
needed jar.
When I was running my XT dependent module (who was using crimson), I ended
up with a sealing violation. It took me a while to realize that...it was due
to xt that had a Class-Path: sax.jar in its manifest and was thus loading a
jar I didn't want.
That is, in a complex product, you probably end up with 10 times the
necessary classes and you'd better have the exact same version otherwise
you'll be doing some tricks with the classpath order until you realize its
not possible in certain cases, so what choice do you have ? cut the
distibuted jar in pieces ?
Just my $0.01.
Stephane
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime
JspWriterImpl.java
Posted by cm...@yahoo.com.
>
> > This adds another dependency between jasper and tomcat.util ( the first is
> > tomcat.util.log, now tomcat.util.compat ). Since both packages are completely
> > standalone and can be bundled with jasper, I don't think it'll be a problem.
>
> Comments:
>
> I don't personally see a problem with Jasper requiring Tomcat, but I do see
> a problem with the other way around. :-)
Tomcat3.3 doesn't have any dependency on jasper in core or utils.
JspInterceptor is the only piece that depends ( via a Liaison - which
takes full advantage of all jasper APIs.).
Jasper has no dependency on tomcat internals, except 2 general-purpose
utils which are shared.
> HOWEVER, I'm not sure what other corporations will think about this. People
> who want to bundle Jasper without Tomcat (ie: IBM) may not like this at
> all...even if the Tomcat stuff is standalone.
Jasper already had a dependency of a "shared" util ( util.log), this fix
just adds a second one ( util.compat ). That means someone integrating
Japser in a different container needs to add the 2 shared utils.
> Maybe a good idea would be to change the build scripts to package the
> jasper.jar file with *everything* it needs to run standalone...even if it
> means duplicating a couple .class files.
The build scripts are already doing something like that - all
"shared utils" are packaged in tomcat_util ( can be renamed
"shared_utils" or soemthing like that ).
The utils have no external dependencies, and the only thing they have in
common with tomcat is the package name ( org.apache.tomcat.util ).
Someone who needs only jasper can take the utils and jasper package.
( duplicating some of the classes in 2 package may have negative impact on
class loading - it may throw "Sealing" exceptions )
--
Costin
Re: cvs commit:
jakarta-tomcat/src/share/org/apache/jasper/runtime JspWriterImpl.java
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/11/01 11:27 AM, "costin@apache.org" <co...@apache.org> wrote:
> This adds another dependency between jasper and tomcat.util ( the first is
> tomcat.util.log, now tomcat.util.compat ). Since both packages are completely
> standalone and can be bundled with jasper, I don't think it'll be a problem.
Comments:
I don't personally see a problem with Jasper requiring Tomcat, but I do see
a problem with the other way around. :-)
HOWEVER, I'm not sure what other corporations will think about this. People
who want to bundle Jasper without Tomcat (ie: IBM) may not like this at
all...even if the Tomcat stuff is standalone.
Maybe a good idea would be to change the build scripts to package the
jasper.jar file with *everything* it needs to run standalone...even if it
means duplicating a couple .class files.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/>