Re: re:tag plugin

2005-08-26 Thread Kin-man Chung
For practical purposes, I don't think you'll gain much using plugins
for c:set and c:out, since they are relatively simple, and the
overheads for invoking the corresponding tag handlers is relatively
minor.  You'll probably achieve most benefit if you can provide plugins
for them that only handle tags with no or empty bodies.

If you must, just for academic discussion, you can get to the body
content of a tag by generating codes to invoke pushBody() when you
enter the body, and popBody() when you leave.

- Kin-man

On Thu, 2005-08-25 at 21:07, wing lee wrote:
 Thanks a lot at first :-)
  
 By now I think on two occasions the body content should be used. Firstly in 
 the out tag, because some special characters should be converted,  so if body 
 content is output, the body content should be filtered. Secondly in the set 
 tag, if the body content is assigned to the variable, the body content should 
 be got at first.
  
 That's why I think there should be a method to get the body content.
  
 Now in the out tag, I just output the body content without filter. In the set 
 tag, when I have to use the body content, I invoke the method 
 dontUseTagPlugin. I don't know whether doing so is ok.
  
 Best regards,
 Li Jing
  
 
 
 
   
 -
 DO YOU YAHOO!?
   雅虎免费G邮箱-中国第一绝无垃圾邮件骚扰超大邮箱 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: tag plugin

2005-08-23 Thread Kin-man Chung
The method generateBody() is meant to continue to generate
codes for body of the tag, as usual.  What you want is a method
to generate codes to get the body content, which is certainly
doable, but is not currently available.  You are welcome to have
the first crack at extending the plugin framework if you like.  It'll
require invoking pushBody(), generateBody(), then popBody() to get the
body content, similar to the codes that are being generated for
fragments.  But I don't think you really need it though.

Attributes are much simpler, they are just expressions.

BTW, your English is just fine: no apologies needed.  :-)

-Kin-man

On Tue, 2005-08-23 at 02:33, wing lee wrote:
 Thanks for all your help.
  
 But I still have questions :-). I know that the body content of the tag is 
 the runtime entity. I think the value of some attributes is also runtime 
 entity, if its value can be EL. The method generateAttribute can generate the 
 code in the generated x_jsp.java file which returns the dynamic value of the 
 attribute. So I can write such code to get the dynamic value in the 
 x_jsp.java file:
  
 //in jsp file
 c:out value=${xxx}/
 //in the tag plugin file
 ctxt.generateJavaSource(String s = (String));
 ctxt.generateAttribute(value);
 ctxt.generateJavaSource(;);
  
 The generated code is:
  
 String s = (String) (Object)
  org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate
  (${xxx}, java.lang.Object.class, (PageContext)
  _jspx_page_context, null, false);
  
 But if I write such code:(just for example)
  
 //the jsp file
 c:out value=asd${xxx}/c:out
 //in the tag plugin file
 ctxt.generateJavaSource(String s = (String));
 ctxt.generateBody();
 ctxt.generateJavaSource(;);
  
 the generated code is:
  
 String s = (String) out.write((Object)
  org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate
  (${xxx}, java.lang.Object.class, (PageContext)
  _jspx_page_context, null, false));
  
 and this code's syntax is wrong.
  
 I think that there should be a method to provide the functionality similar to 
 the one of the generateAttribute which doesn't output the out.write source 
 code, so that I can use the body content in the generated file x_jsp.java.
  
 I am not so good at English so perhaps my expression is not very clear. Sorry 
 about that. 
 
 
   
 -
 DO YOU YAHOO!?
   雅虎免费G邮箱-中国第一绝无垃圾邮件骚扰超大邮箱 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: tag plugin

2005-08-22 Thread Kin-man Chung
The body content of a tag is a runtime entity, and you cannot
generally get it during compilation time, since it may contain
non-template texts.  You need to achieve what you want in another way,
such as the use of JSP fragments.

-Kin-man

On Sat, 2005-08-20 at 00:26, wing lee wrote:
 I think it's ok in the if tag. When the following code
  
 ctxt.generateJavaSource(if ( + condV + ){);
  ctxt.generateBody();
 ctxt.generateJavaSource(});
 
 is executed, the generated code is supposed to be:
 
 if(temp_name_of_condV){
 
 out.write(body_content);
 
 }
 
 the generateBody method not generates the code body_content, but the 
 out.write(body_content). so I can not write the code to get the value of 
 the body like following:
 
 String tempName = ctxt.getTemporaryVariable();
 
 ctxt.generateJavaSource(Object +tempName+=);
 
 ctxt.generateBody();
 
 ctxt.generateJavaSource(;);
 
 because the generated code will be like this:
 
 Object temp_name = out.write(body_content);
 not this:
 Object temp_name = body_content;
 
 so this is what confuses me.
 
 Remy Maucherat [EMAIL PROTECTED] 写道:
 wing lee wrote:
  I've tried the generateBody method, but it just generate such code 
  write.out(body content), don't return the value of the body content. 
 
 That's odd: it's supposed to continue evaluation and code generation for
 the body, not consider nested stuff as static text. There's a good
 example with the if tag plugin (although, as I said, I didn't test it
 at all, so maybe it's broken).
 
 public final class If implements TagPlugin {
 
 public void doTag(TagPluginContext ctxt) {
 String condV = ctxt.getTemporaryVariableName();
 ctxt.generateJavaSource(boolean  + condV + =);
 ctxt.generateAttribute(test);
 ctxt.generateJavaSource(;);
 if (ctxt.isAttributeSpecified(var)) {
 String scope = PageContext.PAGE_SCOPE;
 if (ctxt.isAttributeSpecified(scope)) {
 String scopeStr = ctxt.getConstantAttribute(scope);
 if (request.equals(scopeStr)) {
 scope = PageContext.REQUEST_SCOPE;
 } else if (session.equals(scopeStr)) {
 scope = PageContext.SESSION_SCOPE;
 } else if (application.equals(scopeStr)) {
 scope = PageContext.APPLICATION_SCOPE;
 }
 }
 ctxt.generateJavaSource(_jspx_page_context.setAttribute();
 ctxt.generateAttribute(var);
 ctxt.generateJavaSource(, new Boolean( + condV + ), + scope +
 ););
 }
 ctxt.generateJavaSource(if ( + condV + ){);
  ctxt.generateBody();
 ctxt.generateJavaSource(});
 }
 }
 
 Rémy
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
   
 -
 DO YOU YAHOO!?
   雅虎免费G邮箱-中国第一绝无垃圾邮件骚扰超大邮箱 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: New TLP draft

2005-04-06 Thread Kin-man Chung
It appears that my name (Kin-man Chung [EMAIL PROTECTED]) has been
dropped from the PMC.  Hope this is not intentional.  :-)


On Wed, 2005-04-06 at 05:15, Remy Maucherat wrote:
 Hi,
 
 Here's a new draft with the necessary updates.
 
 I suppose this needs to be sent to the PMC for approval. If this draft 
 is ok, I will send it there.
 
 Then there are infrastructure taks:
 - renaming mailing lists
 - moving CVS
 - new DNS and virtual host
 
 To summarize things:
 - I will be the proposed first PMC chair
 - PMC chairs will serve for one year, and cannot serve consecutive one 
 year terms (shouldn't this be put in the resolution text ? - if so, 
 please help writing it, as I can't write ASF resolution compliant language)
 - although the ASF infrastructure is quite aggressive in pushing 
 Subversion, I find it harder to work with than CVS at the moment 
 (including crucial - for me - revision graphs, and better tool support); 
 as a result, I think I would prefer keeping CVS for the time being
 - feel free to take any further actions to update the PMC list (as 
 proposed by Costin)
 
 Rmy
 
 --- Draft TLP resolution ---
 X. Establish the Apache Tomcat Project
 
 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the
 Foundation's purpose to establish a Project Management
 Committee charged with the creation and maintenance of
 open-source software related to the implementation of the
 Java Servlet and Java Server Pages specifications, for
 distribution at no charge to the public.
 
 NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache Tomcat PMC, be and
 hereby is established pursuant to Bylaws of the Foundation; and
 be it further
 
 RESOLVED, that the Apache Tomcat PMC be and hereby is
 responsible for the creation and maintenance of software
 related to creation and maintenance of open-source software
 related to the implementation of the Java Servlet and Java
 Server Pages specifications based on software licensed to
 the Foundation; and be it further
 
 RESOLVED, that the office of Vice President, Apache Tomcat be
 and hereby is created, the person holding such office to serve
 at the direction of the Board of Directors as the chair of the
 Apache Tomcat PMC, and to have primary responsibility for
 management of the projects within the scope of responsibility
 of the Apache Tomcat PMC; and be it further
 
 RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial members of the
 Apache Tomcat PMC:
 
 Jean-Francois Arcand ([EMAIL PROTECTED])
 Bill Barker ([EMAIL PROTECTED])
 Ian Darwin ([EMAIL PROTECTED])
 Jean-Frederic Clere ([EMAIL PROTECTED])
 Tim Funk ([EMAIL PROTECTED])
 Henri Gomez ([EMAIL PROTECTED])
 Filip Hanik ([EMAIL PROTECTED])
 Larry Isaacs ([EMAIL PROTECTED])
 Jim Jagielski ([EMAIL PROTECTED])
 Jan Luehe ([EMAIL PROTECTED])
 Costin Manolache ([EMAIL PROTECTED])
 Remy Maucherat ([EMAIL PROTECTED])
 Kurt Miller ([EMAIL PROTECTED])
 Glenn Nielsen ([EMAIL PROTECTED])
 Amy Roh ([EMAIL PROTECTED])
 Peter Rossbach ([EMAIL PROTECTED])
 Yoav Shapira ([EMAIL PROTECTED])
 Mark Thomas ([EMAIL PROTECTED])
 Mladen Turk ([EMAIL PROTECTED])
 Keith Wannamaker ([EMAIL PROTECTED])
 
 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Remy Maucherat
 be appointed to the office of Vice President, Apache Tomcat, to
 serve in accordance with and subject to the direction of the
 Board of Directors and the Bylaws of the Foundation until
 death, resignation, retirement, removal or disqualification, or
 until a successor is appointed; and be it further
 
 RESOLVED, that the initial Apache Tomcat PMC be and hereby is
 tasked with the creation of a set of bylaws intended to
 encourage open development and increased participation in the
 Apache Tomcat Project; and be it further
 
 RESOLVED, that the initial Apache Tomcat PMC be and hereby is
 tasked with the migration and rationalization of
 the Apache Jakarta PMC Tomcat subproject; and be it further
 
 RESOLVED, that all responsibility pertaining to
 the Jakarta Tomcat sub-project and encumbered upon
 the Apache Jakarta PMC are hereafter discharged.
 
 --- End draft TLP resolution ---
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED

Re: JSP Compile Hangs

2004-10-20 Thread Kin-man Chung
Please file a report on bugzilla.  If you also include a test case
(to save me some typing :)), I'll take a look to see where Jasper is
spending its time.  Did you said it was in commons-el?  That'd be bad.

-Kin-man

