DO NOT REPLY [Bug 31233] - jsp compile errors with Chinese Characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31233 jsp compile errors with Chinese Characters --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 06:50 --- Created an attachment (id=12737) a simple jsp which contains a few chinese chars with UTF8 encoded - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31233] - jsp compile errors with Chinese Characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31233 jsp compile errors with Chinese Characters --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 10:15 --- Created an attachment (id=12739) another jsp which will cause compile error - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31233] - jsp compile errors with Chinese Characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31233 jsp compile errors with Chinese Characters --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 13:59 --- I can't test the correctness of the characters right now, but I do not get any compilation error with the second file. So this part of the report is bad. Although I'm not the biggest expert in i18n, one of the pages seem wrong: it does not include a page directive with the correct charset. Last, you might want to try using the init-param of Jasper (in conf/web.xml) to play with the encoding during the compilation. init-param param-namejavaEncoding/param-name param-valueISO-8859-1/param-value /init-param - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31233] - jsp compile errors with Chinese Characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31233 jsp compile errors with Chinese Characters --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 16:06 --- Created an attachment (id=12742) test jsp on tomcat 5.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31233] - jsp compile errors with Chinese Characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31233 jsp compile errors with Chinese Characters --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 16:08 --- Created an attachment (id=12743) test jsp on tomcat 5.5 with default javaEncoding - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31233] - jsp compile errors with Chinese Characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31233 jsp compile errors with Chinese Characters --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 16:09 --- Created an attachment (id=12744) test jsp on tomcat 5.5 with javaEncoding set to ISO-8859-1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31233] - jsp compile errors with Chinese Characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31233 jsp compile errors with Chinese Characters --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 16:15 --- I tested the second jsp on three environment settings and got three different results(please see the attatched images): 1. on tomcat 5.0 with default jsp compiler setting: ok 2. on tomcat 5.5 with default jsp compiler setting: compile error 3. on tomcat 5.5 with javaEncoding set to ISO-8859-1: display incorrectly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31233] - jsp compile errors with Chinese Characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31233 jsp compile errors with Chinese Characters [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 16:18 --- The is not productive at all. As I said: the syntax error does not occur for me. So I will ignore this part of the report until I get a real test case. As for the rest, since the generated source will very likely be the same (you didn't compare, though), and the encoding is properly set on the compiler (you can verify that in the compiler adapter source), the issue must rest with the compiler itself. You have the option of using Ant as the compiler if JDT is the issue (remove the JDT jar, and put ant.jar where the JDT jar was). Supporting JDT is outside of Tomcat's scope, so I will resolve this report as INVALID. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31233] New: - jsp compile errors with Chinese Characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31233 jsp compile errors with Chinese Characters Summary: jsp compile errors with Chinese Characters Product: Tomcat 5 Version: 5.5.1 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] My jsp pages (which contains Chinese characters and encoded in UTF8) can be executed without any problems in Tomcat 4.1 and Tomcat 5.0. When I try to run these jsp pages in Tomcat 5.5, either it will result in compile errors or the Chinese characters can not be displayed correctly on the browser. Then I tried to replace jasper-compiler.jar and jasper-runtime.jar in Tomcat 5.5 with those in Tomcat 5.0 and all back to normal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31233] - jsp compile errors with Chinese Characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31233 jsp compile errors with Chinese Characters --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 05:13 --- Can you provide a test case ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13956] - XSI Namespace Declaration Causing JSP Compile Errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=13956. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=13956 XSI Namespace Declaration Causing JSP Compile Errors [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-08-22 15:56 --- This has been fixed in CVS for TC4. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21978] - Certain tag file pathnames lead to compile errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978 Certain tag file pathnames lead to compile errors [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 17:38 --- I thought about refactoring that part, but was too lazy to actually do it. Glad that you did though. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21978] New: - Certain tag file pathnames lead to compile errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978 Certain tag file pathnames lead to compile errors Summary: Certain tag file pathnames lead to compile errors Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Tomcat can't compile certain tag files: 1) Tag files whose relative pathname contains a component (one of the directories, or the filename without the .tag suffix) which is not a legal Java identifier. Tomcat converts the relative pathname to a fully-qualified class name, and if the parts aren't all legal Java identifiers, the Java compiler will throw an error. 2) Tag files in /some_directories/immediate_parent_directory/ when there's a tag file in /some_directories/ with filename immediate_parent_directory.tag. Here the problem is that the package of the tag files in /some_directories/immediate_parent_directory/ clashes with the class of the immediate_parent_directory.tag tag file. For instance, the tag file /WEB-INF/tags/foo/bar.tag will have package name org.apache.jsp.tag.web.foo, which conflicts with the fully-qualified class name of the tag file /WEB-INF/tags/foo.tag. I will attach a patch that fixes this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21978] - Certain tag file pathnames lead to compile errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978 Certain tag file pathnames lead to compile errors --- Additional Comments From [EMAIL PROTECTED] 2003-07-29 18:45 --- Created an attachment (id=7563) Proposed patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21978] - Certain tag file pathnames lead to compile errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978 Certain tag file pathnames lead to compile errors [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21978] - Certain tag file pathnames lead to compile errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978 Certain tag file pathnames lead to compile errors [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-29 23:26 --- Patch applied. I also added checks for Java keywords in the package names. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21978] - Certain tag file pathnames lead to compile errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978 Certain tag file pathnames lead to compile errors [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 02:51 --- Good catch on checking for Java keywords. That also makes it possible to refactor getDerivedPackageName and eliminate some duplicate code. I will attach a patch implementing this. No issues whatsoever with your commit fixing the bug I reported, so if you don't think the new patch makes the code cleaner, feel free to change this bug ticket back to Resolved/Fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21978] - Certain tag file pathnames lead to compile errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21978 Certain tag file pathnames lead to compile errors --- Additional Comments From [EMAIL PROTECTED] 2003-07-30 02:52 --- Created an attachment (id=7574) Refactoring getDerivedPackageName() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
isapi_redirector2 compile errors...(Cannot open include file: 'apr.h')
Hi, I am using vc6 on win2000 to compile isapi_redirector2: jakarta-tomcat-connectors-4.1.12-src\jk\native2\server\isapi and getting the following error. I would like to know which version of apr I should use with this build. I noticed that most of the apr libraries have apr.h.in rather than apr.h?? Thanks for your help in advance. Ajit Configuration: isapi - Win32 Debug Creating resources from ..\..\common\jk_logger_win32_message.mc MC: Compiling ..\..\common\jk_logger_win32_message.mc Compiling resources... Compiling... jk_channel.c d:\software\jakarta-tomcat-connectors-4.1.12-src\jk\native2\include\jk_global.h (151) : fatal error C1083: Cannot open include file: 'apr.h': No such file or directory jk_channel_apr_socket.c d:\software\jakarta-tomcat-connectors-4.1.12-src\jk\native2\include\jk_global.h (151) : fatal error C1083: Cannot open include file: 'apr.h': No such file or directory jk_channel_jni.c cl.exe terminated at user request. Tool execution canceled by user. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP Compile Errors
I need to make sure that these Java libraries are included when my JSP's are compiled: java.io.* java.util.* I am migrating from another application server that added these to my JSP's and now will have the daunting task of manually importing these on every JSP that we have. 1) What kind of app server would import those for you? You need to file a big, loud bug report, cuz that violates the spec! Only java.lang is imported for free in Java. 2) Write a Shell or Perl script, or a Java program, or use vi. How many JSPs are you talking about anyway? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSP Compile Errors
Write a simple Java program: 1. Drill down and get files. 2. Check for package statement, check for import statements. 3. If blah, blah, blah, then add import blah, blah. I wrote a generic one that could be used whenever I needed to so something like that to lots of files, e.g. change the package name on all of them. It is proprietary to the company I worked for, so I cannot put it in here. But, they are really not hard to write. At 05:24 PM 10/25/2002 -0400, you wrote: I need to make sure that these Java libraries are included when my JSP's are compiled: java.io.* java.util.* I am migrating from another application server that added these to my JSP's and now will have the daunting task of manually importing these on every JSP that we have. 1) What kind of app server would import those for you? You need to file a big, loud bug report, cuz that violates the spec! Only java.lang is imported for free in Java. 2) Write a Shell or Perl script, or a Java program, or use vi. How many JSPs are you talking about anyway? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org Micael --- This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
JSP Compile Errors
Hello All. I need to make sure that these Java libraries are included when my JSP's are compiled: java.io.* java.util.* I am migrating from another application server that added these to my JSP's and now will have the daunting task of manually importing these on every JSP that we have. Any thoughts?
DO NOT REPLY [Bug 13956] New: - XSI Namespace Declaration Causing JSP Compile Errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13956. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13956 XSI Namespace Declaration Causing JSP Compile Errors Summary: XSI Namespace Declaration Causing JSP Compile Errors Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I use XML Spy to create my xml-valid JSPs by providing sun's schema...XML Spy produces a page similar to this: jsp:root xmlns:xtags=http://jakarta.apache.org/taglibs/xtags-1.0; xmlns:jsp=http://java.sun.com/JSP/Page; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/JSP/Page http://java.sun.com/dtd/jspxml.xsd; /jsp:root This, to the best of my knowledge is the correct way to declare a JSP. I have been using these pages since Tomcat 3.x (bundled with JBoss). When migrating these pages to Tomcat 4.1.12 I started receiving compile errors for every page that contains: xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/JSP/Page http://java.sun.com/dtd/jspxml.xsd; The compile error is found at the end of my entry. If I remove this entry the page compiles just fine. Are these invalid namespace declarations that Tomcat was mistakingly allowing before or does the new compiler introduced in 4.1.x have a bug? I have a work-around for this problem (simply remove the declarations), but I am concerned about other namespace entries that may cause a problem. Thanx, Aaron Roller org.apache.jasper.JasperException: Unable to compile class for JSP at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:479) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:469) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480
Re: Compile errors
On Mon, 17 Sep 2001, Jon Stevens wrote: Date: Mon, 17 Sep 2001 21:25:33 -0700 From: Jon Stevens [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: tomcat-dev [EMAIL PROTECTED] Subject: Compile errors I'm trying to build off the tomcat-4.0 branch and it isn't working... It seems that for some reason, the copying of the files over to the build directory is commented out. Why is that? It says that one cannot re-distribute the JSSE stuff, but this is for BUILDING, not distribution. The distribution build process should remove those files if they exist... And *that* is why the build system was modified to be the way that it is. (I haven't voted yet on the future build mechanism, but here's the background on the current approach.) Today, if you download (say) the 3.2 source tree and build it, in an environment that doesn't have JSSE installed, the build script will silently create a incomplete distribution for you, because it will silently exclude building SSLServerSocketFactory. Thus, even though you *think* you just built a complete binary distribution, you didn't -- you cannot take your distribution and deploy it on a machine that does have JSSE installed and run SSL connections, without going back and building from source yet again. Now multiply this same sort of problem by all the options people might want to not require in Tomcat 4. If the build system does not provide at least the option to guarantee a functionally complete build (i.e. fail if something optional is actually missing), I'm going to be -1 on it. Without this, people building distributions (including the release manager building the official ones) has no automated means to validate success. -jon Craig build-main: [javac] Compiling 4 source files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/classes [javac] Compiling 16 source files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/classes [javac] [javac] Found 14 semantic errors compiling /Users/jon/checkout/jakarta-tomcat-4.0/catalina/src/share/org/apache/catali na/net/SSLServerSocketFactory.java: [javac] [javac] 71. import javax.net.ServerSocketFactory; [javac]--- [javac] *** Error: javax/net/ServerSocketFactory is either a misplaced package name or a non-existent entity. [javac] [javac] [javac] 72. import javax.net.ssl.SSLServerSocket; [javac]--- [javac] *** Error: javax/net/ssl/SSLServerSocket is either a misplaced package name or a non-existent entity. [javac] [javac] [javac] 73. import javax.net.ssl.SSLSocket; [javac]- [javac] *** Error: javax/net/ssl/SSLSocket is either a misplaced package name or a non-existent entity.
Re: Compile errors
On Tue, 18 Sep 2001, Craig R. McClanahan wrote: Today, if you download (say) the 3.2 source tree and build it, in an environment that doesn't have JSSE installed, the build script will silently create a incomplete distribution for you, because it will silently exclude building SSLServerSocketFactory. Thus, even though you *think* you just built a complete binary distribution, you didn't -- you cannot take your distribution and deploy it on a machine that does have JSSE installed and run SSL connections, without going back and building from source yet again. Now multiply this same sort of problem by all the options people might want to not require in Tomcat 4. If the build system does not provide at least the option to guarantee a functionally complete build (i.e. fail if something optional is actually missing), I'm going to be -1 on it. Without this, people building distributions (including the release manager building the official ones) has no automated means to validate success. I disagree with this - in tomcat3.x we do the build using only components that are redistributable under apache license - jaxp included ( we use xml.apache.org code for crimson, jaxp and xalan ). The result is functionally complete - it is true it does not include components that depend on other licenses, but I don't think you can require people to download and accept other licenses in order to build tomcat or redistribute. The release manager - on the other side - or people who want to build that functionality - can get the extra code and build the components that would enable it, for the release or for their own use. I believe the build system for 3.x is the right one - and it's consistent with what Apache does - you are not required to download an SSL implementation to build apache httpd. ( as a matter of fact, in some countries it is illegal to use encryption - I think even France has some interesting laws - or used to have, so that would make building tomcat quite difficult ). It may be inconvenient for people - but if a jar is included in an apache product that means ASF gives people who get that package the right to redistribute it without restrictions ( assuming they give credit to apache, etc ). Costin
Re: Compile errors
On Mon, 17 Sep 2001, Jon Stevens wrote: Date: Mon, 17 Sep 2001 21:25:33 -0700 From: Jon Stevens [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: tomcat-dev [EMAIL PROTECTED] Subject: Compile errors I'm trying to build off the tomcat-4.0 branch and it isn't working... It seems that for some reason, the copying of the files over to the build directory is commented out. Why is that? It says that one cannot re-distribute the JSSE stuff, but this is for BUILDING, not distribution. The distribution build process should remove those files if they exist... And *that* is why the build system was modified to be the way that it is. (I haven't voted yet on the future build mechanism, but here's the background on the current approach.) Today, if you download (say) the 3.2 source tree and build it, in an environment that doesn't have JSSE installed, the build script will silently create a incomplete distribution for you, because it will silently exclude building SSLServerSocketFactory. Thus, even though you *think* you just built a complete binary distribution, you didn't -- you cannot take your distribution and deploy it on a machine that does have JSSE installed and run SSL connections, without going back and building from source yet again. That's cool, but my proposal included an option (the C) which would allow people to build a version of Tomcat for their own environment (for example, I plan to have JDK 1.4 switches where the build process wouldn't bug you with JSSE, JAXP, among other things), while leaving in the full build, which has indeed many advantages and should be used to build the distribution binaries. So I fail to see the problem. Now multiply this same sort of problem by all the options people might want to not require in Tomcat 4. If the build system does not provide at least the option to guarantee a functionally complete build (i.e. fail if something optional is actually missing), I'm going to be -1 on it. Without this, people building distributions (including the release manager building the official ones) has no automated means to validate success. Fair enough, but it's only truly useful for the release manager and some of the core contributors, while discouraging external contributors from actually getting involved. I think option C was an appropriate middle ground. We can also add something which would display the status of the various flags before starting building. Remy
Compile errors
I'm trying to build off the tomcat-4.0 branch and it isn't working... It seems that for some reason, the copying of the files over to the build directory is commented out. Why is that? It says that one cannot re-distribute the JSSE stuff, but this is for BUILDING, not distribution. The distribution build process should remove those files if they exist... -jon build-main: [javac] Compiling 4 source files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/classes [javac] Compiling 16 source files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/classes [javac] [javac] Found 14 semantic errors compiling /Users/jon/checkout/jakarta-tomcat-4.0/catalina/src/share/org/apache/catali na/net/SSLServerSocketFactory.java: [javac] [javac] 71. import javax.net.ServerSocketFactory; [javac]--- [javac] *** Error: javax/net/ServerSocketFactory is either a misplaced package name or a non-existent entity. [javac] [javac] [javac] 72. import javax.net.ssl.SSLServerSocket; [javac]--- [javac] *** Error: javax/net/ssl/SSLServerSocket is either a misplaced package name or a non-existent entity. [javac] [javac] [javac] 73. import javax.net.ssl.SSLSocket; [javac]- [javac] *** Error: javax/net/ssl/SSLSocket is either a misplaced package name or a non-existent entity.
J34: Parsing compile errors
Hi, Next step on line mapping is finding the JSP line that caused the compiler error. For that we need to parse the compile error. Does anyone know any existing code or some magic to get to a consistent format ? Costin
