Search list

[Pete Gieser]

I may have missed this, but why is searching on the user list not
working?

Pete


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DynaActionForm population

[Pete Gieser]

I am having a problem with the following design.  

In my jsp, i'm using the  tag with property="action",
but I find that when I want to cancel, I can't prevent the
RequestProcessor
from trying to copy the request form values into a new DynaActionForm.
The problem is that when cancelling, some of the values may be invalid,
but since I don't want to validate, this can throw an exception when
auto
conversions are attempted (that don't succeed) to populate the bean. For
example, if I leave the birthDate field blank, I get:

java.lang.IllegalArgumentException
at java.sql.Date.valueOf(Date.java:100)
at
org.apache.commons.beanutils.converters.SqlDateConverter.convert(SqlDate
Converter.java:157)

I guess this is a consequence of the action mapping I've got below. I
really only require the form for update and delete, but not for cancel.

How can I fix this?


Thanks!
Pete

=

  

  
  
  

  


  
  
  



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Error handling (ServletException)

[Pete Gieser]

Is there something special I have to do to handle a ServletException?
No matter what I try, the stack trace always seems to be sent to the 
standard Tomcat error page.  

I've tried configuring  in struts-config, but that
doesn't seem to work.  What's the secret?

  

  

javax.servlet.ServletException: BeanUtils.populate
at
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:980)
at
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcess
or.java:779)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
246)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1292)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)

Thanks!
Pete


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Strutstest with tiles - verifyForward behavior

[Pete Gieser]

I also notice that a bug has been filed by another individual on
sourceforge that is displaying this same behavior...so I guess
you are right.

Pete

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Thomas Quas
> Sent: Tuesday, November 19, 2002 1:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Strutstest with tiles - verifyForward behavior
> 
> 
> 
> Pete,
> 
> I'm seeing the same behavior... plus more weirdness. I'm using the 
> latest CVS snapshot; I guess strutstestcase is not ready for testing 
> those kind of Struts applications yet.
> 
> 
> tom
> 
> Pete Gieser wrote:
> > Using MockStrutsCase (from release 1.9) with the following 
> test method:
> >  
> > public void testManagerSuccess()
> > {
> > setRequestPathInfo("/famnet");
> > actionPerform();
> > verifyForward("success");
> > assertNotNull(getSession().getAttribute("members"));
> > verifyNoActionErrors();
> > }
> > 
> > and this section from struts-config.xml:
> >  
> > 
> >   
> > 
> > 
> > and this section from tiles-def.xml:
> >  
> >> extends="main.layout">
> > 
> > 
> >   
> > 
> > I'm getting the following error:
> >  
> > processActionForward(famnet.list, false)
> >   'famnet.list' - processed as definition
> > -  ---
> >  
> > Testcase: testManagerSuccess took 3.636 sec
> >  FAILED
> > was expecting 'famnet.list' but received '/layout/layout.jsp'
> > junit.framework.AssertionFailedError: was expecting 
> 'famnet.list' but
> > received '/layout/layout.jsp'


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Commons-logging and JDK 1.4 Logger

[Pete Gieser]

Gee, didn't expect the formatting problem...

commons-logging.properties attached instead.