On Wed, 2004-10-20 at 00:43, Eric Blenkush wrote:
 On Oct 19, 2004, at 10:41 PM, Remy Maucherat wrote:
 
  Eric Blenkush wrote:
 
  Hi,
 
  On Tomcat 5.5.2 I am experiencing very long compile times(and hangs)  
  for certain JSP pages. The page has an EL expression like this:
 
  ${fn:toUpperCase((fn:toUpperCase((fn:toUpperCase((fn:toUpperCase((fn: 
  toUpperCase((fn:toUpperCase((fn:toUpperCase((fn:toUpperCase((fn: 
  toUpperCase((fn:toUpperCase((fn:toUpperCase((fn:toUpperCase((fn: 
  toUpperCase((fn:toUpperCase((fn:toUpperCase((fn: 
  toUpperCase(('b'}
 
  If you remove the extraneous parenthesis it will compile and execute  
  very quickly. However, if you add more nested calls to fn:toUpperCase 
   compiling will again take a very long time. So, this may be related 
  to  the number of nested expressions. This is just a test case 
  obviously  but I am generating JSPs automatically and it is difficult 
  if not  impossible to avoid EL statements with these nested function 
  calls.  Resin can compile and execute these pages very quickly but I 
  want to  stick with Tomcat.
 
  This is crucial to the project I am working on and if someone has an  
  idea of what is causing this and where to look in the tomcat source I 
   would appreciate it.
 
  Please don't whine. I hope you have tested this with 5.0.x as well.
 
  If you have a compilation problem specific to the Java compiler, you 
  obviously should:
  - report it to the Eclipse project
  - use Ant + javac to compile instead (remove the 
  jasper-compiler-jdt.jar and put ant.jar at the same spot)
 
  You may want to try to generate efficient code.
 
  Any bug filed about the Eclipse compiler (other than an integration 
  issue) will be marked as INVALID.
 
  Rmy
 
 
 The hang is happening when the .java file is being generated from the 
 .jsp file. I confirmed this by taking the commons-el-1.0 source and 
 modifying it to parse the same EL statement as given above and it never 
 completed.
 
 Any helpful comments on where to start looking to fix this are welcome.
 
 Thanks,
 Eric
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



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

2004-09-17 Thread Kin-man Chung
I have no problem getting rid of all those messages, since they are
no longer useful.

- Kin-man

On Fri, 2004-09-17 at 14:23, Amy Roh wrote:
  [EMAIL PROTECTED] wrote:
 
 amyroh  2004/09/17 14:02:34
 
   Modified:jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
jasper2/src/share/org/apache/jasper/runtime 
  HttpJspBase.java
jasper2/src/share/org/apache/jasper/security
 SecurityClassLoad.java
jasper2/src/share/org/apache/jasper/xmlparser
 ParserUtils.java UTF8Reader.java
   Log:
   More logging changes.
 
  You might want to get rid of the if (verbose) and other if 
  (debug_flag_with_funky_name) at the same time :)
 
 Yeah, I thought about that.  But I didn't want to just get rid of it in case 
 some folks are still using the property.
 
 Does anyone object to getting rid of debug/verbose property?
 
 Thanks,
 Amy
 
 
  Rmy 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Question on 5.0.23

2004-05-05 Thread Kin-Man Chung
Which watchdog is it?  Can you send me the other part (tld and tag handler)
of it?

If the tag is of a TAGDEPENDENT body type, then its body is should not
be evaluated.  It used to be evaluated in XML syntax, which is wrong and
which is what the patch intend to fix.  If this is the case, then the
golden file for the watchdog test should be replaced.

-Kin-man

 Date: Wed, 05 May 2004 02:26:32 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: Question on 5.0.23
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 I have some possible problems with Jasper and XML syntax. One example 
 from old watchdog:
 
 jsp:root
 xmlns:jsp=http://java.sun.com/JSP/Page; version=1.2
 xmlns:direct=urn:jsptld:/WEB-INF/tlds/example-taglib.tld
  
 
 jsp:text![CDATA[html
 titlepositiveDirectTldReference/title
 body
 ]]/jsp:text
 
 jsp:text![CDATA[
 
 ]]/jsp:text
 direct:test toBrowser=true att1=att1
 jsp:text![CDATA[
 Validated
 ]]/jsp:text
 /direct:test
 jsp:text![CDATA[
 /body
 /html
 ]]/jsp:text
 
 /jsp:root
 
 Generates for the tag:
 
  do {
out.write(jsp:text);
out.write(\n);
out.write(Validated\n);
out.write(/jsp:text);
out.write('\n');
int evalDoAfterBody = _jspx_th_direct_test_0.doAfterBody();
member = (String) _jspx_page_context.findAttribute(member);
if (evalDoAfterBody != 
 javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN)
  break;
  } while (true);
 
 So the tag body is not getting evaluated. I suspect this patch, which 
 was not yet present in 5.0.22:
 
 kinman  2004/04/16 16:22:30
 
Modified:jasper2/src/share/org/apache/jasper/compiler
  JspDocumentParser.java
Log:
- Fix a bug where a custom tag with tagdependent body type is not
  handled correctly in XML syntax.  The fix would have been trivial 
 if not
  for the cases where jsp:attribute and/or jsp:body is present.
 
 I'm not too big on tags though, so I don't know for sure if it's even a bug.
 
 (et hop, 5.0.25 ... :/ )
 
 Rémy
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tomcat 5.0.20 Issue

2004-03-30 Thread Kin-Man Chung
Your test for bad beans is much weaker than what it is now.  For instance,
you do not catch the case where the bean class is abstract.

However, I am sympathetic to your view on this.  If I can be convinced that
we have covered all checks that we can do without too much trouble, I'll
fix Jasper.

-Kin-man

 Date: Tue, 30 Mar 2004 08:30:05 -0600
 From: Jess Holle [EMAIL PROTECTED]
 Subject: Re: Tomcat 5.0.20 Issue
 To: Tomcat Developers List [EMAIL PROTECTED]
 X-OriginalArrivalTime: 30 Mar 2004 14:30:06.0040 (UTC) 
FILETIME=[7EEF4580:01C41663]
 
 Kin-Man Chung wrote:
 
 I think your only valid point is the one about the need to make
 errorOnUseBeanInvalidClassAttribute be switchable from Jspc main,
 but we are not bundling jspc scripts anymore, so I didn't feel there
 is a need for it.  Anyway, its value can be set with an ant task.
 
 Otherwise, Jasper behaves the same as before when
 errorOnUseBeanInvalidClassAttribute is set to false.  Well, maybe it
 take more time to compile, but that's a compile-time vs. runt-time
 tradeoff that all compilers make.
 
 The ideas behind the fix, both in the Jasper and the JSP 2.0 spec, is
 to allow the Jasper to generate faster code and to catch as much
 errors as possible at compile time.  For the embedded compilations, the
 comile environment is the same as the runitme (request time) environment,
 so there is no problem.  For Jspc compilations, you'll just need to make
 sure that they are the same, otherwise you'll need to set
 errorOnUseBeanInvalidClassAttribute to false there.
   
 
 I'm not arguing with the overall intent of your change.  Rather I 
 believe that calling the constructor during compilation is wasteful and 
 improper as the environment *can* differ between compilation and 
 runtime.  Also, the fact that a failure to compile in this fashion 
 generates a partial Java source means that once a compilation fails due 
 to an environmental issue it will continue to fail even when the 
 environment is corrected (e.g. when another server comes back up).  
 That's certainly not appropriate.
 
 If you have ideas about how to modify Generator that works better, please
 submit a patch, and I'll see if it can be incorporated.
   
 
 I must profess ignorance as to how to submit an official patch (e.g. how 
 to generate one), but here's a diff with Generator.java version 1.230 
 from CVS of what I'm suggesting:
 
 22a23
   *import java.lang.reflect.Constructor;*
 1224c1225,1226
  bean.newInstance();
 ---
   // Next line will throw exception if
 public no-args constructor cannot be found
   *Constructor  constructor =
 bean.getConstructor( new Class[] {} );
 *
 
 Essentially, I'm suggesting we check for the existence of the default 
 constructor, but don't call it.  That takes the same amount of real code 
 (2 more lines thanks to my import and gratuitous comment) and avoids (1) 
 actually constructing the bean during compilation and (2) making any 
 unnecessary assumptions about compilation vs. runtime environmental 
 conditions.
 
 Applying this diff to Generator.java addresses my issue and I believe is 
 an overall improvement and better aligned with the JSP specification.  I 
 would greatly appreciate it if this could be incorporated into the 
 Jasper/Tomcat source stream.
 
 --
 Jess Holle
 [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tomcat 5.0.20 Issue

2004-03-24 Thread Kin-Man Chung
I think your only valid point is the one about the need to make
errorOnUseBeanInvalidClassAttribute be switchable from Jspc main,
but we are not bundling jspc scripts anymore, so I didn't feel there
is a need for it.  Anyway, its value can be set with an ant task.

Otherwise, Jasper behaves the same as before when
errorOnUseBeanInvalidClassAttribute is set to false.  Well, maybe it
take more time to compile, but that's a compile-time vs. runt-time
tradeoff that all compilers make.

The ideas behind the fix, both in the Jasper and the JSP 2.0 spec, is
to allow the Jasper to generate faster code and to catch as much
errors as possible at compile time.  For the embedded compilations, the
comile environment is the same as the runitme (request time) environment,
so there is no problem.  For Jspc compilations, you'll just need to make
sure that they are the same, otherwise you'll need to set
errorOnUseBeanInvalidClassAttribute to false there.

If you have ideas about how to modify Generator that works better, please
submit a patch, and I'll see if it can be incorporated.

-Kin-man

 Date: Wed, 24 Mar 2004 09:50:43 -0600
 From: Jess Holle [EMAIL PROTECTED]
 Subject: Tomcat 5.0.20 Issue
 To: Tomcat Developers List [EMAIL PROTECTED]
 X-OriginalArrivalTime: 24 Mar 2004 15:50:43.0599 (UTC) 
FILETIME=[C3DDB1F0:01C411B7]
 
 Jess Holle wrote:
 
  Works just great in quick testing at least.
 
  I'm still waiting for my precompilation script to return to determine 
  whether Jasper still compiles everything it used to (and should have).
 
 Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages 
 (which Tomcat 5.0.19 compiled just fine).
 
 The issue can be traced directly to a single entry in the change log:
 
 Add some intellignece to the compiler for generating code for
 useBean action. Generate direct instantiation (use new) when
 possible, use bean.instantiate when bean name is specified, and for
 the case of invalid bean class, either issue a translation time
 error (instead of javac error), or generate codes to throw
 InstantiationException at runtime, depending on a new compiler
 switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman)
 
 There are several issues with this change:
 
1. The new logic assumes that the bean can be directly instantiated
   /at compile time/ and throws a page compilation error when this is
   not the case.
   * There are beans that can be directly instantiated at run
 time but not at compile time (e.g. upon precompilation). 
 This was the case in all 6 of our failures.  [Examples as to
 when this might occur include requirements for databases
 being accessible, other servers running, etc, etc, for
 successful bean instantiation.]
   * The error occurs in such a way that a partial Java source
 file is written, so later attempts to recompile the page
 (when the runtime environment is duplicated) also fail
 unless the partial Java source file is first deleted.
2. I note the errorOnUseBeanInvalidClassAttribute setting but there
   are issues here as well:
   * The default value, true, breaks existing code.
   * If errorOnUseBeanInvalidClassAttribute  is set to false:
 o Instantiation of some (e.g. session or application
   scope) beans can be time and/or resource consuming. 
   Besides being an invalid test as to whether a bean can
   be directly instantiated, instantiating such beans
   during compilation can be costly.  [The combined time
   for precompiling all pages was longer in 5.0.20 with
   this behavior in place than when I removed it.]
 o The new behavior will cause beans to be instantiated
   via Beans.instantiate() rather than directly
   instantiated when compile time direct instantiation
   fails.  This leads to a performance degradation
   whenever a bean has a runtime instantiation dependency.
   * As best I can tell, errorOnUseBeanInvalidClassAttribute is
 not accessible from / exposed via JspC main -- which I use
 from my pre-compilation scripts for various reasons.
 
 Due to these issues I have reverted this change in Generator to the 
 5.0.19 state (leaving the other valuable changes in this class intact).  
 Once I did so all 985 JSP pages compiled -- including the 6 that had 
 previously failed.
 
 I would urge that this change be reverted -- either in this release (or 
 an immediate 5.0.21 release) or immediately changed in HEAD for the next 
 release.
 
 --
 Jess Holle
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspWriterImpl.java

2004-03-18 Thread Kin-Man Chung
-1.  The patch breaks the spec.

According to JSP 2.0 spec, JSP.5.5 (p1-111),

If the page output was unbuffered and anything has been written to
it, an attempt to forward the request will result in an
IllegalStateException.

-Kin-man
 
 Date: Thu, 18 Mar 2004 21:05:17 +
 From: [EMAIL PROTECTED]
 Subject: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime 
JspWriterImpl.java
 To: [EMAIL PROTECTED]
 
 markt   2004/03/18 13:05:17
 
   Modified:jasper2/src/share/org/apache/jasper/runtime
 JspWriterImpl.java
   Log:
   - Fix bug 13499. Remove unnecssary bufferSize check
   - Ported from TC4
   
   Revision  ChangesPath
   1.10  +0 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspWriterImpl.
java
   
   Index: JspWriterImpl.java
   ===
   RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspW
riterImpl.java,v
   retrieving revision 1.9
   retrieving revision 1.10
   diff -u -r1.9 -r1.10
   --- JspWriterImpl.java  17 Mar 2004 19:23:04 -  1.9
   +++ JspWriterImpl.java  18 Mar 2004 21:05:17 -  1.10
   @@ -139,9 +139,6 @@
 * Discard the output buffer.
 */
public final void clear() throws IOException {
   -if (bufferSize == 0)
   -throw new IllegalStateException(
   -getLocalizeMessage(jsp.error.ise_on_clear));
if (flushed)
throw new IOException(

getLocalizeMessage(jsp.error.attempt_to_clear_flushed_buffer));
   
   
   
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspWriterImpl.java

2004-03-18 Thread Kin-Man Chung
The action jsp:forward generates a call to PageContextImpl.forward(),
so the patch affects how this action works.  The following test

%@ page buffer=none %
jsp:forward page=test.jsp/

used to raise an ISE, now it does not.  The test for buffersize might
not be the best way to implement the part of the spec (that was before
my time), but it got the job done.  The patch may (and should) break
some TCK tests.

-Kin-man

 Date: Thu, 18 Mar 2004 22:23:12 +
 From: Mark Thomas [EMAIL PROTECTED]
 Subject: RE: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime 
JspWriterImpl.java
 To: 'Tomcat Developers List' [EMAIL PROTECTED]
 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
 Thread-index: AcQNM+1cLsjNLxfdTQ2XKdmvPyCgnAAAa/UA
 
 Kin-man,
 
 The original bug report was that Jasper threw an exception on an immediate
 pageContext.forward() on an unbuffered page. My reading of the spec is that 
this
 shouldn't happen. I can't see how this check helps meet the part of the spec 
you
 quoted.
 
 Am I being stupid and missing the blindingly obvious here?
 
 Mark
 
  -Original Message-
  From: Kin-Man Chung [mailto:[EMAIL PROTECTED] 
  Sent: Thursday, March 18, 2004 9:57 PM
  To: [EMAIL PROTECTED]
  Subject: Re: cvs commit: 
  jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runt
  ime JspWriterImpl.java
  
  -1.  The patch breaks the spec.
  
  According to JSP 2.0 spec, JSP.5.5 (p1-111),
  
  If the page output was unbuffered and anything has been 
  written to
  it, an attempt to forward the request will result in an
  IllegalStateException.
  
  -Kin-man
   
   Date: Thu, 18 Mar 2004 21:05:17 +
   From: [EMAIL PROTECTED]
   Subject: cvs commit: 
  jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime 
  JspWriterImpl.java
   To: [EMAIL PROTECTED]
   
   markt   2004/03/18 13:05:17
   
 Modified:jasper2/src/share/org/apache/jasper/runtime
   JspWriterImpl.java
 Log:
 - Fix bug 13499. Remove unnecssary bufferSize check
 - Ported from TC4
 
 Revision  ChangesPath
 1.10  +0 -3  
  jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runt
  ime/JspWriterImpl.
  java
 
 Index: JspWriterImpl.java
 
  ===
 RCS file: 
  /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j
  asper/runtime/JspW
  riterImpl.java,v
 retrieving revision 1.9
 retrieving revision 1.10
 diff -u -r1.9 -r1.10
 --- JspWriterImpl.java  17 Mar 2004 19:23:04 -  1.9
 +++ JspWriterImpl.java  18 Mar 2004 21:05:17 -  1.10
 @@ -139,9 +139,6 @@
   * Discard the output buffer.
   */
  public final void clear() throws IOException {
 -if (bufferSize == 0)
 -throw new IllegalStateException(
 -
  getLocalizeMessage(jsp.error.ise_on_clear));
  if (flushed)
  throw new IOException(
  
  getLocalizeMessage(jsp.error.attempt_to_clear_flushed_buffer));
 
 
 
   
   
  -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
   
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

2004-02-02 Thread Kin-Man Chung
-1.

Remy, please reread JSP 2.0 spec, p 1-101,1-102.  Bullet .2 of the Semantics
section was added to allow for this kind of optimization.  Bullet .5 and .6
will be executed ONLY IF the container choose not to issue translation errors.

-Kin-man

 Date: Mon, 02 Feb 2004 18:18:01 +
 From: [EMAIL PROTECTED]
 Subject: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler 
Generator.java
 To: [EMAIL PROTECTED]
 
 remm2004/02/02 10:18:01
 
   Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
   Log:
   - Revert useBean optimization done by Kin-Man, as it seems to violate the
 spec wording (which basically says that an error should occur at runtime 
if the class
 is not a JavaBean).
   - Bug 26507.
   
   Revision  ChangesPath
   1.217 +31 -35
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.jav
a
   
   Index: Generator.java
   ===
   RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Gen
erator.java,v
   retrieving revision 1.216
   retrieving revision 1.217
   diff -u -r1.216 -r1.217
   --- Generator.java  31 Jan 2004 01:56:28 -  1.216
   +++ Generator.java  2 Feb 2004 18:18:00 -   1.217
   @@ -1261,41 +1261,37 @@
className =
attributeValue(beanName, false, String.class);
}
   -out.printil(try {);
   -out.pushIndent();
   -out.printin(name);
   -out.print( = ();
   -out.print(type);
   -out.print() java.beans.Beans.instantiate();
   -out.print(this.getClass().getClassLoader(), );
   -out.print(className);
   -out.println(););
   -out.popIndent();
   -/*
   - * Note: Beans.instantiate throws 
ClassNotFoundException
   - * if the bean class is abstract.
   - */
   -out.printil(} catch (ClassNotFoundException exc) {);
   -out.pushIndent();
   -out.printil(
   -throw new 
InstantiationException(exc.getMessage()););
   -out.popIndent();
   -out.printil(} catch (Exception exc) {);
   -out.pushIndent();
   -out.printin(throw new ServletException();
   -out.print(\Cannot create bean of class \ + );
   -out.print(className);
   -out.println(, exc););
   -out.popIndent();
   -out.printil(}); // close of try
} else {
// Implies klass is not null
   -// Generate codes to instantiate the bean class
   -out.printin(name);
   -out.print( = new );
   -out.print(klass);
   -out.println((););
   +className = quote(klass);
}
   +out.printil(try {);
   +out.pushIndent();
   +out.printin(name);
   +out.print( = ();
   +out.print(type);
   +out.print() java.beans.Beans.instantiate();
   +out.print(this.getClass().getClassLoader(), );
   +out.print(className);
   +out.println(););
   +out.popIndent();
   +/*
   + * Note: Beans.instantiate throws ClassNotFoundException
   + * if the bean class is abstract.
   + */
   +out.printil(} catch (ClassNotFoundException exc) {);
   +out.pushIndent();
   +out.printil(
   +throw new InstantiationException(exc.getMessage()););
   +out.popIndent();
   +out.printil(} catch (Exception exc) {);
   +out.pushIndent();
   +out.printin(throw new ServletException();
   +out.print(\Cannot create bean of class \ + );
   +out.print(className);
   +out.println(, exc););
   +out.popIndent();
   +out.printil(}); // close of try
/*
 * Set attribute for bean in the specified scope
 */
   
   
   
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, 

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

2004-02-02 Thread Kin-Man Chung
Agreed that the spec can be clearer.  :-)

This has been discussed by the Spec expert group, and bullet .2 was added
because some vendors wanted it.  I'll check with the spec lead for a
clarification.

Also agreed that this breaks backward compatibility; but it not really too
bad.  I think a lot of users would rather have the error at compilation
time than at runtime.  What can you do with an instantiation error at
runtime?

If we are really concern about BC, then we can add another compilation
option to revert to old behavior.  I really don't like another switch, but
if it'll make people happy...

-Kin-man

 Date: Mon, 02 Feb 2004 19:41:54 +0100
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler 
Generator.java
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Kin-Man Chung wrote:
  -1.
  
  Remy, please reread JSP 2.0 spec, p 1-101,1-102.  Bullet .2 of the Semantics
  section was added to allow for this kind of optimization.  Bullet .5 and .6
  will be executed ONLY IF the container choose not to issue translation 
errors.
 
 I cannot really understand what the fragment really means, so I don't 
 know. I had the impression that it implied that the error should be at 
 runtime.
 I recommend the change is reverted as I did, as many users will likely 
 make the same mistake, since the specification is impossible to 
 understand (if you are right and your change indeed does not break the 
 specification). This will also create compilation errors when upgrading 
 from TC 4 to TC 5.
 
 Rémy
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

2004-02-02 Thread Kin-Man Chung

 Date: Mon, 02 Feb 2004 20:17:29 +0100
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler 
Generator.java
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Kin-Man Chung wrote:
  Agreed that the spec can be clearer.  :-)
  
  This has been discussed by the Spec expert group, and bullet .2 was added
  because some vendors wanted it.  I'll check with the spec lead for a
  clarification.
 
 Ok.
 
  Also agreed that this breaks backward compatibility; but it not really too
  bad.  I think a lot of users would rather have the error at compilation
  time than at runtime.  What can you do with an instantiation error at
  runtime?
 
 Nothing, but some don't care: they never intended their page to be 
 called without the right attribute in the right scope, so the case where 
 their JavaBean is instantiated never happens.

Then EL should be used in this case.

 
  If we are really concern about BC, then we can add another compilation
  option to revert to old behavior.  I really don't like another switch, but
  if it'll make people happy...
 
 No new switch, please ;) So we have to decide one or the other.
 So do you want me to revert the patch ?
 

I'd rather you check with me first before the patch, but since it is
already done, let's wait for the spec clarification before we do anything.
A revert on a revert would make us look really silly.  :-)

-Kin-man

 Rémy
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Understanding jakarta-tomcat-4.0 cvs source base / jasper

2003-12-15 Thread Kin-Man Chung
The source for Jasper in Tomcat 4.1.29 is from j-t-j/jasper2 with
Tomcat_4_branch tag.  The head branch is for Tomcat 5.

A lot of bugs filed against Tomcat 4.1.x has been fixed in Tomcat 5.
Unfortunately I don't have cycles to apply the fixes to 4.1.x.  It would
be great if someone can do that, and I can help and/or anser questions if
needed.

The branch jakarta-tomcat-4.0/jasper was used for Tomcat 4.0.x releases,
and I don't think we are making new releases for Tomcat 4.0.x.

-Kin-man

 Date: Mon, 15 Dec 2003 12:42:30 -0700
 From: Jeff Tulley [EMAIL PROTECTED]
 Subject: Understanding jakarta-tomcat-4.0 cvs source base / jasper
 To: [EMAIL PROTECTED]
 Content-disposition: inline
 
 Quick question - Does the jasper that ships with Tomcat 4.1.29 come from
 the source code in jakarta-tomcat-4.0/jasper, or is it from the
 jakarta-tomcat-jasper CVS module?
 
 I am looking at some bugs in Bugzilla against Jasper, where they
 complain about something in j-t-4.0/jasper/src/(some class), and the bug
 is fixed in j-t-j/jasper2/src   I do not know whether to mark the bug as
 fixed or investigate further.
 
 If the answer turns out that the source code in j-t-4/jasper is NOT
 being used, what is there against removing it to avoid confusion?
 
 Jeff Tulley  ([EMAIL PROTECTED])
 (801)861-5322
 Novell, Inc., The Leading Provider of Net Business Solutions
 http://www.novell.com
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Jasper used for Tomcat 4.0.6

2003-10-30 Thread Kin-Man Chung
The code for Jasper in 4.0.x is in the module jakarta-tomcat-4.0.

 Date: Thu, 30 Oct 2003 14:51:13 -0600
 From: Ken Sipe [EMAIL PROTECTED]
 Subject: Jasper used for Tomcat 4.0.6
 To: [EMAIL PROTECTED]
 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
 Importance: Normal
 X-Priority: 3 (Normal)
 X-MSMail-priority: Normal
 
 There are uses with the currect Jasper JspC compiler in the current Tomcat
 4.1.x.  It works fine in Tomcat 4.0.x.  I was looking to see the diff on
 them and I can't find a label in CVS that maps to code for Tomcat 4.0.x.
 
 Could someone explain where the JspC code is for Tomcat 4.0 stuff.  It
 doesn't appear to be under the jasper code base.  Although I see tomcat 33
 and 4.1 references.
 
 Thanks,
 Ken
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] New builds

2003-10-29 Thread Kin-Man Chung

 Date: Wed, 29 Oct 2003 11:32:58 +0100
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: [VOTE] New builds
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 ballot
 Release 4.1.29 as Stable ?
 [ ] Yes
 [ ] No
 /ballot
 
 ballot
 Release 5.0.14 as Beta ?
 [X] Yes

Jasper seems solid.

 [ ] No
 /ballot
 
 Rémy
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [5] IndexOutOfBoundsException from CharChunk

2003-10-15 Thread Kin-Man Chung
I believe 23805 is unrelated to my problem, and may even be invalid.
Mine comes from CharChunk.  To refresh the memory, the stack trace is

Servlet.service() for servlet jsp threw exception
java.lang.IndexOutOfBoundsException
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:132)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:191)
at org.apache.tomcat.util.buf.WriteConvertor.write(C2BConverter.java:228
)
at org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:120
)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.ja
va:606)
at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:463)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:357)
at org.apache.coyote.tomcat5.CoyoteWriter.flush(CoyoteWriter.java:117)
at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:203)
at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary
.java:990)
...

In my case, it's not the offset, but end that is too big.  It got the value
of 16384 when limit is only 8192.

I have looked into this more without getting more insight.  I use jdb to
catch IndexOutOfBoundsException but couldn't figure out what caused end
to get this big.  Since this happens randomly, I cannot stop a thread and
follow its progress.  Inserting prints in CharChunk was also not useful,
since values for end in threads appear normal until the exception
occurs, as if its value were clobbered by a strayed pointer (like in C).
The print did show that in some cases, the value for end is 16384 after
write(char[]) was invoked, though that didn't cause any exception for some
reason.

This turns out to be more elusive that it appears.  I might have to give
this up as another mystery of the universe.  :-)

-Kin-man

 Date: Wed, 15 Oct 2003 10:36:01 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: [5] IndexOutOfBoundsException from CharChunk
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Kin-Man Chung wrote:
  I don't know much about the test; it is one of stress test we have, but it
  should not affect CharChunk this way, right, even if it has something
  weird?  Like I said, this happens only in this test, and not always
  reproducible, so I am not surprised that nobody noticed it in 4.1.  I
  thought it might be thread related, but each thread should have its own
  CharChunk instance, so I can't see how.  I look into this more and report
  back.
 
 Bug 23805 could be related to this, and I'm awaiting more details. At 
 least, the offset numbers do match, which is too big a coincidence ;-)
 
 Remy
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[5] IndexOutOfBoundsException from CharChunk

2003-10-08 Thread Kin-Man Chung
I am getting a sporadic IndexOutOfBoundsException and it seems to come from
org.apache.tomcat.util.buf.CharChunk.flushBuffer.  The trace is

Servlet.service() for servlet jsp threw exception
java.lang.IndexOutOfBoundsException
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:132)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:191)
at org.apache.tomcat.util.buf.WriteConvertor.write(C2BConverter.java:228
)
at org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:120
)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.ja
va:606)
at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:463)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:357)
at org.apache.coyote.tomcat5.CoyoteWriter.flush(CoyoteWriter.java:117)
at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:203)
at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary
.java:990)
...

In CharChunk, 

public void flushBuffer()
throws IOException
{
//assert out!=null
if( out==null ) {
throw new IOException( Buffer overflow, no sink  + limit +   +
   buff.length  );
}
out.realWriteChars( buff, start, end - start );
end=start;
}

when realWriteChars is called, the value for start is 0, end is 16384, and
buff.length is 8192, hence the exception.

Does anyone knows how end can go beyond 8192?  This only hapeens very
rarely, under heavy load.

-Kin-man





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [5] IndexOutOfBoundsException from CharChunk

2003-10-08 Thread Kin-Man Chung

 Date: Wed, 08 Oct 2003 21:22:07 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: [5] IndexOutOfBoundsException from CharChunk
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Kin-Man Chung wrote:
 
  I am getting a sporadic IndexOutOfBoundsException and it seems to come from
  org.apache.tomcat.util.buf.CharChunk.flushBuffer.  The trace is
  
  Servlet.service() for servlet jsp threw exception
  java.lang.IndexOutOfBoundsException
  at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:132)
  at java.io.OutputStreamWriter.write(OutputStreamWriter.java:191)
  at 
org.apache.tomcat.util.buf.WriteConvertor.write(C2BConverter.java:228
  )
  at 
org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:120
  )
  at 
org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.ja
  va:606)
  at 
org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:463)
  at 
org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:357)
  at 
org.apache.coyote.tomcat5.CoyoteWriter.flush(CoyoteWriter.java:117)
  at 
org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:203)
  at 
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary
  .java:990)
  ...
  
  In CharChunk, 
  
  public void flushBuffer()
  throws IOException
  {
  //assert out!=null
  if( out==null ) {
  throw new IOException( Buffer overflow, no sink  + limit +   
+
 buff.length  );
  }
  out.realWriteChars( buff, start, end - start );
  end=start;
  }
  
  when realWriteChars is called, the value for start is 0, end is 16384, and
  buff.length is 8192, hence the exception.
  
  Does anyone knows how end can go beyond 8192?  This only hapeens very
  rarely, under heavy load.
 
 I don't know. I suppose limit is 8192 also. Are you sure your test is 
 clean, and without anything weird ? (somehow, I doubt it)
 I've changed a bit the algorithm in ByteChunk, and it seems better, but 
 the CharChunk algorithm is identical in 4.1's ByteChunk and CharChunk. 
 We would have noticed anything bad, I think.
 

I don't know much about the test; it is one of stress test we have, but it
should not affect CharChunk this way, right, even if it has something
weird?  Like I said, this happens only in this test, and not always
reproducible, so I am not surprised that nobody noticed it in 4.1.  I
thought it might be thread related, but each thread should have its own
CharChunk instance, so I can't see how.  I look into this more and report
back.

-Kin-man

 Remy
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: \% not handled right?

2003-09-23 Thread Kin-Man Chung
This is a bug.  I have committed a fix in Tomcat 5.  Thanks for reporting.

-Kin-man

 Date: Tue, 23 Sep 2003 07:30:29 -0400
 From: Tim Funk [EMAIL PROTECTED]
 Subject: \% not handled right?
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Attached is a note from tomcat-user which I think might be a bug in jasper.
 
 Summary it you don't want to read it...
 Take this page:
 -
 %=BAR%
 \%=bar%
 -
 
 It produces:
 BAR
 \%=bar%
 
 Instead of
 BAR
 \bar
 
 The spec says to escape % with \%
 
 -Tim
 
  Original Message 
 Subject: JSP Compilation Problem
 Date: Tue, 23 Sep 2003 13:23:30 +0300
 From: Anatol Pomazau [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 
 Hi.
 
 I just upgrade tomcat server from 4.1.12 to Tomcat-dev (I get sources
 from CVS and compile it yesterday)
 But I have a problem with one jsp.
 So, such code
   % String fullname = Anatol Pomazau; %
   a target=newForm
 href=\\epmsa007\applForm\new_applicant_form\%=fullname%.doc%=fulln
 ame%/a
 Works fine in old version but in new Tomcat generates
   a target=newForm
 href=\\epmsa007\applForm\new_applicant_form\%=fullname%.docAnatol
 Pomazau/a
 Insead of
   a target=newForm
 href=\\epmsa007\applForm\new_applicant_form\Anatol Pomazau.docAnatol
 Pomazau/a
 
 I have looked JSP Spec 2.0 and I have not found any remarks about such
 quoting.
 
 What I do wrong? Please help me.
 
 epam
 EPAM Systems, Minsk, Belarus
 work: +375 17 210 1662, ext. #1373
 icq uin: 138182429
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java Node.java SmapStratum.java SmapUtil.java

2003-09-22 Thread Kin-Man Chung
 @@
 break;
 case '\n' :
 sb.append('\\').append('n');
+srcLine++;
 
 if (breakAtLF || count  0) {
 // Generate an out.write() when see a '\n' in 
template
@@ -1940,6 +1946,9 @@
 }
 sb.setLength(initLength);
 count = JspUtil.CHUNKSIZE;
+
+// add a Smap for this line
+n.addSmap(srcLine);
 }
 break;
 case '\t' : // Not sure we need this



1.77  +24 -4 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java

Index: Node.java
===
RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Nod
e.java,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- Node.java 2 Sep 2003 21:39:59 - 1.76
+++ Node.java 16 Sep 2003 17:46:43 - 1.77
@@ -63,6 +63,7 @@
 import java.util.Iterator;
 import java.util.List;
 import java.util.Vector;
+import java.util.ArrayList;
 
 import javax.servlet.jsp.tagext.BodyTag;
 import javax.servlet.jsp.tagext.DynamicAttributes;
@@ -1921,6 +1922,8 @@
  */
 public static class TemplateText extends Node {
 
+private ArrayList extraSmap = null;
+
 public TemplateText(String text, Mark start, Node parent) {
 super(null, null, text, start, parent);
 }
@@ -1957,13 +1960,30 @@
 public boolean isAllSpace() {
 boolean isAllSpace = true;
 for (int i=0; itext.length(); i++) {
- if (!Character.isSpace(text.charAt(i))) {
+ if (!Character.isWhitespace(text.charAt(i))) {
 isAllSpace = false;
 break;
 }
 }
 return isAllSpace;
 }
+
+/**
+ * Add a source to Java line mapping
+ * @param srcLine The postion of the source line, relative to the 
line
+ *at the start of this node.  The corresponding java line 
is
+ *assumed to be consecutive, i.e. one more than the last.
+ */
+public void addSmap(int srcLine) {
+if (extraSmap == null) {
+extraSmap = new ArrayList();
+}
+extraSmap.add(new Integer(srcLine));
+}
+
+public ArrayList getExtraSmap() {
+return extraSmap;
+}
 }
 
 
/*



1.11  +6 -0  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SmapStratum.j
ava

Index: SmapStratum.java
===
RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Sma
pStratum.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- SmapStratum.java 31 Aug 2003 03:46:29 - 1.10
+++ SmapStratum.java 16 Sep 2003 17:46:43 - 1.11
@@ -210,6 +210,12 @@
  */
 public void optimizeLineSection() {
 
+/* Some debugging code
+for (int i = 0; i  lineData.size(); i++) {
+LineInfo li = (LineInfo)lineData.get(i);
+System.out.print(li.toString());
+}
+*/
 //Incorporate each LineInfo into the previous LineInfo's 
 //outputLineIncrement, if possible
 int i = 0;



1.19  +8 -16 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SmapUtil.java

Index: SmapUtil.java
===
RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Sma
pUtil.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- SmapUtil.java 25 Aug 2003 03:58:48 - 1.18
+++ SmapUtil.java 16 Sep 2003 17:46:43 - 1.19
@@ -77,6 +77,7 @@
  * @author Shawn Bayern
  * @author Robert Field (inner SDEInstaller class)
  * @author Mark Roth
+ * @author Kin-man Chung
  */
 public class SmapUtil {
 
@@ -613,25 +614,16 @@
 int iOutputStartLine = n.getBeginJavaLine();
 smap.addLineData(iInputStartLine, fileName, 1, 
iOutputStartLine, 1);
 
-//Walk through the node text the same way Generator.java's 
-//visit(Node.TemplateText n) does.  Every time the 
-//line number advances in the input

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

2003-09-22 Thread Kin-Man Chung
Eric,

I forgot about those generated Declartions.  It good to have an extra
pair of eyes to keep one honest.  Thanks.  :)

I have committed a fix for this and the last you reported.  Please see if
it works better now.  I have noticed that smap now contains lots of
overlaps, because of duplications in the unoptimized smap.  I'll leave
to you as an exercise to remove them in smap optimizations  :-)  Enough
smap for me for the time being.

-Kin-man

 Date: Sat, 20 Sep 2003 00:45:21 -0700
 From: Eric Carmichael [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler 
Generator.java
 X-Originating-IP: [64.203.49.21]
 To: Tomcat Developers List [EMAIL PROTECTED]
 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
 X-Priority: 3
 X-MSMail-priority: Normal
 X-Originating-Email: [EMAIL PROTECTED]
 X-OriginalArrivalTime: 20 Sep 2003 07:45:25.0789 (UTC) 
FILETIME=[2776FCD0:01C37F4B]
 
 This SMAPs all declaration nodes, including the ones tacked on to the root 
node by ELFunctionMapper.java.  So for instance the SMAP for 
jsp2/el/functions.jsp from the jsp-examples webapp ends with
 
 43,6:120
 1,3:10
 1,5:13
 
 thus SMAPping 
 
   %@ taglib prefix=my 
uri=http://jakarta.apache.org/tomcat/jsp2-example-taglib%
 
 to
 
   static private org.apache.jasper.runtime.ProtectedFunctionMapper 
_jspx_fnmap_0;
   static private org.apache.jasper.runtime.ProtectedFunctionMapper 
_jspx_fnmap_1;
 
 and
 
   static {
 _jspx_fnmap_0= 
org.apache.jasper.runtime.ProtectedFunctionMapper.getMapForFunction(my:reverse
, jsp2.examples.el.Functions.class, reverse, new Class[] 
{java.lang.String.class});
 _jspx_fnmap_1= 
org.apache.jasper.runtime.ProtectedFunctionMapper.getMapForFunction(my:countVow
els, jsp2.examples.el.Functions.class, numVowels, new Class[] 
{java.lang.String.class});
   }
 
 which is clearly wrong.
 
 Eric
 
 - Original Message - 
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Friday, September 19, 2003 4:38 PM
 Subject: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler 
Generator.java
 
 
  kinman  2003/09/19 16:38:09
  
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Make sure scriptlet declarations get properly mapped.  This fixes 22833

Revision  ChangesPath
1.211 +7 -6  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.jav
a

Index: Generator.java
===
RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Gen
erator.java,v
retrieving revision 1.210
retrieving revision 1.211
diff -u -r1.210 -r1.211
--- Generator.java 19 Sep 2003 18:30:09 - 1.210
+++ Generator.java 19 Sep 2003 23:38:08 - 1.211
@@ -196,9 +196,7 @@
  */
 public void visit(Node.PageDirective n) throws 
JasperException {
 
-if (!getServletInfoGenerated) {
-getServletInfoGenerated = true;
-} else {
+if (getServletInfoGenerated) {
 return;
 }
 
@@ -206,6 +204,7 @@
 if (info == null)
 return;
 
+getServletInfoGenerated = true;
 out.printil(public String getServletInfo() {);
 out.pushIndent();
 out.printin(return );
@@ -217,8 +216,10 @@
 }
 
 public void visit(Node.Declaration n) throws JasperException 
{
+n.setBeginJavaLine(out.getJavaLine());
 out.printMultiLn(new String(n.getText()));
 out.println();
+n.setEndJavaLine(out.getJavaLine());
 }
 
 // Custom Tags may contain declarations from tag plugins.



  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

2003-09-16 Thread Kin-Man Chung

 Date: Mon, 15 Sep 2003 22:57:32 -0700
 From: Eric Carmichael [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources 
messages.properties
 X-Originating-IP: [64.203.49.21]
 To: Tomcat Developers List [EMAIL PROTECTED]
 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
 X-Priority: 3
 X-MSMail-priority: Normal
 X-Originating-Email: [EMAIL PROTECTED]
 X-OriginalArrivalTime: 16 Sep 2003 05:57:41.0966 (UTC) 
FILETIME=[7112DEE0:01C37C17]
 
  But this also shows that tight coupling between Generator and SmapUtil is
  flagile and error prone.  I think it would be a better design if we
  decouple these two modules somehow.  We could create additional data
  structure that captures the mapping info for template texts, with
 Generator
  its producer and SmapUtil its comsumer.  What do you think?  I'll
  think about this more.
 
 I thought about this a bit when I was copying the line feed logic from
 Generator.java to SmapUtil.java to fix the line mappings for template text
 nodes, because I didn't like duplicating code, but I didn't see an
 alternative except to move the SMAPping into Generator.  How would your
 producer/consumer approach differ from that?  If a data structure that
 captures mapping info is what's needed, we already have SmapStratum
 performing that function, so I don't see much difference between having
 Generator produce a new mapping info data structure and just having
 Generator produce the SMAP directly.
 

I think keeping an array (in the Template node) of the source line that
corresponds to each of the Java line we generate is probably enough.  I'll
commit some codes today and you'll see what I mean.

There are reasons for not doing SMAP generation in Generator.  Generator is
already the biggest module in Jasper, and I'd like not to make it any more
complicated.  Also, some codes are generated out of order, in buffers that
got appended at the end of generating the main method, so that the mappings
cannot be determined when codes are generated.

SMAP generation is one of the area that does not got enough test and use.
You seem to be one of the few who actually look at it.  Are you doing anything
with it?

-Kin-man

  BTW, the reason for if (textSize = 3) is for performance optimization.
  out.write('\n') should be faster than out.write(\n) so it's OK that
  you move into the if (ctxt.getOptions().genStringAsCharArray()) block,
  for now; but it should really be applied in all cases.  Maybe we can
  write all out.write()'s in a single line, so that the mapping is not
  changed?  Or we can revisit this later.
 
 Yeah, I didn't know if putting if (textSize = 3) outside the if
 (ctxt.getOptions().genStringAsCharArray()) block was intentional or not,
 which is why I was hesitant to commit my fix.  Thanks for clarifying.  I
 don't have a problem changing the SMAPs as long as we don't break them, so
 do whatever you think best on the Generator side, and I'll just try to make
 sure to check for SMAP regressions before the next release.
 
 Eric
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

2003-09-16 Thread Kin-Man Chung
I know, I know.  I plead guilty as charged.  :-)

Unfortunately, not having a debugger that uses SMP, it is hard to automate
SMAP testing.  You pretty much has to manually eyeball the files to verify
its correctness.  I think netbeans is planning to use tomcat 5 for its
next major, so we'll expect more use there.

-Kin-man

 Date: Tue, 16 Sep 2003 19:46:19 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources 
messages.properties
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Kin-Man Chung wrote:
  I think keeping an array (in the Template node) of the source line that
  corresponds to each of the Java line we generate is probably enough.  I'll
  commit some codes today and you'll see what I mean.
  
  There are reasons for not doing SMAP generation in Generator.  Generator is
  already the biggest module in Jasper, and I'd like not to make it any more
  complicated.  Also, some codes are generated out of order, in buffers that
  got appended at the end of generating the main method, so that the mappings
  cannot be determined when codes are generated.
  
  SMAP generation is one of the area that does not got enough test and use.
  You seem to be one of the few who actually look at it.  Are you doing 
anything
  with it?
 
 Given the number of bug reports which have been filed against that 
 single feature, I can assert this is not the case. You should rewrite 
 your sentence as SMAP generation is one of the area that does not get 
 enough test and use among Tomcat committers ;-)
 
 Remy
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

2003-09-15 Thread Kin-Man Chung
Ah, I forgot about the fix that you did in SmapUtil to improve line mappings
for template texts.  Sorry.  :-(

But this also shows that tight coupling between Generator and SmapUtil is
flagile and error prone.  I think it would be a better design if we
decouple these two modules somehow.  We could create additional data
structure that captures the mapping info for template texts, with Generator
its producer and SmapUtil its comsumer.  What do you think?  I'll
think about this more.

BTW, the reason for if (textSize = 3) is for performance optimization.
out.write('\n') should be faster than out.write(\n) so it's OK that
you move into the if (ctxt.getOptions().genStringAsCharArray()) block,
for now; but it should really be applied in all cases.  Maybe we can
write all out.write()'s in a single line, so that the mapping is not
changed?  Or we can revisit this later.

-Kin-man

 Date: Sun, 14 Sep 2003 21:44:56 -0700
 From: Eric Carmichael [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources 
messages.properties
 X-Originating-IP: [64.203.49.21]
 To: Tomcat Developers List [EMAIL PROTECTED]
 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
 X-Priority: 3
 X-MSMail-priority: Normal
 X-Originating-Email: [EMAIL PROTECTED]
 X-OriginalArrivalTime: 15 Sep 2003 04:45:06.0060 (UTC) 
FILETIME=[22569CC0:01C37B44]
 
 This change leads to incorrect SMAPs of TemplateText nodes with 3 or fewer
 characters, because the if (textSize = 3) logic isn't mirrored in
 SmapUtil.java.
 
 Moving the if (textSize = 3) block into the if
 (ctxt.getOptions().genStringAsCharArray()) block seems to be a quick way to
 fix the problem for genStrAsCharArray=false (which, if
 genStrAsCharArray=true is still experimental, is the only case that really
 matters), but I haven't followed this thread closely enough to feel
 confident committing that change.
 
 Eric
 
 
 - Original Message - 
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Tuesday, September 09, 2003 2:46 PM
 Subject: cvs commit:
 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources
 messages.properties
 
 
  kinman  2003/09/09 14:46:22
 
Modified:jasper2/src/share/org/apache/jasper
  EmbeddedServletOptions.java JspC.java Options.java
 jasper2/src/share/org/apache/jasper/compiler Generator.java
 jasper2/src/share/org/apache/jasper/resources
  messages.properties
Log:
- Add an compilation option to generate writing char arrays instead of
 Strings
  for template texts.
 
  OK, I'm committing the code experimentally.  Please try it out and see
  if it improves performance.  To turn it on, set the initParam
  genStrAsCharArray to true.
 
Revision  ChangesPath
1.6   +28 -3
 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOpt
 ions.java
 
Index: EmbeddedServletOptions.java
===
RCS file:
 /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Embedded
 ServletOptions.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- EmbeddedServletOptions.java 6 Aug 2003 20:04:05 - 1.5
+++ EmbeddedServletOptions.java 9 Sep 2003 21:46:22 - 1.6
@@ -157,6 +157,11 @@
 private boolean isSmapDumped = false;
 
 /**
+ * Are Text strings to be generated as char arrays?
+ */
+private boolean genStringAsCharArray = false;
+
+/**
  * I want to see my generated servlets. Which directory are they
  * in?
  */
@@ -290,6 +295,13 @@
 }
 
 /**
+ * Are Text strings to be generated as char arrays?
+ */
+public boolean genStringAsCharArray() {
+return this.genStringAsCharArray;
+}
+
+/**
  * Class ID for use in the plugin tag when the browser is IE.
  */
 public String getIeClassId() {
@@ -513,6 +525,19 @@
 } else {
 if (log.isWarnEnabled()) {
 
 log.warn(Localizer.getMessage(jsp.warning.dumpSmap));
+}
+}
+}
+
+String genCharArray =
 config.getInitParameter(genStrAsCharArray);
+if (genCharArray != null) {
+if (genCharArray.equalsIgnoreCase(true)) {
+genStringAsCharArray = true;
+} else if (genCharArray.equalsIgnoreCase(false)) {
+genStringAsCharArray = false;
+} else {
+if (log.isWarnEnabled()) {
+
 log.warn(Localizer.getMessage(jsp.warning.genchararray));
 }
 }
 }
 
 
 
1.60  +10 -3
 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
 
Index: JspC.java

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

2003-09-11 Thread Kin-Man Chung
Yeah, now I remember; but I didn't pay attention then!  :-)

Anyway, the print methods handle null String and Object, so we are covered.
This is true for outputting expressions in text mode; evaluating attributes
with expressions is, however, another matter.

BTW, I also think it acceptable to raise NPE.  Let's leave print's in
until someone else objects!  :-)

-Kin-man

 Date: Thu, 11 Sep 2003 08:53:36 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler 
Generator.java
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 [EMAIL PROTECTED] wrote:
  kinman  2003/09/10 16:11:56
  
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Use out.print(expr) instead of out.write(String.valueOf(expr)) for 
outputting
  expressions in template texts.
 
 The problem was when the expression was null, if I remember well the 
 original justification for String.valueOf (of course, it is IMO 
 acceptable to raise a NPE).
 
 Remy
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: AW: AW: [5.0] JSP performance ...

2003-09-10 Thread Kin-Man Chung

 Date: Wed, 10 Sep 2003 18:34:40 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: AW: AW: AW: [5.0] JSP performance ...
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Torsten Fohrer wrote:
 
  next try
 
 Yes, the code is better (IMO) and performs a little better also.
 However, looking more at my profiler, I think the problem with that 
 benchmark is all the not optimized int - String conversions. Since 
 that's not too useful in the real world (but in that benchmark, it seems 
 extremely important), it is not worth optimizing it right now.
 
 BTW, for these, Resin generated out.print((var)), assuming the type of 
 the expression would be correct. I think we went through that and 
 decided not to do that, right ?
 

We did?

I think we should also use out.print(var) instead of
out.write(String.valueOf(var)).  The print methods cover all the types
covered by String.valueOf, so there is really no advantage in using
out.write's.  Using print lets javac resolves the object types at
compile time instead of runtime, and should be faster.

If there is no objections, I'll go ahead and make the change.

- Kin-man

 I think we would need to define a decent servletJSP bench suite :) (and 
 avoid to rig it)
 
 Remy
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: [5.0] JSP performance ...

2003-09-09 Thread Kin-Man Chung

 Date: Tue, 09 Sep 2003 08:59:51 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: AW: [5.0] JSP performance ...
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Kin-Man Chung wrote:
  I have implemented generating text strings as char arrays, with a
  compiler option to turn it on and off, and did some timings on the
  benchmark.  Just as I suspected, the benchmark did not show much
  performance difference, when the option was turned on and then off.
  
  Now I am wondering if there is any value in committing my change.  :(
 
 Well, if it does improve results, it can't hurt, but the two should 
 likely be similar. What did you get in your testing ?

I ran your Jsp page with added timings.  The difference in the numbers
with the option switched on and off is less the time flutuation itself.

 I think what should be optimized is that there's twice the amount of writes.
 Looking at the code generated, this situation seems rather common. So 
 the idea would be to do a pass to merge all those TemplateText nodes :)
 

I'll try that next, but don't get your hope up.  It may not change much.

 The profile showed about 75% of the CPU was spent in the JSP service (as 
 usual with the VM profiles, it's probably misleading), and probably some 
 of that time comes from the fact it has to invoke hundreds of methods.
 
Method calls should be cheap.  The question is: is writng a String of
size 1000 much faster than writing 10 Strings each of size 100?

-Kin-man

 Remy
 
 I took a look at o.a.j.runtime.JspWriterImpl and the methods
 
 write(String s, int off, int len)
 and
 write(char cbuf[], int off, int len)
 
 in particualr, and failed to see any performance gain of the 2nd over the
 first.  They are very similar, the only different is that the first uses
 String.getChars while the second uses System.arraycopy, but those two
 methods should be on par in terms of performance.  That is, I don't see
 any extra unnecessary copies.
 
 Perhasp the culprit is those extra writes?
 
 -Kin-man
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: [5.0] JSP performance ...

2003-09-08 Thread Kin-Man Chung
This seems easy enough to implement, so I'll look into it.  Concatenating
texts is also on my list, and it should help a little in this case.

- Kin-man

 Date: Mon, 08 Sep 2003 08:46:32 +0200
 From: Torsten Fohrer [EMAIL PROTECTED]
 Subject: AW: [5.0] JSP performance ...
 To: 'Tomcat Developers List' [EMAIL PROTECTED]
 
 
 i have patched jasper to use char arrays instead of strings, and it gaves a
 good performance improvment. It's not perfect, but is works.
 
 cu Torsten
 
 -Ursprüngliche Nachricht-
 Von: Remy Maucherat [mailto:[EMAIL PROTECTED]
 Gesendet: Sonntag, 7. September 2003 15:49
 An: Tomcat Developers List
 Betreff: [5.0] JSP performance ...
 
 
 .. is not as good as it should be. I found a benchmark where TC is 
 currently not too good. The problem occurs when dealing with lots of 
 strings.
 
 I'm attaching the benchmark, the code generated by TC, and the code 
 generated by Resin. Resin String handling tricks ends with it making 
 about half the amount of writes, and writing char arrays instead of 
 Strings. I believe this is faster :-D
 
 While the benchmark is quite lame, I believe a lot of pages have similar 
 amounts of interleaved static HTML, so optimizing this would give a 
 healthy performance increase. (Note: I did a quick review with a 
 profiler, and all the CPU time is spent in the _jspService method body, 
 using a compiled JSP, so the performance overhead is in the generated 
 code for this particular test)
 
 (I found this while looking for optimization ideas)
 
 Can we get the same kind of stuff ? Kin-Man, Jan, others ?
 
 Remy
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: [5.0] JSP performance ...

2003-09-08 Thread Kin-Man Chung
I took a look at o.a.j.runtime.JspWriterImpl and the methods

write(String s, int off, int len)
and
write(char cbuf[], int off, int len)

in particualr, and failed to see any performance gain of the 2nd over the
first.  They are very similar, the only different is that the first uses
String.getChars while the second uses System.arraycopy, but those two
methods should be on par in terms of performance.  That is, I don't see
any extra unnecessary copies.

Perhasp the culprit is those extra writes?

-Kin-man

 Date: Mon, 08 Sep 2003 23:03:19 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: AW: [5.0] JSP performance ...
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Kin-Man Chung wrote:
  This seems easy enough to implement, so I'll look into it.  Concatenating
  texts is also on my list, and it should help a little in this case.
 
 That would be awesome.
 The test had a *lot* of writes, so this would save hundreds of write 
 invocations (as well as making them faster as it would user char arrays).
 
 JSP performance should be really good with that change.
 
 Remy
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AW: [5.0] JSP performance ...

2003-09-08 Thread Kin-Man Chung
I have implemented generating text strings as char arrays, with a
compiler option to turn it on and off, and did some timings on the
benchmark.  Just as I suspected, the benchmark did not show much
performance difference, when the option was turned on and then off.

Now I am wondering if there is any value in committing my change.  :(

-Kin-man

 Date: Mon, 08 Sep 2003 15:18:34 -0700 (PDT)
 From: Kin-Man Chung [EMAIL PROTECTED]
 Subject: Re: AW: [5.0] JSP performance ...
 To: [EMAIL PROTECTED]
 Content-MD5: +Y/z1F8l8EXxpI9LL3yPSA==
 
 I took a look at o.a.j.runtime.JspWriterImpl and the methods
 
   write(String s, int off, int len)
 and
   write(char cbuf[], int off, int len)
 
 in particualr, and failed to see any performance gain of the 2nd over the
 first.  They are very similar, the only different is that the first uses
 String.getChars while the second uses System.arraycopy, but those two
 methods should be on par in terms of performance.  That is, I don't see
 any extra unnecessary copies.
 
 Perhasp the culprit is those extra writes?
 
 -Kin-man
 
  Date: Mon, 08 Sep 2003 23:03:19 +0200
  From: Remy Maucherat [EMAIL PROTECTED]
  Subject: Re: AW: [5.0] JSP performance ...
  To: Tomcat Developers List [EMAIL PROTECTED]
  
  Kin-Man Chung wrote:
   This seems easy enough to implement, so I'll look into it.  Concatenating
   texts is also on my list, and it should help a little in this case.
  
  That would be awesome.
  The test had a *lot* of writes, so this would save hundreds of write 
  invocations (as well as making them faster as it would user char arrays).
  
  JSP performance should be really good with that change.
  
  Remy
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [5.0.8] Tag soon

2003-08-18 Thread Kin-Man Chung
Remy,

I discovered there is a jasper bug that causes wrong Java line numbers
to be mapped when codes for invoking tag handlers are generated in separate
methods.  This would completely screw up JSP debugging, and causes javac
error messages to be lost if it happens in the generated method.  I have
a fix for this and plan to commit it.  The fix is safe in that it does
not affect the generated codes, and I promise to do thorough testing
before committing.  :-)

Kin-man

 Date: Mon, 18 Aug 2003 18:24:53 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: [5.0.8] Tag soon
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 As most (all ?) of the issues uncovered in build 5.0.7 have been fixed 
 or addressed in some way, I plan to tag and release 5.0.8 soon (likely 
 wednesday). Please apply any fixes before then (but please no features 
 addition or refactorings), such as the servlet API updates.
 
 Thanks :)
 
 (hopefully, we'll have a good quality build this time :) )
 
 Remy
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JSP include

2003-08-14 Thread Kin-Man Chung
It eventually invokes

request.getRequestDispatcher(bar.jsp).include().


 Date: Fri, 08 Aug 2003 11:40:45 +0200
 From: Marc Baumgartner [EMAIL PROTECTED]
 Subject: JSP include
 To: [EMAIL PROTECTED]
 Content-disposition: inline
 
 Hello all,
 
 I want to fix a bug in the JSPReader of the Cocoon-Project. It would be 
 helpfull for me if someone could explain me how the tomcat handles the 
 jsp:include and jsp:forward tag.
 
 For example, I have foo.jsp and bar.jsp:
 
 titlefoo/title
 jsp:include page=bar.jsp /
 
 
 titlebar/title
 phello/p
 
 How is the location of the file bar constructed by tomcat? 
 Which methods of HttpServletRequest are used? 
 
 Thanks in advanced.
 
 Regards,
 Marc
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] New committer: Eric Carmichael

2003-08-14 Thread Kin-Man Chung
He has my +1 as well.  Yan and I need all the help on Jasper!

 Date: Sun, 10 Aug 2003 18:56:49 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: [VOTE] New committer: Eric Carmichael
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 I'd like to nominate Eric Carmichael as a committer on the Tomcat 
 project. Eric has been steadily supplying quality patches to the new 
 Jasper which will implement the JSP 2.0 specification, and has helped 
 fix outstanding bug reports. He plans to continue contributing in the 
 future.
 
 He has my +1.
 
 Remy
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compilerJspDocumentParser.java

2003-08-14 Thread Kin-Man Chung
I don't think this patch is correct.  The order that the methods
startPrefixMapping and endPrefixMapping are called is properly nested,
so a stack is appropiate.  Take for instance the follow xml fragment

1 foo xmlns:my=mytaglib !-- namespace for my taglib --
2bar xmlns:my=nottaglib/ !-- this namesapce is not a taglib --
3my:doThat/   !-- Is this a taglib invokation? --
4 /foo

The order that those methods will be called is:

At line 1: startPrefixMapping(my, mytaglib)
At line 2: startPrefixMapping(my, nottaglib)
At line 2: endPrefixMapping(my)   # for nottaglib
At line 4: endPrefixMapping(my)   # for mytaglib

According to your patch, pageInfo.popPrefixMapping() will be called
resulting in Line 3 above not being interpreted as a tag handler
invokation.

This probably does not matter, as I simplify the logic here and remove
the stack altogeterh.

-Kin-man

 Date: Sat, 09 Aug 2003 14:55:46 +
 From: [EMAIL PROTECTED]
 Subject: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler 
JspDocumentParser.java
 To: [EMAIL PROTECTED]
 
 remm2003/08/09 07:55:46
 
   Modified:jasper2/src/share/org/apache/jasper/compiler
 JspDocumentParser.java
   Log:
   - pop is called in the same order as push, so using a stack is not correct.
 A linked list should be used instead.
   
   Revision  ChangesPath
   1.63  +9 -10 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentPa
rser.java
   
   Index: JspDocumentParser.java
   ===
   RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Jsp
DocumentParser.java,v
   retrieving revision 1.62
   retrieving revision 1.63
   diff -u -r1.62 -r1.63
   --- JspDocumentParser.java  8 Aug 2003 22:22:09 -   1.62
   +++ JspDocumentParser.java  9 Aug 2003 14:55:46 -   1.63
   @@ -109,7 +109,7 @@
private boolean isTagFile;
private boolean directivesOnly;
private boolean isTop;
   -private Stack prefixMapStack;
   +private LinkedList prefixMapLinkedList;

/*
 * Constructor
   @@ -128,7 +128,7 @@
   this.isTagFile = isTagFile;
   this.directivesOnly = directivesOnly;
   this.isTop = true;
   -this.prefixMapStack = new Stack();;
   +this.prefixMapLinkedList = new LinkedList();;
}

/*
   @@ -560,10 +560,9 @@
if (taglibInfo != null) {
pageInfo.addTaglib(uri, taglibInfo);
pageInfo.pushPrefixMapping(prefix, uri);
   -prefixMapStack.push(new Boolean(true));
   -   }
   -else {
   -prefixMapStack.push(new Boolean(false));
   +prefixMapLinkedList.addLast(new Boolean(true));
   +} else {
   +prefixMapLinkedList.addLast(new Boolean(false));
}
 }

   @@ -571,7 +570,7 @@
  * Receives notification of the end of a Namespace mapping. 
  */
public void endPrefixMapping(String prefix) throws SAXException {
   -if (((Boolean)prefixMapStack.pop()).booleanValue()) {
   +if (((Boolean) prefixMapLinkedList.removeFirst()).booleanValue()) {
pageInfo.popPrefixMapping(prefix);
}
}
   
   
   
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Please confirm soln: [Bug 22226] Tomcat throws JasperExceptioninstead of NumberFormatException when parameter can't convert to bean property

2003-08-09 Thread Kin-Man Chung
You are right in that this is not a spec conformant issue and is
therefore not a bug.

Except for some exceptions, most exceptions are caught and rethrown
as JasperExceptions.  Making exceptions would just, well, complicate
things.  :-)

-Kin-man

 Date: Fri, 08 Aug 2003 09:00:30 -0400
 From: Tim Funk [EMAIL PROTECTED]
 Subject: Please confirm soln: [Bug 6]   Tomcat throws JasperException 
instead of NumberFormatException when parameter can't convert to bean property
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 The spec says for jsp:setProperty:
 A conversion failure leads to an error, whether at translation time or 
 requesttime.
 
  From a compliance point of view, it looks like tomcat is OK that is throws a 
 JasperException.
 
 But from a user (web developer) point of view, I would think this sucks. But 
 am I correct that this is not a bug? (So I can resolve as invalid)
 
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6
 
 -Tim
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jsp:include

2003-06-24 Thread Kin-Man Chung
Can you reproduce your problem with Tomcat 5?  If so, you may get it
fixed faster if you post it on bugzilla.  When you do, make sure to
include a test case (a war file would be great).

Not sure I understand what the problem is.  Also not sure what
jsp:include has to anything to do with your problem.  You cannot
find a class that is related to jsp:include because there isn't one.
jsp:include eventually invokes RequestDispatcher.include in the generated
servlet code.  See org.apache.jasper.runtime.JspRuntimeLibrary.include()
for more details.

 Date: Tue, 24 Jun 2003 15:45:39 -0500
 From: Reshat Sabiq [EMAIL PROTECTED]
 Subject: jsp:include
 To: [EMAIL PROTECTED]
 
 Hi,
 
 There's a bug in J2EE 1.4 RI Beta 2 that prevents me from using a custom 
 tag:
 instanceof operator treats TagSupport subclass as SimpleTagSupport instance.
 
 This leaves me only one appropriate option: subclass the class that 
 implements jsp:include tag, and overwrite a method in it. I'd appreciate 
 a pointer as to what class implements that tag. I've been searching 
 through taglibs and tomcat-5 nightly builds, and have not found a single 
 class that is related to jsp:include.
 Thank you in advance.
 
 P.S. Yes, i will be reporting the bug on sun's website. But i need to 
 work around at this time...
 
 -- 
 Sincerely,
 Reshat.
 
 

---
 If you see my certificate with this message, you should be able to send me 
encrypted e-mail. 
 Please consult your e-mail client for details if you would like to do that.
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [5] EL parsing eats extra character after '?'

2003-05-31 Thread Kin-Man Chung

 Date: Fri, 30 May 2003 13:47:01 -0400
 From: Tim Funk [EMAIL PROTECTED]
 Subject: [5] EL parsing eats extra character after '?'
 To: Tomcat Developers List [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 
 Attached below is a message from tomcat-user. I don't know it this is a valid 
 issue or not. If its not, it has great FAQ potential.
 
Argh, this is a bug!  JSP 2.0 now recognizes ${...} as an EL expression,
so there are some special handling for $ in the parser.  It got this
wrong, apparently.

I'll commit a fix to this as soon as I send this mail out.  Note that
the workaound to this problem is to write

\$jsp:getProperty name=login property=username/

instead.  Here, \$ is an escape for $.  This is new in JSP 2.0. 

Note also that this can now be written as

\$${login.username}

taking advantage of EL in tc 5.

 If it is a problem, could it be caused by the following the snippet below? It 
 looks like any custom tag would be ignored if preceded by a $. This seems to 
 be the behavior I saw when I put $ in front of the hello world tag in 
 /jsp-examples/jsp2/tagfiles/hello.jsp.
 
 
 In org.apache.jasper.compiler.Parser.parseXMLTemplateText()
 lines 1502, 1506
  if (ch != '{') {
  ttext.write('$');
  ttext.write(ch);
  continue;
  }
 
This would not work, since parseXMLTemplateText deals only with
text in the body of jsp:text element.

 
 I really don't know much about Jasper, and was just snooping.
 

Well, this is a good time to do that, now that Jasper in TC5 has
stablized.  Ping me if you need help.  :)

-Kin-man

 -Tim
 
  Original Message 
 Subject: Tomcat 5.0.2 Bug
 Date: Fri, 30 May 2003 06:36:04 -0700 (PDT)
 From: Ed Smith [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 
 I think there is a bug in Tomcat 5.0.2 (at least under
 Windows XP) dealing with placing a $ before (at least
 some) tags.
 
 Consider the following JSP:
 
 jsp:useBean id=login class=LoginBean
 scope=session/
 jsp:setProperty name=login property=username
 value=foo/
 
 html
body
  $jsp:getProperty name=login
 property=username/
/body
 /html
 
 In Tomcat 4.1.24, this generates the following HTML
 (as expected)
 
 html
body
  $foo
/body
 /html
 
 In Tomcat 5.0.2, it generates
 
 html
body
  $jsp:getProperty name=login
 property=username/
/body
 /html
 
 The jsp taglib does not get processed in
 5.0.2.  Note that if I add a space after the $, it
 works in 5.0.2
 
 Changing to
 
 $ jsp:getProperty name=login property=username/
 
 gets the following HTML
 
 html
body
  $ foo
/body
 /html
 
 Am I missing something?  I didn’t find the problem in
 either the bugs database or the mailing list archives.
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [4.1.21] Stability rating

2003-02-28 Thread Kin-Man Chung
The patch you mentioned in 14302 was actually applied to TC5.

 Date: Fri, 28 Feb 2003 12:07:21 -0800
 From: Hans Bergsten [EMAIL PROTECTED]
 Subject: Re: [4.1.21] Stability rating
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Remy Maucherat wrote:
  ballot
  [X] Alpha
  [ ] Beta
  [ ] Stable (GA)
  /ballot
 
 The TagLibraryInfoImpl patch attached to bug 14302 is still not
 applied, so JSPC fails with an NPE for any web app that contains
 a tag library packaged as a JAR file (with the TLD in the JAR file).
 
 Other than that, all my tests works okay.
 
 Hans
 -- 
 Hans Bergsten[EMAIL PROTECTED]
 Gefion Software   http://www.gefionsoftware.com/
 Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
 Details athttp://TheJSPBook.com/
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [5.0.1] Tagging today

2003-02-21 Thread Kin-Man Chung

 Date: Fri, 21 Feb 2003 19:16:46 +0100
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: [5.0.1] Tagging today
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Costin Manolache wrote:
  Kin-Man Chung wrote:
 
 I also don't believe jsp-examples has been successful compiled with JSPC
 before.  I know haven't tried that with JSP2.0 examples.  With automatic
 compiling of the tag files, I won't be surprise if there are problems.  :)
  
  
  It doesn't matter what it's for - if it is valid JSP it should compile
  with jspc the same as with jspservlet :-). If it's not valid - it should be
  removed...
 
 I tried to look into the issue, but it's quite complex :-(

I have just committed a fix for using JSPC to compile JSP pages that uses
tag files.  The complication comes from the need to compile tag files
into class objects before a JSP page that references them can be compiled.
I don't know a better strategy for precompiling an application would be to
first compile all the tag files first, then compile the JSP pages after
that.  The added complication is that a tag file may use other tag files, or
even be circularly dependent.

 I don't like that new spec feature, overall. Same for the ability to put 
 the TLD in random places.
 

It's supposed to help page authors that are not programmers.  But if a
seasoned programmer find tag files hard to use, it's not a good sign.

 It seems the new spec revisions mean more complex + more bloated :-( 
 This is quite disappointing ...
 

Isn't that always true?  :-)  You need to add new features but cannot
remove old ones.

 Remy
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compilerTagFileProcessor.java

2003-02-19 Thread Kin-Man Chung
The fix looks OK, except that you still need to put the call to
incTripCount in a synchronized block.  Of course that won't
be necessary for JSPC.

There may better solutions to this problem, and I'll look into that.
I'll also make sure that there won't be problems using jspc on tag
files.


 Date: Wed, 19 Feb 2003 07:03:46 +
 From: [EMAIL PROTECTED]
 Subject: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler 
TagFileProcessor.java
 To: [EMAIL PROTECTED]
 
 billbarker2003/02/18 23:03:45
 
   Modified:jasper2/src/share/org/apache/jasper
 JspCompilationContext.java
jasper2/src/share/org/apache/jasper/compiler
 TagFileProcessor.java
   Log:
   Fix for most of the pre-compile problems with TC-5.
   
   The basic problem is that with Jspc, there is no 'RuntimeContext'.  I've 
patched around the worst parts of it, but I'm the first to admit that I don't 
know Jasper down to this sort of level.
   
   Jan, Kin-Man, please review (and feel free to -1 if I've broken something).
   
   Revision  ChangesPath
   1.32  +5 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.
java
   
   Index: JspCompilationContext.java
   ===
   RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilati
onContext.java,v
   retrieving revision 1.31
   retrieving revision 1.32
   diff -u -r1.31 -r1.32
   --- JspCompilationContext.java  12 Feb 2003 16:37:11 -  1.31
   +++ JspCompilationContext.java  19 Feb 2003 07:03:44 -  1.32
   @@ -201,6 +201,8 @@
public ClassLoader getClassLoader() {
if( loader != null )
return loader;
   +   if( rctxt == null) 
   +   return getClass().getClassLoader();
return rctxt.getParentClassLoader();
}

   
   
   
   1.40  +62 -49
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProces
sor.java
   
   Index: TagFileProcessor.java
   ===
   RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Tag
FileProcessor.java,v
   retrieving revision 1.39
   retrieving revision 1.40
   diff -u -r1.39 -r1.40
   --- TagFileProcessor.java   5 Feb 2003 23:35:21 -   1.39
   +++ TagFileProcessor.java   19 Feb 2003 07:03:45 -  1.40
   @@ -412,60 +412,73 @@

   JspCompilationContext ctxt = compiler.getCompilationContext();
   JspRuntimeContext rctxt = ctxt.getRuntimeContext();
   -JspServletWrapper wrapper =
   +   JspServletWrapper wrapper = null;
   +   if( rctxt != null ) {
   +   wrapper =
   (JspServletWrapper) rctxt.getWrapper(tagFilePath);

   -   synchronized(rctxt) {
   -   if (wrapper == null) {
   -   wrapper = new JspServletWrapper(ctxt.getServletContext(),
   -   ctxt.getOptions(),
   -   tagFilePath,
   -   tagInfo,
   -   ctxt.getRuntimeContext(),
   -   (JarFile) 
ctxt.getTagFileJars().get(tagFilePath));
   -   rctxt.addWrapper(tagFilePath,wrapper);
   +   synchronized(rctxt) {
   +   if (wrapper == null) {
   +   wrapper = new JspServletWrapper(ctxt.getServletContext(),
   +   ctxt.getOptions(),
   +   tagFilePath,
   +   tagInfo,
   +   ctxt.getRuntimeContext(),
   +   (JarFile) 
ctxt.getTagFileJars().get(tagFilePath));
   +   rctxt.addWrapper(tagFilePath,wrapper);
   +   }
   }
   +   } else {
   +   wrapper = new JspServletWrapper(ctxt.getServletContext(),
   +   ctxt.getOptions(),
   +   tagFilePath,
   +   tagInfo,
   +   ctxt.getRuntimeContext(),
   +   
(JarFile)ctxt.getTagFileJars().get(tagFilePath)
   +   );
   +   }
   +

   -   Class tagClazz;
   -   int tripCount = wrapper.incTripCount();
   -   try {
   -   if (tripCount  0) {
   -   // When tripCount is greater than zero, a circular
   -   // dependency exists.  The circularily dependant tag
   -   // file is compiled in prototype mode, to avoid infinite
   -   // recursion.
   +   Class 

Re: [5.0.1] Tagging today

2003-02-18 Thread Kin-Man Chung

 Date: Tue, 18 Feb 2003 21:46:54 +0100
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: [5.0.1] Tagging today
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Costin Manolache wrote:
  Remy Maucherat wrote:
  
  
 Costin Manolache wrote:
 
 Remy Maucherat wrote:
 
 
 
 Jeanfrancois Arcand wrote:
 
 
 Are you able to build it? The nightly build failled with the following
 (see below). I will look at the failure latter this afternoon...
 
 It's a hint that there are urgent bugs to fix in either JspC or Jasper,
 which make precompilation fail (read my commit massage to see the full
 story) ;-)
 
 
 Well, we can't release a milestone with both gump and normal build
 failing. At this point disabling the precompilation seems the best
 short-term workaround, but I think we should rather wait with the
 milestone until the fix is available.
 
 That's reasonable.
 +1 for fixing the bugs (I tried a bit and failed).
  
  
  +1 for fixing the bug too - but I don't know how :-)
  
  It seems to be introduced by one of the recent changes - I had no problem
  compiling the admin few weeks ago. We either roll back the change or find
  another way.
 
 The bug happens in the jsp-examples precompilation (which is supposed to 
 work also, right ?). One of the tag examples apparently causes problems.
 

The strange thing is the error hapeened with source.jsp, which is not one
of the exmaples.  Do you guys know what it's for?

I also don't believe jsp-examples has been successful compiled with JSPC
before.  I know haven't tried that with JSP2.0 examples.  With automatic
compiling of the tag files, I won't be surprise if there are problems.  :)

  One thing should be clear - precompiled jsps should be included with tomcat5
  and we should strongly recommend ( and support ) this mode for production 
  sites. For development it is normal to compile the page, but doing the 
  compilation on a production server is really bad idea.
 
 +1.
 

+1 from me too.  However, is Jspc good enough now?  Are there areas that need
to be fixed?  We should not make this a requirement for tomcat5 and recommand
such a practice until it is good enough.  For now we should just turn off
precompilation of the examples until the problem is identified and fixed.

 Remy
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: TC 5.0 nightly builds

2003-02-11 Thread Kin-Man Chung
No matter how easy the build is, it is still not as easy as downloading
a binary from the nightly build area.  Just tell someone who haven;t
done a build before to do it now and watch her cringe!

Sue' point is that TC5 nightly build has failed for a week now
and should be fixed.  It's important that we have a current nightly
build for TC5, especially since we don't have a release for TC5 (hint!
hint :) ).

 Date: Tue, 11 Feb 2003 16:49:20 -0500
 From: Jeanfrancois Arcand [EMAIL PROTECTED]
 Subject: Re: TC 5.0 nightly builds
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Hi,
 
 an easy way to build tomcat 5 is to:
 
 cvs -d bla bla checkout jakarta-tomcat-5
 cd jakarta-tomcat-5
 ant download //download all dependencies (including common-el.jar)
 ant checkout   //jakarta-servletapi-5, jakarta-tomcat-catalina, 
 jakarta-tomcat-connectors, jakarta-tomcat-jasper
 ant dist
 
 Et hop :-)
 
 -- Jeanfrancois
 
 Brian Millett wrote:
 
 On Tue, 2003-02-11 at 11:34, Sue Spielman wrote:
   
 
 Is there an ETA when the nightly builds of TC 5.0 will return? It has not 
 been building since 2/5. Thanks.
 
 
 
 
 It will build if you go and get a nightly binary build of commons-el.
   
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




[TC5] Time to make a release?

2003-02-06 Thread Kin-Man Chung
There has been inquiries about a Tomcat 5 release, both in and out
of the mailing list.  I usually direct them to our nightly builds,
but there is no links from the jakarta page, and they are not always
available.  I think it's time that we make a release, to make it
easier for people to try it out.

I know there are a lot of work still going on, and a lot need to be
done to make it into a stable release.  I am thinking about an alpha
release.  Now that JSP 2.0 PFD2 has been published,

(http://jcp.org/aboutJava/communityprocess/first/jsr152/index2.html)

and the jasper implementation has been complete, we need a release for
people to try it out.

Comment?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: bean with jsp

2003-02-05 Thread Kin-Man Chung
You should try to get answers to questions like this on tmcat-users alias.

You'll need to put whatever you import in a package.  This is a new
in JDK1.4.

 Date: Wed, 05 Feb 2003 17:39:07 +0530
 From: Sachin Chowdhary [EMAIL PROTECTED]
 Subject: bean with jsp
 To: [EMAIL PROTECTED]
 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
 Importance: Normal
 X-Priority: 3 (Normal)
 X-MSMail-priority: Normal
 X-OriginalArrivalTime: 05 Feb 2003 12:09:09.0271 (UTC) 
FILETIME=[63397A70:01C2CD0F]
 
 
 I am trying to use a class by using useBean tag in jsp but i am not able to
 do it so remove all coding and just using import class name syntax but still
 i am not able to do that on tomcat4.1.18 .so what i am doing wrong
 
 can you suggest me
 
 
 C:\Program Files\Apache Group\Tomcat 4.1\webapps\examples\jsp
 %@ page import=MyClass %
 
 html
 body
 Meet a Bean!
/body
 /html
 
 //MyClass.java
 
 
 C:\Program Files\Apache Group\Tomcat 4.1\webapps\examples\WEB-INF\classes
 public class MyClass
 {
  public String val;
 }
 
 
 
 HTTP Status 500 -
 
 type Exception report
 message
 description The server encountered an internal error () that prevented it
 from fulfilling this request.
 exception
 org.apache.jasper.JasperException: Unable to compile class for JSP
 
 An error occurred at line: -1 in the jsp file: null
 
 Generated servlet error:
 [javac] Compiling 1 source file
 
 C:\Program Files\Apache Group\Tomcat
 4.1\work\Standalone\localhost\examples\jsp\MyJsp_jsp.java:7: '.' expected
 import MyClass;
   ^
 1 error
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

2003-01-22 Thread Kin-Man Chung
See below.

 Date: Wed, 22 Jan 2003 19:03:08 +0100
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Costin Manolache wrote:
  Remy Maucherat wrote:
  
  Then why not default to the context path ?
 
 Can you give examples ? It's very hard to determine the context path 
 from JSPC IMO.
 
  I think the naming conventions for the generated servlets should be 
  settled down, documented - and treated as APIs ( i.e. no change unless 
  absolutely needed ).
 
 Ok, but in the meantime, we must not allow non packaged classes.
 
 When I wrote my patch, I also felt that a default package prefix was
 a good idea, but I dropped it in the end due to the package/directory
 structure mismatch. If it's really important to, you should also make
 sure the class files are generated in a directory structure that starts
 with org/apache/jsp/
 
 I was wondering about that, actually, and thought this was inconsistent.
  
  
  JSPC does generate the right package directory structure. I think JspServlet
  should do the same - if it doesn't already.
 
 Well, I don't think we care. JspServlet generates in the workdir, and 
 uses one CL per page. So packaging is not relevant IMO.
 OTOH, JSPC may generate the classes in /WEB-INF/classes, so we would 
 need to create the full package structure. I'd like to point out that 
 you admin precompilation example does include an extra admin subfolder 
 in the output directory path.
 
 Remy
 

Well, there is one case that generating the classes with the same package
name would cause problem, and that is when you have two JSP pages with the
same file name (but in different directories).  Still not a problem in
class loading, since the class files are placed in different directories,
but you cannot debug them anymore since you cannot identify the classes by
name - they have the same name.

Anyone knows why it was done this way?

 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

2003-01-22 Thread Kin-Man Chung

 Date: Wed, 22 Jan 2003 13:20:48 -0600
 From: Glenn Nielsen [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 
 
 Kin-Man Chung wrote:
  See below.
  
  
 Date: Wed, 22 Jan 2003 19:03:08 +0100
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
  
  jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
  
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Costin Manolache wrote:
 
 Remy Maucherat wrote:
 
 Then why not default to the context path ?
 
 Can you give examples ? It's very hard to determine the context path 
 from JSPC IMO.
 
 
 I think the naming conventions for the generated servlets should be 
 settled down, documented - and treated as APIs ( i.e. no change unless 
 absolutely needed ).
 
 Ok, but in the meantime, we must not allow non packaged classes.
 
 
 When I wrote my patch, I also felt that a default package prefix was
 a good idea, but I dropped it in the end due to the package/directory
 structure mismatch. If it's really important to, you should also make
 sure the class files are generated in a directory structure that starts
 with org/apache/jsp/
 
 I was wondering about that, actually, and thought this was inconsistent.
 
 
 JSPC does generate the right package directory structure. I think 
JspServlet
 should do the same - if it doesn't already.
 
 Well, I don't think we care. JspServlet generates in the workdir, and 
 uses one CL per page. So packaging is not relevant IMO.
 OTOH, JSPC may generate the classes in /WEB-INF/classes, so we would 
 need to create the full package structure. I'd like to point out that 
 you admin precompilation example does include an extra admin subfolder 
 in the output directory path.
 
 Remy
 
  
  
  Well, there is one case that generating the classes with the same package
  name would cause problem, and that is when you have two JSP pages with the
  same file name (but in different directories).  Still not a problem in
  class loading, since the class files are placed in different directories,
  but you cannot debug them anymore since you cannot identify the classes by
  name - they have the same name.
  
  Anyone knows why it was done this way?
  
 
 I did some refactoring of the JasperClassLoader and the package naming
 over a year ago.  The code for all this in Jasper had been very convoluted
 and added a great deal of overhead.  The refactoring improved runtime JSP
 performance by 33% and compilation by 25%.  If you search the tomcat-dev
 archives you can find the detailed description of what was changed and why.
 
 I am -1 for changing the default package name for JSP pages compiled at 
runtime
 from org.apache.jsp to something else until all the implication of doing this
 are thought through.
 
Agreed.  But I don't think changing the package name to one that reflects
the directory structure of the jsp files is going to have much performance
impact.

 Jean-Francois mentioned that there are SecurityManager issues related to
 changing the package name.
 

Yea, I saw.  And having an unique package name seems to solve that too.

 Glenn
 
 
 
 --
 Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
 MOREnet System Programming   |  * if iz ina coment.  |
 Missouri Research and Education Network  |  */   |
 --
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [newbie] where do I get TagFileInfo, etc.?

2002-12-12 Thread Kin-Man Chung
Sorry for not responding earlier.

When checking out files from jakarta-tomcat-jasper, make sure to
use the tag tomcat_4_branch.  The head branch is an implementation
of JSP 2.0, and is used for building TC5.0.

Good luck!

 Date: Sat, 07 Dec 2002 14:57:24 -0800
 From: Michael [EMAIL PROTECTED]
 Subject: Re: [newbie] where do I get TagFileInfo, etc.?
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Kin-Man Chung wrote:
 
 It's in jakarta-servletapi-4, which IS mentioned in BUILDING_txt.
 Make sure that you have servlet.home defined correctly in build.properties.
 
 I'm trying to build jakarta-tomcat-4.0, but it wanted 
 jakarta-tomcat-jasper (not mentioned in BUILDING.txt). I checked that 
 out, but it's build fails with undefined symbols. Where can I find these?
 
 
 
 I was relying on Debian's libservlet2.3-java package.
 
 But it's not in jakarta-servletapi-4, either. I built that, and pointed 
 jakarta-tomcat-4.0/build.properties to it, but get the same errors. I 
 grepped the tree, too, and couldn't find 
 'package.*javax\.servlet\.jsp\.el', for example. So far, I've got the 
 CVS from
 
 jakarta-servletapi-4
 jakarta-tomcat-connectors
 jakarta-tomcat-4.0
 jakarta-tomcat-jasper
 
 Thanks.
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jasper 2 Synchronized JSP compiles

2002-12-04 Thread Kin-Man Chung
Performance-wise, wouldn't doing javac compilation in another process
be much worse than synchronized javac, at least for systems with small
number of processors?  It would nice if we can have some numbers for
comparision.

I know javac used to have memory leak, but is it still true for modern
compilers, such as the one in JDK 1.4.0?

BTW, I am +1 on the proposal.

 Date: Wed, 04 Dec 2002 09:04:35 -0600
 From: Glenn Nielsen [EMAIL PROTECTED]
 Subject: Jasper 2 Synchronized JSP compiles
 To: [EMAIL PROTECTED]
 
 I have some ideas on how invoking the javac compiler for compiling JSP pages 
can be
 improved.  Currently Jasper 2 uses ant to do compiles from within Tomcat which 
are
 synchronized.
 
 There are currently several problems.
 
 1. The known javac memory leak.
 
 2. JSP page compiles are synchronized.
 
 3. Jikes currently can't be configured for windows because the windows build 
of
 jikes doesn't support -encoding.
 
 4. We may be getting some bug reports related to this problem noted in the Ant
 documentation for the javac task:
 
 Windows Note:When the modern compiler is used in unforked mode on Windows, it 
locks up the files present in the 
 classpath of the javac task, and does not release them. The side effect of 
this is that you will not be able to delete 
 or move those files later on in the build. The workaround is to fork when 
invoking the compiler.
 
 Recommendation:
 
 Change Jasper 2 so that it tells ant to fork the javac compile.  This should 
remove the need
 to synchronize the compiles.  It will also move java compilation outside of 
the JVM process
 Tomcat is running in saving JVM heap memory and reducing GC overhead from 
objects created for
 JSP compiles.  This could be done by just adding another parameter called 
fork to the
 JspServlet paramters. If fork=true ant forks the javac compile and no 
synchronization is done.
 The default for fork would be false.
 
 Comments?
 
 Regards,
 
 Glenn
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [newbie] where do I get TagFileInfo, etc.?

2002-12-04 Thread Kin-Man Chung
It's in jakarta-servletapi-4, which IS mentioned in BUILDING_txt.
Make sure that you have servlet.home defined correctly in build.properties.

 Date: Wed, 04 Dec 2002 17:39:25 -0800
 From: Michael [EMAIL PROTECTED]
 Subject: [newbie] where do I get TagFileInfo, etc.?
 To: [EMAIL PROTECTED]
 
 I'm trying to build jakarta-tomcat-4.0, but it wanted 
 jakarta-tomcat-jasper (not mentioned in BUILDING.txt). I checked that 
 out, but it's build fails with undefined symbols. Where can I find these?
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




[Jasper2] framework for tag optimization

2002-11-22 Thread Kin-Man Chung
I am designing a framework in Jasper for enabling plugins that
work closely with Jasper to generate Java codes instead of calls
to tag handlers.  The main idea is to take take JSTL tags, such as

c:forEach var=i begin=1, end=100
${i}
/c:forEach

and generates the Java codes

for (int i = 0; i = 100; i++) {
pageContext.setAttribute(i, String.valueOf(i));
out.print(evaluate(${i}));
}

or even

for (int i = 0; i = 100; i++) {
out.print(i);
}

The design is not to do the actual optimization in Jasper, but to
provide a framework for taglib writers to develop plugins to Jasper
that will do the actual optimization.  Eventually, Jasper will be
bundled with 1 or 2 plugins for JSTL, as test cases for the framework
and as examples for writing the plugins.

The plugins are specified in a xml file:

tag-plugins
tag-plugin
tag-classthe name of the tag class/tag-class
plugin-classthe name of the pkugin class/plugin-class
/tag-plugin
tag-plugins

There are currently 3 interfaces:

TagPluginFactory
   Used for creating a TagPlugin.
   
TagPlugin
   Created at code generation time for a specific tag invokation.  Used
   by Jasper to generate java codes.
   
TagPlugContext
   Created by Japser and used by the plugin to query properties of
   the current tag, and to use resources in Jasper.
   
This work is at the very early stage of the design, and is purely
experimental.  I'll be checking in sources for this work, and they
should not affect the other part of Jasper, when plugins are not
turned on.

I welcome comments and suggestions.


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: TagHandlerPool doesn't release Tags on reuse

2002-11-11 Thread Kin-Man Chung
According to the JSP 1.2 Spec, the release method is not invoked between
tag usages, but is invoked before GC of the tag handler.  Therefore
it should not be used to reset the tag handler to its initial state;
you should do that in doStartTag.  See p164 and p166.


 Date: Mon, 11 Nov 2002 13:32:31 +0100
 From: Torsten Fohrer [EMAIL PROTECTED]
 Subject: TagHandlerPool doesn't release Tags on reuse
 To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
 
 
 I have some jsp sites which taglibs. With pooling enabled, some problems
 occures. 
 
 Samples:
 
   Customer Registration: all fields have the same values???
   Sessions Values are used together
 
 After reading the jsp spezifikation and source of the
 jasper/runtime/TagHandlerPool, i see that the pool doesn't call release in
 his reuse method? 
 
 After adding a general release in the reuse methode, which perhaps breaks
 the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's working.
 
 /**
  * Adds the given tag handler to this tag handler pool, unless this tag
  * handler pool has already reached its capacity, in which case the tag
  * handler's release() method is called.
  *
  * @param handler Tag handler to add to this tag handler pool
  */
 public synchronized void reuse(Tag handler) {
 
 // Releasing Tags, see jsp spec 1.2-fcs, page 172
 handler.release();
 
 if (current  (handlers.length - 1))
 handlers[++current] = handler;
 }
 
 Torsten Fohrer
 
 **
 * DCSI AG* Tel.: +49 7131 155 88-0   *
 * Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
 * D-74076 Heilbronn  * [EMAIL PROTECTED]*
 * GERMANY* http://www.dcsi.de*
 ** 
 
 --
 To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
 For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
 


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




Re: TagHandlerPool doesn't release Tags on reuse

2002-11-11 Thread Kin-Man Chung
Use doStartTag for inits, doEndTag for cleanups.  release will be invoked
from destroy.


 Date: Mon, 11 Nov 2002 20:34:13 +0100
 From: [EMAIL PROTECTED] (Torsten Fohrer)
 Subject: Re: TagHandlerPool doesn't release Tags on reuse
 X-Sender: [EMAIL PROTECTED]
 To: Tomcat Developers List [EMAIL PROTECTED]
 Content-disposition: inline
 
 
 But if i looking into the generated jsp/servlet sources, i see the following:
 
 --- example ---
   /*   tools:simpleCell  */
   de.dcsi.util.jsp.taglibs.Validator_SimpleCell 
 _jspx_th_tools_simpleCell_0 = (de.dcsi.util.jsp.taglibs.Validator_SimpleCell) 
 _jspx_
 
tagPool_tools_simpleCell_width_valign_messageName_height_errorName_errorColor.ge
t(de.dcsi.util.jsp.taglibs.Validator_SimpleCell.class);
   _jspx_th_tools_simpleCell_0.setPageContext(pageContext);
   _jspx_th_tools_simpleCell_0.setParent(null);
   _jspx_th_tools_simpleCell_0.setErrorName(messages);
   _jspx_th_tools_simpleCell_0.setMessageName(login);
   _jspx_th_tools_simpleCell_0.setHeight(30);
   _jspx_th_tools_simpleCell_0.setValign(top);
   _jspx_th_tools_simpleCell_0.setWidth(14%);
   _jspx_th_tools_simpleCell_0.setErrorColor( errorColor );
   int _jspx_eval_tools_simpleCell_0 = 
 _jspx_th_tools_simpleCell_0.doStartTag();
   if (_jspx_th_tools_simpleCell_0.doEndTag() == 
 javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
 return;
 
 
  example
 
 If i now reset my tag to a initial state in doStartTag() i haven't any 
 properties set
 
 Who call the release method in reaction of the GC, finalize can't it.
 
 On Monday 11 November 2002 18:44, Kin-Man Chung wrote:
  According to the JSP 1.2 Spec, the release method is not invoked between
  tag usages, but is invoked before GC of the tag handler.  Therefore
  it should not be used to reset the tag handler to its initial state;
  you should do that in doStartTag.  See p164 and p166.
 
   Date: Mon, 11 Nov 2002 13:32:31 +0100
   From: Torsten Fohrer [EMAIL PROTECTED]
   Subject: TagHandlerPool doesn't release Tags on reuse
   To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
  
  
   I have some jsp sites which taglibs. With pooling enabled, some problems
   occures.
  
   Samples:
  
 Customer Registration: all fields have the same values???
 Sessions Values are used together
  
   After reading the jsp spezifikation and source of the
   jasper/runtime/TagHandlerPool, i see that the pool doesn't call release
   in his reuse method?
  
   After adding a general release in the reuse methode, which perhaps breaks
   the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's
   working.
  
   /**
* Adds the given tag handler to this tag handler pool, unless this
   tag * handler pool has already reached its capacity, in which case the
   tag * handler's release() method is called.
*
* @param handler Tag handler to add to this tag handler pool
*/
   public synchronized void reuse(Tag handler) {
  
   // Releasing Tags, see jsp spec 1.2-fcs, page 172
   handler.release();
  
   if (current  (handlers.length - 1))
   handlers[++current] = handler;
   }
  
   Torsten Fohrer
  
   **
   * DCSI AG* Tel.: +49 7131 155 88-0   *
   * Lessingstrasse 17-19   * Fax.: +49 7131 155 88-99  *
   * D-74076 Heilbronn  * [EMAIL PROTECTED]*
   * GERMANY* http://www.dcsi.de*
   **
  
   --
   To unsubscribe, e-mail:  
   mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional
   commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
 
  --
  To unsubscribe, e-mail:  
  mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands,
  e-mail: mailto:tomcat-dev-help;jakarta.apache.org
 
 
 --
 To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
 For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
 


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




costin: fix reverted

2002-11-04 Thread Kin-Man Chung
costin,

This fix seems to break errorPage handling in JSP, causing the errorPage
example to fail, and a couple of JSP watchdog tests too.  I have reverted
your fix.

I have not reverted the tomcat_4_branch.

 Date: Thu, 24 Oct 2002 19:18:55 +
 From: [EMAIL PROTECTED]
 Subject: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime 
PageContextImpl.java
 To: [EMAIL PROTECTED]
 
 costin  2002/10/24 12:18:55
 
   Modified:jasper2/src/share/org/apache/jasper/runtime
 PageContextImpl.java
   Log:
   Change the 'flush' to just a 'flushBuffer'.
   
   This allows the container to deal with flushing the buffer (
   wich is done automatically if the servlet doesn't explicitely
   flush()/close() ). The container can attach the Content-Length
   header which is usefull in many cases.
   
   Revision  ChangesPath
   1.27  +11 -6 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImp
l.java
   
   Index: PageContextImpl.java
   ===
   RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/Page
ContextImpl.java,v
   retrieving revision 1.26
   retrieving revision 1.27
   diff -u -r1.26 -r1.27
   --- PageContextImpl.java4 Oct 2002 19:21:44 -   1.26
   +++ PageContextImpl.java24 Oct 2002 19:18:55 -  1.27
   @@ -162,7 +162,7 @@
   this.bufferSize   = bufferSize;
   this.autoFlush= autoFlush;
   this.request  = request;
   -   this.response = response;
   +   this.response = response;

   // setup session (if required)
   if (request instanceof HttpServletRequest  needsSession)
   @@ -209,7 +209,12 @@
   ((JspWriterImpl)out).flushBuffer();
   // push it into the including jspWriter
   } else {
   -   out.flush();
   +// Old code:
   +   //out.flush();
   +// Do not flush the buffer even if we're not included (i.e.
   +// we are the main page. The servlet will flush it and 
close
   +// the stream.
   +((JspWriterImpl)out).flushBuffer();
   }
   } catch (IOException ex) {
   loghelper.log(Internal error flushing the buffer in release());
   @@ -226,7 +231,7 @@
depth = -1;
   baseOut.recycle();
   session  = null;
   -
   + 
   attributes.clear();
}

   
   
   
 
 --
 To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
 For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
 


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




Re: costin: fix reverted

2002-11-04 Thread Kin-Man Chung

 X-Trace: main.gmane.org 1036447809 25208 64.84.39.162 (4 Nov 2002 22:10:09 
GMT)
 Date: Mon, 04 Nov 2002 14:11:32 -0800
 From: Costin Manolache [EMAIL PROTECTED]
 Subject: Re: costin: fix reverted
 To: [EMAIL PROTECTED]
 X-Complaints-to: [EMAIL PROTECTED]
 NNTP-posting-date: Mon, 4 Nov 2002 22:10:09 + (UTC)
 X-Injected-Via-Gmane: http://gmane.org/
 NNTP-posting-host: 64.84.39.162
 
 Kin-Man Chung wrote:
 
  costin,
  
  This fix seems to break errorPage handling in JSP, causing the errorPage
  example to fail, and a couple of JSP watchdog tests too.  I have reverted
  your fix.
  
  I have not reverted the tomcat_4_branch.
 
 If it breaks something - tomcat_4_branch should be the first to revert :-)
 
I reverted tc5 for my own convenience.  I didn't revert tomcat_4_branch
becuase I thought that you may want hack more there.  :-)

 I think the main question is if releasePageContext is required by the 
 spec to flush() ( i.e. commit the message ) or not. 
 

The spec is not specific about this.  So it is up to the implementation. :-)

 If it is required - then Content-Length just can't be set by the container
 for jsps ( which is not the end of the world :-).
 
 If the spec doesn't require that ( and my reading is that releasePageContext 
 doc doesn't in any way imply this as a side effect - the flush() is a very
 different API ) - then I would say the tests are wrong.
 

It's not that the tests are wrong, but that your 'fix' renders any JSP
error page not work at all.  When an exception occurs, instead of displaying
the error page, it displays the stack trace of the exception!  I don't have
anything against not calling flush() in release, but you'll also need to
make sure that it doesn't break this.

 
 
 Costin
 
 
  
  Date: Thu, 24 Oct 2002 19:18:55 +
  From: [EMAIL PROTECTED]
  Subject: cvs commit:
  jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime
  PageContextImpl.java
  To: [EMAIL PROTECTED]
  
  costin  2002/10/24 12:18:55
  
Modified:jasper2/src/share/org/apache/jasper/runtime
  PageContextImpl.java
Log:
Change the 'flush' to just a 'flushBuffer'.

This allows the container to deal with flushing the buffer (
wich is done automatically if the servlet doesn't explicitely
flush()/close() ). The container can attach the Content-Length
header which is usefull in many cases.

Revision  ChangesPath
1.27  +11 -6
  
 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImp
  l.java

Index: PageContextImpl.java
===
RCS file:
  
 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/Page
  ContextImpl.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- PageContextImpl.java   4 Oct 2002 19:21:44 -   1.26
+++ PageContextImpl.java   24 Oct 2002 19:18:55 -  1.27
@@ -162,7 +162,7 @@
 this.bufferSize   = bufferSize;
 this.autoFlush= autoFlush;
 this.request  = request;
-  this.response = response;
+  this.response = response;
 
 // setup session (if required)
 if (request instanceof HttpServletRequest  needsSession)
@@ -209,7 +209,12 @@
 ((JspWriterImpl)out).flushBuffer();
 // push it into the including jspWriter
 } else {
-  out.flush();
+// Old code:
+  //out.flush();
+// Do not flush the buffer even if we're not included
(i.e.
+// we are the main page. The servlet will flush it and
  close
+// the stream.
+((JspWriterImpl)out).flushBuffer();
 }
 } catch (IOException ex) {
 loghelper.log(Internal error flushing the buffer in release());
@@ -226,7 +231,7 @@
 depth = -1;
 baseOut.recycle();
 session  = null;
-
+
 attributes.clear();
 }
 



  
  --
  To unsubscribe, e-mail:  
  mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional
  commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
 
 
 
 
 
 --
 To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
 For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
 


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




Help! Tomcat problem

2002-10-08 Thread Kin-Man Chung

I got the following exception when I run TC5.

I am using xerces-2_0_1.  I tried disable xmlValidation, but still have
the problem.

catalina.sh run
Using CATALINA_BASE:   /home/kchung/tc/jakarta-tomcat-5/build
Using CATALINA_HOME:   /home/kchung/tc/jakarta-tomcat-5/build
Using CATALINA_TMPDIR: /home/kchung/tc/jakarta-tomcat-5/build/temp
Using JAVA_HOME:   /tomc/j2sdk1.4.0/
Oct 8, 2002 7:17:01 PM org.apache.commons.modeler.Registry loadRegistry
INFO: Loading registry information
Oct 8, 2002 7:17:01 PM org.apache.commons.modeler.Registry getRegistry
INFO: Creating new Registry instance
Oct 8, 2002 7:17:03 PM org.apache.commons.modeler.Registry getServer
INFO: Creating MBeanServer
Oct 8, 2002 7:17:06 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on port 8080
Starting service Tomcat-Standalone
Apache Tomcat/5.0
Oct 8, 2002 7:17:08 PM org.apache.catalina.loader.WebappLoader start
INFO: Reloading checks are enabled for this Context
java.lang.NullPointerException
at 
org.apache.catalina.startup.ContextConfig.registerLocalSchema(ContextConfig.java
:740)
at 
org.apache.catalina.startup.ContextConfig.createWebDigester(ContextConfig.java:5
93)
at 
org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:628)
at 
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:774)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:260)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.ja
va:166)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:791)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:497)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:2290)
at org.apache.catalina.startup.Catalina.start(Catalina.java:516)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:402)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: JSP Compilation Issues (Multiple Domains)

