Re: Is it legal to have multiple taglib setter methods for the same property
Maya Muchnik wrote:
Why you cannot use only one setter "public setIndex (String index)" and then inside
check if the
string is convertable to integer or not? This way your index can represent a number
or "all".
In Tocmat 3.x, your suggestion works if the tag looks like:
foo:displayCLE index="1"/
OR
foo:displayCLE index="all"/
However, if the tag is used like so:
% int i = 1; %
foo:displayCLE index="%= i %"/
Tomcat tries to call "setIndex ( int i )", instead of trying to convert the int into a
String. This
results in an error in the JSP.
...alex...
"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 \
Is it legal to have multiple taglib setter methods for the same property
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 ui.html._0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3._jspService \
(_0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3.java:274)
...
I don't actually think that is hotspot related. I think i'm doing
something wrong. I've looked through the tomcat code, however not too
particularly closely. I was hoping someone would know what's wrong.
In a somewhat unrelated question, I tried having my setIndex() method
defined as:
public void setIndex ( Object o )
and then doing internal "instanceof" calls and casting to proper
objects. This works in Tomcat 3.1, however it fails in Tomcat 4.0.
Did something change in JSP/Taglib 1.2 that makes that type of
declaration invalid?
Thanks very much.
...alex...
-
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
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.
Thanks again.
...alex...
"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
ui.html._0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3._jspService \
(_0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3.java:274)
...
I don't actually think that is hotspot related. I think i'm doing
something wrong. I've looked through the tomcat code, however not too
particularly closely. I was hoping someone would know what's wrong.
In a somewhat unrelated question, I tried having my setIndex() method
defined as:
public void setIndex ( Object o )
and then doing internal "instanceof" calls and casting to proper
objects. This works in Tomcat 3.1, however it fails in Tomcat 4.0.
Did something change in JSP/Taglib 1.2 that makes that type of
declaration invalid?
Thanks very much.
...alex...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: WML Generation from JSP broken!!!!
Is there a way to get the compiler to ignore the "?xml version="1.0"?" syntax? Otherwise this means that serving any page that is XML compliant (WML, XHTML, etc) now requires a complete rewrite of all JSP files to run in 4.0. Thanks. ...alex... "Craig R. McClanahan" wrote: Davanum Srinivas wrote: Hi all, Attached is a JSP Sample file which generates WML. It works with no problems on Tomcat3.1, but fails miserably with the latest dev nightly snapshot and m4. Can someone shed light? Well, your page certainly doesn't work under Tomcat 4.0 (which implements JSP 1.2). Furthermore, it *should* not. Because you are starting this page with an ?xml version="1.0"? directive, the JSP compiler assumes that you have created this page in the XML syntax for JSP pages, as described in the 1.2 spec http://java.sun.com/products/jsp/download.html. However, this page violates several of the rules: * It does not start with a jsp:root element (this is what the parse error is complaining about). * It uses % % for a scriptlet, instead of the required jsp:scriptlet element. You will need to rewrite your page conforming to the new syntax rules in order for it to work correctly under 4.0. Thanks in advance, dims PS: Am not currently subscribed to the list. So please CC me at "[EMAIL PROTECTED]" Craig McClanahan PS: Why did it work under 3.1? Because 3.1 didn't support the XML syntax, so it just passed the ?xml? directive through as template text.
