[GitHub] commons-codec pull request #12: Corrected vital comment issue

[RubbaBoy]

GitHub user RubbaBoy opened a pull request:

https://github.com/apache/commons-codec/pull/12

Corrected vital comment issue



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/RubbaBoy/commons-codec patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-codec/pull/12.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #12


commit 5cb99556ac6af11474ca83b2e1c8563cf74f
Author: RubbaBoy 
Date:   2018-03-31T01:29:31Z

Corrected vital comment issue




---

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

Re: [collections] breaking changes

[Dave Brosius]

i'm not sure i follow, don't we already have breaking changes for which 
we've decided to change bump the version?



On 03/29/2018 11:00 PM, Paul King wrote:

Just to clarify, when I said "It's built with gradle and uses Ant", I
mean our build is gradle based and our call of Bridger uses Ant.
Bridger itself is built with Maven.

On Fri, Mar 30, 2018 at 12:20 PM, Paul King  wrote:

In the Groovy build we do this using Bridger
(https://github.com/dmlloyd/bridger). It's built with gradle (and uses
Ant). They have a Maven plugin but I haven't used it.

In our build we have this:

compileJava {
 doLast {
 ant.java(classname:'org.jboss.bridger.Bridger', classpath:
rootProject.configurations.tools.asPath, outputproperty: 'stdout') {
 arg(value:
"${sourceSets.main.java.outputDir.canonicalPath}/org/codehaus/groovy/runtime/DefaultGroovyMethods.class")
 }
 ant.echo('Bridger: ' + ant.properties.stdout)
 }
}

And in the relevant source file we have a small number of $$bridge
methods like this one:

public static  List withDefault$$bridge(List self, Closure init) {
 return withDefault(self, init);
}

to match the original methods we are duplicating, e.g.:

public static  ListWithDefault withDefault(List self,
Closure init) {
 // ... code here ...
}

Cheers, Paul.

On Fri, Mar 30, 2018 at 9:52 AM, Peter Burka  wrote:

This could be solved if it were possible to force javac to generate bridge
methods. There's an extension which would allow that here:
https://github.com/infradna/bridge-method-injector, but I suspect it would
complicate the build process quite a bit.

On Thu, Mar 29, 2018 at 4:48 PM sebb  wrote:


The return type is part of the method signature that Java uses to find
resolve references.