2002-09-30 Thread Kin-Man Chung

If you are using JDK javac for compiling the servlet generated by the
JSP compiler, then you probably ran into the problem that the javac
not being thread-safe.

In Tomcat 5 the javac compilation is synchronized, so that the compilation
is serialized.  Guess that fix is not ported to 4.1.5.  :-(

I always assume that JSP pages would be deployed precompiled, and
simultaneous compilation under development mode is rare.  Maybe my
assumption is wrong?


 Date: Mon, 30 Sep 2002 18:30:48 -0700
 From: Joseph Kiok [EMAIL PROTECTED]
 Subject: JSP Compilation Issues (Multiple Domains)
 To: [EMAIL PROTECTED]
 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.
 X-Priority: 3
 X-MSMail-priority: Normal
 
 
 Hi All,
 
 I'm currently running multiple domains (2 specifically) on top of
 Apache/Tomcat.  It seems that when I hit both domains at the same time
 (using 2 browser windows), I get a JSP compilation error most (85%) of the
 time.
 
 However, when I reload the page with no JSP code change, it'll compile
 properly.  (Some of the time like 10-15%, it won't recompile until I touch
 the file manually)
 
 Note: It doesn't happen when I only access one domain.
 
 PROBLEM SUMMARY:
 When loading JSPs on multiple domains (hosts) simultaneously, a JSP compile
 error is generated.
 
 SYSTEM COMPONENTS:
 - Solaris 2.8
 - JDK 1.4.0_01
 - Tomcat 4.1.12
 - Apache 1.3.20
 
 SOLUTIONS TRIED (FAILED):
 - Configured different workers for each domains (hosts) as recommended in
 the tomcat mod_jk document.
 - Downloaded the source of tomcat and recompiled everything on our
 environment.
 
 Any help would be appreciated.
 
 Thanks.
 
 Best regards,
 Joseph Kiok
 
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [VOTE] [5.0] Milestones

2002-09-29 Thread Kin-Man Chung

+1

 Date: Sat, 28 Sep 2002 16:12:06 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: [VOTE] [5.0] Milestones
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Hi,
 
 Now that the first stable releases of Tomcat 4.1 are out (and according 
 to reports, of good overall quality), it could be appropriate to start 
 releasing 5.0.x milestones.
 It should be pointed out that 5.0.x is still far from being feature 
 complete (esp the configuration code needs to be unified if possible, 
 and some optimizations are needed), so the milestones should be 
 considered alpha or pre alpha until further notice.
 
 ballot
 [ ] +1 Yes, start releasing milestones
 [ ] -1 No, because:
 
 
 /ballot
 
 Remy
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: JSR45

2002-09-23 Thread Kin-Man Chung

JSR45 support is already in Tomcat 5, which is yet to be released.  You
can, however, build it from source and try it out yourself.


 Date: Wed, 18 Sep 2002 16:48:00 +0200
 From: Damian Frach [EMAIL PROTECTED]
 Subject: JSR45
 To: [EMAIL PROTECTED]
 
 Hi,
 
 I am a member of the web app group of  the Forte tools.
 
 Our group is responsible for the Tomcat integration with the 
 Netbeans/Forte IDE.
 
 We are now planning new features for the next Forte release. We have 
 plans for a JSR45 implementation.
 Can you give me information of your plans in this issue?
 
 It will really help us.
 
 Thanks, Damian.
 
 -
 Damian Frach   
 
 Software Engineer, Forte Tools   
 Software Platforms and Products   
 
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
 
 Sun Microsystems Czech s.r.o.   
 Evropska 33E   
 160 00 Prague 6 - Dejvice   
 Tel.:   +420 (2)   3300 - 9183
   3300 - 9311
 Fax.:   +420 (2)   3300 - 9299   
 Mobile: +420 (604) 6277 - 20
 
 Private:
 Tunelaru 328 Praha 5 - Zbraslav 15600
  Tel:  +420 (2)   57924924
 Polni 10Stepankovice74728
  Tel:  +420 (653) 6750 - 27
 -
 
 
 
 
 -- 
 -
 Damian Frach  
 
 Software Engineer, Forte Tools
 Software Platforms and Products   
 
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
 
 Sun Microsystems Czech s.r.o. 
 Evropska 33E  
 160 00 Prague 6 - Dejvice 
 Tel.:   +420 (2)   3300 - 9183
3300 - 9311
 Fax.:   +420 (2)   3300 - 9299
 Mobile: +420 (604) 6277 - 20
 
 Private:
  Tunelaru 328 Praha 5 - Zbraslav 15600
   Tel:  +420 (2)   57924924
  Polni 10Stepankovice74728
   Tel:  +420 (653) 6750 - 27
 -
 
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Catalina tester failure on JSP Document Parsing

2002-09-11 Thread Kin-Man Chung

I'd suggest that we remove this test.

Jasper 2 and jasper produces different but correct XML view of the JSP
document.  If the golden file is fixed to pass in TC5, it would then
fail in TC4.0.

 Date: Wed, 11 Sep 2002 18:10:59 -0400
 From: Steve Downey [EMAIL PROTECTED]
 Subject: Catalina tester failure on JSP Document Parsing
 To: [EMAIL PROTECTED]
 
 I'm seeing the following error on catalina's tester app, running it under 
 Tomcat 5:
 
[echo] - JSP Document Parsing -
[tester] EXPECTED: ==
[tester] 
 
atextb/b/aatextb/b/acdtext/d/ccdtext/d/cef/
ftextf/f/eef/ftextf/f/e
[tester] 
[tester] RECEIVED: ==
[tester] 
 
atextb//aatextb//acdtext/d/ccdtext/d/cef/textf/
/eef/textf//e
[tester] 
[tester] FAIL [GET /tester/JspDoc01.jsp HTTP/1.0] Failed Golden File 
 Comparison
 
 
 However, I'm not sure the test is actually correct. It's failing because of 
 the empty elements being converted from b/b to b/, and from f/f to 
 /f. But, under XML, those are identical ways of saying the same thing.
 
 If my analysis is correct, then the golden text needs to be changed, and here 
 is a patch for it. Otherwise, there's a deeper problem.


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: JSP Bug

2002-09-09 Thread Kin-Man Chung

This is not a bug.  Any % that appears in an expression bracketed by
% ... % needs to be escaped as %\ (JSP.2.6).

 Date: Mon, 09 Sep 2002 15:17:04 -0400
 From: Stephane Zafirov [EMAIL PROTECTED]
 Subject: JSP Bug
 To: [EMAIL PROTECTED]
 
 I just wanted to make sure the following bug has been classified. Or maybe
 it is not a bug, but it looks like one.
 
 The following JSP:
 
 %
   String s = %;
 %
 
 is interpreted as:
 
   String s = 
 
 in the java file in the work directory. So it does not compile.
 Obviously, there are workarrounds. I am just making sure it is known to
 everyone. Since its pretty simple, my guess is I am the last one to find it.
 
 Stephane
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servletJspServletWrapper.java

2002-08-28 Thread Kin-Man Chung


 Date: Wed, 28 Aug 2002 16:41:16 -0700 (PDT)
 From: Craig R. McClanahan [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet 
JspServletWrapper.java
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 
 
 On 28 Aug 2002 [EMAIL PROTECTED] wrote:
 
- Fixed 11485: recompilation of jsp files when TLD is modified.
 
 Cool!  This change (and wasn't there another recent change to auto-detect
 changes in files included via %@ include %?) will definitely reduce user
 confusion.
 
The auto-detect of included files is already working in 4.1.x.  I turned
that off for tomcat 5, because it was causing problems with auto
compilation of tag files.  It all works now.

I also turn on auto-detection of changes to files that are included with
include-prelude and include-coda in jsp-config in JSP2.0, usign the
same mechanism.

 Now if I had this one in 4.1.x ... :-)
 
I could back port the TLD dependency check part to 4.1.x if there are
demands for it.

 Thanks,
 Craig
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [4.1.9] New test milestone released

2002-08-12 Thread Kin-Man Chung

There is also this feature/bug in jasper2 regarding the scope of
scripting variables that costin had objected to.  The clarifications
from JSP spec lead inidcates that costin was right.  We should have a
fix this week and that should go into 4.1.10.

  - Kin-man

 Date: Sat, 10 Aug 2002 09:54:02 -0700 (PDT)
 From: [EMAIL PROTECTED]
 Subject: Re: [4.1.9] New test milestone released
 X-X-Sender: [EMAIL PROTECTED]
 To: Tomcat Developers List [EMAIL PROTECTED]
 X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing 
-bs
 
 Remy, 
 
 Let's try to make 4.1.10 the 'stable' release ( and consider 4.1.9 as
 the 'release candidate ). I cleaned up some of the jk messages and
 I want to do some more watchdog tests with apache/jk.
 
 If everyone agree, I think we should also tag jk2 as 'jk2.0beta' and
 jk1.2.0 release, even if we don't distribute a standalone package.
 
 
 Costin
 
 
 On Sat, 10 Aug 2002, Remy Maucherat wrote:
 
  A new test milestone of Tomcat 4.1 has just been released.
  
  Downloads:
  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.9/
  
  Significant changes over 4.1.8 Beta include:
  - Jasper 2 bugfixes
  - Catalina classloader bugfixes
  - Coyote HTTP/1.1 fixes
  - Updated commons-dbcp connection pool
  
  The list of changes is available in the release notes.
  
  Remy
  
  
  --
  To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
  For additional commands, e-mail: mailto:[EMAIL PROTECTED]
  
  
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: javax.servlet.jsp.el.ExpressionEvaluator ????

2002-07-25 Thread Kin-Man Chung

The head branch of jasper2 is meant to be part of Jakarta-tomcat-5, which
in the middle of being set up.  It might be a while before tomcat 5
can be built.

You should check out the tomcat_4_branch of jasper2 for your build.

If you really want to build Jakarta-tomcat-4 with the head branch
of jasper2 with, just to try out JSP2.0 features, then you should
follow the instructions in BUILDING.txt in jasper2.


 Date: Thu, 25 Jul 2002 14:45:07 -0500
 From: Brian Millett [EMAIL PROTECTED]
 Subject: javax.servlet.jsp.el.ExpressionEvaluator 
 To: Tomcat Developers List [EMAIL PROTECTED]
 Content-transfer-encoding: 7bit
 
 I am trying to compile the latest 7/25 cvs co of Jakarta-tomcat-4 and I
 have ran into a problems with jasper2.
 
[javac]
 
/home/bpm/compile_area/cvs_jakarta/jakarta-tomcat-jasper/jasper2/src/share/org/a
pache/jasper/compiler/JspUtil.java:90: package javax.servlet.jsp.el does not 
exist
 [javac] import javax.servlet.jsp.el.ExpressionEvaluator;
 [javac] ^
 
 
 I have no idea where this file might be located.  It is not part of the
 commons, commons-sandbox, taglibs, struts, velocity, etc.
 
 What is it and why was code committed to CVS that references files that
 do not exist?
 
 Thanks.
 
 -- 
 Brian Millett
 Enterprise Consulting Group Shifts in paradigms
 (314) 205-9030 often cause nose bleeds.
 [EMAIL PROTECTED]   Greg Glenn
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspCompilationContext.java

2002-07-18 Thread Kin-Man Chung


 Date: Thu, 18 Jul 2002 14:15:16 -0400
 From: Tim Funk [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper 
JspCompilationContext.java
 To: Tomcat Developers List [EMAIL PROTECTED]
 Content-transfer-encoding: 7bit
 
 Yeah! $ is replaced by _ when JSP's are converted to java files.
 
 Question:
 When someone upgrades to this release, would it be advisable for the 
 user to eliminate the work directory (or clean it) since an older 
 compiled JSP now has the wrong name?


Yes.  It'd be advisable to do so for any new release, anyways.

 Or warn them that every JSP will be recompiled?
 

By all means.  Or do you think we should give the warning in the release
note?

 
 [EMAIL PROTECTED] wrote:
  kinman  2002/07/18 10:57:27
  
Modified:jasper2/src/share/org/apache/jasper Tag: tomcat_4_branch
  JspCompilationContext.java
Log:
- use _ instead of $ to generate file and class names for jsp servlets.

Revision  ChangesPath
No   revision


No   revision


1.6.2.1   +6 -6  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.
java

Index: JspCompilationContext.java
===
RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilati
onContext.java,v
retrieving revision 1.6
retrieving revision 1.6.2.1
diff -u -r1.6 -r1.6.2.1
--- JspCompilationContext.java20 Jun 2002 22:33:57 -  1.6
+++ JspCompilationContext.java18 Jul 2002 17:57:27 -  1.6.2.1
@@ -266,15 +266,15 @@
 new StringBuffer(jspUri.length() - iSep);
  if (!Character.isJavaIdentifierStart(jspUri.charAt(iSep))) {
  // If the first char is not a legal Java letter or digit,
- // prepend a '$'.
- modifiedClassName.append('$');
+ // prepend a '_'.
+ modifiedClassName.append('_');
  }
 for (int i = iSep; i  iEnd; i++) {
 char ch = jspUri.charAt(i);
 if (Character.isLetterOrDigit(ch)) {
 modifiedClassName.append(ch);
 } else if (ch == '.') {
-modifiedClassName.append('$');
+modifiedClassName.append('_');
 } else {
 modifiedClassName.append(mangleChar(ch));
 }



  
  --
  To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
  For additional commands, e-mail: mailto:[EMAIL PROTECTED]
  
  
  
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Missed vote

2002-07-17 Thread Kin-Man Chung

I am sympathetic to Jon's view on separating servlet and JSP API
and repositories.

One result of the separation would make it likely that package names
for JSP 2.0 API may change.  JSP2.0 is now in public review, so it may
be important to raise this issue before the door is closed.

Until the JSP 2.0 spec is changed, it make less sense for us to
have two separate repos.  (It just make more sense to put
javax.servlet.jsp.tagext.TagInfo with javax.servlet classes).


 Date: Wed, 17 Jul 2002 20:28:43 +0200
 From: Paulo Gaspar [EMAIL PROTECTED]
 Subject: RE: Missed vote
 To: Tomcat Developers List [EMAIL PROTECTED]
 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.
 Content-transfer-encoding: 7bit
 Importance: Normal
 X-Priority: 3 (Normal)
 X-MSMail-priority: Normal
 
 For what is worth, I think Jon is 100% right on this one.
 
 And he was cristal clear about the reasons too.
 
 Regards,
 Paulo
 
  -Original Message-
  From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, July 17, 2002 12:43 AM
  To: tomcat-dev
  Subject: Re: Missed vote
 
 
  on 7/16/02 1:14 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote:
 
   What's so painful about a ten-line build.xml target that creates a
   separate JAR file with just the javax.servlet and javax.servlet.http API
   classes, if that's what you need?
  
   Sharing a CVS repository has little or nothing to do with how many
   distributable outputs you create.  On the other hand, having
  both servlet
   and JSP APIs in a single JAR file is quite useful to a very large number
   of existing Tomcat (and other container) users, so it should be
  available
   also.
  
   Craig
 
  I used to say the same thing about Turbine and Torque. You could
  use Torque
  without using any of the Turbine code...yet people refused to use Torque
  because it was packaged in the same jar file as Turbine.
 
  I also think that keeping two different API's in the same .jar file is a
  terrible idea. Think about all the issues we have/had with the XML api's.
  The Servlet API is also on a different release cycle than the JSP API.
 
  Also, having things in the same repo makes it to easy to create
  dependencies
  between the two API's...that is why the JSR's were split as well.
 
  As Pier said, 2 API's, 2 JSR's, 2 CVS repo's.
 
  Consider this my strong -1.
 
  -jon
 
 
  --
  To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compilerGenerator.java

2002-07-16 Thread Kin-Man Chung

Remy,

No they don't: they are bug fixes for JSP2.0 stuff.

I'll make sure bug fixes that apply to both branches get in both branches.
Don't worry!  :-)

- Kin-man

 Date: Wed, 17 Jul 2002 00:43:53 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler 
Generator.java
 To: Tomcat Developers List [EMAIL PROTECTED]
 Content-transfer-encoding: 7bit
 
 [EMAIL PROTECTED] wrote:
  luehe   2002/07/16 15:39:20
  
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
Fixed infinite loop in fragment generation for jsp:body.
 
 BTW, those patches probably need to be also applied to the 4.1 branch.
 
 Remy
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: $ in JSP names

2002-07-15 Thread Kin-Man Chung

I totally agree that the use of $ in a file name is a pain in the neck.
In fact, I don't see the need for appending a $jsp at all.  Currently
we have the following mapping:

jsp file name: foo.jsp
class name: foo$jsp
servelt file name: foo$jsp.java
class file name: foo$jsp.class

I think it'd be perfectly OK to use the following mapping:

jsp file name: foo.jsp
class name: foo
servelt file name: foo.java
class file name: foo.class


 Date: Fri, 12 Jul 2002 14:55:01 -0700 (PDT)
 From: [EMAIL PROTECTED]
 Subject: $ in JSP names
 X-X-Sender: [EMAIL PROTECTED]
 To: List Tomcat-Dev [EMAIL PROTECTED]
 X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing 
-bs
 
 I just upgraded to jikes1.16, and I get one warning for each JSP file
 I compile:
 
 Lexical: The use of $ in an identifier, while legal, is strongly 
 discouraged, since it can conflict with compiler-generated names. If you 
 are trying to access a nested type, use . instead of $.
 
 In addition, it is painfull to look at the source from shell ( need
 to do emacs page\$jsp.jsp ).
 
 Would it be possible to use another delimiter in the generated name ?
 The change is trivial.
 
 Costin
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: $ in JSP names

2002-07-15 Thread Kin-Man Chung

I think you and Craig are both right.  So how about using a _ instead of
a $?


 Date: Mon, 15 Jul 2002 12:48:18 -0700
 From: Arvind Srinivasan [EMAIL PROTECTED]
 Subject: Re: $ in JSP names
 To: Tomcat Developers List [EMAIL PROTECTED]
 Cc: Kin-Man Chung [EMAIL PROTECTED]
 Content-transfer-encoding: 7BIT
 
 
 
 Craig R. McClanahan wrote:
  
  On Mon, 15 Jul 2002, Kin-Man Chung wrote:
  
   Date: Mon, 15 Jul 2002 11:55:15 -0700 (PDT)
   From: Kin-Man Chung [EMAIL PROTECTED]
   Reply-To: Tomcat Developers List [EMAIL PROTECTED],
Kin-Man Chung [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]
   Subject: Re: $ in JSP names
  
   I totally agree that the use of $ in a file name is a pain in the neck.
   In fact, I don't see the need for appending a $jsp at all.  Currently
   we have the following mapping:
  
 jsp file name: foo.jsp
 class name: foo$jsp
 servelt file name: foo$jsp.java
 class file name: foo$jsp.class
  
   I think it'd be perfectly OK to use the following mapping:
  
 jsp file name: foo.jsp
 class name: foo
 servelt file name: foo.java
 class file name: foo.class
  
  
 
 I thought the reason for appending something ($jsp or _jsp) was to
 prevent errors in the generated java files for jsp filenames that use
 one of java's keywords - default.jsp or new.jsp.
 
 -Arvind


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [5.0] [VOTE] New branches and repositories

2002-07-11 Thread Kin-Man Chung


 ballot
 
 A) Servlet 2.4  JSP 2.0 API
 1. [X] Use new jakarta-servletapi-5
 2. [ ] Use the HEAD of jakarta-servletapi
 3. [ ] Other:
 
 B) Catalina 2.0
 1. [X] Use new jakarta-tomcat-catalina
 2. [ ] Use new jakarta-tomcat-5.0
 3. [ ] Use the HEAD of jakarta-tomcat-4.0
 4. [ ] Other:
 
 C) Coyote 2.0
 1. [ ] Yes, use the HEAD of jakarta-tomcat-connectors
 2. [ ] No, use:
 
 D) Tomcat 5.0
 1. [X] Use new jakarta-tomcat-5.0
 2. [ ] Use the HEAD of jakarta-tomcat-4.0
 3. [ ] Use the HEAD of jakarta-tomcat
 4. [ ] Other:
 
 E) Jasper 2.0
 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper
 2. [ ] No, use:
 
 /ballot


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [VOTE] Apache Tomcat 5.0 Proposal

