Re: Tomcat 3.3 deployment - last minute problem
Hi all, i also investigating this problem a little bit, my solution to this is use a filter to convert all the income request's data to UTF8. and generate JSP by UTF8 encoding. it work quite good. but the problem is my backend database must have UTF8 support From Timothy - Original Message - From: Renato [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 18, 2001 6:27 PM Subject: Re: Tomcat 3.3 deployment - last minute problem Hi all, I'm investigating this problem and may found something. The html that is pushed to my browser is definitely pure Unicode ( UTF8 ), so somehow the HTML bytes are not been properly translated to chars. Where can I look in the code to make some tests ? Thanks Renato. Reply-to: Tomcat Developers List From: Renato Date: Fri Dec 14 15:19:28 2001 To: Tomcat Developers List , Tomcat Developers List , , Subject: Re: Tomcat 3.3 deployment - last minute problem Hi, This is what I'm using: I saw the servlet generated in the work directory and it actually write the response.setContentType(text/html;charset=ISO-8859-1) ( default type in server.xml is set to ISO-8859-1 too ) How can I know the charset of Linux ? ( I'll STW of course.. :)) ) Thanks for the promptness ! On Fri, 14 Dec 2001 08:48:31 -0800 (PST), escreveu : On Fri, 14 Dec 2001, Renato wrote: *** HTML pages with latin characters don't display correctly on Linux *** ( JSP file with: ) Ex: áéíóú It's maybe a problem with the locale variables on my Linux, which I don't quite understand ( tried LC_ALL, LANG, LC_CTYPE and it didn't work ) or Tomcat itself. Do you set the charset in the page setContentType(text/html;charset=8859-??) or the jsp equivalent ? What charset do you use to write the page ? ( i.e. UTF or 8859-?? ) ? There are few variables: - Java default charset ( which is typically the same as the OS charset). This is what jasper uses to read the page from disk. The page is converted to UTF by the reader. ( you can override the charset used on each page, don't remember the directive ) - output charset. This is specified in setContentType() or setCharEncoding on the response, and is used to convert from UTF to the target charset. Costin -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
getOutputStream() or getWriter() within a JSP
According to the Servlet spec, I know that calling response.getOutputStream() after response.getWriter() has been called is an IllegalStateException, and vice versa. I have a question about a related area in JSP 1.2, section 2.7: Initially, out is a new JspWriter object. This object may be different from the stream object returned from response.getWriter(), and may be considered to be interposed on the latter in order to implement buffering (see Section JSP.2.10.1, The page Directive). This is the initial out object. JSP page authors are prohibited from writing directly to either the PrintWriter or OutputStream associated with the ServletResponse. I am unsure about what actions the container needs to take to fullfill the last sentence. Does this mean: 1) The container should throw an Exception (IllegalState?) if the jsp calls getOutputStream() or getWriter(). 2) If a jsp calls getOutputStream() or getWriter(), any methods called on those objects should be ignored by the container. 3) It is discouraged for page authors to do this. ( JSP Container does nothing ) I think 1) is correct, but the spec is ambiguous. As far as I can tell, if 1) is true, Tomcat has a bug. If 2) is true I think Tomcat has a bug, but I'm not sure. If 3) is true Tomcat has no bug. Side Note: Tomcat does throw an Exception for getOutputStream() inside jsp:include'ed jsps, but not for getWriter(). This I also don't quite understand. thanks, Tim Julien HP Middleware -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
readme for webapp connector update.
Pier, et.al., I just completed building the Tomcat 4.0.1 WARP connector. I doing so I noted a problem with the README.txt (v1.15 in CVS) regarding the configure script. Specifically, the detailed the command line options (switches) mentions the use of --with-java[=JAVA_HOME] for compiling and jarring the Java portion (warp.jar) of the webapp connector. When attempting this, I noted that the Java did not run as expected. My investigation took me into the bowels of the configure script. I found that the script is expecting --enable-java. This oversight should be corrected in the next iteration of the README. Warmest Regards, Tim -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: sun.tools.javac.Main will be removed from JDK1.4
Over in HP middleware, we're not to happy with this development either our JSP implementation will suffer for the same reasons Jasper will We can work with an external compiler, but for speed, we much prefer sun.tool.javac.Main. Tim Julien HP Middleware -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, July 20, 2001 1:54 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: sun.tools.javac.Main will be removed from JDK1.4 There are some pretty intense discussions going on about this, and the story hasn't yet been finished ... On the other hand, the new compiler entry point has an absolutely horrible feature (from the point of view of Jasper) -- you have to modify System.out and System.err to redirect the compiler output. Unless system variables are unique per classloader (they weren't last time I checked), that means we can only do one compile at a time :-(. An additional note of interest to Ant developers - there is evidence that running the compiler (either old or new) leaves a fair amount of cruft lying around in static variables, after the compile has completed. The recommended solution is to load the compiler itself in its own class loader, so that you can throw it all away afterwards. That's the approach we'll take when modifying Jasper. Craig On Fri, 20 Jul 2001, Sam Ruby wrote: FYI. Bye bye classic compiler. Ant looks safe (it uses reflection), but Jasper looks like it will be affected. - Sam Ruby -- Forwarded by Sam Ruby/Raleigh/IBM on 07/20/2001 07:30 AM --- Davanum Srinivas [EMAIL PROTECTED] on 07/20/2001 06:16:57 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: sun.tools.javac.Main will be removed from JDK1.4 FYI, -Original Message- From: Leclair, Donald Sent: Thursday, July 19, 2001 7:15 PM To: J2EE Communications Subject: Message 14: Class change impact Sent: Thursday, July 19, 2001 7:08 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Class change impact Dear Licensee, The Java(TM) 2 Platform, Standard Edition team will be making a change that might impact you. The change is that the class sun.tools.javac.Main (used for compiling java classes) will be removed in J2SE 1.4. This is not a public API change. If you depend on this class you may be impacted. If you have questions, please follow-up with your designated Licensee Engineer. Regards, Jill Smith Java Partner Engineering = Davanum Srinivas, JNI-FAQ Manager http://www.jGuru.com/faq/JNI __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
servlet.jar and jsp.jar
I see that Tomcat 4.0 is not yet using the new servlet.jar and jsp.jar that were released on April 24 by SUN. I think they are broken - servlet.jar is missing javax.servlet.LocalStrings.properties, javax.servlet.LocalStrings_es.properties, and javax.servlet.http.LocalStrings.properties files. This causes javax.servlet.http.Cookie to fail to initialize at Class loading time. just thought I'd bring this up since some devs on this list have some pull with Sun ;) Tim Julien HP Middleware
FORM implementation
does Tomcat save header, cookie, and parameter (could be POST data) data when doing FORM login? Tim Julien HP Middleware
RE: FORM implementation
ignore this mail - dont know why it just now went through - i sent it days ago. Tim Julien HP Middleware -Original Message- From: JULIEN,TIMOTHY (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 4:52 PM To: '[EMAIL PROTECTED]' Subject: FORM implementation does Tomcat save header, cookie, and parameter (could be POST data) data when doing FORM login? Tim Julien HP Middleware
RE: Class Reloading
After a successful FORM login, how does Tomcat restore the original request? If it uses the forward mechanism, how does it force the browser to use the URL of the original request, and not */j_security_check? Tim Julien HP Middleware
RE: RE: how do I create a WAR file?
jar is a basic tool that comes with the jdk used for packaging up files. Ant does alot more - its like 'make'. You can declare dependencies, and use Ant to build your app - not just package it (like jar). Tim Julien HP Middleware -Original Message- From: Derek Harding [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 17, 2001 1:12 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: RE: how do I create a WAR file? yes exactly thanks. What is the difference using the java tool instead of the Ant tool? [EMAIL PROTECTED] writes: 1. open a prompt or shell. 2. go to the root of your web-app. 3. run: jar cf directory-name.war * is this what you are asking about, or are you asking about creating the web-app directory structure as well? Tim Julien HP Middleware -Original Message- From: Derek Harding [mailto:[EMAIL PROTECTED]] Sent: Monday, April 16, 2001 9:00 PM To: [EMAIL PROTECTED] Subject: how do I create a WAR file? Are there any examples of how to create a WAR file?
RE: how do I create a WAR file?
1. open a prompt or shell. 2. go to the root of your web-app. 3. run: jar cf directory-name.war * is this what you are asking about, or are you asking about creating the web-app directory structure as well? Tim Julien HP Middleware -Original Message- From: Derek Harding [mailto:[EMAIL PROTECTED]] Sent: Monday, April 16, 2001 9:00 PM To: [EMAIL PROTECTED] Subject: how do I create a WAR file? Are there any examples of how to create a WAR file?
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
Yes - from my experience, this was the problem deploying Jasper in another container. Tim Julien HP Middleware -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 11:33 AM To: [EMAIL PROTECTED] Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] So far jasper has been one of the most stable pieces on tomcat ( most bugs I know about are related with the interfacing between jasper and the container ). And it has a huge potential for performance improvement - if we do the right refactoring and provide the right internal APIs. Costin The second most common cause of bugs in Jasper is confusion over when to use File.separator and when to use '/'. It's hard to keep track of, since Jasper does deal with both files and URIs. And the File methods are used to regularize some URIs. Another reason to refactor. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
standard test apps
Are there standard test apps for testing a Servlet container? I am running watchdog, and several struts apps; Java pet store requires EJB's, so thats no good. Any known apps out there that are either standard or opensource? Tim Julien HP middleware
RE: jasper's -classpath
Thanks alot - clears a few things up. My issues are all related to compile-time classpath, and your explanation seems to verify that. I have a strong interest in getting Jasper to run in our container, so if you need any help coding or testing, i'm gald to help with either. -Tim Julien HP middleware -Original Message- From: Mel Martinez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 11:30 PM To: [EMAIL PROTECTED] Subject: Re: jasper's -classpath --- "Julien, Timothy" [EMAIL PROTECTED] wrote: How does Jasper construct its Classpath when compiling jsps? From what I see it is: System class path + something from Tomcat + the directory containing the jsp source. Note that when running Jasper in another container, the 'something from Tomcat' part is null - an init-parameter 'org.apache.cataline.jsp_classpath' for JspServlet, I think, is (obviously) missing when running in another container. When running in another container, the class path visible to jasper JSP's is like so: 0 - Classpath (via system class loader) 1 - classes visible to JspServlet's class loader (i.e. the servlet class loader for the container) 2 - classes visible to JasperLoader (the class loader used to load Jsp servlets after they have been compiled). In general, you may or may not have control over 0 (depends on how the container starts up) and what is available via (1) depends on how the container loads servlets. The control over (2) is a little shaky currently. The classpath available to JasperLoader for loading classes is basically whatever directories, jar or zip files have been added via the addJar() method. Unfortunately, as near as I can tell, this is not done anywhere. Now the classpath that is pulled out of the JspServlet's init-params looks like it is _supposed_ to be added to JasperLoader, but if it is I can't find where. It IS appended to the classpath used by the Compiler to compile the jsp's .java files into .class files, but that doesn't help you load the classes and run them. Before I got involved with the tomcat project directly, I solved this problem by extending a few jasper classes to refactor it and fix this and a few other problems specifically to address running Jasper in a non-tomcat container (I need to run it in WebLogic as well). In my solution, I did two things. (1) I outright added a system property to set a classpath for the jsp loader. (2) I calculate the classpath for the JasperLoader using the above property as well as the heretofore ignored init-param and make sure to add it to the loader when I construct the loader for the particular page (my implementation uses a loader for each page to support dynamic reloading). So somewhere between the creation of the loader and the attempt to load the class, which currently happens in JspServlet.doLoadJSP(), the classpath needs to be added to the loader. I say 'currently' because Costin is right when he says that jasper could use some refactoring. I'd like to propose some wholesale refactoring of the class model for the JspServlet and it's supporting classes to better partition responsibilities. I'll make a more formal proposal along these lines shortly. Question: Would Jasper be able to run out of a web-app, without hanving it in the system classpath? Could I stick all of Jaspers relevant jars in the WEB-INF/lib directory and get it to work? The behavior I am seeing says no. I would think that the classpath for compilation should include the jars in WEB-INF/lib directory. If the container properly implements the spec, then JspServlet and thus the jsp servlets should be able to 'see' the WEB-INF/lib classes for LOADING purposes via the servlet classloader. However, that classpath is not made available to the compiler for COMPILATION currently. The compiler sees the classpath of the JasperLoader.getClassPath() call (which as I've said above, is not necessarily set because that is initialized via missing addJar() calls) catenated to the init-param classpath. So the result is that currently, you can only LOAD classes that the parent servlet classloader can see and you can only COMPILE classes visible in the init-param classpath. If you know how the container's classloader behaves, and also manually setup the init-param classpath, you can work around this confusion. However, this needs to be fixed. I will try to take a stab at first a short-term fix to get it working right in the next couple of days and then as mentioned, I'd like to propose some more wholesale changes. Note - a lot of these problems don't exist with the JspInterceptor. These problems seem to be solely with the JspServlet as used separately from tomcat. Cheers, Dr. Mel Martinez __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
bug in Jasper - bad lookups to Constants.getString()
I believe there is a bug in Jasper when resources (such as web.xml's dtd)
can't be loaded.
The basic problem is that keys are getting passed into Constants.getString()
which aren't keys in the message resources file. This happens because of
some exception handling, which basically constructs an invalid key - namely,
a *value* in the message resources file.
JspUtil.parseXMLDocJaxp(String, InputStream)
{
try
{
...
}
catch(IOException io)
{
throw new
JasperException(Constants.getString("jsp.error.parse.xml", new Object[] {
uri, io.toString()
}));
}
}
and then lower down the call stack:
public TldLocationsCache(ServletContext ctxt)
{
mappings = new Hashtable();
try
{
processWebDotXml(ctxt);
processJars(ctxt);
}
catch(JasperException ex)
{
Constants.message(ex.getMessage(), 1);
}
}
The trouble is that ex.getMessage() here contains a *value* from the message
resource file, (as looked up in the first caught Exception) not a *key*.
One fix would be in JspUtil.parseXMLDocJaxp(String, InputStream) to pass
only the key (jsp.error.parse.xml) as the JasperException's message - and
delay the lookup. But then you lose some information (i.e., io.String()).
Maybe a better solution is to set a flag on JasperException which marks its
message as being either key or value - so that Constants.getString can be
called only when necessary. I realize this would effect alot of code.
anyway, I'm happy to help in any way with the fix.
Tim Julien
HP Middleware
bug in Jasper - bad calls to Constants.getString
I believe there is a bug in Jasper when resources (such as web.xml's dtd)
can't be loaded.
The basic problem is that keys are getting passed into Constants.getString()
which aren't keys in the message resources file. This happens because of
some exception handling, which basically constructs an invalid key - namely,
a *value* in the message resources file.
JspUtil.parseXMLDocJaxp(String, InputStream)
{
try
{
...
}
catch(IOException io)
{
throw new
JasperException(Constants.getString("jsp.error.parse.xml", new Object[] {
uri, io.toString()
}));
}
}
and then lower down the call stack:
public TldLocationsCache(ServletContext ctxt)
{
mappings = new Hashtable();
try
{
processWebDotXml(ctxt);
processJars(ctxt);
}
catch(JasperException ex)
{
Constants.message(ex.getMessage(), 1);
}
}
The trouble is that ex.getMessage() here contains a *value* from the message
resource file, (as looked up in the first caught Exception) not a *key*.
One fix would be in JspUtil.parseXMLDocJaxp(String, InputStream) to pass
only the key (jsp.error.parse.xml) as the JasperException's message - and
delay the lookup. But then you lose some information (i.e., io.String()).
Maybe a better solution is to set a flag on JasperException which marks its
message as being either key or value - so that Constants.getString can be
called only when necessary. I realize this would effect alot of code.
anyway, I'm happy to help in any way with the fix.
Tim Julien
HP Middleware
another bug in Jasper - incorrect File.separator
Still in the endeavor of running Jasper in another container
When making calls in ParserController.getReader() to
ServletContext.getResourceAsStream() (through JspCompilationContext), the
String that is passed in is file.toString() (where file denotes the jsp to
be translated/compiled). The problem with that call is that File.toString()
calls File.getPath(), which replaces '/' with File.separator - which on
Windows is '\'. However, calls to ServletContext.getResourceAsStream() must
begin with '/', per the servlet 2.2 javadocs. Hence, getResourceAsStream()
returns null.
I've included the fix:
in org.apache.jasper.compiler.ParserController:
private InputStreamReader getReader(File file, String encoding,
String absFileName)
throws FileNotFoundException, JasperException
{
InputStream in;
InputStreamReader reader;
try {
if (ctxt == null) {
in = new FileInputStream(file);
reader = new InputStreamReader(in, encoding);
} else {
//String fileName = ctxt.getRealPath(file.toString());
// TDJ
// changed file.toString( ) -
// absFileName
// ServletContext.getResourceAsStream( ) requires
// url slashes ( '/' ), not platform specific slashes
in = ctxt.getResourceAsStream(absFileName);
if (in == null) {
throw new FileNotFoundException(absFileName);
}
reader = new InputStreamReader(in, encoding);
}
return reader;
} catch (UnsupportedEncodingException ex) {
throw new JasperException(
Constants.getString("jsp.error.unsupported.encoding",
new Object[]{encoding}));
}
}
Tim Julien
HP middleware
Re: mod_jk.so build problems with SunOS 5.6
Hello, Has anyone gotten an answer for this post? I ran into the same problem also. tt At 03:45 PM 1/29/01 +0900, you wrote: hi, I failed to build mod_jk.so.what can tell me how can I do. I get a error message when I use apxs -o mod_jk.so jk_worker.o jk_util.o jk_uri_worker_map.o jk_sockbuf.o jk_pool.o jk_nwmain.o jk_msg_buff.o jk_map.o jk_lb_worker.o jk_jni_worker.o jk_connect.o j k_ajp13_worker.o jk_ajp13.o jk_ajp12_worker.o mod_jk.o -lrt apxs:Break: Command failed with rc=255 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
