RE: %=x% expression syntax bug in XML jsp?
Ok. Thanks for the reply. I can see the arguments on both sides. It's a pitty my side lost ;) james -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 26, 2001 8:59 PM To: [EMAIL PROTECTED] Subject: Re: %=x% expression syntax bug in XML jsp? On Wed, 26 Sep 2001, Mark Abbott wrote: Date: Wed, 26 Sep 2001 10:43:51 -0700 From: Mark Abbott [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: %=x% expression syntax bug in XML jsp? Hi Craig - I'm curious whether the expert group has discussed what might be done in the future about this unfortunate aspect of JSP. In what I would think would be a really common case in the future, where one wants to design an app using clean, readable, and purely XML templates (perhaps XHTML for example), but editing by hand rather than with some JSP savvy tool, the choices are: * Create a custom tag foo:text which just dumps out the corresponding text tag Wrapping all the tags in every markup of interest is impractical * Write the XML syntax in the way that the JSP compiler expects: jsp:text![CDATA[text y=10 x=]] jsp:expressionxpos/jsp:expression jsp:text![CDATA[test/test/jsp:text This is an unreadable mess, especially considering scaling up to a substantial size of template * Use the JSP syntax, where %= % expressions *are* recognized everywhere. This is not XML any more Cheers - Mark There was *considerable* discussion about the details of the XML syntax. On this particular point, my take-away from the results was no particular desire to change a fundamental assumption from the very early days of JSP -- that JSP is totally agnostic to the syntax and semantics of the template text. To do as you suggest would require the JSP compiler to understand in some fashion that the template text it is processing is really element+attribute oriented (as XML and HTML are), so that it could apply this particular transformation the way you want. Also, the design center for the XML syntax was definitely around automatic generation from tools, rather than hand-editing. And it shows in use cases like this one. It's too late to do anything in a JSP 1.2 time frame (since the spec just went final), but it would certainly be worthwhile to log your suggestion to the spec feedback address for consideration in a future version: [EMAIL PROTECTED] Craig
Re: Tomcat 4.0 RPMs?
Hi Vic. We're currently trying to sort out the best way of packaging a 4.0 RPM. TC4 has quite a few external jar dependencies ... some optional, some mandatory. We're kind of between a rock and a hard place with both a few of the RPM packaging policies as well as some jar redistribution issues. The prevailing theory seems to be that the RPM should include just the absolute minimum number of jars required to successfully run a minimal build of Tomcat. The rest will still have to be downloaded separately (although we might make a tomcat-supplimental.tar.gz available containing all of the optional jars that we can safely redistribute). The problem is that RPM packaging policies frown upon including external binaries (in our case non-TC jars) in the RPM, and beyond that, doing so is not really good form anyway. In other words, the RPM install isn't going to be as painless as we would like. If you are comfortable with building from source, and if you need anything other than a minimal build, the source might be your best bet. (You could also just download the binaries, of course.) I'm not even sure that an exact approach for TC4 RPMs has been decided upon, and I'm also not sure what Henri's (our RPM packager) timeframe is, so AFAIK the date on having an RPM is still up in the air. Quoting Vic Ricker [EMAIL PROTECTED]: Hi. Will RPMs for Tomcat 4.0 be released on the web site any time soon? I have no problem installing from the tar but I'd prefer the RPM since that's how I installed the previous version. Thanks, -Vic - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
Re: TC 3.3: getRequestURI()
[EMAIL PROTECTED] wrote: On Wed, 26 Sep 2001, Keith Wannamaker wrote: 0x3b = ';'. Ignacio is right, SessionID doesn't remove the id because it is not expecting ; to be encoded. So now it shows up in the URI and has the side effect of breaking sessions that depend on url rewriting. But, the spec does say the URL should be encoded, so I'd rather fix SessionID with this patch. However, are there other places where TC is manipulating the URL and assuming it is unencoded? I'm not sure this is the right solution ( but it's a good patch:-). The 'original' URI included a ';' - which is a valid character used in the right way. It shouldn't be encoded by mod_jk - the whole reason for encoding is to try to reproduce the original URI or something equivalent. The only use for %3B is to allow the user to specify some path-info ( or other path components ) that include the ';' character. In a URI ';' is used to pass additional informations about the path ( and it seems it can be attached to any path component ) - I never saw any server to use this feature. Well, we have a big nightmare here - and probably the only way out is to find some consistent ( and implementable ) interpretation of the involved specs and stick with that. The encoded URI is used only to satisfy the servlet spec - and re-encoding the URI is an imperfect workaround. We have few choices: 1. revert to the use of unencoded_uri. Problems: - what about IIS and NES, where this is not available ? - what about integrating with apache, where the decoded uri is used for everything ( that means any attempt to authenticate using apache modules may create huge problems) 2. Use a different encoding function, that doesn't encode ';'. Problems: - encoding/decoding will result in a different URI ( thus the servlet spec will not be happy ) - inconsistency between tomcat standalone and tomcat+server 3. Revert to the use of uri ( i.e. the decoded uri ), and change the getRequestURI ( the facade ) to generated a 'canonical' encoding. Problems: - again it'll not be the 'original' as required by servlet ( but at least this will be consistent across servers) Using 'unencoded' URIs is a huge source of security problems - the server and container _must_ use decoded URIs internally, because otherwise security constraints would be useless. On the other side, servlets that are doing any matching on 'unencoded' URIs are likely to be tricked easily by encoding tricks. So if a user is doing any security check, he'll likely repeat all our bugs. Using a 'canonical' encoding ( where only the chars that are required to be encoded are encoded ) has the benefit that gives a consistent output. My preference would be to do (3). Mine also. Costin
Crystal Reports In Tomcat
Hi, I have installed Tomcat ver 3.2 in my system. The server is Apache in Windows NT platform. I want to integrate Crystal Report with this. Seagate Software is providing an applet and using this applet the crystal reports can be viewed in a browser. This whole process is managed by a dll. The integration is available with IIS. Whenever a .rpt file is called in the browser, the URL is redirected to a dll which in turn provides with the applet. The process of redirecting the rpt to the dll is managed by IIS. I would like to know whether this can be done using Apache server. I want a similar thing to be done using Tomcat with Apache. Is it possible? If yes, How? Rajesh
RE: [VOTE] Kin-Man Chung and William Barker for Tomcat Committer Status
I'd like to follow up on Nacho's (good) suggestion that we add William Barker and Kin-Man Chung as committers on Tomcat. They've both been providing invaluable assistance and patches. +2 (2 * +1)
Re: [VOTE] Kin-Man Chung and William Barker for Tomcat Committer Status
Craig R. McClanahan wrote: I'd like to follow up on Nacho's (good) suggestion that we add William Barker and Kin-Man Chung as committers on Tomcat. They've both been providing invaluable assistance and patches. I'm +1 on them. Craig +1 Jean-frederic
DO NOT REPLY [Bug 3850] New: - Tomcat 4 does not start /examples context. JspServlet/Jasper problem.
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=3850. 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=3850 Tomcat 4 does not start /examples context. JspServlet/Jasper problem. Summary: Tomcat 4 does not start /examples context. JspServlet/Jasper problem. Product: Tomcat 4 Version: 4.0 Final Platform: PC OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi all. I've just downloaded and installed Tomcat 4 Final on several Win2000 sp2 PCs with JDK130 and JDK131, depending on the machine. The steps are very simple: - Extracted files to a folder. - Set: CATALINA_HOME to Tomcat4 folder. - Set JAVA_HOME to JDK 130/131 folder. - Launched: %CATALINA_HOME%\bin\startup In the log files can be read these lines: FILE: localhost_examples_log [BEGIN] 2001-09-27 09:52:39 WebappLoader[/examples]: Deploying class repositories to work directory C:\Tomcat4\work\localhost\examples 2001-09-27 09:52:39 WebappLoader[/examples]: Reloading checks are enabled for this Context 2001-09-27 09:52:39 StandardManager[/examples]: Seeding random number generator class java.security.SecureRandom 2001-09-27 09:52:39 StandardManager[/examples]: Seeding of random number generator has been completed 2001-09-27 09:52:40 ContextConfig[/examples]: Configured an authenticator for method FORM 2001-09-27 09:52:40 StandardContext[/examples]: Exception starting filter Compression Filter java.lang.ClassCastException: compressionFilters.CompressionFilter at org.apache.catalina.core.ApplicationFilterConfig.getFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef (Unknown Source) at org.apache.catalina.core.ApplicationFilterConfig.init(Unknown Source) at org.apache.catalina.core.StandardContext.filterStart(Unknown Source) at org.apache.catalina.core.StandardContext.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardEngine.start(Unknown Source) at org.apache.catalina.core.StandardService.start(Unknown Source) at org.apache.catalina.core.StandardServer.start(Unknown Source) at org.apache.catalina.startup.Catalina.start(Unknown Source) at org.apache.catalina.startup.Catalina.execute(Unknown Source) at org.apache.catalina.startup.Catalina.process(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Unknown Source) 2001-09-27 09:52:40 StandardContext[/examples]: Exception starting filter Servlet Mapped Filter java.lang.ClassCastException: filters.ExampleFilter at org.apache.catalina.core.ApplicationFilterConfig.getFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef (Unknown Source) at org.apache.catalina.core.ApplicationFilterConfig.init(Unknown Source) at org.apache.catalina.core.StandardContext.filterStart(Unknown Source) at org.apache.catalina.core.StandardContext.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardEngine.start(Unknown Source) at org.apache.catalina.core.StandardService.start(Unknown Source) at org.apache.catalina.core.StandardServer.start(Unknown Source) at org.apache.catalina.startup.Catalina.start(Unknown Source) at org.apache.catalina.startup.Catalina.execute(Unknown Source) at org.apache.catalina.startup.Catalina.process(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Unknown Source) 2001-09-27 09:52:40 StandardContext[/examples]: Exception starting filter Set Character Encoding java.lang.ClassCastException: filters.SetCharacterEncodingFilter at org.apache.catalina.core.ApplicationFilterConfig.getFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef (Unknown Source) at org.apache.catalina.core.ApplicationFilterConfig.init(Unknown Source) at org.apache.catalina.core.StandardContext.filterStart(Unknown Source) at org.apache.catalina.core.StandardContext.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at
DO NOT REPLY [Bug 3847] - Apache authorization headers not passed through to servlet
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=3847. 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=3847 Apache authorization headers not passed through to servlet [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2001-09-27 01:16 --- AFAIK this is by desing, now AJp12 and Ajp13 interceptors have a atributte called tomcatAuthentication that controls how authentication is done, obeying HTTP server , apache in your case, or Tomcat own authentication mechanism.., and is true by default.., so you need to add a tomcatAuthentication=false to your connector interceptors.. We will try to document that better.. sorry about that.. Please test this feature ASAP..
Re: [VOTE] Kin-Man Chung and William Barker for Tomcat Committer Status
+1, +1 Craig R. McClanahan wrote: I'd like to follow up on Nacho's (good) suggestion that we add William Barker and Kin-Man Chung as committers on Tomcat. They've both been providing invaluable assistance and patches. I'm +1 on them. Craig -- Andy Armstrong, Tagish
cvs commit: jakarta-tomcat/src/doc mod_jk-howto.html
bojan 01/09/27 01:23:06 Modified:src/doc mod_jk-howto.html Log: Added j_security_check FAQ Revision ChangesPath 1.13 +63 -1 jakarta-tomcat/src/doc/mod_jk-howto.html Index: mod_jk-howto.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/mod_jk-howto.html,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- mod_jk-howto.html 2001/08/02 17:15:47 1.12 +++ mod_jk-howto.html 2001/09/27 08:23:06 1.13 @@ -892,8 +892,70 @@ /blockquote Note: The above steps assume that you downloaded the Apache source and placed it in your /usr/local/src directory. -br +h3 +Q. Why doesn't my form authentication work? I'm getting similar error messages +from Apache:/h3 + +table class=inlinetabletrtd class=inlinetd +blockquotepreNot Found +The requested URL /login/j_security_check was not found on this server. +/pre/blockquote +/td/tr/table + +A. If you used manual configuration such as: + +table class=inlinetabletrtd class=inlinetd +blockquotepre +JkMount /*.jsp ajp13 +/pre/blockquote +/td/tr/table + +or + +table class=inlinetabletrtd class=inlinetd +blockquotepre +JkMount /*.vm ajp13 +/pre/blockquote +/td/tr/table + +mod_jk will pass requests for all JSP or Velocity pages to Tomcat. If some of +those pages are configured as login and error pages in web.xml: + +table class=inlinetabletrtd class=inlinetd +blockquotepre +lt;login-configgt; + lt;auth-methodgt;FORMlt;/auth-methodgt; + lt;realm-namegt;Protectedlt;/realm-namegt; + lt;form-login-configgt; +lt;form-login-pagegt;/login/login.vmlt;/form-login-pagegt; +lt;form-error-pagegt;/login/error.vmlt;/form-error-pagegt; + lt;/form-login-configgt; +lt;/login-configgt; +/pre/blockquote +/td/tr/table + +there is also another, somewhat hidden request involved in the authentication +process: strong/login/j_security_check/strong, which is the 'action' of the +form specified within stronglogin.vm/strong and strongerror.vm/strong +like this: + +table class=inlinetabletrtd class=inlinetd +blockquotepre +lt;form method=quot;postquot; action=quot;j_security_checkquot;gt; +/pre/blockquote +/td/tr/table + +This request is not mapped. This following fixes the problem: + +table class=inlinetabletrtd class=inlinetd +blockquotepre +JkMount /*.vm ajp13 +JkMount /login/j_security_check ajp13 +/pre/blockquote +/td/tr/table + hr + h2 a NAME=s11/aCredits/h2 This document was originally created by
mod_webapp - regex matching
Hi all,
I'm not sure why regex matching wasn't included with the mod_webapp
connector, and reading the user lists there clearly is a demand for it. I
hope I'm not overstepping the mark but I've put a diff listing below which
enables regex matching. As you'll see it's only for apache 1, but that's
what I'm currently working with and in the true sense of the open source
'thing' I'm just scratching my personal itch.
Regards,
James Williamson
Index: apache-1.3/mod_webapp.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c,v
retrieving revision 1.23
diff -r1.23 mod_webapp.c
401a402
if (apr_fnmatch(appl-rpth,r-uri,FNM_PERIOD) == 0) break;
Index: include/wa.h
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/include/wa.h,v
retrieving revision 1.11
diff -r1.11 wa.h
84a85
#include apr_fnmatch.h
Index: lib/wa_config.c
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/lib/wa_config.c,v
retrieving revision 1.6
diff -r1.6 wa_config.c
85c85,89
appl-rpth=apr_pstrcat(wa_pool,buf,/,NULL);
---
if (!ap_is_fnmatch(buf)) {
appl-rpth=apr_pstrcat(wa_pool,buf,/,NULL);
} else {
appl-rpth=apr_pstrdup(wa_pool,buf);
}
Re: Tomcat next
Remy Maucherat wrote: On Wed, 26 Sep 2001, Dave Oxley wrote: Date: Wed, 26 Sep 2001 22:59:55 +0100 From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tomcat next Hi all, A couple of questions on future Tomcat releases: 1. Will there be a TC3.4 release or is 3.x obsolete after 3.3? I don't know on this one. 2. Has TC4.0 been branched (i.e. has development started on TC4.1 or are you waiting for TC4.0.1 to branch?) Yes, it has been branched (tomcat_40_branch is for 4.0.x). The HEAD branch can be used for new development and features. 3. Is there a list of planned features for TC4.1? Hmm, the todo list doc looks like it got lost in the shuffle ... Two big areas I'd like to see focus on (and where I and some of my colleagues will definitely be spending some time) are: * Major improvements to the JSP page compiler to improve the quality and performance of the code it generates, and to make the compiler itself more maintainable. A high level requirements doc for my view of what this should include will be circulated soon. * Implementing a nice administration/configuration interface (as a web app), talking to server components through a JMX interface (so that Tomcat can be managed by any JMX compliant tool). Some time ago I published some functional requirements for this (in the Tomcat documentation, go to Functional Specs under Catalina) but it hasn't received much in the way of comment yet. What would *you* like to see happen? (And what would *you* like to work on to make it happen? :-). Actually, I would be more in favor of releasing a 4.1 before that, focusing mostly on small refactorings of the core (like the error report refactoring I just did) and optimizations. More specifically, that would include: - the Service stuff (if done) - a Coyote connector (note: Coyote is the name I've chosen to designate half of what is currently the TC 3.3 core) - a HTTP/1.1 connector for Coyote - better mod_webapp Better connectors... mod_jk works with both TC3.3 and TC4.0. A good enhancement is to add the WARP protocol to mod_jk. - fixes for all the compliance issues that need some refactoring (error report, response commit, ...) Such a release could happen relatively soon, and would provide a better basis for adding all the big new features mentioned above. Of course, we could decide that all the things mentioned above are small enough feature additions and refactorings so that they can be released as part of the 4.0.x branch. Note: Obviously, I'm in favor of more incremental but more frequent releases than what has been done in the past. Remy
DO NOT REPLY [Bug 3851] New: - SingleThreadModel ignored
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=3851. 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=3851 SingleThreadModel ignored Summary: SingleThreadModel ignored Product: Tomcat 3 Version: 3.2.3 Final Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have found out that a class of type SingleThreadModel will not be synchronized, which gives serious problem with thread security. This works in the 3.1 release so it must have been removed in either the 3.2.2 rewrite or in the 3.2 release.
RE: [J-T-C] ajp13 works from jt to jtc ?
I'll send today some modifications to ajp13 parts in java and build to ease the use of ajp13 with Tomcat 4.0 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 26, 2001 5:10 PM To: [EMAIL PROTECTED] Subject: Re: [J-T-C] ajp13 works from jt to jtc ? On Wed, 26 Sep 2001, GOMEZ Henri wrote: Hi to all, Did someone is planning to port ajp13 java changes done in TC 3.3 back to J-T-C ? If not I'll do it but I want to avoid duplicate works ... Hi Henri, I do plan to do that - haven't started yet, I was planning to start after 3.3 final is labeled. Costin
RE: [PATCH] Potential buffer overflow attach in mod_jk
Thanks, I'll back port to J-T-C - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 2:42 AM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Potential buffer overflow attach in mod_jk Here's with jk_pool_strdup (against RC1, not HEAD). It looked to me like uw_map-p wasn't suitable for per-request allocations (i.e. it would just eat memory until the server was re-started), and since this is in common, I couldn't use ap_strdup since that breaks all non-Apache servers. - Original Message - From: Keith Wannamaker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 5:25 PM Subject: RE: [PATCH] Potential buffer overflow attach in mod_jk Hi Bill, would you resubmit a patch that makes use of either Apache or jk's pools? ie ap_strdup or jk_pool_strdup. That would be a better way to solve the problem. Apache modules should and do avoid os memory-allocation routines like the plague. I think uw_map-p would be ok, but please do some testing. Thanks, Keith | -Original Message- | From: Bill Barker [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 26, 2001 2:37 PM | To: [EMAIL PROTECTED] | Subject: Fw: [PATCH] Potential buffer overflow attach in mod_jk | | | Urm, let's try that again with a patch that at least compiles.. ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: mod_webapp - regex matching
Sorry all,
The patch I sent you it utter garbage, please disregard.
Regards,
James Williamson
- Original Message -
From: James Williamson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 27, 2001 9:02 AM
Subject: mod_webapp - regex matching
Hi all,
I'm not sure why regex matching wasn't included with the mod_webapp
connector, and reading the user lists there clearly is a demand for it. I
hope I'm not overstepping the mark but I've put a diff listing below which
enables regex matching. As you'll see it's only for apache 1, but that's
what I'm currently working with and in the true sense of the open source
'thing' I'm just scratching my personal itch.
Regards,
James Williamson
Index: apache-1.3/mod_webapp.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c,v
retrieving revision 1.23
diff -r1.23 mod_webapp.c
401a402
if (apr_fnmatch(appl-rpth,r-uri,FNM_PERIOD) == 0) break;
Index: include/wa.h
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/include/wa.h,v
retrieving revision 1.11
diff -r1.11 wa.h
84a85
#include apr_fnmatch.h
Index: lib/wa_config.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/webapp/lib/wa_config.c,v
retrieving revision 1.6
diff -r1.6 wa_config.c
85c85,89
appl-rpth=apr_pstrcat(wa_pool,buf,/,NULL);
---
if (!ap_is_fnmatch(buf)) {
appl-rpth=apr_pstrcat(wa_pool,buf,/,NULL);
} else {
appl-rpth=apr_pstrdup(wa_pool,buf);
}
RE: Tomcat 4.0 RPMs?
Hi Vic. We're currently trying to sort out the best way of packaging a 4.0 RPM. TC4 has quite a few external jar dependencies ... some optional, some mandatory. We're kind of between a rock and a hard place with both a few of the RPM packaging policies as well as some jar redistribution issues. I'm still waiting for Craig answer on externals jars avaibility outside Sun site (jta, jmx, ldap, ). I've asked to have them all of them in a tomcat-supplemental tarball available on jakarta.apache.org to have them included in TC 4.0 RPM, of course if license permit that also. Something to be validated by Sun Lawyers. The interest of the RPM is that it provides a ready-to-run solution but it won't be the case if the users need to grab and then install (where) the external jars by hand. Some could think we could get the TC 4.0 binary and package it in RPM but it's also not a solution since RPM policies ask to have a binary generated from one or many sources and in that case it won't be the case. Only some vendors provide RPM like this, JDK/SDK from Sun/IBM for example but these tools are not OpenSource... Until I got a positive answer from Craig, I'll have to delay TC 4.0 RPM (allready done in-house) and I'm more than sorry about that.
cvs commit: jakarta-tomcat/src/doc mod_jk-howto.html
bojan 01/09/27 03:18:01 Modified:src/doc mod_jk-howto.html Log: Typos, wording for j_security_check FAQ Revision ChangesPath 1.14 +9 -7 jakarta-tomcat/src/doc/mod_jk-howto.html Index: mod_jk-howto.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/mod_jk-howto.html,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- mod_jk-howto.html 2001/09/27 08:23:06 1.13 +++ mod_jk-howto.html 2001/09/27 10:18:01 1.14 @@ -918,8 +918,8 @@ /pre/blockquote /td/tr/table -mod_jk will pass requests for all JSP or Velocity pages to Tomcat. If some of -those pages are configured as login and error pages in web.xml: +mod_jk will pass requests for all JSP or Velocity pages to Tomcat. If form +authentication is configured like this: table class=inlinetabletrtd class=inlinetd blockquotepre @@ -934,10 +934,10 @@ /pre/blockquote /td/tr/table -there is also another, somewhat hidden request involved in the authentication -process: strong/login/j_security_check/strong, which is the 'action' of the -form specified within stronglogin.vm/strong and strongerror.vm/strong -like this: +then there is also another, somewhat hidden request involved in the +authentication process: strong/login/j_security_check/strong. It is the +'action' of the form specified within stronglogin.vm/strong and +strongerror.vm/strong, usually: table class=inlinetabletrtd class=inlinetd blockquotepre @@ -945,7 +945,9 @@ /pre/blockquote /td/tr/table -This request is not mapped. This following fixes the problem: +The request strong/login/j_security_check/strong is not mapped, therefore +mod_jk doesn't know that it should pass it to Tomcat. The following fixes the +problem: table class=inlinetabletrtd class=inlinetd blockquotepre
cvs commit: jakarta-tomcat/src/doc JDBCRealm-howto.html
bojan 01/09/27 03:23:50 Modified:src/doc JDBCRealm-howto.html Log: JDBC jar in lib/container, not lib Revision ChangesPath 1.4 +2 -2 jakarta-tomcat/src/doc/JDBCRealm-howto.html Index: JDBCRealm-howto.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/JDBCRealm-howto.html,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- JDBCRealm-howto.html 2001/07/21 00:44:25 1.3 +++ JDBCRealm-howto.html 2001/09/27 10:23:50 1.4 @@ -251,10 +251,10 @@ h2Hints/h2 p - - Make sure that the JDBC driver is in the lib directory. + - Make sure that the JDBC driver is in the lib/container directory. br - If you have problem connecting you can specify connectionName and connectionPassword/p -div align=center$Header: /home/cvs/jakarta-tomcat/src/doc/JDBCRealm-howto.html,v 1.3 2001/07/21 00:44:25 nacho Exp $ +div align=center$Header: /home/cvs/jakarta-tomcat/src/doc/JDBCRealm-howto.html,v 1.4 2001/09/27 10:23:50 bojan Exp $ /div /body /html
cvs commit: jakarta-tomcat-connectors/jk build.xml
hgomez 01/09/27 03:26:02 Modified:jk build.xml Log: Add tomcat3.skip to help people build ajp13 for Tomcat 4.0 without Tomcat 3.3 on their box Revision ChangesPath 1.12 +1 -1 jakarta-tomcat-connectors/jk/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- build.xml 2001/06/24 21:19:22 1.11 +++ build.xml 2001/09/27 10:26:02 1.12 @@ -64,7 +64,7 @@ verbose=off excludes=**/CVS/** exclude name=org/apache/ajp/tomcat4/** if=tomcat4.skip/ - exclude name=org/apache/ajp/tomcat33/** / +exclude name=org/apache/ajp/tomcat33/** if=tomcat3.skip/ classpath refid=build-main.classpath/ /javac
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp Ajp13.java
hgomez 01/09/27 03:28:12
Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java
jk/java/org/apache/ajp Ajp13.java
Log:
remove hard-coded debug in ajp13 and make use
of debug properties in server.xml.
Connector className=org.apache.ajp.tomcat4.Ajp13Connector
port=8009 minProcessors=5 maxProcessors=75
acceptCount=10 debug=0/
Make block read safer backporting readN from TC 3.3
Revision ChangesPath
1.3 +5 -4
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java
Index: Ajp13Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Ajp13Processor.java 2001/05/15 15:22:47 1.2
+++ Ajp13Processor.java 2001/09/27 10:28:12 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
1.2 2001/05/15 15:22:47 seguin Exp $
- * $Revision: 1.2 $
- * $Date: 2001/05/15 15:22:47 $
+ * $Header:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
1.3 2001/09/27 10:28:12 hgomez Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/09/27 10:28:12 $
*
*
*
@@ -102,7 +102,7 @@
/**
* @author Kevin Seguin
- * @version $Revision: 1.2 $ $Date: 2001/05/15 15:22:47 $
+ * @version $Revision: 1.3 $ $Date: 2001/09/27 10:28:12 $
*/
final class Ajp13Processor
@@ -320,6 +320,7 @@
private void process(Socket socket) {
Ajp13 ajp13 = new Ajp13();
+ajp13.setDebug(debug);
Ajp13InputStream input = new Ajp13InputStream(ajp13);
Ajp13OutputStream output = new Ajp13OutputStream(ajp13);
response.setAjp13(ajp13);
1.15 +97 -33jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java
Index: Ajp13.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Ajp13.java2001/09/17 15:45:50 1.14
+++ Ajp13.java2001/09/27 10:28:12 1.15
@@ -112,6 +112,14 @@
public static final byte JK_AJP13_END_RESPONSE = 5;
public static final byte JK_AJP13_GET_BODY_CHUNK= 6;
+// Error code for Ajp13
+public static final int JK_AJP13_BAD_HEADER= -100;
+public static final int JK_AJP13_NO_HEADER = -101;
+public static final int JK_AJP13_COMM_CLOSED = -102;
+public static final int JK_AJP13_COMM_BROKEN = -103;
+public static final int JK_AJP13_BAD_BODY = -104;
+public static final int JK_AJP13_INCOMPLETE_BODY = -105;
+
// Integer codes for common response header strings
public static final int SC_RESP_CONTENT_TYPE= 0xA001;
public static final int SC_RESP_CONTENT_LANGUAGE= 0xA002;
@@ -159,7 +167,7 @@
MOVE,
LOCK,
UNLOCK,
-ACL,
+ACL,
REPORT
};
@@ -214,8 +222,8 @@
byte []bodyBuff = new byte[MAX_READ_SIZE];
int blen; // Length of current chunk of body data in buffer
-int pos; // Current read position within that buffer
-
+int pos; // Current read position within that buffer
+
boolean end_of_stream; // true if we've received an empty packet
public Ajp13() {
@@ -238,7 +246,7 @@
// This is a touch cargo-cultish, but I think wise.
blen = 0;
-pos = 0;
+pos = 0;
end_of_stream = false;
}
@@ -589,9 +597,9 @@
}
// If the server returns an empty packet, assume that that end of
- // the stream has been reached (yuck -- fix protocol??).
-if (end_of_stream) {
-return false;
+ // the stream has been reached (yuck -- fix protocol??).
+if (end_of_stream) {
+return false;
}
// Why not use outBuf??
@@ -605,14 +613,14 @@
throw new IOException();
}
-// No data received.
-if( inBuf.getLen() == 0 ) {
-pos=0;
-blen=0;
-end_of_stream = true;
-return false;
-}
-
+// No data received.
+if( inBuf.getLen() == 0 ) {
+pos=0;
+blen=0;
+end_of_stream = true;
+return false;
+}
+
blen = inBuf.peekInt();
pos = 0;
inBuf.getBytes(bodyBuff);
cvs commit: jakarta-tomcat/src/doc tomcat-ug.html
bojan 01/09/27 03:33:21 Modified:src/doc tomcat-ug.html Log: Mention -server option for HotSpot Revision ChangesPath 1.16 +4 -2 jakarta-tomcat/src/doc/tomcat-ug.html Index: tomcat-ug.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ug.html,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- tomcat-ug.html2001/09/18 03:28:27 1.15 +++ tomcat-ug.html2001/09/27 10:33:21 1.16 @@ -1,7 +1,7 @@ !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head -!-- $Id: tomcat-ug.html,v 1.15 2001/09/18 03:28:27 larryi Exp $ -- +!-- $Id: tomcat-ug.html,v 1.16 2001/09/27 10:33:21 bojan Exp $ -- !-- Copyright 1999-2001 Apache Software Foundation -- meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 link rel=stylesheet type=text/css href=style.css @@ -438,7 +438,9 @@ ul liYou may pass options and system property settings to the Java VM by - specifying them in an environment variable called TOMCAT_OPTS.br + specifying them in an environment variable called TOMCAT_OPTS (for + instance: '-server' is useful as a performance enhancement if you're + running Sun's HotSpot VM).br bNote:/b On Win9x, you will not be able so include system property settings in TOMCAT_OPTS because the codeSET/code command won't accept a line with more than one equals sign./li
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c
hgomez 01/09/27 03:42:26
Modified:jk/native/common jk_uri_worker_map.c
Log:
BackPort security fix from TC 3.3 to J-T-C
Revision ChangesPath
1.8 +5 -3 jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c
Index: jk_uri_worker_map.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jk_uri_worker_map.c 2001/08/06 17:31:45 1.7
+++ jk_uri_worker_map.c 2001/09/27 10:42:26 1.8
@@ -67,7 +67,7 @@
* servlet container. *
* *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.7 $ *
+ * Version: $Revision: 1.8 $ *
***/
#include jk_pool.h
@@ -413,11 +413,11 @@
unsigned i;
unsigned best_match = -1;
unsigned longest_match = 0;
-char clean_uri[4096];
+char clean_uri = NULL;
char *url_rewrite = strstr(uri, JK_PATH_SESSION_IDENTIFIER);
if(url_rewrite) {
-strcpy(clean_uri, uri);
+clean_uri = strdup(uri);
url_rewrite = strstr(clean_uri, JK_PATH_SESSION_IDENTIFIER);
*url_rewrite = '\0';
uri = clean_uri;
@@ -485,6 +485,7 @@
}
if(-1 != best_match) {
+free(clean_uri);
return uw_map-maps[best_match]-worker_name;
} else {
/*
@@ -501,6 +502,7 @@
jk_log(l, JK_LOG_EMERG,
In jk_uri_worker_map_t::map_uri_to_worker, found a security
fraud in '%s'\n,
uri);
+free(clean_uri);
return uw_map-maps[fraud]-worker_name;
}
}
RE: TC 3.3: getRequestURI()
Thanks to port mod_jk/ajp13 modifications to jk in J-T-C ;) Just to be in sync... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Keith Wannamaker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 2:27 AM To: [EMAIL PROTECTED] Subject: RE: TC 3.3: getRequestURI() I'm +1 for this. It is the best solution. Keith | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] | | 3. Revert to the use of uri ( i.e. the decoded uri ), and | change the getRequestURI ( the facade ) to generated a | 'canonical' encoding. | Problems:
Plans on release of j.-t-c mod_jk for TC 4.0
Hola a todos, Remmy: which are the plans ( timing and schedule ) for release j-t-c code for use with tc 4.0? I think i can port isapi_redirect changes from 3.3 to j-t-c, in the next weekend or next next :), is that ok for you ? Saludos , Ignacio J. Ortega
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers ReloadInterceptor.java
bojan 01/09/24 21:33:45
Modified:src/share/org/apache/tomcat/modules/mappers
ReloadInterceptor.java
Log:
Enable local interceptor reload at context reload.
Revision ChangesPath
1.12 +18 -0
jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers/ReloadInterceptor.java
Index: ReloadInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers/ReloadInterceptor.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ReloadInterceptor.java2001/09/16 00:33:30 1.11
+++ ReloadInterceptor.java2001/09/25 04:33:45 1.12
@@ -184,6 +184,14 @@
ContextManager cm=ctx.getContextManager();
if( fullReload ) {
+ Vector sI=new Vector(); // saved local interceptors
+ BaseInterceptor[] eI;// all exisiting interceptors
+
+ // save the ones with the same context, they are local
+ eI=ctx.getContainer().getInterceptors();
+ for(int i=0; i eI.length ; i++)
+ if(ctx == eI[i].getContext()) sI.add(eI[i]);
+
Enumeration e;
// Need to find all the config that
// was read from server.xml.
@@ -205,6 +213,16 @@
cm.removeContext( ctx );
cm.addContext( ctx1 );
+
+ // put back saved local interceptors
+ e=sI.elements();
+ while(e.hasMoreElements()){
+ BaseInterceptor savedI=(BaseInterceptor)e.nextElement();
+
+ ctx1.addInterceptor(savedI);
+ savedI.setContext(ctx1);
+ savedI.reload(request,ctx1);
+ }
ctx1.init();
Proble with Unloading Catalina
hi, I am running catalina on HP-UX. When i give the following command, /home/cio_port/jwdf_src_v101/jwdf/ org.apa che.catalina.startup.Bootstrap start The catalina engine starts successfully. But it does not stop. I am using the following command for the same /home/cio_port/jwdf_src_v101/jwdf/ org.apa che.catalina.startup.Bootstrap stop The classpath is set properly as the catalina engine is running successfully. Any suggestion in this regard would be of great help. Anticipating earliest reply. Thanks in Advance Regards, Sai Sekhar __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
How to build MOD_WEBAPP connector on windows?
The README.txt file coming with the WebApp Module only described how to building it on UNIX,but how can i build it on windows 2K?
Tomcat and Socket send-buffer sizes
I've been trying to reduce the default blocks of 8k data being sent from tomcat back to the browser when a HTML page is returned from a JspWriter (because of a high packet-loss network connection becomimg prone to collisions and tcp restarts at this size). I've tried setting s.setSendBufferSize in tomcat/net/ServerSocketFactory (to 4k). I've tried setting the size of the buffer size used by tomcat/core/BufferedServletOutputStream. I've tried setting (on Solaris 8) tcp_xmit_hiwat on the server machine. I've tried changing the jsp page size with buffer=4k in the jsp page directive. A tcpdump log still shows a block of 8k being returned without any 'ack' from the client machine. This means that the TCP send buffer is not being affected by any of the above. I suspect that the TCP send-buffer size is being influenced by the stream associated with the socket, overriding the s.setSendBufferSize() but would like extra information on the subject. Also if I can reduce this value, do the developers have any thoughts on the knock-on effects of this, since I see that: jasper.runtime.BodyContentImpl jasper.runtime.JspWriterImpl tomcat.core.BufferedServletOutputStream jasper.constants tomcat.util.ByteBuffer all use a hard-coded value of 8k when allocating a buffer. Thanks for any help, Steve Owen.
[Fwd: Tomcat's non-polymorphic request handler.]
I sent this to the tomcat user group, but got no response.
Comments?
I'm having some difficulty with the polymorphic behavior of Tomcat's
request handler.
Consider the following:
package RMS;
import java.lang.Integer;
public class TestPolyMorph {
int i;
String s;
public void setNumberVar(String i) {
this.i = Integer.parseInt(i);
}
public void setNumberVar(int i) {
this.i = i;
}
public int getNumber() {
return(i);
}
public void setStringVar(String s) {
this.s = s;
}
public String getStringVar(String s) {
return(s);
}
public TestPolyMorph() {
}
}
... and the .JSP file:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
head
!-- meta http-equiv=Pragma content=no-cache
meta http-equiv=Expires content=Mon, 01 Jan 1990 00:00:01 GMT
--
meta http-equiv=Content-Type
content=text/html;CHARSET=iso-8859-1
meta http-equiv=Content-Style-Type content=text/css
/head
%@ page language=java import=RMS.* %
jsp:useBeanid=ui class=RMS.TestPolyMorph scope=session/
jsp:setProperty name=ui property=*/
body
Testing... Testing... Testing.
/body
/html
Now... the passing a non-integer value for the property: numberVar will
yield a stack trace:
http://SERVER:PORT/CONTEXT/jsp/TestPolyMorph.jsp?numberVar=foobar
org.apache.jasper.JasperException: foobar
at
org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper(JspRuntimeLibrary.java:204)
at
org.apache.jasper.runtime.JspRuntimeLibrary.introspect(JspRuntimeLibrary.java:152)
at
jsp._0002fjsp_0002fTestPolyMorph_0002ejspTestPolyMorph_jsp_2._jspService(_0002fjsp_0002fTestPolyMorph_0002ejspTestPolyMorph_jsp_2.java:91)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)
Root cause:
org.apache.jasper.JasperException: 3.2
at
org.apache.jasper.runtime.JspRuntimeLibrary.convert(JspRuntimeLibrary.java:138)
at
org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper(JspRuntimeLibrary.java:198)
at
org.apache.jasper.runtime.JspRuntimeLibrary.introspect(JspRuntimeLibrary.java:152)
at
jsp._0002fjsp_0002fTestPolyMorph_0002ejspTestPolyMorph_jsp_2._jspService(_0002fjsp_0002fTestPolyMorph_0002ejspTestPolyMorph_jsp_2.java:91)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)
Even though there is indeed a method signature:
setNumberVar(String i);
Tomcat prefers to use (through introspection):
setNumberVar(int i);
The beans I use to handle property settings must continue to use
polymorphism.
Any ideas?
Thanks,
matt
---BeginMessage---
I'm having some difficulty with the polymorphic behavior of Tomcat's
request handler.
Consider the following:
package RMS;
import java.lang.Integer;
public class TestPolyMorph {
int i;
String s;
public void setNumberVar(String i) {
this.i =
Re: %=x% expression syntax bug in XML jsp?
One approach we also considered was a JSP action that can be used to construct an XML element dynamically. For example (shooting from the hip) jsp:element name=theAttributeName jsp:attribute name=theAttributenameValue/jsp:attribute jsp:attribute name=anotherAttributeName value=inlineValue/ /jsp:element In your case that would be: jsp:element name=text jsp:attribute name=y value=10/ jsp:attribute name=x value=%=xpos%/ /jsp:element That is essentially what what XSLT does. My recollection is that XSP has something like that too. This seems, to me, to be pretty in the spirit of XML. In the end we decided not to include this because it can be written as a plain custom-action and we could wait before adding it to the language. I believe that the JSPTL 1.0 EG is talking about adding such an action. There are some other things that could be done in the JSP syntax, including a new bodyContent property of a tag that requires it to be a well formed XML document, plus an in-line expansion of expressions... But we never looked much into that part. I do agree that we will be doing much more XML in the future, so I hope that we will fine-tune the XML syntax in JSP 1.3 based on feedback from all of you. Thanks, - eduard/o Mark Abbott wrote: Hi Craig - I'm curious whether the expert group has discussed what might be done in the future about this unfortunate aspect of JSP. In what I would think would be a really common case in the future, where one wants to design an app using clean, readable, and purely XML templates (perhaps XHTML for example), but editing by hand rather than with some JSP savvy tool, the choices are: * Create a custom tag foo:text which just dumps out the corresponding text tag Wrapping all the tags in every markup of interest is impractical * Write the XML syntax in the way that the JSP compiler expects: jsp:text![CDATA[text y=10 x=]] jsp:expressionxpos/jsp:expression jsp:text