2002-07-08 Thread Kin-Man Chung

+1.

I'll populate jasper2 and servlet-api with initial changes for JSP2.0
support.


 Date: Tue, 02 Jul 2002 16:57:20 -0700
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: [VOTE] Apache Tomcat 5.0 Proposal
 To: Tomcat Developers List [EMAIL PROTECTED]

 After trying to address the concerns raised by the proposal draft, I 
 would like to call for a vote on it, now that the discussions have died 
 down.
 
 ballot
 [ ] +1 I support the proposal, and will help implement it
 [ ] +0 I support the proposal
 [ ] -0 I do not support the proposal
 [ ] -1 I am against the proposal being implemented, because:
 
 
 /ballot
 
 The vote will run for one full week until July 9th. Users and other 
 contributors may vote, but only committers have binding votes.
 
 Remy


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jasper2: serious problem with tag declarations

2002-06-26 Thread Kin-Man Chung


   - in the same case, the 'a' variable is declared at the top
   of the file, even if it is AT_END. That brakes previous iterate
   that used the 'a' id. I believe this is a bug.
  
  According to the spec, the scope of an AT_END variable spans
  from the end element of the tag exposing it to the end of the page.
  
  The previous jasper did not implement this correctly:
  If the tag exposing the AT_END variable was nested, the previous
  jasper would declare the variable at its nesting level, limiting
  its visibility. I think this was in violation of the spec.
 
 However the current jasper exposes it from the beginning of
 the service() method - which is also in violation of the spec.
 ( i.e. AT_END is before AT_BEGIN and anything else ).
 
 
 Costin
 

