Re: tomcat crashes
Quoting Taral Shah [EMAIL PROTECTED]: Try a different JDK. This doesn't look a Tomcat problem. Bojan Hi I am facing strange problem at one of my customers side. I am using tomcat 3.3 for my devlopment and its working fine. But at one of customers side tomcat crases unknowingly. It even does not compile a simple jsp. The os at the client side is solaris, WHen tomcat starts and a simple jsp(containg just 2 html tags like html and title) is run it throws following error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 10 occurred at PC=0x10a1fc Function name=(N/A) Library=(N/A) - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Spec question: RE BUG 12052
Quoting [EMAIL PROTECTED]: So: getServerPort() should return the same as the CGI variable SERVER_PORT ( which returns the server port, not the host header ! ), meaning the value of the part after : in the Host header. I didn't know that the servlet spec can define new meanings for the CGI spec. Pretty cool, ha? :-)) Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat crashes
But same thing works with different solaris. Here I have solaris 5.7 and with 5.8 it works fine, even in one of 5.7 solaris machine tomcat runs fine. I checked with memory and space, initially it showed that it had occupied 99% of disk space, so i moved whole code to another partition and there only 50% space is used. Still its giving me same problem. Any other solution, Or if i change JDK then which jdk should i go, as I need jdk 1.3 and here i am using same, do u suggest me to go with jdk1.4? Thanks Taral Shah - Original Message - From: Bojan Smojver [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; Taral Shah [EMAIL PROTECTED] Sent: Thursday, August 29, 2002 12:13 PM Subject: Re: tomcat crashes Quoting Taral Shah [EMAIL PROTECTED]: Try a different JDK. This doesn't look a Tomcat problem. Bojan Hi I am facing strange problem at one of my customers side. I am using tomcat 3.3 for my devlopment and its working fine. But at one of customers side tomcat crases unknowingly. It even does not compile a simple jsp. The os at the client side is solaris, WHen tomcat starts and a simple jsp(containg just 2 html tags like html and title) is run it throws following error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 10 occurred at PC=0x10a1fc Function name=(N/A) Library=(N/A) - This mail sent through IMP: http://horde.org/imp/ -- 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: tomcat crashes
One more thing - check if the OS has all the relevant patches. Sometimes it's the libraries that JDK's using. Bojan Quoting Bojan Smojver [EMAIL PROTECTED]: Quoting Taral Shah [EMAIL PROTECTED]: Try a different JDK. This doesn't look a Tomcat problem. Bojan Hi I am facing strange problem at one of my customers side. I am using tomcat 3.3 for my devlopment and its working fine. But at one of customers side tomcat crases unknowingly. It even does not compile a simple jsp. The os at the client side is solaris, WHen tomcat starts and a simple jsp(containg just 2 html tags like html and title) is run it throws following error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 10 occurred at PC=0x10a1fc Function name=(N/A) Library=(N/A) - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12113] - Log4J ConsoleAppender System.out.println do not display on console
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=12113. 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=12113 Log4J ConsoleAppender System.out.println do not display on console --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 06:52 --- I think making it configurable is a great solution, especially for developers using IDEs with small monitors. Thank you for taking the time to add this. Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat crashes
Quoting Taral Shah [EMAIL PROTECTED]: But same thing works with different solaris. Here I have solaris 5.7 and with 5.8 it works fine, even in one of 5.7 solaris machine tomcat runs fine. And they all have the same patches applied? I don't use Solaris, so I can't tell you specifically what to do or patch, but the errors indicate a VM problem (or something outside affecting the VM). Even if you feed VM total garbage, it shouldn't crash. That's the theory, at least. I checked with memory and space, initially it showed that it had occupied 99% of disk space, so i moved whole code to another partition and there only 50% space is used. Still its giving me same problem. I never had such crowded partitions, so I can tell if that might affect the VM. Any other solution, Or if i change JDK then which jdk should i go, as I need jdk 1.3 and here i am using same, do u suggest me to go with jdk1.4? I think there is a 1.3.1_04 available for Solaris. If you're aren't familiar with 1.4 (like I'm not), I think it's better to stick with the same minor version, unless, of course, that doesn't fix it. And given the error message (An unexpected exception has been detected in native code outside the VM), I would investigate the patch status of the machine quite seriously. Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Spec question: RE BUG 12052
- Original Message -
From: [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, August 28, 2002 7:12 PM
Subject: Re: Spec question: RE BUG 12052
On Wed, 28 Aug 2002, Bill Barker wrote:
I think the decision to use the Host header is right, but
I agree that it violates the wording in the servlet spec.
The SERVER_PORT and the port in the Host: header are different
beasts - in most use cases I've seen the user is interested
in the second.
Not anymore. ;-) In the current 2.4 spec draft it is required to be
taken
from the Host header.
I hope this is listed in the 'incompatible changes between 2.3 and 2.4'
:-)
Nope.
spec-quote version=2.4 section=S.1
Clarification of SERVER_NAME and SERVER_PORT in getServerName()
and getServerPort() (14.2.16)
/spec-quote
As for the new wording - am I missing the ':-)' ?
Here's mine :-)
So: getServerPort() should return the same as the CGI variable SERVER_PORT
( which returns the server port, not the host header ! ), meaning the
value of the part after : in the Host header.
I didn't know that the servlet spec can define new meanings for the
CGI spec.
FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
here. If I actually thought that any members of the JCP were subscribed to
this list, I'd think to ask for clarification before 2.4 went final. :)
Costin
spec-quote version=2.4 section=14.2.16
getServerName()
public java.lang.String getServerName()
Returns the host name of the server to which the request was sent. For
HTTP
servlets, same as the value of the CGI variable SERVER_NAME, meaning the
value of the part before : in the Host header, if any, or the resolved
server
name, or the server IP address.
Returns: a String containing the name of the server
getServerPort()
public int getServerPort()
Returns the port number to which the request was sent. For HTTP
servlets,
same as the value of the CGI variable SERVER_PORT, meaning the value of
the
part after : in the Host header, if any, or the server port where the
client
connection was accepted on.
Returns: an integer specifying the port number
/spec-quote
Note that a load balancer or proxy is required ( AFAIK ) to insert
Host: headers if none is present.
Costin
On 29 Aug 2002, Bojan Smojver wrote:
On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
The question in 12052 is whether Apache should use the socket port
(as
it
does now), or the port in the Host header. When this came up with
the
Coyote/Http11 connector, the decision was that the Host header was
the
correct one. I'd have to say that the bug is valid.
This is what the API (2.2) docs say about the getServerPort():
Returns the port number on which this request was received. For HTTP
servlets, same as the value of the CGI variable SERVER_PORT.
This in itself could be contradicting, but I think that in the case
of
Apache it is pretty straightforward.
This is what Apache 2.0 does to populate the variable SERVER_PORT:
apr_table_addn(e, SERVER_PORT,
apr_psprintf(r-pool, %u,
ap_get_server_port(r)));
And this is the ap_get_server_port():
AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
{
apr_port_t port;
core_dir_config *d =
(core_dir_config *)ap_get_module_config(r-per_dir_config,
core_module);
if (d-use_canonical_name == USE_CANONICAL_NAME_OFF
|| d-use_canonical_name == USE_CANONICAL_NAME_DNS) {
/* With UseCanonicalName off Apache will form
self-referential
* URLs using the hostname and port supplied by the client
if
* any are supplied (otherwise it will use the canonical
name).
*/
port = r-parsed_uri.port ? r-parsed_uri.port :
r-server-port ? r-server-port :
ap_default_port(r);
}
else { /* d-use_canonical_name == USE_CANONICAL_NAME_ON */
/* With UseCanonicalName on (and in all versions prior to
1.3)
* Apache will use the hostname and port specified in the
* ServerName directive to construct a canonical name for
the
* server. (If no port was specified in the ServerName
* directive, Apache uses the port supplied by the client if
* any is supplied, and finally the default port for the
protocol
* used.
*/
port = r-server-port ? r-server-port :
r-connection-local_addr-port ?
r-connection-local_addr-port
ap_default_port(r);
}
/* default */
return port;
}
This doesn't seem like coming from
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
[EMAIL PROTECTED] wrote: On Wed, 28 Aug 2002, jean-frederic clere wrote: Are you ok with a change for daemon to use introspection, and remove the dependency from tomcat to daemon plus consolidate all startups ? Sure ;-) Ok, then let me push a bit more: are you ok with merging the C code from daemon into jk2, and continuing the development on the C side in j-t-c/jk/native2 ? I am +1 for merging the code but in daemon. I am using the daemon code for projects not related with mod_jk and I would perfer to have it independant from mod_jk. An other point to be against moving it in mod_jk is that the code has been moved recently in commons (sandbox) I do not thing that it is a good idea to move it back in the Tomcat repos. Also if we move it from daemon to mod_jk we have to ask it to the common dev list before moving it. There is no point on having 2 codebases that launch the VM from C, or 2 service launchers. And there is a lot to benefits from both sides - I think. That should happen after jk2.0 is released ( eventually we can branch when 4.1 is released - and use the main branch ). ( one nice benefit may be getting back the ability to start and control the java process from apache, like jserv did ). That is a feature I need. I'm only talking about the C code here. Costin -- 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: tomcat crashes
- Original Message - From: Bojan Smojver [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, August 28, 2002 11:50 PM Subject: Re: tomcat crashes One more thing - check if the OS has all the relevant patches. Sometimes it's the libraries that JDK's using. This is **especially** true of Solaris. In my experience, almost all Solaris JVM crashes are due to un-patched kernels. Bojan Quoting Bojan Smojver [EMAIL PROTECTED]: Quoting Taral Shah [EMAIL PROTECTED]: Try a different JDK. This doesn't look a Tomcat problem. Bojan Hi I am facing strange problem at one of my customers side. I am using tomcat 3.3 for my devlopment and its working fine. But at one of customers side tomcat crases unknowingly. It even does not compile a simple jsp. The os at the client side is solaris, WHen tomcat starts and a simple jsp(containg just 2 html tags like html and title) is run it throws following error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 10 occurred at PC=0x10a1fc Function name=(N/A) Library=(N/A) - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - This mail sent through IMP: http://horde.org/imp/ -- 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: JSP include after redirect. Spec. or bug?
Well, it's a bug, but it is in the application programmer's code. There should be a: return; after the 'response.sendRedirect(b.jsp)' line. - Original Message - From: Hugh J. L. [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, August 28, 2002 11:12 PM Subject: JSP include after redirect. Spec. or bug? Hi, % response.sendRedirect(b.jsp); String left_page=c.jsp; % jsp:include page=%=left_page% flush=true / Running on Tomcat 4, it is ok. Running on Tomcat 3.3, the result is correct but there is error message on console. Of course, the include in this example is meaningless, but this jsp is extracted from large jsp file from client. Is it a limitation of JSP 1.1 or a trivial bug? Thanks. Hugh __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- 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: HTTP Host Request header and TC Connectors]
Bill Barker wrote: - Original Message - From: Ryan Lubke [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, August 28, 2002 4:00 PM Subject: Re: HTTP Host Request header and TC Connectors] On Wed, 2002-08-28 at 17:32, Bill Barker wrote: - Original Message - From: Ryan Lubke [EMAIL PROTECTED] To: tcdev [EMAIL PROTECTED] Sent: Wednesday, August 28, 2002 9:43 AM Subject: [Fwd: HTTP Host Request header and TC Connectors] By the way the quote was pulled from section 14.23 of RFC 2616. = Hi, Looking for a little input from the HTTP gurus here. Given the following: If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. So, I'm looking for other interpretations of what the above means. My interpretation at this point is the serviced targeted by the request URI is identified via an IP address vs a host name, that the Host request header will be sent but with an empty value. Does anyone agree/disagree? The reason I ask is that if an empty Host header is sent to Tomcat, and a redirect is sent back, the value of the Location header is useless, i.e. http:///index.jsp. My reading of 14.23 says that this is exactly what should happen, since the only (valid) way that this could happen is if the user originally requested http:///. Since the client was capable of resolving that request, it should be able to resolve the value of the Location header. Actually, the client doesn't request http:///. Example below. Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. GET / HTTP/1.1 Host: HTTP/1.1 302 Moved Temporarily Content-Type: text/html Date: Wed, 28 Aug 2002 23:01:29 GMT Transfer-Encoding: chunked Location: http:///index.html Server: Apache Tomcat/4.0.4 (HTTP/1.1 Connector) Perhaps I missed your point. My point is that unless you typed http:/// into the URL box of your browser, then your client is broken if it sent an empty Host header. The RFC requires that the content of the Host header is the part of the URL after the // and before the next / (aka the authority). The above request is invalid and should be handled as invalid. TC should not send a redirect in the case. I'm trying to determine if this is a problem with the client implementation's interpretation of the spec, or a problem with Tomcat. Thanks, -rl -- 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] -- 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] -- 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]
DO NOT REPLY [Bug 12098] - Session manager and context class loader
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=12098. 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=12098 Session manager and context class loader --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 08:01 --- The correct one is WebappClassLoader, though. StandardCL means that the internal Catalina CL is set as the context CL, which is not good. I think it should be fixed in Tomcat 4.0.4. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
[EMAIL PROTECTED] wrote: On Wed, 28 Aug 2002, jean-frederic clere wrote: Are you ok with a change for daemon to use introspection, and remove the dependency from tomcat to daemon plus consolidate all startups ? Sure ;-) Ok, then let me push a bit more: are you ok with merging the C code from daemon into jk2, and continuing the development on the C side in j-t-c/jk/native2 ? There is no point on having 2 codebases that launch the VM from C, or 2 service launchers. And there is a lot to benefits from both sides - I think. That should happen after jk2.0 is released ( eventually we can branch when 4.1 is released - and use the main branch ). ( one nice benefit may be getting back the ability to start and control the java process from apache, like jserv did ). I'm only talking about the C code here. +1 from me. If we do that, that would mean commons-daemon is not going anywhere: - the interfaces will go away - the launcher code is supposed to end up in Ant If the launcher doesn't end up in Ant, then IMO we should create commons-launcher. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12140] - Administration webapp does not start - cant load struts.jar
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=12140. 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=12140 Administration webapp does not start - cant load struts.jar [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 08:11 --- The JVM temp directory must exist for Tomcat to behave properly. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Fwd: 0.9.0 release]
Hi, That is a good news for the native projects in Tomcat that use it, it is not it? Cheers Jean-frederic ---BeginMessage--- I've uploaded a site structure to http://www.apache.org/dist/apr/ and also uploaded some 0.9.0 source tarballs/zipballs. (signed, blah blah) Since this is our first formalized release, could somebody at least take a look around and make any tweaks or suggestions? Before putting an announcement at Freshmeat or [EMAIL PROTECTED] or whatever, it would be nice to at least get some validation of our release management setup. IOW, it looks fine to me, but I don't trust it yet :-) And, of course, anybody on *this* list is free to start trying out the newly released tarballs :-) btw, the release.sh script seems fine, although there is till a need for a doc around that. Cheers, -g -- Greg Stein, http://www.lyra.org/ ---End Message--- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/doc/images - New directory
hgomez 2002/08/29 01:33:43 jakarta-tomcat-connectors/jk/doc/images - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreStandardContext.java
Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: Capturing of stdout/stderr has been enabled in Tomcat 4.1 for 2-3 months now. I don't think it was, as RequestBase is deprecated, and is not used anymore (except in the old connectors). What I committed was a bug fix. If you revert it, capturing stderr/stdout code will still exist, you would just put back in place a memory leak. Ok. There is another place where you will need to implement your SwallowOutput flag, in StandardWrapper.java. It captures output from a load on startup servlet. I don't have many problems with capturing during servlet init. It makes more sense to me to capture that data (no rational explanation, just a feeling). It's not done during shutdown, BTW. I can add that. :-) I can also make that optional using the same flag. The thread sync issue is a good point, but this can be improved by changing the SystemLogHandler to use Thread Local variables. Thread local is quite slow, from what I saw with OptimizeIt, so I don't want to use it. From reading the section on Thread Local Performance here: http://www-106.ibm.com/developerworks/java/library/j-threads3.html#h15292 Thread local performance differs based on the JVM. 1.2 - poor 1.3 - better than normal sync _if_ you have alot of thread contention. In production where performance is an issue Tomcat can spawn alot of threads, so Thread Local could be of benefit. 1.4 - much faster than normal sync Based on this, for the long run, I think its better to switch to Thread Local. Thanks for the information :) In the long run it may be better to add support for CaptureLog to the base class for a Processor so that the thread sync issues can be avoided altogether. So I'll add support for log capture on shutdown (I think it's as useful to have it as on startup). My personal preference is to leave the capture switched off by default for the critical path, as it would confuse developers (IMO). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/doc/images banner.gif tomcat.gif tomcat.ico
hgomez 2002/08/29 01:34:38 Added: jk/doc/images banner.gif tomcat.gif tomcat.ico Log: Added images Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/doc/images/banner.gif Binary file 1.1 jakarta-tomcat-connectors/jk/doc/images/tomcat.gif Binary file 1.1 jakarta-tomcat-connectors/jk/doc/images/tomcat.ico Binary file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.10-dev] Jasper 2 problems
Jan Luehe wrote: Remy, I'm testing 4.1.10-dev before tagging, and I ran into some serious problems. Jasper 2 seems broken (in the TC 4 branch; the HEAD/TC 5 branch may be broken as well, but I didn't have time to test it), and fails to compile most pages from the admin webapp. my apologies! When backporting a fix involving several code changes from Tomcat 5 to tomcat_4_branch, I overlooked one change in Generator.java. After applying this change to Generator.java in tomcat_4_branch, the admin webapp is working fine again. Thanks Jan :) I think 4.1.10 is almost ready to go. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servletJspServletWrapper.java
Kin-Man Chung wrote: Date: Wed, 28 Aug 2002 16:41:16 -0700 (PDT) From: Craig R. McClanahan [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java To: Tomcat Developers List [EMAIL PROTECTED] On 28 Aug 2002 [EMAIL PROTECTED] wrote: - Fixed 11485: recompilation of jsp files when TLD is modified. Cool! This change (and wasn't there another recent change to auto-detect changes in files included via %@ include %?) will definitely reduce user confusion. The auto-detect of included files is already working in 4.1.x. I turned that off for tomcat 5, because it was causing problems with auto compilation of tag files. It all works now. I also turn on auto-detection of changes to files that are included with include-prelude and include-coda in jsp-config in JSP2.0, usign the same mechanism. Now if I had this one in 4.1.x ... :-) I could back port the TLD dependency check part to 4.1.x if there are demands for it. The feature is good. Could we wait until the first stable 4.1.x release to add it ? Remy -- 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/08/29 02:15:38 Modified:.RELEASE-NOTES-4.1.txt Log: - Status update. Revision ChangesPath 1.17 +6 -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.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- RELEASE-NOTES-4.1.txt 28 Aug 2002 11:53:10 - 1.16 +++ RELEASE-NOTES-4.1.txt 29 Aug 2002 09:15:38 - 1.17 @@ -392,6 +392,9 @@ [4.1.10] Documentation: Fixes and small additons to the DBCP documentation. +[4.1.10] StandardContext: + Add new swallowOutput flag, to allow configuring logger redirection. + Jasper Bug Fixes: @@ -536,6 +539,8 @@ Summary: Iteration tags do not resynchronize scripting variables after doAfterBody() +[4.1.10] #12128 + Summary: JSP Comment end symbol not recognized in some cases -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12126] - Apache 2.0.40 and mod_jk2 errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12126. 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=12126 Apache 2.0.40 and mod_jk2 errors [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Severity|Critical|Normal Component|Connector:JK/AJP|Connector:Coyote JK 2 |(deprecated)| --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 09:32 --- This messages are harmless, probably they should be lowered from errors to warnings, anyway to solve them all you need is to disvle the jni channel channel.jni.enable=0 in your wokers2.properties file.. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12126] - Apache 2.0.40 and mod_jk2 errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12126. 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=12126 Apache 2.0.40 and mod_jk2 errors --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 09:44 --- My last comment contains a wrong wording for the disable the JNI channel in the workers2.properties file it must be.. [channel.jni:jni] disabled=1 it's possible to use the other format channel.jni.disabled=1 but i'm not truly sure of the correct wording then, the excerpt above must work fine too.. if you already have a channel.jni section in your wk2.p file, add the disabled property there. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat crashes
Hi, I checked with solaris and no patch is installed, but surprisingly on the other solaris(i.e. 5.7) where tomcat is running there also no patch is installed. In my solaris 8 where sun had asked to install one patch that is not installed and still my system is running perfectly. So now I am surprised with this as if for two same OS if tomcat is running in one then it should work in other, do you think should be something like memory or harddisk space like proble? Any other suggestions?? Thanks Taral Shah - Original Message - From: Bojan Smojver [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; Taral Shah [EMAIL PROTECTED] Sent: Thursday, August 29, 2002 12:46 PM Subject: Re: tomcat crashes Quoting Taral Shah [EMAIL PROTECTED]: But same thing works with different solaris. Here I have solaris 5.7 and with 5.8 it works fine, even in one of 5.7 solaris machine tomcat runs fine. And they all have the same patches applied? I don't use Solaris, so I can't tell you specifically what to do or patch, but the errors indicate a VM problem (or something outside affecting the VM). Even if you feed VM total garbage, it shouldn't crash. That's the theory, at least. I checked with memory and space, initially it showed that it had occupied 99% of disk space, so i moved whole code to another partition and there only 50% space is used. Still its giving me same problem. I never had such crowded partitions, so I can tell if that might affect the VM. Any other solution, Or if i change JDK then which jdk should i go, as I need jdk 1.3 and here i am using same, do u suggest me to go with jdk1.4? I think there is a 1.3.1_04 available for Solaris. If you're aren't familiar with 1.4 (like I'm not), I think it's better to stick with the same minor version, unless, of course, that doesn't fix it. And given the error message (An unexpected exception has been detected in native code outside the VM), I would investigate the patch status of the machine quite seriously. Bojan - This mail sent through IMP: http://horde.org/imp/ -- 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]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardWrapper.java
remm2002/08/29 03:37:55
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
Log:
- Capture output when unloading servlets.
Revision ChangesPath
1.40 +16 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- StandardWrapper.java 26 Jun 2002 13:41:12 - 1.39
+++ StandardWrapper.java 29 Aug 2002 10:37:55 - 1.40
@@ -1098,6 +1098,9 @@
Thread.currentThread().getContextClassLoader();
ClassLoader classLoader = instance.getClass().getClassLoader();
+PrintStream out = System.out;
+SystemLogHandler.startCapture();
+
// Call the servlet destroy() method
try {
instanceSupport.fireInstanceEvent
@@ -1120,6 +1123,15 @@
} finally {
// restore the context ClassLoader
Thread.currentThread().setContextClassLoader(oldCtxClassLoader);
+// Write captured output
+String log = SystemLogHandler.stopCapture();
+if (log != null log.length() 0) {
+if (getServletContext() != null) {
+getServletContext().log(log);
+} else {
+out.println(log);
+}
+}
}
// Deregister the destroyed instance
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11891] - JspC does not work for webapps
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=11891. 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=11891 JspC does not work for webapps [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Major Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 10:41 --- Sorry but I'm reopening this again as I still cannot make it work for me, and I now have other users complaining about it.I will attach new simpler example of the problem. I have created a simple webapp called jspdemo: jspdemo/: WEB-INF/ index.jsp subdir/ jspdemo/WEB-INF: classes/ jspdemo/WEB-INF/classes: jspdemo/subdir: index.jsp this is attached as before.zip I then run java org.apache.jasper.JspC -webapp jspdemo -d jspdemo/WEB-INF/classes -webxml jspdemo/WEB-INF/web.xml which generates the source and web.xml (after.zip), but they cannot be used because of two problems. The source files generated are: jspdemo/WEB-INF/classes/index_jsp.java jspdemo/WEB-INF/classes/subdir/index_jsp.java But both are in the org.apache.jsp package. Thus I cannot compile them to WEB-INF/classes as both end up in WEB-INF/classes/org/apache/jsp/index_jsp.class Also the generated web.xml has a duplicate definition of servlet servlet-nameorg.apache.jsp.index_jsp/servlet-name servlet-classorg.apache.jsp.index_jsp/servlet-class /servlet which is used by both servlet mapping clauses, so both JSPs are mapped to the same servlet. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11891] - JspC does not work for webapps
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=11891. 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=11891 JspC does not work for webapps --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 10:46 --- Created an attachment (id=2866) jspdemo before JspC generation -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11891] - JspC does not work for webapps
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=11891. 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=11891 JspC does not work for webapps --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 10:46 --- Created an attachment (id=2867) jspdemo after JspC generation -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 - New directory
jfclere 2002/08/29 03:49:16 jakarta-tomcat-connectors/jk/xdocs/jk2 - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/common - New directory
jfclere 2002/08/29 03:49:17 jakarta-tomcat-connectors/jk/xdocs/common - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk - New directory
jfclere 2002/08/29 03:49:17 jakarta-tomcat-connectors/jk/xdocs/jk - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configtc.xml configweb.xml
jfclere 2002/08/29 04:04:34
Modified:jk build.xml
jk/xdocs menu.idx style.xsl.in
Added: jk/xdocs/common AJPv13.xml
jk/xdocs/jk2 configtc.xml configweb.xml
Removed: jk/xdocs AJPv13.xml configtc.xml configweb.xml
Log:
Arrange structure to allow jk and jk2 documentation togother.
Note:
- The index.xml is still the jk2 one.
- The links to sessions are not working.
Revision ChangesPath
1.48 +11 -1 jakarta-tomcat-connectors/jk/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- build.xml 13 Aug 2002 16:26:37 - 1.47
+++ build.xml 29 Aug 2002 11:04:34 - 1.48
@@ -394,7 +394,17 @@
basedir=${source.docs}
destdir=${build.docs}
style=${source.docs}/style.xsl
-includes=**.xml/
+includes=*/**.xml
+excludes=index.xml
+/style
+style
+basedir=${source.docs}
+destdir=${build.docs}
+style=${source.docs}/style.xsl
+includes=index.xml
+param name=images expression=images/
+param name=homedoc expression=/
+/style
!-- Copy all relevant (non processed) files from the sources --
copy
1.3 +3 -3 jakarta-tomcat-connectors/jk/xdocs/menu.idx
Index: menu.idx
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/menu.idx,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- menu.idx 20 Jun 2002 19:33:10 - 1.2
+++ menu.idx 29 Aug 2002 11:04:34 - 1.3
@@ -2,7 +2,7 @@
index
document href=index.xml/
- document href=AJPv13.xml/
- document href=configtc.xml/
- document href=configweb.xml/
+ document href=common/AJPv13.xml/
+ document href=jk2/configtc.xml/
+ document href=jk2/configweb.xml/
/index
1.4 +15 -10jakarta-tomcat-connectors/jk/xdocs/style.xsl.in
Index: style.xsl.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/style.xsl.in,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- style.xsl.in 30 Jun 2002 03:32:01 - 1.3
+++ style.xsl.in 29 Aug 2002 11:04:34 - 1.4
@@ -7,10 +7,14 @@
!--
Let's start by declaring HOW this stylesheet must behave.
--
- xsl:output method=html indent=no
+ xsl:output method=html indent=yes
doctype-public=-//W3C//DTD HTML 4.01//EN
doctype-system=http://www.w3.org/TR/html4/strict.dtd/
+ !-- Define default values for parameters --
+ xsl:param name=images select='../images'/
+ xsl:param name=homedoc select='../'/
+
!-- Defined variables (non-overrideable) --
xsl:variable name=body-bg select='@body-bg@'/
xsl:variable name=body-fg select='@body-fg@'/
@@ -56,7 +60,7 @@
meta name=email content={$email}/
/xsl:for-each
link rel=stylesheet type=text/css href=style.css/
-link rel=shortcut icon href=images/tomcat.ico/
+link rel=shortcut icon href={$images}/tomcat.ico/
/head
!--
@@ -72,10 +76,10 @@
--
tr height=1
td width=150 bgcolor={$body-bg} height=1 class=nil
- img src=images/pixel.gif border=0 width=150 height=1
vspace=0 hspace=0/
+ img src={$images}/pixel.gif border=0 width=150 height=1
vspace=0 hspace=0/
/td
td width=* bgcolor={$body-bg} height=1 class=nil
- img src=images/pixel.gif border=0 width=370 height=1
vspace=0 hspace=0/
+ img src={$images}/pixel.gif border=0 width=370 height=1
vspace=0 hspace=0/
/td
/tr
@@ -87,10 +91,10 @@
table border=0 cellspacing=0 cellpadding=0 width=100%
tr
td align=left
-img src=images/jakarta.gif border=0 width=270
height=75 align=left/
+img src={$images}/jakarta.gif border=0 width=270
height=75 align=left/
/td
td align=right
-img src=images/mod_jk.jpeg border=0 width=400
height=75 align=right/
+img src={$images}/mod_jk.jpeg border=0 width=400
height=75 align=right/
/td
/tr
/table
@@ -131,10 +135,10 @@
!-- Empty row, thanks IE --
tr height=1
td width=10 bgcolor=#cc height=1 class=nil
-img src=images/pixel.gif border=0 width=10
cvs commit: jakarta-tomcat-4.0/resources INSTALLLICENSE
remm2002/08/29 04:16:10 Modified:resources INSTALLLICENSE Log: - Update copyright year. Revision ChangesPath 1.2 +1 -1 jakarta-tomcat-4.0/resources/INSTALLLICENSE Index: INSTALLLICENSE === RCS file: /home/cvs/jakarta-tomcat-4.0/resources/INSTALLLICENSE,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- INSTALLLICENSE15 Jul 2001 19:17:32 - 1.1 +++ INSTALLLICENSE29 Aug 2002 11:16:10 - 1.2 @@ -2,7 +2,7 @@ The Apache Software License, Version 1.1 - Copyright (c) 1999, 2000, 2001 The Apache Software Foundation. + Copyright (c) 1999-2002 The Apache Software Foundation. All rights reserved. == -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12156] New: - Apache and Tomcat 3.3.1 Interworking problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12156. 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=12156 Apache and Tomcat 3.3.1 Interworking problem Summary: Apache and Tomcat 3.3.1 Interworking problem Product: Tomcat 3 Version: 3.1.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Here is a problem in the interworking of Apache Web Server and Tomcat Servlet/JSP engine. We are using Apache 1.3.22 and Tomcat 3.3.1 on Windows 2000 and running them as Windows Services. Our web application is successfully deployed in Tomcat in a standard way i.e. in the %TOMCAT_HOME% \webapps directory. Apache web server can be contacted directly without any problems. Trying to access one of the servlets running in Tomcat via Apache using ajp13 “worker”, leads to no response at all. However with the same configuration if we try to access servlet using ajp12 “worker” we get our desired response. There is no error reported in the ap_mod_jk.log file. In case of ajp13 the last entry is: [jk_ajp13_worker.c (610)]: send_request 2: request body to send 0 - request body to resend 0 This gives a hint that the request was sent but no response was received or the request was never sent. However in case of ajp12 after inspecting the ap_mod_jk.log file one can observe that there is a response back from the Tomcat. Here is the snippet of ap_mod_jk.log in case of ajp12: [jk_ajp12_worker.c (357)]: Into ajpv12_handle_request [jk_ajp12_worker.c (361)]: ajpv12_handle_request, sending the ajp12 start sequence [jk_ajp12_worker.c (413)]: ajpv12_handle_request, sending the headers [jk_ajp12_worker.c (432)]: ajpv12_handle_request, sending the terminating mark [jk_ajp12_worker.c (477)]: ajpv12_handle_request done [jk_ajp12_worker.c (148)]: In jk_endpoint_t::service, sent request [jk_ajp12_worker.c (493)]: Into ajpv12_handle_response [jk_ajp12_worker.c (507)]: ajpv12_handle_response, read Status: 200 OK [jk_ajp12_worker.c (535)]: ajpv12_handle_response, read Status=200 OK [jk_ajp12_worker.c (507)]: ajpv12_handle_response, read Content-Type: text/html [jk_ajp12_worker.c (535)]: ajpv12_handle_response, read Content-Type=text/html [jk_ajp12_worker.c (547)]: ajpv12_handle_response, allocating header arrays [jk_ajp12_worker.c (507)]: ajpv12_handle_response, read Set-Cookie: JSESSIONID=jqrjfqw0l1;Path=/apmQuery [jk_ajp12_worker.c (535)]: ajpv12_handle_response, read Set- Cookie=JSESSIONID=jqrjfqw0l1;Path=/apmQuery [jk_ajp12_worker.c (507)]: ajpv12_handle_response, read Servlet-Engine: Tomcat Web Server/3.3.1 Final ( JSP 1.1; Servlet 2.2 ) [jk_ajp12_worker.c (535)]: ajpv12_handle_response, read Servlet-Engine=Tomcat Web Server/3.3.1 Final ( JSP 1.1; Servlet 2.2 ) [jk_ajp12_worker.c (507)]: ajpv12_handle_response, read [jk_ajp12_worker.c (509)]: ajpv12_handle_response, headers are done [jk_ajp12_worker.c (568)]: ajpv12_handle_response, starting response [jk_ajp12_worker.c (579)]: ajpv12_handle_response, reading response body [jk_ajp12_worker.c (595)]: ajpv12_handle_response, response body is done [jk_ajp12_worker.c (607)]: ajpv12_handle_response done [jk_ajp12_worker.c (163)]: Into jk_endpoint_t::done Interestingly if we try to access our servlet directly from Tomcat, the desired response is generated. Our question is as follows: Is there a bug in Tomcat 3.3.1 that prevents it to work with ajp13? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreStandardContext.java
Remy Maucherat wrote: Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: Capturing of stdout/stderr has been enabled in Tomcat 4.1 for 2-3 months now. I don't think it was, as RequestBase is deprecated, and is not used anymore (except in the old connectors). What I committed was a bug fix. If you revert it, capturing stderr/stdout code will still exist, you would just put back in place a memory leak. Ok. There is another place where you will need to implement your SwallowOutput flag, in StandardWrapper.java. It captures output from a load on startup servlet. I don't have many problems with capturing during servlet init. It makes more sense to me to capture that data (no rational explanation, just a feeling). It's not done during shutdown, BTW. I can add that. :-) I can also make that optional using the same flag. The thread sync issue is a good point, but this can be improved by changing the SystemLogHandler to use Thread Local variables. Thread local is quite slow, from what I saw with OptimizeIt, so I don't want to use it. From reading the section on Thread Local Performance here: http://www-106.ibm.com/developerworks/java/library/j-threads3.html#h15292 Thread local performance differs based on the JVM. 1.2 - poor 1.3 - better than normal sync _if_ you have alot of thread contention. In production where performance is an issue Tomcat can spawn alot of threads, so Thread Local could be of benefit. 1.4 - much faster than normal sync Based on this, for the long run, I think its better to switch to Thread Local. Thanks for the information :) In the long run it may be better to add support for CaptureLog to the base class for a Processor so that the thread sync issues can be avoided altogether. So I'll add support for log capture on shutdown (I think it's as useful to have it as on startup). My personal preference is to leave the capture switched off by default for the critical path, as it would confuse developers (IMO). Thanks The number of people using Tomcat for development is probably much larger than those using it in production. So I am removing my previous -1 for the default setting of swallowOutput. Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12101] - SecurityManager + unprivileged call to getParameter() = Security Violation
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=12101. 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=12101 SecurityManager + unprivileged call to getParameter() = Security Violation --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 12:35 --- Try adding the following permission to your default grant in catalina.policy. java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.util.* And report back if this takes care of the problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
strange compile error
Hi, I'm new to the list, so please forgive me if i'm posting an already answered issue (although i did not find it in the archive) My problem : I've built a quite huge web app based on JSP pages, and there is a page which SOMETIMES does not get compiled. It happens once or twice form 10 occasions, but it's quite boring. The error I get is, variable ... might not have been initialised for all my variables, and also for the 'result' and 'out' variables, which are Tomcat's own! If I take the generated Java source fileI can compile it with javac with no errors. Has anybody had an issue like this, please give me some hints, I'm clueless... Thanks, Peter __ Do you want a free e-mail for life ? Get it at http://www.email.ro/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12041] - CGIServlet can block on input
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=12041.
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=12041
CGIServlet can block on input
--- Additional Comments From [EMAIL PROTECTED] 2002-08-29 13:31 ---
I'm running existing CGI script (perl/DBI), and encountered the same problem. My
current workaround is to redirect STDERR at the beginning of the script to avoid
getting into deadlock.
I applied the patch, and found the following additional issues:
+ STRERR messages should always go to the log file (following Apache
convention). It should not matter if the message if produced before, during of
after the header section (which is coming from STDOUT).
+ The patch do not support long running scripts, that do not produce output
(during database activity)
+ The patch does not work well when there are a lot of message on STDERR, but
little output on STDOUT. The CGI script is getting blocked on STDERR, while the
servlet is waiting on STDOUT (#1734).
I think that a good solution will be
A. running an extra thread to deal with STDERR, OR
B. Using Non-Blocking IO (unfortunantely, only with JDK 1.4), OR
C. Fixing the polling loop
while ( isRunning ) {
if (commandsStdErr != null commandsStdErr.ready()) {
/* Move STDERR data */
else if (commandsStdOut != null commandsStdOut.ready()) {
/* Deal with STDOUT data */
else {
sleep a little (0.1 sec)
}
}
/* Process Cleanup */
try {
... = proc.exitValue()}
catch ( ... ) {
/* Pause, then Kill Process if needed */
} ;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
-Mensaje original-
De: Bojan Smojver [mailto:[EMAIL PROTECTED]]
Enviado el: 29 de agosto de 2002 1:46
Para: Tomcat Dev List
Asunto: Re: Spec question: RE BUG 12052
AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
{
apr_port_t port;
core_dir_config *d =
(core_dir_config *)ap_get_module_config(r-per_dir_config,
core_module);
if (d-use_canonical_name == USE_CANONICAL_NAME_OFF
|| d-use_canonical_name == USE_CANONICAL_NAME_DNS) {
/* With UseCanonicalName off Apache will form self-referential
* URLs using the hostname and port supplied by the client if
* any are supplied (otherwise it will use the
canonical name).
*/
port = r-parsed_uri.port ? r-parsed_uri.port :
r-server-port ? r-server-port :
ap_default_port(r);
From the comment it seems to say, that Apache will get the port form
client supplied infos, and in the rfc2616(5.2) says that if the request
uri is relative ( i think actual clients only produce relative uris )
the host+port SHOULD be readed from the Host header..
So, i dont see any contradiction here, Apache2 does the rights thing
too.. at least with the port, for sure the servername will be the same..
This doesn't seem like coming from headers, but rather from URL or as
indicated by the server itself. What do you think?
We know how r-parsed_uri.port gets his value? but for sure Apache is
following the HTTP rfc 5.2.. reading it from Host header if needed
(raletive uris), if not it's a bug in Apache2 ( 2 days to be
sufficiently daring to say that :)
All of that if you USE_CANONICAL_NAME_OFF, but is the default, i think.
Saludos ,
Ignacio J. Ortega
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7359] - Classloader problems with RMI
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=7359. 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=7359 Classloader problems with RMI --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 13:57 --- Hi, Yes, I have also met this problem. The RMI server works fine with other Java applications but not with Tomcat as client to the RMI server. There is a workaround for this that work fine until 'apache.org' fix this bug. You add two codebases, one with 'file:/xx' and one with 'http://'. So when the bug is fixed, you just remove the 'file:/xx' stuff from the '-Djava.rmi.server.codebase='. regards, // Robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12126] - Apache 2.0.40 and mod_jk2 errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12126. 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=12126 Apache 2.0.40 and mod_jk2 errors --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 13:58 --- Please post your wk2.p file.., it seems your have been using the jni channel only, not the ajp13 one, you have been using the inprocess worker? -- 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/servlets HTMLManagerServlet.java LocalStrings.properties ManagerServlet.java
glenn 2002/08/29 07:01:21
Modified:catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java LocalStrings.properties
ManagerServlet.java
Log:
Prevent manager from trying to reload, remove, stop, or undeploy itself
Revision ChangesPath
1.9 +19 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
Index: HTMLManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- HTMLManagerServlet.java 13 Jun 2002 14:58:01 - 1.8
+++ HTMLManagerServlet.java 29 Aug 2002 14:01:19 - 1.9
@@ -258,7 +258,10 @@
args[2] = appsStop;
args[3] = appsReload;
args[4] = appsRemove;
-if (context.getAvailable()) {
+if (context.getPath().equals(this.context.getPath())) {
+writer.print(MessageFormat.format(
+MANAGER_APP_ROW_BUTTON_SECTION, args));
+} else if (context.getAvailable()) {
writer.print(MessageFormat.format(
STARTED_APPS_ROW_BUTTON_SECTION, args));
} else {
@@ -513,6 +516,17 @@
td class=\row-center\small{2}/small/td \n +
td class=\row-center\ +
smalla href=\sessions?path={0}\{3}/a/small/td \n;
+
+private static final String MANAGER_APP_ROW_BUTTON_SECTION =
+ td class=\row-left\ \n +
+ small \n +
+ nbsp;{1}nbsp; \n +
+ nbsp;{2}nbsp; \n +
+ nbsp;{3}nbsp; \n +
+ nbsp;{4}nbsp; \n +
+ /small \n +
+ /td \n +
+/tr \n;
private static final String STARTED_APPS_ROW_BUTTON_SECTION =
td class=\row-left\ \n +
1.19 +1 -0
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/LocalStrings.properties,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- LocalStrings.properties 13 Jun 2002 14:58:01 - 1.18
+++ LocalStrings.properties 29 Aug 2002 14:01:19 - 1.19
@@ -56,6 +56,7 @@
{0}
managerServlet.noRename=FAIL - Cannot deploy uploaded WAR for path {0}
managerServlet.noRole=FAIL - User does not possess role {0}
+managerServlet.noSelf=FAIL - The manager can not reload, remove, stop, or undeploy
itself
managerServlet.noWrapper=Container has not called setWrapper() for this
servlet
managerServlet.reloaded=OK - Reloaded application at context path {0}
1.25 +24 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
Index: ManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- ManagerServlet.java 31 May 2002 21:08:03 - 1.24
+++ ManagerServlet.java 29 Aug 2002 14:01:19 - 1.25
@@ -728,6 +728,11 @@
writer.println(sm.getString(managerServlet.noReload,
displayPath));
return;
}
+// It isn't possible for the manager to reload itself
+if (context.getPath().equals(this.context.getPath())) {
+writer.println(sm.getString(managerServlet.noSelf));
+return;
+}
context.reload();
writer.println(sm.getString(managerServlet.reloaded, displayPath));
} catch (Throwable t) {
@@ -764,6 +769,11 @@
writer.println(sm.getString(managerServlet.noContext,
displayPath));
return;
}
+// It isn't possible for the manager to remove itself
+if (context.getPath().equals(this.context.getPath())) {
+writer.println(sm.getString(managerServlet.noSelf));
+return;
+}
deployer.remove(path);
writer.println(sm.getString(managerServlet.removed, displayPath));
} catch (Throwable t) {
@@ -1041,6 +1051,11 @@
writer.println(sm.getString(managerServlet.noContext,
displayPath));
return;
}
+// It isn't possible for the manager to stop itself
+if
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreStandardContext.java
Glenn Nielsen wrote: So I'll add support for log capture on shutdown (I think it's as useful to have it as on startup). My personal preference is to leave the capture switched off by default for the critical path, as it would confuse developers (IMO). Thanks The number of people using Tomcat for development is probably much larger than those using it in production. So I am removing my previous -1 for the default setting of swallowOutput. I was thinking maybe it could be useful to add that flag to the DefaultContext. I'll do that after tagging 4.1.10. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.10-dev] Jasper 2 problems
The pending Tomcat 4.1.10 release looks like it may be a good candidate for a final release. It would be nice if we included some docs on using/configuring jasper. And the manager-howto.xml doc needs to be updated to document the HTMLManagerServlet, /manager/html/ Regards, Glenn Remy Maucherat wrote: Jan Luehe wrote: Remy, I'm testing 4.1.10-dev before tagging, and I ran into some serious problems. Jasper 2 seems broken (in the TC 4 branch; the HEAD/TC 5 branch may be broken as well, but I didn't have time to test it), and fails to compile most pages from the admin webapp. my apologies! When backporting a fix involving several code changes from Tomcat 5 to tomcat_4_branch, I overlooked one change in Generator.java. After applying this change to Generator.java in tomcat_4_branch, the admin webapp is working fine again. Thanks Jan :) I think 4.1.10 is almost ready to go. Remy -- 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: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreStandardContext.java
Remy Maucherat wrote: Glenn Nielsen wrote: So I'll add support for log capture on shutdown (I think it's as useful to have it as on startup). My personal preference is to leave the capture switched off by default for the critical path, as it would confuse developers (IMO). Thanks The number of people using Tomcat for development is probably much larger than those using it in production. So I am removing my previous -1 for the default setting of swallowOutput. I was thinking maybe it could be useful to add that flag to the DefaultContext. I'll do that after tagging 4.1.10. I forgot about the DefaultContext, yes, swallowOutput must be configurable in the DefaultContext. It shouldn't take much to add this, why not add it before tagging 4.1.10 since it may be a good candidate for release. I know that I will require the ability to set swallowOutput=true in the DefaultContext. Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreStandardContext.java
Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: So I'll add support for log capture on shutdown (I think it's as useful to have it as on startup). My personal preference is to leave the capture switched off by default for the critical path, as it would confuse developers (IMO). Thanks The number of people using Tomcat for development is probably much larger than those using it in production. So I am removing my previous -1 for the default setting of swallowOutput. I was thinking maybe it could be useful to add that flag to the DefaultContext. I'll do that after tagging 4.1.10. I forgot about the DefaultContext, yes, swallowOutput must be configurable in the DefaultContext. It shouldn't take much to add this, why not add it before tagging 4.1.10 since it may be a good candidate for release. I know that I will require the ability to set swallowOutput=true in the DefaultContext. Ok. Do you have time to add it ? I don't have time to do it today, so I would only do it tomorrow before tagging. Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Spec question: RE BUG 12052
On Thu, 29 Aug 2002, Bill Barker wrote: FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync here. If I actually thought that any members of the JCP were subscribed to this list, I'd think to ask for clarification before 2.4 went final. :) The way to ask would be to send feedback to [EMAIL PROTECTED]. Personally, I'd prefer to banish any mention of CGI environment variables in the servlet spec. That was useful when the servlet api was introduced because it was familiar, but today it just causes confusion. It's probably too late for that big a change this time around :-(, but with my new job role (Web Layer Architect for J2EE) I might have a better shot at convincing people next time ... Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servletJspServletWrapper.java
On Thu, 29 Aug 2002, Remy Maucherat wrote: Date: Thu, 29 Aug 2002 10:40:49 +0200 From: Remy Maucherat [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java Kin-Man Chung wrote: Date: Wed, 28 Aug 2002 16:41:16 -0700 (PDT) From: Craig R. McClanahan [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java To: Tomcat Developers List [EMAIL PROTECTED] On 28 Aug 2002 [EMAIL PROTECTED] wrote: - Fixed 11485: recompilation of jsp files when TLD is modified. Cool! This change (and wasn't there another recent change to auto-detect changes in files included via %@ include %?) will definitely reduce user confusion. The auto-detect of included files is already working in 4.1.x. I turned that off for tomcat 5, because it was causing problems with auto compilation of tag files. It all works now. I also turn on auto-detection of changes to files that are included with include-prelude and include-coda in jsp-config in JSP2.0, usign the same mechanism. Now if I had this one in 4.1.x ... :-) I could back port the TLD dependency check part to 4.1.x if there are demands for it. The feature is good. Could we wait until the first stable 4.1.x release to add it ? Yah, it can wait, but this is sure a pain for people actively building tag libraries on 4.1.x ... Remy Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs style.xsl.in
jfclere 2002/08/29 08:52:07
Modified:jk/xdocs style.xsl.in
Log:
Use the @name instead generate-id().
That way it is possible to add a href to a session in the xml.
Revision ChangesPath
1.5 +3 -3 jakarta-tomcat-connectors/jk/xdocs/style.xsl.in
Index: style.xsl.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/style.xsl.in,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- style.xsl.in 29 Aug 2002 11:04:34 - 1.4
+++ style.xsl.in 29 Aug 2002 15:52:07 - 1.5
@@ -172,7 +172,7 @@
tr
td bgcolor=#cc width=10/
td bgcolor=#cc width=140
- a class=menu href=#section_{generate-id(.)}
+ a class=menu href=#{@name}
xsl:value-of select=@name/
/a
/td
@@ -231,7 +231,7 @@
/xsl:template
xsl:template match=section
-a name=section_{generate-id(.)}
+a name={@name}
table border=0 cellspacing=0 cellpadding=0 width=100%
tr
td bgcolor={$banner-bg} class=section valign=top align=left
@@ -249,7 +249,7 @@
/xsl:template
xsl:template match=subsection
-a name=subsection_{generate-id(.)}
+a name=sub_{@name}
table border=0 cellspacing=0 cellpadding=0 width=100%
tr
td bgcolor={$sub-banner-bg} class=subsection valign=top
align=left
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Spec question: RE BUG 12052
On Thu, 2002-08-29 at 11:13, Craig R. McClanahan wrote: On Thu, 29 Aug 2002, Bill Barker wrote: FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync here. If I actually thought that any members of the JCP were subscribed to this list, I'd think to ask for clarification before 2.4 went final. :) The way to ask would be to send feedback to [EMAIL PROTECTED]. I've forwarded the thread to the spec lead for 2.4 and it has been brought up to the expert group. However, as Craig mentioned, the best way to ask is using the email address he listed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
Remy, Remy Maucherat wrote: +1 from me. If we do that, that would mean commons-daemon is not going anywhere: - the interfaces will go away - the launcher code is supposed to end up in Ant If the launcher doesn't end up in Ant, then IMO we should create commons-launcher. Since it will take a while to migrate all of the functionality in the launcher to Ant, we should plan on the commons-launcher code being around a while. So, +1 for creating a separate commons-launcher repository. Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk build.xml
jfclere 2002/08/29 09:12:01 Modified:jk build.xml Log: Allow to build the html documentation even if the tomcat-coyote.jar is not present. Revision ChangesPath 1.49 +1 -1 jakarta-tomcat-connectors/jk/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v retrieving revision 1.48 retrieving revision 1.49 diff -u -r1.48 -r1.49 --- build.xml 29 Aug 2002 11:04:34 - 1.48 +++ build.xml 29 Aug 2002 16:12:01 - 1.49 @@ -328,7 +328,7 @@ -- target name=docs.check - depends=prepare + depends=detect description=Fail if we don't find Xalan unless=avail.xalan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Spec question: RE BUG 12052
On Thu, 29 Aug 2002, Bill Barker wrote:
So: getServerPort() should return the same as the CGI variable SERVER_PORT
( which returns the server port, not the host header ! ), meaning the
value of the part after : in the Host header.
I didn't know that the servlet spec can define new meanings for the
CGI spec.
FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
here. If I actually thought that any members of the JCP were subscribed to
this list, I'd think to ask for clarification before 2.4 went final. :)
Nah... As long as they're returning the port from the host header -
I don't want any new clarification :-)
Actually, it is right about the server port, since the CGI says:
The port number to which the request was sent.
But not for the server name:
The server's hostname, DNS alias, or IP address as it would appear in
self-referencing URLs.
And the port can be interpreted easily to mean the Host header. Except
that apparently nobody implements it this way. Sometimes it is better to
provide all informations about the request - the port it was received
on and the host header. If you return the info from the host header in
both getServerPort and getHeader(), the port info is lost.
For getServerName() - the CGI interpretation is more 'the canonical name'.
If I access http://10.0.0.1, the Host will include the IP but
SERVER_NAME will be the canonical name. But now that the servlet
spec finally 'clarified' the CGI spec, we can wait for IIS and Apache
to fix their implementation and be compliant with the CGI spec at least :-)
Costin
Costin
spec-quote version=2.4 section=14.2.16
getServerName()
public java.lang.String getServerName()
Returns the host name of the server to which the request was sent. For
HTTP
servlets, same as the value of the CGI variable SERVER_NAME, meaning the
value of the part before : in the Host header, if any, or the resolved
server
name, or the server IP address.
Returns: a String containing the name of the server
getServerPort()
public int getServerPort()
Returns the port number to which the request was sent. For HTTP
servlets,
same as the value of the CGI variable SERVER_PORT, meaning the value of
the
part after : in the Host header, if any, or the server port where the
client
connection was accepted on.
Returns: an integer specifying the port number
/spec-quote
Note that a load balancer or proxy is required ( AFAIK ) to insert
Host: headers if none is present.
Costin
On 29 Aug 2002, Bojan Smojver wrote:
On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
The question in 12052 is whether Apache should use the socket port
(as
it
does now), or the port in the Host header. When this came up with
the
Coyote/Http11 connector, the decision was that the Host header was
the
correct one. I'd have to say that the bug is valid.
This is what the API (2.2) docs say about the getServerPort():
Returns the port number on which this request was received. For HTTP
servlets, same as the value of the CGI variable SERVER_PORT.
This in itself could be contradicting, but I think that in the case
of
Apache it is pretty straightforward.
This is what Apache 2.0 does to populate the variable SERVER_PORT:
apr_table_addn(e, SERVER_PORT,
apr_psprintf(r-pool, %u,
ap_get_server_port(r)));
And this is the ap_get_server_port():
AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
{
apr_port_t port;
core_dir_config *d =
(core_dir_config *)ap_get_module_config(r-per_dir_config,
core_module);
if (d-use_canonical_name == USE_CANONICAL_NAME_OFF
|| d-use_canonical_name == USE_CANONICAL_NAME_DNS) {
/* With UseCanonicalName off Apache will form
self-referential
* URLs using the hostname and port supplied by the client
if
* any are supplied (otherwise it will use the canonical
name).
*/
port = r-parsed_uri.port ? r-parsed_uri.port :
r-server-port ? r-server-port :
ap_default_port(r);
}
else { /* d-use_canonical_name == USE_CANONICAL_NAME_ON */
/* With UseCanonicalName on (and in all versions prior to
1.3)
* Apache will use the hostname and port specified in the
* ServerName directive to construct a canonical name for
the
* server. (If no port was specified in the ServerName
* directive, Apache uses the port supplied by the client if
* any is supplied, and finally the default port for the
protocol
* used.
DO NOT REPLY [Bug 12126] - Apache 2.0.40 and mod_jk2 errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12126. 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=12126 Apache 2.0.40 and mod_jk2 errors --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 16:41 --- Created an attachment (id=2869) workers2.properties file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
On Thu, 29 Aug 2002, jean-frederic clere wrote: I am +1 for merging the code but in daemon. I am using the daemon code for projects not related with mod_jk and I would perfer to have it independant from mod_jk. An other point to be against moving it in mod_jk is that the code has been moved recently in commons (sandbox) I do not thing that it is a good idea to move it back in the Tomcat repos. Also if we move it from daemon to mod_jk we have to ask it to the common dev list before moving it. Ok, not 'move'. What about 'copy' :-) ? There is a lot of duplication, I just want to make sure that jk has all the features that it needs - starting the VM is one thing I want to review and 'copy', if there's something that we missed in jk. I would also like to 'copy' the service monitor and copy and modify the service registration ( I like the jk_nt_service properties file, but the code is a bit ugly right now ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12101] - SecurityManager + unprivileged call to getParameter() = Security Violation
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=12101. 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=12101 SecurityManager + unprivileged call to getParameter() = Security Violation --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 16:55 --- Actually I needed to add this slightly different permission to address the problem: permission java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.util; Are there any security vulnerabilities exposed to untrusted webapps with this permission granted? If the org.apache.catalina.util... packages are expected to be protected from untrusted/user code, are there missing PrivilegedAction blocks in the HttpRequestBase Catalina implementation for methods like getParameter() and getParameterNames()? The way I masked the bug (w/o granting the permission above to untrusted webapps) was to have a trusted filter that calls getParameterNames() for the first request of each context. (It's a hack, yes, but I figured this was safer than simply granting the permission to all webapps, since I wasn't sure if that compromised any security.) Thoughts? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Spec question: RE BUG 12052
To answer my own email - with a summary: - what the user really wants is to know how to form URLs - that's how the server name and port are used in most cases - the real problem is getServerName(). In CGI it is the 'canonical' name. A server may have multiple aliases for a host, and in many cases it is desirable to return URLs that point to the 'canonical' or main name. - Host: header allways returns the host and port the user typed in. - the 'canonical name' is no longer available for servlets, if getServletName() is to return the info from Host ( i.e. the alias that the user typed ). That IMO is a _major_ loss. - Another cause to worry is the comment in apache2 core.c: There are two options regarding what the name of a server is. The canonical name as defined by ServerName and Port, or the client's name as supplied by a possible Host: header or full URI. We never trust the port passed in the client's headers, we always use the port of the actual socket. For tomcat, I would propose adding 1 'implementation specific' attribute ( allowed by the spec AFAIK ) to compensate for the loss of info. This attribute ( say 'CANONICAL_HOST' ?) would pass the 'official' name of the server ( and port ). Another option is to make this a context attribute. getServerName() and getPortName() would reflect what the user typed in the browser and would work in most cases. It is obviously not what the CGI is doing. My advice for anyone would be to avoid getServerName() and getPortName() and use getHeader( Host ) - that would work in any servlet container consistently and is far more portable ( if the host is what you want - if you want the real host/port, you're out of luck with servlet2.4 but you can use 2.3 and 2.2 without problems ). Costin [EMAIL PROTECTED] wrote: On Thu, 29 Aug 2002, Bill Barker wrote: So: getServerPort() should return the same as the CGI variable SERVER_PORT ( which returns the server port, not the host header ! ), meaning the value of the part after : in the Host header. I didn't know that the servlet spec can define new meanings for the CGI spec. FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync here. If I actually thought that any members of the JCP were subscribed to this list, I'd think to ask for clarification before 2.4 went final. :) Nah... As long as they're returning the port from the host header - I don't want any new clarification :-) Actually, it is right about the server port, since the CGI says: The port number to which the request was sent. But not for the server name: The server's hostname, DNS alias, or IP address as it would appear in self-referencing URLs. And the port can be interpreted easily to mean the Host header. Except that apparently nobody implements it this way. Sometimes it is better to provide all informations about the request - the port it was received on and the host header. If you return the info from the host header in both getServerPort and getHeader(), the port info is lost. For getServerName() - the CGI interpretation is more 'the canonical name'. If I access http://10.0.0.1, the Host will include the IP but SERVER_NAME will be the canonical name. But now that the servlet spec finally 'clarified' the CGI spec, we can wait for IIS and Apache to fix their implementation and be compliant with the CGI spec at least :-) Costin Costin spec-quote version=2.4 section=14.2.16 getServerName() public java.lang.String getServerName() Returns the host name of the server to which the request was sent. For HTTP servlets, same as the value of the CGI variable SERVER_NAME, meaning the value of the part before : in the Host header, if any, or the resolved server name, or the server IP address. Returns: a String containing the name of the server getServerPort() public int getServerPort() Returns the port number to which the request was sent. For HTTP servlets, same as the value of the CGI variable SERVER_PORT, meaning the value of the part after : in the Host header, if any, or the server port where the client connection was accepted on. Returns: an integer specifying the port number /spec-quote Note that a load balancer or proxy is required ( AFAIK ) to insert Host: headers if none is present. Costin On 29 Aug 2002, Bojan Smojver wrote: On Thu, 2002-08-29 at 04:28, Bill Barker wrote: The question in 12052 is whether Apache should use the socket port (as it does now), or the port in the Host header. When this came up with the Coyote/Http11 connector, the decision was that the Host header was the correct one. I'd have to say that the bug is valid. This is what the API (2.2) docs say about the getServerPort(): Returns the port number on which this request
Vacation
FYI: I'll be in vacation between Sep 1 and Sep 21. I'll read the mail from time to time, but probably not answer too much. I'm 'pre' voting +1 on the release of tomcat4.1 and on the release of jk1.2 and jk2.0beta - preferably using the same tag and date. I consider all of them stable and good enough. I'll spend some time in planes, and I plan to do a bit of work. Most likely I'll have fun with the JNDI/JMX configuration - I'll try to get some basic context for the jk2 config and switch jk2 to jndi as a first step. I also have some ideas for the hook mechanism in coyote, and some ant itches. If you have any proposal you know I don't like - now is the time to make it :-) -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12171] New: - jsp:params does not evaluate expression for value=%=expression%
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=12171. 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=12171 jsp:params does not evaluate expression for value=%=expression% Summary: jsp:params does not evaluate expression for value=%=expression% Product: Tomcat 4 Version: 4.1.9 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Within a jsp:plugin tag, the jsp:params tag doesn't evaluate expressions, (for the value attribute at least). Below is a sample of my JSP source code, and how it looks by the time it gets to the browser: JSP Source: jsp:param name=rmi value=%=rmiport%/ HTML Output: param name=rmi value=rmiport The same goes for the attributes as they appear in the embed output plugin tag. Note that the quotes are also stripped off the value. (Of course I've tested the value of 'rmiport' and it is correctly set to my particular port number, not the text value rmiport.) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12147] - session logout() method does not invalidate the session
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=12147. 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=12147 session logout() method does not invalidate the session [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/bin shutdown-using-launcher.bat startup-using-launcher.bat tool-wrapper-using-launcher.bat
patrickl2002/08/29 11:19:27 Modified:catalina/src/bin shutdown-using-launcher.bat startup-using-launcher.bat tool-wrapper-using-launcher.bat Log: Update scripts that use commons-launcher.jar so that %PATH% is only used on Window 9x Revision ChangesPath 1.2 +7 -1 jakarta-tomcat-catalina/catalina/src/bin/shutdown-using-launcher.bat Index: shutdown-using-launcher.bat === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/shutdown-using-launcher.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- shutdown-using-launcher.bat 4 Aug 2002 18:19:43 - 1.1 +++ shutdown-using-launcher.bat 29 Aug 2002 18:19:26 - 1.2 @@ -34,7 +34,13 @@ goto setArgs :doneSetArgs +rem Set classpath to handle when %0 does not contain any path +set PRG_CLASSPATH=%PRG%\.. +if %OS% == Windows_NT goto gotClasspath +set PRG_CLASSPATH=%PRG_CLASSPATH%;%PATH%;. +:gotClasspath + rem Execute the Launcher using the catalina target -%JAVA_HOME%\bin\java.exe -classpath %PRG%\..;%PATH% LauncherBootstrap -launchfile catalina.xml -verbose catalina %CMD_LINE_ARGS% stop +%JAVA_HOME%\bin\java.exe -classpath %PRG_CLASSPATH% LauncherBootstrap -launchfile catalina.xml -verbose catalina %CMD_LINE_ARGS% stop :end 1.2 +7 -1 jakarta-tomcat-catalina/catalina/src/bin/startup-using-launcher.bat Index: startup-using-launcher.bat === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/startup-using-launcher.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- startup-using-launcher.bat4 Aug 2002 18:19:43 - 1.1 +++ startup-using-launcher.bat29 Aug 2002 18:19:26 - 1.2 @@ -33,7 +33,13 @@ goto setArgs :doneSetArgs +rem Set classpath to handle when %0 does not contain any path +set PRG_CLASSPATH=%PRG%\.. +if %OS% == Windows_NT goto gotClasspath +set PRG_CLASSPATH=%PRG_CLASSPATH%;%PATH%;. +:gotClasspath + rem Execute the Launcher using the catalina target -%JAVA_HOME%\bin\java.exe -classpath %PRG%\..;%PATH% LauncherBootstrap -launchfile catalina.xml -verbose catalina %CMD_LINE_ARGS% start +%JAVA_HOME%\bin\java.exe -classpath %PRG_CLASSPATH% LauncherBootstrap -launchfile catalina.xml -verbose catalina %CMD_LINE_ARGS% start :end 1.2 +7 -1 jakarta-tomcat-catalina/catalina/src/bin/tool-wrapper-using-launcher.bat Index: tool-wrapper-using-launcher.bat === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/tool-wrapper-using-launcher.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- tool-wrapper-using-launcher.bat 4 Aug 2002 18:19:43 - 1.1 +++ tool-wrapper-using-launcher.bat 29 Aug 2002 18:19:26 - 1.2 @@ -34,7 +34,13 @@ goto setArgs :doneSetArgs +rem Set classpath to handle when %0 does not contain any path +set PRG_CLASSPATH=%PRG%\.. +if %OS% == Windows_NT goto gotClasspath +set PRG_CLASSPATH=%PRG_CLASSPATH%;%PATH%;. +:gotClasspath + rem Execute the Launcher using the tool-wrapper target -%JAVA_HOME%\bin\java.exe -classpath %PRG%\..;%PATH% LauncherBootstrap -launchfile catalina.xml -verbose tool-wrapper %CMD_LINE_ARGS% +%JAVA_HOME%\bin\java.exe -classpath %PRG_CLASSPATH% LauncherBootstrap -launchfile catalina.xml -verbose tool-wrapper %CMD_LINE_ARGS% :end -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/bin jspc-using-launcher.bat
patrickl2002/08/29 11:19:59 Modified:jasper2/src/bin jspc-using-launcher.bat Log: Update scripts that use commons-launcher.jar so that %PATH% is only used on Windows 9x Revision ChangesPath 1.2 +7 -1 jakarta-tomcat-jasper/jasper2/src/bin/jspc-using-launcher.bat Index: jspc-using-launcher.bat === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/bin/jspc-using-launcher.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jspc-using-launcher.bat 4 Aug 2002 18:21:08 - 1.1 +++ jspc-using-launcher.bat 29 Aug 2002 18:19:59 - 1.2 @@ -34,7 +34,13 @@ goto setArgs :doneSetArgs +rem Set classpath to handle when %0 does not contain any path +set PRG_CLASSPATH=%PRG%\.. +if %OS% == Windows_NT goto gotClasspath +set PRG_CLASSPATH=%PRG_CLASSPATH%;%PATH%;. +:gotClasspath + rem Execute the Launcher using the jspc target -%JAVA_HOME%\bin\java.exe -classpath %PRG%\..;%PATH% LauncherBootstrap -launchfile jasper.xml -verbose jspc %CMD_LINE_ARGS% +%JAVA_HOME%\bin\java.exe -classpath %PRG_CLASSPATH% LauncherBootstrap -launchfile jasper.xml -verbose jspc %CMD_LINE_ARGS% :end -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java
kinman 2002/08/29 11:31:20
Modified:jasper2/src/share/org/apache/jasper/compiler
ParserController.java
jasper2/src/share/org/apache/jasper/servlet
JspServletWrapper.java
Log:
- Fix the regression that isTagFile not passed correct when compiling tag files.
Revision ChangesPath
1.17 +4 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java
Index: ParserController.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- ParserController.java 28 Aug 2002 23:00:19 - 1.16
+++ ParserController.java 29 Aug 2002 18:31:20 - 1.17
@@ -112,7 +112,9 @@
private boolean isTopFile = true;
/*
- * Tells if this is a regular jsp page or tag file.
+ * Tells if the file to be parsed is a regular jsp page or tag file.
+ * Usually we get the info from the compilation context, but it can
+ * be temporarily overrideen with a parameter to the parse method
*/
private boolean isTagFile = false;
@@ -136,7 +138,6 @@
this.ctxt = ctxt; // @@@ can we assert that ctxt is not null?
this.compiler = compiler;
}
-
public JspCompilationContext getJspCompilationContext () {
return ctxt;
@@ -157,7 +158,7 @@
*/
public Node.Nodes parse(String inFileName)
throws FileNotFoundException, JasperException, IOException {
- return parse(inFileName, null, false);
+ return parse(inFileName, null, ctxt.isTagFile());
}
/**
1.16 +7 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java
Index: JspServletWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- JspServletWrapper.java28 Aug 2002 23:00:19 - 1.15
+++ JspServletWrapper.java29 Aug 2002 18:31:20 - 1.16
@@ -244,6 +244,10 @@
return null;
}
+public boolean isTagFile() {
+ return this.isTagFile;
+}
+
public void service(HttpServletRequest request,
HttpServletResponse response,
boolean precompile)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2002/08/29 12:22:00
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
Fixed 11742 (jsp:attribute with a non string body)
Revision ChangesPath
1.84 +22 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -r1.83 -r1.84
--- Generator.java28 Aug 2002 23:00:18 - 1.83
+++ Generator.java29 Aug 2002 19:22:00 - 1.84
@@ -2506,8 +2506,13 @@
// XXX assert(c.length 0)
}
- if (attrs[i].isExpression() || attrs[i].isNamedAttribute()) {
+ if (attrs[i].isExpression()) {
// Do nothing
+ } else if (attrs[i].isNamedAttribute()) {
+ attrValue = convertString(
+c[0], attrValue, attrName,
+ handlerInfo.getPropertyEditorClass(attrName),
+ false);
} else if (attrs[i].isELInterpreterInput()) {
// run attrValue through the expression interpreter
attrValue = JspUtil.interpreterCall(this.isTagFile,
@@ -2515,7 +2520,8 @@
} else {
attrValue = convertString(
c[0], attrValue, attrName,
- handlerInfo.getPropertyEditorClass(attrName));
+ handlerInfo.getPropertyEditorClass(attrName),
+ true);
}
if (attrs[i].isDynamic()) {
@@ -2546,17 +2552,22 @@
}
private String convertString(Class c, String s, String attrName,
- Class propEditorClass)
+ Class propEditorClass, boolean quote)
throws JasperException {
-
+
+ String quoted = s;
+ if (quote) {
+ quoted = quote(s);
+ }
+
if (propEditorClass != null) {
return ( + c.getName()
+ )JspRuntimeLibrary.getValueFromBeanInfoPropertyEditor(
+ c.getName() + .class, \ + attrName + \,
- + quote(s) + ,
+ + quoted + ,
+ propEditorClass.getName() + .class);
} else if (c == String.class) {
- return quote(s);
+ return quoted;
} else if (c == boolean.class) {
return Boolean.valueOf(s).toString();
} else if (c == Boolean.class) {
@@ -2606,12 +2617,12 @@
} else if (c == Long.class) {
return new Long( + Long.valueOf(s).toString() + l);
} else if (c == Object.class) {
- return new String( + quote(s) + );
+ return new String( + quoted + );
} else {
return ( + c.getName()
+ )JspRuntimeLibrary.getValueFromPropertyEditorManager(
+ c.getName() + .class, \ + attrName + \,
- + quote(s) + );
+ + quoted + );
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11742] - jsp:attribute with a non string body
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=11742. 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=11742 jsp:attribute with a non string body [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 19:26 --- Fixed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/compressionFilters CompressionServletResponseWrapper.java
amyroh 2002/08/29 12:32:29
Modified:webapps/examples/WEB-INF/classes/compressionFilters
CompressionServletResponseWrapper.java
Log:
Minor change to take default encoding when no content-type is set.
Patch submitted by Peter Rajsky [EMAIL PROTECTED].
Revision ChangesPath
1.8 +1 -4
jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/compressionFilters/CompressionServletResponseWrapper.java
Index: CompressionServletResponseWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/examples/WEB-INF/classes/compressionFilters/CompressionServletResponseWrapper.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- CompressionServletResponseWrapper.java28 Aug 2002 18:35:35 - 1.7
+++ CompressionServletResponseWrapper.java29 Aug 2002 19:32:29 - 1.8
@@ -277,10 +277,7 @@
System.out.println(stream is set to +stream+ in getWriter);
}
String charset = getCharsetFromContentType(contentType);
-if (charset == null) {
-charset = windows-1250;
-}
-writer = new PrintWriter(new OutputStreamWriter(stream, charset));
+writer = new PrintWriter((charset == null)? new OutputStreamWriter(stream)
: new OutputStreamWriter(stream, charset));
return (writer);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ?? Wrong HTTP Header Encoding, Posted to Bugzilla ??
Tony, Bugzilla bug status will remain UNCONFIRMED until one of the developers takes a look at it and change its status. Depending on the bug, its status can be changed to NEW, ASSIGNED, or RESOLVED. Amy Tony LaPaso wrote: Hey all, I'm new to Bugzilla so forgive me if you know about this. I posted this bug against TC 4.1.8 a couple weeks ago but I'm not sure if there is something else I should do to get it in the Bug Queue. Right now its status is UNCONFIRMED (although *I* am pretty sure about it). Is it appropriate for me to reassign this [EMAIL PROTECTED]? Thanks...again, I'm not sure of the proper etiquette for using Bugzilla. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11647 -- 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]
DO NOT REPLY [Bug 12126] - Apache 2.0.40 and mod_jk2 errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12126.
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=12126
Apache 2.0.40 and mod_jk2 errors
--- Additional Comments From [EMAIL PROTECTED] 2002-08-29 21:02 ---
Ughh, i have surpassed the detail that you were trying the inprocess worker..
First, disregard my previous postings.. and sorry for the waste of time..
I seems that Tomcat is not started.. can you acces tomcat using
http://localhost:8080? Do you get anything logged to stdout or stderr files?
Try changing the classpath line for this:
OPT=-Djava.class.path=${CATALINA_HOME}/bin/tomcat-
jni.jar;${CATALINA_HOME}/lib/tomcat.jar
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ?? Wrong HTTP Header Encoding, Posted to Bugzilla ??
My recollection is that this is a known bug with the (deprecated) Http11Connector, but is fixed in the CoyoteConnector. I haven't attempted to reproduce the bug myself however. - Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, August 29, 2002 1:29 PM Subject: Re: ?? Wrong HTTP Header Encoding, Posted to Bugzilla ?? Tony, Bugzilla bug status will remain UNCONFIRMED until one of the developers takes a look at it and change its status. Depending on the bug, its status can be changed to NEW, ASSIGNED, or RESOLVED. Amy Tony LaPaso wrote: Hey all, I'm new to Bugzilla so forgive me if you know about this. I posted this bug against TC 4.1.8 a couple weeks ago but I'm not sure if there is something else I should do to get it in the Bug Queue. Right now its status is UNCONFIRMED (although *I* am pretty sure about it). Is it appropriate for me to reassign this [EMAIL PROTECTED]? Thanks...again, I'm not sure of the proper etiquette for using Bugzilla. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11647 -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12179] New: - Deployer.REMOVE_EVENT is not implemented in StandardHost
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=12179. 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=12179 Deployer.REMOVE_EVENT is not implemented in StandardHost Summary: Deployer.REMOVE_EVENT is not implemented in StandardHost Product: Tomcat 4 Version: 4.0.4 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The comments for StandardHost.remove() say that if the application is successfully removed, a ContainerEvent of type REMOVE_EVENT will be sent to registered listeners supplying the removed Context object as an argument. However, this is not yet implemented. This functionality is incomplete and inconsistent with the already implemented INSTALL_EVENT. -- 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
bobh2002/08/29 15:23:38 Modified:catalina/src/share/org/apache/catalina/session StandardSession.java Log: - fix for some of bug 12147 Namely, logout() was deferring to the SingleSignOn bit to perform the logout - however if SingleSignOn isn't being used then the current logout() implementation doesn't do squat. Now it correctly invalidates the current session when SingleSignOn isn't present. Revision ChangesPath 1.5 +10 -6 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.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- StandardSession.java 12 Aug 2002 19:12:44 - 1.4 +++ StandardSession.java 29 Aug 2002 22:23:38 - 1.5 @@ -1066,9 +1066,13 @@ throw new IllegalStateException (sm.getString(standardSession.isNew.ise)); - -// kills all sessions +// NOTE: The SingleSignOn Valve/SessionListener will expire +// all sessions, if it is being used. fireSessionEvent(Session.SESSION_DESTROYED_EVENT, logout); + +// If the SingleSignOn didnt expire it, lets do it now. +if (isValid) +expire(false); } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12126] - Apache 2.0.40 and mod_jk2 errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12126.
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=12126
Apache 2.0.40 and mod_jk2 errors
--- Additional Comments From [EMAIL PROTECTED] 2002-08-29 22:27 ---
Yes, I can access tomcat stand alone using port 8080.
Here's the tomcat startup console output:
[INFO] Registry - -Loading registry information
[INFO] Registry - -Creating new Registry instance
[INFO] Registry - -Creating MBeanServer
[INFO] Http11Protocol - -Initializing Coyote HTTP/1.1 on port 8080
[INFO] JkMain - -Starting Jk2, base dir= C:\Tomcat conf=C:\Tomcat\conf\jk2.prope
rties
[INFO] JkMain - -APR not loaded, disabling jni components: java.io.IOException:
no jkjni in java.library.path
[INFO] ChannelSocket - -JK: listening on tcp port 8009
[INFO] ChannelUn - -No file, disabling unix channel
[INFO] JkMain - -Jk running ID=0 ... init time=130 ms
Starting service Tomcat-Standalone
Apache Tomcat/4.1.8
[INFO] Http11Protocol - -Starting Coyote HTTP/1.1 on port 8080
Tomcat doesn't create stdout or stderr files, that I can find (logs directory).
tomcat.jar and ${CATALINA_HOME}/lib don't exist on my machine (tomcat 4.1.9).
${CATALINA_HOME}/common/lib and ${CATALINA_HOME}/server/lib do exist though.
In the past Apache 2.0.39 and Tomcat 4.1.9 worked inprocess just fine. 2.0.40
doesn't like mod_jk2 for some reason. At least it doesn't like the version
that I built. Would it be possible for you to recompile, for 2.0.40, and post
the mod_jk2.dll file?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5] Session.logout()
The JSP spec 2.4 gives us Session.logout(), what do we do when using Basic authentication? Once challenged, the web browser keeps passing the user/pass (right?) so any ideas about how to get the browser to re-challenge the end user? (change the domain?) Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12183] New: - Setting unpack WARs flag not recognized after using Admintool
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=12183. 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=12183 Setting unpack WARs flag not recognized after using Admintool Summary: Setting unpack WARs flag not recognized after using Admintool Product: Tomcat 4 Version: 4.1.9 Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I set the Unpack WARs flag to true using the Administration tool, save, and commit the file and then restart Tomcat, WARs in the webapps directory are not unpacked. However, if I modify the original server.xml to set the flag to true or false, the property is observed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
On Thu, 2002-08-29 at 23:49, Ignacio J. Ortega wrote: We know how r-parsed_uri.port gets his value? Yep. It's getting it from the URL, not the headers. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12184] New: - FORM based authentication / j_security_check not working
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=12184. 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=12184 FORM based authentication / j_security_check not working Summary: FORM based authentication / j_security_check not working Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] General setup description : Some webapp(works well), now adding form-based security, web-client-browser is InternetExplorer, and then 2 problems detected. First setup: On submitting my specified login form via ...action=j_security_check... on InternetExplorer with cookies disabled, always got HTTP Status 400 - Invalid direct reference to form login page. Workaround: Enabled cookies and works perfect. Second setup: Deploying my webapp outside %TOMCAT_HOME%, under c:/somewhere/under and tweaked server.xml accordingly in context element to docbase=c:/somewhere/under. Without FORM-based authentication served all well. But on submitting my specified login form via ...action=j_security_check... on InternetExplorer : 1.) response url was http://localhost:8080/search/j_security_check; and 2.)IE-own-error- messageHTTP 500. (Doesnt matter wether cookies enabled or not). Thanx for questions and comments. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
kinman 2002/08/29 16:27:36
Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java Parser.java
ParserController.java TagFileProcessor.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
- More treaking on isTagFile to make sure it works for included files.
Revision ChangesPath
1.18 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
Index: JspDocumentParser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- JspDocumentParser.java28 Aug 2002 23:00:19 - 1.17
+++ JspDocumentParser.java29 Aug 2002 23:27:36 - 1.18
@@ -223,7 +223,7 @@
node = new Node.IncludeDirective(attrsCopy, start, current);
String file = attrsCopy.getValue(file);
try {
- parserController.parse(file, node, false);
+ parserController.parse(file, node);
} catch (FileNotFoundException fnfe) {
throw new SAXParseException(
err.getString(jsp.error.file.not.found, file),
1.27 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- Parser.java 28 Aug 2002 23:00:19 - 1.26
+++ Parser.java 29 Aug 2002 23:27:36 - 1.27
@@ -330,7 +330,7 @@
}
try {
- parserController.parse(file, parent, false);
+ parserController.parse(file, parent);
} catch (FileNotFoundException ex) {
err.jspError(start, jsp.error.file.not.found, file);
} catch (Exception ex) {
1.18 +28 -9
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java
Index: ParserController.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ParserController.java 29 Aug 2002 18:31:20 - 1.17
+++ ParserController.java 29 Aug 2002 23:27:36 - 1.18
@@ -151,14 +151,38 @@
// Parse
/**
- * Parse the jsp page provided as an argument.
- * This is only invoked by the compiler.
+ * Parses a jsp file. This is invoked by the compiler.
*
* @param inFileName The name of the JSP file to be parsed.
*/
public Node.Nodes parse(String inFileName)
throws FileNotFoundException, JasperException, IOException {
- return parse(inFileName, null, ctxt.isTagFile());
+ isTagFile = ctxt.isTagFile();
+ return parseFile(inFileName, null);
+}
+
+/**
+ * Parses a jsp file. This is invoked to process an include file.
+ *
+ * @param inFileName The name of the JSP file to be parsed.
+ * @param parent The node for the 'include' directive.
+ */
+public Node.Nodes parse(String inFileName, Node parent)
+ throws FileNotFoundException, JasperException, IOException {
+ return parseFile(inFileName, parent);
+}
+
+/**
+ * Parses a tag file. This is invoked by the compiler to extract tag
+ * file directive information.
+ *
+ * @param inFileName The name of the tag file to be parsed.
+ */
+public Node.Nodes parseTagFile(String inFileName)
+ throws FileNotFoundException, JasperException, IOException {
+ isTagFile = true;
+ isTopFile = true;
+ return parseFile(inFileName, null);
}
/**
@@ -166,19 +190,14 @@
* This is invoked recursively to handle 'include' directives.
*
* @param inFileName The name of the jsp file to be parsed.
- * @param parent The node for the 'include' directive.
*/
-public Node.Nodes parse(String inFileName, Node parent, boolean isTagFile)
+private Node.Nodes parseFile(String inFileName, Node parent)
throws FileNotFoundException, JasperException, IOException {
- this.isTagFile = isTagFile;
Node.Nodes parsedPage = null;
String encoding = topFileEncoding;
InputStreamReader reader = null;
String absFileName = resolveFileName(inFileName);
- if
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util ExtensionValidator.java
horwat 2002/08/29 16:56:12
Modified:catalina/src/share/org/apache/catalina/util
ExtensionValidator.java
Log:
Add more robust handling of invalid manifests.
If a manifest does not end with a newline as defined by the Manifest Specification
(http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#JAR%20Manifest) then
JarInputStream.getManifest() returns a null value.
Revision ChangesPath
1.2 +10 -8
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/ExtensionValidator.java
Index: ExtensionValidator.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/ExtensionValidator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ExtensionValidator.java 24 Aug 2002 02:27:28 - 1.1
+++ ExtensionValidator.java 29 Aug 2002 23:56:12 - 1.2
@@ -237,10 +237,12 @@
InputStream in = resource.streamContent();
JarInputStream jin = new JarInputStream(in);
Manifest jmanifest = jin.getManifest();
-ManifestResource mre = new ManifestResource
-(binding.getName(), jmanifest,
-ManifestResource.APPLICATION);
-appManifestResources.add(mre);
+if (jmanifest != null) {
+ManifestResource mre = new ManifestResource
+(binding.getName(), jmanifest,
+ManifestResource.APPLICATION);
+appManifestResources.add(mre);
+}
} catch (java.io.IOException iox) {
// do not do anything... go to the next entry
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2002/08/29 18:43:53
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
Fixed indentation in generated servlet code
Revision ChangesPath
1.85 +7 -7
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.84
retrieving revision 1.85
diff -u -r1.84 -r1.85
--- Generator.java29 Aug 2002 19:22:00 - 1.84
+++ Generator.java30 Aug 2002 01:43:53 - 1.85
@@ -2766,14 +2766,14 @@
}
if (ci.isHasUsebean()) {
-out.println(HttpSession session = pageContext.getSession(););
-out.println(ServletContext application =
pageContext.getServletContext(););
+out.printil(HttpSession session = pageContext.getSession(););
+out.printil(ServletContext application =
pageContext.getServletContext(););
}
if (ci.isHasUsebean() || ci.isHasIncludeAction() || ci.isHasSetProperty()) {
-out.println(HttpServletRequest request =
(HttpServletRequest)pageContext.getRequest(););
+out.printil(HttpServletRequest request =
(HttpServletRequest)pageContext.getRequest(););
}
if (ci.isHasIncludeAction()) {
-out.println(HttpServletResponse response =
(HttpServletResponse)pageContext.getResponse(););
+out.printil(HttpServletResponse response =
(HttpServletResponse)pageContext.getResponse(););
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12101] - SecurityManager + unprivileged call to getParameter() = Security Violation
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=12101. 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=12101 SecurityManager + unprivileged call to getParameter() = Security Violation --- Additional Comments From [EMAIL PROTECTED] 2002-08-30 02:51 --- What version of the JVM are you using. How accessClassInPackage and defineClassInPackage work changed from Java 1.3 to Java 1.4. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs manager-howto.xml
glenn 2002/08/29 20:46:27 Modified:webapps/tomcat-docs manager-howto.xml Log: Update the manager docs Revision ChangesPath 1.16 +49 -12jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml Index: manager-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/manager-howto.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- manager-howto.xml 6 Jun 2002 15:29:57 - 1.15 +++ manager-howto.xml 30 Aug 2002 03:46:27 - 1.16 @@ -48,15 +48,45 @@ directory./li /ul -pSince codeManager/code is itself a web application, it interacts with -you using standard HTTP requests and responses. However, it's user interface -is minimal, because it is intended to be accessed from scripts set up by the -system administrator. For this reason, commands are given as part of the +pThere are two ways to configure the Manager web application +codeContext/code: +ul +liInstall the codemanager.xml/code context configuration file +in the codeappBase/code for your codeHost/code./li +liConfigure the Manager codeContext/code within the +codeHost/code configuration in your Tomcat codeserver.xml/code +configuration. Here is an example: +pre +lt;Context path=/manager debug=0 privileged=true + docBase=/usr/local/kinetic/tomcat4/server/webapps/managergt; +lt;/Contextgt; +/pre +/li +/ul +/p + +pIf you have Tomcat configured to support multiple virtual hosts +(websites) you would need to configure a Manager for each./p + +pThere are three ways to use the codeManager/code web application. +ul +liAs an application with a user interface you use in your browser. +Here is an example URL where you can replace codelocalhost/code with +your website host name: codehttp://localhost/manager/html//code ./li +liA minimal version using HTTP requests only which is suitable for use +by scripts setup by system administrators. Commands are given as part of the request URI, and responses are in the form of simple text that can be easily -parsed and processed./p +parsed and processed. See a href=#Supported Manager Commands +Supported Manager Commands/a for more information./li +liA convenient set of task definitions for the emAnt/em +(version 1.4 or later) build tool. See +a href=#Executing Manager Commands With AntExecuting Manager Commands +With Ant/a for more information./li +/ul +/p pFuture versions of Tomcat 4 will include administrative functionality that -is presented in (at least) the following forms:/p +is presented in (at least) the following forms: ul liAs web services, so that Tomcat administration can be easily integrated into remote and/or non-Java mnagement environments./li @@ -64,12 +94,7 @@ web services processing layer) for easy Tomcat administration via a web browser./li /ul - -pIn addition to executing Manager commands directly via HTTP, Tomcat 4 -includes a convenient set of task definitions for the emAnt/em -(version 1.4 or later) build tool. See -a href=#Executing Manager Commands With AntExecuting Manager Commands -With Ant/a for more information./p +/p /section @@ -134,6 +159,18 @@ as long as they identify a valid user in the users database who possesses the role strongmanager/strong./p +pIn addition to the password restrictions the manager web application +could be restricted by the remote IP address or host by adding a +codeRemoteAddrValve/code or codeRemoteHostValve/code. Here is +an example of restricting access to the localhost by IP address: +pre +lt;Context path=/manager debug=0 privileged=true + docBase=/usr/local/kinetic/tomcat4/server/webapps/managergt; + lt;Valve className=org.apache.catalina.valves.RemoteAddrValve +allow=127.0.0.1/gt; +lt;/Contextgt; +/pre +/p /section -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12101] - SecurityManager + unprivileged call to getParameter() = Security Violation
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=12101. 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=12101 SecurityManager + unprivileged call to getParameter() = Security Violation --- Additional Comments From [EMAIL PROTECTED] 2002-08-30 04:44 --- I'm using Sun JDK 1.3.1_04. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Session.logout()
Bob, You are correct that browsers keep passing the user/pass with each request. As for getting the browser to rechallenge, that is very tricky and would be hacky at best. I would expect that when Basic authentication is used and the last request caused Session.logout() to called, the next request (which will contain a valid user/pass), will effectively log the user in. Trying to make Basic authentication act exactly like FORM authentication is probably not realistic as the display of user/pass input screen is browser dependent. Effectively, the user is silently logging back in with the next visit. I believe that this still complies with the spec. I suspect that the real problem may be that the bug submitter's interpretation of the spec may be a bit inaccurate. Patrick Bob Herrmann wrote: The JSP spec 2.4 gives us Session.logout(), what do we do when using Basic authentication? Once challenged, the web browser keeps passing the user/pass (right?) so any ideas about how to get the browser to re-challenge the end user? (change the domain?) Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9361] - jsp:param calls URLEncoder.encode() without null check
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=9361. 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=9361 jsp:param calls URLEncoder.encode() without null check [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Blocker --- Additional Comments From [EMAIL PROTECTED] 2002-08-30 04:58 --- There is talk of calling 4.1.10 a final release, but yet this apparent spec violation has not been fixed?!? -- 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 [EMAIL PROTECTED] changed: What|Removed |Added Severity|Critical|Blocker --- Additional Comments From [EMAIL PROTECTED] 2002-08-30 04:58 --- There is talk of calling 4.1.10 a final release, but yet this apparent spec violation has not been fixed?!? -- 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 DefaultContext.java
glenn 2002/08/29 22:41:13
Modified:catalina/src/share/org/apache/catalina/core
StandardDefaultContext.java
catalina/src/share/org/apache/catalina DefaultContext.java
Log:
Implement support for swallowOutput in DefaultContext.
Cleanup the default context docs and add swallowOutput.
useNaming was not in Context.java, just in the
Standard Implementation.
Removed useNaming from DefaultContext.java.
Updated docs so useNaming is listed as part of the
Standard Implementation.
Revision ChangesPath
1.7 +33 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java
Index: StandardDefaultContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- StandardDefaultContext.java 25 Jun 2002 22:29:23 - 1.6
+++ StandardDefaultContext.java 30 Aug 2002 05:41:13 - 1.7
@@ -197,6 +197,12 @@
/**
+ * The swallowOutput flag for this web application.
+ */
+private boolean swallowOutput = false;
+
+
+/**
* The set of classnames of LifecycleListeners that will be added
* to each newly created Wrapper by codecreateWrapper()/code.
*/
@@ -367,6 +373,28 @@
/**
+ * Return the swallowOutput flag for this web application.
+ */
+public boolean getSwallowOutput() {
+
+return (this.swallowOutput);
+
+}
+
+
+/**
+ * Set the swallowOutput flag for this web application.
+ *
+ * @param swallowOutput The new swallowOutput flag
+ */
+public void setSwallowOutput(boolean swallowOutput) {
+boolean oldSwallowOutput = this.swallowOutput;
+this.swallowOutput = swallowOutput;
+
+}
+
+
+/**
* Return the Java class name of the Wrapper implementation used
* for servlets registered in this Context.
*/
@@ -1293,6 +1321,7 @@
if (context instanceof StandardContext) {
((StandardContext)context).setUseNaming(isUseNaming());
+((StandardContext)context).setSwallowOutput(getSwallowOutput());
if (!contexts.containsKey(context)) {
((StandardContext) context).addLifecycleListener(this);
}
1.3 +4 -16
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/DefaultContext.java
Index: DefaultContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/DefaultContext.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DefaultContext.java 9 Nov 2001 19:34:21 - 1.2
+++ DefaultContext.java 30 Aug 2002 05:41:13 - 1.3
@@ -91,18 +91,6 @@
/**
- * Returns true if the internal naming support is used.
- */
-public boolean isUseNaming();
-
-
-/**
- * Enables or disables naming.
- */
-public void setUseNaming(boolean useNaming);
-
-
-/**
* Return the use cookies for session ids flag.
*/
public boolean getCookies();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config context.xml defaultcontext.xml
glenn 2002/08/29 22:41:41 Modified:webapps/tomcat-docs/config context.xml defaultcontext.xml Log: Implement support for swallowOutput in DefaultContext. Cleanup the default context docs and add swallowOutput. useNaming was not in Context.java, just in the Standard Implementation. Removed useNaming from DefaultContext.java. Updated docs so useNaming is listed as part of the Standard Implementation. Revision ChangesPath 1.11 +7 -7 jakarta-tomcat-4.0/webapps/tomcat-docs/config/context.xml Index: context.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/context.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- context.xml 28 Aug 2002 12:09:07 - 1.10 +++ context.xml 30 Aug 2002 05:41:40 - 1.11 @@ -149,13 +149,6 @@ on demand./p /attribute - attribute name=useNaming required=false -pSet to codetrue/code (the default) to have Catalina enable a -JNDI codeInitialContext/code for this web application that is -compatible with Java2 Enterprise Edition (J2EE) platform -conventions./p - /attribute - attribute name=wrapperClass required=false pJava class name of the codeorg.apache.catalina.Wrapper/code implementation class that will be used for servlets managed by this @@ -188,6 +181,13 @@ System.out and System.err by the web application will be redirected to the web application logger. If not specified, the default value of the flag is codefalse/code./p + /attribute + + attribute name=useNaming required=false +pSet to codetrue/code (the default) to have Catalina enable a +JNDI codeInitialContext/code for this web application that is +compatible with Java2 Enterprise Edition (J2EE) platform +conventions./p /attribute attribute name=workDir required=false 1.4 +18 -11jakarta-tomcat-4.0/webapps/tomcat-docs/config/defaultcontext.xml Index: defaultcontext.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/defaultcontext.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- defaultcontext.xml30 Nov 2001 06:23:13 - 1.3 +++ defaultcontext.xml30 Aug 2002 05:41:40 - 1.4 @@ -37,7 +37,7 @@ subsection name=Common Attributes -pAll implementations of strongHost/strong +pAll implementations of strongDefaultContext/strong support the following attributes:/p attributes @@ -71,13 +71,6 @@ on demand./p /attribute - attribute name=useNaming required=false -pSet to codetrue/code (the default) to have Catalina enable a -JNDI codeInitialContext/code for this web application that is -compatible with Java2 Enterprise Edition (J2EE) platform -conventions./p - /attribute - attribute name=wrapperClass required=false pJava class name of the codeorg.apache.catalina.Wrapper/code implementation class that will be used for servlets managed by this @@ -97,6 +90,21 @@ common attributes listed above):/p attributes + + attribute name=swallowOutput required=false +pIf the value of this flag is codetrue/code, the bytes output to +System.out and System.err by the web application will be redirected to +the web application logger. If not specified, the default value +of the flag is codefalse/code./p + /attribute + + attribute name=useNaming required=false +pSet to codetrue/code (the default) to have Catalina enable a +JNDI codeInitialContext/code for this web application that is +compatible with Java2 Enterprise Edition (J2EE) platform +conventions./p + /attribute + /attributes /subsection @@ -105,9 +113,9 @@ /section +!-- section name=Nested Components -!-- pYou can nest at most one instance of the following utility components by nesting a corresponding element inside your strongDefaultContext/strong element:/p @@ -136,10 +144,9 @@ resources associated with each web application. Normally, the default configuration of the resource manager will be sufficient./li /ul --- /section - +-- section name=Special Features -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java
billbarker2002/08/29 22:41:42
Modified:src/share/org/apache/tomcat/modules/session
SimpleSessionStore.java
Log:
Switch the order between copy and Serialize.
Reloading is an expensive operation in any case. By doing serialize first, we
handle the case where the session value is e.g. a Hashtable or Vector which contains
(a Serializable) value loaded with the old Webapp Classloader.
Revision ChangesPath
1.21 +5 -4
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java
Index: SimpleSessionStore.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- SimpleSessionStore.java 21 Aug 2002 04:11:56 - 1.20
+++ SimpleSessionStore.java 30 Aug 2002 05:41:42 - 1.21
@@ -147,14 +147,15 @@
while( e.hasMoreElements() ) {
String key = (String) e.nextElement();
Object value = session.getAttribute(key);
- if( value.getClass().getClassLoader() != oldCL ) {
- // it's loaded by the parent loader, no need to reload
- newSession.put( key, value );
- } else if ( value instanceof Serializable ) {
+ if ( value instanceof Serializable ) {
Object newValue =
ObjectSerializer.doSerialization( newCL,
value);
newSession.put( key, newValue );
+ }
+ else if( value.getClass().getClassLoader() != oldCL ) {
+ // it's loaded by the parent loader, no need to reload
+ newSession.put( key, value );
}
}
// If saving back to the same session.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: It seems new Tomcat33 reloading has a ClassLoader problem
I can't reproduce this (ok, I'm lying, if you re-order server.xml enough, you can do it :). But I can't find a valid case where this occurs. I've reversed the check between Serialize, and Copy so that your previous Hashtable example should now work. - Original Message - From: Hugh J. L. [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, August 25, 2002 7:02 PM Subject: Re: It seems new Tomcat33 reloading has a ClassLoader problem When I was tracing into ObjectSerializer, I found that the class loader parameter it got was NOT the one passed to it in SimpleSessionStore. So the serialization was NOT done using our expected context class loader of the new context. Why? I can't explain this behavior... I simulated the serialization process in a servlet, which was loaded by the new context class loader as a matter of course, it worked well and the servlet could access the old object after serialization. Don't know if these clues are useful to you. Regards, Hugh --- Bill Barker [EMAIL PROTECTED] wrote: This is really going beyond Tomcat's ability to detect. Beans that want this much control will need to be life-cycle aware (e.g. implement javax.servlet.http.HttpSessionBindingListener). Alternatively, the Bean can re-load the class when serialized. That having been said, I'm not really happy with the life-cycle support on the current patch. It is currently too closely tied to the Intercepter/Facade split. I may make it cleaner later. __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- 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]
