Re: [beanutils] BeanUtilsBean2 vs BeanUtilsBean, ConvertUtilsBean2 vs ConvertUtilsBean

2024-09-03 Thread Gary Gregory
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  wrote:
>
> +1 for Gary's second option as well.
>
> On Sun, Sep 1, 2024 at 3:47 AM Niall Pemberton 
> wrote:
>
> > On Sat, 31 Aug 2024 at 20:45, Dávid Szigecsán  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  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



Re: [beanutils] BeanUtilsBean2 vs BeanUtilsBean, ConvertUtilsBean2 vs ConvertUtilsBean

2024-09-03 Thread Melloware Inc
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  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 
> 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 
> 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  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
==


Re: [beanutils] Thoughts on PR https://github.com/apache/commons-beanutils/pull/276

2024-09-03 Thread Gary D. Gregory
On 2024/08/31 12:44:19 Melloware Inc wrote:
> I feel like this PR is a good idea.  Just from a safety perspective and not
> accidentally logging a password.

The PR does nothing to avoid logging passwords. It only plays games when a bean 
implements toString() which might have unexpected consequences. I'm not sure.

I took another look and I'm not sure this is helpful though, and it also 
contains some global variable editing that will be problematic IMO. See my 
comments in the PR.

Gary

> 
> On Mon, Aug 26, 2024 at 5:41 PM Gary D. Gregory  wrote:
> 
> > Hi All,
> >
> > Does anyone have thoughts on PR
> > https://github.com/apache/commons-beanutils/pull/276 ?
> >
> > TY,
> > 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



Re: [beanutils] Thoughts on PR https://github.com/apache/commons-beanutils/pull/276

2024-09-03 Thread Melloware Inc
I could be wrong but his whole intent of that PR was not logging a
bean.toString() that might accidentally expose a password.  That seems to
be his entire goal.  So if there is a better way to achieve that goal is
what i think the developer was going for.

On Tue, Sep 3, 2024 at 9:52 AM Gary D. Gregory  wrote:

> On 2024/08/31 12:44:19 Melloware Inc wrote:
> > I feel like this PR is a good idea.  Just from a safety perspective and
> not
> > accidentally logging a password.
>
> The PR does nothing to avoid logging passwords. It only plays games when a
> bean implements toString() which might have unexpected consequences. I'm
> not sure.
>
> I took another look and I'm not sure this is helpful though, and it also
> contains some global variable editing that will be problematic IMO. See my
> comments in the PR.
>
> Gary
>
> >
> > On Mon, Aug 26, 2024 at 5:41 PM Gary D. Gregory 
> wrote:
> >
> > > Hi All,
> > >
> > > Does anyone have thoughts on PR
> > > https://github.com/apache/commons-beanutils/pull/276 ?
> > >
> > > TY,
> > > 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
==


Re: [beanutils] Thoughts on PR https://github.com/apache/commons-beanutils/pull/276

2024-09-03 Thread Gary D. Gregory
I appreciate the intent but this feels like bad solution. If a toString() 
method return a password, then the security issue is in the toString() IMO.

Gary

On 2024/09/03 14:18:03 Melloware Inc wrote:
> I could be wrong but his whole intent of that PR was not logging a
> bean.toString() that might accidentally expose a password.  That seems to
> be his entire goal.  So if there is a better way to achieve that goal is
> what i think the developer was going for.
> 
> On Tue, Sep 3, 2024 at 9:52 AM Gary D. Gregory  wrote:
> 
> > On 2024/08/31 12:44:19 Melloware Inc wrote:
> > > I feel like this PR is a good idea.  Just from a safety perspective and
> > not
> > > accidentally logging a password.
> >
> > The PR does nothing to avoid logging passwords. It only plays games when a
> > bean implements toString() which might have unexpected consequences. I'm
> > not sure.
> >
> > I took another look and I'm not sure this is helpful though, and it also
> > contains some global variable editing that will be problematic IMO. See my
> > comments in the PR.
> >
> > Gary
> >
> > >
> > > On Mon, Aug 26, 2024 at 5:41 PM Gary D. Gregory 
> > wrote:
> > >
> > > > Hi All,
> > > >
> > > > Does anyone have thoughts on PR
> > > > https://github.com/apache/commons-beanutils/pull/276 ?
> > > >
> > > > TY,
> > > > 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
> ==
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[beanutils] Should Commons BeanUtil types implement Serializable

