commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From EP...@upstate.com
Subject [betwixt] Strategies for roundtripping Date objects
Date Tue, 01 Apr 2003 16:04:47 GMT
Hi all,

I am using betwixt to take a basic object with lots of string parameters and
roundtrip them to XML and back.  However, I just added a java.util.Date
object, and now betwixt is erroring when it tries to pass the String
representation of the date object back in as a string.  I could add a method

public void setDate(String dateAsString)

but that seems icky.  Do I have to create a .betwixt file to deal with this?
Or, should betwixt be changed to look at my String and try and convert it to
a date if my only matching method signature takes a date.  Alternatively to
create a .betwixt file, can I do the same thing, but programatically.  I
don't really want to add yet another file for mapping.

Loving Betwixt!

Eric Pugh

-----Original Message-----
From: Richard Sitze [mailto:rsitze@us.ibm.com]
Sent: Tuesday, April 01, 2003 9:31 AM
To: Jakarta Commons Developers List
Subject: Re: [logging] Moving Towards A 1.0.3 Release


Summary: +1 on all issues

> Folks,
> 
> A lot of people are interested in an updated release of commons-logging
> that incorporates post-1.0.2 bugfixes.  In order to do so, we need to
> address the following outstanding bug reports -- I've described my own
> recommendations on dealing with them in indented paragraphs marked
> "CRM>>>" -- we need to come to consensus on the actions to take and them
> implement them in order to reach a 1.0.3 release quickly:
> 
> 
> 13201 Remove default log4j configuration
> 
>       CRM>>> I agree.  The code in Log4JLogger.initialize() violates
>       the basic scope of commons-logging, which states  "The basic
>       principle is that the user is totally responsible for the
>       configuration of the underlying logging system.  Commons-logging
>       whould not change the existing configuration."  As an alternative
>       to the application explicitly configuring things, logging
>       implementations should provide auto-configuration mechanisms
>       (for Log4J, that means recognizing the existence of the
>       "log4j.properties" resource and using it.)
> 
>       Similar code exists in the deprecated Log4JCategoryLogger class,
>       and should be removed from there as well.

+1

> 
> 
> 16880 Language specs violation in Commons Logging 1.0.2 in class
>       LogFactoryImpl
> 
>       CRM>>> I haven't investigated this one yet, but we'll want to
>       make sure we do not introduce any security-related vulnerabilities
>       in dealing with it.

+1

> 
> 
> 17561 LogFactoryImpl.guessConfig overrides configuration
> 
>       CRM>>> As the bug report points out, we currently mess up the
>       Log4J configuration even if you explicitly select SimpleLog.
>       Dealing with 13201 will fix part of that; as a further step I
>       would like to deprecate Log4jFactory and the way that it is
>       created as a proxy for the standard LogFactoryImpl.  It seems
>       to add zero value, and only obfuscates the code -- anything
>       specific that we need should be possible in the base class.
>       I'd like to see Log4jFactory removed in 1.1, because
>       LogFactoryImpl should be capable of doing everything.

+1

> 
> 
> 17894 Unable to configure commons-logging SimpleLog for a webapp
> 
>       Other than the part about getting the manifest created
>       correctly (which I've fixed), this *appears* to be a duplicate
>       of 17561.

Agreed.

> 
> What do you guys think on these issues?


*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message