DO NOT REPLY [Bug 24932] - Is there a rule on the User Name field?
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=24932. 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=24932 Is there a rule on the User Name field? [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 09:59 --- Please post on tomcat-user for this kind of issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Elements in web.xml file for 2.4 servlet specification (Tomcat 5)
Hi, As you already know, one of the changes of the servlet 2.4 specification is that it uses XML schemas. And with this new schema, there is not anymore a strict order for the top level elements in the web.xml file So we can declare a servlet and then its mapping, and then a new servlet with its mapping Something like that : servlet ...servletA../servlet servlet-mapping..servletA.../servlet-mapping servlet ...servletB../servlet servlet-mapping..servletB.../servlet-mapping But the mapping of a servlet can be declared before the declaration of the servlet element servlet-mapping..servletA.../servlet-mapping servlet ...servletA../servlet The problem is that this is a valid XML but it fails during the deployment on Tomcat 5. This is due to the fact that during the XML parsing, when we add a servlet mapping, there is a check to see if the servlet exists. Method addServletMapping() in org.apache.catalina.core.StandardContext class. // Validate the proposed mapping if (findChild(name) == null) throw new IllegalArgumentException (sm.getString(standardContext.servletMap.name, name)); I agree that it is strange to do that (mapping between servlet declaration) and it can be a minor problem but it can occurs sometimes (during some copy/paste) So, maybe the check has to move to another place. Regards, Florent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat stats and performance
Hi to all, I have two questions. We have Tomcat as server for a struts web application. - We need do stats for that web application, stats like what pages user enter, who user enter more to the application, performance stats ... I have seen that one choice is do a manual filter, other choice use awstats. I would appreciate information about that of someone that have experiencia on stats, and he can help me to choose the best choice on time and effort. - The second question is about performance, here we have tomcat and when most user enter to the application the server don't reply very well. I have read that is better have APACHE as web server and TOMCAT as server container, is that true? would I improve the performance? or the solution is customize tomcat better?. THANKS IN ADVANCE. REGARDS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24940] New: - Direct access to request wrapped in (Http)ServletWrapper
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=24940. 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=24940 Direct access to request wrapped in (Http)ServletWrapper Summary: Direct access to request wrapped in (Http)ServletWrapper Product: Tomcat 5 Version: 5.0.14 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The ServletWrapper class provides getRequest and setRequest methods - as specificied in Java™ Servlet Specification Version 2.4 Final Draft. These methods are used in core of Tomcat to directly access the wrapped request and hence to bipass the wrapper. The whole point of the wrapper is to do just that - to wrap the request, so all access to the wrapped object should go through the wrapper implementation - this allows it to control and to modify access to the request as it sees fit. It would seem best to me to remove the getRequest and setRequest methods altogether in order to force access through the Wrapper (of course this would mean altering the 2.4 spec. doc also). This is not just a theoretical design problem it has manifested as a bug in my code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24940] - Direct access to request wrapped in (Http)ServletWrapper
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=24940. 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=24940 Direct access to request wrapped in (Http)ServletWrapper --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 12:56 --- This actually is the most poorly defined part of the spec and I have met differing implementations. Some parts even contradict each other. http://www.coredevelopers.net/library/j2ee/servlet24/ar01s05.jsp#d0e711 is an interesting read on that. I figure that until the spec gets clarified about this, the Tomcat implementors cannot do much about that. I propose you address [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JAASCallbackHandler clear password in the log file
Hi, if the debug level is 3, the org.apache.catalina.realm.JAASCallbackHandler.handle method writes in the log file the login and password it received (tomcat 4.1.29 JAASCallbackHandler.java, line 155). So any people who can access the machine on which Tomcat is running can see all the login and passwords used. Isn't this unsafe ? Should'nt this log be removed ? Thank for your answers. Yann _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24940] - Direct access to request wrapped in (Http)ServletWrapper
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=24940. 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=24940 Direct access to request wrapped in (Http)ServletWrapper [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 13:18 --- getRequest is IMO necessary. As for the rest, I had pointed out months ago the contradiction between wrapping and request dispatcher. My current understanding is that implementing the RD requirements is more important, so that wrapping will actually always occur. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21561] - jk_uriEnv.c version 1.49 does not handle uri's with asterix
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=21561.
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=21561
jk_uriEnv.c version 1.49 does not handle uri's with asterix
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|jk_uriEnv.c version 1.49|jk_uriEnv.c version 1.49
|does not handle uri's with |does not handle uri's with
|asterix |asterix
--- Additional Comments From [EMAIL PROTECTED] 2003-11-24 13:24 ---
I've also encountered this bug after switching from JK2 of Tomcat 4.1.27 to
4.1.29. Thanks to this bug report which pointed me to the right file I could
track down the problem. Here is a patch against the 4.1.29 distribution to fix
this problem.
---
--- old_jk_uriEnv.c 2003-11-24 13:43:30.0 +0100
+++ jk_uriEnv.c 2003-11-24 14:13:16.0 +0100
@@ -445,6 +445,7 @@
if (uri[strlen(uri) - 1] == '*') {
/* context based /context/prefix/ASTERISK */
+uri[strlen(uri) - 1] = '\0';
uriEnv-suffix = NULL;
uriEnv-prefix = uri;
uriEnv-prefix_len =strlen( uriEnv-prefix );
---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24940] - Direct access to request wrapped in (Http)ServletWrapper
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=24940. 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=24940 Direct access to request wrapped in (Http)ServletWrapper --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 13:28 --- I have submitted the question to [EMAIL PROTECTED] as suggested. Not sure that I agree that getRequest is necessary. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LB with mod_jk 2
Bill Barker wrote: Remy Maucherat [EMAIL PROTECTED] wrote in message Hi, I got a support question about LB with mod_jk 2 (and I saw posts about that on tomcat-user). Either there's something I don't understand, or the jk2_get_most_suitable_worker method in jk_worker_lb will always return the first worker which is not in an error state (assuming there was no session), causing all requests to be redirected to the first declared worker in a group. So did I miss something, or is the algorithm bad ? My recollection is that the algorithm is bad. Of course, I'm currently of the opinion that mod_jk2 is hopelessly broken, so I don't spend much time there :). At best, it suffers from the same problems as mod_jk if you are using the pre-fork MPM, so it doesn't work at all. mod_jk2 will need to save this to the smem file in order to work with pre-fork. The same configuration did get LB working ok with mod_jk 1.2.x. It seems mod_jk 2 woul need work indeed ;-) In the meantime, I'll recommend using mod_jk 1.2.x. Maybe I'll have time to help improve mod_jk 2.0, who knows. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Justification for URIEncoding addition?
Hans Bergsten wrote: Larry Isaacs wrote: Hans, The behavior change is unrelated to the use of getParameter() to search for jsp_precompile. Both Tomcat 3.x and Tomcat 4.x were bit by this log ago and Craig's fix was applied to both. In Tomcat 4's case, it was prior to the 4.0 release. Okay, I'm sure you're right that there may be more to it than avoiding the getParameter() call in Jasper, but based on what I've read, it seems to be part of the problem at least. Assuming I have a good grip on the issue, I think it relates to using UTF-8 to decode the path portion of the URL which gets used to determine context, servlet mapping, etc. Then allowing setCharacterEncoding() to change the character encoding for the query portion of the same URL. The Servlet 2.3 and 2.4 specs both say setCharacterEncoding() applies to the request body but don't mention it applying to the query portion of the URL. Right, but since the servlet spec doesn't say anything about encoding for the query portion, I think we have some room for a sensible interpretation. My concern is that with the new decoding behavior, apps that used to work fine suddenly don't, and the reason seems to be that browsers in fact ignore the RFC2718 recommendation that TC now enforces. I'm all for compliance with all related specs, but in this case it's just a recommendation and following it seems to do more harm than good. I agree it's not as clean as you may want, but are there any real problems with decoding the path portion using one charset and the query string with another (i.e., the one from getCharacterEncoding()), the way it used to be done? I see you as a member of the expert group for the servlet spec. Did you make out those points during the review period ? If not, then you IMO have nothing to complain about, esp since Tomcat implements a far more reasonable and simpler behavior for the URL string handling. The specification should have specified something along the lines of: - The URL must be %xx encoded - This decodes to bytes reprensenting UTF-8 characters There's an IETF standard that, I think, states this in BW. It is being ignored. Maybe this wouldn't be the case if very popular tech, such as servlets JSPs, started mandating it ? This is simply a chiken egg issue. i18n issues with HTTP and srevlets have been known about for years, but unfortunately they still haven't been addressed properly. Same with the request dispatcher + wrapping issues that I have pointed out months ago (and of course, were silently ignored). To balance this a little, among the other big issues, I have to give credit for solving the welcome files in a satisfactory way, as well as filters with RDs. Filters now make the proprietary APIs provided by the container irrelevant for most tasks. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAASCallbackHandler clear password in the log file
IMO, no. In a production environment: 1) The debug should not turned up that high 2) If its a production box, file permissions as well as people able to log into the box should be trusted. -Tim Yann GUEVEL wrote: Hi, if the debug level is 3, the org.apache.catalina.realm.JAASCallbackHandler.handle method writes in the log file the login and password it received (tomcat 4.1.29 JAASCallbackHandler.java, line 155). So any people who can access the machine on which Tomcat is running can see all the login and passwords used. Isn't this unsafe ? Should'nt this log be removed ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24723] - JNDI Datasource HOWTO instructions incorrect - Name jdbc is not bound in this Context
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=24723. 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=24723 JNDI Datasource HOWTO instructions incorrect - Name jdbc is not bound in this Context --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 15:16 --- I actually got the DataSource working as per the example, but only if i used the admin interface to add the resource. I added it under the context for my app, not in the global. However, this was almost a catch-22 because the admin interface would dump cannot find driverName if there wasn't a resource already defined. So I went directly to the server.xml file and added a dummy resource, then the admin interface would allow me to modify the url, login, etc. Then it worked. For awhile. Now it seems that when i have ant pop the war file for my app into the tomcat webapps dir, and delete the folder for my app under the webapps dir, i get the naming problem after restart. Do i have to be locked into the admin interface? whatever - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SingleSignOn Valve and FormAuthenticator Principal Caching
Brian, What format is your attachement in? When I try to follow the link, it asks me to open a file named showattachment with no suffix. It doesn't appear to be text. Does your fix do anything for bug 9077? I've been working on fixing the patch that is already pending for 9077. Luke -Original Message- From: Brian Stansberry [mailto:[EMAIL PROTECTED] Sent: Saturday, November 22, 2003 4:55 PM To: Tomcat Developers List Subject: Re: SingleSignOn Valve and FormAuthenticator Principal Caching Hi, Your timing is good to bring this up. We should definitely compare notes. Last night I committed a patch to JBoss that deals with this issue (classes can be found in the JBoss CVS in the org.jboss.web.catalina.tc4 package; most are in the authenticator subpackage). The JBoss patch is really more properly a Tomcat patch, but the JBoss folks asked me to commit it. I was planning to post a version to the Tomcat Bugzilla this weekend. In fact, I'll do it (against Bug 23881) as soon as I send this. The TC patch is against TC 5 HEAD; the JBoss version is against TC 4.1, plus has some minor tweaks to optimize for embedding in JBoss. Best, Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 At 04:27 PM 11/21/2003 -0600, you wrote: I believe that I have found a problem with the SingleSignOn valve, and the Principal caching that is performed in the FormAuthenticator. I believe that I have a valid patch for the issue, and I would like to discuss my proposed changes with the community. After reading the community rules, however, I'm unsure whether I'm suppose to present this discussion on the mailing list, or create a new bug report, and have everything tracked there. I believe my patch fixes some interaction problems with JBoss and Tomcat when Tomcat is used as an embedded server (related to bug 23881). Luke Nelson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: catalina.policy to avoid no object DCH for MIME...
This is a special use case depending on where you install the mail API jars.
Since there are potentially 1000's of special use cases I don't see where
adding these examples to catalina.policy would help.
A better solution would be to add a section to the Tomcat SecurityManager doc
which lists what permissions are required for different standard API's. JDBC,
mail, etc.
If you want to create a patch for the Tomcat security manager docs I would be
happy to review it and commit it.
Thanks,
Glenn
Jun Inamori wrote:
Hi,
We faced the same problem as:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg48320.html
The message reports the exception when sending e-mail.
It looks like this:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type
text/plain
at javax.mail.Transport.send0(Transport.java:219)
We re-produce this, only if we enable SecurityManager and place mail.jar and
activation.jar into:
${catalina.home}/shared/lib
SecurityManager seems to prevent javax.activation.CommandMap to load:
META-INF/mailcap
from mail.jar
To avoid this kind of problem, catalina.policy should include the entity like this:
grant codeBase file:${catalina.home}/shared/lib/activation.jar {
permission java.io.FilePermission
/usr/local/jakarta-tomcat-4.1.12-LE-jdk14/shared/lib/mail.jar,read;
};
I request you to add the lines below to catalina.policy.
// If you place mail.jar and activation.jar into:
//${catalina.home}/shared/lib
// please activate the entity below and update the target of
// FilePermission.
//grant codeBase file:${catalina.home}/shared/lib/activation.jar {
// permission java.io.FilePermission
/usr/local/jakarta-tomcat-4.1.12-LE-jdk14/shared/lib/mail.jar,read;
//};
I think this will help many Tomcat users, but do no harm.
Any suggestion/questions are welcome to me.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat stats and performance
[EMAIL PROTECTED] wrote: Hi to all, I have two questions. We have Tomcat as server for a struts web application. - We need do stats for that web application, stats like what pages user enter, who user enter more to the application, performance stats ... I have seen that one choice is do a manual filter, other choice use awstats. I would appreciate information about that of someone that have experiencia on stats, and he can help me to choose the best choice on time and effort. - The second question is about performance, here we have tomcat and when most user enter to the application the server don't reply very well. I have read that is better have APACHE as web server and TOMCAT as server container, is that true? would I improve the performance? or the solution is customize tomcat better?. THANKS IN ADVANCE. REGARDS. I recommend using Apache 2 with mod_jk 1.2 to serve static content in front of Tomcat. You can then configure mod_jk to do tomcat request logging which includes things like request latency in ms. There are perl scripts which come with the mod_jk 1.2 source distribution which can be used to analyze the mod_jk log. With Apache in front you can also use tools like analog to generate web statistics from the apache logs. For general Tomcat peformance issues there was a session at ApacheCon on this. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS with Tomcat
I gave up on ajp13 and now am trying to setup an inline jni plugin. I get
the following error in isapi.log:
Can't find class org/apache/tomcat/modules/server/JNIEndpoint
I searched for this, but couldn't find it. Also, I don't have tomcat.jar
under tomcat. Maybe that's the problem? I have 4.1.27 version.
From: Richard Norman [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 15:25:19 -0800
Are you using Windows Server 2003? Windows 2000?
Did you set the jakarta folder as execute permissions (not script)..
Richard Norman
web/Application Developer
Original Message Follows
From: Dmitriy . [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 15:39:49 -0500
Thanks... Went through all the steps that you specified, but something is
still not right. If I change the appbase as you specified to
c:/intetpub/wwwroot the server doesn't find the pages. If I leave it as is
webapps I still get that error:
HTTP Status 404 - /jakarta/isapi_redirect.dll
type Status report
message /jakarta/isapi_redirect.dll
description The requested resource (/jakarta/isapi_redirect.dll) is not
available.
Apache Tomcat/4.1.27-LE-jdk14
From: Richard Norman [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 09:19:46 -0800
For IIS and Tomcat setup, here are some posts I did to get it to work... I
have IIS 6 on Windows Server 2003 and it is working fine for me... I even
got the JK2 connector to work..
{all my posts in archive}
http://nagoya.apache.org/eyebrowse/[EMAIL
PROTECTED]by=authorfrom=82941to=82941first=1count=8
{The JK2 connector and config used}
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=129657
{My General Steps for configuring ISAPI connector-best for original ISAPI
connector}
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=124930
Original Message Follows
From: Andy Armstrong [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 16:03:07 +
MIME-Version: 1.0
Received: from mail.apache.org ([208.185.179.12]) by mc8-f16.hotmail.com
with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Nov 2003 08:03:36 -0800
Received: (qmail 64450 invoked by uid 500); 21 Nov 2003 16:03:24 -
Received: (qmail 64437 invoked from network); 21 Nov 2003 16:03:23 -
Received: from unknown (HELO protactinium.btinternet.com) (194.73.73.176)
by daedalus.apache.org with SMTP; 21 Nov 2003 16:03:23 -
Received: from host213-122-65-99.in-addr.btopenworld.com ([213.122.65.99]
helo=tagish.com)by protactinium.btinternet.com with esmtp (Exim 3.22
#25)id 1ANDki-0005nh-00for [EMAIL PROTECTED]; Fri, 21 Nov 2003
16:03:25 +
X-Message-Info: JGTYoYF78jGOFKEcD5wxD/gCr112vhqb
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Post: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
Delivered-To: mailing list [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Organization: Tagish Ltd
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-gb, en-us, en
References: [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
Return-Path:
[EMAIL PROTECTED]
X-OriginalArrivalTime: 21 Nov 2003 16:03:37.0362 (UTC)
FILETIME=[05D78F20:01C3B049]
Dmitriy . wrote:
Yes, it does... As to the spelling - I misspelled it in the e-mail. An
interesting thing
Well there's certainly no need to set up a /jakarta virtual directory on
Tomcat. The virtual directory on IIS is just part of the mechanism the
connector uses to pass requests to itself. The jk2 code logs to the
Windows event log - is there anything interesting in the application log?
--
Andy Armstrong, Tagish
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Sincerely,
Richard Norman
Web/Application Developer
Web Site: http://Jazzynupe.no-ip.com/
_
From the hottest toys to tips on keeping fit this winter, youll find a
range of helpful holiday info here.
http://special.msn.com/network/happyholidays.armx
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
DO NOT REPLY [Bug 19965] - mod_jk2 connection fails, workerEnv.init() create slot epStat.0 failed
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=19965.
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=19965
mod_jk2 connection fails, workerEnv.init() create slot epStat.0 failed
--- Additional Comments From [EMAIL PROTECTED] 2003-11-24 16:13 ---
I got the same problem, but when i try to correct it with the following lines
in workers2.properties :
[shm]
file=${serverRoot}/logs/shm.file
size=1048576
debug=0
then i got the following error message in jk2.log :
[Mon Nov 24 15:45:54 2003] (error) [jk_shm.c (358)]: shm.create(): error
mmapping c:/program files/apache group/apache/logs/shm.file
I'm using apache 1.3.29 on Windows XP
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP implicit writer (out) vs. response.getWriter()
Hi Karl,
The result is not unexpected. See the JSP 2.0 specification, section
JSP.1.7:
...JSP page authors are prohibited from writing directly to either the
PrintWriter or OutputStream associated with the ServletResponse.
The reason is that writes performed by the JSP page are normally
buffered. There is an implicit object 'out' that writes to the buffered
JspWriter which will accomplish what you are looking for, in the right
order. So you should do this instead:
html
body
Me first.
% out.println(Me second); %
/body
/html
Hope this helps.
---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
Karl Goldstein wrote:
After thinking about it a bit more, it seems the solution to the issue I raised yesterday is potentially simple: just use a wrapped response for the JSP response variable, which returns the JspWriter.
create a new package class JspResponseWrapper:
class JspResponseWrapper extends HttpServletResponseWrapper {
private Writer out;
JspResponseWrapper(HttpServletResponse response, JspWriter out) {
super(response);
this.out = out;
}
public Writer getWriter() {
return out;
}
...override other methods related to output stream/writer
}
Then in PageContextImpl._initialize:
this.response = new JspResponseWriter(response, this.out);
Thoughts?
Regards,
Karl Goldstein
- Original Message -
From: Karl Goldstein
To: [EMAIL PROTECTED]
Sent: Saturday, November 22, 2003 10:32 PM
Subject: JSP implicit writer (out) vs. response.getWriter()
Hi all,
I recently started working with Tomcat (4.1.29) and ran into an inconsistency between the implicit out variable in a JSP and response.getWriter(). Consider this JSP:
html
body
Me first.
% response.getWriter().println(Me second); %
/body
/html
I was surprised to discover that the out of this is:
Me second.
html
body
Me first.
/body
/html
Looking at org.apache.jasper.runtime.PageContextImpl and JspWriterImpl, it appears that the
out variable is set up
with its own buffer, which explains why text sent straight to the response writer
appears first (before the JSP writer buffer gets flushed).
Am I missing something or is this the way it actually works? If I have it straight,
is this a bug? I'm not sure about the
JSP spec, but other app servers I've tried seem to accumulate text in a single buffer for both
out and response.getWriter().
Thanks,
Karl Goldstein
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
J2EE 1.4 final?
Hi, Supposedly J2EE 1.4 has now gone final and been released. Yet the link on java.sun.com hot downloads section still says J2EE 1.4 Beta 2. The JSR pages for 152 and 154 on www.jcp.org say Final Approval Ballot is completed, so I suppose the spec are indeed final? Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS with Tomcat
Dmitry
The log you sent on Friday indicated a socket connect problem
Usually socket connect problems happen when you do not have you connector
(such as coyote connector in server.xml)
Concerning this problem
is tomcat.jar in %CATALINA_HOME%\common\lib
or %TOMCAT_HOME%\common\lib before you start TOMCAT?
Hth,
artin
- Original Message -
From: Dmitriy . [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 24, 2003 11:02 AM
Subject: Re: IIS with Tomcat
I gave up on ajp13 and now am trying to setup an inline jni plugin. I get
the following error in isapi.log:
Can't find class org/apache/tomcat/modules/server/JNIEndpoint
I searched for this, but couldn't find it. Also, I don't have tomcat.jar
under tomcat. Maybe that's the problem? I have 4.1.27 version.
From: Richard Norman [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 15:25:19 -0800
Are you using Windows Server 2003? Windows 2000?
Did you set the jakarta folder as execute permissions (not script)..
Richard Norman
web/Application Developer
Original Message Follows
From: Dmitriy . [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 15:39:49 -0500
Thanks... Went through all the steps that you specified, but something is
still not right. If I change the appbase as you specified to
c:/intetpub/wwwroot the server doesn't find the pages. If I leave it as
is
webapps I still get that error:
HTTP Status 404 - /jakarta/isapi_redirect.dll
---
-
type Status report
message /jakarta/isapi_redirect.dll
description The requested resource (/jakarta/isapi_redirect.dll) is not
available.
---
-
Apache Tomcat/4.1.27-LE-jdk14
From: Richard Norman [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 09:19:46 -0800
For IIS and Tomcat setup, here are some posts I did to get it to work...
I
have IIS 6 on Windows Server 2003 and it is working fine for me... I
even
got the JK2 connector to work..
{all my posts in archive}
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
.apache.orgby=authorfrom=82941to=82941first=1count=8
{The JK2 connector and config used}
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
ache.orgmsgNo=129657
{My General Steps for configuring ISAPI connector-best for original
ISAPI
connector}
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
ache.orgmsgNo=124930
Original Message Follows
From: Andy Armstrong [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 16:03:07 +
MIME-Version: 1.0
Received: from mail.apache.org ([208.185.179.12]) by mc8-f16.hotmail.com
with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Nov 2003 08:03:36 -0800
Received: (qmail 64450 invoked by uid 500); 21 Nov 2003 16:03:24 -
Received: (qmail 64437 invoked from network); 21 Nov 2003 16:03:23 -
Received: from unknown (HELO protactinium.btinternet.com)
(194.73.73.176)
by daedalus.apache.org with SMTP; 21 Nov 2003 16:03:23 -
Received: from host213-122-65-99.in-addr.btopenworld.com
([213.122.65.99]
helo=tagish.com)by protactinium.btinternet.com with esmtp (Exim 3.22
#25)id 1ANDki-0005nh-00for [EMAIL PROTECTED]; Fri, 21 Nov
2003
16:03:25 +
X-Message-Info: JGTYoYF78jGOFKEcD5wxD/gCr112vhqb
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Post: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
Delivered-To: mailing list [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Organization: Tagish Ltd
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-gb, en-us, en
References: [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
Return-Path:
[EMAIL PROTECTED]
X-OriginalArrivalTime: 21 Nov 2003 16:03:37.0362 (UTC)
FILETIME=[05D78F20:01C3B049]
Dmitriy . wrote:
Yes, it does... As to the spelling - I misspelled it in the e-mail. An
interesting thing
Well there's certainly no need to set up a /jakarta virtual directory on
Tomcat. The virtual directory on IIS is just part of the mechanism the
connector uses to pass requests to itself. The jk2 code logs to the
Windows event log - is there anything interesting in the application
log?
--
Andy Armstrong, Tagish
Re: J2EE 1.4 final?
Shapira, Yoav wrote: Hi, Supposedly J2EE 1.4 has now gone final and been released. Not yet :-) Yet the link on java.sun.com hot downloads section still says J2EE 1.4 Beta 2. The JSR pages for 152 and 154 on www.jcp.org say Final Approval Ballot is completed, so I suppose the spec are indeed final? Yes, they are. The J2EE link on sun.com will be updated soon. -- Jeanfrancois Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SingleSignOn Valve and FormAuthenticator Principal Caching
At 09:39 AM 11/24/2003 -0600, you wrote: What format is your attachement in? When I try to follow the link, it asks me to open a file named showattachment with no suffix. It doesn't appear to be text. Sorry; it's a zip file. Guess bugzilla doesn't like those. Even if you save the file, you have to rename it to something.zip before WinZip will open it. Includes a cvs diff and one new class. I've attached the patch to this reply as its only 10K. Does your fix do anything for bug 9077? I've been working on fixing the patch that is already pending for 9077. No, because this patch was written against the TC 5 code base. The TC 5 version on SingleSignOn already included logic for handling session expiration's differently from logouts, so I didn't change that. A port of this patch to TC 4 would need to address bug 9077. Best, Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 patch.zip Description: Zip archive - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2EE 1.4 final?
Shapira, Yoav wrote: Hi, Supposedly J2EE 1.4 has now gone final and been released. Yet the link on java.sun.com hot downloads section still says J2EE 1.4 Beta 2. The JSR pages for 152 and 154 on www.jcp.org say Final Approval Ballot is completed, so I suppose the spec are indeed final? They were voted on the 11th. However, I think we have to wait for the final specs to be available officially (and then I'll tag 5.0.15 within 24 hours). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/balancer/WEB-INF/classes/org/apache/webapp/balancer RulesParser.java
remm2003/11/24 08:41:24
Modified:webapps/balancer/WEB-INF/classes/org/apache/webapp/balancer
RulesParser.java
Log:
- Use the context CL for the digester (this allows not duplicating JARs).
Revision ChangesPath
1.2 +1 -0
jakarta-tomcat-catalina/webapps/balancer/WEB-INF/classes/org/apache/webapp/balancer/RulesParser.java
Index: RulesParser.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/balancer/WEB-INF/classes/org/apache/webapp/balancer/RulesParser.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RulesParser.java 20 Nov 2003 18:43:44 - 1.1
+++ RulesParser.java 24 Nov 2003 16:41:24 - 1.2
@@ -105,6 +105,7 @@
*/
protected Digester createDigester() {
Digester digester = new Digester();
+digester.setUseContextClassLoader(true);
String rules = rules;
String rule = /rule;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24943] New: - Tomcat 5.0.14 / Windows 2000 Service does not start
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=24943. 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=24943 Tomcat 5.0.14 / Windows 2000 Service does not start Summary: Tomcat 5.0.14 / Windows 2000 Service does not start Product: Tomcat 5 Version: 5.0.14 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Native:Integration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I downloaded jakarta-tomcat-5.0.14.exe and installed without any problem. I have only j2sdk 1.4.2 and not jre. (But jre included with jdk you know) After installation I opened the Windows 2000 Services tool and tried to start Apache Tomcat service but it didn't start and I received following error message; Could not start the Apache Tomcat service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion. I can start/stop Tomcat 5 with startup.bat and shutdown.bat without any problem. I think there was a problem about tomcat.exe or tomcatw.exe service installation parameters. But I couldn't find any documentation about Windows NT/2000/XP Service Installation in currect documentation bundle. For example if I want to use tomcat zip distribution (jakarta-tomcat- 5.0.14.zip) and make a manual installation (which it is better and flexible for me) I must know how to install the service with command line arguments. Or you can put a batch file for this, it will be very usefull. I read http://jakarta.apache.org/commons/daemon/procrun.html; but I couldn't install tomcat5 service. I don't know what is the problem? Thanks lot, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24942] New: - Tomcat 5.0.14 / Windows 2000 Service does not start
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=24942. 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=24942 Tomcat 5.0.14 / Windows 2000 Service does not start Summary: Tomcat 5.0.14 / Windows 2000 Service does not start Product: Tomcat 5 Version: 5.0.14 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Native:Integration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I downloaded jakarta-tomcat-5.0.14.exe and installed without any problem. I have only j2sdk 1.4.2 and not jre. (But jre included with jdk you know) After installation I opened the Windows 2000 Services tool and tried to start Apache Tomcat service but it didn't start and I received following error message; Could not start the Apache Tomcat service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion. I can start/stop Tomcat 5 with startup.bat and shutdown.bat without any problem. I think there was a problem about tomcat.exe or tomcatw.exe service installation parameters. But I couldn't find any documentation about Windows NT/2000/XP Service Installation in currect documentation bundle. For example if I want to use tomcat zip distribution (jakarta-tomcat- 5.0.14.zip) and make a manual installation (which it is better and flexible for me) I must know how to install the service with command line arguments. Or you can put a batch file for this, it will be very usefull. I read http://jakarta.apache.org/commons/daemon/procrun.html; but I couldn't install tomcat5 service. I don't know what is the problem? Thanks lot, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthenticator.java SingleSignOn.java mbeans-descriptors.xml
remm2003/11/24 08:46:56
Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java BasicAuthenticator.java
DigestAuthenticator.java FormAuthenticator.java
NonLoginAuthenticator.java SSLAuthenticator.java
SingleSignOn.java mbeans-descriptors.xml
Added: catalina/src/share/org/apache/catalina/authenticator
SingleSignOnEntry.java
Log:
- Bug 23881: SSO in embedded Tomcat.
- Patch submitted by Brian Stansberry. Thanks :)
Revision ChangesPath
1.14 +86 -20
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- AuthenticatorBase.java23 Oct 2003 17:33:10 - 1.13
+++ AuthenticatorBase.java24 Nov 2003 16:46:56 - 1.14
@@ -625,7 +625,7 @@
*
* @param request Request we are processing
* @param response Response we are creating
- * @param login Login configuration describing how authentication
+ * @param configLogin configuration describing how authentication
* should be performed
*
* @exception IOException if an input/output error occurs
@@ -643,7 +643,6 @@
protected synchronized String generateSessionId() {
// Generate a byte array containing a session identifier
-Random random = getRandom();
byte bytes[] = new byte[SESSION_ID_BYTES];
getRandom().nextBytes(bytes);
bytes = getDigest().digest(bytes);
@@ -801,6 +800,53 @@
/**
+ * Attempts reauthentication to the codeRealm/code using
+ * the credentials included in argument codeentry/code.
+ *
+ * @param ssoId identifier of SingleSignOn session with which the
+ * caller is associated
+ * @param request the request that needs to be authenticated
+ */
+protected boolean reauthenticateFromSSO(String ssoId, HttpRequest request) {
+
+if (sso == null || ssoId == null)
+return false;
+
+boolean reauthenticated = false;
+
+SingleSignOnEntry entry = sso.lookup(ssoId);
+if (entry != null entry.getCanReauthenticate()) {
+Principal reauthPrincipal = null;
+Container parent = getContainer();
+if (parent != null) {
+Realm realm = getContainer().getRealm();
+String username = entry.getUsername();
+if (realm != null username != null) {
+reauthPrincipal =
+realm.authenticate(username, entry.getPassword());
+}
+}
+
+if (reauthPrincipal != null) {
+associate(ssoId, getSession(request, true));
+request.setAuthType(entry.getAuthType());
+request.setUserPrincipal(reauthPrincipal);
+
+reauthenticated = true;
+if (log.isDebugEnabled()) {
+log.debug( Reauthenticated cached principal ' +
+ entry.getPrincipal().getName() +
+ ' with auth type ' +
+ entry.getAuthType() + ');
+}
+}
+}
+
+return reauthenticated;
+}
+
+
+/**
* Register an authenticated Principal and authentication type in our
* request, in the current session (if there is one), and with our
* SingleSignOn valve, if there is one. Set the appropriate cookie
@@ -825,9 +871,9 @@
request.setAuthType(authType);
request.setUserPrincipal(principal);
+Session session = getSession(request, false);
// Cache the authentication information in our session, if any
if (cache) {
-Session session = getSession(request, false);
if (session != null) {
session.setAuthType(authType);
session.setPrincipal(principal);
@@ -845,19 +891,39 @@
// Construct a cookie to be returned to the client
if (sso == null)
return;
-HttpServletRequest hreq =
-(HttpServletRequest) request.getRequest();
-HttpServletResponse hres =
-(HttpServletResponse) response.getResponse();
-String value = generateSessionId();
-Cookie cookie = new Cookie(Constants.SINGLE_SIGN_ON_COOKIE, value);
-cookie.setMaxAge(-1);
DO NOT REPLY [Bug 24943] - Tomcat 5.0.14 / Windows 2000 Service does not start
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=24943. 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=24943 Tomcat 5.0.14 / Windows 2000 Service does not start [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 16:48 --- *** This bug has been marked as a duplicate of 24942 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24942] - Tomcat 5.0.14 / Windows 2000 Service does not start
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=24942. 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=24942 Tomcat 5.0.14 / Windows 2000 Service does not start --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 16:48 --- *** Bug 24943 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS with Tomcat
Martin,
No, I don't have tomcat.jar in common/lib... It's weird because in docs they
refer to that... Maybe a 4.1.27 was a bad build? But then I would assume a
standalone tomcat (without IIS) wouldn't be working properly and it works
just fine.
From: Martin Gainty [EMAIL PROTECTED]
To: Tomcat Developers List
[EMAIL PROTECTED],[EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Mon, 24 Nov 2003 16:20:19 -0500
Dmitry
The log you sent on Friday indicated a socket connect problem
Usually socket connect problems happen when you do not have you connector
(such as coyote connector in server.xml)
Concerning this problem
is tomcat.jar in %CATALINA_HOME%\common\lib
or %TOMCAT_HOME%\common\lib before you start TOMCAT?
Hth,
artin
- Original Message -
From: Dmitriy . [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 24, 2003 11:02 AM
Subject: Re: IIS with Tomcat
I gave up on ajp13 and now am trying to setup an inline jni plugin. I
get
the following error in isapi.log:
Can't find class org/apache/tomcat/modules/server/JNIEndpoint
I searched for this, but couldn't find it. Also, I don't have tomcat.jar
under tomcat. Maybe that's the problem? I have 4.1.27 version.
From: Richard Norman [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 15:25:19 -0800
Are you using Windows Server 2003? Windows 2000?
Did you set the jakarta folder as execute permissions (not script)..
Richard Norman
web/Application Developer
Original Message Follows
From: Dmitriy . [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 15:39:49 -0500
Thanks... Went through all the steps that you specified, but something
is
still not right. If I change the appbase as you specified to
c:/intetpub/wwwroot the server doesn't find the pages. If I leave it as
is
webapps I still get that error:
HTTP Status 404 - /jakarta/isapi_redirect.dll
---
-
type Status report
message /jakarta/isapi_redirect.dll
description The requested resource (/jakarta/isapi_redirect.dll) is not
available.
---
-
Apache Tomcat/4.1.27-LE-jdk14
From: Richard Norman [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 09:19:46 -0800
For IIS and Tomcat setup, here are some posts I did to get it to
work...
I
have IIS 6 on Windows Server 2003 and it is working fine for me... I
even
got the JK2 connector to work..
{all my posts in archive}
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
..apache.orgby=authorfrom=82941to=82941first=1count=8
{The JK2 connector and config used}
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
ache.orgmsgNo=129657
{My General Steps for configuring ISAPI connector-best for original
ISAPI
connector}
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
ache.orgmsgNo=124930
Original Message Follows
From: Andy Armstrong [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: IIS with Tomcat
Date: Fri, 21 Nov 2003 16:03:07 +
MIME-Version: 1.0
Received: from mail.apache.org ([208.185.179.12]) by
mc8-f16.hotmail.com
with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Nov 2003 08:03:36 -0800
Received: (qmail 64450 invoked by uid 500); 21 Nov 2003 16:03:24 -
Received: (qmail 64437 invoked from network); 21 Nov 2003 16:03:23
-
Received: from unknown (HELO protactinium.btinternet.com)
(194.73.73.176)
by daedalus.apache.org with SMTP; 21 Nov 2003 16:03:23 -
Received: from host213-122-65-99.in-addr.btopenworld.com
([213.122.65.99]
helo=tagish.com)by protactinium.btinternet.com with esmtp (Exim 3.22
#25)id 1ANDki-0005nh-00for [EMAIL PROTECTED]; Fri, 21 Nov
2003
16:03:25 +
X-Message-Info: JGTYoYF78jGOFKEcD5wxD/gCr112vhqb
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Post: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
Delivered-To: mailing list [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Organization: Tagish Ltd
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-gb, en-us, en
References: [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
Return-Path:
[EMAIL PROTECTED]
X-OriginalArrivalTime: 21 Nov 2003 16:03:37.0362 (UTC)
FILETIME=[05D78F20:01C3B049]
Dmitriy . wrote:
Yes, it
DO NOT REPLY [Bug 12810] - socket write error clicking between pages to fast
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=12810. 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=12810 socket write error clicking between pages to fast --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 16:49 --- I fixed this a month ago. Here is the commit message for j-t-c. glenn 2003/10/22 06:46:28 Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java Log: SocketExceptions can occur in a networked app. No need to log a stack trace, just log the remote host name/ip and the exception message. Then there is less cruft in the logs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24942] - Tomcat 5.0.14 / Windows 2000 Service does not start
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=24942. 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=24942 Tomcat 5.0.14 / Windows 2000 Service does not start [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 16:52 --- If this cannot start, this likely means your JVM cannot be found for some reason (you moved it manually maybe); the installation uses the registry keys to locate your VM (pay special attention to the JVM path being chosen at that time, this won't work if it's not right). I have yet to see this report be valid, so please use tomcat-user to debug this more. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
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=23881. 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=23881 SingleSignOn and FormAuthenticator in embedded tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 16:53 --- I have applied your patch, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20073] - no object DCH for MIME type text/plain
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=20073. 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=20073 no object DCH for MIME type text/plain [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 16:55 --- This is not a bug in Tomcat bug a misconfigured catalina.policy for using the JavaMail API. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthenticator.java SingleSignOn.java mbeans-descriptors.xml
This means that the logout check is now back in, the revert from 1.6 - 1.7 for bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23764 Diff link: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java.diff?r1=1.6r2=1.7diff_format=h Just an FYI, at this point, I don't know if that is good, bad, or neither. -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthenticator.java SingleSignOn.java mbeans-descriptors.xml
Tim Funk wrote: This means that the logout check is now back in, the revert from 1.6 - 1.7 for bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23764 Diff link: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java.diff?r1=1.6r2=1.7diff_format=h Just an FYI, at this point, I don't know if that is good, bad, or neither. That's true. Maybe Brian can explain why he removed this (otherwise, I'll reapply the fix). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24944] New: - jasper writes temp files to directory TC started from
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=24944. 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=24944 jasper writes temp files to directory TC started from Summary: jasper writes temp files to directory TC started from Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 1/ deploy new war file 2/ start (/bin/startup.sh) TC from a directory to which TC user has no write permissions 3/ TC will not be able to compile (some - no pattern I could see) jsps as it will try to write a file (eg. files8349374) to the directory you started TC from which will not have sufficient write permissions This file looks like a file jasper needs to write before performing the initial jsp - _jsp.java conversion. When appropriate permissions provided - it is created then automatically deleted after about 1 second. If you cat the temp file created example contents are : /usr/local/tomcat/work/Standalone/localhost/_/jsp/diagnostics/diagpage_jsp.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24944] - jasper writes temp files to directory TC started from
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=24944. 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=24944 jasper writes temp files to directory TC started from [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Other |Linux Platform|Other |PC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthenticator.java SingleSignOn.java mbeans-descriptors.xml
At 06:15 PM 11/24/2003 +0100, you wrote: Tim Funk wrote: This means that the logout check is now back in, the revert from 1.6 - 1.7 for bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23764 Diff link: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java.diff?r1=1.6r2=1.7diff_format=h Just an FYI, at this point, I don't know if that is good, bad, or neither. That's true. Maybe Brian can explain why he removed this (otherwise, I'll reapply the fix). No, my mistake. It didn't intend to change anything related to session invalidation and didn't notice it in the diff. :( Since the logout feature no longer is there, this means bug 9077 still applies to TC5. Is anyone aware of any issue with the proposed patch attached to that bug? Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic
I have tried applying the patch, and I found three problems with it. First, its removal of a session from the SingleSignOnEntry object causes an IndexOutOfBounds exception. Second, the method for determining whether the user explicitly logged out or whether a session timed out doesn't scale one of the numbers correctly (i.e. comparing millisecond values to seconds). I have fixed the patch, but I don't have a diff of it yet (I'm new to helping with this project). Finally, the patch doesn't synchronize on 'reverse' when removing an entry from it. The only other issue that I have with this patch is that if someone explicitly logged out at the same instant that the session timed out, the user may not be logged out of all of the applications. It is an unlikely scenario, but still a dangerous one. This is why it is better for the session object, when firing the destroyed event, to indicate whether it was destroyed by timeout or explicit invalidation. Luke -Original Message- From: Brian Stansberry [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:43 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic At 06:15 PM 11/24/2003 +0100, you wrote: Tim Funk wrote: This means that the logout check is now back in, the revert from 1.6 - 1.7 for bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23764 Diff link: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src /share/org/apache/catalina/authenticator/SingleSignOn.java.diff?r1=1.6r 2=1.7diff_format=h Just an FYI, at this point, I don't know if that is good, bad, or neither. That's true. Maybe Brian can explain why he removed this (otherwise, I'll reapply the fix). No, my mistake. It didn't intend to change anything related to session invalidation and didn't notice it in the diff. :( Since the logout feature no longer is there, this means bug 9077 still applies to TC5. Is anyone aware of any issue with the proposed patch attached to that bug? Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic
I'm sorry I should have stated in my last message that I have tried the patch to bug 9077. Luke -Original Message- From: Nelson, Luke Sent: Monday, November 24, 2003 10:57 AM To: Tomcat Developers List Subject: RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic I have tried applying the patch, and I found three problems with it. First, its removal of a session from the SingleSignOnEntry object causes an IndexOutOfBounds exception. Second, the method for determining whether the user explicitly logged out or whether a session timed out doesn't scale one of the numbers correctly (i.e. comparing millisecond values to seconds). I have fixed the patch, but I don't have a diff of it yet (I'm new to helping with this project). Finally, the patch doesn't synchronize on 'reverse' when removing an entry from it. The only other issue that I have with this patch is that if someone explicitly logged out at the same instant that the session timed out, the user may not be logged out of all of the applications. It is an unlikely scenario, but still a dangerous one. This is why it is better for the session object, when firing the destroyed event, to indicate whether it was destroyed by timeout or explicit invalidation. Luke -Original Message- From: Brian Stansberry [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:43 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic At 06:15 PM 11/24/2003 +0100, you wrote: Tim Funk wrote: This means that the logout check is now back in, the revert from 1.6 - 1.7 for bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23764 Diff link: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src /share/org/apache/catalina/authenticator/SingleSignOn.java.diff?r1=1.6r 2=1.7diff_format=h Just an FYI, at this point, I don't know if that is good, bad, or neither. That's true. Maybe Brian can explain why he removed this (otherwise, I'll reapply the fix). No, my mistake. It didn't intend to change anything related to session invalidation and didn't notice it in the diff. :( Since the logout feature no longer is there, this means bug 9077 still applies to TC5. Is anyone aware of any issue with the proposed patch attached to that bug? Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24944] - jasper writes temp files to directory TC started from
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=24944. 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=24944 jasper writes temp files to directory TC started from [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 18:04 --- *** This bug has been marked as a duplicate of 18485 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18485] - Jasper tries to write something directly to $CATALINA_HOME
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=18485. 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=18485 Jasper tries to write something directly to $CATALINA_HOME [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 18:04 --- *** Bug 24944 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic
At 11:56 AM 11/24/2003 -0600, you wrote: I have tried applying the patch, and I found three problems with it. First, its removal of a session from the SingleSignOnEntry object causes an IndexOutOfBounds exception. Second, the method for determining whether the user explicitly logged out or whether a session timed out doesn't scale one of the numbers correctly (i.e. comparing millisecond values to seconds). I have fixed the patch, but I don't have a diff of it yet (I'm new to helping with this project). Finally, the patch doesn't synchronize on 'reverse' when removing an entry from it. I also looked at the code for StandardSession.getLastAccessedTime() and it looks as if it will throw an IllegalStateException if the session is expired. So that would break the algorithm used in the 9077 patch. BTW, the javadoc for javax.servlet.http.HttpSession doesn't specify throwing an IllegalStateException for a call to getLastAccessedTime(). It looks as if the exception throw was added in response to bug 15967, which stated that the javadoc does specify the exception, but I'm looking at the javadoc for both Servlet 2.3 and 2.4, and in both cases it's not specified. Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Non beta version of TC5?
Hi, When would a non-beta version of Tomcat 5 be released? Thanks, /s __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic
Brian Stansberry wrote: At 11:56 AM 11/24/2003 -0600, you wrote: I have tried applying the patch, and I found three problems with it. First, its removal of a session from the SingleSignOnEntry object causes an IndexOutOfBounds exception. Second, the method for determining whether the user explicitly logged out or whether a session timed out doesn't scale one of the numbers correctly (i.e. comparing millisecond values to seconds). I have fixed the patch, but I don't have a diff of it yet (I'm new to helping with this project). Finally, the patch doesn't synchronize on 'reverse' when removing an entry from it. I also looked at the code for StandardSession.getLastAccessedTime() and it looks as if it will throw an IllegalStateException if the session is expired. So that would break the algorithm used in the 9077 patch. BTW, the javadoc for javax.servlet.http.HttpSession doesn't specify throwing an IllegalStateException for a call to getLastAccessedTime(). It looks as if the exception throw was added in response to bug 15967, which stated that the javadoc does specify the exception, but I'm looking at the javadoc for both Servlet 2.3 and 2.4, and in both cases it's not specified. Hum...look at: http://java.sun.com/j2ee/1.4/docs/api/index.html quote getLastAccessedTime public long *getLastAccessedTime*() [.] *Returns:* a |long| representing the last time the client sent a request associated with this session, expressed in milliseconds since 1/1/1970 GMT *Throws:* |IllegalStateException http://java.sun.com/j2se/1.4/docs/api/java/lang/IllegalStateException.html| - if this method is called on an invalidated session /quote -- Jeanfrancois Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic
Brian Stansberry wrote: At 11:56 AM 11/24/2003 -0600, you wrote: I have tried applying the patch, and I found three problems with it. First, its removal of a session from the SingleSignOnEntry object causes an IndexOutOfBounds exception. Second, the method for determining whether the user explicitly logged out or whether a session timed out doesn't scale one of the numbers correctly (i.e. comparing millisecond values to seconds). I have fixed the patch, but I don't have a diff of it yet (I'm new to helping with this project). Finally, the patch doesn't synchronize on 'reverse' when removing an entry from it. I also looked at the code for StandardSession.getLastAccessedTime() and it looks as if it will throw an IllegalStateException if the session is expired. So that would break the algorithm used in the 9077 patch. BTW, the javadoc for javax.servlet.http.HttpSession doesn't specify throwing an IllegalStateException for a call to getLastAccessedTime(). It looks as if the exception throw was added in response to bug 15967, which stated that the javadoc does specify the exception, but I'm looking at the javadoc for both Servlet 2.3 and 2.4, and in both cases it's not specified. Can you address those issues ASAP ? (incl the array out of bounds and the sync issue) Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] J2EE release
Sun has released the new J2EE RI, but not the specifications (no wonder they are first with an implementation ...). Assuming the specs are also released today, I will tag 5.0.15 tomorrow. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic
At 02:08 PM 11/24/2003 -0500, you wrote: Brian Stansberry wrote: BTW, the javadoc for javax.servlet.http.HttpSession doesn't specify throwing an IllegalStateException for a call to getLastAccessedTime(). It looks as if the exception throw was added in response to bug 15967, which stated that the javadoc does specify the exception, but I'm looking at the javadoc for both Servlet 2.3 and 2.4, and in both cases it's not specified. Hum...look at: http://java.sun.com/j2ee/1.4/docs/api/index.html quote getLastAccessedTime public long *getLastAccessedTime*() [.] *Returns:* a |long| representing the last time the client sent a request associated with this session, expressed in milliseconds since 1/1/1970 GMT *Throws:* |IllegalStateException http://java.sun.com/j2se/1.4/docs/api/java/lang/IllegalStateException.html| - if this method is called on an invalidated session /quote Oh, OK. The Servlet 2.4 javadoc I was looking at was downloaded from the JSR-154 Proposed Final Draft 3 web page (http://jcp.org/aboutJava/communityprocess/first/jsr154/index3.html). The throws tag is not included there. Hopefully they'll make this clear when they issue the final J2EE 1.4 spec. Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23811] - Erratic The servlet container is temporary unavailable or being upgraded message
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=23811. 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=23811 Erratic The servlet container is temporary unavailable or being upgraded message [EMAIL PROTECTED] changed: What|Removed |Added Version|Unknown |4.1.29 --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 19:48 --- I am using Tomcat 4.1.29 with newest version of mod_jk2. I am receiving the same kind of behavior. This is with the simplest setup... no jni, just the channelSocket and very moderate load. [Mon Nov 24 14:23:54 2003] [error] workerEnv.processCallbacks() Error reading reply [Mon Nov 24 14:23:54 2003] [error] ajp13.service() ajpGetReply recoverable error 12 [Mon Nov 24 14:24:29 2003] [error] channelSocket.receive(): Error receiving message body -1 11 Resource temporarily unavailable [Mon Nov 24 14:24:29 2003] [error] workerEnv.processCallbacks() Error reading reply [Mon Nov 24 14:24:29 2003] [error] ajp13.service() ajpGetReply recoverable error 12 [Mon Nov 24 14:24:32 2003] [error] channelSocket.receive(): Error receiving message body -1 11 Resource temporarily unavailable [Mon Nov 24 14:26:23 2003] [error] ajp13.service() ajpGetReply recoverable error 3 [Mon Nov 24 14:26:24 2003] [error] ajp13.service() ajpGetReply recoverable error 3 [Mon Nov 24 14:26:24 2003] [error] ajp13.service() Error forwarding ajp13:localhost:8009 1 0 [Mon Nov 24 14:26:24 2003] [error] mod_jk.handler() Error connecting to tomcat 3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] J2EE release
Hi Remy, How close is 5.0.15 to a non-beta Tomcat release? Thanks, /s --- Remy Maucherat [EMAIL PROTECTED] wrote: Sun has released the new J2EE RI, but not the specifications (no wonder they are first with an implementation ...). Assuming the specs are also released today, I will tag 5.0.15 tomorrow. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9077] - SingleSignOn and session invalidate
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=9077. 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=9077 SingleSignOn and session invalidate --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 20:04 --- Created an attachment (id=9266) Proposed fixes to previous attachment - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9077] - SingleSignOn and session invalidate
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=9077. 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=9077 SingleSignOn and session invalidate --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 20:09 --- I just added a new attachment that fixes three problems with the attachment dated 04/29/03 22:54: 1) The comparison on the timeout was comparing seconds to milliseconds. Added a scaling factor of 1000 to compensate. 2) A value was removed from the reverse map with being called in a synchronized block. Added a synchronized block on reverse. 3) Removing a session from the SingleSignOnEntry was causing an IndexOutOfBounds exception. Added logic to test more carefully how to resize the array. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SingleSignOn.java
remm2003/11/24 12:22:54
Modified:catalina/src/share/org/apache/catalina/authenticator
SingleSignOn.java
Log:
- Reapply fix for bug 23764.
Revision ChangesPath
1.9 +7 -12
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java
Index: SingleSignOn.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- SingleSignOn.java 24 Nov 2003 16:46:56 - 1.8
+++ SingleSignOn.java 24 Nov 2003 20:22:54 - 1.9
@@ -376,14 +376,9 @@
if (ssoId == null)
return;
-if ( event.getData() != null
- logout.equals( event.getData().toString() )) {
-// logout of all applications
-deregister(ssoId);
-} else {
-// invalidate just one session
-deregister(ssoId, session);
-}
+// FIXME: Find a way to deregister only a single session in case of
+// a timeout
+deregister(ssoId, session);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic
At 08:21 PM 11/24/2003 +0100, Remy wrote:
Brian Stansberry wrote:
At 11:56 AM 11/24/2003 -0600, Luke Nelson wrote:
I have tried applying the patch, and I found three problems with
it. First, its removal of a session from the SingleSignOnEntry
object causes an IndexOutOfBounds exception. Second, the method
for determining whether the user explicitly logged out or whether a
session timed out doesn't scale one of the numbers correctly (i.e.
comparing millisecond values to seconds). I have fixed the patch,
but I don't have a diff of it yet (I'm new to helping with this
project). Finally, the patch doesn't synchronize on 'reverse' when
removing an entry from it.
I also looked at the code for StandardSession.getLastAccessedTime()
and it looks as if it will throw an IllegalStateException if the
session is expired. So that would break the algorithm used in the
9077 patch.
BTW, the javadoc for javax.servlet.http.HttpSession doesn't specify
throwing an IllegalStateException for a call to
getLastAccessedTime(). It looks as if the exception throw was added
in response to bug 15967, which stated that the javadoc does specify
the exception, but I'm looking at the javadoc for both Servlet 2.3
and 2.4, and in both cases it's not specified.
Can you address those issues ASAP ? (incl the array out of bounds and the sync issue)
Sure; I'm starting on it now. However, Jean-Francois found a HttpSession javadoc that
specifies throwing an IllegalStateException in getLastAccessedTime(). If that is in
the final spec, the 9077 patch algorithm will not work. I'll work on it anyway in
case the exception's not in the final spec.
As a backup, I've attached a patch that restores your earlier removal of the logout
code.
Brian Stansberry
WAN Concepts, Inc.
www.wanconcepts.com
Tel:(510) 894-0114 x 116
Fax:(510) 797-3005 Index: SingleSignOn.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java,v
retrieving revision 1.8
diff -u -r1.8 SingleSignOn.java
--- SingleSignOn.java 24 Nov 2003 16:46:56 - 1.8
+++ SingleSignOn.java 24 Nov 2003 20:14:10 -
@@ -376,7 +376,11 @@
if (ssoId == null)
return;
-if ( event.getData() != null
+deregister(ssoId);
+// FIXME: There's no way right now to specify per application or
+// global logout
+/*
+if ( event.getData() != null
logout.equals( event.getData().toString() )) {
// logout of all applications
deregister(ssoId);
@@ -384,6 +388,7 @@
// invalidate just one session
deregister(ssoId, session);
}
+*/
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAut
Nelson, Luke wrote: Brian, I believe I just fixed those issues. See the latest patch to 9077. Did you actually test it ? Your patch calls getLastModified, does this really work if the session *did* timeout (and as such is no longer valid) ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAut
I tested it and it didn't throw the exception indicated earlier in this thread. I would rather this part of the patch be replaced with something more robust. There really isn't a need to test for the timeout as we should be able to know how the session expired by the session itself providing that information. Luke -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 1:49 PM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat- catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAut Nelson, Luke wrote: Brian, I believe I just fixed those issues. See the latest patch to 9077. Did you actually test it ? Your patch calls getLastModified, does this really work if the session *did* timeout (and as such is no longer valid) ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat sessions at ApacheCon
Quoting Remy Maucherat [EMAIL PROTECTED]: * Performance and optimization (Glenn) * JSP 2.0 (Mark Roth) - well, not really about TC * Jasper from TC 5 (Kin-Man) * TC 5 new features (JF + Craig) - Craig has had nothing to do with TC for a while, I wonder what he'll be talking about Basically I was just a fill-in speaker for J-F's session on new Catalina features. Slides are at: http://www.apache.org/~craigmcc/ Craig * Building desktops apps with TC (Will Iverson) - something original, woohoo :) * Various other vaguely related sessions It could be useful to post online the slides for the first four sessions in a few days, if possible :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: catalina.policy to avoid no object DCH for MIME...
Hi, Thank you for your reply. This is a special use case depending on where you install the mail API jars. Since there are potentially 1000's of special use cases I don't see where adding these examples to catalina.policy would help. A better solution would be to add a section to the Tomcat SecurityManager doc which lists what permissions are required for different standard API's. JDBC, mail, etc. That's a good idea. I'll try it. I just downloaded: security-manager-howto.xml from CVS. I think I should work on this XML, rather than the HTML. After the section titled: h3Policy File Format/h3 I'll add the new section titled: h3Required Permissions for standard API's/h3 The new section will list the required permissions for JDBC and JavaMail. I have ever experienced the difficulties in Java Advanced Imaging API with SecurityManager, and so I'll also list the required permission for it. I'll work on it in the next weekend. Any suggestions are welcome to me. Best regards, -- Happy Java programming! Jun Inamori OOP-Reserch Corporation E-mail: [EMAIL PROTECTED] URL:http://www.oop-reserch.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
9077 Patch
Did you actually test it ? Rémy, I started two of my jsp applications. Logged into one, then accessed the other (which automatically signs me in because of the SingleSignOn.) Waited for one minute (my timeout interval), and the sessions expired without throwing any exceptions. Next, I logged in again under both applications (the same as before), but manually logged out by invalidating the session. Again, no exception were thrown. To be fair, I'm using Tomcat 4.1.27 with a few patches applied. I do not know how this would behave in Tomcat 5.0. Hopefully Brian can take the patch I added, and test it under 5.0 since he indicated he was available to make the change. Luke -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 1:49 PM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat- catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAut Nelson, Luke wrote: Brian, I believe I just fixed those issues. See the latest patch to 9077. Did you actually test it ? Your patch calls getLastModified, does this really work if the session *did* timeout (and as such is no longer valid) ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SingleSignOn.java
remm2003/11/24 13:28:22 Modified:catalina/src/share/org/apache/catalina/authenticator SingleSignOn.java Log: - Oops. Unregister the whole session. Revision ChangesPath 1.10 +5 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java Index: SingleSignOn.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- SingleSignOn.java 24 Nov 2003 20:22:54 - 1.9 +++ SingleSignOn.java 24 Nov 2003 21:28:22 - 1.10 @@ -378,7 +378,7 @@ // FIXME: Find a way to deregister only a single session in case of // a timeout -deregister(ssoId, session); +deregister(ssoId); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 9077 Patch
Nelson, Luke wrote: Did you actually test it ? Rémy, I started two of my jsp applications. Logged into one, then accessed the other (which automatically signs me in because of the SingleSignOn.) Waited for one minute (my timeout interval), and the sessions expired without throwing any exceptions. Next, I logged in again under both applications (the same as before), but manually logged out by invalidating the session. Again, no exception were thrown. To be fair, I'm using Tomcat 4.1.27 with a few patches applied. I do not know how this would behave in Tomcat 5.0. Hopefully Brian can take the patch I added, and test it under 5.0 since he indicated he was available to make the change. That would be good. I can apply a verified TC 5 patch tomorrow if you can post one. Otherwise, the issue won't be fixed in 5.0.15. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
jfarcand2003/11/24 13:48:27 Modified:catalina/src/share/org/apache/catalina/core ApplicationContext.java Log: When calling ServletContext.log, append the application's name so we know from which application the log is coming. Feel free to revert if it breaks something. Revision ChangesPath 1.21 +7 -7 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java Index: ApplicationContext.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- ApplicationContext.java 4 Sep 2003 17:45:40 - 1.20 +++ ApplicationContext.java 24 Nov 2003 21:48:27 - 1.21 @@ -665,7 +665,7 @@ Logger logger = context.getLogger(); if (logger != null) -logger.log(message); +logger.log(context.logName() + message); } @@ -683,7 +683,7 @@ Logger logger = context.getLogger(); if (logger != null) -logger.log(exception, message); +logger.log(exception, context.logName() + message); } @@ -698,7 +698,7 @@ Logger logger = context.getLogger(); if (logger != null) -logger.log(message, throwable); +logger.log(context.logName() + message, throwable); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24954] New: - Removing web application at context path /jaxrpc-VoteService by tomcat manager
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=24954. 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=24954 Removing web application at context path /jaxrpc-VoteService by tomcat manager Summary: Removing web application at context path /jaxrpc- VoteService by tomcat manager Product: Tomcat 4 Version: 4.1.29 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Tomcat manager removes deployment jaxrpc immediately after deployment. After I deployed my war file by dropping to webapps dir or thru deployment tool, my deployement is removed immediatelly when I call tomcat manager from the browser. Removing web application at context path /jaxrpc-VoteService After deployment! the following is message from log file 2003-11-24 14:02:11 HostConfig[localhost]: Expanding web application archive jaxrpc-VoteService.war 2003-11-24 14:02:11 StandardHost[localhost]: Installing web application at context path /jaxrpc-VoteService from URL file:c:/tomcat-4.1.29/webapps/jaxrpc- VoteService 2003-11-24 14:02:11 WebappLoader[/jaxrpc-VoteService]: Deploying class repositories to work directory C:\tomcat-4.1.29 \work\Standalone\localhost\jaxrpc-VoteService 2003-11-24 14:02:11 WebappLoader[/jaxrpc-VoteService]: Deploy class files /WEB- INF/classes to c:\tomcat-4.1.29\webapps\jaxrpc-VoteService\WEB-INF\classes 2003-11-24 14:02:11 WebappLoader[/jaxrpc-VoteService]: Deploy JAR /WEB- INF/lib/RmiJdbc.jar to c:\tomcat-4.1.29\webapps\jaxrpc-VoteService\WEB- INF\lib\RmiJdbc.jar 2003-11-24 14:02:11 WebappLoader[/jaxrpc-VoteService]: Deploy JAR /WEB- INF/lib/cloudclient.jar to c:\tomcat-4.1.29\webapps\jaxrpc-VoteService\WEB- INF\lib\cloudclient.jar 2003-11-24 14:02:11 WebappLoader[/jaxrpc-VoteService]: Deploy JAR /WEB- INF/lib/jdbc_inet.jar to c:\tomcat-4.1.29\webapps\jaxrpc-VoteService\WEB- INF\lib\jdbc_inet.jar 2003-11-24 14:02:11 StandardManager[/jaxrpc-VoteService]: Seeding random number generator class java.security.SecureRandom 2003-11-24 14:02:11 StandardManager[/jaxrpc-VoteService]: Seeding of random number generator has been completed 2003-11-24 14:02:11 StandardWrapper[/jaxrpc-VoteService:default]: Loading container servlet default 2003-11-24 14:02:11 StandardWrapper[/jaxrpc-VoteService:invoker]: Loading container servlet invoker Removal section 2003-11-24 14:03:53 StandardWrapper[/manager:HTMLManager]: Loading container servlet HTMLManager 2003-11-24 14:03:53 HTMLManager: init: Associated with Deployer 'localhost' 2003-11-24 14:03:53 HTMLManager: init: Global resources are available 2003-11-24 14:03:53 HTMLManager: remove: Removing web application at '/jaxrpc- VoteService' 2003-11-24 14:03:53 StandardHost[localhost]: Removing web application at context path /jaxrpc-VoteService 2003-11-24 14:03:54 HTMLManager: list: Listing contexts for virtual host 'localhost' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24956] New: - Removing web application at context path /jaxrpc-VoteService by tomcat manager
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=24956. 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=24956 Removing web application at context path /jaxrpc-VoteService by tomcat manager Summary: Removing web application at context path /jaxrpc- VoteService by tomcat manager Product: Tomcat 4 Version: 4.1.29 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Tomcat manager removes deployment jaxrpc immediately after deployment. After I deployed my war file by dropping to webapps dir or thru deployment tool, my deployement is removed immediatelly when I call tomcat manager from the browser. Removing web application at context path /jaxrpc-VoteService After deployment! the following is message from log file 2003-11-24 14:02:11 HostConfig[localhost]: Expanding web application archive jaxrpc-VoteService.war 2003-11-24 14:02:11 StandardHost[localhost]: Installing web application at context path /jaxrpc-VoteService from URL file:c:/tomcat-4.1.29/webapps/jaxrpc- VoteService 2003-11-24 14:02:11 WebappLoader[/jaxrpc-VoteService]: Deploying class repositories to work directory C:\tomcat-4.1.29 \work\Standalone\localhost\jaxrpc-VoteService 2003-11-24 14:02:11 WebappLoader[/jaxrpc-VoteService]: Deploy class files /WEB- INF/classes to c:\tomcat-4.1.29\webapps\jaxrpc-VoteService\WEB-INF\classes 2003-11-24 14:02:11 WebappLoader[/jaxrpc-VoteService]: Deploy JAR /WEB- INF/lib/RmiJdbc.jar to c:\tomcat-4.1.29\webapps\jaxrpc-VoteService\WEB- INF\lib\RmiJdbc.jar 2003-11-24 14:02:11 WebappLoader[/jaxrpc-VoteService]: Deploy JAR /WEB- INF/lib/cloudclient.jar to c:\tomcat-4.1.29\webapps\jaxrpc-VoteService\WEB- INF\lib\cloudclient.jar 2003-11-24 14:02:11 WebappLoader[/jaxrpc-VoteService]: Deploy JAR /WEB- INF/lib/jdbc_inet.jar to c:\tomcat-4.1.29\webapps\jaxrpc-VoteService\WEB- INF\lib\jdbc_inet.jar 2003-11-24 14:02:11 StandardManager[/jaxrpc-VoteService]: Seeding random number generator class java.security.SecureRandom 2003-11-24 14:02:11 StandardManager[/jaxrpc-VoteService]: Seeding of random number generator has been completed 2003-11-24 14:02:11 StandardWrapper[/jaxrpc-VoteService:default]: Loading container servlet default 2003-11-24 14:02:11 StandardWrapper[/jaxrpc-VoteService:invoker]: Loading container servlet invoker Removal section 2003-11-24 14:03:53 StandardWrapper[/manager:HTMLManager]: Loading container servlet HTMLManager 2003-11-24 14:03:53 HTMLManager: init: Associated with Deployer 'localhost' 2003-11-24 14:03:53 HTMLManager: init: Global resources are available 2003-11-24 14:03:53 HTMLManager: remove: Removing web application at '/jaxrpc- VoteService' 2003-11-24 14:03:53 StandardHost[localhost]: Removing web application at context path /jaxrpc-VoteService 2003-11-24 14:03:54 HTMLManager: list: Listing contexts for virtual host 'localhost' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
amyroh 2003/11/24 15:01:22
Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
Add getters for all attributes defined in MBeanInfo so getAttribute calls suceed.
Revision ChangesPath
1.44 +143 -14
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- Http11Protocol.java 17 Nov 2003 09:42:40 - 1.43
+++ Http11Protocol.java 24 Nov 2003 23:01:21 - 1.44
@@ -264,20 +264,36 @@
// Pool setup
+public boolean getPools(){
+return ep.isPoolOn();
+}
+
public void setPools( boolean t ) {
ep.setPoolOn(t);
setAttribute(pools, + t);
}
+public int getMaxThreads() {
+return ep.getMaxThreads();
+}
+
public void setMaxThreads( int maxThreads ) {
ep.setMaxThreads(maxThreads);
setAttribute(maxThreads, + maxThreads);
}
+public int getMaxSpareThreads() {
+return ep.getMaxSpareThreads();
+}
+
public void setMaxSpareThreads( int maxThreads ) {
ep.setMaxSpareThreads(maxThreads);
setAttribute(maxSpareThreads, + maxThreads);
}
+
+public int getMinSpareThreads() {
+return ep.getMinSpareThreads();
+}
public void setMinSpareThreads( int minSpareThreads ) {
ep.setMinSpareThreads(minSpareThreads);
@@ -286,11 +302,19 @@
// Tcp setup
+public int getBacklog() {
+return ep.getBacklog();
+}
+
public void setBacklog( int i ) {
ep.setBacklog(i);
setAttribute(backlog, + i);
}
+public int getPort() {
+return ep.getPort();
+}
+
public void setPort( int port ) {
ep.setPort(port);
setAttribute(port, + port);
@@ -301,123 +325,223 @@
ep.setAddress( ia );
setAttribute(address, + ia);
}
-
-public void setHostName( String name ) {
+
+// commenting out for now since it's not doing anything
+//public void setHostName( String name ) {
// ??? Doesn't seem to be used in existing or prev code
// vhost=name;
-}
+//}
+public String getSocketFactory() {
+return socketFactoryName;
+}
+
public void setSocketFactory( String valueS ) {
socketFactoryName = valueS;
setAttribute(socketFactory, valueS);
}
-
+
+public String getSSLImplementation() {
+return sslImplementationName;
+}
+
public void setSSLImplementation( String valueS) {
sslImplementationName = valueS;
setAttribute(sslImplementation, valueS);
}
+public boolean getTcpNoDelay() {
+return ep.getTcpNoDelay();
+}
+
public void setTcpNoDelay( boolean b ) {
ep.setTcpNoDelay( b );
setAttribute(tcpNoDelay, + b);
}
+public boolean getDisableUploadTimeout() {
+return disableUploadTimeout;
+}
+
public void setDisableUploadTimeout(boolean isDisabled) {
disableUploadTimeout = isDisabled;
}
+public int getSocketBuffer() {
+return socketBuffer;
+}
+
public void setSocketBuffer(int valueI) {
socketBuffer = valueI;
}
+public String getCompression() {
+return compression;
+}
+
public void setCompression(String valueS) {
compression = valueS;
setAttribute(compression, valueS);
}
+public int getMaxPostSize() {
+return maxPostSize;
+}
+
public void setMaxPostSize(int valueI) {
maxPostSize = valueI;
setAttribute(maxPostSize, + valueI);
}
+public String getRestrictedUserAgents() {
+return restrictedUserAgents;
+}
+
public void setRestrictedUserAgents(String valueS) {
restrictedUserAgents = valueS;
setAttribute(restrictedUserAgents, valueS);
}
+public String getNoCompressionUserAgents() {
+return noCompressionUserAgents;
+}
+
public void setNoCompressionUserAgents(String valueS) {
noCompressionUserAgents = valueS;
setAttribute(noCompressionUserAgents, valueS);
}
+public
DO NOT REPLY [Bug 24956] - Removing web application at context path /jaxrpc-VoteService by tomcat manager
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=24956. 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=24956 Removing web application at context path /jaxrpc-VoteService by tomcat manager [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 23:13 --- *** This bug has been marked as a duplicate of 24954 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24954] - Removing web application at context path /jaxrpc-VoteService by tomcat manager
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=24954. 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=24954 Removing web application at context path /jaxrpc-VoteService by tomcat manager --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 23:13 --- *** Bug 24956 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24586] - Compilation error when exposing an Inner class
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=24586. 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=24586 Compilation error when exposing an Inner class --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 23:30 --- Created an attachment (id=9271) changes from tomcat 5 adapted back to tomcat 4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24586] - Compilation error when exposing an Inner class
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=24586. 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=24586 Compilation error when exposing an Inner class --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 23:34 --- This looks very similar to http://nagoya.apache.org/bugzilla/show_bug.cgi? id=22867 which has been fixed in 5. I've attached diffs which are the changes from 5 applied to 4. I've tested the fix as far as it affects inner tag classes. It looks like it fixes beans too, but I haven't explicitly tested that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 9077 Patch
At 10:29 PM 11/24/2003 +0100, you wrote: Nelson, Luke wrote: Hopefully Brian can take the patch I added, and test it under 5.0 since he indicated he was available to make the change. That would be good. I can apply a verified TC 5 patch tomorrow if you can post one. Otherwise, the issue won't be fixed in 5.0.15. Yes, I'm working on this and have integrated Luke's patch w/ the TC5 SSO version. Had to run out and fix a customer's broken network, but I'll be on this the rest of the day. But, the IllegalStateException issue needs to be resolved. Luke, your patch has no problem in TC4 because the IllegalStateException in getLastAccessedTime() was added in TC5. Off the top of my head, I can think of only 1 potential workaround, which is to move the logic that throws the exception to HttpSessionFacade; this complies with the javadoc version that specifies the exception in javax.servlet.http.HttpSession but leaves the method in StandardSession available for internal use anytime. Kind of a hack, and it changes the behavior of the public API of StandardSession. But, the exception throw is not specified in the javadoc for interface o.a.c.Session, and a quick look at the TC5 usages of o.a.c.Session.getLastAccessedTime() shows a few calls to the method that 1) aren't making any obvious tests for session validity before invoking it; and 2) aren't catching IllegalStateException. 1) JDBCStore.save() 2) ManagerBase.getLastAccessedTime() 3) PersistentValve.isSessionStale() Or we can hope the final spec matches the JSR154-PFD3 javadoc, and not the J2EE1.4 docs on the Sun site ;-) Any thoughts? Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24957] New: - EL treates operators as functions
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=24957.
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=24957
EL treates operators as functions
Summary: EL treates operators as functions
Product: Tomcat 5
Version: 5.0.14
Platform: Sun
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The JSP/EL language is incorrectly treating operator keywords (such as 'and'
'or' 'mod' and so on) as functions when the expression on the right of the
operator is a parenthetical expression.
For example: ${7 div (3 + 2)} gives a translation error because it thinks
that 'div' should be treated as a function (but it cannot find the declaration
of that function).
I have a test webapp that I will submit.
-Bryan Basham
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JspDocumentParser.java
kinman 2003/11/24 15:51:10
Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java
Log:
- Fix 24779: Jasper fails to compile a valid JSP document (xml syntax) when
an EL string in template text contains a []. The fix to to buffer and
concatenate template text strings and only start processing the texts when
they are all in one piece.
This, BTW, also fixes the bug that somestimes trims the white spaces that
trails template texts.
Revision ChangesPath
1.72 +42 -15
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.71
retrieving revision 1.72
diff -u -r1.71 -r1.72
--- JspDocumentParser.java22 Nov 2003 02:09:34 - 1.71
+++ JspDocumentParser.java24 Nov 2003 23:51:10 - 1.72
@@ -90,6 +90,7 @@
* syntax.
*
* @author Jan Luehe
+ * @author Kin-man Chung
*/
class JspDocumentParser
@@ -110,6 +111,7 @@
private JspCompilationContext ctxt;
private PageInfo pageInfo;
private String path;
+private StringBuffer charBuffer;
// Node representing the XML element currently being parsed
private Node current;
@@ -287,6 +289,8 @@
AttributesImpl nonTaglibAttrs = null;
AttributesImpl nonTaglibXmlnsAttrs = null;
+processChars();
+
checkPrefixes(uri, qName, attrs);
if (directivesOnly
@@ -399,14 +403,33 @@
/*
* Receives notification of character data inside an element.
*
+ * The SAX does not call this method with all of the template text, but may
+ * invoke this method with chunks of it. This is a problem when we try
+ * to determine if the text contains only whitespaces, or when we are
+ * looking for an EL expression string. Therefore it is necessary to
+ * buffer and concatenate the chunks and process the concatenated text
+ * later (at beginTag and endTag)
+ *
* @param buf The characters
* @param offset The start position in the character array
* @param len The number of characters to use from the character array
*
* @throws SAXException
*/
-public void characters(char[] buf, int offset, int len)
-throws SAXException {
+public void characters(char[] buf, int offset, int len) {
+
+if (charBuffer == null) {
+charBuffer = new StringBuffer();
+}
+charBuffer.append(buf, offset, len);
+}
+
+private void processChars() throws SAXException {
+
+if (charBuffer == null) {
+return;
+}
+
/*
* JSP.6.1.1: All textual nodes that have only white space are to be
* dropped from the document, except for nodes in a jsp:text element,
@@ -418,11 +441,11 @@
boolean isAllSpace = true;
if (!(current instanceof Node.JspText)
!(current instanceof Node.NamedAttribute)) {
-for (int i = offset; i offset + len; i++) {
-if (!(buf[i] == ' '
-|| buf[i] == '\n'
-|| buf[i] == '\r'
-|| buf[i] == '\t')) {
+for (int i = 0; i charBuffer.length(); i++) {
+if (!(charBuffer.charAt(i) == ' '
+|| charBuffer.charAt(i) == '\n'
+|| charBuffer.charAt(i) == '\r'
+|| charBuffer.charAt(i) == '\t')) {
isAllSpace = false;
break;
}
@@ -436,10 +459,10 @@
int column = startMark.getColumnNumber();
CharArrayWriter ttext = new CharArrayWriter();
-int limit = offset + len;
int lastCh = 0;
-for (int i = offset; i limit; i++) {
-int ch = buf[i];
+for (int i = 0; i charBuffer.length(); i++) {
+
+int ch = charBuffer.charAt(i);
if (ch == '\n') {
column = 1;
line++;
@@ -463,7 +486,7 @@
boolean doubleQ = false;
lastCh = 0;
for (;; i++) {
-if (i = limit) {
+if (i = charBuffer.length()) {
throw new SAXParseException(
Localizer.getMessage(
jsp.error.unterminated,
@@ -471,7 +494,7 @@
locator);
}
-
DO NOT REPLY [Bug 24957] - EL treates operators as functions
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=24957. 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=24957 EL treates operators as functions --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 23:54 --- Created an attachment (id=9272) test webapp for failure of EL operators - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Justification for URIEncoding addition?
Remy Maucherat wrote: Hans Bergsten wrote: Larry Isaacs wrote: Hans, The behavior change is unrelated to the use of getParameter() to search for jsp_precompile. Both Tomcat 3.x and Tomcat 4.x were bit by this log ago and Craig's fix was applied to both. In Tomcat 4's case, it was prior to the 4.0 release. Okay, I'm sure you're right that there may be more to it than avoiding the getParameter() call in Jasper, but based on what I've read, it seems to be part of the problem at least. Assuming I have a good grip on the issue, I think it relates to using UTF-8 to decode the path portion of the URL which gets used to determine context, servlet mapping, etc. Then allowing setCharacterEncoding() to change the character encoding for the query portion of the same URL. The Servlet 2.3 and 2.4 specs both say setCharacterEncoding() applies to the request body but don't mention it applying to the query portion of the URL. Right, but since the servlet spec doesn't say anything about encoding for the query portion, I think we have some room for a sensible interpretation. My concern is that with the new decoding behavior, apps that used to work fine suddenly don't, and the reason seems to be that browsers in fact ignore the RFC2718 recommendation that TC now enforces. I'm all for compliance with all related specs, but in this case it's just a recommendation and following it seems to do more harm than good. I agree it's not as clean as you may want, but are there any real problems with decoding the path portion using one charset and the query string with another (i.e., the one from getCharacterEncoding()), the way it used to be done? I see you as a member of the expert group for the servlet spec. Did you make out those points during the review period ? If not, then you IMO have nothing to complain about, esp since Tomcat implements a far more reasonable and simpler behavior for the URL string handling. Remy, I'm not complaining, I'm just trying to help with ideas for how solve a problem that apparently affects a lot of people. Sigh! Yes, I'm in the servlet spec EG and I did help solving other i18n problems by bringing together all the spec leads for servlets, JSP and JSTL and Sun's i18n guru to fix inconsistencies between these specs. Unfortunately, I missed the query string encoding problem, largely because the way TC handled it before the recent change seemed to work for most apps so I hadn't encountered the problem. My bad. The specification should have specified something along the lines of: - The URL must be %xx encoded - This decodes to bytes reprensenting UTF-8 characters There's an IETF standard that, I think, states this in BW. It is being ignored. Maybe this wouldn't be the case if very popular tech, such as servlets JSPs, started mandating it ? This is simply a chiken egg issue. And because its a chicken and egg problem, I doubt that it will ever be solved. No server vendor is likely to change the behavior in a way that's incompatible with a large set of browsers. A more sensible way to solve this would be for W3C to change the spec to require the behavior most browsers already implement, even if it's less elegant. i18n issues with HTTP and srevlets have been known about for years, but unfortunately they still haven't been addressed properly. Same with the request dispatcher + wrapping issues that I have pointed out months ago (and of course, were silently ignored). To balance this a little, among the other big issues, I have to give credit for solving the welcome files in a satisfactory way, as well as filters with RDs. Filters now make the proprietary APIs provided by the container irrelevant for most tasks. I'm glad you like something in the new spec ;-) Although, there's more to be done with the welcome file mechanism. I tried to get it all done in 2.4, but we couldn't reach consensus so what there now is still too vague, IMHO. Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 2.0 and JSTL 1.1 Details athttp://TheJSPBook.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24739] - Control of secure flag when establishing sessions through https using cookies
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=24739. 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=24739 Control of secure flag when establishing sessions through https using cookies [EMAIL PROTECTED] changed: What|Removed |Added Severity|Minor |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-11-25 00:41 --- Tomcat 4 (and 5) work this way to protect sessions created in SSL from being at risk of session hijacking if transferred back to http. That being said, there have been a number of requests for this type of functionality on tomcat- user. As this is not strictly a bug, I am setting it to an enhancement request. Until such time as a patch is written, using something similar to the following in your jsp will provide a work-around. A HREF=http://localhost:8080/bug24739/display.jsp;jsessionid=%=session.getId ()%display session cookie(http)/A Obviously, you will need to replace http://localhost:8080/bug24739/display.jsp; with something appropriate to your environment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24779] - Jasper fails to parse correct XML syntax JSP page with certain EL expressions.
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=24779. 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=24779 Jasper fails to parse correct XML syntax JSP page with certain EL expressions. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-25 01:03 --- Fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Protocol.java
amyroh 2003/11/24 17:26:26
Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
Log:
Put unused methods back in comments -- accidently removed /* earlier.
Revision ChangesPath
1.45 +7 -6
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- Http11Protocol.java 24 Nov 2003 23:01:21 - 1.44
+++ Http11Protocol.java 25 Nov 2003 01:26:26 - 1.45
@@ -321,6 +321,10 @@
//this.port=port;
}
+public InetAddress getAddress() {
+return ep.getAddress();
+}
+
public void setAddress(InetAddress ia) {
ep.setAddress( ia );
setAttribute(address, + ia);
@@ -774,11 +778,7 @@
}
}
-
-public InetAddress getAddress() {
-return ep.getAddress();
-}
-
+/*
public boolean isKeystoreSet() {
return (attributes.get(keystore) != null);
}
@@ -802,7 +802,8 @@
public PoolTcpEndpoint getEndpoint() {
return ep;
}
-
+*/
+
protected String domain;
protected ObjectName oname;
protected MBeanServer mserver;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17323] - Cancelled SSL connections cause Tomcat to stumble
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=17323. 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=17323 Cancelled SSL connections cause Tomcat to stumble --- Additional Comments From [EMAIL PROTECTED] 2003-11-25 01:29 --- Which build has this been fixed in? It still seems to occur in Tomcat 4.1.27. Is there a patch or workaround available without going to a nightly build? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler ELParser.java
kinman 2003/11/24 17:38:21
Modified:jasper2/src/share/org/apache/jasper/compiler ELParser.java
Log:
- Fix 24957: Operators are mis-treated as functions
Revision ChangesPath
1.3 +27 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ELParser.java
Index: ELParser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ELParser.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ELParser.java 30 Oct 2003 02:39:48 - 1.2
+++ ELParser.java 25 Nov 2003 01:38:21 - 1.3
@@ -77,6 +77,11 @@
private String expression; // The EL expression
private boolean escapeBS;// is '\' an escape char in text outside EL?
+private static final String reservedWords[] = {
+and, div, empty, eq, false,
+ge, gt, instanceof, le, lt, mod,
+ne, not, null, or, true};
+
public ELParser(String expression) {
index = 0;
this.expression = expression;
@@ -145,7 +150,7 @@
* Note: currently we don't parse arguments
*/
private boolean parseFunction() {
- if (! (curToken instanceof Id)) {
+ if (! (curToken instanceof Id) || isELReserved(curToken.toString())) {
return false;
}
String s1 = null; // Function prefix
@@ -172,6 +177,27 @@
}
setIndex(mark);
return false;
+}
+
+/**
+ * Test if an id is a reserved word in EL
+ */
+private boolean isELReserved(String id) {
+int i = 0;
+int j = reservedWords.length;
+while (i j) {
+int k = (i+j)/2;
+int result = reservedWords[k].compareTo(id);
+if (result == 0) {
+return true;
+}
+if (result 0) {
+i = k+1;
+} else {
+j = k;
+}
+}
+return false;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24957] - EL treates operators as functions
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=24957. 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=24957 EL treates operators as functions [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-25 01:41 --- Fixed. Thanks for reporting the bug, and for providing the test. If every bug has test as good as this, they'd all have been fixed! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: catalina.policy to avoid no object DCH for MIME...
Jun Inamori wrote: Hi, Thank you for your reply. This is a special use case depending on where you install the mail API jars. Since there are potentially 1000's of special use cases I don't see where adding these examples to catalina.policy would help. A better solution would be to add a section to the Tomcat SecurityManager doc which lists what permissions are required for different standard API's. JDBC, mail, etc. That's a good idea. I'll try it. I just downloaded: security-manager-howto.xml from CVS. I think I should work on this XML, rather than the HTML. Yes, thats the right place. After the section titled: h3Policy File Format/h3 I'll add the new section titled: h3Required Permissions for standard API's/h3 The new section will list the required permissions for JDBC and JavaMail. I have ever experienced the difficulties in Java Advanced Imaging API with SecurityManager, and so I'll also list the required permission for it. I'll work on it in the next weekend. Any suggestions are welcome to me. Best regards, This sounds great. Thanks for taking the initiative to improve the docs. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9077] - SingleSignOn and session invalidate
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=9077. 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=9077 SingleSignOn and session invalidate --- Additional Comments From [EMAIL PROTECTED] 2003-11-25 02:26 --- Created an attachment (id=9275) Previous patch adapted for TC 5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9077] - SingleSignOn and session invalidate
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=9077. 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=9077 SingleSignOn and session invalidate --- Additional Comments From [EMAIL PROTECTED] 2003-11-25 02:43 --- Attached patch adapts Luke Nelson's patch (Thanks Luke!) for TC 5. Of 3 issues Luke mentions, 3rd is not relevant to TC5 as TC 5 code already had a valid algorithm for removing a single session from the SSO entry. Attached also updates StandardSession for 2 reasons: 1) Unlike other similar methods in the class, TC 5's StandardSession.getLastAccessedTime() used field isValid to check for session validity instead of calling isValid(). isValid() will return true during session expiration, allowing SessionEventHandlers to access the session during shutdown. The SingleSignOn patch needs to access getLastAccessedTime() during the session expiration process. 2) The key to the LocalStrings.properties file used in getLastAccessedTime() did not match the properties file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 9077 Patch
At 10:29 PM 11/24/2003 +0100, you wrote: Nelson, Luke wrote: Hopefully Brian can take the patch I added, and test it under 5.0 since he indicated he was available to make the change. That would be good. I can apply a verified TC 5 patch tomorrow if you can post one. Otherwise, the issue won't be fixed in 5.0.15. TC 5 version of patch tested posted to bug 9077. Thanks Luke! Turns out the issue with the IllegalStateException was easily solved; my note attached to the bug report explains. Best, Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24960] New: - CGI module reveals server internals details to all
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=24960. 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=24960 CGI module reveals server internals details to all Summary: CGI module reveals server internals details to all Product: Tomcat 4 Version: 4.1.29 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Servlets:CGI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A request to a context that supports CGI for a CGI script that does not exist results in an error page that includes a whole swag of internal context details. Some of these details, such as context init parameters, may be sensitive (eg passwords). The problem is in org.apache.catalina.servlets.CGIServlet. Its doGet() method calls printServletEnvironment() when (certain) errors occur. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24961] New: - Temporary files marked deleteOnExit not deleted when Tomcat runs as NT Service
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=24961. 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=24961 Temporary files marked deleteOnExit not deleted when Tomcat runs as NT Service Summary: Temporary files marked deleteOnExit not deleted when Tomcat runs as NT Service Product: Tomcat 4 Version: 4.1.29 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've written a simple JSP to illustrate: %@ page contentType=text/html;charset=UTF-8 session=false import=java.io.*% % ServletContext servlet_ctxt = getServletContext(); File temp_directory = (File)servlet_ctxt.getAttribute ( javax.servlet.context.tempdir ); File new_temp_file = File.createTempFile ( test, file, temp_directory ); new_temp_file.deleteOnExit(); % Just make this available to Tomcat, run Tomcat as a console app, and when you CTRL-C to quit Tomcat, those files will disappear. However, do the exact same thing using Tomcat as a service, and when you net stop Apache Tomcat 4.1, those files will still exist. I've found a workaround for my particular use of temp files, but I think that it would be best if this was fixed. I believe the issue relates to how tomcat.exe is killing the Java process, but I'm not entirely sure. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
