You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jacob Hookom <ho...@uwec.edu> on 2002/07/01 08:23:40 UTC
Struts 1.1b1 HTML:Form
With struts 1.1b, the only way it will instantiate a bean for a form
correctly is if the bean actually extends ActionForm? The jsp works
fine on my JRun server running the old release of struts.
I’m seeing that only my forms with specialized ActionForms seem to work
correctly with 1.1b; and it’s only when I use the <html:form> tag,
otherwise using <form action=”/action.do”> works.
[see below for exception thrown from <html:form>]
If forms now require being extended from actionform, do I have to
basically duplicate bean logic specifically for a form on a page?
Regards,
Jake Hookom
University of Wisconsin, Eau Claire
Exception Thrown:
javax.servlet.jsp.JspException: Exception creating bean of class
com.dds.bean.Workspace: {1}
at
org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:610)
at
org.apache.jsp.workspace_0002dinsert$jsp._jspService(workspace_0002dinse
rt$jsp.java:302)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServle
t.java:201)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:190)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja
va:246)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:234
7)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:180)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
lve.java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:174)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
ava:1027)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
1125)
at java.lang.Thread.run(Thread.java:536)
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
RE: Problem with Struts 1.1b1 and Log4J 1.2.4
Posted by Hemanth Setty <hs...@buildview.com>.
Thanks..worked perfectly :)
Also, Is there a way to not show the apache DEBUG messages(without the
obvious log4j.properties Thresholod change..?)Nothing major, but it would be
good not to see the apache DEBUG messages for my application?? I guess it
will be removed when it goes out of beta.
-hemanth
-----Original Message-----
From: hemant [mailto:yaxiz@softhome.net]
Sent: Tuesday, July 02, 2002 11:02 AM
To: Struts Users Mailing List
Subject: Re: Problem with Struts 1.1b1 and Log4J 1.2.4
One other thing, Make sure your Startup Servlet does not extend
ActionServlet. I made it extend HttpServlet and the problem went away.
Thanks
hemant
----- Original Message -----
From: "hemant" <ya...@softhome.net>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Tuesday, July 02, 2002 11:54 AM
Subject: Re: Problem with Struts 1.1b1 and Log4J 1.2.4
> Fabrice and Hemant
>
> I had this problem too but I overcame it the hard way. Many a times, its
the
> IDE that causes this kinda confusion.
>
> Here is what I did, I wrote a startup servlet that starts up logging ,
> creates the connection pools via poolman, and loads a few other things.
>
> step1: I loaded this startup servlet "prior" to loading the Action
> Servlet.Please see my web.xml below: (<load-on-startup> number )
> step2: Remove log4j property files from your webapp. Let it pick it up
from
> your IDE environment. (I mean C:/program files/ibm/visual age /yada/yada)
> step3: Make sure your WEB-INF/lib has the latest struts libraries.
>
> But yes, it was almost insulting that the LOG4J error would baffle us
like
> that.
>
> LOL
>
> later...
> hemant
>
>
>
> //-----------------------------------------------------
> <web-app>
> <servlet>
> <servlet-name>action</servlet-name>
> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
> <init-param>
> <param-name>debug</param-name>
> <param-value>2</param-value>
> </init-param>
> <init-param>
> <param-name>config</param-name>
> <param-value>/WEB-INF/struts-config.xml</param-value>
> </init-param>
> <init-param>
> <param-name>application</param-name>
> <param-value>blah.blah...........ApplicationResources</param-value>
> </init-param>
> <init-param>
> <param-name>detail</param-name>
> <param-value>2</param-value>
> </init-param>
> <init-param>
> <param-name>validate</param-name>
> <param-value>true</param-value>
> </init-param>
> <load-on-startup>2</load-on-startup>
> </servlet>
>
>
>
>
> <!--Startup Manager-->
>
> <servlet>
> <servlet-name>mpi_startup_manager</servlet-name>
> <servlet-class>blah.blah............StartupManager</servlet-class>
> <init-param>
> <param-name>LOG4J_CONFIG</param-name>
> <param-value>/blah/.blah.........../log4j.properties</param-value>
> </init-param>
> <load-on-startup>1</load-on-startup>
> </servlet>
> //-----------------------------------------------------
>
>
> ----- Original Message -----
> From: "Hemanth Setty" <hs...@buildview.com>
> To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> Sent: Monday, July 01, 2002 8:53 PM
> Subject: Problem with Struts 1.1b1 and Log4J 1.2.4
>
>
> > Hello,
> >
> > I have included both the Struts and Log4J packages in a webapp. Things
> > worked fine when I was using Struts 1.0.2. After I got the latest beta
> > realease of struts(1.1b1)..I get this error
> >
> > log4j:WARN No appenders could be found for logger
> > (org.apache.commons.digester.Digester).
> > log4j:WARN Please initialize the log4j system properly.
> >
> > Does anybody know why this occurs? After digging in a little bit I
> realized
> > its because of the common-digester.jar file that comes with the
struts1.1?
> > But why does this error show up? Should I just stick with 1.0.2 of
struts
> > until a full release of 1.1?
> >
> > -hemanth
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with Struts 1.1b1 and Log4J 1.2.4
Posted by hemant <ya...@softhome.net>.
One other thing, Make sure your Startup Servlet does not extend
ActionServlet. I made it extend HttpServlet and the problem went away.
Thanks
hemant
----- Original Message -----
From: "hemant" <ya...@softhome.net>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Tuesday, July 02, 2002 11:54 AM
Subject: Re: Problem with Struts 1.1b1 and Log4J 1.2.4
> Fabrice and Hemant
>
> I had this problem too but I overcame it the hard way. Many a times, its
the
> IDE that causes this kinda confusion.
>
> Here is what I did, I wrote a startup servlet that starts up logging ,
> creates the connection pools via poolman, and loads a few other things.
>
> step1: I loaded this startup servlet "prior" to loading the Action
> Servlet.Please see my web.xml below: (<load-on-startup> number )
> step2: Remove log4j property files from your webapp. Let it pick it up
from
> your IDE environment. (I mean C:/program files/ibm/visual age /yada/yada)
> step3: Make sure your WEB-INF/lib has the latest struts libraries.
>
> But yes, it was almost insulting that the LOG4J error would baffle us
like
> that.
>
> LOL
>
> later...
> hemant
>
>
>
> //-----------------------------------------------------
> <web-app>
> <servlet>
> <servlet-name>action</servlet-name>
> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
> <init-param>
> <param-name>debug</param-name>
> <param-value>2</param-value>
> </init-param>
> <init-param>
> <param-name>config</param-name>
> <param-value>/WEB-INF/struts-config.xml</param-value>
> </init-param>
> <init-param>
> <param-name>application</param-name>
> <param-value>blah.blah...........ApplicationResources</param-value>
> </init-param>
> <init-param>
> <param-name>detail</param-name>
> <param-value>2</param-value>
> </init-param>
> <init-param>
> <param-name>validate</param-name>
> <param-value>true</param-value>
> </init-param>
> <load-on-startup>2</load-on-startup>
> </servlet>
>
>
>
>
> <!--Startup Manager-->
>
> <servlet>
> <servlet-name>mpi_startup_manager</servlet-name>
> <servlet-class>blah.blah............StartupManager</servlet-class>
> <init-param>
> <param-name>LOG4J_CONFIG</param-name>
> <param-value>/blah/.blah.........../log4j.properties</param-value>
> </init-param>
> <load-on-startup>1</load-on-startup>
> </servlet>
> //-----------------------------------------------------
>
>
> ----- Original Message -----
> From: "Hemanth Setty" <hs...@buildview.com>
> To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> Sent: Monday, July 01, 2002 8:53 PM
> Subject: Problem with Struts 1.1b1 and Log4J 1.2.4
>
>
> > Hello,
> >
> > I have included both the Struts and Log4J packages in a webapp. Things
> > worked fine when I was using Struts 1.0.2. After I got the latest beta
> > realease of struts(1.1b1)..I get this error
> >
> > log4j:WARN No appenders could be found for logger
> > (org.apache.commons.digester.Digester).
> > log4j:WARN Please initialize the log4j system properly.
> >
> > Does anybody know why this occurs? After digging in a little bit I
> realized
> > its because of the common-digester.jar file that comes with the
struts1.1?
> > But why does this error show up? Should I just stick with 1.0.2 of
struts
> > until a full release of 1.1?
> >
> > -hemanth
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with Struts 1.1b1 and Log4J 1.2.4
Posted by hemant <ya...@softhome.net>.
Fabrice and Hemant
I had this problem too but I overcame it the hard way. Many a times, its the
IDE that causes this kinda confusion.
Here is what I did, I wrote a startup servlet that starts up logging ,
creates the connection pools via poolman, and loads a few other things.
step1: I loaded this startup servlet "prior" to loading the Action
Servlet.Please see my web.xml below: (<load-on-startup> number )
step2: Remove log4j property files from your webapp. Let it pick it up from
your IDE environment. (I mean C:/program files/ibm/visual age /yada/yada)
step3: Make sure your WEB-INF/lib has the latest struts libraries.
But yes, it was almost insulting that the LOG4J error would baffle us like
that.
LOL
later...
hemant
//-----------------------------------------------------
<web-app>
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
<init-param>
<param-name>application</param-name>
<param-value>blah.blah...........ApplicationResources</param-value>
</init-param>
<init-param>
<param-name>detail</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>validate</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
<!--Startup Manager-->
<servlet>
<servlet-name>mpi_startup_manager</servlet-name>
<servlet-class>blah.blah............StartupManager</servlet-class>
<init-param>
<param-name>LOG4J_CONFIG</param-name>
<param-value>/blah/.blah.........../log4j.properties</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
//-----------------------------------------------------
----- Original Message -----
From: "Hemanth Setty" <hs...@buildview.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Monday, July 01, 2002 8:53 PM
Subject: Problem with Struts 1.1b1 and Log4J 1.2.4
> Hello,
>
> I have included both the Struts and Log4J packages in a webapp. Things
> worked fine when I was using Struts 1.0.2. After I got the latest beta
> realease of struts(1.1b1)..I get this error
>
> log4j:WARN No appenders could be found for logger
> (org.apache.commons.digester.Digester).
> log4j:WARN Please initialize the log4j system properly.
>
> Does anybody know why this occurs? After digging in a little bit I
realized
> its because of the common-digester.jar file that comes with the struts1.1?
> But why does this error show up? Should I just stick with 1.0.2 of struts
> until a full release of 1.1?
>
> -hemanth
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with Struts 1.1b1 and Log4J 1.2.4
Posted by fabrice dewasmes <fd...@kaptech.com>.
Hi,
i had the same question. I haven't gone very deep in the problem but here's
what i assumed :
Struts makes use of log4j for its logging purpose. When it comes to
initialize itself it happens that it loads your log4j but as it is yours
you've got initialize it before any debug stuff get logged. A way i used to
work around this is to extend the ActionServlet Class and do your log4j init
before calling super.init()
I guess this is ok as init is not a constructor and you're not forced to
call the super method before any other.
Be careful after doing this to properly filter any org.apache debug traces
in your log4j configurator.
Fabrice
> -----Message d'origine-----
> De : Hemanth Setty [mailto:hsetty@buildview.com]
> Envoyé : mardi 2 juillet 2002 02:54
> À : Struts Users Mailing List
> Objet : Problem with Struts 1.1b1 and Log4J 1.2.4
>
>
> Hello,
>
> I have included both the Struts and Log4J packages in a webapp. Things
> worked fine when I was using Struts 1.0.2. After I got the latest beta
> realease of struts(1.1b1)..I get this error
>
> log4j:WARN No appenders could be found for logger
> (org.apache.commons.digester.Digester).
> log4j:WARN Please initialize the log4j system properly.
>
> Does anybody know why this occurs? After digging in a little bit
> I realized
> its because of the common-digester.jar file that comes with the struts1.1?
> But why does this error show up? Should I just stick with 1.0.2 of struts
> until a full release of 1.1?
>
> -hemanth
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Problem with Struts 1.1b1 and Log4J 1.2.4
Posted by Hemanth Setty <hs...@buildview.com>.
Hello,
I have included both the Struts and Log4J packages in a webapp. Things
worked fine when I was using Struts 1.0.2. After I got the latest beta
realease of struts(1.1b1)..I get this error
log4j:WARN No appenders could be found for logger
(org.apache.commons.digester.Digester).
log4j:WARN Please initialize the log4j system properly.
Does anybody know why this occurs? After digging in a little bit I realized
its because of the common-digester.jar file that comes with the struts1.1?
But why does this error show up? Should I just stick with 1.0.2 of struts
until a full release of 1.1?
-hemanth
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts 1.1b1 HTML:Form
Posted by Ted Husted <hu...@apache.org>.
The change you are running into is that in 1.1 the html:form tag now
calls the reset() method. That was not the case in 1.0 so the bean type
wasn't as important.
But, if your "legacy" JavaBeans and ActionForms share the same property
names (or "protocol"), you can use those beans to write the form -- so
long as they *already exist*. If these beans are doing the data access
or something, just instantiate them in an Action first, and then forward
them out to the page under the appropriate attribute name. If the
html:form doesn't need to create the bean, and the method names are
right, that should be the end of it.
It's important to use an ActionForm "on the other side of the submit".
But for bringing data down from the business tier, you're right, it is
often convenient to use a business bean. And this is easy to do, so long
as it usses the same protocol (property names) as the ActionForm annd
html:form doesn't need to create it (and call reset()). But to take the
modified data back up again, you *do* need to use an ActionForm to check
the input and so forth.
-- Ted Husted, Husted dot Com, Fairport NY US
-- Java Web Development with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services
Jacob Hookom wrote:
>
> With struts 1.1b, the only way it will instantiate a bean for a form
> correctly is if the bean actually extends ActionForm? The jsp works
> fine on my JRun server running the old release of struts.
>
> Im seeing that only my forms with specialized ActionForms seem to work
> correctly with 1.1b; and its only when I use the <html:form> tag,
> otherwise using <form action=/action.do> works.
>
> [see below for exception thrown from <html:form>]
>
> If forms now require being extended from actionform, do I have to
> basically duplicate bean logic specifically for a form on a page?
>
> Regards,
> Jake Hookom
> University of Wisconsin, Eau Claire
>
> Exception Thrown:
> javax.servlet.jsp.JspException: Exception creating bean of class
> com.dds.bean.Workspace: {1}
> at
> org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:610)
> at
> org.apache.jsp.workspace_0002dinsert$jsp._jspService(workspace_0002dinse
> rt$jsp.java:302)
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServle
> t.java:201)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:247)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:193)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
> e.java:243)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> e.java:190)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
> org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja
> va:246)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:234
> 7)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> :180)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
> lve.java:170)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> :170)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468
> )
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:174)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
> ava:1027)
> at
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
> 1125)
> at java.lang.Thread.run(Thread.java:536)
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts 1.1b1 HTML:Form
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 1 Jul 2002, Jacob Hookom wrote:
> Date: Mon, 1 Jul 2002 12:32:11 -0500
> From: Jacob Hookom <ho...@uwec.edu>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: 'Struts Users Mailing List' <st...@jakarta.apache.org>
> Subject: RE: Struts 1.1b1 HTML:Form
>
> Thanks for the clarification.
>
> My thought was that struts w/should be able to accommodate pre-existing
> beans on the system for ease of generating jsp's-- without generating
> new beans that contain the same object definition and just extend from a
> different class.
>
You can do that for non-form-beans just fine. But the decision to make
you create form beans is a very deliberate part of the design of Struts.
In a single sentence, form beans are part of the view tier in the MVC
architecture, not the model tier like a typical JavaBean that represents
data from your database.
Consider the case where you've got a bean property that is an integer
(i.e. data type is "int"). Now, this will typically get displayed as a
text entry field on your form, and you'll need to do a String->int
conversion someplace.
Now, consider what happens when the user types "1a3" instead of "123".
The user expects your app to complain about this, AND to redisplay the
value exactly the way it was typed ("1a3") so that it can be corrected.
That's the way any well-behaved GUI program behaves, and that is the way
webapps should work as well.
The Struts approach to this is that the form bean would use a String for
this property, with a rule in your validate() method to ensure that the
conversion is possible. That way, you can live up to the user's
expectations for high quality input, and the need for the application to
validate everything sent by the client. The actual conversion only
happens in your Action that processes the form, after validation has been
completed successfully.
As an extra added benefit, you don't have to worry about your model beans
getting scribbled on with form data that hasn't been validated yet. That
is all hidden away n the form bean, and you only copy it out when you know
that the validation rules have all passed.
> -Jake
Craig
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Monday, July 01, 2002 12:06 PM
> To: Struts Users Mailing List
> Subject: Re: Struts 1.1b1 HTML:Form
>
> It is correct to say that all of the automatic Struts machinery for form
> beans only works if your bean is a subclass of ActionForm. (In Struts
> 1.1, that includes the DynaActionForm class as well.)
>
> Craig
>
>
> On Mon, 1 Jul 2002, Jacob Hookom wrote:
>
> > Date: Mon, 1 Jul 2002 01:23:40 -0500
> > From: Jacob Hookom <ho...@uwec.edu>
> > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> > To: 'Struts Users Mailing List' <st...@jakarta.apache.org>
> > Subject: Struts 1.1b1 HTML:Form
> >
> > With struts 1.1b, the only way it will instantiate a bean for a form
> > correctly is if the bean actually extends ActionForm? The jsp works
> > fine on my JRun server running the old release of struts.
> >
> > Im seeing that only my forms with specialized ActionForms seem to
> work
> > correctly with 1.1b; and its only when I use the <html:form> tag,
> > otherwise using <form action=/action.do> works.
> >
> > [see below for exception thrown from <html:form>]
> >
> > If forms now require being extended from actionform, do I have to
> > basically duplicate bean logic specifically for a form on a page?
> >
> > Regards,
> > Jake Hookom
> > University of Wisconsin, Eau Claire
> >
> > Exception Thrown:
> > javax.servlet.jsp.JspException: Exception creating bean of class
> > com.dds.bean.Workspace: {1}
> > at
> > org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:610)
> > at
> >
> org.apache.jsp.workspace_0002dinsert$jsp._jspService(workspace_0002dinse
> > rt$jsp.java:302)
> > at
> > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > at
> >
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServle
> > t.java:201)
> > at
> >
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
> > at
> > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> > tionFilterChain.java:247)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> > erChain.java:193)
> > at
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
> > e.java:243)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> > va:566)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> > 72)
> > at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > at
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> > e.java:190)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> > va:566)
> > at
> >
> org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja
> > va:246)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> > va:564)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> > 72)
> > at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > at
> >
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:234
> > 7)
> > at
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> > :180)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> > va:566)
> > at
> >
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
> > lve.java:170)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> > va:564)
> > at
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> > :170)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> > va:564)
> > at
> >
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468
> > )
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> > va:564)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> > 72)
> > at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > at
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> > java:174)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> > va:566)
> > at
> >
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> > 72)
> > at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > at
> >
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
> > ava:1027)
> > at
> >
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
> > 1125)
> > at java.lang.Thread.run(Thread.java:536)
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts 1.1b1 HTML:Form
Posted by Jacob Hookom <ho...@uwec.edu>.
Thanks for the clarification.
My thought was that struts w/should be able to accommodate pre-existing
beans on the system for ease of generating jsp's-- without generating
new beans that contain the same object definition and just extend from a
different class.
-Jake
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Monday, July 01, 2002 12:06 PM
To: Struts Users Mailing List
Subject: Re: Struts 1.1b1 HTML:Form
It is correct to say that all of the automatic Struts machinery for form
beans only works if your bean is a subclass of ActionForm. (In Struts
1.1, that includes the DynaActionForm class as well.)
Craig
On Mon, 1 Jul 2002, Jacob Hookom wrote:
> Date: Mon, 1 Jul 2002 01:23:40 -0500
> From: Jacob Hookom <ho...@uwec.edu>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: 'Struts Users Mailing List' <st...@jakarta.apache.org>
> Subject: Struts 1.1b1 HTML:Form
>
> With struts 1.1b, the only way it will instantiate a bean for a form
> correctly is if the bean actually extends ActionForm? The jsp works
> fine on my JRun server running the old release of struts.
>
> I’m seeing that only my forms with specialized ActionForms seem to
work
> correctly with 1.1b; and it’s only when I use the <html:form> tag,
> otherwise using <form action=”/action.do”> works.
>
> [see below for exception thrown from <html:form>]
>
> If forms now require being extended from actionform, do I have to
> basically duplicate bean logic specifically for a form on a page?
>
> Regards,
> Jake Hookom
> University of Wisconsin, Eau Claire
>
> Exception Thrown:
> javax.servlet.jsp.JspException: Exception creating bean of class
> com.dds.bean.Workspace: {1}
> at
> org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:610)
> at
>
org.apache.jsp.workspace_0002dinsert$jsp._jspService(workspace_0002dinse
> rt$jsp.java:302)
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
>
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServle
> t.java:201)
> at
>
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:247)
> at
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:193)
> at
>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
> e.java:243)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> e.java:190)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
>
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja
> va:246)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:234
> 7)
> at
>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> :180)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
>
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
> lve.java:170)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> :170)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
>
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468
> )
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:174)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
> ava:1027)
> at
>
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
> 1125)
> at java.lang.Thread.run(Thread.java:536)
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts 1.1b1 HTML:Form
Posted by "Craig R. McClanahan" <cr...@apache.org>.
It is correct to say that all of the automatic Struts machinery for form
beans only works if your bean is a subclass of ActionForm. (In Struts
1.1, that includes the DynaActionForm class as well.)
Craig
On Mon, 1 Jul 2002, Jacob Hookom wrote:
> Date: Mon, 1 Jul 2002 01:23:40 -0500
> From: Jacob Hookom <ho...@uwec.edu>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: 'Struts Users Mailing List' <st...@jakarta.apache.org>
> Subject: Struts 1.1b1 HTML:Form
>
> With struts 1.1b, the only way it will instantiate a bean for a form
> correctly is if the bean actually extends ActionForm? The jsp works
> fine on my JRun server running the old release of struts.
>
> Im seeing that only my forms with specialized ActionForms seem to work
> correctly with 1.1b; and its only when I use the <html:form> tag,
> otherwise using <form action=/action.do> works.
>
> [see below for exception thrown from <html:form>]
>
> If forms now require being extended from actionform, do I have to
> basically duplicate bean logic specifically for a form on a page?
>
> Regards,
> Jake Hookom
> University of Wisconsin, Eau Claire
>
> Exception Thrown:
> javax.servlet.jsp.JspException: Exception creating bean of class
> com.dds.bean.Workspace: {1}
> at
> org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:610)
> at
> org.apache.jsp.workspace_0002dinsert$jsp._jspService(workspace_0002dinse
> rt$jsp.java:302)
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServle
> t.java:201)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:247)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:193)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
> e.java:243)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> e.java:190)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
> org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja
> va:246)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:234
> 7)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> :180)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
> lve.java:170)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> :170)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468
> )
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:564)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:174)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
> va:566)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
> 72)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
> ava:1027)
> at
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
> 1125)
> at java.lang.Thread.run(Thread.java:536)
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>