2024-09-03 Thread Gary D. Gregory
Hi All,

Considering the long history of problematic Serializable implementations 
throughout the Java ecosystem, not just in Commons, I propose that no BeanUtils 
types implement Serializable in the upcoming new major version 2.0.

Instead, we would document that if you want to serialize objects, you should 
implement a serialization proxy as suggested in Effective Java by Joshua Bloch.

The alternative would be to write a large amounts of tests to insure no 
security issues occur on top of fixing all read/write security bugs like 
BEANUTILS-556 [1].

WDYT?

[1] https://issues.apache.org/jira/browse/BEANUTILS-556

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [beanutils] Should Commons BeanUtil types implement Serializable

2024-09-03 Thread Melloware Inc
+1 from me.

On Tue, Sep 3, 2024 at 12:51 PM Gary D. Gregory  wrote:

> Hi All,
>
> Considering the long history of problematic Serializable implementations
> throughout the Java ecosystem, not just in Commons, I propose that no
> BeanUtils types implement Serializable in the upcoming new major version
> 2.0.
>
> Instead, we would document that if you want to serialize objects, you
> should implement a serialization proxy as suggested in Effective Java by
> Joshua Bloch.
>
> The alternative would be to write a large amounts of tests to insure no
> security issues occur on top of fixing all read/write security bugs like
> BEANUTILS-556 [1].
>
> WDYT?
>
> [1] https://issues.apache.org/jira/browse/BEANUTILS-556
>
> -
> 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
==


Re: [beanutils] Should Commons BeanUtil types implement Serializable

2024-09-03 Thread Mike Drob
+1

Please include an example (or pseudocode) for people of a serialization
proxy, since not all readers may be familiar with Bloch or his book.

On Tue, Sep 3, 2024 at 11:54 AM Melloware Inc 
wrote:

> +1 from me.
>
> On Tue, Sep 3, 2024 at 12:51 PM Gary D. Gregory 
> wrote:
>
> > Hi All,
> >
> > Considering the long history of problematic Serializable implementations
> > throughout the Java ecosystem, not just in Commons, I propose that no
> > BeanUtils types implement Serializable in the upcoming new major version
> > 2.0.
> >
> > Instead, we would document that if you want to serialize objects, you
> > should implement a serialization proxy as suggested in Effective Java by
> > Joshua Bloch.
> >
> > The alternative would be to write a large amounts of tests to insure no
> > security issues occur on top of fixing all read/write security bugs like
> > BEANUTILS-556 [1].
> >
> > WDYT?
> >
> > [1] https://issues.apache.org/jira/browse/BEANUTILS-556
> >
> > -
> > 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
> ==
>


[validator] Collections 4

2024-09-03 Thread Josh Fenlason
I have requirements to eliminate collections3 from my project.
The latest Validator released is dependent on collections3 though.  What are 
the chances of a new Validator release that is dependent on collections4?  What 
could I do to assist with making that happen?
Thanks,
Josh.


Re: [validator] Collections 4

2024-09-03 Thread Gary Gregory
I am planning on what will likely be a new major version as we cannot break
binary compatibility. Maybe within the next few weeks.

Gary

On Tue, Sep 3, 2024, 3:10 PM Josh Fenlason
 wrote:

> I have requirements to eliminate collections3 from my project.
> The latest Validator released is dependent on collections3 though.  What
> are the chances of a new Validator release that is dependent on
> collections4?  What could I do to assist with making that happen?
> Thanks,
> Josh.
>


RE: [validator] Collections 4

2024-09-03 Thread Josh Fenlason
That is great to hear!  Is there anything I can do to assist with that?

-Original Message-
From: Gary Gregory  
Sent: Tuesday, September 3, 2024 2:53 PM
To: Commons Developers List 
Subject: Re: [validator] Collections 4


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



I am planning on what will likely be a new major version as we cannot break 
binary compatibility. Maybe within the next few weeks.

Gary

On Tue, Sep 3, 2024, 3:10 PM Josh Fenlason  
wrote:

> I have requirements to eliminate collections3 from my project.
> The latest Validator released is dependent on collections3 though.  
> What are the chances of a new Validator release that is dependent on 
> collections4?  What could I do to assist with making that happen?
> Thanks,
> Josh.
>