RE: [4.1.16] New tag ?

[Mladen Turk]

> -Original Message-
> From: Remy Maucherat
> 
> It would be good to have updated native connectors at the 
> same time or 
> before.
> 

Before, IMO.

> I'm posting this to confirm that all the fixes which were 
> needed in JK 
> are in.
> 

Think that Henri is preparing a tag this week for JK1.21, and JK2 2.0.2
is planned to be tagged on Monday, so we could have those and TC in
sync... amazing ;).


MT.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/tester/web/golden SSIVarSub06.txt SSIVarSub01.txt SSIVarSub04.txt SSIVarSub05.txt

[dsandberg]

dsandberg2002/11/23 22:22:37

  Modified:catalina/src/share/org/apache/catalina/ssi SSIConfig.java
SSIExec.java SSIFlastmod.java SSIFsize.java
SSIInclude.java SSIMediator.java SSISet.java
   tester/src/bin tester.xml
   tester/web SSIConditional03.shtml SSIVarSub05.shtml
   tester/web/golden SSIVarSub01.txt SSIVarSub04.txt
SSIVarSub05.txt
  Added:   tester/web/golden SSIVarSub06.txt
  Log:
  Added back Paul Speed's variable substitution SSI enhancement.  Updated 
code/regression tests to better emulate Apache SSI.
  
  Revision  ChangesPath
  1.2   +8 -7  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIConfig.java
  
  Index: SSIConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIConfig.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SSIConfig.java24 May 2002 04:38:58 -  1.1
  +++ SSIConfig.java24 Nov 2002 06:22:36 -  1.2
  @@ -87,13 +87,14 @@
   for(int i=0;i 1 && sb.charAt(i-2) == '\\') {
  +sb.deleteCharAt(i-2);
  +i--;
  +continue;
  + }
  +
  +int nameStart = i;
  +int start = i - 1;
  +int end = -1;
  +int nameEnd = -1;
  +char endChar = ' ';
  +
  +// Check for {} wrapped var
  +if (sb.charAt(i) == '{') {
  +nameStart++;
  +endChar = '}';
  +}
  +
  +// Find the end of the var reference
  +for (; i < sb.length(); i++) {
  +if (sb.charAt(i) == endChar)
  +break;
  +}
  +end = i;
  +nameEnd = end;
  +
  +if (endChar == '}')
  +end++;
  +
  +// We should now have enough to extract the var name
  +String varName = sb.substring( nameStart, nameEnd );
  +
  +String value = getVariableValue( varName );
  +if (value == null)
  +value = "";
  +
  +// Replace the var name with its value
  +sb.replace( start, end, value );
  +
  +// Start searching for the next $ after the value
  +// that was just substituted.
  +i = start + value.length();
  +}
  +
  +return sb.toString();
  +}
  +
   protected String formatDate( Date date, TimeZone timeZone ) {
String retVal;
   
  
  
  
  1.2   +6 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSISet.java
  
  Index: SSISet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSISet.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SSISet.java   24 May 2002 04:38:58 -  1.1
  +++ SSISet.java   24 Nov 2002 06:22:36 -  1.2
  @@ -92,7 +92,8 @@
variableName = paramValue;
} else if ( paramName.equalsIgnoreCase("value") ) {
if ( variableName != null ) {
  - ssiMediator.setVariableValue( variableName, paramValue );
  + String substitutedValue = ssiMediator.substituteVariables( 
paramValue );
  + ssiMediator.setVariableValue( variableName, substitutedValue );
} else {
ssiMediator.log("#set--no variable specified");
writer.write( errorMessage );
  
  
  
  1.84  +24 -0 jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.83
  retrieving revision 1.84
  diff -u -r1.83 -r1.84
  --- tester.xml14 Mar 2002 20:41:38 -  1.83
  +++ tester.xml24 Nov 2002 06:22:36 -  1.84
  @@ -1848,6 +1848,30 @@
request="${context.path}/SSIFsize08.shtml" debug="${debug}"
 golden="${golden.path}/SSIFsize02.txt"/>
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
 
   -->
   
  
  
  
  1.2   +1 -1  jakarta-tomcat-4.0/tester/web/SSIConditional03.shtml
  
  Index: SSIConditional03.shtml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/web/SSIConditional03.shtml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SSIConditional03.shtml29 Nov 2001 03:52:27 -  1.1
  +++ SSIConditional03.shtml24 Nov 2002 06:22:36 -  1.2
  @@ -1,6 +1,6 @@
   Before if block.
   
  -
  +
   test = "unquoted multi

RE: [Jasper2] framework for tag optimization

[Peter Lin]

 
I sent the suggestion a while back to the expert group. 
> AFAIK, the and other tags don't actually generate *any* output
> of their own -- the extra line breaks you are seeing are undoubtedly those
> you've put in the source JSP page itself.


Yes, I was referring to the spaces that are generated by jasper because my original 
JSP source has:



  
  



> Can't you do this with a standard javax.servlet.Filter, without needing to
> integrate it into a compiler? A custom BodyTag of your own could
> certainly do the job as well.


I've considered it, but again it seems like a band-aid solution. It's a bit wasteful 
to have the servlet container generate out.print("\r\n") and then to have a filter 
strip it out. It might not matter for small sites. but if your website gets 1million+ 
hits a day, it adds up. It matters even more if other parts of your application are 
heavy weight and the server has to support a high number of concurrent requests. In my 
hand tweaked tests, it resulted in 10-20% performance improvement. Obviously this 
could easily be solved by putting  statements all in one line, but that 
makes it a pain to read and debug. The test I ran had 400+ extra "\r\n" in the tag 
version vs hand tweaked. when the project requirements state you have to generate a 
complete page of results within 250ms and it takes 200ms to get XML from an app 
server, every bit helps :)

 

Most projects/sites do not have these kids of performance requirements, but it would 
make life easier. I also considered writing a class to parse my JSP before calling 
JSPC, so that's another approach that wouldn't break spec compliance.

 

peter






-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

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

[Paul Speed]

"Craig R. McClanahan" wrote:
> 
> On Sat, 23 Nov 2002, Paul Speed wrote:
> 
> > Date: Sat, 23 Nov 2002 18:50:34 -0500
> > From: Paul Speed <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Why can I not use attributes "lang" and "maxRows" in a
> > custom tag
> >
> > The Java beans API requires getters.  It does not require setters.
> > No setter means the property is read-only.  There's no such thing as
> > write-only in the Java beans API.
> >
> 
> That turns out not to be the case.
> 
> Section 8.3.1 of the JavaBeans Specification makes it clear that you can
> have either a read-only or a write-only property, in addition to a
> read-write property.

Ok, I'll admit this is true... however, (and it may be a personal
problem) the only way I ever got write-only properties to work was
to setup bean info.  I've had problems getting the introspector to 
find these automatically... especially if you have more than one 
setter.  Whereas, if you add a properly typed getter, everything 
magically works without the extra trouble.

I knew as soon as I made an absolute statement right after waking up 
from a nap, I'd regret it. ;)  Now if beans would just get 
multi-valued properties right... but that's another story. :)
-Paul

> 
> JSP custom tags are a pretty good use case for write-only properties --
> the JSP contracts only require an ability to *set* the property values;
> there is no requirement that the attribute values be made publicly
> available to any other class.  After all, the tag implementation class
> will have internal access to the set value, by referencing whatever
> instance variable the setter stored it in.
> 
> > A getter is the only way to determine what the type of the property
> > is since there can be only one getter with a particular name.  The
> > Java beans API is all about deducing all of this information at
> > runtime... so it must be able to figure this out. (For
> > PropertyDescriptors and such.)
> >
> 
> The user's original problem wasn't that they had a write-only property.
> The problem was that the data type of the getter and setter did not match,
> which violates the design patterns of Section 8.3.  Therefore, te
> JavaBeans introspector does not consider this to be an actual JavaBeans
> property.
> 
> > Not 100% useful as a way to do simple reflection though.
> > -Paul
> >
> 
> Craig
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Tomcat 5 Nightly ( Errors

[Matt Raible]

I downloaded the Tomcat 5 binary version from
http://jakarta.apache.org/builds/jakarta-tomcat/nightly-5/ (Nov. 23rd
2002) and I'm trying to get it working.  Below is a condensed list of
error's I'm receiving.  Please let me know what I need to change OR what
I'm doing wrong and I'll attempt to spread the knowledge.

