which should not be on
StringUtils to new util classes and finally remove CS StringUtils from the
codebase.
From: Rafael Weingärtner
Sent: Friday, January 12, 2018 6:59:01 AM
To: dev
Subject: Re: Which StringUtils to use?
Well, there is always other approaches
Well, there is always other approaches...If we did not use those static
loggers, this number could be greatly reduced. Most of those objects are
singletons and we could use a protected attribute in the first element of
the hierarchy.
I do not mind a PR with this number of files changes as long as
if we don't use a wrapper we get PRs like
https://github.com/apache/cloudstack/pull/2276 in the future, trying to
update logging touches 1710 files. I think we should go for the wrapper
model on these kind of utilities.
On Thu, Jan 11, 2018 at 9:59 PM, Rafael Weingärtner <
rafaelweingart...@gmail.
Wrapping would still hold code on our side. We have to get rid of code…
If we want to start removing CloudStack’s StringUtils in favor of
StringUtils from Apache, we could start creating PRs by components (java
project in Eclipse). That is manageable to do and to review. There are
about 119 classe
All, I am having second thoughts. I think we should maintain a wrapper for
string utils and pass through as much as possible to commons string utils.
A similar thing is applicable to logging. It was started at one time and a
second attempt was started to use slf4j.
I think we should encapsulate the
Certainly better to find the references and remove them if you can get
that done in a single effort.
Just a technical question: Could one not just add the Warning to the
constructor?
Might have to create a null (log warning only) constructor.
Ron
On 10/01/2018 3:58 PM, Daan Hoogland wrote:
We can add log messages to each of the methods in StringUtils but I do not
think that is a good way to go. Any method you touch you can reform or
remove anyhow.
On Wed, Jan 10, 2018 at 9:51 PM, Ron Wheeler wrote:
> Agreed about deprecation.
> A logged WARNing would be detected during testing as
Agreed about deprecation.
A logged WARNing would be detected during testing as well as at run-time.
Ron
On 10/01/2018 3:34 PM, Daan Hoogland wrote:
Ron, we could but that would only log during compile-time, not on
runtime. I am doing some analysis and commenting in Wido's ticket.
On Wed, Jan 1
Ron, we could but that would only log during compile-time, not on runtime.
I am doing some analysis and commenting in Wido's ticket.
On Wed, Jan 10, 2018 at 9:23 PM, Ron Wheeler wrote:
> Is it possible to mark it as deprecated and have it log a warning when
> used?
>
> Ron
>
>
> On 10/01/2018 2:
Is it possible to mark it as deprecated and have it log a warning when used?
Ron
On 10/01/2018 2:26 PM, Daan Hoogland wrote:
I think we could start with giving it an explicit non standard name like
CloudStackLocalStringUtils or something a little shorter. Making sure that
we prefer for these ty
I think we could start with giving it an explicit non standard name like
CloudStackLocalStringUtils or something a little shorter. Making sure that
we prefer for these types of utils to be imported from other projects.
On Wed, Jan 10, 2018 at 4:26 PM, Wido den Hollander wrote:
>
>
> On 01/10/201
On 01/10/2018 01:09 PM, Rafael Weingärtner wrote:
Instead of creating a PR for that, we could do the bit by bit job
(hopefully one day we finish the job).
Every time we see a code using ACS's StringUtils, we check if it can be
replaced by Apache's one.
Yes, but that will slip from peoples at
Instead of creating a PR for that, we could do the bit by bit job
(hopefully one day we finish the job).
Every time we see a code using ACS's StringUtils, we check if it can be
replaced by Apache's one.
On Wed, Jan 10, 2018 at 10:01 AM, Wido den Hollander wrote:
>
>
> On 01/10/2018 12:01 PM, Daa
On 01/10/2018 12:01 PM, Daan Hoogland wrote:
I'd say remove as much functionality as we can from 'our' StringUtils and
phase them out asap.
Yes, but such a PR would be invasive and would be difficult to merge and
also break a lot of other code.
It's not easy since it will touch a lot, but
+1 to what Daan's said
On Wed, Jan 10, 2018 at 9:01 AM, Daan Hoogland
wrote:
> I'd say remove as much functionality as we can from 'our' StringUtils and
> phase them out asap.
>
> On Wed, Jan 10, 2018 at 11:59 AM, Wido den Hollander
> wrote:
>
> > Hi,
> >
> > We have com.cloud.utils.StringUtils
I'd say remove as much functionality as we can from 'our' StringUtils and
phase them out asap.
On Wed, Jan 10, 2018 at 11:59 AM, Wido den Hollander wrote:
> Hi,
>
> We have com.cloud.utils.StringUtils which has a few nice functions, but
> throughout the code I also see org.apache.commons.lang.St
Hi,
We have com.cloud.utils.StringUtils which has a few nice functions, but
throughout the code I also see org.apache.commons.lang.StringUtils
They both provide about the same functionality, but which one do we prefer?
I'd say org.apache.commons.lang.StringUtils as that allows us to remove
o
17 matches
Mail list logo
