On 1/17/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > >On 1/17/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > >> > >> This seems like a handly utility. Clay has something similar, > PropUtils, > >> that uses the ConvertUtils. I think we could refactor to use this > >> utility. Is there a specific reason that you wanted to factor out > Commons > >> BeanUtils? > > > > > >Yes ... it seems to be the source of some memory leaks from not always > >getting cleaned up at runtime. Plus, when I develop on Windows, > >commons-beanutils.jar gets left locked a lot, meaning you have to restart > >your container to be able to do a clean rebuild. > > > >This doesn't help a lot right at the moment, because we still inherit the > >dependency from Digester and the JSF implementation if its bundled. But > >it's a step down the path of simplifying the dependency hierarchy for > Shale, > >especially in a JavaEE 5 world where the JSF implementation will already > be > >provided by the container. > > That snapped in very nicely :-)
Cool. I should, for the record, mention one other practical reason for this change ... the new ConverterHelper uses the registered by-type converters that the JSF application is using for everything else, rather than the set of BeanUtils converters that are registered separately. That would seem to meet developer expectations better than the way it was before. Along the same lines, have you looked at the > org.apache.shale.usecases.rolodex.GenericComparator? It might be a > canidate > for the core utils if we plugged in the FacesContext? I can see how you could leverage PropertyHelper here (and with that it would make a dandy utility helper class). But I don't think you actually need type conversion support, right? If so, we don't need to worry about a FacesContext. The PropertyHelper methods do not need one. >>Gary > >Craig > Gary > Craig
