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:[EMAIL PROTECTED] 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