That's true, but the value of those variables are still synchronized
with the corresponding pageContext attributes at the locations
specified by the spec, so using these variables before they are
synchronized is meaningless.

The spec as is today really cannot be implemented correctly in Java.
What we are doing is let pages that conform to the spec
(e.g. referencing an AT_END variable after end of tag) be compiled
and run correctly, but does not prevent people from writing page that
is not spec conformant (e.g. referencing an AT_END variables in the
body).


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jasper2: serious problem with tag declarations

2002-06-24 Thread Kin-Man Chung

Costin,

 
 On Fri, 21 Jun 2002, Kin-Man Chung wrote:
 
  Use of scripting varibles in nested tag never work before, so obviously
  no body uses it much.  I think the whole scripting variable in JSP1.2 is
  poorly designed, and not well understood.
 
 The failures are from an app that worked perfectly fine with
 jasper1, and with jasper2 ( up to 4.1.4 ). 
 
 And IMHO are very elementary use cases - 2 iterates and one
 condition is not that infrequent.
 

jasper1 and old jasper2 implements scripting variables by declaring them
when a tag handler is instantiated, inside a block of its own, like

{
String x;   // variable x defined here
...
}

This implementation has 2 problems.

1) Nested tags with same variable does not work

mytag:foo
mytag:foo
/mytag:foo
/mytag:foo

   because you cannot have two varibles of the same name in Java, even if
   they are in blocks nested within one another.
   
