Re: [VOTE] Release build 6.0.28
On 06/30/2010 05:20 AM, Konstantin Kolinko wrote: > 2010/6/29 jean-frederic clere : >> Due to bugs (49445 and 49424) and as I was not able to finish the >> release process quickly (because of working remotely) and as releases >> are cheap we would like to abandon 6.0.27 and propose the vote for 6.0.28 >> >> The candidates binaries are available here: >> http://people.apache.org/~jfclere/tomcat-6/v6.0.28/ >> > > 1. /src/apache-tomcat-6.0.28-src.zip.asc is absent. There are only 5 > files in the src folder. Oops I have added the missing asc file. > 2. like it was with 6.0.27, your 4096-bit key is still missing from > the KEYS file, That is not a regression... We have KEYS everywhere we should clean that and use only http://www.apache.org/dist/tomcat/tomcat-6/KEYS. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r959233 - in /tomcat/trunk/test/org/apache/el: TestMethodExpressionImpl.java TesterBeanBB.java TesterBeanC.java
Author: markt
Date: Wed Jun 30 08:46:50 2010
New Revision: 959233
URL: http://svn.apache.org/viewvc?rev=959233&view=rev
Log:
Re-factor to make upcoming changes easier to understand
Added:
tomcat/trunk/test/org/apache/el/TesterBeanBB.java
- copied, changed from r959061,
tomcat/trunk/test/org/apache/el/TesterBeanC.java
Removed:
tomcat/trunk/test/org/apache/el/TesterBeanC.java
Modified:
tomcat/trunk/test/org/apache/el/TestMethodExpressionImpl.java
Modified: tomcat/trunk/test/org/apache/el/TestMethodExpressionImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/el/TestMethodExpressionImpl.java?rev=959233&r1=959232&r2=959233&view=diff
==
--- tomcat/trunk/test/org/apache/el/TestMethodExpressionImpl.java (original)
+++ tomcat/trunk/test/org/apache/el/TestMethodExpressionImpl.java Wed Jun 30
08:46:50 2010
@@ -88,10 +88,10 @@ public class TestMethodExpressionImpl ex
factory.createValueExpression(beanA, TesterBeanA.class);
context.getVariableMapper().setVariable("beanA", varA);
-TesterBeanC beanC = new TesterBeanC();
+TesterBeanBB beanC = new TesterBeanBB();
beanC.setName("Tomcat");
ValueExpression varC =
-factory.createValueExpression(beanC, TesterBeanC.class);
+factory.createValueExpression(beanC, TesterBeanBB.class);
context.getVariableMapper().setVariable("beanC", varC);
MethodExpression me1 = factory.createMethodExpression(context,
Copied: tomcat/trunk/test/org/apache/el/TesterBeanBB.java (from r959061,
tomcat/trunk/test/org/apache/el/TesterBeanC.java)
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/el/TesterBeanBB.java?p2=tomcat/trunk/test/org/apache/el/TesterBeanBB.java&p1=tomcat/trunk/test/org/apache/el/TesterBeanC.java&r1=959061&r2=959233&rev=959233&view=diff
==
--- tomcat/trunk/test/org/apache/el/TesterBeanC.java (original)
+++ tomcat/trunk/test/org/apache/el/TesterBeanBB.java Wed Jun 30 08:46:50 2010
@@ -17,7 +17,7 @@
package org.apache.el;
-public class TesterBeanC extends TesterBeanB {
+public class TesterBeanBB extends TesterBeanB {
private String extra;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49511] IIS 7.5 incorrect logging: pfc->pFilterContext is per-connection not per-request
https://issues.apache.org/bugzilla/show_bug.cgi?id=49511 --- Comment #1 from Attila Király 2010-06-30 05:51:56 EDT --- The problem could be reproduced with IIS 6.0 too (32 bit). The workaround, disabling keep-alive, solves the logging problem on both versions. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49528] HttpServletRequest.isAsyncStarted() returns false when a Runnable is started
https://issues.apache.org/bugzilla/show_bug.cgi?id=49528 Pieter Libin changed: What|Removed |Added CC||pie...@emweb.be -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49528] New: HttpServletRequest.isAsyncStarted() returns false when a Runnable is started
https://issues.apache.org/bugzilla/show_bug.cgi?id=49528 Summary: HttpServletRequest.isAsyncStarted() returns false when a Runnable is started Product: Tomcat 7 Version: 7.0.0 Platform: PC OS/Version: Linux Status: NEW Severity: blocker Priority: P2 Component: Servlet & JSP API AssignedTo: dev@tomcat.apache.org ReportedBy: pie...@emweb.be Created an attachment (id=25667) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25667) Servlet 3.0 isAsyncStarted testcase In the attached example, an async request is created, but within a Runnable started using AsyncContext.start() the isAsyncStarted() returns false. This conflicts with the servlet 3.0 specification. Quoting chapter "2.3.3.3 Asynchronous processing" : " public boolean isAsyncStarted() - Returns true if async processing has started on this request, and false otherwise. If this request has been dispatched using one of the AsyncContext.dispatch methods since it was put in asynchronous mode, or a call to AsynContext.complete is made, this method returns false. " This output is generated by Tomcat 7.0.0: Start async() Dispatching start() request.isAsyncStarted()1true Returning from doGet() request.isAsyncStarted()2false Before sleep() After sleep() request.isAsyncStarted()3false Returning from run() request.isAsyncStarted()4false The following output is what we would expect and what Jetty v8.0 generates: Start async() Dispatching start() request.isAsyncStarted()1true Returning from doGet() request.isAsyncStarted()2true Before sleep() After sleep() request.isAsyncStarted()3true Returning from run() request.isAsyncStarted()4false -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49523] Broken links on Manager List Applications page
https://issues.apache.org/bugzilla/show_bug.cgi?id=49523 --- Comment #6 from Rainer Jung 2010-06-30 07:03:47 EDT --- The application list in the manager webapp simply lists all known contexts. The link provided for each context is a convenience link for an admin to jump into the respective context. The link assumes, that there is some reasonable content available directly under the context path. This might be true for some contexts that use e.g. welcome pages or have a servlet mapping for /, but there will also be contexts which do not produce any reasonable response when their conext root is called. Yes, manager and host-manager are not general applications but instead provided by the Tomcat project. Nevertheless producing special links just for the manager and host-manager will bloat the code and only work as long as the admin doesn't deploy them under a different context name - or doesn't deploy something else under the names manager or host-manager. IMHO that's the reason for INVALID. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49530] New: Context is not correctly stopped at shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=49530 Summary: Context is not correctly stopped at shutdown Product: Tomcat 7 Version: 7.0.0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: rainer.frey+tom...@inxmail.de Created an attachment (id=25669) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25669) Application that show the behavior Apparently a web application context is not correctly stopped when shutting down Tomcat 7.0.0. I noticed that the destroy() method of a Servlet that's loaded on startup was not called, and put together a test case (see attached files). The test servlet writes to System.out on init() and destroy(), the output on init appears in logs/catalina.out, but no output on destroy. From what I understand of the attached log, the context isn't stopped at all. Steps to reproduce: 1. copy attached startupServlet.war to webapps 2. start Tomcat, then "StartTestServlet.init" appears in catalina.out 3. stop Tomcat Actual Result: no output appears in logs/catalina.out Expected Result: "StartTestServlet.destroy" appears in catalina.out catalina.log shows evidence of context /startupServlet being stopped FWIW: java -version: java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) uname -a Linux 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64 GNU/Linux -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49530] Context is not correctly stopped at shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=49530 --- Comment #1 from Rainer Frey 2010-06-30 10:10:24 EDT --- Created an attachment (id=25670) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25670) Source code of the test servlet -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49530] Context is not correctly stopped at shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=49530 --- Comment #2 from Rainer Frey 2010-06-30 10:12:25 EDT --- Created an attachment (id=25671) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25671) Log file with LifecycleBase logger on FINE level -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
FW: problem with org.apache.catalina.core.ApplicationHttpRequest method.
Hi guys, sorry for the bother. I do have a question related to how a certain
feature was implemented in Tomcat (6.0, probably
all of them), that's why I address the question to the dev-list and the
user-list.
I do have a fairly complicated case, in which I have a filter for jsp's, and I
use a custom request wrapper in the respective filter.
My request wrapper overrides setAttribute and getAttribute (does some internal
management, not relying on the "super"),
and I had the surprise to see that the setAttribute from my wrapper doesn't get
called from the
org.apache.catalina.core.ApplicationHttpRequest setAttribute, at least not for
the "special attributes" (and I need the
javax.servlet.include attributes, which Tomcat considers "special").
The code that I find is problematic is copied underneath (the if(!setSpecial)
part), and the question is "why doesn't the
getRequest.setAttribute get called ALL THE TIME". The problem manifests when I
do a jsp:include, and when the
filter on the included jsp checks my wrapper, can't find the
javax.servlet.include.* attributes. This is somewhat bothering,
considering that I don't have this issue with Weblogic and Websphere, both do
call my wrapper's set/getAttribute...
p.s. the code I believe is at fault is:
org.apache.catalina.core.ApplicationHttpRequest
...
public void setAttribute(String name,
Object value)
{
if (name.equals(Globals.DISPATCHER_TYPE_ATTR)) {
dispatcherType = value;
return;
} else if (name.equals(Globals.DISPATCHER_REQUEST_PATH_ATTR)) {
requestDispatcherPath = value;
return;
}
if (!setSpecial(name, value)) {
getRequest().setAttribute(name, value);
}
}So, the questions are:
1. do you think is a big issue if I remove the "if" and I just use instead to
instructions -
- setSpecial(name, attribute);
- getRequest().setAttribute...
In my tests it seemed to work fine, but maybe I don't grasp all the
implications.
2. any particular reason for calling the getRequest().setAttribute only for
some (non-special) attributes, but not for others (javax.servlet.include.*)?
thanks for any suggestion/
ranjix
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
Learn more.
_
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1
Re: Proposal: Some todo's at AsyncContext detected...
Hi,
What you write means that the freshly release Tomcat 7 doesn't fully
implement Servlet API 3.0, isn't it?
Interesting to see that nobody reacts :-(
Cheers,
Marc.
Peter Roßbach wrote:
Hi!
I detected some Todo's at AsyncContext
- AsyncContext.createListener
We don't make a resource injection or make it configurable!
Servlet 3.0 API comment:
"This method supports resource injection if the given clazz
represents a Managed Bean. See the Java EE platform and JSR 299
specifications for additional details about Managed Beans and resource
injection."
- I miss the is[Started,Completed] methods at AsyncContext interface
The only way to detect a completed state at AsyncContext inside an
AsyncListener is:
if (ac.getResponse() != null)
AsyncListener got an event, with empty state... -- Very strange!
Can't we clear all AsyncListener after send complete and before we
refresh the AsyncContext state?
How can a user handle a completed situation?
see o.a.c.core.TestAsyncListener
- AsyncContext.start() dosen't really start a thread!
We create wrapper of a Runnable, but we don't start a thread...
Error handling seam a little bit strange.
We only throw a RuntimeException(ex) and log an error!
Servlet API comment:
"Causes the container to dispatch a thread, possibly from a
managed thread pool, to run the specified Runnable. The container may
propagate appropriate contextual information to the Runnable."
How can we implement that?
Start everytime a new thread without pooling?
Use the connector executor pool from request?
Then we must extend the ProtocolHandler interface with
getExecutor() signature.
Use a separate Executor pool per Engine/Host or Context
How do we have to implemented the error handling?
- JioEndpoint has a timeout detection thread, but we don't start it!
I easy fix it with revision 958362,
but the polling strategy is slow and ineffectiv.
I didn't make a test at NIO/APR-HTTP or AJP-Connectors.
- After the timeout event is emitted, the completed method is
automatically called!
Servlet API 3.0 Spec says:
■In the event that an asynchronous operation times out, the container
must run
through the following steps:
■ Invoke the AsyncListener.onTimeout method on all the AsyncListener
instances registered with the ServletRequest on which the asynchronous
operation was initiated.
■ If none of the listeners called AsyncContext.complete() or any of the
AsyncContext.dispatch methods, perform an error dispatch with a status
code equal to HttpServletResponse.SC_INTERNAL_SERVER_ERROR.
■ If no matching error page was found, or the error page did not call
AsyncContext.complete() or any of the AsyncContext.dispatch
methods, the container MUST call AsyncContext.complete().
===
I miss the implementation that we call the error page!
- Currently a AsyncListener can't reinit a async cycle!
see o.a.c.connector.Request.startAsync
... L1555ff
if (asyncContext==null) {
asyncContext = new AsyncContextImpl(this);
} else if (asyncContext.isStarted()) {
throw new IllegalStateException("Already started.");
}
...
What does this spec definition really mean?
=== Ch 2 Page 18
■public void onStartAsync(AsyncEvent event) - Is used to notify the
listener that a new asynchronous cycle is being initiated via a call to
one of the
ServletRequest.startAsync methods. The AsyncContext corresponding
to the asynchronous operation that is being reinitialized may be
obtained by
calling AsyncEvent.getAsyncContext on the given event.
- AsyncListener doesn't receive a onStartAsync event.
We don't implement it.
At AsyncListenerWrapper fireOnStartAsync is missing
As AsyncContext.startAsync method doesn't emit an event
- ContextClassLoader at AsyncContext.dispatch is not set!
I can't see that we correcly set the application ContextClassLoader
before
we dispatch the Request. What must we do at a CrossContext dispatch?
- After first complete async cycle, an AsyncListner receive onStartAsync
as code start next async cycle?
Why doesn't the Servlet 3.0 TCK check basic AsyncContext functionalities?
It seams that we better start a open test suite implementation at the
new Servlet 3.0 API.
Regards,
Peter
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: FW: problem with org.apache.catalina.core.ApplicationHttpRequest method.
On 30/06/2010 15:23, Ranjix R wrote:
Cross posting to both lists isn't usually a good idea.
p
> Hi guys, sorry for the bother. I do have a question related to how a certain
> feature was implemented in Tomcat (6.0, probably
> all of them), that's why I address the question to the dev-list and the
> user-list.
> I do have a fairly complicated case, in which I have a filter for jsp's, and
> I use a custom request wrapper in the respective filter.
> My request wrapper overrides setAttribute and getAttribute (does some
> internal management, not relying on the "super"),
> and I had the surprise to see that the setAttribute from my wrapper doesn't
> get called from the
> org.apache.catalina.core.ApplicationHttpRequest setAttribute, at least not
> for the "special attributes" (and I need the
> javax.servlet.include attributes, which Tomcat considers "special").
>
> The code that I find is problematic is copied underneath (the if(!setSpecial)
> part), and the question is "why doesn't the
> getRequest.setAttribute get called ALL THE TIME". The problem manifests when
> I do a jsp:include, and when the
> filter on the included jsp checks my wrapper, can't find the
> javax.servlet.include.* attributes. This is somewhat bothering,
> considering that I don't have this issue with Weblogic and Websphere, both do
> call my wrapper's set/getAttribute...
>
> p.s. the code I believe is at fault is:
>
> org.apache.catalina.core.ApplicationHttpRequest
> ...
> public void setAttribute(String name,
> Object value)
> {
> if (name.equals(Globals.DISPATCHER_TYPE_ATTR)) {
> dispatcherType = value;
> return;
> } else if (name.equals(Globals.DISPATCHER_REQUEST_PATH_ATTR)) {
> requestDispatcherPath = value;
> return;
> }
> if (!setSpecial(name, value)) {
> getRequest().setAttribute(name, value);
> }
> }So, the questions are:
>
> 1. do you think is a big issue if I remove the "if" and I just use instead to
> instructions -
> - setSpecial(name, attribute);
> - getRequest().setAttribute...
> In my tests it seemed to work fine, but maybe I don't grasp all the
> implications.
>
> 2. any particular reason for calling the getRequest().setAttribute only for
> some (non-special) attributes, but not for others (javax.servlet.include.*)?
>
> thanks for any suggestion/
> ranjix
>
>
>
>
> Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
> Learn more.
> _
> Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1
signature.asc
Description: OpenPGP digital signature
Re: Proposal: Some todo's at AsyncContext detected...
2010/6/30 Marc Guillemot : > Hi, > > What you write means that the freshly release Tomcat 7 doesn't fully > implement Servlet API 3.0, isn't it? > 1. It was released as Beta 2. It passes TCK Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r959371 - in /tomcat/tc5.5.x/trunk/build: sign.bat sign.sh tag.sh
Author: jim Date: Wed Jun 30 16:44:43 2010 New Revision: 959371 URL: http://svn.apache.org/viewvc?rev=959371&view=rev Log: Unix rev's... mostly for pre and post efforts. Still need Windoze to build the releases. Added: tomcat/tc5.5.x/trunk/build/sign.sh (with props) tomcat/tc5.5.x/trunk/build/tag.sh (with props) Modified: tomcat/tc5.5.x/trunk/build/sign.bat Modified: tomcat/tc5.5.x/trunk/build/sign.bat URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/build/sign.bat?rev=959371&r1=959370&r2=959371&view=diff == --- tomcat/tc5.5.x/trunk/build/sign.bat (original) +++ tomcat/tc5.5.x/trunk/build/sign.bat Wed Jun 30 16:44:43 2010 @@ -19,10 +19,8 @@ rem Example script to sign the entire re rem pass in your password as the first argument, then this script will rem sign all the files in the release directory -rem todo - make one for unix as well, and avoid signing the .md5 files - @echo off -set VERSION=v5.5.29 +set VERSION=v5.5.30 FOR /R %cd%\release\%VERSION% %%i in (*.tar.gz) do ( echo Signing %%i echo %1|gpg --passphrase-fd 0 -a -b %%i Added: tomcat/tc5.5.x/trunk/build/sign.sh URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/build/sign.sh?rev=959371&view=auto == --- tomcat/tc5.5.x/trunk/build/sign.sh (added) +++ tomcat/tc5.5.x/trunk/build/sign.sh Wed Jun 30 16:44:43 2010 @@ -0,0 +1,29 @@ +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. +# The ASF licenses this file to You under the Apache License, Version 2.0 +# (the "License"); you may not use this file except in compliance with +# the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + + +# Example script to sign the entire release +# pass in your password as the first argument, then this script will +# sign all the files in the release directory + + +VERSION=v5.5.30 +cd $VERSION +for i in *.tar.gz *.exe *.zip +do + echo Signing $i + gpg --armor --detach-sign $i +done + Propchange: tomcat/tc5.5.x/trunk/build/sign.sh -- svn:eol-style = native Added: tomcat/tc5.5.x/trunk/build/tag.sh URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/build/tag.sh?rev=959371&view=auto == --- tomcat/tc5.5.x/trunk/build/tag.sh (added) +++ tomcat/tc5.5.x/trunk/build/tag.sh Wed Jun 30 16:44:43 2010 @@ -0,0 +1,19 @@ +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. +# The ASF licenses this file to You under the Apache License, Version 2.0 +# (the "License"); you may not use this file except in compliance with +# the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +# Expects one argument, the tag name (no quotes needed, e.g. TOMCAT_5_5_13) + +# All - new layout +svn copy https://svn.apache.org/repos/asf/tomcat/tc5.5.x/trunk https://svn.apache.org/repos/asf/tomcat/tc5.5.x/tags/$1 -m "Tagging Tomcat version $1." Propchange: tomcat/tc5.5.x/trunk/build/tag.sh -- svn:eol-style = native - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r959372 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: jim Date: Wed Jun 30 16:46:43 2010 New Revision: 959372 URL: http://svn.apache.org/viewvc?rev=959372&view=rev Log: some votes Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=959372&r1=959371&r2=959372&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Wed Jun 30 16:46:43 2010 @@ -38,6 +38,7 @@ PATCHES PROPOSED TO BACKPORT: 2) http://people.apache.org/~kkolinko/patches/2010-03-06_tc55_remove_JSSE13Factory_v2.patch +1: kkolinko, markt + -O: jim -1: * Configure Tomcat to use HttpOnly for session cookies by default @@ -49,5 +50,5 @@ PATCHES PROPOSED TO BACKPORT: * Arrange filter logic. http://svn.apache.org/viewvc?rev=958911&view=rev - +1: jfclere, markt, rjung + +1: jfclere, markt, rjung, jim -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Proposal: Some todo's at AsyncContext detected...
On 30/06/2010 17:01, Marc Guillemot wrote:
Hi,
What you write means that the freshly release Tomcat 7 doesn't fully
implement Servlet API 3.0, isn't it?
Interesting to see that nobody reacts :-(
If you were following the dev list you would have seen that
Jean-Frederic has already vetoed the change Peter made on the basis that
it breaks the TCK. That suggests that Peter's analysis of the current
situation is not 100% correct.
My recollection is that the last thing that Filip implemented for
Servlet 3.0 was the necessary timeout features. I'd be surprised if
Filip, as a member of the Servlet Expert Group that wrote the spec,
missed something fundamental. I wouldn't be surprised if there were some
edge cases missed. I do know that Filip tended to leave a lot of the
Servlet 3.0 TODOs in the code, even when he had implemented the
appropriate feature. Those certainly need cleaning up.
Looking at Peter's test case - along with the other issues folks have
raised in Bugzilla for the 7.0.0 release - is on my todo list but like
the other committers I have a day job. Whilst many of the committers are
fortunate enough (me included) to be able to allocate some work time to
Tomcat development, it doesn't follow one of the other committers will
immediately have the time necessary to look at Peter's e-mail and
comment in detail. I can't speak for the others, but my free time is
currently occupied with another Tomcat 7 issue - namely
http://tomcat.markmail.org/thread/25g353eqvqfqniiz
Like any area of Tomcat, help is always appreciated. If you are
interested in this issue and would like to help out I would encourage
you to look at Peter's test case, compare the expected behaviour to what
the spec defines and offer your view on whether there is a bug that
needs fixing or not. If there is an issue, patches would be even better.
Mark
Cheers,
Marc.
Peter Roßbach wrote:
Hi!
I detected some Todo's at AsyncContext
- AsyncContext.createListener
We don't make a resource injection or make it configurable!
Servlet 3.0 API comment:
"This method supports resource injection if the given clazz represents
a Managed Bean. See the Java EE platform and JSR 299 specifications
for additional details about Managed Beans and resource injection."
- I miss the is[Started,Completed] methods at AsyncContext interface
The only way to detect a completed state at AsyncContext inside an
AsyncListener is:
if (ac.getResponse() != null)
AsyncListener got an event, with empty state... -- Very strange!
Can't we clear all AsyncListener after send complete and before we
refresh the AsyncContext state?
How can a user handle a completed situation?
see o.a.c.core.TestAsyncListener
- AsyncContext.start() dosen't really start a thread!
We create wrapper of a Runnable, but we don't start a thread...
Error handling seam a little bit strange.
We only throw a RuntimeException(ex) and log an error!
Servlet API comment:
"Causes the container to dispatch a thread, possibly from a managed
thread pool, to run the specified Runnable. The container may
propagate appropriate contextual information to the Runnable."
How can we implement that?
Start everytime a new thread without pooling?
Use the connector executor pool from request?
Then we must extend the ProtocolHandler interface with getExecutor()
signature.
Use a separate Executor pool per Engine/Host or Context
How do we have to implemented the error handling?
- JioEndpoint has a timeout detection thread, but we don't start it!
I easy fix it with revision 958362,
but the polling strategy is slow and ineffectiv.
I didn't make a test at NIO/APR-HTTP or AJP-Connectors.
- After the timeout event is emitted, the completed method is
automatically called!
Servlet API 3.0 Spec says:
■In the event that an asynchronous operation times out, the container
must run
through the following steps:
■ Invoke the AsyncListener.onTimeout method on all the AsyncListener
instances registered with the ServletRequest on which the asynchronous
operation was initiated.
■ If none of the listeners called AsyncContext.complete() or any of the
AsyncContext.dispatch methods, perform an error dispatch with a status
code equal to HttpServletResponse.SC_INTERNAL_SERVER_ERROR.
■ If no matching error page was found, or the error page did not call
AsyncContext.complete() or any of the AsyncContext.dispatch
methods, the container MUST call AsyncContext.complete().
===
I miss the implementation that we call the error page!
- Currently a AsyncListener can't reinit a async cycle!
see o.a.c.connector.Request.startAsync
... L1555ff
if (asyncContext==null) {
asyncContext = new AsyncContextImpl(this);
} else if (asyncContext.isStarted()) {
throw new IllegalStateException("Already started.");
}
...
What does this spec definition really mean?
=== Ch 2 Page 18
■public void onStartAsync(AsyncEvent event) - Is used to notify the
listener that a new asynchronous cycle is being initiated via a call
to one of the
Servlet
Re: Proposal: Some todo's at AsyncContext detected...
Hi Marc,
Am 30.06.2010 um 20:03 schrieb Mark Thomas:
On 30/06/2010 17:01, Marc Guillemot wrote:
Hi,
What you write means that the freshly release Tomcat 7 doesn't fully
implement Servlet API 3.0, isn't it?
Interesting to see that nobody reacts :-(
If you were following the dev list you would have seen that Jean-
Frederic has already vetoed the change Peter made on the basis that
it breaks the TCK. That suggests that Peter's analysis of the
current situation is not 100% correct.
Which of my findings aren't correct?
Peter
My recollection is that the last thing that Filip implemented for
Servlet 3.0 was the necessary timeout features. I'd be surprised if
Filip, as a member of the Servlet Expert Group that wrote the spec,
missed something fundamental. I wouldn't be surprised if there were
some edge cases missed. I do know that Filip tended to leave a lot
of the Servlet 3.0 TODOs in the code, even when he had implemented
the appropriate feature. Those certainly need cleaning up.
Looking at Peter's test case - along with the other issues folks
have raised in Bugzilla for the 7.0.0 release - is on my todo list
but like the other committers I have a day job. Whilst many of the
committers are fortunate enough (me included) to be able to allocate
some work time to Tomcat development, it doesn't follow one of the
other committers will immediately have the time necessary to look at
Peter's e-mail and comment in detail. I can't speak for the others,
but my free time is currently occupied with another Tomcat 7 issue -
namely http://tomcat.markmail.org/thread/25g353eqvqfqniiz
Like any area of Tomcat, help is always appreciated. If you are
interested in this issue and would like to help out I would
encourage you to look at Peter's test case, compare the expected
behaviour to what the spec defines and offer your view on whether
there is a bug that needs fixing or not. If there is an issue,
patches would be even better.
Mark
Cheers,
Marc.
Peter Roßbach wrote:
Hi!
I detected some Todo's at AsyncContext
- AsyncContext.createListener
We don't make a resource injection or make it configurable!
Servlet 3.0 API comment:
"This method supports resource injection if the given clazz
represents
a Managed Bean. See the Java EE platform and JSR 299 specifications
for additional details about Managed Beans and resource injection."
- I miss the is[Started,Completed] methods at AsyncContext interface
The only way to detect a completed state at AsyncContext inside an
AsyncListener is:
if (ac.getResponse() != null)
AsyncListener got an event, with empty state... -- Very strange!
Can't we clear all AsyncListener after send complete and before we
refresh the AsyncContext state?
How can a user handle a completed situation?
see o.a.c.core.TestAsyncListener
- AsyncContext.start() dosen't really start a thread!
We create wrapper of a Runnable, but we don't start a thread...
Error handling seam a little bit strange.
We only throw a RuntimeException(ex) and log an error!
Servlet API comment:
"Causes the container to dispatch a thread, possibly from a managed
thread pool, to run the specified Runnable. The container may
propagate appropriate contextual information to the Runnable."
How can we implement that?
Start everytime a new thread without pooling?
Use the connector executor pool from request?
Then we must extend the ProtocolHandler interface with getExecutor()
signature.
Use a separate Executor pool per Engine/Host or Context
How do we have to implemented the error handling?
- JioEndpoint has a timeout detection thread, but we don't start it!
I easy fix it with revision 958362,
but the polling strategy is slow and ineffectiv.
I didn't make a test at NIO/APR-HTTP or AJP-Connectors.
- After the timeout event is emitted, the completed method is
automatically called!
Servlet API 3.0 Spec says:
■In the event that an asynchronous operation times out, the
container
must run
through the following steps:
■ Invoke the AsyncListener.onTimeout method on all the
AsyncListener
instances registered with the ServletRequest on which the
asynchronous
operation was initiated.
■ If none of the listeners called AsyncContext.complete() or any
of the
AsyncContext.dispatch methods, perform an error dispatch with a
status
code equal to HttpServletResponse.SC_INTERNAL_SERVER_ERROR.
■ If no matching error page was found, or the error page did not
call
AsyncContext.complete() or any of the AsyncContext.dispatch
methods, the container MUST call AsyncContext.complete().
===
I miss the implementation that we call the error page!
- Currently a AsyncListener can't reinit a async cycle!
see o.a.c.connector.Request.startAsync
... L1555ff
if (asyncContext==null) {
asyncContext = new AsyncContextImpl(this);
} else if (asyncContext.isStarted()) {
throw new IllegalStateException("Already started.");
}
...
What does this spec definition really mean?
=== Ch 2 Page 18
■public vo
Re: Proposal: Some todo's at AsyncContext detected...
On 30/06/2010 21:23, Peter Roßbach wrote: Hi Marc, Am 30.06.2010 um 20:03 schrieb Mark Thomas: On 30/06/2010 17:01, Marc Guillemot wrote: Hi, What you write means that the freshly release Tomcat 7 doesn't fully implement Servlet API 3.0, isn't it? Interesting to see that nobody reacts :-( If you were following the dev list you would have seen that Jean-Frederic has already vetoed the change Peter made on the basis that it breaks the TCK. That suggests that Peter's analysis of the current situation is not 100% correct. Which of my findings aren't correct? I don't know - I haven't run the TCK with your patch applied. Just the fact the the findings led to the patch which in turn caused TCKs failures suggests at least something isn't quite right. It could also be the analysis is OK but the patch has issues or that there is a problem with the TCK. I wouldn't be at all surprised to find part of the spec not covered by the TCK. I would be surprised to find a bug in the TCK. My own experiences with potential TCK bugs is that the TCK has always been correct. Regardless, until the TCK is proved wrong Jean-Frederic's veto is valid and your patch needs to be reverted. Mark Peter My recollection is that the last thing that Filip implemented for Servlet 3.0 was the necessary timeout features. I'd be surprised if Filip, as a member of the Servlet Expert Group that wrote the spec, missed something fundamental. I wouldn't be surprised if there were some edge cases missed. I do know that Filip tended to leave a lot of the Servlet 3.0 TODOs in the code, even when he had implemented the appropriate feature. Those certainly need cleaning up. Looking at Peter's test case - along with the other issues folks have raised in Bugzilla for the 7.0.0 release - is on my todo list but like the other committers I have a day job. Whilst many of the committers are fortunate enough (me included) to be able to allocate some work time to Tomcat development, it doesn't follow one of the other committers will immediately have the time necessary to look at Peter's e-mail and comment in detail. I can't speak for the others, but my free time is currently occupied with another Tomcat 7 issue - namely http://tomcat.markmail.org/thread/25g353eqvqfqniiz Like any area of Tomcat, help is always appreciated. If you are interested in this issue and would like to help out I would encourage you to look at Peter's test case, compare the expected behaviour to what the spec defines and offer your view on whether there is a bug that needs fixing or not. If there is an issue, patches would be even better. Mark Cheers, Marc. Peter Roßbach wrote: Hi! I detected some Todo's at AsyncContext - AsyncContext.createListener We don't make a resource injection or make it configurable! Servlet 3.0 API comment: "This method supports resource injection if the given clazz represents a Managed Bean. See the Java EE platform and JSR 299 specifications for additional details about Managed Beans and resource injection." - I miss the is[Started,Completed] methods at AsyncContext interface The only way to detect a completed state at AsyncContext inside an AsyncListener is: if (ac.getResponse() != null) AsyncListener got an event, with empty state... -- Very strange! Can't we clear all AsyncListener after send complete and before we refresh the AsyncContext state? How can a user handle a completed situation? see o.a.c.core.TestAsyncListener - AsyncContext.start() dosen't really start a thread! We create wrapper of a Runnable, but we don't start a thread... Error handling seam a little bit strange. We only throw a RuntimeException(ex) and log an error! Servlet API comment: "Causes the container to dispatch a thread, possibly from a managed thread pool, to run the specified Runnable. The container may propagate appropriate contextual information to the Runnable." How can we implement that? Start everytime a new thread without pooling? Use the connector executor pool from request? Then we must extend the ProtocolHandler interface with getExecutor() signature. Use a separate Executor pool per Engine/Host or Context How do we have to implemented the error handling? - JioEndpoint has a timeout detection thread, but we don't start it! I easy fix it with revision 958362, but the polling strategy is slow and ineffectiv. I didn't make a test at NIO/APR-HTTP or AJP-Connectors. - After the timeout event is emitted, the completed method is automatically called! Servlet API 3.0 Spec says: ■In the event that an asynchronous operation times out, the container must run through the following steps: ■ Invoke the AsyncListener.onTimeout method on all the AsyncListener instances registered with the ServletRequest on which the asynchronous operation was initiated. ■ If none of the listeners called AsyncContext.complete() or any of the AsyncContext.dispatch methods, perform an error dispatch with a status code equal to HttpServletResponse.SC_INT
svn commit: r959428 - in /tomcat/tc5.5.x/trunk: ./ connectors/http11/src/java/org/apache/coyote/http11/ connectors/http11/src/java/org/apache/coyote/http11/filters/ container/webapps/docs/
Author: jfclere
Date: Wed Jun 30 20:43:36 2010
New Revision: 959428
URL: http://svn.apache.org/viewvc?rev=959428&view=rev
Log:
Arrange filter logic. Back port of r958911.
Modified:
tomcat/tc5.5.x/trunk/STATUS.txt
tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java
tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/filters/BufferedInputFilter.java
tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml
Modified: tomcat/tc5.5.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=959428&r1=959427&r2=959428&view=diff
==
--- tomcat/tc5.5.x/trunk/STATUS.txt (original)
+++ tomcat/tc5.5.x/trunk/STATUS.txt Wed Jun 30 20:43:36 2010
@@ -47,8 +47,3 @@ PATCHES PROPOSED TO BACKPORT:
-0: markt - Consensus was for disabled in 5.5.x
http://svn.apache.org/viewvc?view=revision&revision=749019
-1:
-
-* Arrange filter logic.
- http://svn.apache.org/viewvc?rev=958911&view=rev
- +1: jfclere, markt, rjung, jim
- -1:
Modified:
tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java?rev=959428&r1=959427&r2=959428&view=diff
==
---
tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java
(original)
+++
tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java
Wed Jun 30 20:43:36 2010
@@ -77,6 +77,12 @@ public class Http11AprProcessor implemen
protected static StringManager sm =
StringManager.getManager(Constants.Package);
+/*
+ * Tracks how many internal filters are in the filter library so they
+ * are skipped when looking for pluggable filters.
+ */
+private int pluggableFilterIndex = Integer.MAX_VALUE;
+
// --- Constructors
@@ -1699,6 +1705,8 @@ public class Http11AprProcessor implemen
//inputBuffer.addFilter(new GzipInputFilter());
outputBuffer.addFilter(new GzipOutputFilter());
+pluggableFilterIndex = inputBuffer.filterLibrary.length;
+
}
@@ -1717,7 +1725,7 @@ public class Http11AprProcessor implemen
(inputFilters[Constants.CHUNKED_FILTER]);
contentDelimitation = true;
} else {
-for (int i = 2; i < inputFilters.length; i++) {
+for (int i = pluggableFilterIndex; i < inputFilters.length; i++) {
if (inputFilters[i].getEncodingName()
.toString().equals(encodingName)) {
inputBuffer.addActiveFilter(inputFilters[i]);
Modified:
tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java?rev=959428&r1=959427&r2=959428&view=diff
==
---
tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
(original)
+++
tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Wed Jun 30 20:43:36 2010
@@ -78,6 +78,12 @@ public class Http11Processor implements
protected static StringManager sm =
StringManager.getManager(Constants.Package);
+/*
+ * Tracks how many internal filters are in the filter library so they
+ * are skipped when looking for pluggable filters.
+ */
+private int pluggableFilterIndex = Integer.MAX_VALUE;
+
// --- Constructors
@@ -1657,6 +1663,8 @@ public class Http11Processor implements
//inputBuffer.addFilter(new GzipInputFilter());
outputBuffer.addFilter(new GzipOutputFilter());
+pluggableFilterIndex = inputBuffer.filterLibrary.length;
+
}
@@ -1675,7 +1683,7 @@ public class Http11Processor implements
(inputFilters[Constants.CHUNKED_FILTER]);
contentDelimitation = true;
} else {
-for (int i = 2; i < inputFilters.length; i++) {
+for (int i = pluggableFilterIndex; i < inputFilters.length; i++) {
if (inputFilters[i].getEncodingName()
.toString().equals(encodingName)) {
inputBuffer.addActiveFilter(inputFilters[i]);
Modified:
tomcat/tc5.5.x/trunk/connectors/http11/src/java/org/apache/coyote/http11/filters/BufferedInputFilter.java
URL:
http://svn.apache.org/viewvc
DO NOT REPLY [Bug 49531] New: singlesignon failover not working on DeltaManager/cluster upon shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=49531
Summary: singlesignon failover not working on
DeltaManager/cluster upon shutdown
Product: Tomcat 6
Version: 6.0.26
Platform: HP
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: Cluster
AssignedTo: dev@tomcat.apache.org
ReportedBy: yok...@takedasd.com
Created an attachment (id=25672)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25672)
log
Tomcat 6.0.18, 20, 24, 26
OS: Linux 2.6.18-194.3.1.el5 #1 SMP Sun May 2 04:17:42 EDT 2010 x86_64 x86_64
x86_64 GNU/Linux
Jdk 1.6.0_20
When the node shuts down and destroys the context, singlesignon removes
sessions created for the context. Then, DeltaSession.expire() method is called
and then calls super.exire() method. This sequence of events signals to the
listeners and one of listeners sends the message to SimpleTpcCluster that
propagates the message to other nodes in the same cluster. Therefore, sso
session will be removed from other nodes upon shutdown.
I would like to request an enhancement that both sso session and regular
session identifiers should be retained on other nodes upon the node shutdown.
== DeltaSession.java ==
public void expire(boolean notify, boolean notifyCluster) {
if (expiring)
return;
String expiredId = getIdInternal();
if(expiredId != null && manager != null &&
manager instanceof DeltaManager) {
DeltaManager dmanager = (DeltaManager)manager;
CatalinaCluster cluster = dmanager.getCluster();
ClusterMessage msg = dmanager.requestCompleted(expiredId, true);
if (msg != null) {
if(dmanager.doDomainReplication()) {
cluster.sendClusterDomain(msg);
} else {
cluster.send(msg);
}
}
}
super.expire(notify);
if (notifyCluster) {
if (log.isDebugEnabled())
log.debug(sm.getString("deltaSession.notifying",
((ClusterManager)manager).getName(),
new Boolean(isPrimarySession()),
expiredId));
if ( manager instanceof DeltaManager ) {
( (DeltaManager) manager).sessionExpired(expiredId);
}
}
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37449] Two UserDatabaseRealm break manager user
https://issues.apache.org/bugzilla/show_bug.cgi?id=37449 --- Comment #4 from Bruno Braga 2010-06-30 17:53:45 EDT --- >From 2005 to now, is there any plan to implement it? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37449] Support multi-Realms at Engine element
https://issues.apache.org/bugzilla/show_bug.cgi?id=37449 --- Comment #6 from Chuck Caldarale 2010-06-30 18:25:00 EDT --- (In reply to comment #4) > From 2005 to now, is there any plan to implement it? Looks like it's already implemented, if you'd care to move up: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37449] Support multi-Realms at Engine element
https://issues.apache.org/bugzilla/show_bug.cgi?id=37449 Bruno Braga changed: What|Removed |Added CC||bgbr...@gmail.com Summary|Two UserDatabaseRealm break |Support multi-Realms at |manager user|Engine element --- Comment #5 from Bruno Braga 2010-06-30 18:21:55 EDT --- Based on comment 3, I would suggest change the title of this enhancement to something like "Support multi-Realms at Engine element". Check if it makes sense. Is there a workaround for this feature? I need to support two different LDAPs / Realms using tomcat. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49534] New: ForEachSupport handles unsupported items inconsistently
https://issues.apache.org/bugzilla/show_bug.cgi?id=49534 Summary: ForEachSupport handles unsupported items inconsistently Product: Taglibs Version: 1.2.0 Platform: PC Status: NEW Severity: normal Priority: P2 Component: Standard Taglib AssignedTo: dev@tomcat.apache.org ReportedBy: jboy...@apache.org When the "items" attribute contains an unsupported type an exception is thrown with a "FOREACH_BAD_ITEMS" error message. However, if it contains a value expression that evaluates to an unsupported type, no error occurs. An example would be the snippet: -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49534] ForEachSupport handles unsupported items inconsistently
https://issues.apache.org/bugzilla/show_bug.cgi?id=49534 --- Comment #1 from Jeremy Boynes 2010-07-01 01:04:26 EDT --- Created an attachment (id=25674) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25674) Patch to throw exception on invalid items in deferred expression This patch also removes commented out code that would have bound an deferred expression to the loop variable; this function is performed in LoopTagSupport and is not needed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] Questions in ForEachSupport
On Tue, Jun 29, 2010 at 11:45 PM, Jeremy Boynes wrote: > In bug 45197 https://issues.apache.org/bugzilla/show_bug.cgi?id=45197 Henri > wrote: > * Look at questions in the length method in ForEachSupport.java > * Look at commented out code in prepre in ForEachSupport.java > > By "in the length method" did you mean line #241 where the length gets set to > 0? That's > different to the non-deferred case which throws an exception on line #402. > I'd suggest we do > the same for both (throwing the exception). That was the one. And agreed - throwing a JspTagException makes sense. > The commented code in prepare that sets the itemsName EL variable is > redundant as that is > also done in LoopTagSupport line #532 (assuming the Apache implementation of > the JSTL > API). Looks like this can just be deleted. Looks good; and that would have been the commented code in question. The commented out ResultSet code below is also presumably just chaff, but it was the variable setting that was newly introduced. > if that sounds good, I'll contribute a patch for those changes. Many thanks :) Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49534] ForEachSupport handles unsupported items inconsistently
https://issues.apache.org/bugzilla/show_bug.cgi?id=49534 Henri Yandell changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED OS/Version||All --- Comment #2 from Henri Yandell 2010-07-01 02:16:30 EDT --- Looks great - thanks :) svn ci -m "Adding an exception when the type is not recognized in determineLengthAndType; and removing some unused variables/commented out lines in the prepare method. Thanks to Jeremy Boynes' patch to #49534" Sending impl/src/main/java/org/apache/taglibs/standard/tag/common/core/ForEachSupport.java Transmitting file data . Committed revision 959527. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r959527 - /tomcat/taglibs/standard/trunk/impl/src/main/java/org/apache/taglibs/standard/tag/common/core/ForEachSupport.java
Author: bayard
Date: Thu Jul 1 06:15:44 2010
New Revision: 959527
URL: http://svn.apache.org/viewvc?rev=959527&view=rev
Log:
Adding an exception when the type is not recognized in determineLengthAndType;
and removing some unused variables/commented out lines in the prepare method.
Thanks to Jeremy Boynes' patch to #49534
Modified:
tomcat/taglibs/standard/trunk/impl/src/main/java/org/apache/taglibs/standard/tag/common/core/ForEachSupport.java
Modified:
tomcat/taglibs/standard/trunk/impl/src/main/java/org/apache/taglibs/standard/tag/common/core/ForEachSupport.java
URL:
http://svn.apache.org/viewvc/tomcat/taglibs/standard/trunk/impl/src/main/java/org/apache/taglibs/standard/tag/common/core/ForEachSupport.java?rev=959527&r1=959526&r2=959527&view=diff
==
---
tomcat/taglibs/standard/trunk/impl/src/main/java/org/apache/taglibs/standard/tag/common/core/ForEachSupport.java
(original)
+++
tomcat/taglibs/standard/trunk/impl/src/main/java/org/apache/taglibs/standard/tag/common/core/ForEachSupport.java
Thu Jul 1 06:15:44 2010
@@ -26,7 +26,6 @@ import java.util.StringTokenizer;
import javax.el.ELContext;
import javax.el.ValueExpression;
-import javax.el.VariableMapper;
import javax.servlet.jsp.JspTagException;
import javax.servlet.jsp.jstl.core.IndexedValueExpression;
import javax.servlet.jsp.jstl.core.IteratedExpression;
@@ -237,8 +236,8 @@ public abstract class ForEachSupport ext
length = st.countTokens();
isIndexedValueExpression = false;
} else {
-//What does this mean if we get here???
-length=0;
+// unrecognized type
+throw new
JspTagException(Resources.getMessage("FOREACH_BAD_ITEMS"));
}
}
}
@@ -268,10 +267,6 @@ public abstract class ForEachSupport ext
if (rawItems != null) {
if (rawItems instanceof ValueExpression) {
deferredExpression = (ValueExpression)rawItems;
-ELContext myELContext = pageContext.getELContext();
-VariableMapper vm = myELContext.getVariableMapper();
-//String itemsName=deferredExpression.getExpressionString();
-//vm.setVariable(itemsName, deferredExpression);
items = toDeferredForEachIterator(deferredExpression);
} else {
// extract an iterator over the 'items' we've got
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r958362 - in /tomcat/trunk: java/org/apache/tomcat/util/net/JIoEndpoint.java test/org/apache/catalina/core/TestAsyncListener.java webapps/docs/changelog.xml
I am highly interessed why does my fix is wrong :-) Is my fix really wrong, you can revert my checkin. Today I present the new Tomcat 7 release at Java User Forum Stuttgart (Germany). Many thanks, Peter Am 01.07.2010 um 08:20 schrieb jean-frederic clere: On 06/30/2010 09:15 PM, Peter Roßbach wrote: Hi Jean Frederic! Why does my change break the TCK? Is the current 12/09 servlet spec not correct? How must the async timeout functionalty work? Can you comment my other findings, please? I will have a look today to the stuff. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
