RE: java.util.Date in a Bean/ActionForm

[Matt Raible]

I've accomplished this by registering a DateConverter in a static block.

>From my BaseManager.java class:

static {
   ...
   ConvertUtils.register(new DateConverter(), Date.class);
   ...
}

DateConverter.java

public class DateConverter implements Converter {
//~ Instance fields


/** Log instance for this class */
private Log log = LogFactory.getLog(DateConverter.class);

//~ Methods


/**
 * Convert a String to a Date and a Date to a String
 *
 * @param type the class type to output
 * @param value the object to convert
 * @return object the converted object (Date or String)
 */
public final Object convert(final Class type, final Object value) {
log.debug("entered method");
// for a null value, return null
if (value == null) {
return null;
} else {
if (value instanceof String) {
log.debug("value (" + value + ") instance of
String");

try {
if
(StringUtils.isEmpty(value.toString())) {
return null;
}

return
DateUtil.convertStringToDate(value.toString());
} catch (ParseException pe) {
pe.printStackTrace();
}
} else if (value instanceof Date) {
log.debug("value (" + value + ") instance of
Date");

return DateUtil.convertDateToString((Date)
value);
}
}

throw new ConversionException("Could not convert "
  +
value.getClass().getName() + " to "
  +
type.getName() + "!");
}
}

-Original Message-
From: Cees van de Griend [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 10, 2003 2:00 PM
To: Struts Users
Subject: java.util.Date in a Bean/ActionForm


L.S.

I'm new at Struts, but I got it working.

I've an simple Bean with a java.util.Date property and the set and get
methods 
with to set/get the java.util.Date values. I've an (almost) working 
ActionForm with the same properties.

In a Action I use somthing like: 
org.apache.commons.beanutils.PropertyUtils.copyProperties(form, bean) to
copy 
all the properties from the bean to the form and forward to a JSP page to 
edit the properties in an HTML-form. So far, all is well; the date is 
displayed like '2003-09-10' in an text-field.

If I submit this page, a 'IllegalArgumentException: argument type mismatch'
is 
thrown. If I remove all the java.util.Date code, all is working as expected.

Clearly I'm doing something wrong with the java.util.Date.

What is the best way to get a date from a HTML-form to a Bean?

Regards,
Cees.

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

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

RE: java.util.date in edit form

[Jarnot Voytek Contr AU HQ/SC]

Your form bean should only deal with Strings.  Convert the string later -
either with BeanUtils or manually.  There have been a number of discussions
about why form beans should only deal with Strings - most reasons having to
do with the issue of invalid input, and the redisplaying thereof.

--
Voytek Jarnot
Quidquid latine dictum sit, altum viditur.


> -Original Message-
> From: Softwareentwicklung Hauschel
> [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 30, 2003 8:57 AM
> To: Struts Users Mailing List
> Subject: java.util.date in edit form
> 
> 
> Hey all,
> i've got an edit form, where i have to input a date.
> In my Form.java class the matching properties type is java.util.Date.
> 
> But there ist an error submitting the form -> "ServletException:
> BeanUtils.populate"
> 
> If i delete the date Field, the form/action works ;-(
> 
> How can i input a date with struts ?
> 
> Fredy
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

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

RE: java.util.date in edit form

[Ritesh Singhal]

Since it's a request parameter it will go as a String in the form bean.
So you must have date field as a String in the form bean. Later on you
can convert that to a Date object by using java.text.SimpleDateFormat
class.

Regards
Ritesh

-Original Message-
From: Softwareentwicklung Hauschel
[mailto:[EMAIL PROTECTED]] 
Sent: Thursday, January 30, 2003 8:27 PM
To: Struts Users Mailing List
Subject: java.util.date in edit form


Hey all,
i've got an edit form, where i have to input a date.
In my Form.java class the matching properties type is java.util.Date.

But there ist an error submitting the form -> "ServletException:
BeanUtils.populate"

If i delete the date Field, the form/action works ;-(

How can i input a date with struts ?

Fredy


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


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

RE: java.util.date in edit form

[Pani, Gourav]

why don't you make it a String in the form?  then use the
validator-rules.xml and validator.xml to validate if it is a date or not.
that way, if the person enters a bad date format you can redirect to the
page with the error message as well as populate the bad date into the form
as reference for the person using the application.



-Original Message-
From: Softwareentwicklung Hauschel
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 30, 2003 9:57 AM
To: Struts Users Mailing List
Subject: java.util.date in edit form


Hey all,
i've got an edit form, where i have to input a date.
In my Form.java class the matching properties type is java.util.Date.

But there ist an error submitting the form -> "ServletException:
BeanUtils.populate"

If i delete the date Field, the form/action works ;-(

How can i input a date with struts ?

Fredy


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

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

Re: java.util.Date

[Eddie Bush]

I don't think it's your fault, Max.  The docs should talk about that 
internal Calendar instance.  Knowing things like that .oO( Hrm ... if it 
just has a single internal Calendar instance, it's probably doing 
modification to it on-the-fly ...) is quite important!  If the only 
thing involved were the format, I think your apporach of moving things 
to a static initializer would have been the way to do it.  Sounds like 
that's not the way to do it though :-(

Max Kutny wrote:

EB> from javadoc on SimpleDateFormat: Synchronization

EB> Date formats are not synchronized. It is recommended to create
EB> separate format instances for each thread. If multiple threads access
EB> a format concurrently, it must be synchronized externally.

EB> ... so your concern is quite valid ... kind of.  The time I could see
EB> a problem arising would be when you are *changing* the format.

That's exactly as I understood javadoc. *formats* are not
synchronized. Since format is applyed in static code I suggested to move
SimpleDateFormat creation there. Seems I was wrong. That's javadoc
ambiguously.

Sorry all guys for confusing you.
 

--
Eddie Bush




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

Re: java.util.Date

[Max Kutny]

 EB> from javadoc on SimpleDateFormat: Synchronization

 EB> Date formats are not synchronized. It is recommended to create
 EB> separate format instances for each thread. If multiple threads access
 EB> a format concurrently, it must be synchronized externally.

 EB> ... so your concern is quite valid ... kind of.  The time I could see
 EB> a problem arising would be when you are *changing* the format.

That's exactly as I understood javadoc. *formats* are not
synchronized. Since format is applyed in static code I suggested to move
SimpleDateFormat creation there. Seems I was wrong. That's javadoc
ambiguously.

Sorry all guys for confusing you.

-- 
Max Kutny

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

Re: java.util.Date

[Kris Schneider]

No problem - it's all Rick and Antoni's fault anyway for bringing it up
:-D.

Eddie Bush wrote:
> 
> !!! Gotcha!  Ok - I can see where that might pose a serious issue!
>  Sorry for being stubborn :-)
> 
> Kris Schneider wrote:
> 
> >But the thread-safety issue really *is* with the parse and format
> >methods. The problem is that SimpleDateFormat uses a protected Calendar
> >instance field (inherited from DateFormat) to maintain state specific to
> >an invocation of both parse and format. So, multiple concurrent threads
> >entering the parse and/or format methods of a single SimpleDateFormat
> >instance are gonna tromp all over the state of that Calendar field.
> >
> 
> --
> Eddie Bush
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 
Kris Schneider 
D.O.Tech   


smime.p7s
Description: S/MIME Cryptographic Signature

Re: java.util.Date

[Eddie Bush]

!!! Gotcha!  Ok - I can see where that might pose a serious issue! 
Sorry for being stubborn :-)

Kris Schneider wrote:

But the thread-safety issue really *is* with the parse and format
methods. The problem is that SimpleDateFormat uses a protected Calendar
instance field (inherited from DateFormat) to maintain state specific to
an invocation of both parse and format. So, multiple concurrent threads
entering the parse and/or format methods of a single SimpleDateFormat
instance are gonna tromp all over the state of that Calendar field.



--
Eddie Bush





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

Re: java.util.Date

[Kris Schneider]

But the thread-safety issue really *is* with the parse and format
methods. The problem is that SimpleDateFormat uses a protected Calendar
instance field (inherited from DateFormat) to maintain state specific to
an invocation of both parse and format. So, multiple concurrent threads
entering the parse and/or format methods of a single SimpleDateFormat
instance are gonna tromp all over the state of that Calendar field.

Eddie Bush wrote:
> 
> from javadoc on SimpleDateFormat:
> 
> Synchronization
> 
> Date formats are not synchronized. It is recommended to create separate
> format instances for each thread. If multiple threads access a format
> concurrently, it must be synchronized externally.
> 
> ... so your concern is quite valid ... kind of.  The time I could see a
> problem arising would be when you are *changing* the format.  All
> methods that do not depend on instance-level variables would enjoy
> thread-safe-ness.  My suspicion is that the format and parse methods
> would rely on the pattern, which seems to be a instance variable.  So
> ... as long as you don't change the pattern you should still be fine ...
> I think.
> 
> Did I miss something else?
> 
> In other words:  Assuming you use one pattern everywhere - and assuming
> you set that pattern in the static initializer for the class using the
> SimpleDateFormat (notice that I'm basically saying that pattern is never
> modified in more than a single thread at a time), everything should be
> ... just fine.  Right?  I can't see parse and format being
> non-threadsafe assuming pattern does not change.
> 
> Now, if you wanted to be able to actually *change* the format being used
> in the middle somewhere ... you would have a possible problem :-)  Until
> you have a need to do that, you don't need to synchronize.
> 
> Kris Schneider wrote:
> 
> >Apologies if I'm misinterpreting, but I think Antoni's concern is that the
> >SimpleDateFormat's parse and format methods are not thread-safe. The creation
> >of the converters and their registration can obviously be accomplished in a
> >thread-safe manner, but if multiple threads call into parse and/or format at
> >the same time, this will cause a problem. If that's not what Antoni was
> >saying...it's still a problem ;-). Shouldn't you code a Converter's convert
> >method with the same approach to thread-safety as an Action's execute/perform
> >method? If your Converter maintains a SimpleDateFormat instance field that it
> >uses to either format or parse, it's not thread safe.
> >
> 
> --
> Eddie Bush
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 
Kris Schneider 
D.O.Tech   


smime.p7s
Description: S/MIME Cryptographic Signature

RE: java.util.Date

[Wendy Smoak]

> Several have asked about using BeanUtils.copyProperties when you are
> dealing with Dates. The default copyProperties works fine if you are
> uisng java.sql.Date but not if you want to use java.util.Date.

Rick, thanks for posting this!  I almost missed it, but caught Max's reply.

You say that the default BeanUtils.copyProperties works fie with
java.sql.Date, but I find that I still have a problem unless the user types
in the date backwards-with-dashes (2002-11-06) the way the
java.sql.Date.valueOf() method wants it.  And that's a bit much to expect of
the users.

Then again, I'm using PropertyUtils.copyProperties(), in code I swiped from
the struts-example webapp, not BeanUtils.  Should I be using BeanUtils
instead?

So... I still need to have the user type 5/1/2002 or 05/01/2002 [or 5/01/02]
or any other valid Month-Day-Year date and have a copyProperties method
manage to get it turned into a Date object.  I'm using java.sql.Date right
now, but it doesn't matter to me.

I am investigating the popup javascript calendar that was suggested
(thanks!) and also possibly a Singleton class that does nothing but talk to
the DBMS and use its native date conversions.  (It will take, for example,
'5' and turn it into May 1st of the current year-- the users are used to
that magically happening.)  Any other suggestions are gratefully accepted.

-- 
Wendy Smoak
Applications Systems Analyst, Sr.
Arizona State University PA Information Resources Management

Re: java.util.Date

[Eddie Bush]

from javadoc on SimpleDateFormat:


   Synchronization

Date formats are not synchronized. It is recommended to create separate 
format instances for each thread. If multiple threads access a format 
concurrently, it must be synchronized externally.

... so your concern is quite valid ... kind of.  The time I could see a 
problem arising would be when you are *changing* the format.  All 
methods that do not depend on instance-level variables would enjoy 
thread-safe-ness.  My suspicion is that the format and parse methods 
would rely on the pattern, which seems to be a instance variable.  So 
... as long as you don't change the pattern you should still be fine ... 
I think.

Did I miss something else?

In other words:  Assuming you use one pattern everywhere - and assuming 
you set that pattern in the static initializer for the class using the 
SimpleDateFormat (notice that I'm basically saying that pattern is never 
modified in more than a single thread at a time), everything should be 
... just fine.  Right?  I can't see parse and format being 
non-threadsafe assuming pattern does not change.

Now, if you wanted to be able to actually *change* the format being used 
in the middle somewhere ... you would have a possible problem :-)  Until 
you have a need to do that, you don't need to synchronize.

Kris Schneider wrote:

Apologies if I'm misinterpreting, but I think Antoni's concern is that the 
SimpleDateFormat's parse and format methods are not thread-safe. The creation 
of the converters and their registration can obviously be accomplished in a 
thread-safe manner, but if multiple threads call into parse and/or format at 
the same time, this will cause a problem. If that's not what Antoni was 
saying...it's still a problem ;-). Shouldn't you code a Converter's convert 
method with the same approach to thread-safety as an Action's execute/perform 
method? If your Converter maintains a SimpleDateFormat instance field that it 
uses to either format or parse, it's not thread safe.


--
Eddie Bush





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

Re: java.util.Date

[Kris Schneider]

All I meant was that there's a similarity between a single Action instance 
having multiple threads comcurrently invoke its execute/perform method and a 
single Converter instance having multiple threads concurrently invoke its 
convert method. Same deal with a single HttpServlet instance having multiple 
threads concurrently invoke its doGet/doPost methods. In each case, you really 
want to keep static and instance fields that maintain state for a given method 
invocation out of the equation. If you do make use of those fields, you have to 
provide synchronization. The downside to synchronization is that it can impact 
throughput and potentially cause deadlock.

That being said, in general I'd recommend creating a new instance instead of 
introducing synchronization. The interesting twist with SimpleDateFormat is 
that there appears to be a reported issue with excessive String creation in the 
bug report that Antoni referenced (4228335). It looked like one of the 
reviewers couldn't reproduce the results, but it's something to keep in mind.

Quoting Rick Reumann <[EMAIL PROTECTED]>:

> 
> 
> On Wednesday, November 6, 2002, 4:31:09 PM, Kris wrote:
> 
> KS> The creation of the converters and their registration can
> KS> obviously be accomplished in a thread-safe manner, but if multiple
> KS> threads call into parse and/or format at the same time, this will
> KS> cause a problem. If that's not what Antoni was saying...it's still
> KS> a problem ;-). Shouldn't you code a Converter's convert method
> KS> with the same approach to thread-safety as an Action's
> KS> execute/perform method? If your Converter maintains a
> KS> SimpleDateFormat instance field that it uses to either format or
> KS> parse, it's not thread safe.
> 
> Thank you as well Kris. I'm looking at the Struts Action
> execute/perform methods and I'm not sure how the situation is the
> same though. I'll look at them some more.
> 
> Thanks guy for bringing this thread safe issue to my attention.
> 
> 
> 
> 
> -- 
> 
> Rick
> mailto:maillist@;reumann.net
> 
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


-- 
Kris Schneider 
D.O.Tech   

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

Re: java.util.Date

[Eddie Bush]

static blocks are run with the class - right?  So it's really irrelevant 
how many instances get created - that code is run a maximum of one time 
- when the class is first loaded.

Am I wrong?

Rick Reumann wrote:

On Wednesday, November 6, 2002, 3:21:28 PM, Antoni wrote:


AR> Keep in mind that DateFormat (and SimpleDateFormat) is not thread safe so you 
AR> have to be very careful when reusing them. 

   I like Max's suggestion though. I think I will move it to the
   setFormatPattern for sure. Correct me if I'm wrong here...

   Since the registration of this Converter takes places in a static
   block in the top of my DispatchAction the setFormatPattern should
   only be called once, since isn't only once instance of my
   DispatchAction created (and thus only one initial load in the
   static block?). I guess I could be extra careful and synchronize
   setFormatPattern since I don't think that should incur too much
   overhead since in my situation I can imagine more than one
   instance of the Action class being created.


--
Eddie Bush





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

Re: java.util.Date

[Antoni Reus]

Hi,

see below ...

A Dimecres 06 Novembre 2002 11:29, Max Kutny va escriure:
>  RR> I'm posting this with a different subject line so it will hopefully
>  RR> come up in the archives if someone needs to search for it.
>
>
>  RR> public class DateBeanUtilsConverter implements Converter {
>
>  RR>   private String formatPattern = null;
>
>  RR>   public void setFormatPattern(String formatPattern) {
>  RR> this.formatPattern = formatPattern;
>  RR>   }
>
>  RR>   public Object convert(Class type, Object value) {
>  RR> Date date = null;
>
>  RR> if (value != null && (value instanceof String) && (type ==
>  RR> Date.class)) {
>  RR> try {
>
>  RR> String s = value.toString();
>  RR> SimpleDateFormat formatter =
>  RR>new SimpleDateFormat(formatPattern);
>
> It's probably better to move SimpleDateFormatter creation to
> setFormatPattern method. This would help avoid unnecessary object
> creations.
>

Keep in mind that DateFormat (and SimpleDateFormat) is not thread safe so you 
have to be very careful when reusing them. 
 

>
>  RR> date = formatter.parse(s);
>
>  RR> } catch (Exception e) {
>  RR> //log error
>  RR> }
>  RR> }
>  RR> return date;
>  RR>   }
>
>  RR> }


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

Re: java.util.Date

[Max Kutny]

 RR> I'm posting this with a different subject line so it will hopefully
 RR> come up in the archives if someone needs to search for it.


 RR> public class DateBeanUtilsConverter implements Converter {

 RR>   private String formatPattern = null;

 RR>   public void setFormatPattern(String formatPattern) {
 RR> this.formatPattern = formatPattern;
 RR>   }

 RR>   public Object convert(Class type, Object value) {
 RR> Date date = null;

 RR> if (value != null && (value instanceof String) && (type ==
 RR> Date.class)) {
 RR> try {

 RR> String s = value.toString();
 RR> SimpleDateFormat formatter =
 RR>new SimpleDateFormat(formatPattern);

It's probably better to move SimpleDateFormatter creation to
setFormatPattern method. This would help avoid unnecessary object
creations.


 RR> date = formatter.parse(s);

 RR> } catch (Exception e) {
 RR> //log error
 RR> }
 RR> }
 RR> return date;
 RR>   }

 RR> }

-- 
Max Kutny

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

RE: java.util.Date parameters...

[Jesse Alexander (KADA 12)]

Hi,

I usually do these transformations within the Action. Translating the
content of the form-beans into ValueObjects that are passed into
the model-backend which contains the business-logic. The same on
the way back (Backend generates value-objects, Action transforms into
view-model-classes (smalltalk) which then can be displayed).
I got this advice from some doc by Ted saying that the Action-class
should play the translator from the web (our frontend) to the 
business-logic (model / backend) and vice-versa.

hth
Alexander Jesse

PS: yes it creates a few objects more, but it cleanly separates the
layers

-Original Message-
From: James Carman [mailto:[EMAIL PROTECTED]]
Sent: Montag, 11. Februar 2002 22:28
To: Struts Users Mailing List
Subject: Re: java.util.Date parameters...


My point was that the business logic should not have to deal with Strings
just because Struts can't handle them.

- Original Message -
From: "Keith Bacon" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, February 11, 2002 1:22 PM
Subject: Re: java.util.Date parameters...


> How about 2 setters for in your business logic validation.
>
> setAndValidateMyDateString(String inputDateString) {
> // validate date is valid.
> // If valid call the next method to do the rest.
> }
>
> setAndValidateMyDate(Date inputDate) {..}
>
> String getMyDateDisplayFormat {}
> Date getMyDate() {}
>
> Then your GUI can send you a date or a string as it pleases & fetch the
data in either format.
> This pattern works for numbers too.
> ==
> What I was proposing below is that users type in dates in any format your
validation method can
> handle & see the dates displayed in the format determined by 1 static
method.
> Experience of dates on systems with applet/html & Swing front ends has
lead me to the conclusion
> that defining dates as Strings in java classes is really simple. Also the
simplest design is to
> have validation that can handle input Date objects & a String version of
it.
> (Don't worry you aren't the only one that doesn't believe me!).
>
> I wasn't mentioning how dates are stored on a DB, that's up to code in the
business logic (or the
> persistence layer behind it).
>
> K.
>
>
> --- James Carman <[EMAIL PROTECTED]> wrote:
> > That doesn't answer my question.  I don't want users to have to type
dates
> > in the ISO format on the web page.  I want them to be able to type
> > 02/11/2002 for today's date.  However, I also want to be able to store
this
> > string however I want (maybe as a String in ISO format or a
java.util.Date
> > object).  My design approach allows Struts to still do all of the
> > extracting/populating of the form beans, but also allows the
customization
> > of showing non-String properties in  or  tags.
> > That's all I was looking for, an automated way to bridge the gap between
> > non-String properties and Struts' auto-populate feature.
> >
> > Also, a web application should just be written as a shell around
business
> > logic.  The business logic should not have to cater to the restrictions
of a
> > web application (resorting to storing dates as strings for example).  In
> > fact, the business logic should be able to execute without a web
application
> > being present at all (if for nothing else but testing purposes).
> >
> > - Original Message -
> > From: "Keith Bacon" <[EMAIL PROTECTED]>
> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > Sent: Monday, February 11, 2002 11:45 AM
> > Subject: Re: java.util.Date parameters...
> >
> >
> > > I have a Utility class of static methods to validate & format data.
> > > 1 - To avoid unnecessary object creation for performance.
> > > 2 - Utility methods are the simplest design there is - so why have
> > anything more complicated
> > > (because we are so madly OO sometimes we forget to be simple?).
> > > Also we pass dates around as Strings (mmdd). I saw code from a big
> > bank (can't remember which
> > > one), they had gone the same way - using Strings in ISO date standard
> > format.
> > > I never found a problem with this & it seems so darn direct & simple.
I
> > used to use Date objects
> > > but gave that up.
> > >
> > > eg.
> > >  // returns error message or null if date valid.
> > > static public String validateDate(String inputDate) {..)
> > >
> > >  // after successful call to validate call this to put
> > >  // date in standard format.
> >