Even changing from void to non-void will cause binary incompatibility.
(Source-wise, that's fine)

On 29 March 2018 at 18:20, Gary Gregory  wrote:

Yep, that's no good. I'll revert.

Gary

On Thu, Mar 29, 2018 at 10:16 AM, Paul King 
wrote:


I haven't looked into the IteratorUtils class at all but it's easy to
show binary incompatibility when changing the return type.
Compile this "library" class:

import java.util.ArrayList;
import java.util.List;

public class Lib {
 List getMyList() {
 return new ArrayList();
 }
}

Now compile this user of the library:

import java.util.List;

public class Main {
 public static void main(String[] args) {
 doit(new Lib().getMyList());
 }

 private static void doit(List list) {
 System.out.println("list is: " + list);
 }
}


Ensure it all works:


java -cp path_to_lib Main

Should output:

List is: []

Now change the Lib class to return ArrayList instead of List and
recompile just the Lib class (i.e. importantly don't recompile Main).

Now if you try:


java -cp path_to_lib Main

you should see:

Exception in thread "main" java.lang.NoSuchMethodError:
Lib.getMyList()Ljava/util/List;
 at Main.main(Main.java:5)

Cheers, Paul.

On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory 
wrote:

Can you show how older code would not function. Aside from using

reflection.

Gary

On Thu, Mar 29, 2018, 09:03 Claude Warren  wrote:


if we are using semantic numbering would this not cause a major

revision

change as older code will no longer function?

Claude

On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory <

garydgreg...@gmail.com>

wrote:


Hi All:

Updating Commons Collections' commons-parent from version 43 to 45

causes

the build to fail due to the use of japicmp which reports:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site)

on

project commons-collections4: Error generating
japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate

report:

Breaking the build because there is at least one incompatibility:
org.apache.commons.collections4.IteratorUtils.

peekingIterator(java.util.

Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
collections4.IteratorUtils.pushbackIterator(java.util.
Iterator):METHOD_RETURN_TYPE_CHANGED
-> [Help 1]

This is caused by:

- [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator

signature to

return PushbackIterator.
- [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature

to

return PeekingIterator.

Which are reasonable changes IMO.

Does anyone object to these changes and adding exceptions to allow

japicmp

to
not fail the build?

Thank you,
Gary




--
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren


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

Re: [httpclient] Better user agent header?

[Jochen Wiedmann]

On Fri, Mar 30, 2018 at 12:20 AM, Gary Gregory  wrote:

> User-Agent: Apache-HttpClient/4.5.5 (Oracle Corporation/Java/1.8.0_162)
> Windows/10.0 (amd64)
>
> Any thoughts for or against adding this to the user agent string?

You are aware, that you can configure your own UA-String, are you?

I don't see a necessity for such a change.

Jochen

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

Re: [httpclient] Better user agent header?

[Gary Gregory]

Dang, my bad. Sorry about that.

Gary

On Fri, Mar 30, 2018 at 10:47 AM, Oliver Heger  wrote:

> Wrong mailing list, guys?
>
> Http Client is not part of Apache Commons.
>
> Oliver
>
> Am 30.03.2018 um 18:44 schrieb Mark Thomas:
> > On 30/03/18 12:22, ajs6f wrote:
> >> For at least some cases, this wouldn't be good for security.
> >
> > That is debatable.
> >
> > Providing exact version information is highly unlikely (I almost wrote
> > impossible but never say never) to create a vulnerability.
> >
> > It might make a vulnerability more obvious but if the client is
> > vulnerable, it is vulnerable whether or not the version information is
> > provided.
> >
> > Trying to hide the version information (it may be exposed indirectly
> > elsewhere) is security by obscurity which is no security at all.
> >
> >
> > The key question for me is does the client OS or Java version matter?
> > Why might this information be useful to a sever?
> >
> >
> > I do have a privacy concern. As a user I may not wish to expose my
> > choice of JRE or OS to the server.
> >
> >
> > My default position would be not to send it at all. Depending on the
> > answer to "How is this info useful?", I could be persuaded to support
> > making it optional, possibly even present by default.
> >
> > Of course, all of this is from the peanut gallery as I haven't
> > contributed to this component and am unlikely to do so any time soon.
> >
> > Mark
> >
> >
> >> I would prefer that this be configurable (via HttpClientBuilder and/or
> > system props) and not the default.
> >>
> >> ajs6f
> >>
> >>> On Mar 29, 2018, at 6:20 PM, Gary Gregory 
> wrote:
> >>>
> >>> Hi All:
> >>>
> >>> Right now, the HttpClient is of the form:
> >>>
> >>> User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_162)
> >>>
> >>> With the stack I am working with, it would be handy if the header
> reflected:
> >>>
> >>> - The Java vendor
> >>> - Operating system name and version.
> >>>
> >>> For example:
> >>>
> >>> User-Agent: Apache-HttpClient/4.5.5 (Oracle Corporation/Java/1.8.0_162)
> >>> Windows/10.0 (amd64)
> >>>
> >>> Any thoughts for or against adding this to the user agent string?
> >>>
> >>> Gary
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [httpclient] Better user agent header?

[Oliver Heger]

Wrong mailing list, guys?

Http Client is not part of Apache Commons.

Oliver

Am 30.03.2018 um 18:44 schrieb Mark Thomas:
> On 30/03/18 12:22, ajs6f wrote:
>> For at least some cases, this wouldn't be good for security.
> 
> That is debatable.
> 
> Providing exact version information is highly unlikely (I almost wrote
> impossible but never say never) to create a vulnerability.
> 
> It might make a vulnerability more obvious but if the client is
> vulnerable, it is vulnerable whether or not the version information is
> provided.
> 
> Trying to hide the version information (it may be exposed indirectly
> elsewhere) is security by obscurity which is no security at all.
> 
> 
> The key question for me is does the client OS or Java version matter?
> Why might this information be useful to a sever?
> 
> 
> I do have a privacy concern. As a user I may not wish to expose my
> choice of JRE or OS to the server.
> 
> 
> My default position would be not to send it at all. Depending on the
> answer to "How is this info useful?", I could be persuaded to support
> making it optional, possibly even present by default.
> 
> Of course, all of this is from the peanut gallery as I haven't
> contributed to this component and am unlikely to do so any time soon.
> 
> Mark
> 
> 
>> I would prefer that this be configurable (via HttpClientBuilder and/or
> system props) and not the default.
>>
>> ajs6f
>>
>>> On Mar 29, 2018, at 6:20 PM, Gary Gregory  wrote:
>>>
>>> Hi All:
>>>
>>> Right now, the HttpClient is of the form:
>>>
>>> User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_162)
>>>
>>> With the stack I am working with, it would be handy if the header reflected:
>>>
>>> - The Java vendor
>>> - Operating system name and version.
>>>
>>> For example:
>>>
>>> User-Agent: Apache-HttpClient/4.5.5 (Oracle Corporation/Java/1.8.0_162)
>>> Windows/10.0 (amd64)
>>>
>>> Any thoughts for or against adding this to the user agent string?
>>>
>>> Gary
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

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

Re: [httpclient] Better user agent header?

[Mark Thomas]

On 30/03/18 12:22, ajs6f wrote:
> For at least some cases, this wouldn't be good for security.

That is debatable.

Providing exact version information is highly unlikely (I almost wrote
impossible but never say never) to create a vulnerability.

It might make a vulnerability more obvious but if the client is
vulnerable, it is vulnerable whether or not the version information is
provided.

Trying to hide the version information (it may be exposed indirectly
elsewhere) is security by obscurity which is no security at all.


The key question for me is does the client OS or Java version matter?
Why might this information be useful to a sever?


I do have a privacy concern. As a user I may not wish to expose my
choice of JRE or OS to the server.


My default position would be not to send it at all. Depending on the
answer to "How is this info useful?", I could be persuaded to support
making it optional, possibly even present by default.

Of course, all of this is from the peanut gallery as I haven't
contributed to this component and am unlikely to do so any time soon.

Mark


> I would prefer that this be configurable (via HttpClientBuilder and/or
system props) and not the default.
> 
> ajs6f
> 
>> On Mar 29, 2018, at 6:20 PM, Gary Gregory  wrote:
>>
>> Hi All:
>>
>> Right now, the HttpClient is of the form:
>>
>> User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_162)
>>
>> With the stack I am working with, it would be handy if the header reflected:
>>
>> - The Java vendor
>> - Operating system name and version.
>>
>> For example:
>>
>> User-Agent: Apache-HttpClient/4.5.5 (Oracle Corporation/Java/1.8.0_162)
>> Windows/10.0 (amd64)
>>
>> Any thoughts for or against adding this to the user agent string?
>>
>> Gary
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [httpclient] Better user agent header?

[ajs6f]

For at least some cases, this wouldn't be good for security. I would prefer 
that this be configurable (via HttpClientBuilder and/or system props) and not 
the default.

ajs6f

> On Mar 29, 2018, at 6:20 PM, Gary Gregory  wrote:
> 
> Hi All:
> 
> Right now, the HttpClient is of the form:
> 
> User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_162)
> 
> With the stack I am working with, it would be handy if the header reflected:
> 
> - The Java vendor
> - Operating system name and version.
> 
> For example:
> 
> User-Agent: Apache-HttpClient/4.5.5 (Oracle Corporation/Java/1.8.0_162)
> Windows/10.0 (amd64)
> 
> Any thoughts for or against adding this to the user agent string?
> 
> Gary


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

[GitHub] commons-pool issue #4: POOL-337: EvictionTimer does not remove cancelled tas...

[cdeneux]

Github user cdeneux commented on the issue:

https://github.com/apache/commons-pool/pull/4
  
Hi @garydgregory,

To be able to release our product [Petals ESB](http://petals.ow2.org/), we 
wish embed this fix. We can use the official released artefact, or our own 
forked artefact.
To choose between both ways, can you tell me when you plan to merge this PR 
and when you release ? Have you everything you needed to do it ?

Regards,
Christophe


---

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