RE: java.util.Date in a Bean/ActionForm
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
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 in edit form
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
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
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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: java.util.Date
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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: java.util.Date
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 =
RRnew 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: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: java.util.Date
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 =
RRnew 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: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: java.util.Date
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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: java.util.Date
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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- Kris Schneider mailto:kris;dotech.com D.O.Tech http://www.dotech.com/ -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: java.util.Date
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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: java.util.Date
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
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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- Kris Schneider mailto:kris;dotech.com D.O.Tech http://www.dotech.com/ smime.p7s Description: S/MIME Cryptographic Signature
Re: java.util.Date
!!! 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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: java.util.Date
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: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- Kris Schneider mailto:kris;dotech.com D.O.Tech http://www.dotech.com/ smime.p7s Description: S/MIME Cryptographic Signature
RE: java.util.Date parameters...
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 html:text or html:textarea 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.
static public String stringToDate(String inputDate) {}...
Then your form bean action form business logic only have the dates
as
Strings.
A String containing a date is effectively a Date Value object, but
it's
not worth
creating a Date class to encapsulate it.
An Object should have Identity, Attributes Behaviour (said some wise
guy), a date object doesn't
really qualify.
Keith.
--- James Carman [EMAIL PROTECTED] wrote:
What is the best way to user java.util.Dates in your forms, since
the
text html tag requires a
property of type java.lang.String? I thought about creating the
following, reusable framework