2) The variables are out of scope when the tag ends, but for variables
   with AT_BEGIN scope, spec says they should be accessable until the
   end of the page.

 
   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 will work.
   
   ( no test case - but I'm sure you can find such tags )
   
  
  That would not work, and would never be made to work, not only for
  nested case, but also for non-nested tags with AT_BEGIN scopes.
  I tend to think this falls into the user's reponsibility if she uses
  the same variable name for two different types, somewhat analogous to
  declaring two variables of the same name two different types in Java.
 
 I'm lost here - wasn't NESTED supposed to define a lexical scoping ?
 I don't see why this wouldn't work - are you saying it doesn't 
 work with jasper2, it didn't worked with jasper1, or is not 
 required by the spec ? 
 

You cannot have

{
String x;
{
String x;
}
}

in Java, so we are implementing scripting variables with nested scopes as

{
String x;
{
String temp = x;
...
}
x = temp;
}

You can see why we'll have problems if two variables nesting with one
anothers have the same name but different types.

 
  Hopefully, there won't be a need for scripting variables anymore when
  expression language becomes available in JSP2.0.
 
 :-)
 
 Unfortunately JSP1.x will be around for a while, and jasper must support
 it. 
 
 Costin
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jasper2: serious problem with tag declarations

2002-06-24 Thread Kin-Man Chung


 My problem is that code that worked with jasper1 no longer works with
 jasper2. 
 
 And I believe the use case is valid and within the spec, and quite
 common.
 
 The latest failure is just 2 iterate tags and a condition tag - 
 I think it should work. 
 
 Costin
 

With the Jan's patch last Friday, jasper 2 should handle those cases
that used to work for japser1, as well as those those that cannot be
handled by jasper1.  If this is not the case, please let me know.

 - Kin-man


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jasper2: serious problem with tag declarations

2002-06-21 Thread Kin-Man Chung

Costin,

 I'm a bit worried here - most of the stuff is pretty basic and 
 common use of tags. Watchdog and the test suite was supposed
 to detect that withou any problems. 
 

Use of scripting varibles in nested tag never work before, so obviously
no body uses it much.  I think the whole scripting variable in JSP1.2 is
poorly designed, and not well understood.

I am also surprised that how much watchdog *does not* test!

 I'll vote for 'alpha' status for the next build, 
 and I hope more people will check their apps against it - 
 I like the changes that are going on, but we need a bit 
 more testing.
 
 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 will work.
 
 ( no test case - but I'm sure you can find such tags )
 

That would not work, and would never be made to work, not only for
nested case, but also for non-nested tags with AT_BEGIN scopes.
I tend to think this falls into the user's reponsibility if she uses
the same variable name for two different types, somewhat analogous to
declaring two variables of the same name two different types in Java.

Hopefully, there won't be a need for scripting variables anymore when
expression language becomes available in JSP2.0.

-Kin-man

 Costin
 
 
 On Fri, 21 Jun 2002, Jan Luehe wrote:
 
  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 %
   %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
   
   logic:iterate id=a name=foo property=bar
   /logic:iterate
   
   logic:present name=b
   logic:iterate id=a name=foo property=bar
   /logic:iterate
   /logic:present
  
  
  last and final attempt! :)
  The attached patch should fix the last issue you brought up.
  
  Since I am still waiting for my commit privileges, Kin-Man
  has again volunteered to apply the patch. Thanks Kin-Man!
  
  
  Jan
  
  
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Jasper2: serious problem with tag declarations

2002-06-18 Thread Kin-Man Chung


 Date: Tue, 18 Jun 2002 11:04:10 +0100
 From: [EMAIL PROTECTED]
 Subject: RE: Jasper2: serious problem with tag declarations
 To: [EMAIL PROTECTED]
 MIME-version: 1.0
 X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3
 Content-transfer-encoding: quoted-printable
 Content-class: urn:content-classes:message
 Delivered-to: mailing list [EMAIL PROTECTED]
 Thread-topic: Jasper2: serious problem with tag declarations
 Thread-index: AcIWizWxrE/eTDHgQNOcNern1B02QQAIq6BA
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 X-Antivirus: nagoya (v4198 created Apr 24 2002)
 X-WDR-Disclaimer: Version $Revision: 1.15 $
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 List-Post: mailto:[EMAIL PROTECTED]
 List-Subscribe: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
 X-OriginalArrivalTime: 18 Jun 2002 10:04:11.0284 (UTC) 
FILETIME=[7E3D7540:01C216AF]
 
 The scope of scripting variables from tags is specified in the Tag. From the 
1.1 spec:
 
 The defined values for scope are:
 · NESTED, if the scripting variable is available between the start tag and the 
end tag of the
 action that defines it.
 · AT_BEGIN, if the scripting variable is available from the start tag of the 
action that
 defines it until the end of the page.
 · AT_END, if the scripting variable is available after the end tag of the 
action that defines
 it until the end of the page.
 The scope value for a variable implies what methods may affect its value...
 
 
 So while declaring two id's the same is an error IMO, the specific tag 
logic:iterate should probably be NESTED rather than AT_BEGIN (which is what's 
happening). 
 
 Checking the struts code (org.apache.struts.taglib.logic.IterateTei), it is 
indeed declared as NESTED. Looks like a Jasper 2 bug then. Time for a few extra 
{}'s?
 

Having extra {}'s is not going to work, because it's not legal java to
have variables of the same name in a method, even if one is in the block
nested with another block containing the other.

There was a problem with scripting variables when a tag is nested in
the same tag, because of the above problem.  But that has been fixed
recently in jasper2.  If costin's page works in old jasper, but not
in jasper2, then it must be something else.


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 Sent: 18 June 2002 06:44
 To: Tomcat Developers List; Kin-Man Chung
 Subject: Re: Jasper2: serious problem with tag declarations
 
 
 On Mon, 17 Jun 2002, Kin-Man Chung wrote:
 
  Costin,
  
  I am not aware that id attribute is handled differently in a tag.
  Can you give a test case for this?  I can look into it more.  Thanks.
 
 I'll try to extract a test case.
 
 There is nothing special about 'id' - just 2 consecutive struts 
  logic:iterate id='foo' . This generates a variable 'foo'
 ( via TLD/TagInfo/etc ), and the problem is that the variable foo is
 declared twice ( there are 2 'Object foo;' in the same scope ).
 
 I'm not very familiar with struts ( but you may find some
 experts on this list :-), but unless I'm doing something very
 stupid in the page, this issue may be serious.
 
 Costin 
 
 
  
  - Kin-man
  
   Date: Mon, 17 Jun 2002 10:41:07 -0700 (PDT)
   From: [EMAIL PROTECTED]
   Subject: Jasper2: serious problem with tag declarations
   X-X-Sender: [EMAIL PROTECTED]
   To: List Tomcat-Dev [EMAIL PROTECTED]
   MIME-version: 1.0
   Delivered-to: mailing list [EMAIL PROTECTED]
   Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
   X-Antivirus: nagoya (v4198 created Apr 24 2002)
   X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
   X-Authentication-warning: costinm.sfo.covalent.net: costin owned process 
