RE: [validator] Collections 4

2024-09-04 Thread Gary D. Gregory 
On 2024/09/03 19:54:05 Josh Fenlason wrote:
> That is great to hear!  Is there anything I can do to assist with that?

Watch this list and test builds and release candidates when they become 
available.

You can also scan Jira and pull requests on GitHub and see if anything catches 
your eye.

Gary

> 
> -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.
> >
> 

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

[BCEL] BCELifierTestCase.testJavapCompare failure on Java 22

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

Does anyone have ideas of why the fails on Java 22?

See 
https://github.com/apache/commons-bcel/actions/runs/10672020606/job/29578793194

BCELifierTestCase.testJavapCompare:195->testClassOnPath:159 expected:

[lang][LANG-1172] Back and forth on LocaleUtils.toLocale()

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

I'd like to settle on the implementation of LocaleUtils.toLocale() one way or 
another and clearly document expectations.

What should we do?

Please see:
- https://issues.apache.org/jira/browse/LANG-1172
- https://github.com/apache/commons-lang/pull/766
- https://github.com/apache/commons-lang/pull/1271

TY!
Gary

-
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-04 Thread Peter Burka 
I agree with Gary. If an object is exposing sensitive data in its
toString() then the problem should be fixed at the source.

Peter


On Tue, Sep 3, 2024, 11:04 AM Gary D. Gregory  wrote:

> 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
>
>