Thanks,

Matt

Apache Tomcat/5.0
Nov 23, 2002 9:02:34 PM org.apache.commons.digester.Digester fatalError
SEVERE: Parse Fatal Error at line 307 column 39: The string "--" is not
permitted within comments.
org.xml.sax.SAXParseException: The string "--" is not permitted within
comments.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unkno
wn Source)

Nov 23, 2002 9:02:34 PM org.apache.catalina.startup.ContextConfig start
SEVERE: Exception processing TLD at resource path /WEB-INF/controls.tld
javax.servlet.ServletException: Exception processing TLD at resource
path /WEB-INF/controls.tld
at
org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:
1159)

Nov 23, 2002 9:02:34 PM org.apache.catalina.startup.ContextConfig start
SEVERE: Marking this application unavailable due to previous error(s)
Nov 23, 2002 9:02:34 PM org.apache.catalina.session.ManagerBase
getRandom
INFO: Seeding random number generator class java.security.SecureRandom
200
Nov 23, 2002 9:02:34 PM org.apache.catalina.core.ContainerBase log
INFO: Context startup failed due to previous errors
Nov 23, 2002 9:02:34 PM org.apache.catalina.startup.ContextConfig
authenticatorConfig
INFO: Configured an authenticator for method BASIC
Nov 23, 2002 9:02:37 PM org.apache.catalina.core.ContainerBase log
INFO: Installing web application at context path /jsp-examples from URL
file:d:/tools/jakarta-tomcat-5.0/webapps/jsp-exa
mples
Nov 23, 2002 9:02:37 PM org.apache.commons.digester.Digester fatalError
SEVERE: Parse Fatal Error at line 307 column 39: The string "--" is not
permitted within comments.
org.xml.sax.SAXParseException: The string "--" is not permitted within
comments.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unkno
wn Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown
Source)

Nov 23, 2002 9:02:37 PM org.apache.catalina.startup.ContextConfig start
SEVERE: Exception processing TLD META-INF/sql-rt.tld in JAR at resource
path /WEB-INF/lib/standard.jar
javax.servlet.ServletException: Exception processing TLD
META-INF/sql-rt.tld in JAR at resource path /WEB-INF/lib/standa
rd.jar
at
org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:
1079)
at
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:100
5)






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

java.util.logging.* and namespace/classloading/security issues

[j.random.programmer]

Hi:

If and when JDK 1.4 becomes the minimum platform 
for Tomcat, the following must be kept in mind:

The java.util.logging framework provides a global
namespace that by default is tied to the system 
classloaders. J2EE apps should modify this so that
the java.util.logging namespace is specific only
to the app/context specified classloader. 

Here's why:

Loggers are installed and managed by names that 
are common to all classes in the JVM. For example, I 
can install a logger called "Foo".

Now any virtual host or servlet context running in
a J2EE container can access that logger by the name
"Foo". It's also possible for any code to get a
enumeration of all installed loggers in the JVM so
I don't even have to know the name beforehand.

Suppose I am a hosting company and I host 2 seperate
domains using the same J2EE container. Suppose these
domains are called www.a.com and www.b.com

What happens now is that www.b.com can redirect,
change or view any loggging statements made by any 
code running inside www.a.com. To prevent just this 
sort of thing, the servlet spec mandates seperate 
classloaders for different virtual hosts and even 
different contexts within the same host.

The logging documentation has this to say:

-- quote --
For J2EE applications, the J2EE container
typically controls the environment and provides
the shared services that are used by all the
contained components. All the “global” state in
the Logging APIs is maintained in the LogManager
class. The Log-Manager APIs allow a program to
substitute its own version of the LogManager
class. Thus a J2EE container can replace the
standard LogManager class with its own subclass
that may implement different rules for managing
"global" state. For example, a J2EE container
might provide separate logging namespaces for
logically distinct applications that are sharing
the container.
-- end quote --

This can be found in Section 2.19 ("J2EE Issues")
at the following URL:

http://www.jcp.org/aboutJava/communityprocess/review/jsr047/spec.pdf

Note, not changing the LogManager namespace also
implies
ClassCastExceptions (across reloads) in the same web
application.

Here's a bug report on the same subject (although
somewhat harshly worded):

http://developer.java.sun.com/developer/bugParade/bugs/4744186.html

Tomcat must load all java.util.logging classes via
seperate classloaders because even though tomcat
itself does not use java.util.logging internally, the
client code (i.e., my servlet code and 3rd party
library code *does* use java.util.logging).

Best regards,

--j


__
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Craig R. McClanahan]

On Sat, 23 Nov 2002, Paul Speed wrote:

> Date: Sat, 23 Nov 2002 18:50:34 -0500
> From: Paul Speed <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Why can I not use attributes "lang" and "maxRows" in a
> custom tag
>
> The Java beans API requires getters.  It does not require setters.
> No setter means the property is read-only.  There's no such thing as
> write-only in the Java beans API.
>

That turns out not to be the case.

Section 8.3.1 of the JavaBeans Specification makes it clear that you can
have either a read-only or a write-only property, in addition to a
read-write property.

JSP custom tags are a pretty good use case for write-only properties --
the JSP contracts only require an ability to *set* the property values;
there is no requirement that the attribute values be made publicly
available to any other class.  After all, the tag implementation class
will have internal access to the set value, by referencing whatever
instance variable the setter stored it in.

> A getter is the only way to determine what the type of the property
> is since there can be only one getter with a particular name.  The
> Java beans API is all about deducing all of this information at
> runtime... so it must be able to figure this out. (For
> PropertyDescriptors and such.)
>

The user's original problem wasn't that they had a write-only property.
The problem was that the data type of the getter and setter did not match,
which violates the design patterns of Section 8.3.  Therefore, te
JavaBeans introspector does not consider this to be an actual JavaBeans
property.

> Not 100% useful as a way to do simple reflection though.
> -Paul
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Nightly TC 3.3.x builds not working anymore?

[Larry Isaacs]

Hi Sam,

Thanks for the offer.  However, since changes are infrequent,
I like the idea building the occasional 3.3.2-dev version
with the exact same script I will use to build a release
version, one of these days.  Hopefully, I'll be able to come
up for air in the near future and help out a little more
around here.

Cheers,
Larry 

> -Original Message-
> From: Sam Ruby [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, November 20, 2002 10:01 PM
> To: Tomcat Developers List
> Subject: RE: Nightly TC 3.3.x builds not working anymore?
> 
> 
> 
> 
> 
> 
> Costin Manolache wrote:
> >
> > We could use the gump-generated builds.
> > ( it seems we just need to zip the build tree and add a symlink )
> 
> Just let me know what directories you want zipped and/or what 
> generated
> files you want copied.
> 
> - Sam Ruby
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Paul Speed]

The Java beans API requires getters.  It does not require setters.
No setter means the property is read-only.  There's no such thing as
write-only in the Java beans API.

A getter is the only way to determine what the type of the property
is since there can be only one getter with a particular name.  The 
Java beans API is all about deducing all of this information at 
runtime... so it must be able to figure this out. (For 
PropertyDescriptors and such.)

Not 100% useful as a way to do simple reflection though.
-Paul