doing 
  -bs
   List-Post: mailto:[EMAIL PROTECTED]
   List-Subscribe: mailto:[EMAIL PROTECTED]
   List-Unsubscribe: mailto:[EMAIL PROTECTED]
   List-Help: mailto:[EMAIL PROTECTED]
   List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
   
   
   I see some errors, not sure yet if it's an error in the taglibs or
   jasper but seems serious. ( the taglibs are from struts ).
   
   There are few logic:iterate id=foo  tags in the page, using the 
   same id, and the generated code has:
 Object foo;
 
   
 Object foo;
 ...
   
   That obviously doesn't compile.
   
   I don't know too much about struts, but I suppose it is valid to use
   the same value in 2 tag attributes, couldn't find any reference on 
   the contrary in the spec.
   
   It workes fine with older jasper.
   
   Costin
   
   
   
   --
   To unsubscribe, e-mail:   
mailto:[EMAIL PROTECTED]
   For additional commands, e-mail: 
mailto:[EMAIL PROTECTED]
   
  
  
  --
  To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
  For additional commands, e-mail: mailto:[EMAIL PROTECTED]
  
  
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto

Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

2002-06-14 Thread Kin-Man Chung


 costin  2002/06/14 13:43:05

   Log:
   Second stage of braking jasper2.
 

You think jasper 2 is going too fast?  :-)

Otherwise +1 on the changes.



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compilerCompiler.java

2002-06-14 Thread Kin-Man Chung

 costin  2002/06/14 13:44:37
 
   Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
   Log:
   Split the compile() method in generateJava() and generateClass() - JspC only 
generates
   java, the compile is a separate step.
 
  
Why not have an option to include javac compilation in JspC?  There has
been requests for this functionality. 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




[VOTE] Jan Luehe

2002-06-13 Thread Kin-Man Chung

I'd like to nominate Jan Luehe as a committer to tomcat.

Jan is currently a commiter for Jakarta taglib project, and has been
active in implementing JSTL, the standard tag library.

Jan was involved with jasper 2 from the beginning, and has contributed
to writing a number of important modules in jasper 2.  He has submitted
a number of high quality patches recently, of which the tag pooling/reuse
is an examples.

Jan plans to contribute more to increase the performance of jsp pages,
especially those with tag invokations.  His knowledge in JSTL would
make him an invaluable addition to the tomcat development community.


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtimePageContextImpl.java

2002-06-11 Thread Kin-Man Chung

Remy,

I like this much better!  No private API used, and cleaner generated
codes!

Some nitpicks!  :-)  See below.

There seems to be no need for a JspxState object anymore.
Jspx.State.tagCount is really not used, and JspxState.out can be
make local.  I should just comment that out for now.

 remm2002/06/10 20:35:35
 
   Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
jasper2/src/share/org/apache/jasper/runtime
 PageContextImpl.java
   Log:
   - Take advantage of the fact that the PageContext is pooled.
   - Modify the way the buffer reuse is done to conform with the PageContext
 contract (basically, the code moves from the generated servlet to 
PageContext).
   


   Index: Generator.java
   ===
   RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Gen
erator.java,v

   +out.printil(javax.servlet.jsp.tagext.BodyContent _bc = 
pageContext.pushBody(););
   +out.printil(_bc.clear(););
   +out.printil(out = _bc;);


Can call to clear() be moved to pushBody()?
 
   Index: PageContextImpl.java
   ===
   RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/Page
ContextImpl.java,v

   +protected BodyContent[] outs = new BodyContentImpl[0];

Why not start the array with a small fixed size, say 5, to avoid all
these copying.

   +protected int depth = -1;

public BodyContent pushBody() {
   -JspWriter previous = out;
   -writerStack.push(out);
   -out = new BodyContentImpl(previous);
   -return (BodyContent) out;
   +depth++;
   +if (depth = outs.length) {
   +BodyContent[] newOuts = new BodyContentImpl[depth + 1];
   +for (int i = 0; i  outs.length; i++) {
   +newOuts[i] = outs[i];
   +}
   +newOuts[depth] = new BodyContentImpl(out);
   +outs = newOuts;
   +}
   +out = outs[depth];
   +return outs[depth];
}




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: TC 4.1.3 jasper error

2002-06-07 Thread Kin-Man Chung

I already committed a fix for this problem a couple of days ago.

The problem is of course private instance variables are beening referenced
in a child class.  The 1.3 javac does not flag this as an error, and
1.4 javac gives misleading error messages!

 Date: Fri, 07 Jun 2002 11:32:02 -0400 (EDT)
 From: [EMAIL PROTECTED]
 Subject: Re: TC 4.1.3 jasper error
 To: [EMAIL PROTECTED]
 MIME-version: 1.0
 Content-transfer-encoding: 7bit
 Delivered-to: mailing list [EMAIL PROTECTED]
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 X-Antivirus: nagoya (v4198 created Apr 24 2002)
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 List-Post: mailto:[EMAIL PROTECTED]
 List-Subscribe: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
 
  
  My Eclipse IDE (with Sun JDK 1.3.1_03) give me the following error 
  for Node.java
 
 I had a hard time compiling Node.java in jasper2 until I made this
 change (which I believe doenst change the logic at all)
 
 Index: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
 ===
 RCS file: 
/home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compil
er/Node.java,v
 retrieving revision 1.9
 diff -u -r1.9 Node.java
 --- 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java 
 23 May 2002 21:29:38 -   1.9
 +++ 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java 
 7 Jun 2002 15:26:43 -
 @@ -370,13 +370,13 @@
  * @return The text string
  */
 public char[] getText() {
 -   char[] ret = text;
 -   if ((ret == null)  (body != null)) {
 +   char[] ret = super.getText();
 +   if ((ret == null)  (getBody() != null)) {
 CharArrayWriter chars = new CharArrayWriter();
 -   int size = body.size();
 +   int size = getBody().size();
 for (int i=0; isize; i++) {
 -   chars.write(body.getNode(i).getText(), 0,
 -   body.getNode(i).getText().length);
 +   chars.write(getBody().getNode(i).getText(), 0,
 +   getBody().getNode(i).getText().length);
 }
 ret = chars.toCharArray();
 }
 
 
 Cheers,
 -bob
 
 
  in :
  
  /**
   * When this node was created from a JSP page in JSP syntax, its text
   * was stored as a String in the text field, whereas when this node
   * was created from a JSP document, its text was stored as one or more
   * TemplateText nodes in its body. This method handles either case.
   * @return The text string
   */
  public char[] getText() {
  char[] ret = text;
  if ((ret == null)  (body != null)) {
  CharArrayWriter chars = new CharArrayWriter();
  int size = body.size();
  for (int i=0; isize; i++) {
  chars.write(body.getNode(i).getText(), 0,
  body.getNode(i).getText().length);
  }
  ret = chars.toCharArray();
  }
  return ret;
  }
  }
  
  jakarta-tomcat-4.1.3-b1/org/apache/jasper/compiler/Node.java
  
  Cannot make a static reference to the non-static field text
  
  line 373 in Node.ScriptingElement.getText()
  line 374 in Node.ScriptingElement.getText()
  line 376 in Node.ScriptingElement.getText()
  line 378 in Node.ScriptingElement.getText()
  line 379 in Node.ScriptingElement.getText()
  
  Did someone else get this error ?
  
  
  -
  Henri Gomez ___[_]
  EMAIL : [EMAIL PROTECTED](. .) 
  PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
  PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
  
  
  
  -Original Message-
  From: Jean-Francois Nadeau [mailto:[EMAIL PROTECTED]]
  Sent: Friday, June 07, 2002 3:41 PM
  To: Tomcat Developers List
  Subject: RE: mod_jk 4.03 deadlock
  
  
  Hi.
  
  I found something very interesting this morning in catalina.out file.
  Here it is:
  
  java.lang.IllegalStateException: Current state = FLUSHED, new state =
  CODING_END
  at
  java.nio.charset.CharsetEncoder.throwIllegalStateException(Char
  setEncoder.java:933)
  at
  java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
  at
  sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEnco
  der.java:356)
  at
  sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
  at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
  at 
  java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
  at java.io.PrintWriter.close(PrintWriter.java:137)
  at
  org.apache.catalina.connector.ResponseBase.finishResponse(Respo
  

Re: problem in nested custom tags- Jboss3.0-tomcat4.03.

2002-06-07 Thread Kin-Man Chung

Looks like the same problem as one decribed in bugzilla #9699 that
got reported today.  Good timing!  :-)

 Date: Fri, 07 Jun 2002 15:42:54 +0530
 From: Anil Agrawal [EMAIL PROTECTED]
 Subject: problem in nested custom tags- Jboss3.0-tomcat4.03.
 To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
 Cc: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
 MIME-version: 1.0
 Delivered-to: mailing list [EMAIL PROTECTED]
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 X-Antivirus: nagoya (v4198 created Apr 24 2002)
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 List-Post: mailto:[EMAIL PROTECTED]
 List-Subscribe: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
 
 respected sir,
 
   I am working on Jboss3.0-tomcat4.03.
 
   following jsp (uses nested custom tags) working perfactly fine
   with weblogic6.01.
 
   jsp code is logically right also. at compilation time tomcat throws
 exception
 
 
 ==
 jsp compilation error
 =
 
 D:\jboss-3.0.0_tomcat-4.0.3\catalina\work\localhost\wsc_auth\auth\admin\Assi
 gnDeassignService$jsp.java:350: Variable 'inputError' is already defined in
 this method.
   String inputError = null;
 
 ==
 jsp file
 =
 
  auth:getServiceAssignments   componentId='%=cId%'
 serviceName='%=sName%'
  common:inputError 
   p class=error%=inputError%/p
  /common:inputError
  
 common:businessError
   p class=error%=businessError%/p
 /common:businessError
 
common:commandSuccess
  auth:getAllGroups isAdmin=true   
 
common:inputError 
 p class=error%=inputError%/p
/common:inputError
  
   common:businessError
   p class=error%=businessError%/p
   /common:businessError

 
   common:commandSuccess
   
 /common:commandSuccess
/auth:getAllGroups  
   
 /common:commandSuccess 
/auth:getServiceAssignments 
   
   
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Jsp compilation of nested custom tags (porting from weblogic 6 totomcat 4.0.3)

2002-06-06 Thread Kin-Man Chung

I assume that lOffset is a scripting variable defined either in a variable
element of a tld, or in a TagExtraInfo, and that its declaration (in the
generated java file) is a result of the compiler trying to do its
synchronization with the pagecontext attribute of the same name.

If so, what is the scope of this variable?  Is it NESTED or AT_BEGIN?

I can see how the current Jasper implementation can be problematic,
There are two problems here.

First, if the scope is AT_BEGIN, then the scope of the variable should
remain defined until the end of the page, and the current implementation
actually make it unavailable after the end of the tag, which is wrong.

Second, if the tags are nested, as is your case here, then redclaring
it in the nested block would be illegal Java.

Can you file a bug report in bugzilla for this?  It would help if you
can also include a small test case, so that fixes can be verified.

Thanks.


 Date: Thu, 06 Jun 2002 18:54:11 -0400
 From: Pete Gordon [EMAIL PROTECTED]
 Subject: Re: Jsp compilation of nested custom tags (porting from weblogic 6 to 
tomcat 4.0.3)
 To: Tag Libraries Developers List [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 MIME-version: 1.0 (Apple Message framework v481)
 Delivered-to: mailing list [EMAIL PROTECTED]
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 X-Antivirus: nagoya (v4198 created Apr 24 2002)
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 List-Post: mailto:[EMAIL PROTECTED]
 List-Subscribe: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
 
 Thanks, Shawn.
 
 Let me summarize for the tomcat-dev list.  I have an existing 
 application with custom tags that runs on weblogic 6, when porting it 
 over to Tomcat I now am running into an error where the generated java 
 from a jsp with self nested tags will not compile, the code generated 
 from jspc simulates the HelloWorld sample below, which is not valid java
 
 code--it would be valid in C, but that's another story.
 
 The first htmlGlobalAttribSearch$jsp.java compile error is line 198, 
 variable lOffset is already defined.  There are several (19) more errors
 
 like this that are also outputed from trying to compile the $jsp.java 
 file that I have attached.
 
 public class HelloWorld{
   public static void main(String args[]){
   do{
   int i = 5;
   do{
   int i=10;
   }while(false);
   }while(false);
   }
 }
 
 Tomorrow, I will try to create a minimal nested tag example and see if I
 
 can duplicate the problem.  Unless someone is aware of this problem 
 already, and can save me the effort.
 
 Thanks,
 Pete Gordon
 
 
 
 On Thursday, June 6, 2002, at 03:03 PM, Shawn Bayern wrote:
 
  Hi Pete,
 
  If this is a Tomcat bug, it would be better to mail tomcat-dev about
 it 
  or
  to submit a Tomcat bug report in Apache's Bugzilla
  (http://nagoya.apache.org/bugzilla).  I'd be happy to take a look at
 it
  myself, but it's difficult to identify the problem in a large compiled
  servlet.  (I can't attempt to compile it myself since it depends on
 some
  custom classes not included.)  If you could post the compilation
 error,
  that'd definitely help us determine whether it looks like a Tomcat bug
 
  or
  not.
 
 
 
 From: Pete Gordon [EMAIL PROTECTED]
 Date: Thu Jun 06, 2002  02:32:06 PM US/Eastern
 To: 'Tag Libraries Developers List' [EMAIL PROTECTED]
 Subject: Jsp compilation of nested custom tags (porting from weblogic 6 
 to tomcat 4.0.3)
 Reply-To: Tag Libraries Developers List taglibs-
 [EMAIL PROTECTED]
 
 There is a problem with compiling the genenerated java code
 (htmlGlobalAttribSearch$jsp.java) it tells me that variables have
 already
 been defined.  I have compiled the source file and even created a test
 HelloWorld.java to test it.  It is correct variables have already been
 defined, which we found strange as far as the scope variables were
 accessible, see the code below
 
 public class HelloWorld{
   public static void main(String args[]){
   do{
   int i = 5;
   do{
   int i=10;
   }while(false);
   }while(false);
   }
 }
 
 The JSP page has several nested custom tags (the same tags) and this is
 working on weblogic 6.  But the generated java file from tomcat/jasper 
 does
 not compile.  The problem is the fci:collection tag being nested a few
 times within itself.  See the JSP below.  I think this is a problem with
 
 the
 jspc generated java code.  Am I way off base?
 
 Thanks,
 Pete Gordon
 
 %@ taglib uri=fciTagLib.tld prefix = fci %
 %@ page import=com.fci.arch.service.*%
 
 form action=fci:get resource=site/ method=GET id=form1 
 name=form1
 input type=hidden name=action 
 value=catalogActions.globalParametric

Re: [VOTE] Rate milestone 4.1.3

2002-06-03 Thread Kin-Man Chung


 
 ballot
 [ ] Alpha
 [X] Beta
 /ballot
 
 4.1.3 should be feature complete (at least according to what is in the
 release plan; it now has the Ant compiler in Jasper 2 and a more finalized
 admin webapp), and does not seem to have any major issues, so it looks like
 a decent beta candidate.
 
 Comments ?
 
 Remy
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




JspException in jasper 2?

2002-06-03 Thread Kin-Man Chung

org.apache.jasper.runtime.JspException seems to be serving no purpose,
and it conflicts with javax.servlet.jsp.JspException.

Any objections to my removing it?

BTW, it also exists in tomcat 4/jasper.


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] Tag pooling/reuse in Jasper 2

2002-06-02 Thread Kin-Man Chung

I think it a good idea to limit the stacks to some reasonable value.  One
easy way of accomplishing this is to add a tag object to the stack only
when its stack has not reach its maximum size.

The neat thing about these two approaches is that they can both be
implemented.  Once a tag object is obtained from the stack, the compiler
can assign it to a local variable, and reuse that local variable for
another tag handler in the same page, if needed.  The compiler has full
control over when a tag object returns to the pool (stack).  Like
Jan said, we intended to do such optimization for tags in iteration
bodies.

I know Peter Lin is very interest in this area, and has tools and
applications for measuring performance.  It'd be good if Peter can run
them again after we put back our mods, and tell us what other areas that
need to be worked on.

- Kin-man

 Date: Sat, 01 Jun 2002 18:59:14 -0400 (EDT)
 From: Denis Benoit [EMAIL PROTECTED]
 Subject: Re: [PROPOSAL] Tag pooling/reuse in Jasper 2
 To: Tomcat Developers List [EMAIL PROTECTED], Jan Luehe 
[EMAIL PROTECTED]
 MIME-version: 1.0
 Delivered-to: mailing list [EMAIL PROTECTED]
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 X-Antivirus: nagoya (v4198 created Apr 24 2002)
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 List-Post: mailto:[EMAIL PROTECTED]
 List-Subscribe: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
 
 Hi,
 
 For my part, I'm a little concerned about the second approach.  If there is
 a lot of pages with a lot of distinct tags; tags libraries are catching on
 fast; there may be a problem where Jasper would cache a lot of tags.  If there
 is a sudden burst of use of a given page, the stacks of the tags used by that
 page could grow significantly.  This memory would never be released.  If there
 was some way where the stack could throw away excess tags, then this approach
 would be very good indeed.
 
 The idea I have in mind is the way the Apache 2.X HTTP server manages 
instances.
 When some instances have not been used for some time, it starts to shut them
 down until it reaches the MaxSpareServer number of instances.  This way,
 a sudden burst of use of the web server does not clog the process table or
 the memory of the machine.  This principle was very good.  Something similar
 could very well be as successfull with tag pooling.
 
 This is just my .02
 
 On Fri, 31 May 2002, Jan Luehe wrote:
 
  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 of the
properties, a tag handler that had some optional properties set can
only be reused if those properties are set to a new (known)
value. This means that tag handlers can only be reused within the same
AttSet (set of attributes that have been set).
  
  This means that while the same tag handler instance may be used to
  service these tags:
  
some_prefix:some_tag a=1 b=2/
some_prefix:some_tag a=1 b=3/
some_prefix:some_tag a=1 b=4/
some_prefix:some_tag a=1 b=5/
  
  it may not be used to service
  
some_prefix:some_tag a=1 b=5 c=3/
  
  One of the ideas we have considered is to support tag reuse on a
  per-page basis, without allowing tag handlers to be shared across
  simultaneous page invocations. In this approach, each custom tag is
  assigned a tag handler variable name at compile time, based on its
  full name, its attribute names, and its nesting level (with respect to
  tags with the same name and AttSet). According to this, the two
  prefix1:tag1 tags in:
  
prefix1:tag1 a=1 b=2/
  
prefix2:tag2 c=1 d=2
  prefix1:tag1 a=1 b=2/
/prefix2:tag2
  
  would be assigned the same tag handler variable name (both are at
  nesting level 0 with respect to their tag class), whereas the two
  prefix1:tag1 tags in:
  
prefix1:tag1 a=1 b=2
  prefix2:tag2 c=1 d=2
prefix1:tag1 a=1 b=2/
  /prefix2:tag2
/prefix1:tag1
  
  would be assigned different tag handler variable names, because they
  are at different nesting levels. All tag handler variables determined
  in this fashion would be declared as (local) variables at the beginning of
  the _jspService() method.
  
  The advantages of this approach would be:
  - No need for synchronization.
  - Tag handler reuse is determined at compile time.
  
  Disadvantages would be:
  - Tag handlers are not shared across multiple page invocations.
  - Does not work well with the proposed approach to remove the 64K limit,
  since a (possibly large) number of tag handlers would have to be
  passed as arguments to (sub)method calls.
  
  

Re: [Proposal] Removing 64K limit in jasper 2

2002-05-27 Thread Kin-Man Chung

I am still in vacation mode, unil Thursday.  Just want to giva some
quick response.

 
 Like Costin, I don't think that there would be much performance penalty
 by calling a private method.  In fact, if we want to reduce the number
 of unnecessary calls, I have another idea...  well I have two ideas,
 one of which is not related to the 64 K limit.
 

The performance hit comes not only from the extra calls, but also from
the local instances (e.g. out and tagStack) that need to be passed
to the methods.  Also the increase in the number of methods in a class
cannot be good to VM performance.  Let's hope that Hotspot can do good
job here.  We'll have to see.

 1. In the generated page, there is a lot of consecutive:
 
   out.write(some string);
   out.write(another string);
   and so on.
 
Why don't we merge all these consecutive strings together?
 
   out.write(some string\nanother string);
 
it would greatly reduce the number of write() calls.  So it would
contribute, in a limited way to reduce the size of the _jsp_service()
method.  It would be sligthly faster, which is not bad :) by reducing
the number of method calls.
 

This is actually in my plan.  It would be relative easy
to collapse consecutive writes.  We should also consider the performance
issues Costin raised, and maybe redo the runtime library to achieve better
performance in writing out the String/char[] area.  The key here is to
avoid unnecessary copying.

 2. This one has nothing to do with the size, it's just something that I think
we should plan for: tag reuse.  Some of the pages that have a lot of tags,
do so because they have them in an HTML table.  A big page can reference 
80 or so tags, but these tags can represent only four or five distinct
types.  It is not so difficult to find 80 tags in a page, but it would be
difficult to find one with 80 _distinct_ tag classes!  Most of these tags
could be reused, that is we often call:
 
   tag1 = new SomeTag();
   tag1.doStartTag();
   tag1.doEndTag();
   tag1.release();
   tag2 = new SomeTag();
   tag2.doStartTag();
   tag2.doEndTag();
   tag2.release();
 
   There is no real reason to create a new tag for tag2, it could have
   been replaced by:
 
   tag1 = new SomeTag();
   tag1.doStartTag();
   tag1.doEndTag();
   tag1.doStartTag();
   tag1.doEndTag();
   tag1.release();
 
Here is the relevant section of the JSP specs (I know Kin-Man, you don't 
need
a reminder, but others might :):
 
   public void release()
Called on a Tag handler to release state. The page compiler guarantees
that JSP page implementation objects will invoke this method on all tag
handlers, but there may be multiple invocations on doStartTag and
doEndTag in between.
 
   So, the specs seem to imply that tag reuse is allowed.
 
 Now, why do I brought about this second point, if it is not relevant to the 
64K
 limit?  Just that whatever the solution we'll take to address the issue, it
 should not make tag reuse impossible.  I agree with Kin-Man, Tag will take 
more
 importance in the future of JSP pages.  So we must take whatever measures to
 optimize them.  Most tags won't see a big performance boost from reuse, but 
some
 tags can be pretty hefty, and for them, tag reuse can be a big factor.
 

Believe it or not, tag reuse is also in my plan.  I am in active discussion
with Jan Leuhe in the very topic, and we'll have a proposal soon.  Our
scheme is very different from the one used in tomcat 3.  We want to have
a simple scheme that can reuse tag in the current page, especially tags
in loops.  More about this later.  Therefore I would not do anything
now that'll make doing tag reuse harder.  :-)

 Now, there were two approach to the 64K problem.  Kin-Man proposed creating
 methods for each custom tags, and Costin proposed a state machine.  I tend to
 agree with Kin-Man for one account, at the current state of the compiler,
 Kin-Man's method could be done faster.  I don't think we should throw away
 the state machine implementation, but I see it more as a Jasper 3 / Tomcat 5
 thing :)  At that time, it could be further investigated the benefits and
 penalties of this approach.  But if we choose to delegate each tag to a 
method,
 I think it would be important to leave the door open to tag reuse, that is if 
we
 do not implement it at the same time.
 

Interpreters with state machines may work well for scriptless pages, and
would be an interesting project.  It is however not my current focus for
now.

 Comments?
 
 -- 
 Denis Benoit
 [EMAIL PROTECTED]
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [VOTE] New committer: Denis Benoit

2002-05-22 Thread Kin-Man Chung

+1

Welcome!  And looking forward to working more with you on Jasper performance!

 Date: Tue, 21 May 2002 19:33:27 -0700
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: [VOTE] New committer: Denis Benoit
 To: [EMAIL PROTECTED]
 MIME-version: 1.0
 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.
 Content-transfer-encoding: 7bit
 X-Priority: 3
 X-MSMail-priority: Normal
 Delivered-to: mailing list [EMAIL PROTECTED]
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 X-Antivirus: nagoya (v4198 created Apr 24 2002)
 X-Spam-Rating: localhost.apache.org 1.6.2 0/1000/N
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 List-Post: mailto:[EMAIL PROTECTED]
 List-Subscribe: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
 
 I'd like to propose Denis Benoit Denis.Benoit at fbn.ca as a committer on
 the Tomcat project. Denis has contributed patches to Jasper 2 which brings
 an impressive performance improvement when using JSP pages which rely
 heavily on tags, such as the administration web application available in
 Tomcat 4.1.x.
 He appears willing to spend time to further improve Jasper 2 performance.
 
 He has my +1 as a committer.
 
 Remy
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [Kin-Man] Jasper compiling wrong stuff in the wrong place...

