DO NOT REPLY [Bug 23209] New: - URL not escaped for logging
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=23209. 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=23209 URL not escaped for logging Summary: URL not escaped for logging Product: Tomcat 3 Version: 3.1 Final Platform: All URL: http://myserver/test1test2 OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I have a double quote in the pathname of the URL, this is not escaped in the log. It should appear as 2 quotes, but appears only as 1 quote. In the log, I then have GET /test1test2 HTTP/1.0 but it should be: GET /test1test2 HTTP/1.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23211] New: - ServletContext,getRequestDispatcher throws exception for invalid path instead of returning null
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=23211. 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=23211 ServletContext,getRequestDispatcher throws exception for invalid path instead of returning null Summary: ServletContext,getRequestDispatcher throws exception for invalid path instead of returning null Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] when calling ServletContext,getRequestDispatcher(invalidPath) the method throws an exception. However, the servlet javadocs specify to return null in that case. getRequestDispatcher public RequestDispatcher getRequestDispatcher(java.lang.String path) Returns a RequestDispatcher object that acts as a wrapper for the resource located at the given path. A RequestDispatcher object can be used to forward a request to the resource or to include the resource in a response. The resource can be dynamic or static. The pathname must begin with a / and is interpreted as relative to the current context root. Use getContext to obtain a RequestDispatcher for resources in foreign contexts. This method returns null if the ServletContext cannot return a RequestDispatcher. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat within custom application
Thanks Remy. I have managed to run the embedded Tomcat 4x. However, I still have a bit of a problem with context configuration. Suppose I install a WAR directory containing a XSLT servlet. The output from this XSLT servlet is XHTML, which contains relative references to images and CSS files. If I place all these relative reference files (in a proper directory structure) in the root directory of the WAR, these are inaccessible. I cannot place them in a different directory and get it from there either. Looks like there is a problem with the contexts configuration. Suppose my servlet is called as http://localhost:8182/xsltservlet/xslTransform?xml=xmlfile.xmlxsl=xslfile.xsl then any reference like http://localhost:8182/xsltservlet/images/myimage.gif is not available even if it is in the directory path. It does not also let me browse the virtual directory http://localhost:8182/xsltservlet/. How do I go about solving this problem? Thanks again. - Original Message - From: Remy Maucherat To: Tomcat Developers List Sent: Tuesday, September 16, 2003 3:23 PM Subject: Re: Tomcat within custom application Xtremebytes Webmaster wrote: I am wondering how I can run the Tomcat JSP/Servlet container within another process, which is not a HTTP server but a custom Java application. This is to mean that I have some JSP or Servlets for example. I need to run them on a client machine (Windows NT/UNIX platform), which doesn't have a web server or the standalone Tomcat container installed. I do not want to install that either. I just want to launch the Tomcat container as one thread within one custom Java application while some other threads will do other unrelated work. The purpose is to deploy the Servlets or JSP making the Tomcat container transparent to the client. You can look at the Tomcat 5 embedded distribution (basically, you get an Ant script replacing server.xml). The included example Ant script just makes some basic JMX calls to create an embedded Tomcat, so you don't have to use Ant (but, for an example, it's obviously easier to understand and more readable) or have any dependencies on the Tomcat APIs. The old Tomcat 4.x Embedded class is also supported (except it has been rewritten to use the standard behavior rather than being a special case). I believe some real docs on embedding would be useful, including: - embedding Coyote - embedding Tomcat using Embedded - embedding Tomcat with JMX Remy - 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]
DO NOT REPLY [Bug 23211] - ServletContext,getRequestDispatcher throws exception for invalid path instead of returning null
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=23211. 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=23211 ServletContext,getRequestDispatcher throws exception for invalid path instead of returning null [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-17 11:48 --- Every URL is ultimately mapped to the default servlet which is mapped to / if no other servlet matches. The default servlet is the one throwing the exception. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.12 stability rating
Remy Maucherat wrote: ballot [ ] Alpha [X] Beta /ballot I didn't get futher reports concerning bug 21763 (and related), so I assume this means things improved. It would be a good idea to release a new 4.1.28 build once this is confirmed to also provide a fix for Tomcat 4.1.x. Since the amount of other outstanding issues is also very low, I think 5.0.12 should be a solid beta. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] fix compression=on option on coyote connector
Currently the option for compression=on in the coyote connector is broken
(see bug 18073). The solution presented in the patches attached to that bug
seemed overly complicated. Here is an alternate patch that also fixes the
problem.
This patch changes 3 things:
1) Decreases the minimum compression size to 1k - this seemed to help with
my particular application. There was a lot in the range of 1-2k.
2) Checks only that the content type starts with an entry in the
compressableMimeTypes list instead of checking equality. This is the real
bug fix since the contentType also includes the character encoding
information.
3) Added application/x-javascript as a default compressable type. Now it
allows all mime types starting with text/, not just the three previously
specified.
Index: Http11Processor.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/
http11/Http11Processor.java,v
retrieving revision 1.78
diff -r1.78 Http11Processor.java
273c273
protected int compressionMinSize = 2048;
---
protected int compressionMinSize = 1024;
291c291
protected String[] compressableMimeTypes = { text/html, text/xml,
text/plain };
---
protected String[] compressableMimeTypes = { text/,
application/x-javascript };
462a463,478
/**
* General use method
*
* @param sArray the StringArray
* @param value string
*/
private boolean startsWithStringArray(String sArray[], String value) {
if (value == null)
return false;
for (int i = 0; i sArray.length; i++) {
if (value.startsWith(sArray[i])) {
return true;
}
}
return false;
}
1216,1217c1232,1233
if (compressableMimeTypes != null)
return (inStringArray(compressableMimeTypes,
response.getContentType()));
---
if (compressableMimeTypes != null)
return (startsWithStringArray(compressableMimeTypes,
response.getContentType()));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] fix compression=on option on coyote connector
Steve Appling a écrit : Currently the option for compression=on in the coyote connector is broken (see bug 18073). The solution presented in the patches attached to that bug seemed overly complicated. Here is an alternate patch that also fixes the problem. This patch changes 3 things: 1) Decreases the minimum compression size to 1k - this seemed to help with my particular application. There was a lot in the range of 1-2k. Are you sure you want to compress content less than 2k ? BTW, you could use compression property for your purpose. 2) Checks only that the content type starts with an entry in the compressableMimeTypes list instead of checking equality. This is the real bug fix since the contentType also includes the character encoding information. That's the way it's done on Apache HTTPD mod_deflate. 3) Added application/x-javascript as a default compressable type. Now it allows all mime types starting with text/, not just the three previously specified. Nope there is problems with many browser which didn't support gzipped javascript. I submitted part of this code after reviewing what HTTPD team does on mod_deflate, and I feel you could trust them isn't it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] fix compression=on option on coyote connector
Henri Gomez wrote: Steve Appling a écrit : Currently the option for compression=on in the coyote connector is broken (see bug 18073). The solution presented in the patches attached to that bug seemed overly complicated. Here is an alternate patch that also fixes the problem. This patch changes 3 things: 1) Decreases the minimum compression size to 1k - this seemed to help with my particular application. There was a lot in the range of 1-2k. Are you sure you want to compress content less than 2k ? BTW, you could use compression property for your purpose. Well, it's a default value. I'd say there's indeed not much point compressing resources which are too small. 2) Checks only that the content type starts with an entry in the compressableMimeTypes list instead of checking equality. This is the real bug fix since the contentType also includes the character encoding information. That's the way it's done on Apache HTTPD mod_deflate. But how can it work without the startsWith ? The charset definitely messes up the test. Or we have to look for ; in the charset String and use a region match. 3) Added application/x-javascript as a default compressable type. Now it allows all mime types starting with text/, not just the three previously specified. Nope there is problems with many browser which didn't support gzipped javascript. Sounds reasonable. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PATCH] fix compression=on option on coyote connector
Henri Gomez wrote: Are you sure you want to compress content less than 2k ? BTW, you could use compression property for your purpose. You are correct, the property works fine. 3) Added application/x-javascript as a default compressable type. Now it allows all mime types starting with text/, not just the three previously specified. Nope there is problems with many browser which didn't support gzipped javascript. Are there really browsers that send Accept-Encoding: gzip, but don't really accept it? I was not aware of that. Which ones do this? I submitted part of this code after reviewing what HTTPD team does on mod_deflate, and I feel you could trust them isn't it ? I'm sorry, I didn't understand that. What was submitted to whom? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] fix compression=on option on coyote connector
Steve Appling a écrit : Henri Gomez wrote: Are you sure you want to compress content less than 2k ? BTW, you could use compression property for your purpose. You are correct, the property works fine. 3) Added application/x-javascript as a default compressable type. Now it allows all mime types starting with text/, not just the three previously specified. Nope there is problems with many browser which didn't support gzipped javascript. Are there really browsers that send Accept-Encoding: gzip, but don't really accept it? I was not aware of that. Which ones do this? Of course, you could make some search on google for it. Also there is still problem to get pdf on gzip streams (may be more a problem with acrobat browser integration). I submitted part of this code after reviewing what HTTPD team does on mod_deflate, and I feel you could trust them isn't it ? I'm sorry, I didn't understand that. What was submitted to whom? I suggested the idea to Remy who wrote the code. I make some change after taking a look at mod_deflate code. mod_deflate has existed before gzip support in coyote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] fix compression=on option on coyote connector
On Wed, 17 Sep 2003, Steve Appling [EMAIL PROTECTED] wrote: Are there really browsers that send Accept-Encoding: gzip, but don't really accept it? This is from mod_gzip: http://www.schroepl.net/projekte/mod_gzip/browser.htm. I was not aware of that. Which ones do this? In short, Netscape 4 probably won't work at all, MSIE seems to have trouble unless you have a certain fix installed. All others should work (even for the JavaScript case). The mod_gzip author recommends not compressing anything for Netscape 4 at all. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PATCH] fix compression=on option on coyote connector
Stefan Bodewig wrote: In short, Netscape 4 probably won't work at all, MSIE seems to have trouble unless you have a certain fix installed. All others should work (even for the JavaScript case). The mod_gzip author recommends not compressing anything for Netscape 4 at all. There is a noCompressionUserAgents list in the Http11Processor which could be used to stop compression for certain user agents, but I don't see where it is ever initialized. Can the noCompressionUserAgents list or the compressableMimeTypes list be customized in a config file? I see setter methods for these lists, but don't see where they are ever called. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23192] - getRemoteUser() returns null with Authorization header
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=23192. 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=23192 getRemoteUser() returns null with Authorization header [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-17 18:42 --- I have had a look at the spec at I think what you are trying to do runs contrary to the concept of programmatic security as described in the spec. The relevant part of the spec is: SRV.12.3 Programmatic Security Programmatic security is used by security aware applications when declarative security alone is not sufficient to express the security model of the application. Programmatic security consists of the following methods of the HttpServletRequest interface: • getRemoteUser • isUserInRole • getUserPrincipal My understanding of this is that using setStatus() to force the sending of an authentication header is not considered a valid part of programmatic security. I am therefore marking this bug as INVALID. However, if you have a security model you can't implement using an appropriate combination declarative and programmatic security please reopen this bug, provide a description of your security model and I will be happy to take another look at this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23228] New: - JSP Error -- Unknown attribute type (String) for attribute
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=23228. 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=23228 JSP Error -- Unknown attribute type (String) for attribute Summary: JSP Error -- Unknown attribute type (String) for attribute Product: Tomcat 5 Version: 5.0.9 Platform: PC OS/Version: Linux Status: NEW Severity: Blocker Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The following error occurs in a web app I'm working on, and it all works fine in Tomcat 4. If it's a change in JSP syntax or libraries, I certainly can't find it anywhere... I looked on the net and found such things as: http://www.google.com/url?sa=Ustart=1q=http://archives.real-time.com/pipermail/tomcat-devel/2003-February/046448.htmle=747 But I can't see anywhere that answers the problem, so I have to assume it's a bug since Tomcat 4 works ... until I can find if it's a coding error that is new in JSP 2.0 and Tomcat 5. Here is the first line from one error: /layout/search-body-layout.jsp(12,0) Unknown attribute type (String) for attribute action.' Here's the JSP that goes with it: %@ page contentType=text/html;charset=UTF-8 language=java % %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % %@ taglib uri=/WEB-INF/struts-nested.tld prefix=nested % %@ taglib uri=/WEB-INF/struts-tiles.tld prefix=tiles % %@ taglib uri=/WEB-INF/struts-layout.tld prefix=layout % %@ taglib uri='/WEB-INF/tlds/AppTags.tld' prefix='app' % nested:form action=search method=Post And then the full stacktrace from another page... org.apache.jasper.JasperException: /layout/main-layout.jsp(58,16) Unknown attribute type (String) for attribute name. org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:83) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:404) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:271) org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:970) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:734) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1444) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2143) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2193) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:754) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1444) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2143) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2193) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:754) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1444) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2143) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2193) org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2199) org.apache.jasper.compiler.Node$Root.accept(Node.java:471) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2143) org.apache.jasper.compiler.Validator.validate(Validator.java:1510) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:259) org.apache.jasper.compiler.Compiler.compile(Compiler.java:453) org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:555) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:300) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:293) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1058) org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:269) org.apache.struts.tiles.TilesRequestProcessor.processTilesDefinition(TilesRequestProcessor.java:249) org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:303) fr.improve.struts.taglib.layout.workflow.LayoutRequestProcessor.processForwardConfig(LayoutRequestProcessor.java:37) org.apache.struts.action.RequestProcessor.processActionForward(RequestProcessor.java:401)
DO NOT REPLY [Bug 23228] - JSP Error -- Unknown attribute type (String) for attribute
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=23228. 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=23228 JSP Error -- Unknown attribute type (String) for attribute [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Major Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-17 21:14 --- I'm sure you're not trying to file obsfucated bug reports, but try to separate the eventual test case from comments and traces, it's easier. I'll change the severity of the bug to something more sane, as you should be able to find a workaround, given all Struts webapps I tried did work fine so far. Please reopen the report with a ready to run JSP (you seem to have that), thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23231] New: - Bad Request, page failed to be served, due to jave length overflow
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=23231. 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=23231 Bad Request, page failed to be served, due to jave length overflow Summary: Bad Request, page failed to be served, due to jave length overflow Product: Tomcat 4 Version: 4.0.4 Final Platform: PC URL: http://www.imedica.net/jspellhtml/test.html OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] From time to time, Tomcat failed to serve a particular page for a few particular clients, failed with 'Bad Request'. The Tomcat log indicated java length error or length overflow; we accidently found, and confirmed that the clients IE browser's cookies are cleaned up, then the problem is resolved for those particular clients. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java
luehe 2003/09/17 16:26:33
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
Log:
Fix for Bugtraq 4924326 (JMX registrations of servlets that map to
the same jsp-file use the same name)
This allows for the following 2 servlets, which map to the same
jsp-file, to be distinguished.
servlet
servlet-namexxx/servlet-name
jsp-file/jsp/test.jsp/jsp-file
/servlet
servlet
servlet-nameyyy/servlet-name
jsp-file/jsp/test.jsp/jsp-file
/servlet
servlet-mapping
servlet-namexxx/servlet-name
url-pattern/xxx/url-pattern
/servlet-mapping
servlet-mapping
servlet-nameyyy/servlet-name
url-pattern/yyy/url-pattern
/servlet-mapping
Without the fix, accessing /xxx causes a 404, because its
registration is overridden by the 2nd servlet, so that /xxx is
handled by the DefaultServlet.
Revision ChangesPath
1.32 +5 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- StandardWrapper.java 29 Jul 2003 15:55:15 - 1.31
+++ StandardWrapper.java 17 Sep 2003 23:26:33 - 1.32
@@ -1607,17 +1607,13 @@
protected void registerJMX(StandardContext ctx) {
try {
-String name=this.getJspFile();
-if( name==null ) {
-name=this.getServletName();
-}
// it should be full name
String parentName=ctx.getName();
String hostName=ctx.getParent().getName();
String webMod= // + ((hostName==null)? DEFAULT :hostName ) +
((.equals(parentName) ) ? / : parentName );
String onameStr=ctx.getDomain() +
-:j2eeType=Servlet,name= + name + ,WebModule= +
+:j2eeType=Servlet,name= + getName() + ,WebModule= +
webMod + ,J2EEApplication= +
ctx.getJ2EEApplication() + ,J2EEServer= +
ctx.getJ2EEServer();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23233] New: - Dynfunctioning of the translation from JSP to Java
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=23233. 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=23233 Dynfunctioning of the translation from JSP to Java Summary: Dynfunctioning of the translation from JSP to Java Product: Tomcat 5 Version: 5.0.9 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A section of the JSP file: jsp:useBean id=PForm class=com.mycom.mm.profile.formbean.FriendProfileForm scope=request/ table ... tr class=TableRowColor td input type=checkbox name=sport value=u %= PForm.sportSelectionAttr(u) % id=sport.u label for=sport.ufmt:message key=sport.u//label /td td input type=checkbox name=sport value=G %= PForm.sportSelectionAttr(G) % id=sport.G label for=sport.Gfmt:message key=sport.G//label /td td input type=checkbox name=sport value=t %= PForm.sportSelectionAttr(t) % id=sport.t label for=sport.tfmt:message key=sport.t//label /td td input type=checkbox name=sport value=v %= PForm.sportSelectionAttr(v) % id=sport.v label for=sport.vfmt:message key=sport.v//label /td /tr tr class=TableRowColor td input type=checkbox name=sport value=W %= PForm.sportSelectionAttr(W) % id=sport.W label for=sport.Wfmt:message key=sport.W//label /td tdnbsp;/td tdnbsp;/td tdnbsp;/td /tr /table The translated Java file: if (_jspx_meth_fmt_message_218(pageContext)) return; out.write(/label\r\n\t\t ); out.write(/td\r\n); out.write(td \r\n ); out.write(input type=\checkbox\ name=\sport\ value=\E\ ); out.write(String.valueOf( PForm.sportSelectionAttr(E) )); out.write( id=\sport.E\\r\n ); out.write(label for=\sport.E\); if (_jspx_meth_fmt_message_219(pageContext)) return; out.write(/label\r\n\t\t ); out.write(/td\r\n\t ); out.write(/tr\r\n ); out.write(tr class=\TableRowColor\ \r\n); out.write(td \r\n ); out.write(input type=\checkbox\ name=\sport\ value=\u\ ); out.write(String.valueOf( PForm.sportSelectionAttr(u) % id=sport.u label for=sport.ufmt:message key=sport.u//label /td td input type=checkbox name=sport value=G %= PForm.sportSelectionAttr(G) % id=sport.G label for=sport.Gfmt:message key=sport.G//label /td td input type=checkbox name=sport value=t %= PForm.sportSelectionAttr(t) % id=sport.t label for=sport.tfmt:message key=sport.t//label /td td input type=checkbox name=sport value=v %= PForm.sportSelectionAttr(v) % id=sport.v label for=sport.vfmt:message key=sport.v//label /td /tr tr class=TableRowColor td input type=checkbox name=sport value=W %= PForm.sportSelectionAttr(W) )); out.write( id=\sport.W\\r\n ); out.write(label for=\sport.W\); The first section (218) is correct, but not the second section (219). As a result, the Java code can't be compiled. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.12 stability rating
Remy Maucherat wrote: ballot [ ] Alpha [x] Beta /ballot It runs all examples in my upcoming JSP 2.0 book, so it looks fine to me. I had some problems with a bundled Xerces version, but for now I consider that an application problem rather than a container problem. If further analysis proves otherwise, I'll let you know. Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0 Details athttp://TheJSPBook.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 5.0.12 stability rating
I agree... Beta... I had a little problem with the ISAPI redirector... But that all is working now... All applications and Database access I am doing works as well. I still would like Isapi redirector 2 to work, but that may be something more to do with my configuration as opposed to any issues with Tomcat... Solid Beta all the way baby... Richard Norman Web/Application Developer -Original Message- From: Hans Bergsten [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 8:19 PM To: Tomcat Developers List Subject: Re: [VOTE] 5.0.12 stability rating Remy Maucherat wrote: ballot [ ] Alpha [x] Beta /ballot It runs all examples in my upcoming JSP 2.0 book, so it looks fine to me. I had some problems with a bundled Xerces version, but for now I consider that an application problem rather than a container problem. If further analysis proves otherwise, I'll let you know. Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0 Details athttp://TheJSPBook.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]
