Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Quoting [EMAIL PROTECTED]: It's jk_translate who decides if a request is to be handled by jk ( by mapping it to a uriEnv ). You can add a test for r-handler==DIR_MAGIC_TYPE, but don't assume any uriEnv is set. Actually, r-handler is always NULL in jk_translate(). At least in mod_jk 1.2.0 (but I'm suspecting that would be the case in mod_jk2 as well, because it's Apache that determines that). So, adding the test wouldn't do anything. If DirectoryIndex is not used, by the time jk_handler() is reached with DIR_MAGIC_TYPE, we're out of mod_dir. If DirectoryIndex is used, then we end up in jk_handler() much sooner, by an explicit call from within mod_dir. That's, of course, when a static file exists. In none of the cases is r-handler set while in jk_translate(). So, for now, I think the only option is to rely on DIR_MAGIC_TYPE test in jk_handler(). How's that going to work in mod_jk2, I have no idea... Hopefully, Mark will do a few tests and then we'll know more. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Mon, 22 Jul 2002, Craig R. McClanahan wrote: In Servlet 2.4 (Community Draft 2), it looks like the language in Section 9.10 that describes this hasn't changed. The basic rule is that you combine the partial URLs specified in the welcome file list to the incoming request for a directory resource in the WAR -- and if a resource in the WAR is mapped that request URI then it's supposed to be served by the servlet corresponding to the complete request URI. And that can't work - if index.jsp is specified as index, then *.jsp mapping will allways match. Acording the the servlet spec there is no requirement for index.jsp to be present ( it can be precompied ), and no way to ask a servlet like JspServlet if a request will work without executing it. So the only correct implementation would be to execute service() - and if the result is a 404 then we should try the next match. However there is no guarantee that the extension-mapped servlet will return 404 - in many cases servlets are using the pathinfo to do some actions ( like Struts ) and may return something valid. Catalina interprets the requirement as meaning that there has to be a static resource that matches. This has the side effect that you can't use a regular servlet mapping that doesn't correspond to a static resource -- if you could, that would mean that a welcome file like foo.jsp would match every time, even if there wasn't such a page in the specified directory, because of the *.jsp mapping. I know. And I think you can't use index.do or pre-compiled jsps ( unless you also have the jsp source files - which in many cases is not desirable ). 3.3 has a similar implementation - and I don't think either implements the spec corectly. It would seem that a web connector should at least be able to emulate what Catalina does, by checking for the existence of a static file in the webapp directory. +1 I don't know how you could implement a generic servlet matching a welcome file path, unless we were to exclude extension mapping and default servlet from the definition of matching. And I'm not sure that even that would do the right thing in all circumstances. It's the index.jsp that worries me - combined with precompile jsps. That could be an extremely common case - and will fail with the current implementation. And of course, I would be good to know if it is at least possible to implement this - and if not to have it fixed in the spec. My proposal was to consider all exact and prefix mappings ( that would cover precompiled jsps and struts ), as well as static files. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Any interest in a Poolman DataSource Factory class?
Isaac Arias wrote: Hi, I know that Tomcat is moving towards using the commons db pool but there may be some people still using the Poolman package to do connection pooling. I created a PoolmanDataSourceFactory that can be plugged into Tomcat 4.0.x and Tomcat 4.1.x to provide Poolman managed pools through the Tomcat JNDI context. This is a good way to transition projects into the J2EE recommended JNDI/DataSource approach without breaking old code that uses other Poolman APIs. If there's any interest I'll be happy to send the file over to whoever needs it. Sounds good. Post it on the list so that people can have a look at the actual code. Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11075] New: - [PATCH] AccessLogValue Request Header ${xxx}i support
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=11075.
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=11075
[PATCH] AccessLogValue Request Header ${xxx}i support
Summary: [PATCH] AccessLogValue Request Header ${xxx}i support
Product: Tomcat 4
Version: 4.1.7
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Added in support for the AccessLog code to enable customised log patterns which
include request headers using the standard Apache server ${xxx}i syntax. Also
changed 'if' statements to potentially more efficient 'case' statements.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11075] - [PATCH] AccessLogValue Request Header ${xxx}i support
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=11075.
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=11075
[PATCH] AccessLogValue Request Header ${xxx}i support
--- Additional Comments From [EMAIL PROTECTED] 2002-07-23 10:01 ---
Created an attachment (id=2448)
Patch to AccessLogValue.java file
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11076] New: - Security grants are not recognized by all loaded classes
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=11076. 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=11076 Security grants are not recognized by all loaded classes Summary: Security grants are not recognized by all loaded classes Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I have found the following problem: I use Tomcat with the security manager. File permissions granted to servlets work very well. File permissions granted to classes imported by sevlets don´t work. The example files are attached: The attached SendMailService class is able to write, the imported UploadBuffer class is not. I have tried: export CATALINA_OPTS=-Djava.security.debug=all The permissions are succesfully recognized but then they fail. Best regards Thomas -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - jakarta-tomcat-4.0
This email is autogenerated from the output from:
http://jakarta.apache.org/builds/gump/2002-07-23/jakarta-tomcat-4.0.html
Buildfile: build.xml
deploy-prepare:
deploy-static:
deploy:
[echo] Target: Catalina - Deploy ...
flags:
flags.display:
[echo] --- Build environment for Catalina ---
[echo] If ${property_name} is displayed, then the property is not set)
[echo] --- Build options ---
[echo] full.dist=${full.dist}
[echo] build.sysclasspath=only
[echo] compile.debug=${compile.debug}
[echo] compile.deprecation=${compile.deprecation}
[echo] compile.optimize=${compile.optimize}
[echo] --- Ant Flags ---
[echo] style task available (required)=true
[echo] --- JDK ---
[echo] jdk.1.2.present=true
[echo] jdk.1.3.present=true
[echo] jdk.1.4.present=${jdk.1.4.present}
[echo] --- Source Dependencies ---
[echo] jtc.home.present=true
[echo] --- Required Libraries ---
[echo] beanutils.present=true
[echo] collections.present=true
[echo] digester.present=true
[echo] jaxp.present=true
[echo] jndi.present=true
[echo] logging.present=true
[echo] regexp.present=true
[echo] servlet.present=true
[echo] --- Optional Libraries ---
[echo] daemon.present=${daemon.present}
[echo] dbcp.present=true
[echo] jaas.present=true
[echo] javamail.present=true
[echo] jmx.present=true
[echo] jsse.present=true
[echo] jta.present=true
[echo] junit.present=true
[echo] ldap.present=true
[echo] modeler.present=true
[echo] pool.present=true
[echo] tyrex.present=${tyrex.present}
[echo] --- Required JARs ---
[echo] jndi.jar.present(except JDK 1.3+)=true
[echo] regexp.jar.present=true
[echo] servlet.jar.present=true
[echo] xerces.jar.present(except JDK 1.4+ or xerces2)=true
[echo] xerces2.jars.present(except JDK 1.4+ or xerces1)=${xerces2.jars.present}
[echo] --- Optional JARs ---
[echo] daemon.jar.present=${daemon.jar.present}
[echo] dbcp.jar.present=true
[echo] jaas.jar.present=true
[echo] javamail.jar.present=true
[echo] jdbc20ext.jar.present=true
[echo] jmx.jar.present=true
[echo] jta.jar.present=true
[echo] junit.jar.present=${junit.jar.present}
[echo] ldap.jar.present=true
[echo] modeler.jar.present=true
[echo] pool.jar.present=true
[echo] tyrex.jar.present=${tyrex.jar.present}
[echo] --- Conditional compilation flags ---
[echo] compile.daemon=${compile.daemon}
[echo] compile.dbcp=true
[echo] compile.jaas=true
[echo] compile.javamail=true
[echo] compile.jmx=true
[echo] compile.jndi=true
[echo] compile.jsse=true
[echo] compile.jta=true
[echo] compile.junit=true
[echo] compile.ldap=true
[echo] compile.ssi=true
[echo] compile.tyrex=${compile.tyrex}
[echo] --- Distribution flags ---
[echo] copy.daemon.jar=${copy.daemon.jar}
[echo] copy.dbcp.jar=true
[echo] copy.jaas.jar=true
[echo] copy.jdbc20ext.jar=true
[echo] copy.javamail.jar=true
[echo] copy.jmx.jar=true
[echo] copy.jndi.jar=${copy.jndi.jar}
[echo] copy.jta.jar=true
[echo] copy.ldap.jar=${copy.ldap.jar}
[echo] copy.logging.jar=true
[echo] copy.modeler.jar=true
[echo] copy.pool.jar=true
[echo] copy.tyrex.jar=${copy.tyrex.jar}
[echo] copy.xerces.jar=true
[echo] copy.xerces2.jars=${copy.xerces2.jars}
build-prepare:
copy-activation.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-daemon.jar:
copy-dbcp.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-jaas.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
copy-jdbc20ext.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-jmx.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
copy-jndi.jar:
copy-jsse.jar:
copy-jta.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-ldap.jar:
copy-modeler.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
copy-pool.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
copy-tyrex.jar:
copy-xerces.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/endorsed
copy-xerces2.jars:
build-static:
build-tomcat-util:
detect:
DO NOT REPLY [Bug 11076] - Security grants are not recognized by all loaded classes
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=11076. 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=11076 Security grants are not recognized by all loaded classes --- Additional Comments From [EMAIL PROTECTED] 2002-07-23 10:33 --- Created an attachment (id=2449) The example files (zip archive) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5899] - HTTP POST parameters ignored in CGIServlet.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=5899. 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=5899 HTTP POST parameters ignored in CGIServlet.java [EMAIL PROTECTED] changed: What|Removed |Added Version|4.0.1 Final |4.0.4 Final -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE]: Re: cvs commit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
And I answer (to myself :-)
On Tue, 2002-07-23 at 14:47, Bojan Smojver wrote:
So, the unsolved questions for me are:
1. What is it then that jk_handler() does that makes it actually serve the
request when DIR_MAGIC_TYPE is included in the test? It must be that its mapping
is 'better' than mapping of jk_translate()...
Nothing special - it just does it ALWAYS. Which means that Tomcat ALWAYS
gets involved, which is NOT what Bill wanted (sorry Bill) and is
definitely not what I wanted. In order to fix that and let Apache handle
the directories it can physically see, and give the rest to Tomcat, we'd
need to do this at the beginning of jk_handler():
-
/* Deciding if this request is for us, or should we pass it on */
if(strcmp(r-handler,JK_HANDLER)){
if(strcmp(r-handler,DIR_MAGIC_TYPE)) /* Not directory, skip */
return DECLINED;
else if(ap_is_directory(r-pool, r-filename)) /* Can stat, skip */
return DECLINED;
}
-
Which would then mean that you MUST have DirectoryIndex in place if you
have extension mappings and want your physically accessible files served
by Tomcat. It would also mean that all physically accessible
directories, without ANY index files mentioned in DirectoryIndex, would
be served by Apache. Anything else would go to Tomcat for resolution.
This is not ideal and maybe not even correct, but it is the best I can
come up with at this point.
Before I make any changes to the CVS, I'd like to know what everyone
thinks. So, here are the choices:
[ ] Keep it as is and send all DIR_MAGIC_TYPE requests to Tomcat
[ ] Keep it as is, but only if DIR_MAGIC_TYPE can be turned on/off
[ ] Remove DIR_MAGIC_TYPE handling altogether
[ ] Make the change
[ ] Make the change, but only if DIR_MAGIC_TYPE can be turned on/off
2. Or is it that jk_translate() never even gets involved during that request and
therefore never has the chance to do the mapping?
I answered this one before. The request with DIR_MAGIC_TYPE never
touches jk_translate().
Bojan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Announcing the JSP 2.0 Preview EA1 Implementation
can any provide a link to a working draft of the spec if it is availabe? I'd like to compare the Expression language portion against the JSTL spec. peter lin Mark Roth wrote: For those of you tracking the JSP 2.0 specification, we are pleased to announce the availability of an Early Access Preview implementation, available now from: http://developer.java.sun.com/developer/earlyAccess/jsp/ The primary goal of the JSP 2.0 specification is to make JSP technology more productive and even easier to use. The specification is being developed by an expert group consisting of over 30 companies and individuals, and is currently in Public Review stages. More information on the specification, including a public download, is available at http://jcp.org/jsr/detail/152.jsp This implementation was developed collectively in the Expert Group using Tomcat 4.1 and Jasper2 as a base. The intent of the Expert Group is to integrate this source base with Tomcat 5.0. The Preview is intended solely to allow you, the developer community, to experiment with some of the new JSP 2.0 features and provide us, the JSR-152 (JSP 2.0) expert group, with hands-on feedback. Please send all feedback to [EMAIL PROTECTED] Please note that this is not a production release, and that not all JSP 2.0 features are implemented. Features implemented include: * New JSP 2.0 APIs * Integrated Expression Language Support * Supports new jsp:attribute and jsp:body standard actions * Supports new SimpleTag Handlers and JSP Fragments Features not yet implemented include: * JSR-45 Debugging Support * Tag Files * Attributes with Dynamic Names * JSP Configuration The download comes with pre-installed JSP 2.0 examples that help illustrate the new feature set. Please give it a try, and we look forward to hearing from you! -- Mark Roth, Java Software Specification Co-Lead of JSP 2.0 Sun Microsystems, Inc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Announcing the JSP 2.0 Preview EA1 Implementation
finally found the page for the spec. http://jcp.org/aboutJava/communityprocess/review/jsr152/index.html in case anyone else doesn't want to spend 10 minutes looking for the spec. peter peter lin wrote: can any provide a link to a working draft of the spec if it is availabe? I'd like to compare the Expression language portion against the JSTL spec. peter lin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin admin.xml
remm2002/07/23 05:12:15 Modified:webapps/admin admin.xml Log: - Add an example of host limiting in the admin webapp. - Patch submitted by Ian Darwin ian at darwinsys.com Revision ChangesPath 1.3 +8 -1 jakarta-tomcat-4.0/webapps/admin/admin.xml Index: admin.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/admin.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- admin.xml 27 Oct 2001 18:56:23 - 1.2 +++ admin.xml 23 Jul 2002 12:12:15 - 1.3 @@ -10,6 +10,13 @@ Context path=/admin docBase=../server/webapps/admin debug=0 privileged=true + !-- Uncomment this Valve to limit access to the Admin app to localhost + for obvious security reasons. Allow may be a comma-separated list of + hosts (or even regular expressions). + Valve className=org.apache.catalina.valves.RemoteAddrValve +allow=127.0.0.1/ + -- + Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_admin_log. suffix=.txt timestamp=true/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/admin admin.xml
remm2002/07/23 05:13:05 Modified:webapps/admin admin.xml Log: - Add an example of host limiting in the admin webapp. - Patch submitted by Ian Darwin ian at darwinsys.com Revision ChangesPath 1.2 +8 -1 jakarta-tomcat-catalina/webapps/admin/admin.xml Index: admin.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/admin.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- admin.xml 18 Jul 2002 16:48:16 - 1.1 +++ admin.xml 23 Jul 2002 12:13:05 - 1.2 @@ -10,6 +10,13 @@ Context path=/admin docBase=../server/webapps/admin debug=0 privileged=true + !-- Uncomment this Valve to limit access to the Admin app to localhost + for obvious security reasons. Allow may be a comma-separated list of + hosts (or even regular expressions). + Valve className=org.apache.catalina.valves.RemoteAddrValve +allow=127.0.0.1/ + -- + Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_admin_log. suffix=.txt timestamp=true/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session StandardSession.java
remm2002/07/23 05:49:11 Modified:catalina/src/share/org/apache/catalina/session StandardSession.java Log: - Set manager to null before recycling. - Patch submitted by Arvind Srinivasan arvind.srinivasan at sun.com Revision ChangesPath 1.31 +8 -8 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java Index: StandardSession.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- StandardSession.java 21 Jun 2002 18:14:21 - 1.30 +++ StandardSession.java 23 Jul 2002 12:49:11 - 1.31 @@ -766,12 +766,12 @@ setPrincipal(null); isNew = false; isValid = false; +Manager savedManager = manager; +manager = null; // Tell our Manager that this Session has been recycled -if ((manager != null) (manager instanceof ManagerBase)) -((ManagerBase) manager).recycle(this); - -manager = null; +if ((savedManager != null) (savedManager instanceof ManagerBase)) +((ManagerBase) savedManager).recycle(this); } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session StandardSession.java
remm2002/07/23 05:49:55 Modified:catalina/src/share/org/apache/catalina/session StandardSession.java Log: - Set manager to null before recycling. - Patch submitted by Arvind Srinivasan arvind.srinivasan at sun.com Revision ChangesPath 1.2 +8 -8 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java Index: StandardSession.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- StandardSession.java 18 Jul 2002 16:47:54 - 1.1 +++ StandardSession.java 23 Jul 2002 12:49:55 - 1.2 @@ -766,12 +766,12 @@ setPrincipal(null); isNew = false; isValid = false; +Manager savedManager = manager; +manager = null; // Tell our Manager that this Session has been recycled -if ((manager != null) (manager instanceof ManagerBase)) -((ManagerBase) manager).recycle(this); - -manager = null; +if ((savedManager != null) (savedManager instanceof ManagerBase)) +((ManagerBase) savedManager).recycle(this); } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11045] - Jikes compiler output appears in catalina.out not browser
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=11045. 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=11045 Jikes compiler output appears in catalina.out not browser [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2002-07-23 13:19 --- This works in Jasper 1, what makes it so difficult to capture the output of jikes in Jasper 2? If Jasper 2 still supports external plugin compilers, it should support capturing the output also. If not, perhaps support for external compilers should be removed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11076] - Security grants are not recognized by all loaded classes
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=11076. 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=11076 Security grants are not recognized by all loaded classes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|Security grants are not |Security grants are not |recognized by all loaded|recognized by all loaded |classes |classes --- Additional Comments From [EMAIL PROTECTED] 2002-07-23 13:30 --- You are not reporting a bug, you are reporting a misconfiguration of your catalina.policy or some other configuration error. Try running Tomcat with -Djava.security.debug=access,failure This should give you the information you need to track down what permission is not being granted. One other thing to look at. It looks like you are running Tomcat on unix. Unix file ownership and permissions still apply, it could very well be that the user Tomcat is running as doesn't have unix file permissions to perform some file operation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11076] - Security grants are not recognized by all loaded classes
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=11076. 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=11076 Security grants are not recognized by all loaded classes [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE]: Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Quoting Bojan Smojver [EMAIL PROTECTED]:
And I answer (to myself :-)
On Tue, 2002-07-23 at 14:47, Bojan Smojver wrote:
So, the unsolved questions for me are:
1. What is it then that jk_handler() does that makes it actually serve the
request when DIR_MAGIC_TYPE is included in the test? It must be that its
mapping
is 'better' than mapping of jk_translate()...
Nothing special - it just does it ALWAYS. Which means that Tomcat ALWAYS
gets involved, which is NOT what Bill wanted (sorry Bill) and is
definitely not what I wanted. In order to fix that and let Apache handle
the directories it can physically see, and give the rest to Tomcat, we'd
need to do this at the beginning of jk_handler():
-
/* Deciding if this request is for us, or should we pass it on */
if(strcmp(r-handler,JK_HANDLER)){
if(strcmp(r-handler,DIR_MAGIC_TYPE)) /* Not directory, skip */
return DECLINED;
else if(ap_is_directory(r-pool, r-filename)) /* Can stat, skip */
return DECLINED;
}
-
Which would then mean that you MUST have DirectoryIndex in place if you
have extension mappings and want your physically accessible files served
by Tomcat. It would also mean that all physically accessible
directories, without ANY index files mentioned in DirectoryIndex, would
be served by Apache. Anything else would go to Tomcat for resolution.
This is not ideal and maybe not even correct, but it is the best I can
come up with at this point.
Before I make any changes to the CVS, I'd like to know what everyone
thinks. So, here are the choices:
[ ] Keep it as is and send all DIR_MAGIC_TYPE requests to Tomcat
[ ] Keep it as is, but only if DIR_MAGIC_TYPE can be turned on/off
[ ] Remove DIR_MAGIC_TYPE handling altogether
[ ] Make the change
[ ] Make the change, but only if DIR_MAGIC_TYPE can be turned on/off
2. Or is it that jk_translate() never even gets involved during that
request and
therefore never has the chance to do the mapping?
I answered this one before. The request with DIR_MAGIC_TYPE never
touches jk_translate().
For someone who have all its tomcat behind a webserver, I'll be to have the
requests sent to Tomcat since my web servers won't have a directory created for
all the webapps available on tomcats farms behind.
Alternativly I don't want to receive index.php or index.pl in Tomcat, and so
want only the one which match with JkMount (in mod_jk 1.2 way), ie JkMount
*.jsp ajp13.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
remm2002/07/23 07:19:19 Modified:.RELEASE-NOTES-4.1.txt Log: - Status update for 4.1.8. Revision ChangesPath 1.14 +52 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- RELEASE-NOTES-4.1.txt 28 Jun 2002 17:31:41 - 1.13 +++ RELEASE-NOTES-4.1.txt 23 Jul 2002 14:19:19 - 1.14 @@ -76,6 +76,9 @@ [4.1.5] ServerLifecycleListener: Generate MBeans for the JNDI resources of the contexts. +[4.1.8] BootstrapService: +Allow passing parameters to the BootstrapService. + --- Jasper New Features: @@ -120,6 +123,8 @@ [4.1.6] Options: Add new enablePooling flag, which allows disabling tag reuse. +[4.1.8] JspCompilationContext: +Use _ instead of $ to generate file and class names for jsp servlets. == @@ -154,6 +159,9 @@ [4.1.6] Administration Webapp: Tweak validation code for the context parameters. +[4.1.8] Build: +Tomcat is now built with JDK 1.4. + -- Catalina Bug Fixes: @@ -322,6 +330,25 @@ [4.1.6] StandardContext: Reset application context when stopping. +[4.1.8] BootstrapService: +Prevent NPE when DaemonContext is not well initialised. + +[4.1.8] StandardServer: +Make sure the global resources are correctly initialized even if there +is no GlobalNamingResources element in server.xml. + +[4.1.8] MBean-descriptors: +Add PersistentManager MBean info to mbeans-descripor.xml so it doesn't +complain in case if you have PersistentManager. + +[4.1.8] #10967 +Summary: Java Deadlock in WebappClassLoader +WebappClassLoader: +Make ResourceEntry a separate class. + +[4.1.8] StandardSession: +Set manager to null before recycling. + Jasper Bug Fixes: @@ -405,6 +432,30 @@ [4.1.6] Generator: Add synchronization of the scripting variables. +[4.1.8] #10896 +Summary: Parsing ContentType error +ParserController: +Fix parsing. + +[4.1.8] #10713 +Summary: Backslashes quoting quotes in attributes does not work +Parser: +Fix parsing. + +[4.1.8] #10711 +Summary: Relative filenames with ../ do not work for JSP-includes +JspCompilationContext: +Add back path normalization code. + +[4.1.8] #10670 +Summary: Problem in JSP compilation +Generator: +Fix compilation problem. + +[4.1.8] #10766 +Summary: %@ page extends % causes ClassCastException +JspServletWrapper: +Fix regression caused by the included JSP modification tracking. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11045] - Jikes compiler output appears in catalina.out not browser
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=11045. 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=11045 Jikes compiler output appears in catalina.out not browser [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-07-23 14:21 --- Jasper 2 uses Ant to compile, so this is an Ant limitation. Jasper 2 has no support for external compilers, it supports whatever Ant 1.5 supports. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11086] New: - Null pointer exception in JasperLoader.loadClass(String, boolean)
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=11086.
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=11086
Null pointer exception in JasperLoader.loadClass(String, boolean)
Summary: Null pointer exception in JasperLoader.loadClass(String,
boolean)
Product: Tomcat 4
Version: 4.0.4 Final
Platform: All
OS/Version: Other
Status: NEW
Severity: Major
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
A null pointer is generated in a specific situation where a JSP page needs to
load a new class. The cause is not quite clear though.
The problem is directly caused by:
In the constructor the securityManager is initialized.
JasperLoader(URL [] urls, String className, ClassLoader parent,
PermissionCollection permissionCollection,
CodeSource codeSource) {
super(urls,parent);
...
this.securityManager = System.getSecurityManager();
}
Further on in public Class loadClass(String name, boolean resolve)
there is a check:
if (System.getSecurityManager() != null) {
if (dot = 0) {
try {
securityManager.checkPackageAccess(name.substring(0,dot));
As you can see the System.getSecurityManager() is checked to be set; and then
THE INSTANCE VARIABLE IS USED.
When at construction there is no security manager; this will be NULL. Af later
at class loading time there IS a security manager the method will cause a null
pointer.
Indirect causes:
I have no clue why there suddenly is a system classloader; I am just using
plain JSP pages and I am not messing about with security managers or class
loaders. Anyway, this kind of check seems erratic to me.
Kind regards,
Wido Riezebos
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper gump.xml
rubys 2002/07/23 07:35:54 Modified:.Tag: tomcat_4_branch gump.xml Log: Specify the tag on the tomcat_4_branch Revision ChangesPath No revision No revision 1.1.2.1 +1 -1 jakarta-tomcat-jasper/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat-jasper/gump.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- gump.xml 13 Apr 2002 17:09:08 - 1.1 +++ gump.xml 23 Jul 2002 14:35:54 - 1.1.2.1 @@ -5,7 +5,7 @@ /description url href=http://jakarta.apache.org/tomcat/index.html/ - cvs repository=jakarta / + cvs repository=jakarta tag=tomcat_4_branch/ project name=jakarta-tomcat-jasper/ /module -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
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=10671. 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=10671 Major issues with jsp:param in jsp:include and jsp:forward --- Additional Comments From [EMAIL PROTECTED] 2002-07-23 14:52 --- One can always encode hyperlinks to UTF-8 bytes and then URLEncode them. This always results in ASCII without any special characters. The issue is that the code processing the link requests must know to expect UTF-8 encoded data. The issue here is in making all of one's form submissions follow this as well (or using POST for forms and handling POST and GET a bit differently). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11086] - Null pointer exception in JasperLoader.loadClass(String, boolean)
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=11086.
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=11086
Null pointer exception in JasperLoader.loadClass(String, boolean)
--- Additional Comments From [EMAIL PROTECTED] 2002-07-23 14:55 ---
As it turns out a component I am using IS installing a (RMI)securityManager on
the fly. Tomcat is unable to handle this because of the previously described
flaw. Suggestion: modify
if (System.getSecurityManager() != null) {
into
if (securityManager != null) {
or do not cache the securityManager at all.
Wido
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10789] - Setting DirectoryIndex of index.jsp does not get served by jk2
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=10789. 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=10789 Setting DirectoryIndex of index.jsp does not get served by jk2 --- Additional Comments From [EMAIL PROTECTED] 2002-07-23 15:06 --- Bojan, I rebuilt mod_jk2 using your latest additions. It does not seem to work for mod_jk2. What happens is, my index.jsp gets displayed in the browser window, but without the jsp part. I.e., the index.jsp for the tomcat examples has this markup in it: %= application.getServerInfo() % that puts Apache Tomcat/4.1 in the center of the page just to the right of the tomcat logo. When I go to the directory, this is left blank. When I go directory to index.jsp it is served correctly. The log shows that the page does not go through mod_jk2, when I go to the directory. Here is some output from the quick test I did. Listing 1 is from the mod_jk2 log: going to httpd://204.210.44.99/ and then httpd://204.210.44.99/tomcat/examples/ Listing 2 is from the log and then going to: httpd://204.210.44.99/index.jsp and then : httpd://204.210.44.99/tomcat/examples/index.jsp Listing 3 is some parts of my httpd.conf Listing 4 is what I think is relevant from workers2.properties Listing 1: - - - - - - - - - - [Tue Jul 23 07:35:27 2002] (error ) [jk_logger_file.c (171)] Initializing log file G:/Apache32/Apache2/logs/jk2.log [Tue Jul 23 07:35:29 2002] (error ) [jk_logger_file.c (171)] Initializing log file G:/Apache32/Apache2/logs/jk2.log [Tue Jul 23 07:35:29 2002] (error ) [jk_logger_file.c (171)] Initializing log file G:/Apache32/Apache2/logs/jk2.log [Tue Jul 23 07:35:29 2002] (debug ) [jk_workerEnv.c (381)] workerEnv.init() create default worker lb:lb [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriMap.c (339)] uriMap.init() set default host [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriMap.c (353)] uriMap.init() loaded host (null) [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriMap.c (147)] uriMap.addUriEnv() / (null) / [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriMap.c (404)] uriMap.init() Create default context / ( for default host ) [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriMap.c (427)] uriMap.init() loaded context (null) /taza.net 678658 642858 63e740 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriMap.c (427)] uriMap.init() loaded context (null) /tomcat/examples 678658 642858 63e740 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriMap.c (427)] uriMap.init() loaded context (null) /admin 678658 642858 63e740 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriMap.c (427)] uriMap.init() loaded context (null) / 678658 642858 63e740 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriMap.c (445)] uriMap.init() processing mappings [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (339)] uriEnv.init() prefix mapping /jkstatus=status: [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (358)] uriEnv.init() uri:/jkstatus/* host=(null) uri=/jkstatus/* type=1 ctx=(null) prefix=/jkstatus suffix=(null) [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (314)] uriEnv.init() suffix mapping / .jsp=ajp13:204.210.44.99:8009 was added [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (358)] uriEnv.init() uri:/*.jsp host=(null) uri=/*.jsp type=2 ctx=(null) prefix=/ suffix=jsp [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (339)] uriEnv.init() prefix mapping /servlet=ajp13:204.210.44.99:8009 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (358)] uriEnv.init() uri:/servlet/* host=(null) uri=/servlet/* type=1 ctx=(null) prefix=/servlet suffix=(null) [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (339)] uriEnv.init() prefix mapping /pages=ajp13:204.210.44.99:8009 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (358)] uriEnv.init() uri:/pages/* host=(null) uri=/pages/* type=1 ctx=(null) prefix=/pages suffix= (null) [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (263)] uriEnv.init() context mapping /taza.net=ajp13:204.210.44.99:8009 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (263)] uriEnv.init() context mapping /tomcat/examples=ajp13:204.210.44.99:8009 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (263)] uriEnv.init() context mapping /admin=ajp13:204.210.44.99:8009 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (339)] uriEnv.init() prefix mapping /admin=ajp13:204.210.44.99:8009 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (358)] uriEnv.init() uri:/admin/* host=(null) uri=/admin/* type=1 ctx=(null) prefix=/admin suffix= (null) [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (339)] uriEnv.init() prefix mapping /manager=ajp13:204.210.44.99:8009 [Tue Jul 23 07:35:29 2002] (debug ) [jk_uriEnv.c (358)] uriEnv.init() uri:/manager/* host=(null) uri=/manager/* type=1 ctx=/manager prefix=/manager suffix=(null) [Tue Jul 23
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Constants.java
remm2002/07/23 08:27:24 Modified:http11/src/java/org/apache/coyote/http11 Constants.java Log: - Make the agent name conform to the usual standards. Revision ChangesPath 1.9 +1 -1 jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java Index: Constants.java === RCS file: /home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- Constants.java24 Jun 2002 21:38:59 - 1.8 +++ Constants.java23 Jul 2002 15:27:24 - 1.9 @@ -81,7 +81,7 @@ * Server string. */ public static final String SERVER = -Apache Coyote HTTP/1.1 Connector [1.0]; +Apache Coyote/1.0; /** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Mon, 22 Jul 2002 [EMAIL PROTECTED] wrote: It's the index.jsp that worries me - combined with precompile jsps. That could be an extremely common case - and will fail with the current implementation. As a workaround, why don't you just include the JSP source files in the war anyway? One of the things JSPC creates for you is a bunch of exact match servlet mappings for the compiled pages, and those will take priority over the extension-match mapping of the index.jsp page to the JSP servlet. And of course, I would be good to know if it is at least possible to implement this - and if not to have it fixed in the spec. My proposal was to consider all exact and prefix mappings ( that would cover precompiled jsps and struts ), as well as static files. Sounds like a topic worth raising with the Servlet 2.4 expert group (JSR-154). I'll start a message thread abou this on the EG mailing list. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11091] New: - Tomcat 4.1.7 ignores error page specified in web.xml
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=11091. 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=11091 Tomcat 4.1.7 ignores error page specified in web.xml Summary: Tomcat 4.1.7 ignores error page specified in web.xml Product: Tomcat 4 Version: 4.1.7 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have created a simple test case to illustrate this bug. The test case is a simple web application, with 2 jsp pages (Error.jsp and test.jsp) and a web.xml deployment descriptor. Error.jsp is a simple one line jsp page (This is the error page) test.jsp does nothing but throw a javax.servlet.jsp.JspException. web.xml has a /Error.jsp set as the designated error page for both 500 response codes and exceptions of type javax.servlet.jsp.JspException. Under tomcat 4.0.3, the expected result occurs; when test.jsp is accessed the contents of the custom error page are returned instead. However, under tomcat 4.1.7, with the exact same web-app a different result occurs. When test.jsp is accessed, a generic apache error page is displayed instead of the custom error page that appears in v4.0.3 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11091] - Tomcat 4.1.7 ignores error page specified in web.xml
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=11091. 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=11091 Tomcat 4.1.7 ignores error page specified in web.xml --- Additional Comments From [EMAIL PROTECTED] 2002-07-23 15:46 --- Created an attachment (id=2450) a zip file containing a test case (web app) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Tue, 23 Jul 2002, Craig R. McClanahan wrote: It's the index.jsp that worries me - combined with precompile jsps. That could be an extremely common case - and will fail with the current implementation. As a workaround, why don't you just include the JSP source files in the war anyway? One of the things JSPC creates for you is a bunch of exact match servlet mappings for the compiled pages, and those will take priority over the extension-match mapping of the index.jsp page to the JSP servlet. I know, and so far that's the only solution I found to make index.jsp work. However there are cases where you don't want to distribute the JSP source files - and AFAIK the spec allows that. I'm not really looking for workarounds - but for the 'correct' behavior, that we can eventually implement, and eventually a clarification to the spec - if this can't be implemented. The root of many problems is the way the extension mapping is defined - in a very different way from what all web servers are doing. That creates many integration problems, disables the pathInfo for extension-mapped resources, brakes the index, and may have other effects in future. Of course, in this particular case ( index.jsp - without having the file ) the extension mapping is usefull. Sounds like a topic worth raising with the Servlet 2.4 expert group (JSR-154). I'll start a message thread abou this on the EG mailing list. Thanks. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
XML parsers and TC4.1.x
The XML parsers in TC4.1.x are in common/endorsed. I need these to be only available to the server and therefore in server/endorsed. Is this supposed to work? Also if using JDK1.4, does TC use the JDK's parser or the parser on the classpath as preference? Dave
Re: Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote: Date: Tue, 23 Jul 2002 09:34:18 -0700 (PDT) From: [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c On Tue, 23 Jul 2002, Craig R. McClanahan wrote: It's the index.jsp that worries me - combined with precompile jsps. That could be an extremely common case - and will fail with the current implementation. As a workaround, why don't you just include the JSP source files in the war anyway? One of the things JSPC creates for you is a bunch of exact match servlet mappings for the compiled pages, and those will take priority over the extension-match mapping of the index.jsp page to the JSP servlet. I know, and so far that's the only solution I found to make index.jsp work. However there are cases where you don't want to distribute the JSP source files - and AFAIK the spec allows that. A zero-length file, rather than the actual source, would still fill the bill :-) I'm not really looking for workarounds - but for the 'correct' behavior, that we can eventually implement, and eventually a clarification to the spec - if this can't be implemented. I know ... a clarification is the important thing. The root of many problems is the way the extension mapping is defined - in a very different way from what all web servers are doing. That creates many integration problems, disables the pathInfo for extension-mapped resources, brakes the index, and may have other effects in future. Of course, in this particular case ( index.jsp - without having the file ) the extension mapping is usefull. Sounds like a topic worth raising with the Servlet 2.4 expert group (JSR-154). I'll start a message thread abou this on the EG mailing list. Thanks. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH]Japanese localization for Tomcat-Admin (2nd time)
Hi, Tomcat 4 commiters, Why didn't you take this patch? Please tell me what I should do. Original Message: Message-ID: [EMAIL PROTECTED] Subject: [PATCH]Japanese localization for Tomcat-Admin Date: Thu, 18 Jul 2002 01:42:30 +0900 To: [EMAIL PROTECTED] I post Japanese localization patch for Tomcat Administration Tool. (original: jakarta-tomcat-4.1.7-LE-jdk14 binary distribution) This patch was made by Okamoto-san and me. It includes the Japanese resource file and modified .jsp files. in .jsp, we added the page directive as follows: [contentType=text/html;charset=utf-8] So, it'll be also useful for i18n. I hope you take this patch. Thanks. --- MORIGUCHI Hirokazu [EMAIL PROTECTED], [EMAIL PROTECTED] ApplicationResources_ja.properties Description: Binary data tomcat-admin-4.1.7-ja.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: XML parsers and TC4.1.x
On Tue, 23 Jul 2002, David Oxley wrote: Date: Tue, 23 Jul 2002 17:53:14 +0100 From: David Oxley [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Subject: XML parsers and TC4.1.x The XML parsers in TC4.1.x are in common/endorsed. I need these to be only available to the server and therefore in server/endorsed. Is this supposed to work? Also if using JDK1.4, does TC use the JDK's parser or the parser on the classpath as preference? There is no such thing as support for server/endorsed. As you can see by looking at the catalina.bat or catalina.sh startup script, the $CATALINA_HOME/common/endorsed directory is passed as a command line setting of the java.endorsed.dirs system property, which makes this directory (instead of $JAVA_HOME/jre/lib/ext) the place where system extensions that override the base classes are stored. This setting is global to the entire JVM, and cannot be performed only for the Tomcat internal classes. Dave Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Missing patch for Japanese support in admin
Hi, Amy and Craig, On Mon, 22 Jul 2002, Amy Roh wrote: If I remember correctly, I believe someone sent a patch for Japanese support in admin webapp a while ago. I accidentally deleted the email Craig R. McClanahan [EMAIL PROTECTED] wrote: I'm pretty sure it was in July, and had the word Japanese or admin in the subject, so you should be able to search for it pretty quickly. Sorry, I overlooked your mails and posted 2nd mail with same patches. see: Subject: [PATCH]Japanese localization for Tomcat-Admin (2nd time) Date: Wed, 24 Jul 2002 01:55:01 +0900 I'm happy to look such a user-friendly Admin-Tool (what lacked in Tomcat). Thanks --- MORIGUCHI Hirokazu [EMAIL PROTECTED], [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: ajp13 (Tomcat 3.2.x) corrupting requests??
We are using Apache 1.3.26 and Tomcat 3.2.2. We've seen some
clients to be hanging Apache on SSL read. The cause of this
hang seems to be network/TCP/IP issue. The read will eventually
times out. When it times out, here's where the problem starts.
Tomcat seems to be grabbing some buffer that contains partial
data of the previous request and call a servlet with it. The
servlet will throw an exception because the data is bad. Here
are the details (you will need to pull up the code to see what
I mean).
When Apache read times out, mod_jk's
jk_ajp13_worker.c::read_into_msg_buff()
will return error. mod_jk will drop its connection to Tomcat and
retry (up to JK_RETRIES times - see the service() function). In
the retry, the HTTP header gets resent to Tomcat.
When Tomcat receives this header, it will eventually call
Ajp13ConnectorRequest::decodeRequest(). This method will
attempt to read more data from mod_jk (the call to con.receive()).
This call will fail because mod_jk has yet again drop the
connection (in its 2nd retry to call read_into_msg_buff() fails).
Since this call (con.receive()) fails, the attribute blen is
never set to the content-length of this request. Instead, blen
has the value of the content-length of the previous request.
Because the call to con.receive() fails, the method decodeRequest()
will return -1. The caller to decodeRequest,
Ajp13ConnectionHandler::processConnection(), doesn't check the error
code and it proceeds to call the servlet.
The servlet will issue a read and it will eventually call
Ajp13ConnectorRequest::doRead().
In doRead(), I dumped some values of the variables. pos is always 0.
blen is some number. The problem happens when blen is less than
the length of the buffer (variable len). The method will copy
some data from bodyBuff, which is a left-over from previous
request.
Note, I checked the source code for Tomcat 3.2.4. It doesn't seem
to be fixed yet. We may not have the luxury to upgrade to Tomcat 3.3
yet. So I am attempting to fix this, but I have a question:
Why does Ajp13ConnectionHandler::processConnection() not check
the error code from decodeRequest()? It seems to me like if it
gets an error in decodeRequest(), it should not call the service()
method which calls the servlet.
So the fix I'm proposing is to add these lines (see diff below).
I've tested this minimally and seemed to fix the problem I saw.
I will need to do more extensive testing, but please let me know
what you think. Do you see any problems with doing this?
thanks,
shinta
Index: Ajp13ConnectionHandler.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/service/conne
ctor/Attic/Ajp13ConnectionHandler.java,v
retrieving revision 1.4.2.1
diff -c -b -w -r1.4.2.1 Ajp13ConnectionHandler.java
*** Ajp13ConnectionHandler.java 12 Dec 2000 09:41:43 - 1.4.2.1
--- Ajp13ConnectionHandler.java 19 Jul 2002 15:58:47 -
***
*** 157,162
--- 157,166
case JK_AJP13_FORWARD_REQUEST:
err = req.decodeRequest(msg);
+ if ( err0 ) {
+ moreRequests=false;
+ break;
+ }
contextM.service(req, res);
req.recycle();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH]Japanese localization for Tomcat-Admin (2nd time)
I'll apply this patch. Thanks, Moriguchi and Okamoto. :-) Amy Hi, Tomcat 4 commiters, Why didn't you take this patch? Please tell me what I should do. Original Message: Message-ID: [EMAIL PROTECTED] Subject: [PATCH]Japanese localization for Tomcat-Admin Date: Thu, 18 Jul 2002 01:42:30 +0900 To: [EMAIL PROTECTED] I post Japanese localization patch for Tomcat Administration Tool. (original: jakarta-tomcat-4.1.7-LE-jdk14 binary distribution) This patch was made by Okamoto-san and me. It includes the Japanese resource file and modified .jsp files. in .jsp, we added the page directive as follows: [contentType=text/html;charset=utf-8] So, it'll be also useful for i18n. I hope you take this patch. Thanks. --- MORIGUCHI Hirokazu [EMAIL PROTECTED], [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Mavenizing tomcat..
Hi everyone, As Costin mentioned on the commons-dev list, is that a real test for maven would be mavenizing tomcat (tomcat-connectors would be cool too btw..). Since I am volunteering and don't have commit access (and now for a whle not fulltime tomcatting anymroe) , I want to ask for some support when needed (and testing) and commiting of the project.xml and the maven.xml when I get an initial build running.. I'll hope to get started near the end of the week on this.. Mvgr, Martin BTW mavezing it, doens't mean replacing the current build,xml ! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Re: JDK 1.4 Logging
On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
I think there is a simpler solution for this class of problems, and
that would also work with log4j and doesn't require _any_ API change.
( only changes to the adapter implementations )
Any 'wrapper' will use:
factory=LogFactory.getFactory();
factory.setAttribute( commons-logging.wrapperClass,
[CLASSNAME-OF-WRAPPER]);
factory.getLog(), etc.
Ok, I experimented some with this. I found that the wrapperMethod
(namely looking for method names log() and internalLog()) are more
effective than a classname for identifying uninteresting stack frames.
Seems Tomcat has 71 classes with a method named log() and often
logs messages from within the class itself.
The attached patch.txt is the Change to commons.
The CommonsLogger.java is a new tomcat logger that sends output
to the commons-logger.
Does this look good?
Cheers,
-bob
The classname of wrapper will be passed to the impl..
- for log4j - this just gets passed further, since log4j already supports
this feature.
- for jdk1.4 or other loggers who don't support wrapping - there is
already code in Jdk14Logger that walks the stack trace. Curently it
uses a hard-coded '2 levels up', but it can use the wrapperClass
and walk up to find it.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
/*
* $Header: $
* $Revision: $
* $Date: $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.catalina.logger;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* Implementation of bLogger/b that appends log messages to the
* Commons logger
*
* @version $Revision: $ $Date: $
*/
public class CommonsLogger
extends LoggerBase
implements Lifecycle {
// - Instance Variables
/**
* The descriptive information about this implementation.
*/
protected static final
jakarta-tomcat-connectors-4.0.4
Hello and thanks for reading! Trying to build mod_jk2 for Tomcat4 and Apache2... with huge problems :( Having gotten this far, I have this compile problem: apache 2.0.39; freebsd 4.4 i386; conne4ctors 4.0.4 snip [so] In file included from /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/include/jk_env.h:71, [so] from /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/include/jk_pool.h:67, [so] from /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/common/jk_uriMap.c:73: [so] /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/include/jk_mutex.h:122: syntax error before `apr_thread_mutex_t' BUILD FAILED file:/usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/build.xml:276: Compile failed /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/common/jk_uriMap.c snip one of the main problems is that apache 2 installs into several directories under freebsd ports, and the connector compile script expects it to go into just one - apache2/ ... Any suggestions, ideas? Thanks in advance, Mike -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk2
Hello and thanks for reading! Trying to build mod_jk2 for Tomcat4 and Apache2... with huge problems :( Having gotten this far, I have this compile problem: apache 2.0.39; freebsd 4.4 i386; conne4ctors 4.0.4 snip [so] In file included from /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/include/jk_env.h:71, [so] from /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/include/jk_pool.h:67, [so] from /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/common/jk_uriMap.c:73: [so] /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/include/jk_mutex.h:122: syntax error before `apr_thread_mutex_t' BUILD FAILED file:/usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/build.xml:276: Compile failed /usr/tmp/jakarta-tomcat-connectors-4.0.4-src/jk/native2/common/jk_uriMap.c snip one of the main problems is that apache 2 installs into several directories under freebsd ports, and the connector compile script expects it to go into just one - apache2/ ... Any suggestions, ideas? Thanks in advance, Mike -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[4.1.8] New test milestone released
A new test milestone of Tomcat 4.1 has just been released. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.8/ Significant changes over 4.1.7 Beta include: - Many Jasper 2 bugfixes - DBCP fixes The list of changes is available in the release notes. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE]: Re: cvs commit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Before I make any changes to the CVS, I'd like to know what everyone thinks. So, here are the choices: [ ] Keep it as is and send all DIR_MAGIC_TYPE requests to Tomcat [ ] Keep it as is, but only if DIR_MAGIC_TYPE can be turned on/off [ ] Remove DIR_MAGIC_TYPE handling altogether [ ] Make the change [ ] Make the change, but only if DIR_MAGIC_TYPE can be turned on/off I can live with any but the first. It would be nice to have it as a config option however. JkOptions is probably fine for 1.2. Not sure where it should be set in Jk2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11101] New: - java.lang.NullPointerException on startup.bat execution
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=11101. 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=11101 java.lang.NullPointerException on startup.bat execution Summary: java.lang.NullPointerException on startup.bat execution Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows XP Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] got the following output when starting tomcat 4.0.4 in windows/xp environment: Using CATALINA_BASE: .. Using CATALINA_HOME: .. Using CATALINA_TMPDIR: ..\temp Using JAVA_HOME: C:\Program Files\Java\j2re1.4.0_01 Starting service Tomcat-Standalone Apache Tomcat/4.0.4 java.lang.NullPointerException at java.io.File.init(Unknown Source) at org.apache.catalina.core.StandardContext.getBasePath (StandardContext.java:3659) at org.apache.catalina.core.StandardContext.setResources (StandardContext.java:1108) at org.apache.catalina.core.StandardContext.start (StandardContext.java:3316) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1123) at org.apache.catalina.core.StandardHost.start(StandardHost.java:638) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:343) at org.apache.catalina.core.StandardService.start (StandardService.java:388) at org.apache.catalina.core.StandardServer.start (StandardServer.java:506) at org.apache.catalina.startup.Catalina.start(Catalina.java:781) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Mavenizing tomcat..
Which version is maven in, right now? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[logging] [PATCH] JDK 1.4 Logging
On Tue, 2002-07-23 at 15:03, Bob Herrmann wrote:
On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
I think there is a simpler solution for this class of problems, and
that would also work with log4j and doesn't require _any_ API change.
( only changes to the adapter implementations )
Any 'wrapper' will use:
factory=LogFactory.getFactory();
factory.setAttribute( commons-logging.wrapperClass,
[CLASSNAME-OF-WRAPPER]);
factory.getLog(), etc.
Hi. This patch to commons logging allow you to specify which methods
in the call stack are uninteresting when using the JDK1.4 Logger. In
Tomcat this seems to be all methods named log and internalLog. This
is based on Costin's idea of uninteresting classes, but seems to work
better for method names (in Tomcat anyway.)
It is something of a back door. It is primarily for projects that
are in the process of converting to using commons-logging.
Is this an acceptable change to commons-logging ?
Cheers,
-bob
P.S. this patch is updated from the one posted to tomcat-dev
Index: src/java/org/apache/commons/logging/impl/Jdk14Logger.java
===
RCS file: /home/cvspublic/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk14Logger.java,v
retrieving revision 1.4
diff -u -r1.4 Jdk14Logger.java
--- src/java/org/apache/commons/logging/impl/Jdk14Logger.java 17 Jul 2002 16:42:40 - 1.4
+++ src/java/org/apache/commons/logging/impl/Jdk14Logger.java 23 Jul 2002 20:49:11 -
@@ -65,8 +65,11 @@
import java.util.logging.Level;
import java.util.logging.Logger;
+import java.util.Hashtable;
+import java.util.StringTokenizer;
import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
/**
@@ -95,6 +98,14 @@
logger = Logger.getLogger(name);
+String wrapperMethods = (String) LogFactory.getFactory().getAttribute(commons-logging.wrapperMethods);
+if ( wrapperMethods != null ){
+StringTokenizer st = new StringTokenizer(wrapperMethods,,);
+while (st.hasMoreTokens()) {
+wrapperMethodsHash.put( st.nextToken(), F );
+}
+}
+
}
@@ -106,6 +117,11 @@
*/
protected Logger logger = null;
+/**
+ * The methods that we ignore in the stack trace
+ */
+private Hashtable wrapperMethodsHash = new Hashtable();
+
// - Public Methods
@@ -116,10 +132,17 @@
// Caller will be the third element
String cname=unknown;
String method=unknown;
-if( locations!=null locations.length 2 ) {
-StackTraceElement caller=locations[2];
-cname=caller.getClassName();
-method=caller.getMethodName();
+if( locations!=null locations.length2 ) {
+StackTraceElement caller=null;
+for (int stackLevel=2;stackLevellocations.length;stackLevel++){
+caller = locations[stackLevel];
+cname = caller.getClassName();
+method = caller.getMethodName();
+if ( wrapperMethodsHash.get( method ) == null ){
+break;
+}
+
+}
}
if( ex==null ) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Better support for stack walking
Hi. This patch to commons logging allow you to specify which methods
in the call stack are uninteresting when using the JDK1.4 Logger. In
Tomcat this seems to be all methods named log and internalLog. This
is based on Costin's idea of uninteresting classes, but seems to work
better for method names (in Tomcat anyway.)
It is something of a back door. It is primarily for projects that
are in the process of converting to using commons-logging.
You use it like this,
LogFactory.getFactory().setAttribute(
commons-logging.wrapperMethods,
log,internalLog );
Log log = LogFactory.getLog( Logger'sName );
log.info(Hello World);
Is this an acceptable change to commons-logging ?
Cheers,
-bob
P.S. this patch is updated from the one posted to tomcat-dev
On Tue, 2002-07-23 at 15:03, Bob Herrmann wrote:
On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
I think there is a simpler solution for this class of problems, and
that would also work with log4j and doesn't require _any_ API
change.
( only changes to the adapter implementations )
Any 'wrapper' will use:
factory=LogFactory.getFactory();
factory.setAttribute( commons-logging.wrapperClass,
[CLASSNAME-OF-WRAPPER]);
factory.getLog(), etc.
On Tue, 2002-07-23 at 15:46, [EMAIL PROTECTED] wrote:
1. For Log4J at least, the wrapper class is 'given' to the logger
implementation via a constructor argument.
No, it is passed on each call. Log4j is the easiest, it has all the
support we need.
1.a. Log.setLogWrapper/setAttribute isn't enough. Putting aside
design/style arguments, it's to late. Granted this COULD be worked around
The only reason for setAttribute on Log is that if we set the
wrapper on the factory, this will be 'global'. In tomcat we have
2-3 wrappers that are used - and if each will use commons-logging
we'll need to do some tricks.
2. In an environment where we have multiple components using
commons-logging, some may wrap - others may not. A Factory.setAttribute
is dangerous here (it's potentially 'global' across multiple components).
Note also the the attributes are (pre-)loaded out of a properties file.
I agree.
3. We need an analogous method (setWrapper or setAttribute) for the
Discovery mechanism. A requirement for 'setWrapper' would seem to be
fairly specific to logging, it doesn't appear to be generally useful in a
'discovery' tool.
I don't think so - this is very specific to logging, it has
nothing to do with discovery.
(2) is a strong vote for 'LogFactory.getInstance(Class wrapper,
[String|Class] cat)', in addition to the current 'getInstance' methods -
and a vote against a 'setAttribute' in a singleton (global) Factory.
I think setAttribute on Log would solve (2).
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Index: src/java/org/apache/commons/logging/impl/Jdk14Logger.java
===
RCS file: /home/cvspublic/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk14Logger.java,v
retrieving revision 1.4
diff -u -r1.4 Jdk14Logger.java
--- src/java/org/apache/commons/logging/impl/Jdk14Logger.java 17 Jul 2002 16:42:40 - 1.4
+++ src/java/org/apache/commons/logging/impl/Jdk14Logger.java 23 Jul 2002 20:49:11 -
@@ -65,8 +65,11 @@
import java.util.logging.Level;
import java.util.logging.Logger;
+import java.util.Hashtable;
+import java.util.StringTokenizer;
import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
/**
@@ -95,6 +98,14 @@
logger = Logger.getLogger(name);
+String wrapperMethods = (String) LogFactory.getFactory().getAttribute(commons-logging.wrapperMethods);
+if ( wrapperMethods != null ){
+StringTokenizer st = new StringTokenizer(wrapperMethods,,);
+while (st.hasMoreTokens()) {
+wrapperMethodsHash.put( st.nextToken(), F );
+}
+}
+
}
@@ -106,6 +117,11 @@
*/
protected Logger logger = null;
+/**
+ * The methods that we ignore in the stack trace
+ */
+private Hashtable wrapperMethodsHash = new Hashtable();
+
// - Public Methods
@@ -116,10 +132,17 @@
// Caller will be the third element
String cname=unknown;
String method=unknown;
-if( locations!=null locations.length 2 ) {
-StackTraceElement caller=locations[2];
-cname=caller.getClassName();
-method=caller.getMethodName();
+if( locations!=null locations.length2 ) {
+StackTraceElement caller=null;
+for (int stackLevel=2;stackLevellocations.length;stackLevel++){
+caller
RE: Mavenizing tomcat..
Almost Beta 5. It just has undergone a major refactor from b4 and has really progressed in the mean time. Currently commons is completely mavenezied to get rid of the bugs that may be around and probably to solve shortcomings still found before b5 is released. Mvgr, Martin On Tue, 2002-07-23 at 22:53, Ignacio J. Ortega wrote: Which version is maven in, right now? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE]: Re: cvs commit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
On Tue, 2002-07-23 at 23:39, Henri Gomez wrote: Before I make any changes to the CVS, I'd like to know what everyone thinks. So, here are the choices: [ ] Keep it as is and send all DIR_MAGIC_TYPE requests to Tomcat [ ] Keep it as is, but only if DIR_MAGIC_TYPE can be turned on/off [ ] Remove DIR_MAGIC_TYPE handling altogether [ ] Make the change [ ] Make the change, but only if DIR_MAGIC_TYPE can be turned on/off For someone who have all its tomcat behind a webserver, I'll be to have the requests sent to Tomcat since my web servers won't have a directory created for all the webapps available on tomcats farms behind. If you don't have the directories that Apache can see, then this latest change would still work for you (i.e. anything that is not an explicit index page like index.jsp or a directory goes to Tomcat). So, I'm guessing this would be a vote for 'Make the change'. Alternativly I don't want to receive index.php or index.pl in Tomcat, and so want only the one which match with JkMount (in mod_jk 1.2 way), ie JkMount *.jsp ajp13. That would be handled by Apache anyway through the usual DirectoryIndex machinery, so no problems there. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11105] New: - Get Http10: Parse error, empty line error while parsing headers
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=11105. 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=11105 Get Http10: Parse error, empty line error while parsing headers Summary: Get Http10: Parse error, empty line error while parsing headers Product: Tomcat 3 Version: 3.3.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] While my application is parsing headers (cookie values), it displays this error several times, marking it even for one same cookie in overlapping strings. For example: Http10: Parse error, empty line: ts%3D0%26locale%3D%26; bSetTemp=mstrSmgr%3D %255B%255B%2B%255D%2 Http10: Parse error, empty line: %26locale%3D%26; bSetTemp=mstrSmgr%3D%255B% 255B%2B%255D%252C%255Bts-7 Http10: Parse error, empty line: 3D0%26locale%3D%26; bSetTemp=mstrSmgr%3D%25 5B%255B%2B%255D%252C%25 Http10: Parse error, empty line: 6locale%3D%26; bSetTemp=mstrSmgr%3D%255B%25 5B%2B%255D%252C%255Bts-72x-p I already checked the value of the cookies and they don't have change of lines in their values - they are URL encoded, but that's it... Is it a known issue? It does not seem to happen for other versions of Tomcat (tested also for 3.2.1 and 4) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE]: Re: cvscommit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
On Wed, 2002-07-24 at 06:47, Bill Barker wrote: Before I make any changes to the CVS, I'd like to know what everyone thinks. So, here are the choices: [ ] Keep it as is and send all DIR_MAGIC_TYPE requests to Tomcat [ ] Keep it as is, but only if DIR_MAGIC_TYPE can be turned on/off [ ] Remove DIR_MAGIC_TYPE handling altogether [ ] Make the change [ ] Make the change, but only if DIR_MAGIC_TYPE can be turned on/off I can live with any but the first. It would be nice to have it as a config option however. JkOptions is probably fine for 1.2. Not sure where it should be set in Jk2. Thanks. I'm not sure about mod_jk2 either. The latest reports show that the code still doesn't work. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Better support for stack walking
1. For Log4J at least, the wrapper class is 'given' to the logger implementation via a constructor argument. No, it is passed on each call. Log4j is the easiest, it has all the support we need. 1.a. Log.setLogWrapper/setAttribute isn't enough. Putting aside design/style arguments, it's to late. Granted this COULD be worked around The only reason for setAttribute on Log is that if we set the wrapper on the factory, this will be 'global'. In tomcat we have 2-3 wrappers that are used - and if each will use commons-logging we'll need to do some tricks. 2. In an environment where we have multiple components using commons-logging, some may wrap - others may not. A Factory.setAttribute is dangerous here (it's potentially 'global' across multiple components). Note also the the attributes are (pre-)loaded out of a properties file. I agree. 3. We need an analogous method (setWrapper or setAttribute) for the Discovery mechanism. A requirement for 'setWrapper' would seem to be fairly specific to logging, it doesn't appear to be generally useful in a 'discovery' tool. I don't think so - this is very specific to logging, it has nothing to do with discovery. (2) is a strong vote for 'LogFactory.getInstance(Class wrapper, [String|Class] cat)', in addition to the current 'getInstance' methods - and a vote against a 'setAttribute' in a singleton (global) Factory. I think setAttribute on Log would solve (2). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11045] - Jikes compiler output appears in catalina.out not browser
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=11045. 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=11045 Jikes compiler output appears in catalina.out not browser --- Additional Comments From [EMAIL PROTECTED] 2002-07-24 00:20 --- If that is the case then perhaps support for external java compilers should be deprecated and that fact listed in the changes doc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
bojan 2002/07/23 17:44:20
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Kick out DIR_MAGIC_TYPE from jk2_handler() since it is never given to it
anyway. This will have to be resolved later for mod_jk2.
Make sure main request gets the appropriate info when the sub-request is
made from mod_dir. This makes DirectoryIndex work (finally :-) for mod_jk2.
Revision ChangesPath
1.46 +15 -17jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- mod_jk2.c 22 Jul 2002 23:18:38 - 1.45
+++ mod_jk2.c 24 Jul 2002 00:44:20 - 1.46
@@ -532,13 +532,8 @@
uriEnv=ap_get_module_config( r-request_config, jk2_module );
-/* We do DIR_MAGIC_TYPE here to make sure TC gets all requests, even
- * if they are directory requests, in case there are no static files
- * visible to Apache and/or DirectoryIndex was not used */
-
/* not for me, try next handler */
-if((uriEnv==NULL || strcmp(r-handler,JK_HANDLER))
- strcmp(r-handler,DIR_MAGIC_TYPE))
+if(uriEnv==NULL || strcmp(r-handler,JK_HANDLER))
return DECLINED;
/* If this is a proxy request, we'll notify an error */
@@ -546,17 +541,6 @@
return HTTP_INTERNAL_SERVER_ERROR;
}
-/* This is needed for DIR_MAGIC_TYPE. Not sure if this is good, bad or just
- * plain ugly, but we really NEED to have uriEnv, otherwise everything else
- * will blow up */
-
-if(uriEnv == NULL){
-uriEnv = ap_get_module_config(r-server-module_config, jk2_module);
-
-if(uriEnv == NULL) /* We still have nothing, go out */
- return DECLINED;
-}
-
workerEnv = uriEnv-workerEnv;
/* Get an env instance */
@@ -678,6 +662,13 @@
ap_set_module_config( r-request_config, jk2_module, uriEnv );
r-handler=JK_HANDLER;
workerEnv-globalEnv-releaseEnv( workerEnv-globalEnv, env );
+
+/* This could be a sub-request, possibly from mod_dir */
+if(r-main){
+ap_set_module_config( r-main-request_config, jk2_module, uriEnv );
+r-main-handler=JK_HANDLER;
+}
+
return OK;
}
@@ -707,12 +698,19 @@
ap_set_module_config( r-request_config, jk2_module, uriEnv );
r-handler=JK_HANDLER;
+/* This could be a sub-request, possibly from mod_dir */
+if(r-main){
+ap_set_module_config( r-main-request_config, jk2_module, uriEnv );
+r-main-handler=JK_HANDLER;
+}
+
if( uriEnv-mbean-debug 0 )
env-l-jkLog(env, env-l, JK_LOG_DEBUG,
mod_jk.translate(): uriMap %s %s %#lx\n,
r-uri, uriEnv-workerName, uriEnv-worker);
workerEnv-globalEnv-releaseEnv( workerEnv-globalEnv, env );
+
return OK;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11086] - Null pointer exception in JasperLoader.loadClass(String, boolean)
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=11086. 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=11086 Null pointer exception in JasperLoader.loadClass(String, boolean) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-07-24 00:46 --- Please see bug report 7052 for a discussion of this bug. Bottom line, you need to configure Tomcat to use the SecurityManager with support for RMI. Applications hosted within Tomcat should not be setting the SecurityManager. *** This bug has been marked as a duplicate of 7052 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7052] - Security manager not initialised or accessed properly
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=7052. 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=7052 Security manager not initialised or accessed properly [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-07-24 00:47 --- *** Bug 11086 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10789] - Setting DirectoryIndex of index.jsp does not get served by jk2
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=10789. 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=10789 Setting DirectoryIndex of index.jsp does not get served by jk2 --- Additional Comments From [EMAIL PROTECTED] 2002-07-24 00:48 --- Mark, I've just commited the version that I actually tested, so it should work :-) DirectoryIndex will work if the physical file is present. DIR_MAGIC_TYPE is not used any more in mod_jk2 since no requests are made to it with handler set to that value. I cannot say why at this point, but this part really behaves in a totally different way than mod_jk 1.2.0. Let me know what your findings are. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11112] New: - Tomcat not aware of Implicit Map entries from TLDs
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=2. 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=2 Tomcat not aware of Implicit Map entries from TLDs Summary: Tomcat not aware of Implicit Map entries from TLDs Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to JSP1.2 spec JPS.7.3.4, it says : Each TLD file is examined. If it has a uri element, then a new taglib element is created, with a taglib-uri subelement whose value is that of the uri element, and with a taglib-location subelement that refers to the TLD file. But if tld has uri, and that tld is not in a web.xml, if jsp has taglib directive with uri which is same as tld's uri value, Jasper raises the exception that : at org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:214) at org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:174) at org.apache.jasper.compiler.JspParseEventListener.processTaglibDirective(JspParse EventListener.java:1162) at org.apache.jasper.compiler.JspParseEventListener.handleDirective(JspParseEventLi stener.java:758) at org.apache.jasper.compiler.DelegatingListener.handleDirective(DelegatingListener .java:121) at org.apache.jasper.compiler.Parser$Directive.accept(Parser.java:255) at org.apache.jasper.compiler.Parser.parse(Parser.java:1145) at org.apache.jasper.compiler.Parser.parse(Parser.java:1103) at org.apache.jasper.compiler.Parser.parse(Parser.java:1099) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:213) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:210) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_global.h
bojan 2002/07/23 19:36:36 Modified:jk/native/common jk_global.h Log: New JkOption: ForwardDirectories. If used, all unresolved directory requests will be handled by Tomcat. By default, this option will be turned off. Revision ChangesPath 1.19 +3 -1 jakarta-tomcat-connectors/jk/native/common/jk_global.h Index: jk_global.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_global.h,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- jk_global.h 21 Jun 2002 15:28:56 - 1.18 +++ jk_global.h 24 Jul 2002 02:36:36 - 1.19 @@ -165,6 +165,8 @@ #define JK_OPT_FWDKEYSIZE 0x0004 +#define JK_OPT_FWDDIRS 0x0008 + /* Check for EBCDIC systems */ /* Check for Apache 2.0 running on an EBCDIC system */ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
bojan 2002/07/23 19:38:32
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Refine directory handling a bit more. Make use of the new JkOption,
ForwardDirectories. When enabled, all unresolved directory requests go
to Tomcat. This option is disabled by default.
Revision ChangesPath
1.53 +21 -6 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- mod_jk.c 22 Jul 2002 21:03:19 - 1.52
+++ mod_jk.c 24 Jul 2002 02:38:32 - 1.53
@@ -959,7 +959,8 @@
* -ForwardSSLKeySize= Don't Forward SSL Key Size, will make mod_jk works
with all TC release
* ForwardURICompat = Forward URI normally, less spec compliant but
mod_rewrite compatible (old TC)
* ForwardURICompatUnparsed = Forward URI as unparsed, spec compliant but broke
mod_rewrite (old TC)
- * ForwardURIEscaped = Forward URI escaped and Tomcat (3.3 rc2) stuff will
do the decoding part
+ * ForwardURIEscaped= Forward URI escaped and Tomcat (3.3 rc2) stuff will
do the decoding part
+ * ForwardDirectories = Forward all directory requests with no index files
to Tomcat
*/
const char *jk_set_options(cmd_parms *cmd,
@@ -1000,6 +1001,9 @@
opt = JK_OPT_FWDURIESCAPED;
mask = JK_OPT_FWDURIMASK;
}
+else if (!strcasecmp(w, ForwardDirectories)) {
+opt = JK_OPT_FWDDIRS;
+}
else
return ap_pstrcat(cmd-pool, JkOptions: Illegal option ', w, ',
NULL);
@@ -1183,20 +1187,26 @@
/* We do DIR_MAGIC_TYPE here to make sure TC gets all requests, even
* if they are directory requests, in case there are no static files
- * visible to Apache and/or DirectoryIndex was not used */
+ * visible to Apache and/or DirectoryIndex was not used. This is only
+ * used when JkOptions has ForwardDirectories set. */
-/* not for me, try next handler */
+/* Not for me, try next handler */
if(strcmp(r-handler,JK_HANDLER) strcmp(r-handler,DIR_MAGIC_TYPE))
- return DECLINED;
+return DECLINED;
xconf = (jk_server_conf_t *)ap_get_module_config(r-server-module_config,
jk_module);
+
+/* Was the option to forward directories to Tomcat set? */
+if(!strcmp(r-handler,DIR_MAGIC_TYPE) !(xconf-options JK_OPT_FWDDIRS))
+return DECLINED;
+
worker_name = apr_table_get(r-notes, JK_WORKER_ID);
xl = xconf-log ? xconf-log : main_log;
/* Set up r-read_chunked flags for chunked encoding, if present */
if(rc = ap_setup_client_block(r, REQUEST_CHUNKED_DECHUNK)) {
-return rc;
+return rc;
}
if( worker_name == NULL ) {
@@ -1610,6 +1620,11 @@
if(worker) {
r-handler=apr_pstrdup(r-pool,JK_HANDLER);
apr_table_setn(r-notes, JK_WORKER_ID, worker);
+
+/* This could be a sub-request, possibly from mod_dir */
+if(r-main)
+apr_table_setn(r-main-notes, JK_WORKER_ID, worker);
+
return OK;
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
bojan 2002/07/23 21:48:52 Modified:jk/native/apache-2.0 mod_jk.c Log: Save a strcmp() call. Revision ChangesPath 1.54 +3 -3 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c Index: mod_jk.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v retrieving revision 1.53 retrieving revision 1.54 diff -u -r1.53 -r1.54 --- mod_jk.c 24 Jul 2002 02:38:32 - 1.53 +++ mod_jk.c 24 Jul 2002 04:48:52 - 1.54 @@ -1183,7 +1183,7 @@ jk_server_conf_t *xconf; jk_logger_t *xl; jk_server_conf_t *conf; -int rc; +int rc,dmt=1; /* We do DIR_MAGIC_TYPE here to make sure TC gets all requests, even * if they are directory requests, in case there are no static files @@ -1191,14 +1191,14 @@ * used when JkOptions has ForwardDirectories set. */ /* Not for me, try next handler */ -if(strcmp(r-handler,JK_HANDLER) strcmp(r-handler,DIR_MAGIC_TYPE)) +if(strcmp(r-handler,JK_HANDLER) (dmt=strcmp(r-handler,DIR_MAGIC_TYPE))) return DECLINED; xconf = (jk_server_conf_t *)ap_get_module_config(r-server-module_config, jk_module); /* Was the option to forward directories to Tomcat set? */ -if(!strcmp(r-handler,DIR_MAGIC_TYPE) !(xconf-options JK_OPT_FWDDIRS)) +if(!dmt !(xconf-options JK_OPT_FWDDIRS)) return DECLINED; worker_name = apr_table_get(r-notes, JK_WORKER_ID); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
Since it seems like people have totally different needs in regards to static files and redirection of 'ambiguous' directory requests to Tomcat, I went with the option ForwardDirectories, which can be specified in JkOptions. It is off by default. When turned off, any directory that doesn't contain any of the files specified in DirectoryIndex will be handled by Apache, by whichever module does automatic directory indexing (normally mod_autoindex). When turned on, such requests will be forwarded to Tomcat for resolution. This then gives Tomcat the opportunity to do its magic and serve whatever it pleases, including the contents of the directory, similar to mod_autoindex, or whatever else. This, of course, is only applicable to mod_jk 1.2.0. mod_jk2 still transfers all such requests to Tomcat, I believe. I'll have to learn a great deal more about it in order to apply something like the above to it. Bojan On Wed, 2002-07-24 at 14:48, [EMAIL PROTECTED] wrote: bojan 2002/07/23 21:48:52 Modified:jk/native/apache-2.0 mod_jk.c -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connectors on MacOS X
Tobias Wunden [EMAIL PROTECTED] wrote: 3) Provide Information on dlopen Build on top of APR and that problem goes away. That's why APR is the way to go, right? Pier -- I love introducing bug: Floating Point Exception this is Access Violation, Access Violation, this is Floating Point Exception. Eric Prud'Hommeaux -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