[EMAIL PROTECTED] wrote:
> 
> If Tomcat uses the "beans" API in Java to do the reflection for calling
> these methods, then that is probably why.
> It insists on having a valid get and set method for an attribute for some
> reason.  I ran into this once when I only wanted
> to have "getters" with no setters, and I couldn't find a way around it
> other than to use reflection directly (mind you,
> I was in a hurry, so I didn't try too hard).
> 
> -- Rob
> 
> 
>   "Jim Cobban"
>   <[EMAIL PROTECTED]To:   "Jan Luehe" 
><[EMAIL PROTECTED]>
>   >cc:   
><[EMAIL PROTECTED]>
>Subject:  Re: Why can I not use 
>attributes "lang" and "maxRows" in a custom tag
>   23/11/2002 11:17
>   AM
>   Please respond to
>   "Tomcat
>   Developers List"
> 
> 
> 
> - Original Message -
> From: "Jan Luehe" <[EMAIL PROTECTED]>
> Subject: Re: Why can I not use attributes "lang" and "maxRows" in a custom
> tag
> 
> > > Tomcat 4.1.12 does not accept a custom tag with attributes "lang"
> > > or "maxRows".  When I asked about this on the Tomcat users list I was
> > > informed that it also does not accept the attribute "class".
> > >
> > > Specifically if I define those attributes then when the jsp is compiled
> I
> > > get an "unable to find setter" error.  If I replace them with similar
> but
> > > meaningless attribute names the page compiles correctly.
> >
> > This can't be true. For example, JSTL defines an attribute
> > named 'maxRows' for its  action.
> > I am not aware of any naming restrictions for custom tag attributes.
> >
> > Are you sure the tag handler for your custom action
> > defines an approriate setter method for the attributes in
> > question?
> 
> I kept experimenting and found exactly what it was that Tomcat disliked
> about my attribute.  It was not the name.  It was not the presence or
> absence of the set method.  It was that there was also a get method which
> did not return String!  Since Tomcat does not use the get method I do not
> understand why it cares whether or not one is present or what its signature
> is.  But as soon as I change the name of the get method so it did not match
> the set method Tomcat merrily accepted the tag.
> 
> For me this is now an issue of documentation.  I have searched the JSP 1.2
> spec using every term I can think of and I cannot find where it specifies
> the characteristics of the set method for an attribute on a custom tag.  I
> have therefore been depending upon the description of this capability in
> Marty Hall's book.  If the JSP specification, and Tomcat, have a legitimate
> reason for looking at the characteristics of the get method when deciding
> whether or not to use the set method, then that should be documented.
> Otherwise the behavior is frankly mysterious.
> 
> Thank you for responding.  When a week went by without a response I
> unsubscribed from the list, so the CC on this message may be discarded.
> 
> --
> To unsubscribe, e-mail:    >
> For additional commands, e-mail:  >
> 
> If you received this e-mail in error please delete it and notify the sender as soon 
>as possible. The contents of this e-mail may be confidential and the unauthorized 
>use, copying, or dissemination of it and any attachments to it, is prohibited.
> 
> Internet communications are not secure and Hyperion does not, therefore, accept 
>legal responsibility for the contents of this message nor for any damage caused by 
>viruses. The views expressed here do not necessarily represent those of Hyperion.
> 
> For more information about Hyperion, please visit our Web site at www.hyperion.com
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Jim Cobban]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Subject: Re: Why can I not use attributes "lang" and "maxRows" in a custom
tag


>
> Tomcat cares because JSP custom tags are required to implement the
> standard JavaBean naming patterns for property-related methods, as defined
> in the JavaBeans Specification.
>
>   http://java.sun.com/products/javabeans/
>
> >
> > For me this is now an issue of documentation.  I have searched the JSP
1.2
> > spec using every term I can think of and I cannot find where it
specifies
> > the characteristics of the set method for an attribute on a custom tag.
I
> > have therefore been depending upon the description of this capability in
> > Marty Hall's book.  If the JSP specification, and Tomcat, have a
legitimate
> > reason for looking at the characteristics of the get method when
deciding
> > whether or not to use the set method, then that should be documented.
> > Otherwise the behavior is frankly mysterious.
>
> In the JSP 1.2 spec, section JSP.10.1:
>
> "A tag handler has some properties that are exposed to
> the page as attributes on an action; these properties
> are managed by the JSP container (via generated code).
> The setter methods used to set the properties are discovered
> using the JavaBeans introspector machinery."
>
> The last sentence refers to the java.beans.Introspector class, which
> refers you to the JavaBeans spec.

Thank you for the pointers.  I appreciate that exploiting the existing
support for Beans is the obvious way for Tomcat to acquire this information
about the class, even if Tomcat never uses the get method.  I merely hope
that the documentation can be improved to be a little less obscure so that
other programmers like myself, who do not have the time to become intimately
familar with all aspects of Java technology, can be brought up to speed with
less wasted effort.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Nightly TC 3.3.x builds not working anymore?

[Sam Ruby]

Costin Manolache wrote:
>
> We could use the gump-generated builds.
> ( it seems we just need to zip the build tree and add a symlink )

Just let me know what directories you want zipped and/or what generated
files you want copied.

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Jasper2] framework for tag optimization

[Craig R. McClanahan]

On Sat, 23 Nov 2002, Peter Lin wrote:

> Date: Sat, 23 Nov 2002 12:36:50 -0800 (PST)
> From: Peter Lin <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: RE: [Jasper2] framework for tag optimization
>
>
>  So it would seam having a plugin framework wouldn't necessarily break
> conformance. On the otherhand, I would still like to see the expert
> group to seriously consider making plugin framework a standard feature
> of JSP compiler.  Beyond performance, there are other good reasons to do
> so.
>

The best place for this feedback would be to the JSP 2.0 expert group
([EMAIL PROTECTED]).

Personally, I'd be surprised if such a suggestion were implemented, since
there is very little in the JSP spec (or most Java specs) about
implementation.  In particular, there is no requirement that there even be
such a thing as a JSP page compiler -- an interpreted implementation would
be legal as well.

> For one, JSTL pages generate a lot of out.print("\r\n") when
>  statemetns are used.

AFAIK, the  and other tags don't actually generate *any* output
of their own -- the extra line breaks you are seeing are undoubtedly those
you've put in the source JSP page itself.

> Rather than have a tag handle the
> body and trim, I would prefer to see a plugin framework that gives
> application developers the ability to strip out extra control linefeeds
> or spaces. For example, some one may want to format their jsp code so it
> is easier to read, but often it breaks HTML formatting. There should be
> an easy way for page developers to write basic filters for jasper that
> allows a plugin to strip tabs and control linefeeds. Not only would this
> reduce the size of the generated page, but it should provide significant
> improvement for pages with lots and lots of tags.
>

Can't you do this with a standard javax.servlet.Filter, without needing to
integrate it into a compiler?  A custom BodyTag of your own could
certainly do the job as well.

> peter lin

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[4.1.16] New tag ?

[Remy Maucherat]

Hi,

Some important fixes went into JK since 4.1.15, some of which were in 
the Java side. I plan to abandon the current 4.1.15 alpha and make a new 
4.1.16 alpha release of Tomcat, to pick up those changes. This release 
looks good on paper, and could be considered for promotion to Beta or 
Stable (GA for the purists ;-) ). At the same time, I'll also release a 
new 5.0.1 alpha.

It would be good to have updated native connectors at the same time or 
before.

I'm posting this to confirm that all the fixes which were needed in JK 
are in.

Thanks,
Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Jasper2] framework for tag optimization

[Peter Lin]

 
So it would seam having a plugin framework wouldn't necessarily break conformance. On 
the otherhand, I would still like to see the expert group to seriously consider making 
plugin framework a standard feature of JSP compiler.  Beyond performance, there are 
other good reasons to do so.
 