2002-05-21 Thread Kin-Man Chung


 
  Haven't seen that before, and no idea why it's so.  You'll need to
  give me a test case.
 
 Test case: touch
 
  $CATALINA_HOME/webapps/examples/jsp/colors/colrs.jsp
 
 So that Jasper will have to recompile it, and it will try (the first time)
 to recompile also:
 
  $CATALINA_HOME/webapps/examples/WEB-INF/classes/colors/ColorGameBean.java
 
 But putting its class back into
 
  $CATALINA_HOME/webapps/examples/WEB-INF/classes/colors/ColorGameBean.class
 
 Not into
 
  $CATALINA_HOME/work/..
 
 That's pretty nasty, as the user under which the Tomcat process is running
 is not (and can not) write into
 
  $CATALINA_HOME/webapps/.
 

I tried that, and couldn't seem to reproduce your problem.  I tried both
the head branch and the 4.0 branch, on Solaris, there was no recompilation
of ColorGameBean.class.  What configurations do you have?

I looked at the code, and couldn't find the place that would cause the
recompilation of the bean classes.  Would appreciate if anyone else
have insights to this puzzle.  :-)


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] Tomcat 4 System.err/System.out logging

2002-05-21 Thread Kin-Man Chung


  
  However, I'd like to point out that there's no other choice but to upgrade.
  In many situations, the current Jasper 2 generated servlets don't compile to
  valid bytecode when using the classic compiler (and you get a VerifyError
  when loading the class; this happens esp when using JSTL). The J2SE team
  hasn't touched the old compiler code for more than 2 years, and refuse to
  fix bugs :-(
 
 I'm wondering how hard it would be to use BCEL associated with some extended
 JavaCC grammar for JSPs... Bah...
 
 Pier

A distinct possibility, at least for the pages where scriptlets are not
used, in which case JavaCC would not be even needed.


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: Switching javac for jasper 2

2002-05-17 Thread Kin-Man Chung

See below.

 Date: Thu, 16 May 2002 14:07:36 -0700 (PDT)
 From: [EMAIL PROTECTED]
 Subject: Re: Switching javac for jasper 2
 X-X-Sender: [EMAIL PROTECTED]
 To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung 
[EMAIL PROTECTED]
 MIME-version: 1.0
 Delivered-to: mailing list [EMAIL PROTECTED]
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 X-Antivirus: nagoya (v4198 created Apr 24 2002)
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing 
-bs
 List-Post: mailto:[EMAIL PROTECTED]
 List-Subscribe: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
 
 
 com.sun.tools.javac.Main doesn't seem to be in JDK1.2.x, and that's the 
 target platform, isn't it ? 
 

I believe for 4.1.x, it should be 1.3.1 and above.  Like I said, 1.2
javac is currently unsupported and deprecated in 1.3 and 1.4, and contain
bugs that are hard to work around.  Can't image people currently using
jdk1.2 wouldn't want to upgrade.

 I think the best solution for javac is to just bundle ant.jar and
 use it programmatically ( i.e. new Javac(), etc ). The introspection
 and hacks required to support multiple compilers are just too 
 ugly  - and they already have good solutions in ant.
 

I'll look into that.  But even if ant.jar is used programmatically,
eventually it still start another process to invoke javac, right?  Plus
it's  yet another jar to be bundled with tomcat; do we really want
that?

What do others think?


 We already have enough complexity to support jikes.
 
 Costin
 

- Kin-man 
 
 On Thu, 16 May 2002, Kin-Man Chung wrote:
 
  Tomcat has been using sun.tools.javac.Main as the default java compiler
  for compiling the java files generated by Jasper.  This compiler is
  essentially a JDK1.2 compiler, current deprecated and unsupported.
  The warning message Note: sun.tools.javac.Main has been deprecated
  is probably familiar to a lot of people.
  
  The compiler to use is com.sun.tools.javac.Main.  The only thing that
  prevented us from switching over to this one is the fact that it does
  not allow a PrintWriter to be specified for error messages that it
  may produce, which essentially force tomcat to synchronize all
  compilation processes, a big performance hit.
  
  I believe that J2sdk1.4.1, currently targetted for FCS in fall 2002,
  will provide a javac.Main which allows us to specify a PrintWriter,
  essentially removing the need for synchronizing the compilation.  We
  definitely will use that when it becomes available.
  
  However, I recently runs into problem with sun.tools.javac.Main which
  surfaces when a jsp page gets large.  Sometimes it produces bogus
  errors, and somteitmes it even produces bad class files that cannot
  be loaded by VM.  I am contemplating switching over to using
  com.sun.tools.javac.Main now, for 4.1 (jasper2).  If there are objections,
  please let me know.
  
  BTW, anyone know the best way to capture javac error messages written to
  standard err stream?  I want to avoid calling Runtime.getRuntime().exec
  if there is a way.
  
  
  --
  To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
  For additional commands, e-mail: mailto:[EMAIL PROTECTED]
  
  
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [Kin-Man] Jasper compiling wrong stuff in the wrong place...

2002-05-17 Thread Kin-Man Chung

Pier,

Long time no see/talk/eamil.  How are you?

Haven't seen that before, and no idea why it's so.  You'll need to
give me a test case.

Why aren't you using jasper2 instead?  Glenn's recompilation stuff
works great!

- Kin-man

 Date: Fri, 17 May 2002 11:54:38 +0100
 From: Pier Fumagalli [EMAIL PROTECTED]
 Subject: [Kin-Man] Jasper compiling wrong stuff in the wrong place...
 To: Tomcat Developers List [EMAIL PROTECTED]
 MIME-version: 1.0
 Content-transfer-encoding: 7bit
 Delivered-to: mailing list [EMAIL PROTECTED]
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 User-Agent: Microsoft-Entourage/10.0.0.1331
 X-Antivirus: nagoya (v4198 created Apr 24 2002)
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 List-Post: mailto:[EMAIL PROTECTED]
 List-Subscribe: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
 
 When I touch the clsr.jsp jsp example with Tomcat 4.0.4 (and before),
 Jasper tries to compile also the bean associated with it (although it wasn't
 modified)... My only problem is that it tries to compile it in the /WEB-INF/
 directory of the application (and it doesn't have permissions to write
 there), so, at the end, it's just throwing me a 500 error...
 
 Any clue on why Jasper should be trying to compile a .java into the
 WEB-INF/classes directory? I mean, even if it is javac trying to do that,
 giving it the -d parameter, it should always write anything in the work
 directory, right?
 
 Pier
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PATCH] Re: [PROPOSAL] Modification of the code generated byJasper2

2002-05-17 Thread Kin-Man Chung

Denis,

Glad that you agree.  About the timing for the patch, I think now is OK.
Jasper 2 is fairly stable and the only bug that may interact with our
fix is 4964 and I already have a fix for it; but am hold off committing
it because struts depends on this bug, and my fix would break it! :-(

Now down to details.  :-)

Since a popBody is always followed by a release, it would be simpler
to have each stack element consists of two entries:

1. the tag, and
2. the state: 0 - release only
  1 - popBody and release.
  
That way we only need to do one push per tag handler.  Of course, all
tags would get state 0 first, and some of them would change to state 1
later.

For efficiency we can use two separate arrays for implementing the
stack: one for holding the tags, the other for keeping track of the state.
The code generated would be like:

stackIndex = -1;
...
++stackIndex;   // Entering a tag
MyTag mt = new MyTag();
tagStack[stackIndex] = mt;
stateStack[stackIndex] = 0; // state 0
if (_jspx_eval_myTag != EVAL_BODY_INCLUDE) {
stateStack[stackIndex] = 1;
...
}
...
--currentIndex; // Exiting a tag

This way, the size of the stack is the maximum number of nesting of the
tags, which should much smaller than the number of tags in the page.
Such information is easy to collect in Jasper 2, which can be
done either in Validator.java, or we have a separate pass whose sole
purpose is to collect info such as this.

- Kin-man

 Date: Thu, 16 May 2002 23:16:15 -0400 (EDT)
 From: Denis Benoit [EMAIL PROTECTED]
 Subject: Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by 
Jasper2
 To: Kin-Man Chung [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 MIME-version: 1.0
 

 
  Now you mentioned the use of an array to hold tag objects, I have
  another idea.  Why don't we use a stack to simulate the runtime state?
  Each stack entry would have a tag object and a state.  State 0 means
  call release() only, and state 1 means call popBody() and then release().
  We push an entry onto the stack when we enter a tag body, and pop it
  when we exit the body.  We change the state on the stack top when we do
  a pushBody.  When an exception is thrown, we just need to pop the entries
  from the stack to decide what to do.  For efficiency, we can use an
  array to simulate the stack, and its size would be the number of nesting
  of the tags.
  
  I think this is quite simple and faster.  What do you think?
 
 Yes! Yes!
 
 In my last e-mail, I mentionned that there is only two actions that we need
 to do in the finallies.  This is:
 
   1) do a release() on a Tag
   2) do a popBody()
 
 We could push on the stack in this order:
 
 Either:
   1- A tag
   2- The Action identifier for release (a Constant representing 
release())
 Or:
   1- The Action identifier for popBody (a Constant representing 
popBody())
 
 
 Now the finallies code look like this:
 
   While stack is not empty:
   Pop an action
   If action is RELEASE then
   pop a Tag
   Do a Tag.release()
   Otherwise /* Action is assumed to be POPBODY */
   do a popBody()
 
 So the finallies could very well be inlined because it would be short.
 
 The other modification would be when we begin the pseudo finally block.  At
 that point we have to remove from the stack what was pushed at the begin of
 the pseudo try block.  If we do a popBody() in the finally, then we must
 pop one element.  If we do a release(), we will pop two elements.
 
 In the event of an exception anywhere in the page, the stack would contain
 only the actions that must be performed in the order to be performed.  Your
 solution is clean, efficient and simple!
 
 The stack could very well be an Object[], but if we must rely on arrayCopy(),
 to extend the array periodically, would it be really much more efficient than
 using a plain Stack object?  After all, this is the way a Stack is implemented
 by the JDK itself.  On the other hand, we know the lower and upper bounds of 
the
 stack.  Each tag will need to be pushed at least once for the release() and
 the action identifier will need to be pushed too (so we push two times the
 number of Tags in the page).  And maybe we will need to push once more for a
 popBody() (so one more time to indicate the action).
 
 This would give us an array of size 2 to 3 times the number of tags in the 
page.
 I think it would be more efficient to allocate an array of 3 times the number 
of
 tags and save us the occasional overhead of arrayCopy() calls to extend the 
array.
 
 Now, I see two ways to determine the size of the array.  Either, after
 generating the _jsp_service() method, the class Generator could produce the
 declaration

Re: [PATCH] Re: [PROPOSAL] Modification of the code generated byJasper2

2002-05-17 Thread Kin-Man Chung


 
 Now, about the level of nesting, shouldn't the information be available
 through the PageInfo object?  After all, the purpose of this class is
 A repository for various info about the page under compilation.  And
 Generator currently has access to an instance of it.  So, if PageInfo
 had something like a public int getTagElementsMaxNestingLevel() method,
 Generator could use it to allocate the arrays.
 

Yes, the information will be available throught PageInfo object,
and which is updated in either Validator or Collector (I just make this
up).

 We have two changes on the table:
 
 1. Get the information about the level of the nesting with Visitor, or a
separate pass;
 
 2. Remove the finallies and replace it with the two state arrays;
 
 For #2, I'm confident that I could do it without problem.  For the #1, well,
 I've taken a quick look at Visitor, but the change seems to me far less
 obvious.
 
 The way I see it, in the constructor we initialize the nesting to zero.
 Each time:
 
   public void visit(Node.CustomTag n) throws JasperException
 
 is called we increment the nesting, and right after the call visitBody(n);,
 just before the method terminate we decrement the nesting count.
 
 Obviously, we must keep track of the maximum depth level.  The information
 is ready to be used at the end of the:
 
   public static void validate(Compiler compiler, ...
 
 method, this is the one that initiates the visit(XXX) calls, right?.
 
 Would you like me to propose a patch for #1?  For #2?  And what about having
 the maximum CustomTag nesting depth level available through PageInfo?
 

I'll implement maximum tag nesting (though PageInfo) and you can work on
#1.  Deal?

 Thanks!
 

Thanks.

 -- 
 Denis Benoit
 [EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Switching javac for jasper 2

2002-05-16 Thread Kin-Man Chung

Tomcat has been using sun.tools.javac.Main as the default java compiler
for compiling the java files generated by Jasper.  This compiler is
essentially a JDK1.2 compiler, current deprecated and unsupported.
The warning message Note: sun.tools.javac.Main has been deprecated
is probably familiar to a lot of people.

The compiler to use is com.sun.tools.javac.Main.  The only thing that
prevented us from switching over to this one is the fact that it does
not allow a PrintWriter to be specified for error messages that it
may produce, which essentially force tomcat to synchronize all
compilation processes, a big performance hit.

I believe that J2sdk1.4.1, currently targetted for FCS in fall 2002,
will provide a javac.Main which allows us to specify a PrintWriter,
essentially removing the need for synchronizing the compilation.  We
definitely will use that when it becomes available.

However, I recently runs into problem with sun.tools.javac.Main which
surfaces when a jsp page gets large.  Sometimes it produces bogus
errors, and somteitmes it even produces bad class files that cannot
be loaded by VM.  I am contemplating switching over to using
com.sun.tools.javac.Main now, for 4.1 (jasper2).  If there are objections,
please let me know.

BTW, anyone know the best way to capture javac error messages written to
standard err stream?  I want to avoid calling Runtime.getRuntime().exec
if there is a way.


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PATCH] Re: [PROPOSAL] Modification of the code generated byJasper2

2002-05-16 Thread Kin-Man Chung

Denis,

First let me mention a couple of improvements over the existing codes
that was generated for flattening out the try/catch block.  See if
you agree with me.

1. I notice the following code pattern that is now generated.

bitmask.set(1);
addTagToVector(tags, 1, new Integer(_jspx_eval_eg_foo_0));
if (_jspx_eval_eg_foo_0 != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUD
E) {
  out = pageContext.pushBody();
  _jspx_th_eg_foo_0.setBodyContent((javax.servlet.jsp.tagext.BodyContent
) out);
  _jspx_th_eg_foo_0.doInitBody();
}

and from finallies:

if (bitmask.get(1)) {
  if (((Integer)tags.elementAt(1)).intValue() != javax.servlet.jsp.tagext.Ta
g.EVAL_BODY_INCLUDE)
out = pageContext.popBody();
}

I notice that the code bitmask.set(1); is there just for popBody, so
if we move it to inside the test that do pushBody, then we don't need
to do the test in the finallies.  See the codes below.

addTagToVector(tags, 1, new Integer(_jspx_eval_eg_foo_0));
if (_jspx_eval_eg_foo_0 != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUD
E) {
  bitmask.set(1);
  out = pageContext.pushBody();
  _jspx_th_eg_foo_0.setBodyContent((javax.servlet.jsp.tagext.BodyContent
) out);
  _jspx_th_eg_foo_0.doInitBody();
}

and in finallies:

if (bitmask.get(1)) {
out = pageContext.popBody();
}

Maybe you don't need to change the argument for addTagToVector afterall!

2. We don't really need to call finallies if there is no exceptions, so
the call to finallies can be placed in a catch block instead of a finally
block.  This would save us time to check for all the bits that have been
cleared, under normal execution.


Now you mentioned the use of an array to hold tag objects, I have
another idea.  Why don't we use a stack to simulate the runtime state?
Each stack entry would have a tag object and a state.  State 0 means
call release() only, and state 1 means call popBody() and then release().
We push an entry onto the stack when we enter a tag body, and pop it
when we exit the body.  We change the state on the stack top when we do
a pushBody.  When an exception is thrown, we just need to pop the entries
from the stack to decide what to do.  For efficiency, we can use an
array to simulate the stack, and its size would be the number of nesting
of the tags.

I think this is quite simple and faster.  What do you think?



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PATCH] Re: [PROPOSAL] Modification of the code generated byJasper2

2002-05-09 Thread Kin-Man Chung

See intermixed.

 Date: Thu, 09 May 2002 20:48:27 -0400 (EDT)
 From: Denis Benoit [EMAIL PROTECTED]
 Subject: Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by 
Jasper2

 
 Good idea, but I think it would be hard to accomplish as presented.  Look 
again
 at your pseudo-code:
 
  int state = 0;
  // try {// 1st try
  ++state;
  ...
  // try {// 2nd try
  ++state;
  ;;;
  // }// end of 2nd try
  --state;
  // try {// 3rd try
  ++state;
  ;;;
  // }// end of 2nd try
  --state;
  // }// end of 1st try
 
 You'll notice that both state 2 and state 3 have the value 2 assigned to the
 state variable.  What is complex here, is that it is hard to find a generic
 way to represent all the states possible.  Sometimes the states are nested,
 like the first with the 2nd and 3rd.  Sometimes the states follow one another,
 like the second and third.
 

I realized my mistake as soon as I sent it out.  :-) 

 But there is surely something to do.  Suppose we assign distinct values to
 the state variable at each step where we enter a pseudo try and a
 pseudo finally.  Then, theoritically, it should be possible to determine
 in the finallies method, just by looking at the value of the state variable
 what remains to do.  The problem could be to do it in exactly the same order
 that would have been done if the page would have nested try/finally clauses.
 

If we have distinct values for each state, theorectically we can implement
a state transition machine in the finallies.  Something like the following.

while (state  0) {
switch (state) {
case 0: ...
state = 3; break;   // goto state 3
case 1:
state = 13; break;  // goto state 13
...
case 10: ...
state = -1; break   // stop
}
 }
 
This way we can specify any sequence we want.  Of course there are various
optimizations that one can do here, but I won't go into them here.

 If we look at what we have to do in the finallies method, we have 
essentially
 two types of method call.  Either the popBody() or the release() of a Tag.
 I'm certainly not expert enough with the JSP specs to take a decision.  Is it
 critical that we call the release() of the tags in the proper order, if all
 what's left to do is release() calls?  What about the popBody()?
 

popBody() simulates popping stacks, and has to be called in order.

 If we could do the popBody() calls out of order, say after all the 
release()
 have been called, then the case of the popBody() is easy to deal with.  We
 just have to increment a counter for each pushBody() calls and decrement
 it after each popBody() calls.  In the finallies method we only have to
 call popBody() the number of times the value of the counter.  If so, the
 state variable would only to have to represent the different combinations that
 the tags doStartTag() have been called and if their respective release()
 have been called.
 

Unfortunately we cannot call release() before calling popBody(), because
popBody() may use resources released by release().  (I'll need to check
that).

 I'm a little cautious about inlining the finallies method, because of
 java's 64K per method limitation.  One of the first pass of my test JSP did
 generate over 64K in the _jsp_service method, so it generated an Invalid
 branch exception or something named like that.  Once I removed a few tags,
 the page worked fine.  It's easy to bypass by JSP include, but some people
 might find the message cryptic (it is!), to determine what's exactly the
 problem.  The _jsp_service method can be really long, even without the
 finallies being inlined.  That's why I had created a new method.
 

There maybe other ways to branch out part of the code in _jspService to
a method.  I am considering moving the body of a tag that does not have
scriptlets out; but that's just a thought at this moments.

Even if we do keep finallies, it may worth looking into passing all the
necessary objects as arguments to it, instead of putting them in a Vector,
at least for the case with samll number of states.  I think VM spec allows
256 arguments to a method.  :-)  We want to avoid unnecessay codes in
the main flow, but can afford to work harder when exceptions occur.

 Your idea of getting information from the PageInfo is certainly welcome.  This
 way we could prevent the creation of the finallies method and
 addTagToVector.  We could even replace the Vector by an Array that could be
 allocated to the proper size at the start of the method.  It would prevent to
 have to cope with the expansion of a Vector.  Your idea of the state 
variable,
 merit more thought.  There may be a way to use it.
 

Collecting information to PageInfo requires a speparate pass prior to
code 

Re: JSP no reload

2002-04-25 Thread Kin-Man Chung

It is currently not an option to turn off checking out-of-date jsp pages
that triggers recompilations.  There has been some efforts recently at
speeding up this area in jasper2 (Remy'work, Duncan's patch for timestamp
cache, and my recent mods), so you may want to try jasper2 to see if
performans better.

I think a more useful options is to enable deployment of jsp pages
without sources.  I sure that'll break the spec though, so I don't know
if that idea should be persued.


 Date: Wed, 24 Apr 2002 22:39:59 -0400
 From: Samuel Gabriel [EMAIL PROTECTED]
 Subject: JSP no reload
 To: Tomcat Developers List [EMAIL PROTECTED]
 MIME-version: 1.0
 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.
 Importance: Normal
 X-Priority: 3 (Normal)
 X-MSMail-priority: Normal
 Delivered-to: mailing list [EMAIL PROTECTED]
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 List-Post: mailto:[EMAIL PROTECTED]
 List-Subscribe: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
 
 Hi All,
 Is there is a setting in Jasper to disable Tomcat from checking the
 timestamp on the page everytime there is a request? It seems important as
 the more include files are there in the JSP page the more checking that
 could happen, additionaly due to the nature of Java creating a File object
 and check the file system each time could be an expensive process.
 Regards
 Sam


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [PROPOSAL] jasper2 detection of compile time page include changes

2002-04-24 Thread Kin-Man Chung

+1 on the idea.

With minor changes, we can also implement a compiler server that compiles
out-of-date pages in the background thread.  This would greatly improve
the response time for accessing the pages, when recompilations are needed.

 Date: Wed, 24 Apr 2002 10:52:51 -0500
 From: Glenn Nielsen [EMAIL PROTECTED]
 Subject: [PROPOSAL] jasper2 detection of compile time page include changes
 To: [EMAIL PROTECTED]
 MIME-version: 1.0
 Content-transfer-encoding: 7bit
 X-Accept-Language: en
 Delivered-to: mailing list [EMAIL PROTECTED]
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 List-Post: mailto:[EMAIL PROTECTED]
 List-Subscribe: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
 
 A common problem Tomcat users have is that Jasper does not detect when
 a compile time included file %@include file=...% changes so that
 it can recompile dependent JSP pages.  This propsoal maps out a possible
 solution for this.
 
 Create a new class (JspDependency) which is used to store mapping of JSP 
 pages to dependent compile time included files.  This class will be 
 created for each web application context and the data it depends upon
 serialized to a special file in the work directory on context stop,
 and read from that file on context startup.  Proposed filename is
 JSP_DEPENDENCY.ser.
 
 Here is how this integrates into Jasper:
 
 On context start instantiate a JspDependency object and read in the
 dependencies from JSP_DEPENDENCY.ser.  If there are dependencies,
 start a background thread which checks for changes in compile time
 included files once each 5-15 minutes. Perhaps make this configurable.
 If changes are detected, set flags for dependent JSP pages which are 
 affected.  Using a thread to accomplish this rather than having JSP 
 Load do the dependency checks should reduce the request latency 
 overhead for detecting these changes.
 
 The JSP Load method will call a method in JspDependency to determine
 whether the current page needs to be recompiled due to dependency changes.
 This will just be a quick test of a boolean, actual dependency checks
 are done by the background thread.
 
 The JSP page compiler will call a method in JspDependency to remove all
 dependencies for the current JSP page on compile start, then call an
 add method for each compile time include dependency found.
 
 After a JSP page compile has completed any changes to dependencies
 are written back out to the JSP_DEPENDENCY.ser file.
 
 Comments or suggestions?
 
 Regards,
 
 Glenn
 
 --
 Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
 MOREnet System Programming   |  * if iz ina coment.  |
 Missouri Research and Education Network  |  */   |
 --
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




  1   2   >