Hi All, The pull-up refactoring and adjusted tests are now in git master. Pease verify your use cases if any.
Gary On Sun, Sep 1, 2024 at 8:00 AM Melloware Inc <melloware...@gmail.com> wrote: > > +1 for Gary's second option as well. > > On Sun, Sep 1, 2024 at 3:47 AM Niall Pemberton <niall.pember...@gmail.com> > wrote: > > > On Sat, 31 Aug 2024 at 20:45, Dávid Szigecsán <sige...@gmail.com> wrote: > > > > > Hi, > > > > > > While I'm still getting familiar with things here, I'd like to share my > > > thoughts on this issue. In my view, version 2.0 typically signifies a > > break > > > in backward compatibility, which makes the second solution—changing the > > > supertype's behavior—acceptable. Given the existence of BeanUtilsBean2 > > and > > > ConvertUtilsBean2, it seems the plan was to modify the behavior in the > > next > > > major release (2.0). > > > > > > > The only reason the 2nd beans were added was to preserve compatibility at > > the time > > https://issues.apache.org/jira/browse/BEANUTILS-285 > > > > Original JIRA: > > https://issues.apache.org/jira/browse/BEANUTILS-258 > > > > > > > My question is whether we intend to support the "old" behavior in any > > > capacity. If so, I believe an alternative solution is necessary, rather > > > than relying on the first solution, which involves overriding methods in > > a > > > subclass. This approach might violate the SOLID principles, specifically > > > the Liskov Substitution Principle, by altering behavior in a subclass. > > > > > > > No, we should IMO remove it - there were only downsides in the old > > behaviour that limited users. The new behaviour allowed the users to > > configure whatever they want. A user could register converters which > > reproduce the old behaviour if they wanted. > > > > IMO we should definitely go with Gary's second option: > > "pull up the "2" classes's method into their respective supertype and > > adjust the tests to make the "2" behavior the _only_ behavior" > > > > Niall > > > > > > > > > > Regards, > > > David > > > > > > Gary Gregory <garydgreg...@gmail.com> ezt írta (időpont: 2024. aug. 31., > > > Szo, 20:09): > > > > > > > Hi All, > > > > > > > > I want us to decide what we want for 2.0 with the classes > > > > BeanUtilsBean2 vs BeanUtilsBean, and ConvertUtilsBean2 vs > > > > ConvertUtilsBean. > > > > > > > > For your convenience: > > > > - > > > > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/BeanUtilsBean2.java > > > > - > > > > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/BeanUtilsBean.java > > > > - > > > > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/ConvertUtilsBean2.java > > > > - > > > > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/ConvertUtilsBean.java > > > > > > > > I plan on doing a 2.0.0-M1 release in mid-September if we can resolve > > > > this and put the new package out in the wild. > > > > > > > > Possible solutions: > > > > > > > > 1) Do nothing, keep both classes and explain when to use one vs. the > > > other > > > > 2) The "simplest" change is to pull up the "2" classes's method into > > > > their respective supertype and adjust the tests to make the "2" > > > > behavior the _only_ behavior > > > > > > > > What needs addressing no matter what IMO is to remove the global > > > > variable BeanUtilsBean.BEANS_BY_CLASSLOADER. Even with class loader > > > > independence, you can still have multiple libraries and your app > > > > competing for setting and using the default. > > > > > > > > Thoughts? > > > > > > > > Gary > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > -- > ============================== > Melloware > melloware...@gmail.com > http://melloware.com > ============================== --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