For one, JSTL pages generate a lot of out.print("\r\n") when  
statemetns are used. Rather than have a tag handle the body and trim, I would prefer 
to see a plugin framework that gives application developers the ability to strip out 
extra control linefeeds or spaces. For example, some one may want to format their jsp 
code so it is easier to read, but often it breaks HTML formatting. There should be an 
easy way for page developers to write basic filters for jasper that allows a plugin to 
strip tabs and control linefeeds. Not only would this reduce the size of the generated 
page, but it should provide significant improvement for pages with lots and lots of 
tags.
 
peter lin
 
 
 "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:Building the pluggability framework 
pretty much has to be done by the
Jasper developers. Implementing plugins for a particular type of
optimization (such as a JSTL recognizer/optimizer) could be done by Jasper
developers or by anyone else.

The way to ensure correctness of a Jasper+Plugin (of any type) is to
ensure that it still passes the TCKs for the APIs it claims to implement
(JSP x.y of course, and JSTL if we're talking about that particular kind
of a plugin).

There's really two proposals -- a pluggability interface into Jasper's
page compiler, and a specific use of this interface for optimizing the
code generated for JSTL tags. The pluggability would be available to
anyone using Jasper (and, in the past at least, that includes more than a
few J2EE platform vendors). None of this is likely to be done by typical
application developers -- it's much more likely to be container developers
that use it.

On the other hand, I wonder if people running Struts-based apps on Tomcat
would enjoy it if we did a pluggable optimizer for the Struts tags ...




-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

DO NOT REPLY [Bug 14797] - Request headers are broken after invoking pageContext.include()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14797

Request headers are broken after invoking pageContext.include()

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-23 20:05 ---
Fixed in 4.1.15

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Jasper2] framework for tag optimization

[Craig R. McClanahan]

On Sat, 23 Nov 2002, Peter Romianowski wrote:

> Date: Sat, 23 Nov 2002 18:05:29 +0100
> From: Peter Romianowski <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: 'Tomcat Developers List' <[EMAIL PROTECTED]>
> Subject: RE: [Jasper2] framework for tag optimization
>
> > If you think using it for JSTL is okay, why wouldn't it be
> > okay for other tag libraries? The same issues (if they are
> > issues) apply to JSTL, don't they?
>
>   I thought of it beeing done by the jasper-crew, i.e. being
> part of "stock tomcat", so it could be assured that it is
> working correct.
>

Building the pluggability framework pretty much has to be done by the
Jasper developers.  Implementing plugins for a particular type of
optimization (such as a JSTL recognizer/optimizer) could be done by Jasper
developers or by anyone else.

The way to ensure correctness of a Jasper+Plugin (of any type) is to
ensure that it still passes the TCKs for the APIs it claims to implement
(JSP x.y of course, and JSTL if we're talking about that particular kind
of a plugin).

>   The way I understand the proposal is that it *could* be some kind of
> a replacement for a tag-library. So for conformity and interoperability
> a programmer would have to implement the plugin *AND* the taghandler.
> (And I extremely doubt that many will).
>

There's really two proposals -- a pluggability interface into Jasper's
page compiler, and a specific use of this interface for optimizing the
code generated for JSTL tags.  The pluggability would be available to
anyone using Jasper (and, in the past at least, that includes more than a
few J2EE platform vendors).  None of this is likely to be done by typical
application developers -- it's much more likely to be container developers
that use it.

On the other hand, I wonder if people running Struts-based apps on Tomcat
would enjoy it if we did a pluggable optimizer for the Struts tags ...

>  I was involved in a discussion about a "precompile all JSPs in a
> webapp"-functionality (which was wanted by *many* users). I was
> willing to contribute to it, but the developers (Craig himself,
> I think :) said that such a thing would not belong to a reference i
> mplementation of a servlet-container. After he told me so, I agreed
> with him, although I still would like to have  this feature. :) So
> that was the reason why I posted my comments.
>

Tomcat has grown way past the days when it's sole purpose was to be the
basis of the reference implementation (although it's still playing that
role).  It has lots of very useful features, and the performance
improvements due to things like Coyote have been quite impressive.

At ApacheCon this last week, Glenn Nielsen (a Tomcat committer) gave a
session on performance tuning Tomcat, and he polled the room on how many
people actually had Tomcat deployed in production environments.  Over
three quarters of the people in the room raised their hand.

>From recent discussions about jspc, it's obvious that lots of people would
like to see this capability not only retained, but improved.  The best way
to make that happen, IMHO, would be for someone to take the lead in
accumulating design requirements that we can agree to.  I don't have time
to do that, but it would seem a natural next step.

>   As an application developer I would say: "YES! Give me that plugin-
> feature!" since it would improve performance drastically. So, I like
> the idea but I am not sure if such a thing would belong to "stock
> tomcat".
>
>
> anyway,
> Peter
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Jasper2] framework for tag optimization

[Craig R. McClanahan]

On Sat, 23 Nov 2002, Peter Romianowski wrote:

> Date: Sat, 23 Nov 2002 15:22:15 +0100
> From: Peter Romianowski <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: 'Tomcat Developers List' <[EMAIL PROTECTED]>
> Subject: RE: [Jasper2] framework for tag optimization
>
>   Just a thought: Doesn't this breack the standard conformance
> tomcat is all about? One could easily be bound to tomcat after
> writing some plugins that break the initial semantics of a tag.
> I think there is no way to assure the correctness of a plugin-
> implementation, so it would become impossible to switch to
> another servlet-container. And I saw many improvement-discussion
> on this list, which had been canceled with exact this reason.
>

There's always been some confusion about the "standard conformance tomcat
is all about" concept.

First, Tomcat itself is *not* the reference implementation of the servlet
and JSP specs.  Instead, its code is *used* in the reference
implementation for these specs, and all the other J2EE platform ones --
the J2EE reference implementation.

Until last March, there was no mechanism available to certify yourself as
compliant with only the servlet and JSP specs, without complying with all
of them.  As a result of the agreement between Sun and Apache, however, it
is now possible to get just the servlet and JSP TCKs, and test your
servlet/JSP container.  It would be possible for Tomcat, or any other
container that only implemented these specs, to certify themselves -- but
they are still not the official RI.

The same thing happens with JSTL -- the JSTL TCK defines the behavior of
(what amounts to) a JSP+JSTL container.  If the TCK tests pass, that means
(to the extent validated by the tests) that standards conformance is being
maintained, and portability remains assurred.  It'll just run faster :-).
If the TCK tests don't pass, that means that the optimizations being
applied are breaking conformance -- that would be a bug that would need to
be fixed.

Take the specific case of .  What the JSTL spec describes
(Section 6.2) is the *effect* of using this tag in your JSP page:
"repeats its nested body content over a collection of objects, or repeats
it a fixed number of times."  It also describes how you configure the
behavior, via the attributes, and how you can optionally expose
LoopTagStatus information inside the body.  However, nowhere in the
description is there any mention that  has to actually *be* a
custom tag invoked via the standard tag invocation protocol.  This is what
gives a JSP page compiler the freedom to recognize "well known" tag
libraries and do special things.  As long as the behavior described in the
spec are faithfully executed, it's perfectly legal for the compiler to
implement this as an appropriate "for" statement instead of as a tag.
Your application will never know the difference.

Of course, an application developer can still do things to mess up the
portability of their apps (like relying on the internal implementation
details of the APIs you use) -- but as long as you use only the public
APIs described in the specs, and the container you are running on passes
the relevant TCKs, you've got some pretty solid assurances of portability.

>   But having plugins for standard tags (JSTL) out of the box
> would be great in respect of performance.
>

Yep.

> Just my $0.02
>
> Peter
>

Craig


