DO NOT REPLY [Bug 36756] New: - taglib setter not found when having get, is and set method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36756.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36756
Summary: taglib setter not found when having get, is and set
method
Product: Tomcat 5
Version: 5.0.28
Platform: All
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Hi,
When I add extra attributes in java files, a getName, isName and
setName(String aValue), the setter can not be found. When I remove the
isName, everything works fine.
Scenario:
custom:form readOnly=${readOnly}
...
/custom:form
FormTag.java:
public class FormTag extends TagBase {
private String theReadOnly;
public String getReadOnly() {
return theReadOnly;
}
public boolean isReadOnly() {
return StringUtils.isTrue(getReadOnly());
}
public void setReadOnly(String aReadOnly) {
theReadOnly = aReadOnly;
}
}
This will not work. Removing the isReadOnly method makes everything work fine.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Yoav Shapira wrote: Hi, I'm fine with this WE, or the end of this week. I mean, the previous build was decent already. I just looked at the changelog for 5.5.12, it's a nice collection of stuff. Is Friday OK with everyone? If not, I can do Saturday, but I'd prefer Friday to keep my weekend more free. How about Friday, September 23rd, 2005, at 9am my time (EDT), which is 1300h UTC? (http://www.timeanddate.com/worldclock/converted.html?month=9day=23year=2005hour=9min=0sec=0p1=43p2=0) That should give people a couple of days for scratching any last-minute itches. No problem with that. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
precompile failure for jsr152 examples
With the new tag plugins patch, precompiling the jsp examples fails. The root cause seems to be jsr152/examples/WEB-INF/tagPlugins.xml has the old classes. When I removed the file - everything compiled fine. When I updated jsr152/examples/WEB-INF/tagPlugins.xml with the tagPlugins.xml from jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/tagplugins/jstl/tagPlugins.xml I get weird compile errors: /home/funkman/src/TOMCAT5/buildtc5/jakarta-tomcat-5/build.xml:832: The following error occurred while executing this line: /home/funkman/src/TOMCAT5/buildtc5/jakarta-tomcat-5/build.xml:426: org.apache.jasper.JasperException: Unable to compile class for JSP Generated servlet error: pageContext cannot be resolved I guess at a minimum, jsr152/examples/WEB-INF/tagPlugins.xml needs fixed by removing it or fixing it with the correct classes but I think that requires someone with jsr152 karma. I didn't have time to look into the cause of Generated servlet error: pageContext cannot be resolved Thoughts? -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36540] - pooled cluster replication does not seem ensure synchronized replication in tomcat 5.5.11
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36540. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36540 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-09-21 13:42 --- Its been a while since I ran my test cases, but I will do it again -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: precompile failure for jsr152 examples
Tim Funk wrote: With the new tag plugins patch, precompiling the jsp examples fails. The root cause seems to be jsr152/examples/WEB-INF/tagPlugins.xml has the old classes. When I removed the file - everything compiled fine. When I updated jsr152/examples/WEB-INF/tagPlugins.xml with the tagPlugins.xml from jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/tagplugins/jstl/tagPlugins.xml I get weird compile errors: /home/funkman/src/TOMCAT5/buildtc5/jakarta-tomcat-5/build.xml:832: The following error occurred while executing this line: /home/funkman/src/TOMCAT5/buildtc5/jakarta-tomcat-5/build.xml:426: org.apache.jasper.JasperException: Unable to compile class for JSP Generated servlet error: pageContext cannot be resolved I guess at a minimum, jsr152/examples/WEB-INF/tagPlugins.xml needs fixed by removing it or fixing it with the correct classes but I think that requires someone with jsr152 karma. I didn't have time to look into the cause of Generated servlet error: pageContext cannot be resolved Thoughts? I can't fix it, I don't have karma either. I agree that the best is for now to remove the file. Worst case if nobody has karma, we can exclude the file when building. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34923] - HostConfig fails for relative docBase containing ..
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34923 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
wrowe 2005/09/21 06:59:50
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Fix the JK_NEED test to follow a 1|0 value instead of ifdef
Revision ChangesPath
1.155 +2 -2 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.154
retrieving revision 1.155
diff -u -r1.154 -r1.155
--- mod_jk.c 12 Sep 2005 22:21:31 - 1.154
+++ mod_jk.c 21 Sep 2005 13:59:50 - 1.155
@@ -2433,7 +2433,7 @@
return HTTP_INTERNAL_SERVER_ERROR;
}
-#ifdef JK_NEED_SET_MUTEX_PERMS
+#if JK_NEED_SET_MUTEX_PERMS
rv = unixd_set_global_mutex_perms(jk_log_lock);
if (rv != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, s,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Ack - there was a lingering #ifdef JK_NEED_... which should have been an #if JK_NEED_... - this is fixed in cvs, please retry and thanks for the detailed report! Bill Tim Whittington wrote: Confused me too. Error message is listed below. [exec] cl.exe /nologo /MD /W3 /Zi /O2 /I ..\common /I C:\j2sdk1.4.2_07\include /I C:\j2sdk1.4.2_07\include \win32 /I C:/Program Files/Apache Group/Apache2\include /D NDEBUG /D WIN32 /D _WINDOWS /Fo.\Release\\ /Fd.\R elease\mod_jk_src /FD /c ..\common\jk_worker.c [exec] jk_worker.c [exec] cl.exe @C:\TEMP\nm7CC.tmp [exec] mod_jk.c [exec] mod_jk.c(2437) : warning C4013: 'unixd_set_global_mutex_perms' undefined; assuming extern returning int [exec] link.exe @C:\TEMP\nm7CD.tmp [exec] LINK : fatal error LNK1104: cannot open file 'MSVCRT.lib' [exec] NMAKE : fatal error U1077: 'link.exe' : return code '0x450' [exec] Stop. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r290718 - /tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/WEB-INF/tagPlugins.xml
Author: billbarker Date: Wed Sep 21 07:53:12 2005 New Revision: 290718 URL: http://svn.apache.org/viewcvs?rev=290718view=rev Log: Remove obsolete TagPlugin file Removed: tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/WEB-INF/tagPlugins.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-21 20:44 --- (In reply to comment #95) The attribute collection inside Tomcat's ServletContext implementation was already synchronized, and not subject to corruption. Yeah, but what does the spec say (now)? If it is about as unclear as with the session attribute collection, history will repeat itself: Tomcat or some other container will implement ServletContext attribute collection unsynchronized (because its faster), some people will whine about lockups, spec needs to be changed one more time, container needs to be changed in order to be (new) spec compliant. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.15
Both users tried with CVS head and the patch works for IRIX and Solaris. No objections to releasing. Hi, There has been couple of major bug fixes against 1.2.14, see: http://jakarta.apache.org/tomcat/connectors-doc/changelog.html They have been fixed in the CVS, and since couple of them actually makes 1.2.14 unusable on some platforms like Solaris 2.8 and Irix we need a release. I plan to tag the 1.2.15 by the end of this week, and pursue for a vote next week for this bug-fixing release. Any objections? Regards, Mladen. - 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 36763] New: - Setting content length to 0 in HttpServletResponse causes response to become falsely committed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36763.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36763
Summary: Setting content length to 0 in HttpServletResponse
causes response to become falsely committed
Product: Tomcat 5
Version: 5.0.28
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: minor
Priority: P4
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Overview Description:
Should setting the content length of an HttpServletResponse to 0 cause that
response to become committed?
If yes, then this defect submission is unfounded.
If no, then please consider the following two examples:
Steps to Reproduce:
Create two servlets as described below and examine what results when a GET
request is made to each.
Servlet 1:
res.setStatus(302);
res.setHeader(Location, http://issues.apache.org;);
res.setHeader(Content-length, 0);
(where res is the reference to the HttpServletResponse)
Servlet 2:
res.setHeader(Location, http://issues.apache.org;);
res.setHeader(Content-length, 0);
res.setStatus(302);
Actual Results:
When Servlet 1 is executed, I see:
HTTP/1.x 302 Moved Temporarily
Location: http://issues.apache.org
Content-Length: 0
Date: SomeDate_GMT
Server: Apache-Coyote/1.1
When Servlet 2 is executed, I see:
HTTP/1.x 200 OK
Location: http://issues.apache.org
Content-Length: 0
Date: SomeDate_GMT
Server: Apache-Coyote/1.1
(Servlet 1: 302, Servlet 2: 200)
Expected Results:
I expect both of these servlets to return what Servlet 1 responded with. For
reference, the same behavior occurs if you use setContentLength(0).
I believe the Servlet 2 invocation of setStatus doesn't have an effect because
setting the content length to 0 caused the response to become incorrectly
committed.
Build Date Platform:
I'm running the official 5.0.28 release on Solaris 8.
Additional Information:
If this is in fact a defect, my only possible suggestion is that something may
be wrong with the implementation of isAppCommitted in
o.a.coy.t5.CoyoteResponse from jakarta-tomcat-catalina. In code above, I
believe that invoking res.setStatus() results in isCommitted() being invoked on
a CoyoteResponseFacade object. In turn, this invokes isAppCommitted on a
CoyoteResponse object. For 5_0_28 the implementation of isAppCommitted reads:
/**
* Application commit flag accessor.
*/
public boolean isAppCommitted() {
return (this.appCommitted || isCommitted() || isSuspended()
|| ((getContentLength() != -1)
(getContentCount() = getContentLength(;
}
It appears that this can evaluate to true even if everything is false up until
the final piece:
|| ((getContentLength() != -1)
(getContentCount() = getContentLength(;
And both getContentCount and getContentLength return 0.
From comments in the same file, getContentCount returns the number of bytes
actually written to the output stream. While getContentLength returns the
content length that was set or calculated for this Response.
So, if I haven't written anything and I don't plan on writing any body part of
the message, then both of these methods return 0, and we're committed even
though neither the status line nor the headers have been necessarily written on
the wire.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36318] - CRC error in compressed sample.war file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36318. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36318 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-21 21:32 --- I have tested the file and I have no problems expanding it. A check of the file date shows it has not changed since this report so it looks like your download was corrupted. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36318] - CRC error in compressed sample.war file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36318. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36318 --- Additional Comments From [EMAIL PROTECTED] 2005-09-21 23:17 --- For the record, the MD5 of the fixed file is 8c6d76407406763b2b69b5fda3cf8e6d -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35298] - Multiple JK/ISAPI redirectors on a single IIS site are not supported
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35298. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35298 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16478|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-09-21 23:25 --- Created an attachment (id=16484) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16484action=view) Fixes for Tomcat Header Handling (Minimal) Redone patch to fix only the TRANSLATE header handling bug. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36763] - Setting content length to 0 in HttpServletResponse causes response to become falsely committed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36763. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36763 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-09-21 23:29 --- *** This bug has been marked as a duplicate of 32604 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32604] - Some httpHeaders can be lost in response
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32604. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32604 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-09-21 23:29 --- *** Bug 36763 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Sorted. William A. Rowe, Jr. wrote: Ack - there was a lingering #ifdef JK_NEED_... which should have been an #if JK_NEED_... - this is fixed in cvs, please retry and thanks for the detailed report! Bill Tim Whittington wrote: Confused me too. Error message is listed below. [exec] cl.exe /nologo /MD /W3 /Zi /O2 /I ..\common /I C:\j2sdk1.4.2_07\include /I C:\j2sdk1.4.2_07\include \win32 /I C:/Program Files/Apache Group/Apache2\include /D NDEBUG /D WIN32 /D _WINDOWS /Fo.\Release\\ /Fd.\R elease\mod_jk_src /FD /c ..\common\jk_worker.c [exec] jk_worker.c [exec] cl.exe @C:\TEMP\nm7CC.tmp [exec] mod_jk.c [exec] mod_jk.c(2437) : warning C4013: 'unixd_set_global_mutex_perms' undefined; assuming extern returning int [exec] link.exe @C:\TEMP\nm7CD.tmp [exec] LINK : fatal error LNK1104: cannot open file 'MSVCRT.lib' [exec] NMAKE : fatal error U1077: 'link.exe' : return code '0x450' [exec] Stop. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36765] New: - Tomcat QUERY Url is not skipped in init_ws_service
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36765. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36765 Summary: Tomcat QUERY Url is not skipped in init_ws_service Product: Tomcat 5 Version: 5.0.0 Platform: PC OS/Version: Windows XP Status: NEW Severity: minor Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The QUERY_HEADER_NAME header used to pass the query string from FilterProc to ExtensionProc is not stripped in init_ws_service like the URI and WORKER headers are. It's optional, so it just seems like a case of decrementing the real header count (cnt) when detected (URI and WORKER are always skipped) and skipping it as a non-real header. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12428] - request.getUserPrincipal(): Misinterpretation of specification?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=12428. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=12428 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-21 23:49 --- The underlying issue here is how BASIC authentication works. With BASIC authentication, the user is required to authenticate with every request and the browser helpfully caches the user name and password and re-uses them with subsequent requests. The spec requires that authentication only takes place if a resource is protected. Therefore, for an unprotected resource no BASIC authentication takes place even if the browser sends the credentials. In turn, this means that getUserPrincipal() will return null since the user has not been authenticated. One work-around is to use FORM authentication. In this scheme, the user is authenticated once and the Principal added to the session. This authenticated Principal remains available whilst the session is valid regardless of whether an individual request requires authentication. I have considered modifying the BASIC authentication implementation so a user is always authenticated if the present credentials but: - this would violate the spec - the behaviour if the authentication fails is undefined (because the spec obviously doesn't define behaviour that violates the spec) Therefore I am going to resolve this as INVALID since any other behaviour is a spec violation. As a final comment I do not like that this means that application behaviour varies with the authentication scheme specified in web.xml but this is a direct side-effect of the differences in per-request and per-session authentication. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16205] - org.apache.naming.factory.BeanFactory bugs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=16205. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=16205 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-22 00:54 --- I have followed the how to using the latest TC4.1.x code from SVN with respect to the issues you raise: 1. resource-env-ref works for me. 2. I think I need an example here. I don't see how the wrong class can end up here based just on user configuration. 3. There is no description element, it is an attribute of the Resource element and is ignored. I have searched the commit history but cannot find any changes that might fix any of the above. However, since I might have missed them I am going to resolve this as fixed. If you think otherwise, please re-open this report with a simple as possible test case that demonstrates the problem with Tomcat 4.1.31 or later. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Alejandro Alhambra Garcia/UN21348/PLATAFORMAS DE SERVICIOS/TSM está ausente de la oficina.
Estaré ausente de la oficina desde el 03/09/2005 y no volveré hasta el 25/09/2005. Para temas urgentes contactar con Yayo Diez Bejerano. -- Este mensaje puede contener información confidencial y/o privilegiada. Si Vd. no es el destinatario de este mensaje o ha recibido este mensaje por error, por favor, informe inmediatamente al emisor y destruya este mensaje. Está estrictamente prohibido por la legislación vigente realizar sin autorización cualquier copia, revelación o distribución de este mensaje. Las opiniones expresadas en este correo son las de su autor y Telefónica Móviles España, S.A. no se responsabiliza de su contenido. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden by current legislation. The points of view expressed in this e-mail are solely those of the author and may not necessarily be from, or supported by, the company. Telefonica Moviles S.A. neither assumes obligations nor accepts liability for the content of this e-mail, unless that information is subsequently confirmed by writing by a duly authorised representative. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33453. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33453 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-09-22 01:15 --- The .jsp file date stamp doesn't have to go back in time for the isOutDated check to fail, it can and does fail in a more normal usage pattern. Here is a scenario that shows the problem: - I deploy version 1, the .jsp has time1 - I make version 2 of the .jsp at time2 - Visitor visits the site, and the .jsp is compiled at time3 - I deploy version2 - isOutDated returns false as time3 time2 Would setting the date stamp of the .java and .class files to the date stamp of the .jsp file, and changing the comparison from to != in the isOutDated check fix the problem sufficiently? Or are there negative side effects I haven't thought of? I am working on patching my Tomcat to do exactly as above, I would be happy to give it to someone for evaluation when its ready. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36741] - ArrayIndexOutOfBoundsException in org.apache.coyote.http11.InternalOutputBuffer.write
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36741 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-09-22 01:52 --- The idea behind this patch is to enable large headers being sent without using up excessive amounts of memory. For example, our application sometimes sets a lot of cookies. Instead of always preallocation memory and sometimes running out of buffer space when we cannot predict the cookie sizes correctly, we send everything through the same buffer. Also, the patch avoids a hard to diagnose exception. If you look around the web, you will see that other people ran into this condition as well. I have not seen any of them successfully identify the problem much less point at maxHttpHeaderSize as a workaround. As to calling this condition a buffer overflow, it would be that had this code not been written in Java. http://forums.atlassian.com/thread.jspa?threadID=6121tstart=75 http://mail-archive.objectweb.org/ops-users/2005-06/msg00109.html http://swforum.sun.com/jive/thread.jspa?threadID=50844messageID=185391 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36742] - Missing diagnostics in InternalInputBuffer on overly long headers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36742. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36742 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-09-22 02:10 --- I actually like the diagnostic message, it's helpful. It should be a rare event (so no big performance hit from logger.info), but when it does happen, the developer would want to know... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12428] - request.getUserPrincipal(): Misinterpretation of specification?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=12428. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=12428 --- Additional Comments From [EMAIL PROTECTED] 2005-09-22 05:09 --- (In reply to comment #14) Unless there have been changes in the latest version of TomCat, I have always been using Form Authentication. So the description of this problem is IN the context of Form Authentication. Even after being authenticated via a Form authentication method, the getUserPrincipal still returns NULL for those resources which are not protected. I worked around this problem, however, by creating my own Valve and storing the authenticated user somewhere I can get it later. Later, I ensure that this user is correctly setup for the JBOSS call to the EJB. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36767] New: - Taglibrary utilizing generified collections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36767.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36767
Summary: Taglibrary utilizing generified collections
Product: Tomcat 5
Version: 5.0.28
Platform: PC
OS/Version: Linux
Status: NEW
Keywords: JDK1.5
Severity: minor
Priority: P4
Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
I implemented two tags, one to display a navigation bar and another to display a
list of news items. Both tags received their data from a DAO which returned a
Collection of appropriate objects. When I switched over to using generics the
error below appeared for *both* tags.
I found two different fixes. If I avoided creating a local variable to hold
either the CollectionNewsItem or IteratorNewsItem, then everything worked
fine. For example:
for(NewsItem n : newsItemDao.getAll()) { ... }
solved the problem. The other approach was simply not to use the generic
approach in the tag, even though the DAO was still returning a generified
collection.
Here's one of the stacktraces, the other was the same:
Sep 21, 2005 9:43:57 PM org.apache.jasper.compiler.Compiler generateClass
SEVERE: Error compiling file:
/var/lib/tomcat-5/default/work/Catalina/localhost/javacms//org/apache/jsp/WEB_002dINF/jsp/news_jsp.java
[javac] Compiling 1 source file
[javac]
/var/lib/tomcat-5/default/work/Catalina/localhost/javacms/org/apache/jsp/WEB_002dINF/jsp/news_jsp.java:95:29:95:35:
Semantic Error: The class file NewsTag.class in
/var/lib/tomcat-5/default/webapps/javacms/WEB-INF/classes/com/snoyman/jcms/taglib
has an invalid format (duplicate local variable type table).
[javac]
/var/lib/tomcat-5/default/work/Catalina/localhost/javacms/org/apache/jsp/WEB_002dINF/jsp/news_jsp.java:95:61:95:91:
Semantic Error: Type NewsTag was not found.
[javac]
/var/lib/tomcat-5/default/work/Catalina/localhost/javacms/org/apache/jsp/WEB_002dINF/jsp/news_jsp.java:95:129:95:159:
Semantic Error: Type NewsTag was not found.
Sep 21, 2005 9:43:57 PM org.springframework.web.servlet.FrameworkServlet
serviceWrapper
SEVERE: Could not complete request
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: 8 in the jsp file: /WEB-INF/jsp/news.jsp
Generated servlet error:
[javac]
/var/lib/tomcat-5/default/work/Catalina/localhost/javacms/org/apache/jsp/WEB_002dINF/jsp/news_jsp.java:95:29:95:35:
Semantic Error: The class file NewsTag.class in
/var/lib/tomcat-5/default/webapps/javacms/WEB-INF/classes/com/snoyman/jcms/taglib
has an invalid format (duplicate local variable type table).
An error occurred at line: 8 in the jsp file: /WEB-INF/jsp/news.jsp
Generated servlet error:
[javac]
/var/lib/tomcat-5/default/work/Catalina/localhost/javacms/org/apache/jsp/WEB_002dINF/jsp/news_jsp.java:95:61:95:91:
Semantic Error: Type NewsTag was not found.
An error occurred at line: 8 in the jsp file: /WEB-INF/jsp/news.jsp
Generated servlet error:
[javac]
/var/lib/tomcat-5/default/work/Catalina/localhost/javacms/org/apache/jsp/WEB_002dINF/jsp/news_jsp.java:95:129:95:159:
Semantic Error: Type NewsTag was not found.
at
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:84)
at
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:332)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:412)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:472)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
at
DO NOT REPLY [Bug 36742] - Missing diagnostics in InternalInputBuffer on overly long headers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36742. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36742 --- Additional Comments From [EMAIL PROTECTED] 2005-09-22 07:56 --- It would also create a nice way to have the server fills out log files predictably. Frankly, it's useless. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36741] - ArrayIndexOutOfBoundsException in org.apache.coyote.http11.InternalOutputBuffer.write
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36741 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-09-22 07:57 --- (In reply to comment #4) As to calling this condition a buffer overflow, it would be that had this code not been written in Java. Yes, but this is Java, where buffer overflow does not exist. -1 and WONTFIX mean: no sorry. Please don't reopen the report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