> -Original Message-
> From: Pete Gieser [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, November 18, 2002 5:57 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Commons-logging and JDK 1.4 Logger
> 
> 
> Just drop this file into WEB-INF/classes and select the LogFactory and
> Log implementation of choice.
 



commons-logging.properties
Description: Binary data
--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Commons-logging and JDK 1.4 Logger

[Pete Gieser]

Just drop this file into WEB-INF/classes and select the LogFactory and
Log
implementation of choice.

#
# commons-logging.properties
#

#---
---
# Select LogFactory:
#---
---
# Dynamically selects logging implementation class according to the
following:
#
# - Use a factory configuration attribute named
org.apache.commons.logging.Log 
#   to identify the requested implementation class. 
# 
# - Use the org.apache.commons.logging.Log system property to identify
the 
#   requested implementation class. 
#
# - If Log4J is available, return an instance of 
#   org.apache.commons.logging.impl.Log4JCategoryLog. 
#
# - If JDK 1.4 or later is available, return an instance of 
#   org.apache.commons.logging.impl.Jdk14Logger. 
#
# - Otherwise, return an instance of
org.apache.commons.logging.impl.NoOpLog. 
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.Lo
gFactoryImpl
#
# Directly selects log4j logging implementation class.
#org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.L
og4jFactory

#---
---
# Select Logging implementation class
#---
---
# Simple commons-logging implementation (uses simplelog.properties)
#org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLo
g
# Maps to a Log4J category (uses log4j.properties)
#  note: org.apache.log4j.Category is deprecated in favor of
org.apache.log4j.Logger
#  and requests for a Category object will return a Logger object.
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JCate
goryLog
# Wraps standard JDK1.4 logging mechanisms
#org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Log
ger
# Wraps jakarta-avalon-logkit
#org.apache.commons.logging.Log=org.apache.commons.logging.impl.LogKitLo
gger
# Throw away all messages, no configuration
#org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog


> -Original Message-
> From: Wendy Cameron [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, November 18, 2002 5:46 PM
> To: Struts Users Mailing List
> Subject: RE: Commons-logging and JDK 1.4 Logger
> 
> 
> So how do you configure commons logging to use the logging 
> tool of your choice?
> 
> I thought if you use apache's logging scheme you are then 
> locked into apache's logging functionality.
> 
> Regards Wendy
> 
> > -Original Message-
> > From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, November 19, 2002 9:47 AM
> > To: Struts Users Mailing List
> > Subject: Re: Commons-logging and JDK 1.4 Logger
> > 
> > 
> > Mazza, Glen R., ,CPMS wrote:
> > 
> > >Hello,
> > >
> > >I am thinking of using the JDK 1.4 Logging API directly 
> > within some of my
> > >web application classes.  Of course, Struts uses 
> > commons-logging for its
> > >"internal" messages, so I still need to configure 
> > commons-logging to use the
> > >JDK 1.4 Logging.
> > >
> > Yes - so why not just use commons-logging everywhere?  It makes you 
> > independent of any given logging implementation.  Then, if 
> you later 
> > decide you need a syslog logger (oops!  I don't think Java 
> > provides for 
> > this!) or an SMTP logger (oops!  again!) - can you say 
> daily rolling 
> > file appender? - you can just go right over to Log4J, change 
> > a couple of 
> > properties, and voila.  The fact of the matter is that 
> there is some 
> > existing functionality in the Log4J logger implementations 
> > that the JDK 
> > does not have.  Rather than paint yourself in a corner, why 
> > not just use 
> > commons-logging everywhere and be independent of your logging 
> > implementation?
> > 
> > >I am interested in using the same output logging file for 
> > both types of
> > >messages:  those I explicitly call via JDK 1.4 Logging, and 
> > those messages
> > >written by Struts via commons-logging.  Can I have them 
> > append to the *same*
> > >output log file without concern for them overwriting each 
> > other's messages?
> > >
> > I don't see how both objects could have write-access to the 
> > same file at 
> > the same time - I would think this would be problematic.  I'm 
> > not sure 
> > how the logs are implemented, but I would think they would 
> > keep the file 
> > open to speed logging.
> > 
> > >Thanks,
> > >Glen
> > >
> > -- 
> > Eddie Bush
> > 
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > 
> > For additional commands, e-mail: 
> > 
> > 
> > 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Strutstest with tiles - verifyForward behavior

[Pete Gieser]

Thanks for the reply.  As I stated in my message, I am in fact using
release 1.9, and had read the readme notes.  That's why I'm expecting
what I'm doing to work...but it don't.

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, November 18, 2002 2:16 PM
> To: Struts Users Mailing List
> Subject: RE: Strutstest with tiles - verifyForward behavior
> 
> 
> What version of StrutsTestCase are you using?
> 
> from the release 1.9 readme.txt
> 
> 
> 
> 
> New Features:
> 
> 
> 
> 
> - Added more support for Tiles plugin.  Previously, StrutsTestCase was
> relying on the deprecated ActionComponentServlet; now the code uses
> more up-to-date mechanisms for verifying Tiles forwards. 
> (MockStrutsTestCase
> and CactusStrutsTestCase)
> 
> 
> 
> Not sure if that fixes your problem, but it might be a good 
> place to start.
> 
> James Mitchell
> Software Engineer/Struts Evangelist
> http://www.open-tools.org
> 
> "If you were plowing a field, which would you rather use? Two 
> strong oxen or
> 1024 chickens?"
> - Seymour Cray (1925-1996), father of supercomputing
> 
> 
> > -Original Message-
> > From: Pete Gieser [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 18, 2002 6:36 AM
> > To: [EMAIL PROTECTED]
> > Subject: Strutstest with tiles - verifyForward behavior
> >
> >
> > Using MockStrutsCase (from release 1.9) with the following 
> test method:
> >
> > public void testManagerSuccess()
> > {
> > setRequestPathInfo("/famnet");
> > actionPerform();
> > verifyForward("success");
> > assertNotNull(getSession().getAttribute("members"));
> > verifyNoActionErrors();
> > }
> >
> > and this section from struts-config.xml:
> >
> > 
> >   
> > 
> >
> > and this section from tiles-def.xml:
> >
> >> extends="main.layout">
> > 
> > 
> >   
> >
> > I'm getting the following error:
> >
> > processActionForward(famnet.list, false)
> >   'famnet.list' - processed as definition
> > -  ---
> >
> > Testcase: testManagerSuccess took 3.636 sec
> >  FAILED
> > was expecting 'famnet.list' but received '/layout/layout.jsp'
> > junit.framework.AssertionFailedError: was expecting 
> 'famnet.list' but
> > received '/layout/layout.jsp'
> >  at servletunit.struts.Common.verifyForwardPath(Common.java:152)
> >  at
> > 
> servletunit.struts.MockStrutsTestCase.verifyForward(MockStruts
> TestCase.j
> > ava:462)
> >  at
> > 
> struts.junit.TestManagerAction.testManagerSuccess(TestManagerA
> ction.java
> > :26)
> >  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >  at
> > 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> orImpl.jav
> > a:39)
> >  at
> > 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> odAccessor
> > Impl.java:25)
> >
> > Is this a bug, or is there something else I should be doing?
> >
> > Pete
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:struts-user-> [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]>

Strutstest with tiles - verifyForward behavior

[Pete Gieser]

Using MockStrutsCase (from release 1.9) with the following test method:
 
public void testManagerSuccess()
{
setRequestPathInfo("/famnet");
actionPerform();
verifyForward("success");
assertNotNull(getSession().getAttribute("members"));
verifyNoActionErrors();
}

and this section from struts-config.xml:
 

  


and this section from tiles-def.xml:
 
  


  

I'm getting the following error:
 
processActionForward(famnet.list, false)
  'famnet.list' - processed as definition
-  ---
 
Testcase: testManagerSuccess took 3.636 sec
 FAILED
was expecting 'famnet.list' but received '/layout/layout.jsp'
junit.framework.AssertionFailedError: was expecting 'famnet.list' but
received '/layout/layout.jsp'
 at servletunit.struts.Common.verifyForwardPath(Common.java:152)
 at
servletunit.struts.MockStrutsTestCase.verifyForward(MockStrutsTestCase.j
ava:462)
 at
struts.junit.TestManagerAction.testManagerSuccess(TestManagerAction.java
:26)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
 
Is this a bug, or is there something else I should be doing?
 
Pete

RE: problem with client-side validation and ValidatorActionForm

[Pete Gieser]

I misread your configurations.  Upon further review, it looks like
you are putting the action instead of the form name in your validation
and jsp form name property.  i.e., you should have

> >   
> > 
> >   
> >   
> >   
> > 
> >   
> > 
> > 
> > The javascript output when I add  > formName="contactInfoForm"/> to my jsp starts out like this:
> > 

Pete


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: problem with client-side validation and ValidatorActionForm

[Pete Gieser]

Is it necessary to have /validateContactInfo in validation.xml and your
jsp?
(I am doing client/server validation and leave out the "/" and it works
fine)

Pete

> -Original Message-
> From: Ryan Bell [mailto:ryan@;messagecast.net] 
> Sent: Wednesday, November 06, 2002 3:07 PM
> To: [EMAIL PROTECTED]
> Subject: problem with client-side validation and ValidatorActionForm
> 
> 
> Is there any way I can do both client and server side 
> validation using ValidatorActionForms without setting up two 
> 'forms' in my validation xml?
> I'm having a problem doing client-side validation because all 
> my action mappings start with '/' and it's causing the 
> generated javascript function to have a name like 
> 'validate/xxx' which, as far as I know is not valid syntax.  
> Here's an example of my setup:
> 
> struts-config.xml:
> ...
>type="config.admin.contactinfo.ValidateContactInfoAction" 
> name="contactInfoForm" scope="request" 
> input="tile.admin.contactInfo.editContactInfo">
> 
>   
> ...
> 
> validation.xml:
> ...
>   
> 
>   
>   
>   
> 
>   
> 
> 
> The javascript output when I add  formName="/validateContactInfo"/> to my jsp starts out like this:
> 
>  To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: How to use Templates efficently ?

[Pete Gieser]

> I still can't see a reason to use tiles instead of a simple include
> file.
> 
> I mean, okay, you can easily change your entire layout. BUT -
> in return you got twice as much files!
> For each file you need a content.jsp and a content-body.jsp.

I don't think so.  The file you refer to as content.jsp, presumably
containing just your includes (header.jsp, content-body.jsp,
footer.jsp),
can be specified as a tile definition and referred to by a logical name.
Thus, all your pages can be designed in one file.

e.g. in tiles-definitions.xml:



http://jakarta.apache.org/struts/dtds/tiles-config.dtd";>



  




  



I'm somewhat of a newbie myself, but I found this javaworld article to
be
useful in describing the pros/cons of this approach.

http://www.javaworld.com/javaworld/jw-01-2002/jw-0104-tilestrut.html

Pete


--
To unsubscribe, e-mail:   
For additional commands, e-mail: