You can get the electronic copy online, visit http://www.manning.com/Fields
for details
Duane Fields
[EMAIL PROTECTED]
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some rel
uot;loginPage=/login.jsp",
allowing me to use the controlling servlet everywhere, even turning it on
and off at deployment time. That way, any page passing through the control
servlet can selectively be made secure.
--
Duane Fields
[EMAIL PROT
Check out http://www.taglib.com
--
Duane Fields
[EMAIL PROTECTED]
Learn Web Development with JSP!
http://www.taglib.com
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some rel
There is a "whois bean" in the source code at http://www.taglib.com.
--
Duane Fields
[EMAIL PROTECTED]
Learn Web Development with JSP!
http://www.taglib.com
===
To unsubscribe: mailto [EMAIL PROTECTED] with body
You need to make sure that tools.jar is in the classpath of the server
(Java2). It's normally in /usr/java/lib/tools.jar
--
Duane Fields
[EMAIL PROTECTED]
Learn Web Development with JSP!
http://www.taglib.com
Web Development with JavaServer Pages will be available in March
http://www.amazon.com/exec/obidos/ASIN/1884777996/deepmagic
http://www.manning.com/Fields
--
Duane Fields
[EMAIL PROTECTED]
Learn Web Development with JSP!
http://www.deepmagic.com/jsp
A colleague and I are finishing up a JSP book now,
http://www.manning.com/Fields and an excerpt is available at
http://developer.netscape.com/viewsource
We should see it hit the shelves this Spring.
Duane Fields
[EMAIL PROTECTED
error page will
automatically create the implicit exception object, and error handling can
proceed. There is no difference between an exception created by our servlet
in this example and an exception being generated by an error in another JSP
page.
Duane Fields
If I try something like
jsp:useBean name="request" property="queryString"/
It works fine as long as queryString doesn't return a null value, in which
case JRun give me a null pointer error in com.livesoftware.jsp.JSPServlet.
Has anyone else seen this? I'm assuming that
jsp:useBean name="request" property="queryString"/
Duh typo: that should be jsp:getProperty of course
Duane Fields
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of
assed to
java.beans.Bean.instantiate() which will instantiate the Bean for the class
loader. It first assumes that the name corresponds to a serialized Bean file
in which case it will bring it to life, but if can't find or invoke t
Is there a good reason that the jsp:useBean tag uses the "ID" attribute to
identify Beans and everything else uses the "NAME" attibute?
Duane Fields
Sr. Engineer
Tivoli Systems
===
To unsubscribe,
I see the dual--approach presented by JSP to be one of its strongest points.
As has been noted, TAGS can't do everything. However, they can do a lot. And
while maybe there's room for one or two more - I would introduce too much
more in the way of flow control or other programmatical issues, as
How is DISPLAY PROPERTY="request:params:myparam" implemented in side of
JRUN or other JSP Engines? Looking at the source generated by JRUN I see
that it places the same call to JSP.beanVal() that it would for any other
bean. What's different of course is that the myparam is a string argument .
I've noticed that JRun doesn't like beans to be part of the default package,
as yours is. Give it at least one level of package, put it in the
appropriate directory hierarchy and you should be set.
Duane K. Fields
[EMAIL PROTECTED]
Sr. Internet Systems Engineer
Tivoli Systems, Inc.
I'll be there as well... put me on the 'guest' list
Duane K. Fields
[EMAIL PROTECTED]
Sr. Internet Systems Engineer
Tivoli Systems, Inc.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the
16 matches
Mail list logo
