Gary, I just built the SNAPSHOT locally and tested against my production scenarios and all is good!
On Tue, Sep 3, 2024 at 8:03 AM Gary Gregory <garydgreg...@gmail.com> wrote: > 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 > > -- ============================== Melloware melloware...@gmail.com http://melloware.com ==============================
