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
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
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 consequenc
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. Gre
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
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,
+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 ver
+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,
> >
> >
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.
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
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 no
11 matches
Mail list logo