> > -Original Message-
> > From: Peter Lin [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, November 23, 2002 4:59 AM
> > To: Tomcat Developers List; Kin-Man Chung
> > Subject: Re: [Jasper2] framework for tag optimization
> >
> >
> >
> > hey kin-man,
> >
> > that sounds great!  I was actually thinking along those lines
> > a while back, but thought it was impracticle because the
> > project I was working one didn't have enough time to explore
> > that approach.
> >
> > when I was doing performance analysis of jasper1 with jslt
> > and saw how bad the performance was (due to the nested
> > try/catch bug), I went through and manually wrote scriplet
> > code to do the same exact logic. The performance compared to
> > jasper1 + jstl was tremendous. I had full mockups of a 3
> > pages written in JSTL and pure scriplet.
> >
> > If memory serves me correctly, the difference was 5-8x. the
> > JSTL version using jasper1 would take 900-1000ms+ to display
> > 15 results. The same exact page using scriplet took about
> > 100-150ms. I would definitely be interested in spending time
> > on this and assisting. I may have some time opening up next
> > year, so I hope to start contributing actively :) cross my fingers.
> >
> > peter lin
> >
> >  Kin-Man Chung <[EMAIL PROTECTED]> wrote: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
> >
> >
> > ${i}
> >
> >
> > and generates the Java codes
> >
> > for (int i = 0; i <= 1

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

[Craig R. McClanahan]

On Sat, 23 Nov 2002, Jim Cobban wrote:

> Date: Sat, 23 Nov 2002 11:17:50 -0500
> From: Jim Cobban <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>,
>  Jim Cobban <[EMAIL PROTECTED]>
> To: Jan Luehe <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Why can I not use attributes "lang" and "maxRows" in a
> custom tag
>
> - Original Message -
> From: "Jan Luehe" <[EMAIL PROTECTED]>
> Subject: Re: Why can I not use attributes "lang" and "maxRows" in a custom
> tag
>
>
> > > Tomcat 4.1.12 does not accept a custom tag with attributes "lang"
> > > or "maxRows".  When I asked about this on the Tomcat users list I was
> > > informed that it also does not accept the attribute "class".
> > >
> > > Specifically if I define those attributes then when the jsp is compiled
> I
> > > get an "unable to find setter" error.  If I replace them with similar
> but
> > > meaningless attribute names the page compiles correctly.
> >
> > This can't be true. For example, JSTL defines an attribute
> > named 'maxRows' for its  action.
> > I am not aware of any naming restrictions for custom tag attributes.
> >
> > Are you sure the tag handler for your custom action
> > defines an approriate setter method for the attributes in
> > question?
>
> I kept experimenting and found exactly what it was that Tomcat disliked
> about my attribute.  It was not the name.  It was not the presence or
> absence of the set method.  It was that there was also a get method which
> did not return String!  Since Tomcat does not use the get method I do not
> understand why it cares whether or not one is present or what its signature
> is.  But as soon as I change the name of the get method so it did not match
> the set method Tomcat merrily accepted the tag.

Tomcat cares because JSP custom tags are required to implement the
standard JavaBean naming patterns for property-related methods, as defined
in the JavaBeans Specification.

  http://java.sun.com/products/javabeans/

>
> For me this is now an issue of documentation.  I have searched the JSP 1.2
> spec using every term I can think of and I cannot find where it specifies
> the characteristics of the set method for an attribute on a custom tag.  I
> have therefore been depending upon the description of this capability in
> Marty Hall's book.  If the JSP specification, and Tomcat, have a legitimate
> reason for looking at the characteristics of the get method when deciding
> whether or not to use the set method, then that should be documented.
> Otherwise the behavior is frankly mysterious.

In the JSP 1.2 spec, section JSP.10.1:

"A tag handler has some properties that are exposed to
the page as attributes on an action; these properties
are managed by the JSP container (via generated code).
The setter methods used to set the properties are discovered
using the JavaBeans introspector machinery."

The last sentence refers to the java.beans.Introspector class, which
refers you to the JavaBeans spec.

>
> Thank you for responding.  When a week went by without a response I
> unsubscribed from the list, so the CC on this message may be discarded.
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Jasper2] framework for tag optimization

[Hans Bergsten]

Peter Romianowski wrote:

If you think using it for JSTL is okay, why wouldn't it be 
okay for other tag libraries? The same issues (if they are 
issues) apply to JSTL, don't they?


  I thought of it beeing done by the jasper-crew, i.e. being
part of "stock tomcat", so it could be assured that it is
working correct.


Well, I hope that it the plugin API would be easy enough to use
to ensure that others than the "jasper crew" can get it right for
other tig libraries ;-)


  The way I understand the proposal is that it *could* be some kind of
a replacement for a tag-library. So for conformity and interoperability
a programmer would have to implement the plugin *AND* the taghandler.
(And I extremely doubt that many will). 

I may be wrong, but I don't think the proposal is a replacement. For
instance, the config file makes a reference to the tag handler class
(the  element).


 I was involved in a discussion about a "precompile all JSPs in a 
webapp"-functionality (which was wanted by *many* users). I was 
willing to contribute to it, but the developers (Craig himself, 
I think :) said that such a thing would not belong to a reference i
mplementation of a servlet-container. After he told me so, I agreed 
with him, although I still would like to have  this feature. :) So 
that was the reason why I posted my comments.

This was before I rejoined this list, so I can't comment on that
specific proposal (yes, I _could_ look for it in the archives, but
I wont ;-) In general, though, I don't see anything wrong with adding
non-standard features to Tomcat, as long as they are clearly optional
and the behavior defined by the spec still works. In fact, there was
a discussion about this in the Jakarta PMC when Jakarta was formed.
The consensus at the time was that Tomcat has to be spec compliant
(it _is_ the RI, after all), but that there are no restrictions on
additional features.


  As an application developer I would say: "YES! Give me that plugin-
feature!" since it would improve performance drastically. So, I like
the idea but I am not sure if such a thing would belong to "stock
tomcat".


As long as a feature doesn't break spec conformance, it should be fine.
For this specific proposal (assuming my understanding of it is correct),
I don't see any problems.

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14801] - imports fail on non-packaged classes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14801

imports fail on non-packaged classes

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-23 17:39 ---
Thanks for mentioning you are using JDK 1.4.1.  This behavior is by design in
the JDK 1.4's javac.  See:

  http://java.sun.com/j2se/1.4/compatibility.html#incompatibilities1.4

Item #8, second subitem states:

The compiler now rejects import statements that import a type from the
unnamed namespace. ...

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Jasper2] framework for tag optimization

[Peter Romianowski]

> If you think using it for JSTL is okay, why wouldn't it be 
> okay for other tag libraries? The same issues (if they are 
> issues) apply to JSTL, don't they?

  I thought of it beeing done by the jasper-crew, i.e. being
part of "stock tomcat", so it could be assured that it is
working correct.

  The way I understand the proposal is that it *could* be some kind of
a replacement for a tag-library. So for conformity and interoperability
a programmer would have to implement the plugin *AND* the taghandler.
(And I extremely doubt that many will). 

 I was involved in a discussion about a "precompile all JSPs in a 
webapp"-functionality (which was wanted by *many* users). I was 
willing to contribute to it, but the developers (Craig himself, 
I think :) said that such a thing would not belong to a reference i
mplementation of a servlet-container. After he told me so, I agreed 
with him, although I still would like to have  this feature. :) So 
that was the reason why I posted my comments.

  As an application developer I would say: "YES! Give me that plugin-
feature!" since it would improve performance drastically. So, I like
the idea but I am not sure if such a thing would belong to "stock
tomcat".


anyway,
Peter

  
 
