Re: [5.0] [PROPOSAL] Make output buffer size limit configurable

Marc, It can also be useful if you have a client that doesn't support "chunked encoding" - which is probably true for a _lot_ of scripting tools. If there is any other way to have the response not use chunked encoding, then I agree this is not needed. Do we still support HTTP/1.0 or some request h

Re: [5.0] [PROPOSAL] Make output buffer size limit configurable

It can also be useful if you have a client that doesn't support "chunked encoding" - which is probably true for a _lot_ of scripting tools. If there is any other way to have the response not use chunked encoding, then I agree this is not needed. Do we still support HTTP/1.0 or some request header t

Re: [5.0] [PROPOSAL] Make output buffer size limit configurable

Remy, Jan Luehe wrote: Currently, the limit up to which the size of an org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the original buffer size: public OutputBuffer(int size) { bb = new ByteChunk(size); bb.setLimit(size); ... cb = new

Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteConnector.java CoyoteRequest.java

Remy, luehe 2003/07/10 08:51:40 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java Log: Consider CoyoteConnector's bufferSize property when creating CoyoteRequest objects Why break the no arg constructor design

[5.0] [PROPOSAL] Make output buffer size limit configurable

Currently, the limit up to which the size of an org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the original buffer size: public OutputBuffer(int size) { bb = new ByteChunk(size); bb.setLimit(size); ... cb = new CharChunk(size); cb.setLim

Re:cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

Remy, > > P.S.: I'm also +1 for removing the CertificatesValve, since it is > > confusing to have several valves essentially doing the same thing. > > There's no need to hardcode the authenticator, you only need to add it > in startup.Authenticators.properties, and it will be added in the > pipel

Re:cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

Bill, > SSLAuthenticator makes a request for a special Request attribute > ("org.apache.coyote.request.X509Certificate"), which fires off an Action > hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary. > > I changed TC 5 a little while back to do a lazy-evaluation of the

Re: cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

Remy/Bill, > Ouch, that's one nasty hack. > -1, please revert it. > > There are callbacks to the processor to evaluate the SSL related > attributes. If something is broken, this should be fixed, but using that > pattern. I believe get/setSocket are useless, and the calls should be > entierely rem

Re: [5.0] Commons dependencies

Remy & others, > Here's the list of the components which will need to be released as > stable before Tomcat 5.0 gets stable. I'm associating a proposed "owner" > for the component, based on past interactions with the components. > > - el: Core JSP 2.0 feature; this is a critical component, and ne

[PATCH] RequestDispatcher.forward() problem with wrapped requests

I am fixing a bug filed by Ryan Lubke (Bugtraq 4871238). I do have a fix in place, but I would like to make sure it's appropriate. Consider the following scenario: Servlet1 acquires a RequestDispatcher and forwards the request to Servlet2. However, before forwarding the request, it wraps the reque

Re: JSP API javadocs out-of-date

Remy, > Jan Luehe wrote: > > I've noticed the JSP API javadocs at > > > > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jspapi > > > > are out-of-date, and I'm wondering what I need to do in order to sync > > them up with the latest API versi

JSP API javadocs out-of-date

I've noticed the JSP API javadocs at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jspapi are out-of-date, and I'm wondering what I need to do in order to sync them up with the latest API versions at jakarta-servletapi-5. The JSP API javadocs in the nightly build of the tomcat-docs webapp ar

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

White, > But would it be a nice idea to use Log 4J through out tomcat? no, we want to preserve the abstraction level provided by commons-logging, which provides support for log4j in addition to other logging packages. Jan > comments.. > Jan Luehe <[EMAIL PROTECTED]> wrote:J

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

Hans, > > Jasper currently uses its own private logging facility implemented > > in the org.apache.jasper.logging package. This is inconsistent with > > the way the other Tomcat subsystems perform logging > > (by leveraging the commons-logging package). > > > > Proposal is to remove org.apache.ja

[PROPOSAL] Replace Jasper's logging facility with commons-logging

Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls

RE: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag

Dimitry: > And JSP.10.5.9: > "The scope value for a variable implies what methods may affect its > value and thus > where synchronization is needed: > - for NESTED, after doInitBody and doAfterBody for a tag handler > implementing > BodyTag, and after doStartTag otherwise. > - for AT_BEGIN, afte

Re: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag

Dimitry: I still believe your patch is invalid, as it would amount to synchronizing AT_BEGIN and NESTED variables after calling doStartTag(). However, the spec explicitly mentions that for tag handlers implementing BodyTag, those variables must not be synchronized after doStartTag(), *only* after

Re: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag

> Dimitry, > > > In jasper2, I have found one interesting bug. It hapens when tag > > implements BodyTag interface and doStartTag returns EVAL_BODY_INCLUDE. > > > > See test-case and patch attached. The patch tested under Tomcat 4.1.18. > > the current synchronization behaviour your are seeing

Re: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag

Dimitry, > In jasper2, I have found one interesting bug. It hapens when tag > implements BodyTag interface and doStartTag returns EVAL_BODY_INCLUDE. > > See test-case and patch attached. The patch tested under Tomcat 4.1.18. the current synchronization behaviour your are seeing is compliant wit

Re: [PROPOSAL] EL Transition to Jakarta Commons

Costin, > +1 > > Is the EL depenent on javax.servlet or javax.servlet.jsp, or is it > completely independent and useable in non-servlet-container environments ? There are some dependencies on servlet containers. For example, the EL supports implicit objects, one of them being "pageContext", so i

Re: [PROPOSAL] EL Transition to Jakarta Commons

Craig, > +1, but you'll probably also want to post this on COMMONS-DEV :-). My plan was to post this to tomcat-dev and taglibs-dev first, get feedback, and then post it to commons-dev, but I guess it is OK to get commons-dev involved right away. I just posted the proposal there, too. Thanks,

[PROPOSAL] EL Transition to Jakarta Commons

I'd like to resume discussion on a proposal circulated by James Strachan on March 13, 2002, about turning the implementation of JSTL's expression language (EL) into a reusable component and moving it from the Standard Taglib, an implementation of JSTL hosted by jakarta-taglibs, to jakarta-commons,

Re: [PATCH][JASPER2] Simple patch for one of the resource error messages.

Ryan, > I think that the following error message is incorrect: > > - Scripting elements ( <%@, <%!, <%=, <% ) are disallowed here. > > Since directives (<%@) are not scripting elements. > > I've attached a patch to correct the messages.properties. Thanks for your patch! I've slightly modifie

Re: Why can I not use attributes "lang" and "maxRows" in a custom tag

Jim, > Tomcat 4.1.12 does not accept a custom tag with attributes "lang" > or "maxRows". When I asked about this on the Tomcat users list I was > informed that it also does not accept the attribute "class". > > Specifically if I define those attributes then when the jsp is compiled I > get an "un

Re: [PATCH] Setting TagHandlerPool size as InitParameter for jasper servlet

Torsten, I've applied your patch. However, I found the following issues with it: > PATCH Content: > Adding handling of init parameter "tagPoolSize" > Changing Generator to use tagPoolSize for initialize TagHandlerPool > > This should, hopefully, be correctly formatted. > Index: resources/mes

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparser ASCIIReader.java UCSReader.java UTF8Reader.java XMLEncodingDetector.java

Remy, > [EMAIL PROTECTED] wrote: > > > luehe 2002/11/06 12:14:20 > > > > Modified:jasper2/src/share/org/apache/jasper/compiler > > ErrorDispatcher.java JspReader.java JspUtil.java > > PageDataImpl.java PageInfo.java > >

Re: 4.1.10 Tag Bug

Milt, > > Ralph, > > > > > I think there is a serious bug in the jsp compiler from tomcat 4.1.10. > > > The compiler creates wrong code for nested variables. Here an example > > > that works with 4.1.9 and does not with 4.1.10 > > > > this is now fixed. > > What version/realease/nightly build is

Re: 4.1.10 Tag Bug

Ralph, > I think there is a serious bug in the jsp compiler from tomcat 4.1.10. > The compiler creates wrong code for nested variables. Here an example > that works with 4.1.9 and does not with 4.1.10 this is now fixed. Jan -- To unsubscribe, e-mail: For addition

Re: 4.1.10 Tag Bug

Ralph, > I think there is a serious bug in the jsp compiler from tomcat 4.1.10. > The compiler creates wrong code for nested variables. Here an example > that works with 4.1.9 and does not with 4.1.10 OK, I really think the spec needs to be clarified in this respect. JSP.10.5.9 ("VariableInfo")

Re: [4.1.10] New test milestone released

Costin, > Something like: > > > > "> > > It'll fist generate a duplicated declaration ( once at top level, > once at block level ) for _jspx_sub_1, and then look for a > variable named 'sub' that is not declared. I am unable to reproduce your problem. The above test case compiles fine for

Re: [4.1.10-dev] Jasper 2 problems

Remy, > I'm testing 4.1.10-dev before tagging, and I ran into some serious problems. > > Jasper 2 seems broken (in the TC 4 branch; the HEAD/TC 5 branch may be > broken as well, but I didn't have time to test it), and fails to compile > most pages from the admin webapp. my apologies! When bac

Re: Jasper2: serious problem with tag declarations

Costin, > > > - I have a > > > > > > > > > The generated code is: > > > a = (java.lang.Object) pageContext.findAttribute("a"); > > > a = (java.lang.Object) pageContext.findAttribute("a"); > > > a = (java.lang.Object) pageContext.findAttribute("a"); > > > ( i.e. 3 times the same line ). > >

Re: Jasper2: serious problem with tag declarations

Costin, > - I have a > > > The generated code is: > a = (java.lang.Object) pageContext.findAttribute("a"); > a = (java.lang.Object) pageContext.findAttribute("a"); > a = (java.lang.Object) pageContext.findAttribute("a"); > ( i.e. 3 times the same line ). > > Not a bug, but strange. this t

Re: Jasper2: serious problem with tag declarations

Costin, > How do we deal with nested tags of different type ? I don't have > a test case, but I assume someone may have a NESTED tag > 'foo' in 2 different tags, with different declared types ( String and > Integer ). The current generator seems to not create { }, > and I'm not sure how this

Re: Jasper2: serious problem with tag declarations

Costin, > > If those variable declaration problems are fixed, I'll release a new > > 4.1.6 milestone as soon as I can fix the JNDI problems. > > Not yet... > > I attached the failed jsp. > > Costin > > [...] > > <%@ page language="java

RE: Jasper2: serious problem with tag declarations

Hi Costin, > But there is still a problem - now if you have: > > > > > > > ( i.e. the same variable name ), it will fail with duplicated declaration, > the code will be: >Object i; >... >Object i; > > ( id is nested ). The above code fragment compiles fine for me. I

RE: Jasper2: serious problem with tag declarations

Hi Costin, > More info: > > The page is: > > <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %> > > > > Foo > > > > I get: > > a$jsp.java:75:25:75:25: Error: No entity named "id2" was found in this > environment. > > And the generated code is: > .

[PATCH] Custom tag scripting variables

As discussed with Kin-Man, the following patch (for Jasper2) addresses two issues related to scripting variables exposed by custom tags (via TagExtraInfo class or TLD): ISSUE 1: +++ According to the JSP spec, scripting variables with scope AT_BEGIN or AT_END are supposed to be visible from th

[PATCH] Tag pooling/reuse in Jasper 2 (RESENT)

ICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH

[PROPOSAL] Tag pooling/reuse in Jasper 2

Kin-Man and I have been throwing around some ideas of how to support tag pooling and reuse in Jasper 2. According to the spec, only tags with the same set of attributes may be reused (see JSP.10.1.1, p.163, "Lifecycle" section, item 3): [3] Note that since there are no guarantees on the state

[PATCH] Simplified scripting-variable declaration/synchronization in Generator.java

According to JSP.7.4 ("The Tag Library Descriptor Format"), it is illegal for a tag to define scripting variables in both its TLD and TagExtraInfo class. Jasper already enforces this, but its code generator makes separate method calls for declaring/synchronizing scripting variables from a TLD and

<    1   2