hi
the information is wrong! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] EL Transition to Jakarta Commons
+1 -- Pierre Jan Luehe wrote: I'd like to resume discussion on a proposal circulated by James Strachan on March 13, 2002, about turning the implementation of JSTL's expression language (EL) into a reusable component and moving it from the Standard Taglib, an implementation of JSTL hosted by jakarta-taglibs, to jakarta-commons, in order to make it available to a larger number of projects. James' original proposal received some positive feedback from the taglibs-dev community. Below is a draft proposal for a formal submission to jakarta-commons, following the format of the jakarta-commons charter at http://jakarta.apache.org/commons/charter.html. (0) Rationale The JSP Standard Tag Library (JSTL), version 1.0, introduced the concept of an Expression Language (EL), whose main goal is to provide page authors with an easy way to access and manipulate application data without requiring the use of scriptlets JSP 2.0 adopted the EL specification from JSTL, and expanded its scope: EL expressions are no longer limited to JSTL action attributes, but may be used in any standard or custom action attribute declared to accept a runtime expression. In addition, EL expressions may now also be used directly in template text outside of any actions. JSP 2.0 also added an important feature to the EL specification: EL functions, which allow page authors to invoke static methods in Java classes from EL expressions. Additionally, JSP 2.0 allows programmatic access and customization of the EL evaluator through a set of standard interfaces and abstract classes. Currently, there are a number of projects (including Tomcat 5 and Java Server Faces) that leverage the EL implementation of the Standard Taglib. In addition, there seems to be interest in leveraging the EL in the context of scripting workflow activities using custom tag libraries. In order to make the EL implementation available to Tomcat 5, the Tomcat team defined a new ant target for the Standard Taglib that builds just the EL portion and packages it in a JAR file (jsp20el.jar) which is stored in Tomcat's common/lib directory. This approach has always been considered an interim solution only, until the EL implementation would move from the Standard Taglib to a more visible location such as jakarta-commons. (1) Scope of the package The package shall provide an implementation of the Expression Language specification which is part of the JSP 2.0 standard. (1.5) Interaction with other packages The package shall provide an implementation of the standard interfaces and abstract classes of the javax.servlet.jsp.el package, which is defined in the JSP 2.0 specification. (2) Identify the initial source for the package The initial codebase will be taken from the Standard Taglib project hosted at jakarta-taglibs. The source of the Standard Taglib is available as part of the jakarta-taglibs nightly source distribution at http://jakarta.apache.org/builds/jakarta-taglibs/nightly/src/ (2.1) Identify the base name for the package The base name of the package shall be org.apache.commons.el (2.2) Identify the coding conventions for this package The package follows Sun's Java coding conventions (see http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html). (3) Identify any Jakarta-Commons resources to be created (3.1) Mailing list The package shall use the jakarta-commons mailing list. (3.2) CVS repositories The package shall use a root branch of the jakarta-commons CVS. (3.3) Bugzilla The package shall be listed as the EL component under the Commons project in Bugzilla. (3.4) Jyve FAQ (when available) n/a (4) Identify the initial set of committers to be listed in the Status File. The initial set of committers will be identical to the set of committers of the Standard Taglib project. Thoughts? 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: re-use of tag objects via Tag.release method
Casey Lucas wrote: Looking at the rendered jsp - java files in the work directory (and noticing the calls to Tag.release), I realized that Jasper is not reusing tags that it creates. So, my question is: Has there been any conversations about implementing tag reuse in Jasper? To my knowledge, there has been no conversation on the topic. But, it'd be great to start one :-). Besides the obvious performance gains, having agressive tag reuse in tomcat would also be great for taglibs testing purposes. Properly handling 'release()' in a tag can be tricky and bugs will only show up when a tag is run in a container that supports 'tag reuse'. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: re-use of tag objects via Tag.release method
Casey Lucas wrote: Ok, I'll bite. Where's the best place to start looking? Code that does the rendering? Wasn't there at one point talk of making the renderer more "pluggable"? Great! Since you asked, here are some ideas: As a first step, I'd make sure to clearly understand all the spec says about tag reuse. Then, I'd get acquainted with the tomcat generated servlet code of various JSP pages that use tags. That will tell how access to tags is currently architected in jasper. (I think it will be easier than looking at the tags generator code itself, but if you're insterested in seeing that code, check the Tag* files in org.apache.jasper.compiler.) Finally, with all that knowledge, I'd come come up with ideas, rough designs, etc... on how reuse could be implemented in Jasper. I don't think any deep knowledge of Jasper code is required to get up to here. Use the list for help/feedback. Before long, you'll be the expert! -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Is it legal to have multiple taglib setter methods for the same property
Alex,
Until the expert group rules on this, one workaround (that will always work)
is to simply do the following (assuming a property of type Object):
instead of:
mytags:foo bar="abc"/
use:
mytags:foo bar='%="abc"%'/
Another way is to define a PropertyEditor associated with your
property of type Object.
As Craig mentioned, this problem has been the subject of numerous
discussions. Here are some pointers that may help you and others
understand the issue.
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg00732.html
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg01323.html
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg01328.html
-- Pierre
"Craig R. McClanahan" wrote:
Alex Tang wrote:
Thanks for the quick reply Craig.
A followup question. In tomcat 3.1, I was able to do
public setIndex ( Object o )
If this is legal, I can do my own internal checking to see if the object "o" is a
String or an
int. However in Tomcat 4.0, I get an error when I try to do this. I saw some
talk about this
on the tomcat archives, however it wasn't clear whether this is an error on my
side or an error
in tomcat.
This has been the subject of no small discussion on the expert group for JSP 1.2. A
final decision
is still pending AFAIK, at which time Tomcat 4.0 will change if it needs to.
Thanks again.
...alex...
Craig
"Craig R. McClanahan" wrote:
IIRC, having two setters with different argument types violates the JavaBeans
specification. In addition, it seems to cause the Java reflection APIs to think
that there
is no setter method at all, so you will get complaints about a read-only
property from any
JSP implementation that uses this technique.
Craig McClanahan
Alex Tang wrote:
Hi folks. (My apologies for crossposting, I wasn't sure if this is a
taglib question or a tomcat question/problem)
I'm writing a taglib using the JSP 1.1 spec (currently Tomcat 3.x). I'm
having a problem with a property "set" method.
I have a taglib tag which takes one parameter: "index". This index can
be either the string "all" or a number representing which CLE object to
show.
I have the following defined in my tld file:
tag
namedisplayCLE/name
tagclasscom.funkware.DisplayCLETag/tagclass
teiclasscom.funkware.DisplayCLEExtraInfo/teiclass
infoDisplay a CLE/info
attribute
nameindex/name
requiredtrue/required
rtexprvaluetrue/rtexprvalue
/attribute
/tag
In my "DisplayCLETag.java" file, I have the following:
/**
* !-- setIndex--
*
*Called when the taglib encounters an int for the index field...
*This form takes an int which happens when a jsp expression is
*evaluated on the right side of the "index=".
*
* @param nIndex
*The index
*/
public void setIndex ( int nIndex ) {
m_nIndex = nIndex;
}
/**
* !-- setIndex--
*
*Called when the taglib encounters the "index" parameter. This
*form takes an object. We try to convert and Integer and a
*String. Anything else we barf on.
*
* @param o
*An object which we'll try to convert.
*/
public void setIndex ( String s ) {
if ( SHOWELEMENT_ALL_STRING.equalsIgnoreCase ( s ) ) {
m_nIndex = SHOWELEMENT_ALL;
return;
}
try {
m_nIndex = Integer.parseInt ( s );
} catch ( NumberFormatException e ) {
Dispatcher.log ( Log.NOTICE, "DisplayListElementTag.setElement",
"The element: '" + s +
"' is invalid, it should be a number" );
m_nIndex = SHOWELEMENT_UNDEF;
}
}
The reason I have two setter methods for Index is that doing:
af:displayCLE index="1"/
is different than
af:displayCLE index="%= i %"/ !-- where i is an int and == 1 --
Is this a legal way of doing this?
I ask because when I run tomcat using the SunJDK1.3, it works fine,
however when I run tomcat with the SunJDK1.3 with Hotspot, it fails with
java.lang.NumberFormatException: all
at java.lang.Integer.parseInt(Integer.java:405)
at java.lang.Integer.(Integer.java:540)
at org.apache.jasper.runtime.JspRuntimeLibrary.convert \
(JspRuntimeLibrary.java:125)
at org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper \
(JspRuntimeLibrary.java:201)
at
Re: [VOTE] New Committer: Kief Morris
+1 -- Pierre -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 12:16 PM To: [EMAIL PROTECTED] Subject: [VOTE] New Committer: Kief Morris Kief has recently proposed improvements to the session management code in Tomcat 4, and wants to continue helping out. I hereby propose him as a committer on the Tomcat project. Votes, please? Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Tomcat 3.3 Release Plan Ballot: [ ] +1I am in favor of this plan and will help [X] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: VOTE: New Commiter Shai Fultheim (was:RE: Tomcat session replicator)
+1 for Shai Fultheim -- Pierre
Re: back port to 3.2 -- JspInterceptor
Hi Costin, JspInterceptor is not "enabled" in 3.2 - it was one of the changes I wanted to spend more time into and make sure it's stable enough. It'll be used in 3.3 - or whatever will be called. Thanks for the clarification. However since it is being compiled in the build, it is "somewhat" enabled :-). I'll just comment out the part that does not compile (with proper references). BTW, did you fixed the command line compiler ? JspInterceptor is based on the command line compiler, so if you fix the first it'll be very easy for me to fix the 3.3 interceptor. Sorry, my radar must have missed this one. If you can give me pointers/info, I'll look into it. -- Pierre
Re: back port to 3.2 -- JspInterceptor
[EMAIL PROTECTED] wrote: BTW, did you fixed the command line compiler ? JspInterceptor is based on the command line compiler, so if you fix the first it'll be very easy for me to fix the 3.3 interceptor. Sorry, my radar must have missed this one. If you can give me pointers/info, I'll look into it. JspC ? It's a great tool - and BTW, in 3.2 it can drastically increase the performance of jsp pages ( if you precompile _and_ use the option to automatically declare the jsps in web.xml )- it's almost as fast as 3.3 with JspInterceptor ( which does the same thing at run time). ( it's not about the first compilation, but JspC and JspInterceptor are removing the *.jsp - JspServlet - actual page servlet overhead ) Costin, Sorry, I was confused. I thought you meant that the command line compiler was broken and needed a fix. A fix was made to JspC to accomodate the proper handling of "javaEncoding". Is that what you were asking? -- Pierre
Bug #55: Default for included files is 8859_1, with no option to set otherwise
Trying to close a few Jasper bugs before the holiday break.
I'd appreciate at least another pair of eyes to review what I believe
should be done on that one... -- Pierre
-
Bug #55
-
Synopsis:
Default for included files is 8859_1, with no option to set otherwise.
Report Description:
The default for reading an included file is ISO_8859_1. We can,
of course, set pageConent to read UTF-8 (which is what we need it
to be to support international
code). Unfortunately, when there are two or more levels of
encoding (or the pageContent type ins't set), the encoding that
the JspReader gets set to a hard-coded
"ISO_8859_1", and doesn't allow this to be set to anything else
via the runtime system properties. In:
org.apache.jasper.compiler.JspReader JspReader.java line
158, encoding ALWAYS defaults to 8859_1, and the file.encoding,
when set from the System properties. This is an easy fix, to set
encoding to: encoding =
System.getPropert("file.encoding","8859_1") ; The result,
typically, is that the file will flake out and convert all of the
non-UTF-8 characters to US-ASCII, @%, etc.
-
I'm not sure I fully understand what's described there,
so here is what I believe should be done.
The "encoding" for a JSP file is currently handled as follows:
1. In Compiler.java, we create a JspReader for the top-level
("including") jsp file using the 8859_1 encoding.
2. Using that JspReader, we check if there is a page directive
with 'contentType' specified. If there is, then
a new JspReader for the page is created with the encoding set to the
"charset" specified in the contentType value of the page
directive; otherwise we stick with the default 8859_1 encoding.
3. When a page is included, JspReader.pushFile() is called,
and the encoding passed as argument appears to always
be null (since no encoding attribute can be specified in
the "include" directive, reading 'encoding' off of the
attributes appears to be a bug in JspParseEventListener).
Because it is null, it always defaults to 8859_1.
If I understand well the intent of the bug report, we'd need the
following modifications:
- In step 2, if contentType is not specified in the "including" page,
set the encoding to be:
encoding = System.getProperty("file.encoding", "8859_1");
This means that the default encoding of all JSP files at a site could
be defined globally using system property "file.encoding".
I don't think this is spec-compliant, and would be reluctant
to make that change.
- In step 3, use the encoding of the "including" page.
This would fix what I believe is a bug in the current implementation.
Comments?
-- Pierre
Re: Bug #55: Default for included files is 8859_1, with no option to set otherwise
Hans, What about the javac encoding? I believe it's currently hardcoded as "UTF8" (in Compiler at least). I'm not sure what it should be in case different included pages specify different charsets ... If you refer to bug report #269, I have a fix coming in the next few minutes. [testing it right now]. It will do as you suggested in the bug report. If not, please enlighten me. -- Pierre
Re: Bug #55: Default for included files is 8859_1, with no option to set otherwise
Hans Bergsten wrote: ... So, the only possible remaining thing I can think of is to make sure the encoding specified by jspEncoding is also used as the "-encoding" argument to the javac command. It is. -- Pierre
back port to 3.2 -- JspInterceptor
Tried to back port the last fix I made to Jasper in tomcat 4.0 to tomcat 3.2 (the fix related to bug report #269 -- java encoding). Was almost there until I realized there is a new class "JspInterceptor" in tomcat 3.2 that is impacted by that fix. Unfortunately, I'm not too knowledgeable about this new class and am afraid I might miss something. So, if some kind sould wants to do the port, all the details are in my last commit. Otherwise, I'd need someone to explain to me the relationship between the Compiler and JspInterceptor classes. [Sorry, too tired and getting lazy...] -- Pierre
Re: Bug #55: Default for included files is 8859_1, with no optionto set otherwise
Maybe I'm not reading carefully enough (and I haven't had time to trace the code) but I don't understand what you mean in your "modifications". The correct behavior seems to me that when a file is included, a 'fake' JspReader should be created to scan the file for a @page directive with a contentType, then create the 'real' JspReader using either the @page directive if it was found, or the encoding of the including file as a default. You may be already saying what I just said, and I hope you are :-) Yes, I am saying what you just said. -- Pierre
Committers
+1 for Vasile Gaburici +1 for Petr Jiricka +1 for Marc Saegesser -- Pierre
Re: Jasper Compiler -- when things go really wrong
This seems right. I'll put the fix in tomorrow unless someone objects.
[no need to send a patch].
-- Pierre
"Bucknam, Brian" wrote:
It's a long story, but I'm working on a project where Jasper 3.x is embedded
inside a servlet, which can then be deployed to the container of our
customer's choice. The servlet uses JSP files as templates, which is where
Jasper comes in.
In this type of environment, sometimes thing can go really wrong, and the
compiled JSP might, in some cases, fail to get a JspFactory, PageContext, or
JspWriter.
Here is a much-snipped version of what JspParseEventListener (in 3.2 and
4.0) generates for the _jspService() method:
JspFactory _jspxFactory = null;
PageContext pageContext = null;
HttpSession session = null;
JspWriter out = null;
try {
_jspxFactory = JspFactory.getDefaultFactory();
pageContext = _jspxFactory.getPageContext(this, request, response,
"", true, 4096, true);
out = pageContext.getOut();
// HTML stuff here
out.write("...my happy JSP page...");
// end
} catch (Exception ex) {
if (out.getBufferSize() != 0)
out.clearBuffer();
pageContext.handlePageException(ex);
} finally {
out.flush();
_jspxFactory.releasePageContext(pageContext);
}
If any of _jspxFactory, pageContext, or out fail to be created, the catch{}
and finally{} clauses just throw NPE's.
I would propose that the catch{} and finally{} should generated as following
instead:
} catch (Exception ex) {
if (out != null out.getBufferSize() != 0)
out.clearBuffer();
if (pageContext != null) pageContext.handlePageException(ex);
} finally {
if (out != null) out.flush();
if (_jspxFactory != null)
_jspxFactory.releasePageContext(pageContext);
}
These seem to me like non-functionality-impacting changes.
If this seems right, I will generate patch files if requested.
Thanks,
Brian
Brian Bucknam
WebGain, Inc.
[EMAIL PROTECTED]
Re: jsp - html speedup
cga wrote: Hi there, I was thinking "There is a way to speed up jps". I mean if I take out white spaces and other unnecesary text out of the html part of a jsp, the server will send less bytes to the browser so it will be faster. I am pretending to do a Reader that takes out that unnecesary chars. I know Java, but few jakarta. So, the first time, when the server reads the jsp to make the code, it also takes out those unnecesary spaces (and comments). Is there something like this already done? Not that I know of. If I do it, will someone help me to integrate? I'm sure that someone in the community will be more than happy to help. If you have a proposal with more specifics, you should also get valuable feedback from other people. By the way, it should be configurable. I mean, someone should use it only if he wants to. And if there is a bug the makes that a particular page not to be shown properly, to disable it for that page. Makes sense. Thanks in advance, Carlos Gaston Alvarez Well, thanks to you for your interest in contributing to the source code! -- Pierre
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java
Hans Bergsten wrote: [EMAIL PROTECTED] wrote: pierred 00/12/09 21:56:44 Modified:jasper/src/share/org/apache/jasper Constants.java jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java Log: Take 2 on the default list of imports for JSP generated classes. Removed java.io.IOException, java.beans.Beans, and org.apache.jasper.Exception. All that's left is org.apache.jasper.runtime.*. That will be in take 3 (eventually :-)) [Thanks to Craig for "waking me up" on this...] Sorry, but I don't see what difference this change make. You're not removing dependencies, just removing imports and replacing them with FQCNs in the code. Why? Agree. Does not make a difference besides having a shorter import list. [Craig had made a comment about "java.Beans.*", but in fact I was only importing java.beans.Beans.] Might be better to leave those in the import list to make the dependency clear. What do you think? -- Pierre Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java
Hans Bergsten wrote: Pierre Delisle wrote: Hans Bergsten wrote: [EMAIL PROTECTED] wrote: pierred 00/12/09 21:56:44 Modified:jasper/src/share/org/apache/jasper Constants.java jasper/src/share/org/apache/jasper/compiler BeanGenerator.java JspParseEventListener.java ParserXJspSaxHandler.java Log: Take 2 on the default list of imports for JSP generated classes. Removed java.io.IOException, java.beans.Beans, and org.apache.jasper.Exception. All that's left is org.apache.jasper.runtime.*. That will be in take 3 (eventually :-)) [Thanks to Craig for "waking me up" on this...] Sorry, but I don't see what difference this change make. You're not removing dependencies, just removing imports and replacing them with FQCNs in the code. Why? Agree. Does not make a difference besides having a shorter import list. [Craig had made a comment about "java.Beans.*", but in fact I was only importing java.beans.Beans.] Might be better to leave those in the import list to make the dependency clear. What do you think? In general, I prefer imports for the reason you mention; it makes it easier to see all dependencies. In generated JSP compilation classes, the important thing is not to have other complete package imports than the ones in the spec, but FQCN imports can't hurt anything. So, yeah, I think it's better to keep imports like java.beans.Beans and org.apache.jasper.Exception. Actually, it could make a difference. Assuming tomcat puts the import 'java.beans.Beans' in all generated JSP servlet classes, then a developer using Tomcat can use 'Beans' in a scriptlet without having to worry about the import. However, when porting the JSP page to another engine, the compile could fail if the target JSP container uses a FQCN in the generated code rather than an import statement as tomcat does. Given this, it then makes sense to limit the import list to the 'default' one mentioned in the spec. Container specific FQCN imports are also OK, but anything else should not be part of the import list. Does that make sense? -- Pierre
Re: Proposal: new commiter
Please vote for Dan Milstein as a new commiter for tomcat. Great! +1 -- Pierre
Re: [PATCH REPOST] Tomcat 4.0 JSP Examples view Source
Hans, I just tried the examples on tomcat 4.0, and the only problem I could see is with the source code of the "number guess" example. The link in num/numguess.html should be changed from "/examples/jsp/source.jsp?/jsp/num/numguess.jsp" to "numguess.txt" Otherwise, everything seems ok when I try the examples (both execute and source). -- Pierre Hans Schmid wrote: Hi there, I sent a patch to display the source code in the JSP examples and did not get any feedback either. Probably because US folk was in turkey mode :) and busy working on Tomcat 3.2 thereafter. Good work!! What it does: JSP Examples in Tomcat 4.0 have a 'View Source' button. All but the numberguess example do execute the JSP instead of displaying the source. My patches do use source.jsp to display the sources instead of referencing the *.txt files. The attatched zip file contains my current webapp\examples\jsp directory tree without the noe unnecessary *.txt files. Most of the example code should be reusable in Tomcat 3.X Please let me know, if this is usefull or not I resend the patch as attatchment. Best regards, Hans I had no luck putting this Bug into Bugrat: Error: 500 Location: /BugRatReport/PostReport Internal Servlet Error: java.lang.NoClassDefFoundError: javax/activation/DataSource at org.gjt.bugrat.servlet.BugRatReport.processReportPOST(Compiled Code) at org.gjt.bugrat.servlet.BugRatReport.doPost(Compiled Code) at javax.servlet.http.HttpServlet.service(Compiled Code) at javax.servlet.http.HttpServlet.service(Compiled Code) at org.apache.tomcat.core.ServletWrapper.doService(Compiled Code) at org.apache.tomcat.core.Handler.service(Compiled Code) at org.apache.tomcat.core.ServletWrapper.service(Compiled Code) at org.apache.tomcat.core.ContextManager.internalService(Compiled Code) at org.apache.tomcat.core.ContextManager.service(Compiled Code) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection (Compiled Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) Here the entry: JSP Examples in Tomcat 4.0 have a 'Source' button. All but the numberguess example do execute the JSP instead of displaying the source. My patch uses source.jsp to display the sources instead of referencing the *.txt files. I will repost a patch in the tomcat-dev list, which corrects this behavior for Tomcat 4.0 But the Tomcat 3.2 examples look pretty much the same. I am using Tomcat 4.0 and 3.2 in standalone mode http://localhost:8080 then press JSP Examples. Click 'Sorce' on the Numberguess line, then 'Source Code for...' you get the source code displayed. For all other examples, the JSP page gets executed. Name: patchfile.txt patchfile.txtType: Plain Text (text/plain) Encoding: quoted-printable Name: jsp.zip jsp.zipType: Zip Compressed Data (application/x-zip-compressed) Encoding: base64
Re: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
The JSP spec is quite clear on the subject:
"The only types of properties that can be assigned to from String
constants and request parameter values are those listed in TABLE 2-4; the conversion
applied
is that shown in the table. Request-time expressions can be assigned to properties of
any
type; no automatic conversions will be performed."
boolean or Boolean As indicated in java.lang.Boolean.valueOf(String)
byte or Byte As indicated in java.lang.Byte.valueOf(String)
char or Character As indicated in java.lang.Character.valueOf(String)1
double or Double As indicated in java.lang.Double.valueOf(String)
int or Integer As indicated in java.lang.Integer.valueOf(String)
float or Float As indicated in java.lang.Float.valueOf(String)
long or Long As indicated in java.lang.Long.valueOf(String)
[Please note that short/Short is missing from the list].
We had a discussion on the topic sometimes this summer (if you look at
the archives). Also seems to me that this would make sense.
Let me try to ping the spec lead on this to see if we could get
final resolution.
-- Pierre
Serge Knystautas wrote:
- Original Message -
From: "Craig R. McClanahan" [EMAIL PROTECTED]
Well, it appears that we successfully licked a large number of the
problems with
3.2-beta-8, without introducing any serious new regressions. Therefore,
I'd
like to ask that we vote on the following three propositions:
(1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000
I'd like to request that a minor patch be applied to Tomcat 3.2 so that it
can fully support tags with object properties. The patch to
org.apache.jasper.compiler.TagBeginGenerator on 7/12/2000 on the tomcat_32
branch disabled this capability (yes, I should have caught this sooner but
didn't start using the 3.2 branch until about a month ago). This was done
in preparation for the JSP 1.2 spec, and while I think this is a good
direction, nobody got the chance to finish it.
To summarize the behavior, if you have a tag with an object property and in
your TLD rtexprvalue is set to true, you cannot pass it a static string. In
Tomcat 3.1 and Tomcat 3.2 prior to 7/12/2000, the setter method for the
Object property would be called passing the static String value. In JSP 1.2
(so I would assume Tomcat 4.0 and Tomcat 3.X once JSP 1.2 support is added),
the specification is more complete and specifies the use of
BeanInfo/PropertyEditor and the setAsText method, and once this is
implemented, we can have tags with object properties. However as of right
now, Tomcat 3.2 does not support passing static Strings to Object properties
on tags.
In the interest of not delaying Tomcat 3.2's release, I would suggest the
diff included below be applied and included into Tomcat 3.2. It passes the
static String to the Object property using the setter method. While this
means tag writers could develop tags that would not comply with the JSP 1.2
spec, I believe this is acceptable as 1) there is clear direction as to how
to make their tags JSP 1.2 compliant and 2) Tomcat 3.2 is not a JSP 1.2
environment. The disadvantage to not doing this is that tags writers have
no way to support receiving static Strings to their tags' Object properties.
Instead page writers would have to use the workaround Craig (I believe)
suggested in every JSP (attr='%="value"%').
Thanks for hearing me out. I know I can just apply my own patch and build
my own instance of Tomcat 3.2, but this seems like an important part of the
spec to consider, especially as custom tags are gradually becoming a more
important component of JSPs.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
cvs diff TagBeginGenerator.java (in directory
C:\DEV\cvs-apache\jakarta-tomcat\src\share\org\apache\jasper\compiler\)
Index: TagBeginGenerator.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagBegin
Generator.java,v
retrieving revision 1.14.2.2
diff -r1.14.2.2 TagBeginGenerator.java
223a224,225
} else if (c == Object.class) {
return writer.quoteString(s);
*CVS exited normally with code 1*
Re: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
(1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000 +1 (2) Ongoing Support Plan for Tomcat 3.2 +1 (3) Release Manager for Tomcat 3.2.x Maintenance Releases +1 -- Pierre
Re: [PATCH] JspParseEventListener.java - Catch Throwable and throw new Exception
Rob Saccoccio wrote:
Would it be possible to change the generated _jspService() method to catch
Throwable instead of Exception? JSP 1.2 is taking this direction (excerpt
and patch below).
Just committed the fix in tomcat-4.0 (since this is JSP1.2).
+ writer.println("java.lang.reflect.InvocationTargetException ex = new
java.lang.reflect.InvocationTargetException(t);");
writer.println("pageContext.handlePageException(ex);");
FYI, did not do this, since the Throwable is passed directly to
handleException(Throwable):
writer.println("pageContext.handlePageException(t);");
Thanks for the patch!
-- Pierre
Re: Patch for JikesJavaCompiler.java
Christian, Thanks for the patch. I've just aplied it to tomcat-4.0. As for tomcat-3.2, I will be porting patches there *only* if this is approved by Craig (since we are so close to an official release of 3.2). -- Pierre "Schmitt, Christian" wrote: Hi all, we've been working with TC 4.0 (M2) for some time now. We treid to get Jikes to compile our JSP pages but it would not work (TC 4.0, JDK1.3, Debian Linux 2.2). So I looked at the JikesJavaCompiler.java file and found what I believe is a bug where the double quotes surround classpath et. al. Attached is a diff that uses the double quotes only in case of TC running under Windows. Hope this helps, Christian Name: JikesJavaCompiler.java.diff JikesJavaCompiler.java.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable
Re: Proper jsp:setProperty behavior for Tomcat 3.2
Larry Isaacs wrote:
When applying Gareth Morgan's bug fix for JspRuntimeLibrary in the Tomcat MAIN
branch, a difference between the tomcat_32 and MAIN versions revealed that
Tomcat 3.2 still has the bug discovered by Glenn Nielsen. This is where:
jsp:setProperty name="bean" property="prop" value=""/
leaves the property unchanged instead of setting it to an empty string. As Glenn
noted, the spec calls for ignoring an empty string when param is used, i.e.:
jsp:setProperty name="bean" property="prop" param="prop"/
with a query string of "?prop=". But doesn't say to ignore it for value. This
is easily fixed.
1) Please beware that the current fix to 3.3 did not quite do it properly
(I ran more tests this weekend).
It did fix the fact that an empty value is jsp:setProperty does go through
properly (i.e. the property is set using the empty string), but it introduced
the bug that an empty value for a request parameter also does go through
(while it should not).
However, its not clear to me what the spec calls for with respect to empty
strings and indexed properties. Also, Tomcat 3.2's current behavior seems
inconsistent on this issue. I tested the following cases where the
property is a String array:
1) jsp:setProperty name="bean" property="prop" param="prop"/
2) jsp:setProperty name="bean" property="prop"/
3) jsp:setProperty name="bean" property="*"/
For an empty query string, or a query string with mutlitple non-empty values,
you get the expected result. However, for the following query strings
which involve empty values, I get the following results for how the String
array is set.
Query String Result1 Result2 Result3 Spec
?prop="" "" not changed not changed
?prop=prop= "","" "","" not changed ???
?prop=prop=text "","text" "","text" not changed ???
I would expect the results to be the same instead of different. The spec
doesn't say that ignoring an empty value shouldn't apply to an indexed
property. But if that's true, what about "?prop=prop="? Should this be
ignored too? And should "?prop=prop=text" set the property to a single
element array containing "text"?
Am I missing something in the spec? Can someone shed some light on what
proper behavior should be?
I discussed the issue with Eduardo (JSP spec lead)
on Friday afternoon.
He agreed that the spec is unclear and has filed a bug
against the spec to trigger further discussions with the
expert group.
In the meantime, here is what we can do:
-
2) Bug fix: When using property="*", indexed properties are
not properly handled when
first property is null or empty
Your test cases exposed this bug. Only the first parameter of an
indexed property is considered when figuring out if it is
null or empty.
This is a simple fix. This will bring your test cases
to all have a consistent behavior (i.e. do not ignore the
request parameters for an indexed property as soon as first
parameter value is empty).
-
3) Pick one behavior for 'indexed properties' in the case of
empty values and document it properly.
I see 3 types of behavior that could make sense:
3A) All request parameter values are passed 'intact' as an array
to the indexed property setter method.
This means that the following query strings would yield the following
arrays being passed to the setter method:
query string: ?prop=prop=oneprop=prop=threeprop=prop=
array: {"","one","","three","",""}
query string: ?prop=prop=prop=prop=prop=prop=
array: {"","","","","",""}
3B) Same behavior as 3A), with the exception that the setter
method with the array argument is called only if at least
one parameter value is non-empty.
query string: ?prop=prop=oneprop=prop=threeprop=prop=
array: {"","one","","three","",""}
query string: ?prop=prop=prop=prop=prop=prop=
- setter method not called; indexed property unchanged
3C) Only set the properties that have a non-empty value
query string: ?prop=prop=oneprop=prop=threeprop=prop=
setIndexed(1, "one")
setIndexed(3, "three")
query string: ?prop=prop=prop=prop=prop=prop=
- no setter called
-
3A is identical in behavior as what happens when an indexed property
is set with the "value" attribute in jsp:setProperty
jsp:setProperty property="indexed" value=%=new String[]{"","",""}%/
3C has the same behavior as for non-indexed properties; only non-empty
values in request parameters trigger a call to the setter method
for the specific index.
3B is half-way solution: it has the same behavior as for non-indexed
properties only if all values of the indexed property are empty.
I'm +1 on fixing the jsp:setProperty name="bean" property="prop" value=""/
bug in Tomcat 3.2. If the desired behavior for indexed properties can be
determined, I
PageContext.removeAttribute
Bug report #412 has just been filed.
Synopsis:
public void removeAttribute(String name) does not work properly
Description:
lt. spec from sun this method is required to remove
the attribute from every scope. in class PageContextImpl
however this only removes attributes from the page context:
public void removeAttribute(String name) {
attributes.remove(name);
}
This is indeed a bug, and I can go ahead and fix it
(at least in 3.3/4.0).
However, before I do so, would someone know why we
have the following comments/code in PageContextImpl?
In the class comments:
* The removeAttribute method does not work for request scope. Needs fixing.
public void removeAttribute(String name, int scope) {
switch (scope) {
...
case REQUEST_SCOPE:
throw new IllegalArgumentException("cant remove Attributes from request
scope");
...
-- Pierre
Re: Proper jsp:setProperty behavior for Tomcat 3.2
Larry Isaacs wrote: ... I'll try to commit a patch that fixes just the following: 1) Fix value="" without allowing param="..." to set. 2) For a String array property, make "?prop=prop=text" set the property for property="*". Currently property="*" handling assumes only simple properties and skips the set because the first argument is empty. Since proper behavior with respect to empty array element is still unclear, I'll wait on the removal of empty array elements. This should be addressed in a separate patch anyway. Sounds good. Thanks. -- Pierre
Re: Proper jsp:setProperty behavior for Tomcat 3.2
Larry Isaacs wrote: I'm +1 on fixing the jsp:setProperty name="bean" property="prop" value=""/ bug in Tomcat 3.2. +1 If the desired behavior for indexed properties can be determined, I can try to fix that too. Sent email to Eduardo to try to get a clarification. -- Pierre
Re: FW: lock
Well, It is now 5:30 am, and the situation still has not changed regarding the following lock (I've had this since 6pm last night). ... cvs server: [05:29:59] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src /share/org/apache/jasper/compiler cvs server: [05:30:29] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src /share/org/apache/jasper/compiler cvs server: [05:30:59] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src /share/org/apache/jasper/compiler cvs server: [05:31:29] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src /share/org/apache/jasper/compiler cvs server: [05:31:59] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src /share/org/apache/jasper/compiler ... Any cvs expert that could fix the situation? Thanks, -- Pierre Larry Isaacs wrote: Sorry, typo in the Cc: -Original Message- From: Larry Isaacs To: 'Pierre Delisle ' Cc: '[EMAIL PROTECTED]' Sent: 11/15/00 9:55 PM Subject: RE: lock Hi Pierre, I saw the same thing a little after 5:00 PM when I tried a commit some changes to this directory. After about 5 minutes of this, I aborted and logged out of jakarta.apache.org. I have tried to commit two more times with the same result. I'm supprised to see my username on the "lock". I thought it was a "lock" that was more general, not something tagged to me. I'm not aware of anything intentional on my part that created this "lock". I have been using WinCVS 1.1b15/16 for a while with no problems. Any suggestions on how I might release this "lock" from my end? Otherwise, hope this can be fixed from the server side. Larry -Original Message- From: Pierre Delisle To: [EMAIL PROTECTED] Sent: 11/15/00 9:21 PM Subject: lock Larry, I cannot commit to tomcat_32. I've been getting this message for the last 5 minutes: . cvs server: [18:18:18] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src /share/org/apache/jasper/compiler cvs server: [18:18:48] waiting for larryi's lock in /home/cvs/jakarta-tomcat/src /share/org/apache/jasper/compiler ... Any idea? -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3.2 status -- no taglibs in jars
Brian Bucknam wrote: Craig says all the critical bugs are fixed, and it seems maybe they are. However, there is still a problem (see bug #215) in TagLibraryInfoImpl which makes it so that tag libraries cannot be packaged in .jar files. (3.2b7 (and 3.1) at least not on Windows, have not tested on *nix.) I marked this bug "serious" when I entered it because you can 'work around it' if you un-jar the tag library into WEB-INF/classes and rename the taglib.tld file, then refer to the .tld file from your JSP's. But if 3.2 is supposed to represent the JSP 1.1 spec, then it clearly states that packaging a tag library in a jar inside WEB-INF/lib is supposed to be a possibility. Maybe this is "critical"? This problem occurs because the jar file is being copied into the work directory. However, this should not be done (there is in fact a comment in the code saying "Take this stuff out when taglib changes are thoroughly tested".) I have commented out that code section and the test I ran worked fine. I'll commit the patch right now and I'd appreciate if you could run some exhaustive tests. -- Pierre On a separate topic, we're having some classloader problems where classes supposedly available in .jars in WEB-INF/lib come up as "NoClassDefFound" as supporting classes for some servlets and JSP pages. Moving these jars to jakarta-tomcat/lib solves the problem. I haven't had time to track down exactly where the problem is, but it seems wrong that the web-app classloader that loads the servlets JSP's seems to be ignoring the lib jars, or acting as if the classes in those jars came from a different loader. I probably should get better details before bringing this to the list, but I saw Rickard Öberg's mention of a getResource() problem... My $.02, Brian - 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 4.0 -- JSP XML representation problems
Boyd, I cannot really use the XML representation, because the jsp:cdata tag doesn't work with current Tomcat-4.0-devel. I get classCastExceptions if I try to use this tag. But you could still use ![CDATA[ ... ]] for your CDATA. jsp:cdata should be in tomcat-4.0 befroe the end of the week. ps: I can see that ultimately, we'll have a clean xml rep of jsp, using the xml namespaces etc. But at the moment it's a mess... With the community contributing constructive feedback, tests, code, patches, comments, etc, it will definitely get there faster... -- Pierre Boyd Waters wrote: Howdy... Tomcat 4.0 attempts to conform to the JSP 1.2 spec. JSP 1.2 specifies an XML representation for JSP pages. One is supposedly able to use the original syntax, or the new XML rep, but one CANNOT inter-mingle XML and the original syntax in the 1.2 spec. People, this is *awful*. All of my stuff breaks. For example: pThis version of the table was created by treating the nested content as the XML document (simulating the case where the JSP page itself would be rendering XML output), but using an external XSL stylesheet./p xsl:apply xsl="/xml/employeeList.xsl" ?xml version="1.0" encoding="ISO-8859-1"? employees employee id="123" first-nameJohn/first-name last-nameDoe/last-name telephone800-555-1212/telephone /employee employee id="456" first-nameJane/first-name last-nameSmith/last-name telephone888-555-1212/telephone /employee employee id="789" first-nameGeorge/first-name last-nameTaylor/last-name telephone555-555-1212/telephone /employee /employees /xsl:apply hr - This code cannot be incorporated into an "original-style" JSP page because its got XML in it. You have to go to the fully blown-out XML representation. I cannot really use the XML representation, because the jsp:cdata tag doesn't work with current Tomcat-4.0-devel. I get classCastExceptions if I try to use this tag. It's actually worse than this, because my site uses XHTML -- the HTML pages are XML documents. I need Tomcat to emit XML, *INCLUDING* the DOCTYPE declaration. So by way of winding down this rant, has anyone been able to use the XSL taglib with Tomcat 4.0? Or any XML at all? -- boyd ps: I can see that ultimately, we'll have a clean xml rep of jsp, using the xml namespaces etc. But at the moment it's a mess... - Boyd Waters [EMAIL PROTECTED] National Radio Astronomy Observatory http://www.nrao.edu PO Box 0 Socorro, NM 87801 505.835.7346 http://www.zocalo.net/~waters [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]