> Hans
> 
> >>-Original Message-
> >>From: Peter Lin [mailto:[EMAIL PROTECTED]]
> >>Sent: Saturday, November 23, 2002 4:59 AM
> >>To: Tomcat Developers List; Kin-Man Chung
> >>Subject: Re: [Jasper2] framework for tag optimization
> >>
> >>
> >>
> >>hey kin-man,
> >> 
> >>that sounds great!  I was actually thinking along those lines
> >>a while back, but thought it was impracticle because the 
> >>project I was working one didn't have enough time to explore 
> >>that approach.
> >> 
> >>when I was doing performance analysis of jasper1 with jslt
> >>and saw how bad the performance was (due to the nested 
> >>try/catch bug), I went through and manually wrote scriplet 
> >>code to do the same exact logic. The performance compared to 
> >>jasper1 + jstl was tremendous. I had full mockups of a 3 
> >>pages written in JSTL and pure scriplet.
> >> 
> >>If memory serves me correctly, the difference was 5-8x. the
> >>JSTL version using jasper1 would take 900-1000ms+ to display 
> >>15 results. The same exact page using scriplet took about 
> >>100-150ms. I would definitely be interested in spending time 
> >>on this and assisting. I may have some time opening up next 
> >>year, so I hope to start contributing actively :) cross my fingers.
> >> 
> >>peter lin
> >> 
> >> Kin-Man Chung <[EMAIL PROTECTED]> wrote: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
> >>
> >>
> >>${i}
> >>
> >>
> >>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:
> >>
> >>
> >>
> >>the name of the tag class
> >>
> >>the name of the pkugin class
> >>
> >>
> >>
> >>
> >>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:
> >>For additional commands, e-mail: 
> >>
> >>
> >>
> >>-
> >>Do you Yahoo!?
> >>Yahoo! Mail Plus - Powerful. Affordable. Sign up now
> >>
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> > For 
> additional commands, 
> e-mail: 
> > 
> > 
> 
> -- 
> Hans Bergsten<[EMAIL PROTECTED]>
> Gefion Software   
> Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
> Details at
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional comm

Re: [Jasper2] framework for tag optimization

[Hans Bergsten]

Peter Romianowski wrote:

  Just a thought: Doesn't this breack the standard conformance
tomcat is all about? 

If I understand the proposal correctly, I don't see that it breaks
standard conformance (I'm in the JSP JRE group, BTW). As long as
it doesn't require extra, non-standard directives or elements in the
JSP files, it's just a proprietary way to get better performance
when using Tomcat. The same JSP files would work fine in any other
JSP container, except that they may run a bit slower.

Another way to look at it. The JSP spec allows a container to do
tricks like this for "well-known tag libraries", such as JSTL. The
proposed feature can be seen as a just way to add other "well-known
libraries", where the knowledge is encoded by the tag library
developer instead of the container developer.


One could easily be bound to tomcat after
writing some plugins that break the initial semantics of a tag.


Sure, but then you have done things with the plugin feature that it's
not supposed to be used for. It's no different than relying on
non-standard APIs a container may provide.


I think there is no way to assure the correctness of a plugin-
implementation, so it would become impossible to switch to 
another servlet-container. And I saw many improvement-discussion
on this list, which had been canceled with exact this reason.

Hmm... Testing the app with and without the plugin seems like a
reasonable approach to ensure it's correct. The plugin feature should
only be used to improve performance, not to add behavior.


  But having plugins for standard tags (JSTL) out of the box
would be great in respect of performance.


If you think using it for JSTL is okay, why wouldn't it be okay for
other tag libraries? The same issues (if they are issues) apply to JSTL,
don't they?

Hans


-Original Message-
From: Peter Lin [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, November 23, 2002 4:59 AM
To: Tomcat Developers List; Kin-Man Chung
Subject: Re: [Jasper2] framework for tag optimization



hey kin-man,

that sounds great!  I was actually thinking along those lines 
a while back, but thought it was impracticle because the 
project I was working one didn't have enough time to explore 
that approach.

when I was doing performance analysis of jasper1 with jslt 
and saw how bad the performance was (due to the nested 
try/catch bug), I went through and manually wrote scriplet 
code to do the same exact logic. The performance compared to 
jasper1 + jstl was tremendous. I had full mockups of a 3 
pages written in JSTL and pure scriplet.

If memory serves me correctly, the difference was 5-8x. the 
JSTL version using jasper1 would take 900-1000ms+ to display 
15 results. The same exact page using scriplet took about 
100-150ms. I would definitely be interested in spending time 
on this and assisting. I may have some time opening up next 
year, so I hope to start contributing actively :) cross my fingers.

peter lin

Kin-Man Chung <[EMAIL PROTECTED]> wrote: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


${i}


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:



the name of the tag class

the name of the pkugin class




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: 
For additional commands, e-mail: 



-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-m

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

[Robert_McDermid]

If Tomcat uses the "beans" API in Java to do the reflection for calling
these methods, then that is probably why.
It insists on having a valid get and set method for an attribute for some
reason.  I ran into this once when I only wanted
to have "getters" with no setters, and I couldn't find a way around it
other than to use reflection directly (mind you,
I was in a hurry, so I didn't try too hard).

-- Rob


   
  
  "Jim Cobban" 
  
  <[EMAIL PROTECTED]To:   "Jan Luehe" 
<[EMAIL PROTECTED]> 
  >cc:   
<[EMAIL PROTECTED]> 
   Subject:  Re: Why can I not use 
attributes "lang" and "maxRows" in a custom tag   
  23/11/2002 11:17 
  
  AM   
  
  Please respond to
  
  "Tomcat  
  
  Developers List" 
  
   
  
   
  




- Original Message -
From: "Jan Luehe" <[EMAIL PROTECTED]>
Subject: Re: Why can I not use attributes "lang" and "maxRows" in a custom
tag


> > Tomcat 4.1.12 does not accept a custom tag with attributes "lang"
> > or "maxRows".  When I asked about this on the Tomcat users list I was
> > informed that it also does not accept the attribute "class".
> >
> > Specifically if I define those attributes then when the jsp is compiled
I
> > get an "unable to find setter" error.  If I replace them with similar
but
> > meaningless attribute names the page compiles correctly.
>
> This can't be true. For example, JSTL defines an attribute
> named 'maxRows' for its  action.
> I am not aware of any naming restrictions for custom tag attributes.
>
> Are you sure the tag handler for your custom action
> defines an approriate setter method for the attributes in
> question?

I kept experimenting and found exactly what it was that Tomcat disliked
about my attribute.  It was not the name.  It was not the presence or
absence of the set method.  It was that there was also a get method which
did not return String!  Since Tomcat does not use the get method I do not
understand why it cares whether or not one is present or what its signature
is.  But as soon as I change the name of the get method so it did not match
the set method Tomcat merrily accepted the tag.

For me this is now an issue of documentation.  I have searched the JSP 1.2
spec using every term I can think of and I cannot find where it specifies
the characteristics of the set method for an attribute on a custom tag.  I
have therefore been depending upon the description of this capability in
Marty Hall's book.  If the JSP specification, and Tomcat, have a legitimate
reason for looking at the characteristics of the get method when deciding
whether or not to use the set method, then that should be documented.
Otherwise the behavior is frankly mysterious.

Thank you for responding.  When a week went by without a response I
unsubscribed from the list, so the CC on this message may be discarded.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 







If you received this e-mail in error please delete it and notify the sender as soon as 
possible. The contents of this e-mail may be confidential and the unauthorized use, 
copying, or dissemination of it and any attachments to it, is prohibited.

Internet communications are not secure and Hyperion does not, therefore, accept legal 
responsibility for the contents of this message nor for any damage caused by viruses. 
The views expressed here do not necessarily represent those of Hyperion.

For more information about Hyperion, please visit our Web site at www.hyperion.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Jim Cobban]

- Original Message -
From: "Jan Luehe" <[EMAIL PROTECTED]>
Subject: Re: Why can I not use attributes "lang" and "maxRows" in a custom
tag


> > Tomcat 4.1.12 does not accept a custom tag with attributes "lang"
> > or "maxRows".  When I asked about this on the Tomcat users list I was
> > informed that it also does not accept the attribute "class".
> >
> > Specifically if I define those attributes then when the jsp is compiled
I
> > get an "unable to find setter" error.  If I replace them with similar
but
> > meaningless attribute names the page compiles correctly.
>
> This can't be true. For example, JSTL defines an attribute
> named 'maxRows' for its  action.
> I am not aware of any naming restrictions for custom tag attributes.
>
> Are you sure the tag handler for your custom action
> defines an approriate setter method for the attributes in
> question?

I kept experimenting and found exactly what it was that Tomcat disliked
about my attribute.  It was not the name.  It was not the presence or
absence of the set method.  It was that there was also a get method which
did not return String!  Since Tomcat does not use the get method I do not
understand why it cares whether or not one is present or what its signature
is.  But as soon as I change the name of the get method so it did not match
the set method Tomcat merrily accepted the tag.

For me this is now an issue of documentation.  I have searched the JSP 1.2
spec using every term I can think of and I cannot find where it specifies
the characteristics of the set method for an attribute on a custom tag.  I
have therefore been depending upon the description of this capability in
Marty Hall's book.  If the JSP specification, and Tomcat, have a legitimate
reason for looking at the characteristics of the get method when deciding
whether or not to use the set method, then that should be documented.
Otherwise the behavior is frankly mysterious.

Thank you for responding.  When a week went by without a response I
unsubscribed from the list, so the CC on this message may be discarded.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14801] New: - imports fail on non-packaged classes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14801

