• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Using java.util.date in faces-config.xml

 
Rancher
Posts: 618
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a value object with a property of java.util.Date and am trying to create an instance of the object as a managed bean in my faces-config.xml. I get an error trying to create the object if the setter expects a java.util.Date. It works fine if the setter expects a String (and I do a conversion in the setter). It also will not work if I have two setters; one that accepts a Date and one that accepts a String.

Is there a way to do this (perhaps with some conversion technique)?
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Tom!

java.util.date's "Set day/month/year" methods are deprecated, but one alternative is to use the setTime mutator, which would five you something like this:


However, the time in milliseconds since January 1 1970 isn't very user-friendly. Referencing a Calendar would seem a reasonable alternative, but unfortunately Calendar doesn't work too well in JavaBean mode.

Here's 3 options:

1. Ignore the fact that setMonth/Dayt/Year are deprecated and use those properties anyway. You'll run the risk that a future Java implementation will fail because someone finally got rid of them, though. I really don't recommend using deprecated methods, no matter how much the boss screams "Git 'R Dun!".

2. Wrap the java.util.Date with a class of your own making that DOES support either a date-string or month/day/year properties (or both). You can use a Calendar to make the translation and then inject the calendar time into the superclass value. This could, however, lead to possible cases where you actually need a Date and not something which merely has a Date superclass, so tread carefully.

3. Last, but not least, take solution 2 and create another Managed Bean to set the data, then take that bean's time property and inject it into the time property of a true java.util.Date bean.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic