You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Renee Petris <re...@loudeye.com> on 2001/01/24 18:05:38 UTC
Problem parsing taglib
I'm trying to run a very simple Hello World example. My jsp contains only:
<%@ page language="java" %>
<!--Import the taglib -->
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
<!--Now use the tag to display the message -->
<bean:message key="hello.message" />
When I try to open the page, I get the following exception:
org.apache.jasper.JasperException: Unable to open taglibrary
/WEB-INF/struts-bean.tld : Parse Error in the tag library descriptor:
Character conversion error: "Unconvertible UTF-8 character beginning with
0xb4" (line number may be too low).
at
org.apache.jasper.compiler.JspParseEventListener.handleDirective(JspParseEve
ntListener.java:672)
at
org.apache.jasper.compiler.DelegatingListener.handleDirective(DelegatingList
ener.java:116)
at
org.apache.jasper.compiler.Parser$Directive.accept(Parser.java:215)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1073)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1038)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1034)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:182)
at org.apache.jasper.runtime.JspServlet.loadJSP(JspServlet.java:413)
at
org.apache.jasper.runtime.JspServlet$JspServletWrapper.loadIfNecessary(JspSe
rvlet.java:149)
at
org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.ja
va:161)
at
org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:261)
at org.apache.jasper.runtime.JspServlet.service(JspServlet.java:369)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java:503)
at
org.apache.tomcat.core.RequestDispatcherImpl.forward(RequestDispatcherImpl.j
ava:163)
at
org.apache.tomcat.servlets.DefaultServlet.doGet(DefaultServlet.java:187)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java:503)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:559)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC
onnectionHandler.java:160)
at
org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:338
)
at java.lang.Thread.run(Thread.java:484)
I'm running Tomcat version 3.1.
Renée Petris
Overseer of the Execution
Loudeye Technologies
renee@loudeye.com
414 Olive Way, Suite 300
Seattle, WA 98101
206-832-4500 phone
206-832-4475 fax
Re: Problem parsing taglib
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Renee Petris wrote:
> I'm running Tomcat version 3.1.
>
> Renée Petris
>
Tomcat 3.1 has lots of bugs that negatively affect Struts based applications.
It is not a suitable platform for Struts development or deployment. I would
suggest updating to 3.2.1 or 4.0-beta-1.
Craig McClanahan
Re: Post/re-post problems
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
George Lessmann wrote:
> > I'm not sure I understand what you mean by the "input level". Could you
> > describe it further?
>
> First, my understanding of Struts is that actions happen at the form level,
> such that a form action is further inspected to determine what needs to be
> done. In my system, I go to the lower level of granularity to the actual
> input events.
>
Yes, that is pretty much the case (Struts currently being form oriented). Your
first level of granularity is the action URL that the form is submitted to, and
that action can (if it chooses to) dispatch to a "sub-action" dependent on some
fields that were submitted. In the example app, for example :-), the "action"
field is used to distinguish sub-actions that are handled very similarly, but
with just a few differing details, by the same action.
>
> Let's say I have a form. On that form I can do a few actions, namely Update,
> Add, and Delete. In my architecture, I have it like so:
>
> <input type="submit" name="formname.update" value="Update">
> <input type="submit" name="formname.add" value="Add">
> <input type="submit" name="formname.delete" value="Delete">
>
> The form is posting to:
>
> <form name="formname" action="/AppServlet" method="post">
>
One option would be to use JavaScript event handlers on the three submit
buttons, and change where the submit would actually go to.
> Right now, those actions are separate objects but I'm not to sure I like
> that, but I'm also not a fan of runtime introspection.
You probably will not like the way that ActionForm beans work, then :-).
> My goal, though, is
> to remove most, if not all, switch-like logic. Also, I'm trying to get my
> application flow to become as far removed as possible, since one of my goals
> is to make an application mapping app.
On the TODO list for 1.1 is to look at how a finer-grained "workflow" type model
might fit into the overall framework. In addition, there's been some discussion
of handling events finer-grained than a submit -- everything from clientside
JavaScript field validations to interacting with the host "in the middle of" a
page. But that's all in the future ... present day Struts 1.0 is very much
form-oriented (using your terminology).
>
> Anyway, I hope this makes some sort of sense. Getting an understanding of
> the motives of Struts while trying to keep what I like about my stuff is a
> prescription for headaches.
Yah, that makes a lot more sense.
Like any framework, Struts expects you to "buy in" to the design philosophies
that it is based on. People that do find it to be tremendously helpful. People
that don't are going to select something different. (And, for a wide range of
the middle ground, there is also room to customize the details of how Struts
works by subclassing, but it's probably not going to be easily to make
fundamental changes by following this route).
>
> George Lessmann
>
> Ponvia Technology, Inc
Craig
Re: Post/re-post problems
Posted by George Lessmann <gl...@ponvia.com>.
> I'm not sure I understand what you mean by the "input level". Could you
> describe it further?
First, my understanding of Struts is that actions happen at the form level,
such that a form action is further inspected to determine what needs to be
done. In my system, I go to the lower level of granularity to the actual
input events.
Let's say I have a form. On that form I can do a few actions, namely Update,
Add, and Delete. In my architecture, I have it like so:
<input type="submit" name="formname.update" value="Update">
<input type="submit" name="formname.add" value="Add">
<input type="submit" name="formname.delete" value="Delete">
The form is posting to:
<form name="formname" action="/AppServlet" method="post">
Right now, those actions are separate objects but I'm not to sure I like
that, but I'm also not a fan of runtime introspection. My goal, though, is
to remove most, if not all, switch-like logic. Also, I'm trying to get my
application flow to become as far removed as possible, since one of my goals
is to make an application mapping app.
Anyway, I hope this makes some sort of sense. Getting an understanding of
the motives of Struts while trying to keep what I like about my stuff is a
prescription for headaches.
George Lessmann
Ponvia Technology, Inc
Re: Post/re-post problems
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
George Lessmann wrote:
> > The technical reason this happens is that RequestDispatcher.forward() (or
> > <jsp:forward>) happens only on the server side -- the browser has no clue
> what
> > is going on, and only displays the URL it submitted to -- not the URL of
> the
> > page you called to create the response.
>
> As a Lurker hoping to add his application framework to Struts...
>
> I separate doGet() and doPost() requests so that doGets use forward() and
> doPosts use redirects.
As Hal points out, you can tell a <Forward> entry to use sendRedirect() instead
if you want to. This was one of the very early enhancement requests.
> I would like to hear why Struts decided to use
> forward exclusively.
Forwards are the default for two reasons:
* You can use request attributes to forward information to
the page that is ultimately displayed. Using a sendRedirect,
you're stuck passing stuff in hidden variables in the form,
or as session attributes. (In particular, the ActionForm
bean can often be passed as a request attribute, which
reduces memory occupancy on your server).
* Forwards will generally be faster, because they avoid
a second round trip across the network. This doesn't
matter a lot on a 100mbps intranet, but it can make a
big difference if your client is at the end of a 56k modem
somewhere across the world.
> On a tangent, I would also like to hear why Struts maps
> actions at the form level rather than the input level as in traditional cgi
> programs.
>
I'm not sure I understand what you mean by the "input level". Could you
describe it further?
>
> thanks,
>
> George Lessmann
>
Craig
>
> Ponvia Technology, Inc
Re: Post/re-post problems
Posted by John Raley <jo...@moonlight.com>.
"Deadman, Hal" wrote:
> You can specify that a <forward> be handled by a redirect instead of a
> jsp:forward by doing this:
Ack! "You could have gone home anytime by clicking your shoes together." - to
Dorothy. Guess I should read the dtd a little more closely...
Thanks.
RE: Post/re-post problems
Posted by "Deadman, Hal" <ha...@tallan.com>.
You can specify that a <forward> be handled by a redirect instead of a
jsp:forward by doing this:
<forward name="success" path="/home.jsp" redirect="true"/>
-----Original Message-----
From: George Lessmann [mailto:glessmann@ponvia.com]
Sent: Wednesday, January 24, 2001 2:31 PM
To: struts-user@jakarta.apache.org
Subject: Re: Post/re-post problems
> The technical reason this happens is that RequestDispatcher.forward() (or
> <jsp:forward>) happens only on the server side -- the browser has no clue
what
> is going on, and only displays the URL it submitted to -- not the URL of
the
> page you called to create the response.
As a Lurker hoping to add his application framework to Struts...
I separate doGet() and doPost() requests so that doGets use forward() and
doPosts use redirects. I would like to hear why Struts decided to use
forward exclusively. On a tangent, I would also like to hear why Struts maps
actions at the form level rather than the input level as in traditional cgi
programs.
thanks,
George Lessmann
Ponvia Technology, Inc
Re: Post/re-post problems
Posted by George Lessmann <gl...@ponvia.com>.
> The technical reason this happens is that RequestDispatcher.forward() (or
> <jsp:forward>) happens only on the server side -- the browser has no clue
what
> is going on, and only displays the URL it submitted to -- not the URL of
the
> page you called to create the response.
As a Lurker hoping to add his application framework to Struts...
I separate doGet() and doPost() requests so that doGets use forward() and
doPosts use redirects. I would like to hear why Struts decided to use
forward exclusively. On a tangent, I would also like to hear why Struts maps
actions at the form level rather than the input level as in traditional cgi
programs.
thanks,
George Lessmann
Ponvia Technology, Inc
Re: Post/re-post problems
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Bear wrote:
> Craig,
>
> At 10:28 AM 1/24/2001 -0800, you wrote:
> >* Tell my users "deal with it -- this is a web application, not a
> > web site, and the URL that you see is totally irrelevant."
>
> I'm perfectly comfortable with this regarding the displayed URL. But what
> about the refresh problem? Is there anyway to elegantly handle that?
>
Isn't that part of "deal with it"? Why is the user pressing the Reload button
(or the Back button to return to a previously displayed page)? Those are the
actions that you want to train them to avoid, and teach them to use only the
navigation controls you have provided within your pages.
NOTE: Technology was recently added to Struts so that your application can
detect a duplicate post that was actually submitted. It involves setting a
command token (whose current value is saved in the user's session) that must be
returned with the next submit. If no such value (or a different value) is
returned, this can be detected by your Action and you can do the appropriate
thing (such as *not* add an item to the shopping cart twice).
This is used in the Struts example app on the registration page. In the
EditRegistrationAction (that sets up the beans for registration.jsp) you will
see the call:
saveToken(request);
down at the bottom. Then, in SaveRegistrationAction (which processes the
submitted form) you see:
if (!isTokenValid(request)) {
... deal with the error ...
}
resetToken(request);
Using this technique, the app will catch the case where the user presses Save on
the registration page, then presses the back arrow, then presses Save again.
No changes are needed to the JSP pages themselves -- the <html:form> tag
generates a hidden field automatically if needed.
>
> thanks
> bear
Craig
Re: Post/re-post problems
Posted by Elod Horvath <el...@itfais.com>.
Bear wrote:
>
> Craig,
>
> At 10:28 AM 1/24/2001 -0800, you wrote:
> >* Tell my users "deal with it -- this is a web application, not a
> > web site, and the URL that you see is totally irrelevant."
>
> I'm perfectly comfortable with this regarding the displayed URL. But what
> about the refresh problem? Is there anyway to elegantly handle that?
>
> thanks
> bear
see the following post in the archives for another view/solution
to this issue:
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg01823.html
e
--
_______________________________________________________________________
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: Post/re-post problems
Posted by Bear <be...@beyondvanilla.com>.
Craig,
At 10:28 AM 1/24/2001 -0800, you wrote:
>* Tell my users "deal with it -- this is a web application, not a
> web site, and the URL that you see is totally irrelevant."
I'm perfectly comfortable with this regarding the displayed URL. But what
about the refresh problem? Is there anyway to elegantly handle that?
thanks
bear
Re: Post/re-post problems
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
John Raley wrote:
> Right now I'm "forwarding" to a JSP that does nothing but redirects to the
> URL I want them to see (basically what you said). I would love to hear
> better solutions as well.
>
The technical reason this happens is that RequestDispatcher.forward() (or
<jsp:forward>) happens only on the server side -- the browser has no clue what
is going on, and only displays the URL it submitted to -- not the URL of the
page you called to create the response.
In various apps I have taken the following approaches to this issue:
* Tell my users "deal with it -- this is a web application, not a
web site, and the URL that you see is totally irrelevant." Of
course, it is incumbent upon the page designer to ensure that
there are always enough navigation controls that the user does
not feel tempted to use the back and forward arrows or bookmarks
within your app.
* Use a framed presentation with only one frame in it -- that way,
the location bar never changes so the user isn't distracted.
* Open your application in a window that does not have a location
bar, so the user isn't distracted.
If you can get away with it, I prefer the first approach :-).
Craig
>
> Bear wrote:
>
> > I'm just in the process of re-vamping my web app to use the Struts
> > framework (moving from a Model 1 to a Model 2 architecture) and have come
> > across what I see as a fundamental problem that I'm sure is just something
> > I must be missing.
> >
> > The result of an action submission from a form is obviously a post
> > operation. When the resulting JSP page shows the result of the action, the
> > URL still shows the "command.do" form of the URL. That's not the problem
> > though. If the user then refreshes the page, he/she gets the "do you want
> > to repost" message (annoying), but worse, the post operation is
> > resubmitted. For a destructive operation (like a delete) this could cause
> > lots of problems for my app.
> >
> > Aside from forcing the ActionForward to be a redirect rather than a
> > forward, how have y'all handled this situation?
> >
> > thanks,
> > bear
Re: Post/re-post problems
Posted by John Raley <jo...@moonlight.com>.
Right now I'm "forwarding" to a JSP that does nothing but redirects to the
URL I want them to see (basically what you said). I would love to hear
better solutions as well.
Bear wrote:
> I'm just in the process of re-vamping my web app to use the Struts
> framework (moving from a Model 1 to a Model 2 architecture) and have come
> across what I see as a fundamental problem that I'm sure is just something
> I must be missing.
>
> The result of an action submission from a form is obviously a post
> operation. When the resulting JSP page shows the result of the action, the
> URL still shows the "command.do" form of the URL. That's not the problem
> though. If the user then refreshes the page, he/she gets the "do you want
> to repost" message (annoying), but worse, the post operation is
> resubmitted. For a destructive operation (like a delete) this could cause
> lots of problems for my app.
>
> Aside from forcing the ActionForward to be a redirect rather than a
> forward, how have y'all handled this situation?
>
> thanks,
> bear
Post/re-post problems
Posted by Bear <be...@beyondvanilla.com>.
I'm just in the process of re-vamping my web app to use the Struts
framework (moving from a Model 1 to a Model 2 architecture) and have come
across what I see as a fundamental problem that I'm sure is just something
I must be missing.
The result of an action submission from a form is obviously a post
operation. When the resulting JSP page shows the result of the action, the
URL still shows the "command.do" form of the URL. That's not the problem
though. If the user then refreshes the page, he/she gets the "do you want
to repost" message (annoying), but worse, the post operation is
resubmitted. For a destructive operation (like a delete) this could cause
lots of problems for my app.
Aside from forcing the ActionForward to be a redirect rather than a
forward, how have y'all handled this situation?
thanks,
bear
Re: Problem parsing taglib
Posted by Rob Leland <Ro...@freetocreate.org>.
Ted Husted wrote:
> Also, I believe that Tomcat requires custom tags to be in packages,
> just to be sure you set your example up that way.
Tomcat 3.1 didn't require custom tags to be in packages, 3.2/4.0 might
behave
differently.
Re: Problem parsing taglib
Posted by Ted Husted <ne...@husted.com>.
I'd try opening the TLD file with a text editor, to be sure everything
is as you would expect. Or moving that one, and copying a new one over.
Also, I believe that Tomcat requires custom tags to be in packages,
just to be sure you set your example up that way.
-Ted.
*********** REPLY SEPARATOR ***********
On 1/24/2001 at 9:05 AM Renee Petris wrote:
I'm trying to run a very simple Hello World example. My jsp contains
only:
<%@ page language="java" %>
<!--Import the taglib --><%@ taglib uri="/WEB-INF/struts-bean.tld"
prefix="bean" %>
<!--Now use the tag to display the message --><bean:message
key="hello.message" />
When I try to open the page, I get the following exception:
org.apache.jasper.JasperException: Unable to open taglibrary
/WEB-INF/struts-bean.tld : Parse Error in the tag library descriptor:
Character conversion error: "Unconvertible UTF-8 character beginning
with 0xb4" (line number may be too low).