imports fail on non-packaged classes

   Summary: imports fail on non-packaged classes
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: UNCONFIRMED
  Severity: Major
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


The import statement fails in JSP pages where the class being imported does not 
have a package.  This occurs regardless of the location of the class.  That is 
to say if the class is located at .\WEB-INF\classes\theClass.class or .\WEB-
INF\lib\jar\jarfile.jar; or within the various areas of tomcat such as 
commons.  The bug does not occur within tomcat 4.0.x.

jdk-version=1.4.1

The import statement:
<%@ page import="MD5" %>
<%@ page import="java.security.MessageDigest" %>
<%@ page import="java.net.*" %>

Note: MD5 fails.

Error Message:
org.apache.jasper.JasperException: Unable to compile class for JSP

An error occurred at line: 32 in the jsp file: /processLogin.jfcc

Generated servlet error:
[javac] Compiling 1 source file

D:\Inetpub\jspwork\myhrlogin.mot.com\processLogin_jfcc.java:7: '.' expected
import MD5;
  ^
D:\Inetpub\jspwork\myhrlogin.mot.com\processLogin_jfcc.java:193: cannot resolve 
symbol
symbol  : class MD5  
location: class org.apache.jsp.processLogin_jfcc
MD5 hash;
^

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Jasper2] framework for tag optimization

[Peter Lin]

yeah, it definitely would risk breaking conformance, unless it became an official 
spec. there is a need for a tag-like markup for designers (non-programmers), but 
performs better for sites that get million hits a day or more. Most sites wouldn't 
need it, but for heavy hitters it would save in resources.
 
peter lin
 Peter Romianowski <[EMAIL PROTECTED]> wrote:Just a thought: Doesn't this breack the 
standard conformance
tomcat is all about? One could easily be bound to tomcat after
writing some plugins that break the initial semantics of a tag.
I think there is no way to assure the correctness of a plugin-
implementation, so it would become impossible to switch to 
another servlet-container. And I saw many improvement-discussion
on this list, which had been canceled with exact this reason.

But having plugins for standard tags (JSTL) out of the box
would be great in respect of performance.

Just my $0.02

Peter

> -Original Message-
> From: Peter Lin [mailto:[EMAIL PROTECTED]] 
> Sent: Saturday, November 23, 2002 4:59 AM
> To: Tomcat Developers List; Kin-Man Chung
> Subject: Re: [Jasper2] framework for tag optimization
> 
> 
> 
> hey kin-man,
> 
> that sounds great! I was actually thinking along those lines 
> a while back, but thought it was impracticle because the 
> project I was working one didn't have enough time to explore 
> that approach.
> 
> when I was doing performance analysis of jasper1 with jslt 
> and saw how bad the performance was (due to the nested 
> try/catch bug), I went through and manually wrote scriplet 
> code to do the same exact logic. The performance compared to 
> jasper1 + jstl was tremendous. I had full mockups of a 3 
> pages written in JSTL and pure scriplet.
> 
> If memory serves me correctly, the difference was 5-8x. the 
> JSTL version using jasper1 would take 900-1000ms+ to display 
> 15 results. The same exact page using scriplet took about 
> 100-150ms. I would definitely be interested in spending time 
> on this and assisting. I may have some time opening up next 
> year, so I hope to start contributing actively :) cross my fingers.
> 
> peter lin
> 
> Kin-Man Chung wrote: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
> 
> 
> ${i}
> 
> 
> 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:
> 
> 
> 
> the name of the tag class
> 
> the name of the pkugin class
> 
> 
> 
> 
> 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: 
> For additional commands, e-mail: 
> 
> 
> 
> -
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now
> 


--
To unsubscribe, e-mail: 
For additional commands, e-mail: 



-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

DO NOT REPLY [Bug 14798] New: - Using jspDestroy for tag pool cleanup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14798

Using jspDestroy for tag pool cleanup

   Summary: Using jspDestroy for tag pool cleanup
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi Jakarta Team,

  Looks as if in Tomcat 4.1.x you are using jspDestroy() to do tag 
pool cleanup. This cleanup should probably be placed in a destroy() method.

Basically, my JSP contains the following (I can send you a WAR file with the 
test code if you email me):


<%@ taglib uri="/WEB-INF/tlds/bug-taglib.tld" prefix="test" %>


<%! public void jspDestroy() {
  System.out.println("In jspDestroy");
}
%>


   
which produces two jspDestroy's in the generated servlet.  The extra  
jspDestroy is:

  public void jspDestroy() {
_jspx_tagPool_test_doLittle.release();
  }

And of course, with two jspDestroy methods, the code does not compile.

Thanks,
Larry Brown
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Jasper2] framework for tag optimization

[Peter Romianowski]

  Just a thought: Doesn't this breack the standard conformance
tomcat is all about? One could easily be bound to tomcat after
writing some plugins that break the initial semantics of a tag.
I think there is no way to assure the correctness of a plugin-
implementation, so it would become impossible to switch to 
another servlet-container. And I saw many improvement-discussion
on this list, which had been canceled with exact this reason.

  But having plugins for standard tags (JSTL) out of the box
would be great in respect of performance.

Just my $0.02

Peter

> -Original Message-
> From: Peter Lin [mailto:[EMAIL PROTECTED]] 
> Sent: Saturday, November 23, 2002 4:59 AM
> To: Tomcat Developers List; Kin-Man Chung
> Subject: Re: [Jasper2] framework for tag optimization
> 
> 
> 
> hey kin-man,
>  
> that sounds great!  I was actually thinking along those lines 
> a while back, but thought it was impracticle because the 
> project I was working one didn't have enough time to explore 
> that approach.
>  
> when I was doing performance analysis of jasper1 with jslt 
> and saw how bad the performance was (due to the nested 
> try/catch bug), I went through and manually wrote scriplet 
> code to do the same exact logic. The performance compared to 
> jasper1 + jstl was tremendous. I had full mockups of a 3 
> pages written in JSTL and pure scriplet.
>  
> If memory serves me correctly, the difference was 5-8x. the 
> JSTL version using jasper1 would take 900-1000ms+ to display 
> 15 results. The same exact page using scriplet took about 
> 100-150ms. I would definitely be interested in spending time 
> on this and assisting. I may have some time opening up next 
> year, so I hope to start contributing actively :) cross my fingers.
>  
> peter lin
>  
>  Kin-Man Chung <[EMAIL PROTECTED]> wrote: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
> 
> 
> ${i}
> 
> 
> 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:
> 
> 
> 
> the name of the tag class
> 
> the name of the pkugin class
> 
> 
> 
> 
> 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: 
> For additional commands, e-mail: 
> 
> 
> 
> -
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14797] - Request headers are broken after invoking pageContext.include()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14797

Request headers are broken after invoking pageContext.include()





--- Additional Comments From [EMAIL PROTECTED]  2002-11-23 14:01 
---
Created an attachment (id=3930)
sample war file. Deploy and access /test/index.jsp

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14797] New: - Request headers are broken after invoking pageContext.include()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14797

Request headers are broken after invoking pageContext.include()

   Summary: Request headers are broken after invoking
pageContext.include()
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When Tomcat and Apache are connected by Coyote/JK2 AJP1.3 connector,
HTTP request headers are broken after invoking pageContext.include() method
in a JSP file. This problem does not occur when using legacy APJ1.3 connector.

For example, when request "http://localhost/test/index.jsp"; is sent,
Web browser displays like follows:
--
test test test test test test test test test test test test test test test test 
test test test test test test test test test test test test test test test test 
test test test test test test test test test test test test test test test test 
test test test test test test test test test test test test test test test test 
test test test test test test test test test test test TEST accept: te
accept-encoding: st test test 
accept-language: te
connection: st test te
cookie: st test test test test test test test test test test test test test 
test test test test 
host: test test t
user-agent: est test test test test test test test test test t
content-length: e
--

where /test/index.jsp and /test/included.jsp are like follows:
[/test/index.jsp]
--
<%@ page contentType="text/html" import="java.util.*" %>

test test test test test test test test test test test test test test test
test test test test test test test test test test test test test test test
test test test test test test test test test test test test test test test
test test test test test test test test test test test test test test test
test test test test test test test test test test test test test test test
<% pageContext.include("/included.jsp"); %>

<%
Enumeration enum = request.getHeaderNames();
while (enum.hasMoreElements()) {
String name = (String)enum.nextElement();
%><%= name %>:
<%= request.getHeader(name) %>
 <% } %>
--
[/test/included.jsp]
--
<%@ page contentType="text/html" %>

TEST
--

However, a request "http://localhost:8080/test/index.jsp";
 does not cause the problem.

Environment:
  Tomcat4.1.12
  Linux 2.2.18-0vl4.2
  Apache1.3.23 + mod_jk-1.3-eapi.so

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3 CoyoteInterceptor2.java

[billbarker]

billbarker2002/11/23 01:07:23

  Modified:coyote/src/java/org/apache/coyote/tomcat3
CoyoteInterceptor2.java
  Log:
  It's way too late for me to be programming, when I miss simple things like this.
  
  Revision  ChangesPath
  1.15  +1 -1  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/CoyoteInterceptor2.java
  
  Index: CoyoteInterceptor2.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/CoyoteInterceptor2.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- CoyoteInterceptor2.java   23 Nov 2002 09:04:16 -  1.14
  +++ CoyoteInterceptor2.java   23 Nov 2002 09:07:23 -  1.15
  @@ -244,7 +244,7 @@
// Only allowed a single cert under the 2.2 Spec.
Object [] value = (Object []) 
cReq.getAttribute(SSLSupport.CERTIFICATE_KEY);
if( value != null ) {
  - cReq.setAttribute(key, value[0]);
  + cReq.setAttribute(SSLSupport.CERTIFICATE_KEY, value[0]);
}

   return cReq.getAttribute(key);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3 CoyoteInterceptor2.java

[billbarker]

billbarker2002/11/23 01:04:17

  Modified:coyote/src/java/org/apache/coyote/tomcat3
CoyoteInterceptor2.java
  Log:
  Last one wasn't quite right.  At the momement, all SSL attributes are grabbed for a 
request for any.  Thus checking the 'key' isn't good enough.
  
  Revision  ChangesPath
  1.14  +5 -7  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/CoyoteInterceptor2.java
  
  Index: CoyoteInterceptor2.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/CoyoteInterceptor2.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- CoyoteInterceptor2.java   23 Nov 2002 08:38:23 -  1.13
  +++ CoyoteInterceptor2.java   23 Nov 2002 09:04:16 -  1.14
  @@ -241,14 +241,12 @@
   if(isSSLAttribute(key)) {
   cReq.action(ActionCode.ACTION_REQ_SSL_ATTRIBUTE,
   httpReq.getCoyoteRequest() );
  - if( SSLSupport.CERTIFICATE_KEY.equals(key) ) {
  - // Only allowed a single cert under the 2.2 Spec.
  - Object [] value = (Object []) cReq.getAttribute(key);
  - if( value != null ) {
  - cReq.setAttribute(key, value[0]);
  - }
  + // Only allowed a single cert under the 2.2 Spec.
  + Object [] value = (Object []) 
cReq.getAttribute(SSLSupport.CERTIFICATE_KEY);
  + if( value != null ) {
  + cReq.setAttribute(key, value[0]);
}
  -
  + 
   return cReq.getAttribute(key);
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3 CoyoteInterceptor2.java

[billbarker]

billbarker2002/11/23 00:38:23

  Modified:coyote/src/java/org/apache/coyote/tomcat3
CoyoteInterceptor2.java
  Log:
  Return to Servlet-Spec 2.2 compliance.
  
  Revert to the brain-dead 2.2 spec.  We are only allowed to send the top level cert 
in 2.2 land, so don't send the full array.
  
  Revision  ChangesPath
  1.13  +8 -0  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/CoyoteInterceptor2.java
  
  Index: CoyoteInterceptor2.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/CoyoteInterceptor2.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- CoyoteInterceptor2.java   20 Jun 2002 18:53:44 -  1.12
  +++ CoyoteInterceptor2.java   23 Nov 2002 08:38:23 -  1.13
  @@ -241,6 +241,14 @@
   if(isSSLAttribute(key)) {
   cReq.action(ActionCode.ACTION_REQ_SSL_ATTRIBUTE,
   httpReq.getCoyoteRequest() );
  + if( SSLSupport.CERTIFICATE_KEY.equals(key) ) {
  + // Only allowed a single cert under the 2.2 Spec.
  + Object [] value = (Object []) cReq.getAttribute(key);
  + if( value != null ) {
  + cReq.setAttribute(key, value[0]);
  + }
  + }
  +
   return cReq.getAttribute(key);
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java

[Bill Barker]

- Original Message -
From: "Bill Barker" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, November 22, 2002 11:34 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java


>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, November 22, 2002 10:34 PM
> Subject: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server
> JkCoyoteHandler.java
>
>
> > hgomez  2002/11/22 22:34:48
> >
> >   Modified:jk/java/org/apache/jk/common HandlerRequest.java
> >jk/java/org/apache/jk/server JkCoyoteHandler.java
> >   Log:
> >   Fix null getRemoteHost.
> >   Lasy extraction of ssl certs to speed up jk/ajp13 when under SSL
> >
> >   Revision  ChangesPath
> >   1.18  +6 -24
> jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
> >
> >   Index: HandlerRequest.java
> >   >   + // SSL certificate extraction is costy, moved to JkCoyoteHandler
> >   +req.setAttribute(SSLSupport.CERTIFICATE_KEY,
> certString);
> >break;
>
> As much as I very much like the switch to constants, this is still wrong.
> As far back as the Servlet 2.2 spec (aka Tomat 3.3) this is required to be
a
> java.security.cert.X509Certificate [].  I'll have to -1 this section of
the
> patch because of this, but the rest looks really good!
>

Urm, it's actually worse than that.  The 2.2 spec requires a single
java.security.cert.X509Certificate, the 2.3 & 2.4 specs (more intelligently)
require the entire chain via java.security.cert.X509Certificate [].  Don't
you just love the JCP? ;-)

>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: