Re: Re: Why common-compress skip data by reading and discard?

[sebb]

On Fri, 24 May 2024 at 14:51, iseki zero  wrote:
>
> Thank you. It will better if we can do a detection before we call it, to
> improve the performance.

Is there a performance issue here?
If so, is it enough to be worth the effort of updating the code?

Alternatively, it would be easy to update the Javadoc to advise users
who are on Java12+ to update their code to use the new methods...


> On 2024/05/23 11:21:33 Gary Gregory wrote:
>  > Hello iseki,
>  >
>  > The Javadoc explains all of this in detail.
>  >
>  > Java 12 adds skipNBytes and IO is still based on Java 8.
>  >
>  > Gary
>  >
>  > On Thu, May 23, 2024, 6:30 AM iseki zero  wrote:
>  >
>  > > Hello,
>  > >
>  > > When I reading the code of common-compress, I found it skip data using
>  > > the `IOUtils.skip` in `commons-io` module.
>  > >
>  > > I found this method just reading the data and discard it directly. But
>  > > in JDK there's an more effeciency method `InputStream.skip` and
>  > > `InputStream.skipNBytes`.
>  > >
>  > > So why we read & discard data instead of call `skip*` directly?
>  > >
>  > > Thank you.
>  > >
>  > > iseki zero.
>  > >
>  > >
>  > > -
>  > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>  > > For additional commands, e-mail: user-h...@commons.apache.org
>  > >
>  > >
>  >
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [ANNOUNCE] Apache Commons BCEL Version 6.8.0

[sebb]

On Sat, 9 Dec 2023 at 17:06, Tamás Cservenák  wrote:
>
> Hej Gary,
>
> The "historical list of changes" is 404 for me...

It should be:

https://commons.apache.org/proper/commons-bcel/changes-report.html

It might be possible to put in a temporary redirect ...

> Thanks
> T
>
> On Sat, Dec 9, 2023 at 5:53 PM Gary Gregory  wrote:
>
> > The Apache Commons BCEL team is pleased to announce the release of
> > Apache Commons BCEL 6.8.0!
> >
> > The Byte Code Engineering Library (BCEL) is intended to give users a
> > convenient way to analyze, create, and manipulate compiled .class
> > files. Classes are represented by objects containing all the symbolic
> > information of the given class: methods, fields, and byte code
> > instructions.
> >
> > This maintenance and bug fix release requires Java 8, and was tested
> > on Java 8, 11, 17, and 21.
> >
> > Historical list of changes:
> > https://commons.apache.org/proper/commons-bcelchanges-report.html
> >
> > For complete information on Apache Commons BCEL, including
> > instructions on how to submit bug reports, patches, or suggestions for
> > improvement, see the Apache Commons BCEL website:
> >
> > https://commons.apache.org/proper/commons-bcel
> >
> > Download it from
> > https://commons.apache.org/proper/commons-bcel/download_bcel.cgi
> >
> > Have fun!
> > Gary Gregory
> > -Apache Commons BCEL team
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >

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

Re: [io] Encoding bug in XmlStreamReader in Commons IO 2.14.0?

[sebb]

On Tue, 3 Oct 2023 at 22:17, Laurence Gonsalves
 wrote:
>
> On Tue, Oct 3, 2023 at 1:50 PM sebb  wrote:
> > > Given this inconsistency, and the fact that there are XML documents "in 
> > > the
> > > wild" that use these encoding names, would it be reasonable to relax the 
> > > regex
> > > just enough so that it'll work with these other names and aliases?
> >
> > I would say yes.
> >
> > I'm currently working on a test to check that all charsets *and
> > aliases* can be matched, and on a fix to the RE.

Test and fix have been committed.

> Excellent! Thank you!

Thank you for raising the issue.

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

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

Re: [io] Encoding bug in XmlStreamReader in Commons IO 2.14.0?

[sebb]

Created https://issues.apache.org/jira/browse/IO-815

On Tue, 3 Oct 2023 at 21:49, sebb  wrote:
>
> On Tue, 3 Oct 2023 at 21:35, Laurence Gonsalves
>  wrote:
> >
> > Thank you. My git bisect just found this change too. :-)
> >
> > We are processing documents that we have no control over, and some may use
> > these numeric encodings, so we can't update the documents.
> >
> > Looking at the XML spec
> > (https: //www.w3.org/TR/2008/REC-xml-20081126/#NT-EncName), it does say...
> >
> >EncName   ::=   [A-Za-z] ([A-Za-z0-9._] | '-')*
> >
> > ...and I assume that that's why the regex in XmlStreamReader was changed.
>
> That would explain the somewhat convoluted RE.
>
> > However, the same part of the XML spec also says...
> >
> > > It is recommended that character encodings registered (as charsets) with 
> > > the
> > > Internet Assigned Numbers Authority [IANA-CHARSETS], other than those just
> > > listed, be referred to using their registered names; other encodings 
> > > should
> > > use names starting with an "x-" prefix.
> >
> > ...and "IANA-CHARSETS" links to
> > http://www.iana.org/assignments/character-sets/character-sets.xhtml
> > which has a table of character sets. In that table there are three columns 
> > of
> > possible codes for referring to charsets: "Preferred MIME", "Name", and
> > "Aliases". The "Aliases" column includes "437" (that's also where "cp437" 
> > can
> > be found).
> >
> > This seems like a bit of an inconsistency in the XML spec, as there are a
> > number of "Name" and "Alias" values that don't quite match the definition of
> > EncName.
>
> Indeed.
> There are also examples such as ISO_8859-1:1987 and ebcdic-de-273+euro
>
> > Given this inconsistency, and the fact that there are XML documents "in the
> > wild" that use these encoding names, would it be reasonable to relax the 
> > regex
> > just enough so that it'll work with these other names and aliases?
>
> I would say yes.
>
> I'm currently working on a test to check that all charsets *and
> aliases* can be matched, and on a fix to the RE.
>
> >
> > On Tue, Oct 3, 2023 at 12:24 PM sebb  wrote:
> > >
> > > Just had another look at the class: in 2.13, the regex for matching
> > > the encoding string was
> > > Pattern.compile("<\\?xml.*encoding[\\s]*=[\\s]*((?:\".[^\"]*\")|(?:'.[^']*'))",
> > > Pattern.MULTILINE);
> > >
> > > In 2.14, the pattern includes the following matching for the encoding:
> > > "encoding\\s*=\\s*((?:\"[A-Za-z]([A-Za-z0-9\\._]|-)*\")|(?:'[A-Za-z]([A-Za-z0-9._]|-)*'))",
> > >
> > > This does not allow for an encoding that starts with a digit; i.e. it
> > > won't match encoding='437'
> > >
> > > AFAICT, no supported encodings start with a digit.
> > >
> > > The '437' encoding is actually known as 'Cp437':
> > > https://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html
> > > https://docs.oracle.com/en/java/javase/17/intl/supported-encodings.html
> > >
> > > Try using 'Cp437' as the encoding.
> > >
> > > On Tue, 3 Oct 2023 at 20:01, sebb  wrote:
> > > >
> > > > On Tue, 3 Oct 2023 at 18:05, Laurence Gonsalves
> > > >  wrote:
> > > > >
> > > > > On Tue, Oct 3, 2023 at 1:39 AM sebb  wrote:
> > > > > >
> > > > > > The byte input stream does not carry any encoding information, so 
> > > > > > the
> > > > > > XmlStreamReader has to guess what encoding was used.
> > > > >
> > > > > Determining what encoding to use when reading XML from a byte stream
> > > > > is the purpose of XmlStreamReader. From its documentation: "Character
> > > > > stream that handles all the necessary Voodoo to figure out the charset
> > > > > encoding of the XML document within the stream."
> > > > >
> > > > > What it's supposed to do in this case is use the "encoding='437'" from
> > > > > the input to determine that the Charset to use when decoding the byte
> > > > > stream is "437" (aka "code page 437").
> > > >
> > > > Sorry, I completely overlooked that.
> > > >
> > > > > -
> > > > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: user-h...@commons.apache.org
> > > > >
> > >
> > > -
> > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: user-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >

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

Re: [io] Encoding bug in XmlStreamReader in Commons IO 2.14.0?

[sebb]

On Tue, 3 Oct 2023 at 21:35, Laurence Gonsalves
 wrote:
>
> Thank you. My git bisect just found this change too. :-)
>
> We are processing documents that we have no control over, and some may use
> these numeric encodings, so we can't update the documents.
>
> Looking at the XML spec
> (https: //www.w3.org/TR/2008/REC-xml-20081126/#NT-EncName), it does say...
>
>EncName   ::=   [A-Za-z] ([A-Za-z0-9._] | '-')*
>
> ...and I assume that that's why the regex in XmlStreamReader was changed.

That would explain the somewhat convoluted RE.

> However, the same part of the XML spec also says...
>
> > It is recommended that character encodings registered (as charsets) with the
> > Internet Assigned Numbers Authority [IANA-CHARSETS], other than those just
> > listed, be referred to using their registered names; other encodings should
> > use names starting with an "x-" prefix.
>
> ...and "IANA-CHARSETS" links to
> http://www.iana.org/assignments/character-sets/character-sets.xhtml
> which has a table of character sets. In that table there are three columns of
> possible codes for referring to charsets: "Preferred MIME", "Name", and
> "Aliases". The "Aliases" column includes "437" (that's also where "cp437" can
> be found).
>
> This seems like a bit of an inconsistency in the XML spec, as there are a
> number of "Name" and "Alias" values that don't quite match the definition of
> EncName.

Indeed.
There are also examples such as ISO_8859-1:1987 and ebcdic-de-273+euro

> Given this inconsistency, and the fact that there are XML documents "in the
> wild" that use these encoding names, would it be reasonable to relax the regex
> just enough so that it'll work with these other names and aliases?

I would say yes.

I'm currently working on a test to check that all charsets *and
aliases* can be matched, and on a fix to the RE.

>
> On Tue, Oct 3, 2023 at 12:24 PM sebb  wrote:
> >
> > Just had another look at the class: in 2.13, the regex for matching
> > the encoding string was
> > Pattern.compile("<\\?xml.*encoding[\\s]*=[\\s]*((?:\".[^\"]*\")|(?:'.[^']*'))",
> > Pattern.MULTILINE);
> >
> > In 2.14, the pattern includes the following matching for the encoding:
> > "encoding\\s*=\\s*((?:\"[A-Za-z]([A-Za-z0-9\\._]|-)*\")|(?:'[A-Za-z]([A-Za-z0-9._]|-)*'))",
> >
> > This does not allow for an encoding that starts with a digit; i.e. it
> > won't match encoding='437'
> >
> > AFAICT, no supported encodings start with a digit.
> >
> > The '437' encoding is actually known as 'Cp437':
> > https://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html
> > https://docs.oracle.com/en/java/javase/17/intl/supported-encodings.html
> >
> > Try using 'Cp437' as the encoding.
> >
> > On Tue, 3 Oct 2023 at 20:01, sebb  wrote:
> > >
> > > On Tue, 3 Oct 2023 at 18:05, Laurence Gonsalves
> > >  wrote:
> > > >
> > > > On Tue, Oct 3, 2023 at 1:39 AM sebb  wrote:
> > > > >
> > > > > The byte input stream does not carry any encoding information, so the
> > > > > XmlStreamReader has to guess what encoding was used.
> > > >
> > > > Determining what encoding to use when reading XML from a byte stream
> > > > is the purpose of XmlStreamReader. From its documentation: "Character
> > > > stream that handles all the necessary Voodoo to figure out the charset
> > > > encoding of the XML document within the stream."
> > > >
> > > > What it's supposed to do in this case is use the "encoding='437'" from
> > > > the input to determine that the Charset to use when decoding the byte
> > > > stream is "437" (aka "code page 437").
> > >
> > > Sorry, I completely overlooked that.
> > >
> > > > -
> > > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: user-h...@commons.apache.org
> > > >
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [io] Encoding bug in XmlStreamReader in Commons IO 2.14.0?

[sebb]

Although the pages I linked don't mention them, it turns out that
there is actually an alias '437', also many other numeric ones.

Indeed there are other aliases that start with a letter but otherwise
don't match the RE.
e.g. ISO_8859-1:1987
So it seems the updated RE is indeed too restrictive.

Sorry for the confusion.

On Tue, 3 Oct 2023 at 20:22, sebb  wrote:
>
> Just had another look at the class: in 2.13, the regex for matching
> the encoding string was
> Pattern.compile("<\\?xml.*encoding[\\s]*=[\\s]*((?:\".[^\"]*\")|(?:'.[^']*'))",
> Pattern.MULTILINE);
>
> In 2.14, the pattern includes the following matching for the encoding:
> "encoding\\s*=\\s*((?:\"[A-Za-z]([A-Za-z0-9\\._]|-)*\")|(?:'[A-Za-z]([A-Za-z0-9._]|-)*'))",
>
> This does not allow for an encoding that starts with a digit; i.e. it
> won't match encoding='437'
>
> AFAICT, no supported encodings start with a digit.
>
> The '437' encoding is actually known as 'Cp437':
> https://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html
> https://docs.oracle.com/en/java/javase/17/intl/supported-encodings.html
>
> Try using 'Cp437' as the encoding.
>
> On Tue, 3 Oct 2023 at 20:01, sebb  wrote:
> >
> > On Tue, 3 Oct 2023 at 18:05, Laurence Gonsalves
> >  wrote:
> > >
> > > On Tue, Oct 3, 2023 at 1:39 AM sebb  wrote:
> > > >
> > > > The byte input stream does not carry any encoding information, so the
> > > > XmlStreamReader has to guess what encoding was used.
> > >
> > > Determining what encoding to use when reading XML from a byte stream
> > > is the purpose of XmlStreamReader. From its documentation: "Character
> > > stream that handles all the necessary Voodoo to figure out the charset
> > > encoding of the XML document within the stream."
> > >
> > > What it's supposed to do in this case is use the "encoding='437'" from
> > > the input to determine that the Charset to use when decoding the byte
> > > stream is "437" (aka "code page 437").
> >
> > Sorry, I completely overlooked that.
> >
> > > -
> > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: user-h...@commons.apache.org
> > >

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

Re: [io] Encoding bug in XmlStreamReader in Commons IO 2.14.0?

[sebb]

Just had another look at the class: in 2.13, the regex for matching
the encoding string was
Pattern.compile("<\\?xml.*encoding[\\s]*=[\\s]*((?:\".[^\"]*\")|(?:'.[^']*'))",
Pattern.MULTILINE);

In 2.14, the pattern includes the following matching for the encoding:
"encoding\\s*=\\s*((?:\"[A-Za-z]([A-Za-z0-9\\._]|-)*\")|(?:'[A-Za-z]([A-Za-z0-9._]|-)*'))",

This does not allow for an encoding that starts with a digit; i.e. it
won't match encoding='437'

AFAICT, no supported encodings start with a digit.

The '437' encoding is actually known as 'Cp437':
https://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html
https://docs.oracle.com/en/java/javase/17/intl/supported-encodings.html

Try using 'Cp437' as the encoding.

On Tue, 3 Oct 2023 at 20:01, sebb  wrote:
>
> On Tue, 3 Oct 2023 at 18:05, Laurence Gonsalves
>  wrote:
> >
> > On Tue, Oct 3, 2023 at 1:39 AM sebb  wrote:
> > >
> > > The byte input stream does not carry any encoding information, so the
> > > XmlStreamReader has to guess what encoding was used.
> >
> > Determining what encoding to use when reading XML from a byte stream
> > is the purpose of XmlStreamReader. From its documentation: "Character
> > stream that handles all the necessary Voodoo to figure out the charset
> > encoding of the XML document within the stream."
> >
> > What it's supposed to do in this case is use the "encoding='437'" from
> > the input to determine that the Charset to use when decoding the byte
> > stream is "437" (aka "code page 437").
>
> Sorry, I completely overlooked that.
>
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >

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

Re: [io] Encoding bug in XmlStreamReader in Commons IO 2.14.0?

[sebb]

On Tue, 3 Oct 2023 at 18:05, Laurence Gonsalves
 wrote:
>
> On Tue, Oct 3, 2023 at 1:39 AM sebb  wrote:
> >
> > The byte input stream does not carry any encoding information, so the
> > XmlStreamReader has to guess what encoding was used.
>
> Determining what encoding to use when reading XML from a byte stream
> is the purpose of XmlStreamReader. From its documentation: "Character
> stream that handles all the necessary Voodoo to figure out the charset
> encoding of the XML document within the stream."
>
> What it's supposed to do in this case is use the "encoding='437'" from
> the input to determine that the Charset to use when decoding the byte
> stream is "437" (aka "code page 437").

Sorry, I completely overlooked that.

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

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

Re: [io] Encoding bug in XmlStreamReader in Commons IO 2.14.0?

[sebb]

The byte input stream does not carry any encoding information, so the
XmlStreamReader has to guess what encoding was used.

I'm surprised that it ever worked reliably.

On Tue, 3 Oct 2023 at 09:13, Laurence Gonsalves  wrote:
>
> Hello,
>
> It looks like XmlStreamReader is not correctly handling several encodings
> in Commons IO 2.14.0 that previously worked in version 2.13.0.
>
> Here's a self-contained snippet (Kotlin) that demonstrates the problem:
>
> val xml = "Ç"
>
> val stream = xml.byteInputStream(Charset.forName("437"))
>
> val reader = XmlStreamReader.builder()
> .setInputStream(stream)
> .setLenient(false)
> .get()
>
> reader.readText() shouldBe xml
>
> With 2.13.0 this code works fine, but in 2.14.0 the "Ç" (C-cedilla) becomes
> a "�" (Unicode replacement character).
>
> We're seeing similar issues with all of the other code page encodings we've
> tried (850, 852, 855, 857, 860, 861, 862, 863, 865, and 866).

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

Re: Issue: Commons list page DbUtils 1.8 still point release date to 1.7 release date

[sebb]

On Sat, 19 Aug 2023 at 11:25, sharedata  wrote:
>
> Nice to seeApache Commons DbUtils1.8.0 release, Thanks to all the 
> developers.
>
>
> DbUtils1.8.0 release date is 2023-08-01, not 2017-07-20.
>
>
> See:
>
> https://commons.apache.org/

Thanks for the report.

The issue is that the Maven Central version button is derived from
Maven itself, so is updated automatically, whereas the date is taken
from a separately maintained data file, and may relate to a different
version. In this case, 1.7. Note that if you click on the Maven link,
it will take you to version 1.7.

The page really needs a rethink.

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

Re: Commons bsf

[sebb]

On Wed, 1 Feb 2023 at 00:22, Alex O'Ree  wrote:
>
> No problem. There was some activity on github.

Please note: That does not mean the component is being developed.
Dependabot runs on most components, and that generates traffic.
Also there may need to be changes to asf.yaml which affect all
components on github.
Etc. This is no indication that the component is being actively
maintained, as such changes need very little (if any) knowledge of the
component.

> I ran the owasp dependency
> check thing against it and found a few issues, attempted to update some of
> the dependencies (jython) and hit a bit of a snag. I'm not entirely sure
> where to go from here. I'm not sure if anyone else has attempted this or
> not.

Note that the component has a separate 3.x version, which is based on
JSR-223 - see https://commons.apache.org/proper/commons-bsf/

I’m not entirely sure that either are still needed.

> On Tue, Jan 31, 2023 at 6:34 PM Gary Gregory  wrote:
>
> > This is an open source project, so support is as best as us volunteers see
> > fit or have itches to scratch ;-)
> >
> > In this case the lack of activity might show that the original authors
> > could have abandoned the component. Let's see how else pipes in.
> >
> > Gary
> >
> > On Tue, Jan 31, 2023, 17:21 Alex O'Ree  wrote:
> >
> > > Is the bsf library still supported? Looks like the website hasn't been
> > > published since 2011.
> > >
> >

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

Re: [Text & Collections] sha512 issue?

[sebb]

On Fri, 30 Dec 2022 at 16:55, Gilles Sadowski  wrote:
>
> Le ven. 30 déc. 2022 à 17:29, Gary Gregory  a écrit :
> >
> > That's the download page, not what you are downloading. What URL are
> > you actually using for the files.
>
> I confirm that
>   
> https://dlcdn.apache.org//commons/collections/binaries/commons-collections4-4.4-bin.tar.gz
> does not match the checksum in
>   
> https://www.apache.org/dist/commons/collections/binaries/commons-collections4-4.4-bin.tar.gz.sha512
> (both links taken from the "download_collections.cgi" page).

Works OK for me; I get sha512 of

678068a958aed983926a8852b25470ab1dcce637856f85e3b3f07fae28b25da6f2326b87d123395c4f531abfc88b74f847dbcaba9a71824adab6d52ca2568395


> Gilles
>
> >
> > Gary
> >
> > On Fri, Dec 30, 2022 at 11:26 AM  wrote:
> > >
> > > Hi Gary,
> > >
> > > I use the links for the binaries (tar.gz) at:
> > > https://commons.apache.org/proper/commons-collections/download_collections.cgi
> > > https://commons.apache.org/proper/commons-text/download_text.cgi
> > >
> > >
> > > > On Dec 30, 2022, at 4:13 AM, Gary Gregory  
> > > > wrote:
> > > >
> > > > Hello Pete,
> > > >
> > > > What are the URLs you are downloading?
> > > >
> > > > Gary
> > > >
> > > > On Thu, Dec 29, 2022, 22:57  wrote:
> > > >
> > > >> I downloaded (multiple times) the two subject bin archives and did a
> > > >> sha-512 check. They did not check. Others, like math, checked 
> > > >> correctly.
> > > >> Is there an issue with those archives? Thanks.
> > > >>
> > > >> Regards
> > > >> Pete
> > > >>
> > > >> PS I do a pgp verification on the signatures but don’t have them 
> > > >> trusted
> > > >> in my keyring so I like to check the sha signatures.
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: Compatibility with RHEL8.6

[sebb]

On Fri, 9 Dec 2022 at 09:56, Gilles Sadowski  wrote:
>
> Hello.
>
> Le ven. 9 déc. 2022 à 09:27, Prince Sonu (EXT)
>  a écrit :
> >
> > Hello Team
> > Can you Please let me know that Apache XML Commons version 1.0.b2

As far as I can tell, there is no such component in Apache Commons.

Did you mean Apache Xerces XML Commons?
https://xerces.apache.org/xml-commons/

If so, the current release appears to be 1.4.01 according to
https://xerces.apache.org/mirrors.cgi

I suggest you contact the Xerces project with any further issues.

> >
> >
> > is Compatibility with RHEL8.6 or not, if no then Please tell me which 
> > version Support RHEL 8.6.
>
> I don't know what "compatibility" means here.
> The ASF provides source code (Java code in the case of the "Commons" project),
> so you can compile it on any computer/system/distribution of your choice as 
> long
> as there is a Java compiler installed.
>
> Regards,
> Gilles
>
> >
> >
> > Thanks
> > Prince Kr Sonu
> >
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: GC issues after upgrading from 1.8 to 1.10

[sebb]

On Thu, 17 Nov 2022 at 15:40, Alex Herbert  wrote:
>
> On Thu, 17 Nov 2022 at 13:34, Gilles Sadowski  wrote:
> >
> > Hello.
> >
> > Le jeu. 17 nov. 2022 à 13:38, Pavel Belousov
> >  a écrit :
> > >
> > > [...]
> > >
> > > As I cannot sign up for your jira, [...]
> >
> > What do you mean?
>
> Recent changes by Infra to prevent spam have blocked user sign-up to
> Jira. An account can be created using:
>
> https://selfserve.apache.org/
>
> I believe this must be done by a PMC member. However I cannot find an
> announcement from Infra on this subject. The change was meant to
> happen around the start of November.

FTR: There are details on Jira itself, but unfortunately not on the
page which users are most likely to see.
I have raised https://issues.apache.org/jira/browse/INFRA-23918 to get
this fixed.

> Pavel, we can create an account for you on Jira so you can create a
> ticket. This will allow you to be notified of changes on the issue.
> Would you like an account, and if so what username would you choose?
>
> Regards,
>
> Alex
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: Vulnerability Impact Assessment for PA VMT-8353 - Apache Commons Text v1.5 - 1.10.0

[sebb]

On Mon, 7 Nov 2022 at 13:46, Erna Banchik  wrote:
>
> Hi,
>
> I would like to know if the new vulnerability for PA VMT-8353 on Apache 
> Commons Text v1.5 - 1.10.0 also impacts Apache Directory Studio.
>
> We're using Apache Directory Studio and I would like to know if this 
> vulnerability related to Apache Commons Text is impacting us.
>

Please ask on the Directory Studio user mailing list:

https://directory.apache.org/mailing-lists-and-irc.html


> Thanks,
> Erna
>
>
> Internal

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

Re: UrlValidator

[sebb]

On Tue, 9 Aug 2022 at 23:34, Anirudh Aggarwal  wrote:
>
> Is UrlValidator of org.apache.commons.validator.routines is thread safe or
> not ?!

It looks like it does not have any mutable state, so it should be.

> Thanks
> Anirudh Aggarwal

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

Re: [dbutils] Please update commons-dbutils 1.8 in Maven central repo

[sebb]

On Sat, 26 Mar 2022 at 02:30, Liu, Yufei (Eric)  wrote:
>
> Hi,
>
> I went through the list further, it looks like on Mar 2020, Gary was
> trying to look into this release again[1].
> It's quite understandable that activities were all slwed down in the
> past 2 years.
>
> But the library's released version is not stable.
> And by looking into the code, even without custom ColumnHandler, the
> ConcurrentModificationException is still there because the existing
> ColumnHandlers are loaded via ServiceLoader.
>
> So any effort to bring this library back to a stable state is highly
> appreciated.

You can perhaps help with that, by testing against the 1.8-RC2 build.
(It is still available, but it is not a formal release, so I won't
publish the link on the user list)

> [1] https://lists.apache.org/thread/yojc0bob6lhwc0rbywhjkbmc0x9p7q9h
>
> Eric Liu
>
> On 3/24/22 23:00, Liu, Yufei (Eric) wrote:
> > Hi,
> >
> > I went through the discussion in the dev list and found the RC2 vote.
> > It looks like RC2 needs two votes to release and got one. And the
> > branch is still on git.
> >
> > The last message[1] which may lead to a vote was from Gary.
> >
> > So is it possible to still review the 1.8 RC2 release and give it a go?
> > Then this project can move onto 2.x development.
> >
> > [1]https://lists.apache.org/thread/t48txmrppbb5xov7k7q9ohcc04o2n09k
> >
> > Thanks,
> >
> > Eric Liu
> >
> > On 3/24/22 18:09, William Speirs wrote:
> >> https://github.com/wspeirs/sop4j-dbutils - if anyone is interested. It
> >> hasn't been touched in a long while.
> >>
> >> Bill-
> >>
> >> On Thu, Mar 24, 2022, 6:01 PM William Speirs  wrote:
> >>
> >>> 2.0 was started by me LONG ago, but will probably never see the
> >>> light-of-day for various reasons. There was a 2.0-style release
> >>> under my
> >>> GitHub, but it's failing to load at the moment.
> >>>
> >>> If someone wants to work on this, 1.8 is the place to start.
> >>>
> >>> Bill-
> >>>
> >>> On Thu, Mar 24, 2022, 5:54 PM Gary Gregory 
> >>> wrote:
> >>>
>  I do not think you should expect any immediate release. I do not
>  know the
>  state of the 2.0 snapshot.
> 
>  Gary
> 
>  On Thu, Mar 24, 2022, 14:51 Liu, Yufei (Eric)  wrote:
> 
> > Thanks Gary and Bruno for the prompt response.
> >
> > My situation is that I just encountered the
> > ConcurrentModificationException in my production deployment.
> > And I am afraid that it would happen again.
> >
> > I am willing to help release the maven if possible. But I don't think
> > this is allowed?
> > And if 2.0 can be released, I believe it should also help.
> >
> > The ConcurrentModificationException could happen on any project using
> > customized ColumnHandler which (I think) is not that uncommon.
> >
> > Thanks again,
> >
> > Eric Liu
> >
> > On 3/24/22 17:41, Gary Gregory wrote:
> >> The POM shows 2.0-SNAPSHOT so I am guessing there will not be a 1.8.
> >>
> >> Gary
> >>
> >> On Thu, Mar 24, 2022, 14:39 Bruno P. Kinoshita
> >>  wrote:
> >>
> >>>Hi Eric,
> >>> The master branch has been updated but not released yet. I saw a
>  1.8RC2
> >>> tag, so I think a vote might have been cancelled/postponed due to
>  some
> >>> issues.
> >>> You can use the latest version until 1.8 is released. Since the
> >>> whole
> >>> Apache Commons is run by volunteers, the next release depends on
>  someone
> >>> have time to read the archives, see why RC2 was not released,
> >>> then go
> > over
> >>> recent activity, check what else needs to be done, and prepare a
> >>> RC3.
> >>> Cheers
> >>> Bruno
> >>>
> >>>   On Friday, 25 March 2022, 09:56:19 am NZDT, Liu, Yufei
> >>> (Eric) <
> >>> e...@hnws.me> wrote:
> >>>
> >>>Hi,
> >>>
> >>> I noticed that on Github[1], commons-dbutils mentioned a 1.8
> >>> release
>  in
> >>> README.md .
> >>> But in the maven central repo, the version is not published. And
> >>> the
> >>> version 1.8 is also not on the download page.
> >>> According to release notes[4]: in version 1.8, a
> >>> ConcurrentModificationException was fixed in DBUTILS-135. I believe
>  this
> >>> is quite important.
> >>>
> >>> Would you please release version 1.8 into release channels
> >>> including
> > maven?
> >>> [1] https://github.com/apache/commons-dbutils
> >>> [2]
>  https://mvnrepository.com/artifact/commons-dbutils/commons-dbutils
> >>> [3] https://github.com/apache/commons-dbutils/pull/3
> >>> [4]
> >>>
>  https://github.com/apache/commons-dbutils/blob/master/RELEASE-NOTES.txt
> 
> >>> --
> >>> Eric Liu
> >>>
> >>>
> >>> -
> >>>
> >>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> 

Re: [External] : Re: [io] Regarding CVE-2021-29425: APACHE COMMONS IO UPDATE

[sebb]

AFAICT the CVE relates to FileNameUtils.normalize.

I suggest you compare the current code with the code in 2.6 and apply
any changes.

You can also look through the Github commit log for changes relating
to the file that contains the method.


On Fri, 17 Dec 2021 at 14:14, Gary Gregory  wrote:
>
> Hello Ravi,
>
> It is technically possible but I personally do not want to take the time to
> dig the repository on your behalf. I am sorry but I have other
> priorities right now.
>
> Gary
>
>
>
> On Fri, Dec 17, 2021, 05:10 Ravi Yelamarthy 
> wrote:
>
> > Hi Gary,
> >
> >
> >
> > Thanks for your mail.
> >
> >
> >
> > In almost all versions of our Product we have upgraded commons-io to
> > v2.11.0 which is latest. We have couple of old versions of our product
> > where we still support Java7 and here we need CVE-2021-29425 to be fixed in
> > commons-io.
> >
> >
> >
> > We can see that commons-io 
> > v2.6 is the last release which is based on Java7.
> >
> >
> >
> > We would like to do the below and need your little help here:
> >
> >
> >
> > We would like to download commons-io v2.6 source
> >  and apply
> > CVE-2021-29425 changes to it and build (using java7) the library ourselves
> > and use it. Before using it we have an official process to get approvals to
> > use it which we will be doing.
> >
> >
> >
> > Normally we follow this process to libraries for which we use and if there
> > is no official release for more than 2 years. In such cases, we absorb the
> > source of that library, maintain it and fix any of the CVE’s reported in it
> > and use.
> >
> >
> >
> > Can we get the github link for changes to CVE-2021-29425? Preferably from
> > v2.7 branch so that it will be easy for us to port the changes to v2.6 for
> > our usage.
> >
> >
> >
> > Is this possible?
> >
> >
> >
> > Thanks and Regards,
> >
> > Ravi.
> >
> >
> >
> > *From:* Gary Gregory [mailto:garydgreg...@gmail.com]
> > *Sent:* Monday, December 13, 2021 5:47 PM
> > *To:* Commons Users List 
> > *Cc:* Ravi Yelamarthy 
> > *Subject:* [External] : Re: [io] Regarding CVE-2021-29425: APACHE COMMONS
> > IO UPDATE
> >
> >
> >
> > Hello Surendra,
> >
> >
> >
> > You will need to update to Commons IO 2.7 or later, the current version is
> > 2.11.0.
> >
> >
> >
> > Commons IO 2.4 is based on Java 6, see
> > https://commons.apache.org/proper/commons-io/
> > 
> > for which version requires which Java version.
> >
> >
> >
> > There is no currently planned support for old versions of Commons IO based
> > on Java 6 or 7.
> >
> >
> >
> > Gary
> >
> >
> >
> >
> >
> > On Mon, Dec 13, 2021 at 6:08 AM Surendra Pulukuri <
> > surendra.puluk...@oracle.com> wrote:
> >
> > Hi Team,
> >
> > As per this security vulnerability CVE-2021-29425, we are using commons-io
> > v2.4 as a 3rd party application in our code base (Java1.7 compatible), to
> > move to latest version of commons-io where the security vulnerability
> > CVE-2021-29425 has fixed starting from v2.7 OR v2.11.0 both are Java 1.8
> > compatible.
> >
> > Is there any way to use v2.6(the final version commons-io which is
> > compatible with Java 1.7) with security vulnerability CVE-2021-29425 in it?
> > Or is there any plans to make security vulnerability CVE-2021-29425 fix on
> > commons-io v2.6?
> >
> > Please guide us. This is blocking our patch to customers.
> >
> > Thanks,
> > Surendra
> >
> >

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

Re: [csv] Does the library provide means to circumvent CSV injection

[sebb]

On Thu, 11 Nov 2021 at 22:00, Bruno P. Kinoshita
 wrote:
>
>  Maybe we could provide a flag that disables the characters mentioned in the 
> OWASP page about CSV Injection [1]

No, please no.

> Normally I suggest going secure by default, but in this case I think the flag 
> should be disabled by default, as filtering cells that start with "equals to" 
> could break in cases where it was used for a legit formula for 
> excel/openoffice/libreoffice/etc.

Or maybe the CSV contains data for another application that requires
these meta-characters.
Or maybe there is another application that blows up when accents are used.
Etc.

It is just not the right place to implement such checks.

> The OWASP page also acknowledges the difficulty of this issue I think:
> > This attack is difficult to mitigate, and explicitly disallowed fromquite a 
> > few bug bounty programs.
> Just my 0.02 cents.
> Bruno

Yes, it is difficult (if not impossible) to mitigate, especially at
the level of a component like Commons CSV.
We don't know the context of how CSV will be used.

Do we even want to take responsibility for guaranteeing that Commons
CSV prevents all CSV injection attacks?

Even if we were able to release a perfect solution, it would not
prevent injection attacks via direct access to CSV files, which is
surely the main vector.

Seems to me we should just update the Javadoc to mention the issue,
and let the application handle it.

> [1] https://owasp.org/www-community/attacks/CSV_Injection
> On Friday, 12 November 2021, 04:29:42 am NZDT, Bernd Eckenfels 
>  wrote:
>
>  Hello,
>
> I don’t really agree, a generic CSV tool should have a flag to protect 
> against this, since it is a very common requirement. The situation is very 
> unfortunate, this is why there is no good solution by default, but I can 
> asume many software vendors working in the area of windows based enterprise 
> desktops and exporting files with CSV downloads want to enable this.
>
> Having said that, not sure if actually quoting is enough and all should 
> prefer xml based office formats anyway.
>
> I won’t mind to accept a tester patch for such an option. Maybe even 
> unsafe-pass-default/quote-injection/reject-injection enum.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: sebb 
> Gesendet: Thursday, November 11, 2021 3:42:08 PM
> An: Commons Users List 
> Cc: Gary Gregory ; ms...@acm.org 
> Betreff: Re: [csv] Does the library provide means to circumvent CSV injection
>
> On Thu, 11 Nov 2021 at 11:36, P. Ottlinger  wrote:
> >
> > Hi guys,
> >
> > thanks for your reply.
> >
> > Maybe I'm misinterpreting something but I thought that it could be made
> > possible to configure CSVFormat-object when writing the CSV data in a
> > way that any data with possibly corrupting values (as shown on the OWASP
> > page) will mask the whole contents of the cell.
> >
> > Thus a library such as commons-csv would be able to lower the risk for
> > CSV injection and not every client/customer would have to manually
> > create this protecting logic.
> >
> > To my mind it's a simple parser for "dangerous" tokens that quotes the
> > given data with additional   as we do not need to write
> > functioning Excel formulas into CSV.
> >
> > WDYT?
>
> As the others have said, this is the wrong place to be looking to fix
> the problem.
>
> CSV files are used for lots of things other than spreadsheets, so what
> is dangerous in one application might be essential in another.
>
> Besides, not all CSV files will be processed by Commons CSV on their
> route to a spreadsheet app.
>
> Such checks need to be made at the input to the application that processes it.
>
> > Cheers,
> > Phil
> >
> > Am 10.11.21 um 20:53 schrieb Gary Gregory:
> > > I agree with Matt. CSV is just a container, it doesn't know or care what
> > > the concept of a "formula" is.
> > >
> > > Gary
> >
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

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

Re: [csv] Does the library provide means to circumvent CSV injection

[sebb]

On Thu, 11 Nov 2021 at 11:36, P. Ottlinger  wrote:
>
> Hi guys,
>
> thanks for your reply.
>
> Maybe I'm misinterpreting something but I thought that it could be made
> possible to configure CSVFormat-object when writing the CSV data in a
> way that any data with possibly corrupting values (as shown on the OWASP
> page) will mask the whole contents of the cell.
>
> Thus a library such as commons-csv would be able to lower the risk for
> CSV injection and not every client/customer would have to manually
> create this protecting logic.
>
> To my mind it's a simple parser for "dangerous" tokens that quotes the
> given data with additional   as we do not need to write
> functioning Excel formulas into CSV.
>
> WDYT?

As the others have said, this is the wrong place to be looking to fix
the problem.

CSV files are used for lots of things other than spreadsheets, so what
is dangerous in one application might be essential in another.

Besides, not all CSV files will be processed by Commons CSV on their
route to a spreadsheet app.

Such checks need to be made at the input to the application that processes it.

> Cheers,
> Phil
>
> Am 10.11.21 um 20:53 schrieb Gary Gregory:
> > I agree with Matt. CSV is just a container, it doesn't know or care what
> > the concept of a "formula" is.
> >
> > Gary
>

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

Re: 1983.christian.muel...@gmail.com

[sebb]

On Sun, 12 Sept 2021 at 11:50, Christian Müller
<1983.christian.muel...@gmail.com> wrote:
>
> Hi everybody,
>
> One short question: Is the javadoc description of
> *commons.io.FileUtils.isRegularFile(...)* correct? It says it returns
> "false" if the path is not a directory. Actually "false" is returned for
> existing directories. I think the javadoc should be corrected to:
> "return false if path is a directory", right?
>

Thanks for the report - the Javadoc is definitely wrong.

However I think it should say

"is not a regular file"

rather than

"is not a directory"

That is what the underlying JVM method File.isRegularFile(...) does.

That would imply that it returns false for directories, as they are
not regular files.

> Best regards,
>
> Christian
>

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

Re: [beanutils] Optional dependency on commons-collections (v3)

[sebb]

On Thu, 22 Apr 2021 at 22:32, Alex Herbert  wrote:
>
> On Thu, 22 Apr 2021 at 22:19, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Gary,
> >
> > On 4/21/21 16:18, Gary Gregory wrote:
> > > You can scan the source files for import statements, of Commons
> > Collections
> > > packages, then see where those files/types are used from, then see where
> > > those files/typee are used from, and so on.
> >
> > I'd be happy to scan the source for, but I followed the instructions on
> > the web site[1] for getting the source code from git, but they don't
> > actually work.
> >
> > $ git clone https://gitbox.apache.org/repos/asf?p=commons-beanutils.git
> > Cloning into 'asf?p=commons-beanutils'...
> > fatal:
> > https://gitbox.apache.org/repos/asf?p=commons-beanutils.git/info/refs
> > not valid: could not determine hash algorithm; is this a git repository?
> >
> >
> It should be:
>
>
> git clone https://gitbox.apache.org/repos/asf/commons-beanutils.git

That works, but if you follow the URL it actually redirects to:

curl -I https://gitbox.apache.org/repos/asf/commons-beanutils.git
..
Location: https://gitbox.apache.org/repos/asf?p=commons-beanutils.git

The version with the ?p= qualifier only seems to be suitable for
browsing, whereas the other works for both clone and browsing.

I expect several of the Commons components have the same issue.


>
> You can also use the github mirror:
>
> https://github.com/apache/commons-beanutils
>
>
> > -chris
> >
> > [1] http://commons.apache.org/proper/commons-beanutils/scm.html
> >
> > > On Wed, Apr 21, 2021, 16:06 Christopher Schultz <
> > > ch...@christopherschultz.net> wrote:
> > >
> > >> All,
> > >>
> > >> I'm trying to debug a problem in a deployment of a product where the
> > >> vendor has removed commons-collections-3.2.2.jar but kept
> > >> commons-beanutils-1.9.3.jar.
> > >>
> > >> We are getting NoClassDefFoundErrors in
> > >> org.apache.commons.beanutils.PropertyUtilsBean.getPropertyDescriptor
> > >>
> > >> beanutils lists commons-collections (3.2.2) as an "optional" (runtime)
> > >> dependency, and I'm wondering under what conditions it's actually
> > >> necessary. I think I've found one (!) but what are the others?
> > >>
> > >> -chris
> > >>
> > >> -
> > >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: user-h...@commons.apache.org
> > >>
> > >>
> > >
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >

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

[ANNOUNCE] Apache Commons Validator 1.7

[sebb AT ASF]

The Apache Commons Validator team is pleased to announce the release
of Apache Commons Validator 1.7

Apache Commons Validator provides the building blocks for both client
side validation and server side data validation.
It may be used standalone or with a framework like Struts.


This is primarily a maintenance release.
All projects are encouraged to update to this release of Apache
Commons Validator.

Commons Validator requires Java 7 or later.

Main enhancements
=

* CreditCard validation specification by numeric range
* DomainValidator instances can be created with instance overrides
* DomainValidator supports overrides of LOCAL TLDs

IMPORTANT NOTES
===

BREAKING CHANGES:

* Now requires Java 7
* N.B. Java 9 changed the way Locales are handled. This affects the
output from some Date-related methods, and may cause some tests to
break.

DEPENDENCIES


* Updates Apache Commons BeanUtils dependency from 1.9.2 to 1.9.4.
 This picks up BEANUTILS-482: Update commons-collections from 3.2.1 to
3.2.2 (CVE-2015-4852).

For the current list of dependencies, please see
http://commons.apache.org/validator/dependencies.html

For complete information on Apache Commons Validator, including
instructions on how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons
Validator website:

http://commons.apache.org/proper/commons-validator/

Download page: 
http://commons.apache.org/proper/commons-validator/download_validator.cgi

Changes in this version include:
===

New features:
o VALIDATOR-474:  DomainValidator should allow local overrides
o VALIDATOR-473:  Allow Email- and UrlValidator to use specified DomainValidator
o VALIDATOR-471:  Allow DomainValidator overrides at run-time
o VALIDATOR-423:  Add ISINValidator
o VALIDATOR-455:  Add IBAN validator for VA – Vatican City State
Thanks to Eugen Hanussek.
o VALIDATOR-446:  ISSN Validator extract ISSN from EAN-13 Thanks to Alex.

Fixed Bugs:
o VALIDATOR-403:  Accept Discover cards of 17 digits long that start
with 6011 Thanks to Tanya.
o VALIDATOR-408:  DISCOVER Card Validation Patterns Thanks to Raj Vaida.
o VALIDATOR-472:  UrlValidator should not be more lax than java.net.URI
o VALIDATOR-283:  URLValidator should check for illegal Hex characters
Thanks to RC Johnson.
o VALIDATOR-445:  Inet6Address may also contain a scope id Thanks to devson.
o VALIDATOR-452:  Validation of URL containing IPv4-mapped IPv6
address Thanks to devson.
o VALIDATOR-438:  IBANValidator fails for El Salvador
  Add definition Thanks to Simon Marti.
o VALIDATOR-434:  Field does not synchronize iteration on synchronized
list Thanks to emopers.
o VALIDATOR-437:  Update Apache Commons BeanUtils dependency from
1.9.2 to 1.9.3.
  This picks up BEANUTILS-482: Update
commons-collections from 3.2.1 to 3.2.2 (CVE-2015-4852).
o VALIDATOR-460:  Update Apache Commons BeanUtils dependency from 1.9.3 to 1.9.4
  This picks up BEANUTILS-520: Mitigate CVE-2014-0114.
Thanks to Jeff Schram.
o VALIDATOR-461:  Generic .gmbh top level domain is considered invalid
Thanks to Nils Reischmann.
o VALIDATOR-444:  LongValidator: numbers bigger than the maxvalue are
Valid Thanks to Martin Scholz.
o VALIDATOR-416:  CreditCardValidator default ctor disagrees with Javadoc
o VALIDATOR-467:  URL validator fails if path starts with double slash
and has underscores Thanks to Ivan Larionov.
o VALIDATOR-464:  UrlValidator says "file://bad ^
domain.com/label/test" is valid Thanks to Sebastian Choina.
o VALIDATOR-449:  Leading and trailing spaces in EmailValidator should
not be valid Thanks to Frederic Boutin.
o VALIDATOR-302:  EMailValidator: Addresses with leading spaces must
not be accepted Thanks to Guido Zockoll.
o VALIDATOR-468:  DomainValidator.getTLDArray does not synch mutable arrays

Changes:
o Drop Clirr and Cobertura in favour of JApiCmp and JaCoCo
o IANA TLD lists: Updated to Version 2020073100, Last
Updated Fri Jul 31 07:07:01 2020 UTC
o VALIDATOR-428:  Update commons digester to 2.1 Thanks to Matthew Zavislak.


Historical list of changes:
http://commons.apache.org/proper/commons-validator/changes-report.html

Enjoy!
-Apache Commons Validator team

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

[ANNOUNCE] Apache Commons NET 3.7 released

[sebb]

The Apache Commons team are pleased to announce the release of
Apache Commons Net version 3.7.

The Commons Net library implements the client side of many basic
Internet protocols.
The purpose of the library is to provide fundamental protocol access,
not higher-level abstractions.

This is a bug fix release. All users are encouraged to upgrade to 3.7.

For details of the fixes and new features please see:

http://www.apache.org/dist/commons/net/RELEASE-NOTES.txt

[These are also included with the binary and source archives]

The changes are also available at:
http://commons.apache.org/net/changes-report.html

Binary and source archives are available from:

http://commons.apache.org/proper/commons-net/download_net.cgi

Please see the Apache Commons Net website for full details:

http://commons.apache.org/net/

The Maven coordinates are:

commons-net
commons-net
3.7

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

Re: commons-exec docs still point to subversion

[sebb]

Thanks for the report.
I hope the stale information have now been fixed/

On Fri, 24 Apr 2020 at 22:11, Carsten Dreesbach
 wrote:
>
> https://commons.apache.org/proper/commons-exec/source-repository.html
> still mentions subversion as the repo (these pages still come up first
> when doing Google searches, so will be somebody's first contact with the
> project if they're unfamiliar with it). The link listed on this page
> (http://svn.apache.org/viewvc/commons/proper/exec/trunk) leads to a 404.
> If you remove the /trunk to go to
> http://svn.apache.org/viewvc/commons/proper/exec/, you see a page with a
> file called "EXECnowUsesGit.txt", which just says "EXEC was moved to
> Git" when you click it, but no indication where on Github it actually lives.
>
> It would be nice if that file could be updated with the official (?)
> Github link (https://github.com/apache/commons-exec?) and also if the
> docs could just point directly to github. Unfortunately I have no idea
> how that would be updated, so I hope somebody on this mailing list can
> help with that. ;]
>
>
> Thanks,
>
> Carsten
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [compress] Support for writing AES-encrypted ZIP files

[sebb]

Fixing subject prefix

On Sat, 28 Sep 2019 at 14:00, Christopher Schultz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> According to
> https://commons.apache.org/proper/commons-compress/limitations.html,
> ZIP support does not include AES encryption when *writing* archives.
>
> I'm wondering if that was a design decision or just that nobody has
> volunteered to write the export code to support that feature.
>
> I've been using the library that was once hosted at
> https://code.google.com/p/winzipaes, but is would be nice to have it
> available through commons-compress as well.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2PWUgACgkQHPApP6U8
> pFhzoxAAtOY3sjNV+KomHrQqQWgo5Tm4r3QT/sdUoeIi5uQHoiajUEuviot5F4jt
> Ql+qgPqDrDAoDUN05/XI3ArQeWwHYzTPi4gDaTATVXmigAYV04PqcyF2w9sZq/t6
> zr2giRdDjg/24LzSLx3O/aX+eCLU1ekqtAPUdCI3vpLfC+ymElaIedD+G748GwKz
> 4xLwZG/eWnTeyWaP6SFaKXmlPexCIAt/FSQh0ztmmSn2ivvLkMTMMsvXbXLVwWQ2
> A0JSPBqywuS5RSGAS8ebX5p7BKbw4jdlxVqyGbgv7yFYQMEOuaI6oOFRdTb5ujgg
> bXYM/hR5wNuveHZON5VqFVj5gnDQDp9GMm8iw0ueJYDxviCVzP6XVeLuUCCZeFf6
> Kz78Q5W65jIylMTGpWc7nXVvWou2aKf8esODPWlvAuXN4EJOkpBBk2zThGnLl4ox
> qiAhAt2Ma3KCNYcTfV0Yx8Pk5PGTkMuhhSjh/oxNQ2amFQ38Jjkvp3feZ1WxgCDC
> GCE+mPAVYu6AMmZmDyIa6jB3O3RgMY3ZsGitrKRinkh+pqDE/MhAiIHbM6q9HK4l
> QSD4yE2xPc6ud5hMeoNhoHr1un4BoWQ4cPno9oO6Yj6pzU5EHUq4TRTIITrMkg3O
> OIB1UIcxovYFkIOVZ/+U1GtCyNmY2MHEX05y/iB3TpM0fM8jHIQ=
> =Xhbd
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [codec] Hex encode

[sebb]

On Sat, 28 Sep 2019 at 06:21, Or Mark  wrote:
>
> Hello,
>
> About commons-codec Hex encoding methods,
> I suggest adding to Hex static encode method which returns byte[]
> It will be consistent with other encoding classes that have such method as
> Base64(same package) and MessageDigest.

Base64 has a static method, but this actually calls a method on a
cached instance using UTF-8.
The use of UTF-8 is noted in the Javadoc.

> I don't see a real reason to use instance method in this case.

It uses the instance Charset, as noted in the Javadoc.

> I would like to contribute this method to library.

What is the use case for this?

> First asked in
> https://stackoverflow.com/questions/58128819/apache-common-codec-why-hex-encode-isnt-static/58129148#58129148

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

Re: Final tag for commons-io-2.6

[sebb]

On Wed, 25 Sep 2019 at 16:59, Gary Gregory  wrote:
>
> On Wed, Sep 25, 2019 at 8:44 AM sebb  wrote:
>>
>> On Wed, 25 Sep 2019 at 11:34, Roberto Oliveira  wrote:
>> >
>> > On Wed, Sep 25, 2019 at 12:31 PM sebb  wrote:
>> > >
>> > > On Wed, 25 Sep 2019 at 07:41, Daniel Kreling  wrote:
>> > > >
>> > > > We need to build the package from source
>> > >
>> > > In which case you should be using the formal release package.
>> > >
>> > > > and we need to know precisely
>> > > > where the development ended.
>> > >
>> > > What do you mean by that?
>> > He means that if he wants to build version 2.6 from source he doesn't
>> > know from where he should build.
>>
>> He should build from the official source release.
>>
>> These are linked from the download page, i.e.
>>
>> https://commons.apache.org/proper/commons-io/download_io.cgi
>>
>> For automated builds you can use:
>>
>> http://www.apache.org/dyn/closer.cgi/?filename=commons/io/source/commons-io-2.6-src.zip=download
>>
>> You should check the sig or hash from:
>> https://www.apache.org/dist/commons/io/source/commons-io-2.6-src.zip.asc
>> https://www.apache.org/dist/commons/io/source/commons-io-2.6-src.zip.sha256
>>
>> You can replace .zip with .tar.gz above
>>
>> > Can you or someone confirm the version 2.6 was built from tag
>> > "commons-io-2.6-RC3" ?
>>
>> Only the source packages linked from the download page are official releases.
>
>
> But that does not address the poster's question. If we are confident that 
> commons-io-2.6-RC3 is indeed 2.6, then we should create a tag called  
> rel/commons-io-2.6, right?

The tag would not be an official source release.

> Gary
>
>>
>> > >
>> > > > Thanks,
>> > > > Daniel
>> > > >
>> > > > On Tue, Sep 24, 2019 at 6:52 PM sebb  wrote:
>> > > > >
>> > > > > Might I ask why the tag is so important?
>> > > > >
>> > > > > If you are looking to download the source, then that is available 
>> > > > > from
>> > > > > the usual download page:
>> > > > >
>> > > > > https://commons.apache.org/proper/commons-io/download_io.cgi
>> > > > >
>> > > > > On Tue, 24 Sep 2019 at 11:32, Roberto Oliveira  
>> > > > > wrote:
>> > > > > >
>> > > > > > Hi Gary,
>> > > > > >
>> > > > > > Thanks for looking at it. Is there any update?
>> > > > > >
>> > > > > > On Fri, Sep 20, 2019 at 2:10 PM Gary Gregory 
>> > > > > >  wrote:
>> > > > > > >
>> > > > > > > Looking...
>> > > > > > >
>> > > > > > > On Fri, Sep 20, 2019 at 7:32 AM Daniel Kreling 
>> > > > > > >  wrote:
>> > > > > > >>
>> > > > > > >> Hi
>> > > > > > >>
>> > > > > > >> I am looking for the final tag for commons-io version 2.6 and I 
>> > > > > > >> have
>> > > > > > >> not been able to find it [0]. The last one I can see is the
>> > > > > > >> commons-io-2.6-RC3, released in Oct 2017, which I assume to be 
>> > > > > > >> the
>> > > > > > >> final one.
>> > > > > > >>
>> > > > > > >> Is there a "Final" tag for commons-io, or one which I can 
>> > > > > > >> explicitly
>> > > > > > >> tell it's the final one?
>> > > > > > >> If not, is it possible for you to create one, please?
>> > > > > > >>
>> > > > > > >> [0] https://github.com/apache/commons-io/releases
>> > > > > > >>
>> > > > > > >> Thanks,
>> > > > > > >> Daniel
>> > > > > > >>
>> > > > > > >> -
>> > > > > > >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> > > > > > >> For additional commands, e-mail: user-h...@commons.apache.org
>> > > > > > >>
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Regards,
>> > > > > > Roberto Oliveira
>> > > > > >
>> > > > > > -
>> > > > > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> > > > > > For additional commands, e-mail: user-h...@commons.apache.org
>> > > > > >
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Roberto Oliveira

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

Re: Final tag for commons-io-2.6

[sebb]

On Wed, 25 Sep 2019 at 11:34, Roberto Oliveira  wrote:
>
> On Wed, Sep 25, 2019 at 12:31 PM sebb  wrote:
> >
> > On Wed, 25 Sep 2019 at 07:41, Daniel Kreling  wrote:
> > >
> > > We need to build the package from source
> >
> > In which case you should be using the formal release package.
> >
> > > and we need to know precisely
> > > where the development ended.
> >
> > What do you mean by that?
> He means that if he wants to build version 2.6 from source he doesn't
> know from where he should build.

He should build from the official source release.

These are linked from the download page, i.e.

https://commons.apache.org/proper/commons-io/download_io.cgi

For automated builds you can use:

http://www.apache.org/dyn/closer.cgi/?filename=commons/io/source/commons-io-2.6-src.zip=download

You should check the sig or hash from:
https://www.apache.org/dist/commons/io/source/commons-io-2.6-src.zip.asc
https://www.apache.org/dist/commons/io/source/commons-io-2.6-src.zip.sha256

You can replace .zip with .tar.gz above

> Can you or someone confirm the version 2.6 was built from tag
> "commons-io-2.6-RC3" ?

Only the source packages linked from the download page are official releases.

> >
> > > Thanks,
> > > Daniel
> > >
> > > On Tue, Sep 24, 2019 at 6:52 PM sebb  wrote:
> > > >
> > > > Might I ask why the tag is so important?
> > > >
> > > > If you are looking to download the source, then that is available from
> > > > the usual download page:
> > > >
> > > > https://commons.apache.org/proper/commons-io/download_io.cgi
> > > >
> > > > On Tue, 24 Sep 2019 at 11:32, Roberto Oliveira  
> > > > wrote:
> > > > >
> > > > > Hi Gary,
> > > > >
> > > > > Thanks for looking at it. Is there any update?
> > > > >
> > > > > On Fri, Sep 20, 2019 at 2:10 PM Gary Gregory  
> > > > > wrote:
> > > > > >
> > > > > > Looking...
> > > > > >
> > > > > > On Fri, Sep 20, 2019 at 7:32 AM Daniel Kreling 
> > > > > >  wrote:
> > > > > >>
> > > > > >> Hi
> > > > > >>
> > > > > >> I am looking for the final tag for commons-io version 2.6 and I 
> > > > > >> have
> > > > > >> not been able to find it [0]. The last one I can see is the
> > > > > >> commons-io-2.6-RC3, released in Oct 2017, which I assume to be the
> > > > > >> final one.
> > > > > >>
> > > > > >> Is there a "Final" tag for commons-io, or one which I can 
> > > > > >> explicitly
> > > > > >> tell it's the final one?
> > > > > >> If not, is it possible for you to create one, please?
> > > > > >>
> > > > > >> [0] https://github.com/apache/commons-io/releases
> > > > > >>
> > > > > >> Thanks,
> > > > > >> Daniel
> > > > > >>
> > > > > >> -
> > > > > >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > > > >> For additional commands, e-mail: user-h...@commons.apache.org
> > > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Roberto Oliveira
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: user-h...@commons.apache.org
> > > > >
>
>
>
> --
> Regards,
> Roberto Oliveira

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

Re: Final tag for commons-io-2.6

[sebb]

On Wed, 25 Sep 2019 at 07:41, Daniel Kreling  wrote:
>
> We need to build the package from source

In which case you should be using the formal release package.

> and we need to know precisely
> where the development ended.

What do you mean by that?

> Thanks,
> Daniel
>
> On Tue, Sep 24, 2019 at 6:52 PM sebb  wrote:
> >
> > Might I ask why the tag is so important?
> >
> > If you are looking to download the source, then that is available from
> > the usual download page:
> >
> > https://commons.apache.org/proper/commons-io/download_io.cgi
> >
> > On Tue, 24 Sep 2019 at 11:32, Roberto Oliveira  wrote:
> > >
> > > Hi Gary,
> > >
> > > Thanks for looking at it. Is there any update?
> > >
> > > On Fri, Sep 20, 2019 at 2:10 PM Gary Gregory  
> > > wrote:
> > > >
> > > > Looking...
> > > >
> > > > On Fri, Sep 20, 2019 at 7:32 AM Daniel Kreling  
> > > > wrote:
> > > >>
> > > >> Hi
> > > >>
> > > >> I am looking for the final tag for commons-io version 2.6 and I have
> > > >> not been able to find it [0]. The last one I can see is the
> > > >> commons-io-2.6-RC3, released in Oct 2017, which I assume to be the
> > > >> final one.
> > > >>
> > > >> Is there a "Final" tag for commons-io, or one which I can explicitly
> > > >> tell it's the final one?
> > > >> If not, is it possible for you to create one, please?
> > > >>
> > > >> [0] https://github.com/apache/commons-io/releases
> > > >>
> > > >> Thanks,
> > > >> Daniel
> > > >>
> > > >> -
> > > >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > >> For additional commands, e-mail: user-h...@commons.apache.org
> > > >>
> > >
> > >
> > > --
> > > Regards,
> > > Roberto Oliveira
> > >
> > > -
> > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: user-h...@commons.apache.org
> > >

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

Re: Final tag for commons-io-2.6

[sebb]

Might I ask why the tag is so important?

If you are looking to download the source, then that is available from
the usual download page:

https://commons.apache.org/proper/commons-io/download_io.cgi

On Tue, 24 Sep 2019 at 11:32, Roberto Oliveira  wrote:
>
> Hi Gary,
>
> Thanks for looking at it. Is there any update?
>
> On Fri, Sep 20, 2019 at 2:10 PM Gary Gregory  wrote:
> >
> > Looking...
> >
> > On Fri, Sep 20, 2019 at 7:32 AM Daniel Kreling  wrote:
> >>
> >> Hi
> >>
> >> I am looking for the final tag for commons-io version 2.6 and I have
> >> not been able to find it [0]. The last one I can see is the
> >> commons-io-2.6-RC3, released in Oct 2017, which I assume to be the
> >> final one.
> >>
> >> Is there a "Final" tag for commons-io, or one which I can explicitly
> >> tell it's the final one?
> >> If not, is it possible for you to create one, please?
> >>
> >> [0] https://github.com/apache/commons-io/releases
> >>
> >> Thanks,
> >> Daniel
> >>
> >> -
> >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: user-h...@commons.apache.org
> >>
>
>
> --
> Regards,
> Roberto Oliveira
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [email] Is there a way to unset CC/BCC?

[sebb]

On Tue, 27 Aug 2019 at 12:02, Pavlo Polishchuk  wrote:
>
> Good day,
> Is there a way to unset CC/BCC through "org.apache.commons.mail.Email" ?
>
> I tried "email.setCC" with empty collection but there is a check for
> null/empty collection inside.
> Also, tried to "email.getMimeMessage().setRecipients(...)" but this fails
> with NPE since MimeMessage is not build at that time.
>
> Do I miss something?

The underlying list is accessible as a protected field and via code of the form:

List list = email.getBccAddresses();

so it's easy enough to clear the list if required.

An alternative is not to set the list in the first place ...

> Thanks in advance!
>
> --
> Best regards,
> Paul

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

Re: [DBCP] Why was 1.5.1 never released?

[sebb]

Why not use 2.7.0?

Does that not fix the issue?

On Wed, 14 Aug 2019 at 23:40, sanchay javeria  wrote:
>
> Alright, that's not a problem. I'll build the jar myself and push it to our
> internal maven repo. Are there any blockers/issues with 1.5.1 we should be
> aware of or is it safe for production usage?
>
> Thanks,
> Sanchay
>
> On Tue, 13 Aug 2019 at 21:46, Gary Gregory  wrote:
>
> > That is quite an old version. The current version is 2.7.0. I don't see
> > myslef spending time releasing such an old version, but someone else here
> > can...
> >
> > Gary
> >
> > On Tue, Aug 13, 2019, 17:56 sanchay javeria 
> > wrote:
> >
> > > Hey,
> > >
> > > DBCP v1.5.1 contains a lot of patches that fix the issues we've been
> > seeing
> > > when MySQL pt-kill unexpectedly kills a query and closes the connection.
> > > The stack trace is very similar to DBCP-398
> > > . Are there any plans on
> > > releasing this version? If not, why so?
> > >
> > > Thank you,
> > > Sanchay
> > >
> >

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

Re: [ANNOUNCEMENT] Apache Commons Collections 4.4

[sebb]

On Wed, 10 Jul 2019 at 13:39, Gary Gregory  wrote:
>
> [Updated download page below]
> The Apache Commons team released Apache Commons Collections 4.4.
>
> The Apache Commons Collections package contains types that extend and
> augment the Java Collections Framework.
>
> Maintenance release.
>
> Changes in this version include:
>
> New features:
> o COLLECTIONS-715:  Implement Collection's removeIf(). Thanks to
> morningmemo, Gary Gregory.
> o COLLECTIONS-719:  Create a PropertiesFactory and SortedPropertiesFactory.
> Thanks to Gary Gregory.
> o COLLECTIONS-719:  Support Transformer for LazyList #52. Thanks to Stephan
> Windmüller, Bruno P. Kinoshita.
> o COLLECTIONS-723:  Make use of FunctionalInterface #48. Thanks to Eitan
> Adler, SOC, Bruno P. Kinoshita.
>
> Fixed Bugs:
> o COLLECTIONS-710:  NullPointerExceptions in CompositeCollection,
> CompositeSet, and CompositeMap. Thanks to Yu Shi, Gary Gregory.
>
> Changes:
> o COLLECTIONS-718:  Fix LRUMap exception message. Thanks to Eitan Adler.
> o COLLECTIONS-716:  Don't include email address in Exception messages.
> Thanks to Sebb.
>
> For complete information on Apache Commons Collections, including
> instructions on how to submit bug reports,
> patches, or suggestions for improvement, see the Apache Apache Commons
> Collections website:
>
> https://commons.apache.org/proper/commons-collections/
>
> Download page:
> https://dist.apache.org/repos/dist/release/commons/collections

Please do *not* use the above URL. Instead please use:

https://commons.apache.org/proper/commons-collections/download_collections.cgi


> Gary Gregory
> for the Apache Commons Team

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

Re: [ANNOUNCEMENT] Apache Commons Collections 4.4

[sebb]

On Tue, 9 Jul 2019 at 15:34, Gary Gregory  wrote:
>
> The Apache Commons team released Apache Commons Collections 4.4.
>
> The Apache Commons Collections package contains types that extend and
> augment the Java Collections Framework.
>
> Maintenance release.
>
> Changes in this version include:
>
> New features:
> o COLLECTIONS-715:  Implement Collection's removeIf(). Thanks to
> morningmemo, Gary Gregory.
> o COLLECTIONS-719:  Create a PropertiesFactory and SortedPropertiesFactory.
> Thanks to Gary Gregory.
> o COLLECTIONS-719:  Support Transformer for LazyList #52. Thanks to Stephan
> Windmüller, Bruno P. Kinoshita.
> o COLLECTIONS-723:  Make use of FunctionalInterface #48. Thanks to Eitan
> Adler, SOC, Bruno P. Kinoshita.
>
> Fixed Bugs:
> o COLLECTIONS-710:  NullPointerExceptions in CompositeCollection,
> CompositeSet, and CompositeMap. Thanks to Yu Shi, Gary Gregory.
>
> Changes:
> o COLLECTIONS-718:  Fix LRUMap exception message. Thanks to Eitan Adler.
> o COLLECTIONS-716:  Don't include email address in Exception messages.
> Thanks to Sebb.
>
> For complete information on Apache Commons Collections, including
> instructions on how to submit bug reports,
> patches, or suggestions for improvement, see the Apache Apache Commons
> Collections website:
>
> https://commons.apache.org/proper/commons-collections/
>
> Download page:
> https://commons.apache.org/proper/commons-collections/download_pool.cgi

That should be:

https://commons.apache.org/proper/commons-collections/download_collections.cgi

> Gary Gregory
> for the Apache Commons Team

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

Re: Quoted content

[sebb]

I should have added:

withIgnoreSurroundingSpaces() affects parsing
withTrim() affects printing.

On Fri, 14 Jun 2019 at 15:05, sebb  wrote:
>
> Try using:
>
> withIgnoreSurroundingSpaces()
>
> On Fri, 14 Jun 2019 at 14:03, sebb  wrote:
> >
> > On Fri, 14 Jun 2019 at 13:34, Daryl Stultz  
> > wrote:
> > >
> > > I'm trying to replace an old CSV library with commons-csv. I seem to be 
> > > having trouble with the most basic idea of the parser recognizing content 
> > > that is quoted.
> > >
> > > I've discovered this bug here:
> > > https://issues.apache.org/jira/browse/CSV-228
> > >
> > > <https://issues.apache.org/jira/browse/CSV-228>The issue refers to the 
> > > parsing of the header, but it doesn't seem to matter what row the 
> > > comma-quoting is on.
> >
> > According to my reading of RFC4180[1], the fields between delimiters
> > are either either escaped or non-escaped.
> > non-escaped fields can include spaces, but not comma
> > escaped fields must start with the double-quote; leading spaces are
> > not permitted.
> >
> > [1] https://tools.ietf.org/html/rfc4180
> >
> > > There's no way I can use this product with this defect. That's 
> > > unfortunate, I like the API and OpenCSV quotes every bit of content when 
> > > printing which I don't like.
> >
> > Now that is the case for DEFAULT and RFC4180.
> >
> > I've not looked into the withTrim() option.
> > If that is supposed to trim before handling quoted fields, then I
> > agree that there seems to be a bug here.
> > But if the trim is only supposed to apply to the un-quoted field, then
> > the current behaviour seems OK, even if it's not what you expect.
> >
> > > --
> > >
> > > Daryl Stultz
> > > Principal Software Developer
> > > _
> > > OpenTempo, Inc
> > > http://www.opentempo.com<http://www.opentempo.com/>
> > > mailto:daryl.stu...@opentempo.com<mailto:daryl.stu...@opentempo.com>
> > >

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

Re: Quoted content

[sebb]

Try using:

withIgnoreSurroundingSpaces()

On Fri, 14 Jun 2019 at 14:03, sebb  wrote:
>
> On Fri, 14 Jun 2019 at 13:34, Daryl Stultz  wrote:
> >
> > I'm trying to replace an old CSV library with commons-csv. I seem to be 
> > having trouble with the most basic idea of the parser recognizing content 
> > that is quoted.
> >
> > I've discovered this bug here:
> > https://issues.apache.org/jira/browse/CSV-228
> >
> > <https://issues.apache.org/jira/browse/CSV-228>The issue refers to the 
> > parsing of the header, but it doesn't seem to matter what row the 
> > comma-quoting is on.
>
> According to my reading of RFC4180[1], the fields between delimiters
> are either either escaped or non-escaped.
> non-escaped fields can include spaces, but not comma
> escaped fields must start with the double-quote; leading spaces are
> not permitted.
>
> [1] https://tools.ietf.org/html/rfc4180
>
> > There's no way I can use this product with this defect. That's unfortunate, 
> > I like the API and OpenCSV quotes every bit of content when printing which 
> > I don't like.
>
> Now that is the case for DEFAULT and RFC4180.
>
> I've not looked into the withTrim() option.
> If that is supposed to trim before handling quoted fields, then I
> agree that there seems to be a bug here.
> But if the trim is only supposed to apply to the un-quoted field, then
> the current behaviour seems OK, even if it's not what you expect.
>
> > --
> >
> > Daryl Stultz
> > Principal Software Developer
> > _
> > OpenTempo, Inc
> > http://www.opentempo.com<http://www.opentempo.com/>
> > mailto:daryl.stu...@opentempo.com<mailto:daryl.stu...@opentempo.com>
> >

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

Re: Quoted content

[sebb]

On Fri, 14 Jun 2019 at 13:34, Daryl Stultz  wrote:
>
> I'm trying to replace an old CSV library with commons-csv. I seem to be 
> having trouble with the most basic idea of the parser recognizing content 
> that is quoted.
>
> I've discovered this bug here:
> https://issues.apache.org/jira/browse/CSV-228
>
> The issue refers to the 
> parsing of the header, but it doesn't seem to matter what row the 
> comma-quoting is on.

According to my reading of RFC4180[1], the fields between delimiters
are either either escaped or non-escaped.
non-escaped fields can include spaces, but not comma
escaped fields must start with the double-quote; leading spaces are
not permitted.

[1] https://tools.ietf.org/html/rfc4180

> There's no way I can use this product with this defect. That's unfortunate, I 
> like the API and OpenCSV quotes every bit of content when printing which I 
> don't like.

Now that is the case for DEFAULT and RFC4180.

I've not looked into the withTrim() option.
If that is supposed to trim before handling quoted fields, then I
agree that there seems to be a bug here.
But if the trim is only supposed to apply to the un-quoted field, then
the current behaviour seems OK, even if it's not what you expect.

> --
>
> Daryl Stultz
> Principal Software Developer
> _
> OpenTempo, Inc
> http://www.opentempo.com
> mailto:daryl.stu...@opentempo.com
>

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

Re: [math] Vector math question

[sebb]

On Tue, 28 May 2019 at 09:31, LE TELLIER Romain 211391
 wrote:
>
> Hello,
>
> Yes, Apache Commons Maths has what you need. Start by having a look at the 
> org.apache.commons.math3.geometry.euclidean.threed package and the Vector3D 
> class
> https://commons.apache.org/proper/commons-math/userguide/geometry.html
>
> By the way, I have understand that this geometry package will be supplanted 
> by the apache commons geometry 
> (https://commons.apache.org/proper/commons-geometry/)  but there is no 
> release yet.
> Does anybody knows what is the associated schedule?

Please start a new thread for a new question.

> Best regards,
> Romain
>
> -Message d'origine-
> De : Oscar Bastidas [mailto:obast...@umn.edu]
> Envoyé : mardi 28 mai 2019 09:38
> À : user@commons.apache.org
> Objet : [math] Vector math question
>
> Hello,
>
> I have some calculations that specifically involve:
>
> 1) calculating vectors from 3-dimensional x, y, z points in Euclidean space
>
> 2) performing dot products with the aforementioned vectors
>
> 3) finding vector length
>
> Would someone please tell me if Apache Commons Math has tools to calculate 
> these quantities, and if so, what is the complete import statements to summon 
> these classes and their methods?  Thanks.
>
> Oscar
>
> Oscar Bastidas, Ph.D.
> Postdoctoral Research Associate
> University of Minnesota

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

Re: [net] FTP.Command.Site.Overflow command.

[sebb]

On Mon, 1 Apr 2019 at 11:55, Marcin Kudla  wrote:
>
> Hi
>
> In our application we use Apache Commons Net FTP client to send files to
> the server. One of our clients indicated us that during the connection our
> client performs the command FTP.Command.Site.Overflow. According to
> https://fortiguard.com/encyclopedia/ips/12624 this command is dangerous.
>
> I added ProtocolCommandListener to see the commands that are executed
> during the connection and, additionally, I looked into the source code and
> found nothing to indicate that the command is being executed. Does the
> FTPClient actually execute this command?

There is no such FTP command as Site.Overflow.
It is just a name for sending an overly long command line to the FTP server.

NET generally only sends whatever you tell it to.

However there are some commands it sends to find out info from the
server, e.g. the SITE command.
These are short.

The only other command I can think of is the NOOP command which is
sent if you enable keep-alive.

See
https://commons.apache.org/proper/commons-net/javadocs/api-3.6/org/apache/commons/net/ftp/FTPClient.html

If the server does not process the NOOPs during a long-running
transfer then I suppose they might build up.

> If so, is it possible to disable its execution somehow?

See above; don't enable keep-alive

> Thanks
> Marcin

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

Re: [SCXML] Snapshot repository does not contain any JAR

[sebb]

Please note that SNAPSHOT releases are offered as-is.

There has been no QA and they are not supported.

The jars in the snapshot repository may be replaced or removed at any time.

They should only be used by developers wishing to help with testing
the code being developed.
They should never be used in a production environment.

On Thu, 14 Mar 2019 at 09:47, Gilles Sadowski  wrote:
>
> Le jeu. 14 mars 2019 à 07:54, Diptendu Dutta
>  a écrit :
> >
> > The SCXML snapshot repository does not contain any JAR files,
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-scxml2/2.0-SNAPSHOT/
>
> HTH,
> Gilles
>
> > they only have MD5 and SHA1 signatures.
> >
> > https://repository.apache.org/content/groups/snapshots/commons-scxml/commons-scxml/
> >
> > https://repository.apache.org/content/groups/snapshots/commons-scxml/commons-scxml/0.10-SNAPSHOT/
> >
> > The 2.0-M1 Jar is available at
> > https://mvnrepository.com/artifact/org.apache.commons/commons-scxml2
> >
> > However I am trying to find the SCXML 2.0-SNAPSHOT JAR since it
> > is supposed to include a fix for a bug:
> > --
> >
> > Hi Diptendu,
> >
> > Hmm... I think I stepped off on the wrong foot, and you're right: It
> > seems failing with 2.0-M1 tag.
> > When I execute the same thing [1] with the latest master branch
> > (2.0-SNAPSHOT), it works fine.
> > So, I assume it was fixed intentionally or it just cannot occur any
> > more as of SCXML-243.
> >
> > Regards,
> >
> > Woonsan
> >
> > 
> >
> >
> > Regards,
> >
> > Diptendu Dutta
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [csv] csv format detector/sniffer?

[sebb]

On Mon, 25 Feb 2019 at 18:38, Tim Allison  wrote:
>
> Hi Gary,
>
> Our charset detector stuff is a combo of html-metaheader detection,
> juniversalchardet and a cut and paste of a small portion of icu4j...we
> could add that to commons-io, but I don't think you'd want to add
> juniversalchardet as a dependency or would you?  Happy to discuss...

I think the HTML stuff is out of scope for IO; not sure about the other bits.

> My main question to commons-csv was intended rather to focus on:
>
> 1) text vs csv detection (aside from filename glob)
> 2) detection of most likely: a) delimiter, b) quote character, c)
> escape character

That seems reasonable for CSV.

But it should probably be in its own package as it is somewhat outside
the rest of CSV.


>  More like:
>
> org.apache.commons.csv.CSVParser.parse(path, charset);
>
> or ideally:
>
> CSVFormat format = CSVDetector.detect(path)
>
> where format includes charset and one value is "probably straight
> text, not likely a csv"
>
> On Mon, Feb 25, 2019 at 10:39 AM Gary Gregory  wrote:
> >
> > Hi,
> >
> > A Charset detector sounds like something generally useful that belongs in
> > Commons IO.
> >
> > Path path = Path.get(...);
> > Charset cs = org.apache.commons.io.CharsetDetector.detect(path);
> > org.apache.commons.csv.CSVParser.parse(path, charset, csvFormat);
> >
> > Thoughts?
> >
> > Gary
> >
> >
> > On Mon, Feb 25, 2019 at 10:23 AM Tim Allison  wrote:
> >
> > > Commons-CSV team,
> > >
> > >   We recently integrated Commons-CSV into Apache Tika.  For now, we’re
> > > relying strictly on the filename for csv detection, and we’re relying
> > > on our AutodetectReader to identify the charset.  It would be really
> > > useful for us to be able to detect:
> > >
> > > 1) A csv/tsv file vs a regular .txt file by content heuristics
> > > 2) The parameters: delimiter, escape and quote characters
> > >
> > >   We realize that no detection will be perfect, but we have two questions:
> > >
> > > 1) Do you have any pointers for this kind of thing?
> > > 2) If we develop it, would you want to put it in commons-csv or should
> > > we leave it in Tika?  I'm not sure, yet, if there'd be a clean/useful
> > > way to integrate this without using a charset detector...but we can
> > > hold off on that for now.
> > >
> > >   Thank you for all of your fantastic work!
> > >
> > >Cheers,
> > >
> > >Tim
> > >
> > > -
> > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: user-h...@commons.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: Apache Common Net issue

[sebb]

On Tue, 19 Feb 2019 at 14:23, Walter Heestermans (TME)
 wrote:
>
> Using Commons Net 3.3

The current release is 3.6

Please try with that version, and if there is still a problem, feel
free to raise a JIRA issue.

> public boolean storeFileToFTPServer(FTPTransferDetails details, byte[] data, 
> String fileName, int fileType){
>FTPClient ftpClient = new FTPClient();
>ftpClient.setConnectTimeout(5000);
>boolean completed = false;
>OutputStream outputStream = null;
>int attempts = 0;
>do {
>   try {
>  LOG.info(attempts+ ": connecting");
>  ftpClient.connect(details.getHostname(), details.getPort());
>  LOG.info(attempts + ": connected");
>  ftpClient.login(details.getUsername(), details.getPassword());
>  LOG.info(attempts+ ": logged in");
>  ftpClient.enterLocalPassiveMode();
>  ftpClient.setFileType(fileType);  <<< We are using binary!!
>  ftpClient.sendSiteCommand("UMASK 0");
>  String secondRemoteFile = details.getDirectory() + File.separator + 
> fileName;
>
>  outputStream = ftpClient.storeFileStream(secondRemoteFile);
>  LOG.info("writing stream");
>  outputStream.write(data);
>  outputStream.close();
>  LOG.info("Stream closed");
>  completed = ftpClient.completePendingCommand();
>  if (completed) {
> LOG.info("File transfer successfully completed for " + fileName + 
> ":Host=" + details.getHostname());
> break;
>  } else if(attempts==MAX_ATTEMPTS-1){
> LOG.info("File transfer waiting to complete for " + fileName + 
> ":Host=" + details.getHostname());
> return false;
>  }
>   }
>   catch (Exception ex) {
> 
>
> The above code is sued to FTP data in UTF-8 format, but some Turkish and 
> Polish characters are not transferred correctly. What are possible causes of 
> this?
>
> Met vriendelijke groet / With kind regards,
> Walter Heestermans
>
>
>
> This e-mail may contain confidential information. If you are not an addressee 
> or otherwise authorised to receive this message, you should not use, copy, 
> disclose or take any action based on this e-mail. If you have received this 
> e-mail in error, please inform the sender promptly and delete this message 
> and any attachments immediately.

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

Re: [commons-cli] handling properties files as default . . .

[sebb]

On Sun, 10 Feb 2019 at 22:30, Albretch Mueller  wrote:
>
> On 2/10/19, P. Ottlinger  wrote:
> > Another way to help out (from the ASF universe) would be:
> > https://tamaya.apache.org/
>
>  I did take a look at tamaya:
>
>  https://tamaya.apache.org/features.html
> ~
>  To me having to go:
>
>  Configuration config = Configuration.builder()
>   .withDefaultPropertySources()
>   .addPropertySources(new MyCustomPropertySource())
>   .withDefaultConverters()
>   .build();
>
>  is a nonsensical and wasteful overkill. What is this useful for,
> exactly? Are there actual use cases that kind of coding relates to?
> ~
> On 2/9/19, Remko Popma  wrote:
> > Picocli has a pluggable default provider
> > (https://picocli.info/#_default_provider), so it should be fairly
> > straightforward to implement what you describe.
>
>  I also spent some time taking a look at picocli and it seems to me
> like some other kind of an overkill:
>
>  13.1. Registering Subcommands Programmatically
>  Subcommands can be registered with the CommandLine.addSubcommand
> method. You pass in the name of the command and the annotated object
> to populate with the subcommand options. The specified name is used by
> the parser to recognize subcommands in the command line arguments.
>
>  CommandLine commandLine = new CommandLine(new Git())
> .addSubcommand("status",   new GitStatus())
> .addSubcommand("commit",   new GitCommit())
> .addSubcommand("add",  new GitAdd())
> .addSubcommand("branch",   new GitBranch())
> .addSubcommand("checkout", new GitCheckout())
> .addSubcommand("clone",new GitClone())
> .addSubcommand("diff", new GitDiff())
> .addSubcommand("merge",new GitMerge())
> .addSubcommand("push", new GitPush())
> .addSubcommand("rebase",   new GitRebase())
> .addSubcommand("tag",  new GitTag());
>
>  It is strongly recommended that subcommands have a @Command
> annotation with name and description attributes.
> ~
> > It also has other nice features that you might be interested in, like usage
> > help with ANSI colors, ... and much
> > more.
>
>  Does it come with ANSI colors? Will it also dance the macarena for me?
>
>  I can't even get what is the point of going through such hoops, when,
> to me, all you need is for a HashMap to be returned
> to you. Users shouldn’t be forced to enter command line arguments in a
> strict way and order and they should be able to chose the character
> encoding of the data they will be feeding into a program (you can’t
> expect for every text on a corpus to be encoded as ASCII or UTF-8).To
> me this is all there should be to such an utility.
>
>  Command line arguments are interpreted as strings in the local
> character encoding anyway, right? You would take it from there,
> interpreting those sequences of characters with whichever semantics
> your code needs to define:
>
>  HashMap HMSSAr ...
>
>  String[] aIVal00 = HMSSAr.get("--int-val00");
>  int iVal00 = (new Integer(aVal00[0])).intValue();
>
>  String[] aLVal02 = HMSSAr.get("--long-val02");
>  long lVal02 = (new Integer(aLVal02[0])).longValue();
>
>  String[] aSAr = HMSSAr.get("--strings-ar00");
>  KCommandObjects KCObjs = new KcommandObjects[aSAr.length];
>  HashMap HMSI = new HashMap();
>  for(int k = 0; (k < aSAr.length) ;++k){
>HMSI.put(aSAr[k], k);
>KCObjs[k] = Class.forname(aSAr[k]).newInstance();
>  }// k [0, aSAr.length)
>
>  . . .
>
>  I am half way into finishing such a thing, which I thought someone
> must had done already. Then I will try to integrate with commons-cli
> or put it out there.
>
>  I would like to still understand why is it that there exist so many
> libraries which complicate such matters and why is it that java itself
> doesn't offer a basic option like the one I have described.

Unfortunately CLI parsing *is* quite complicated.

For example, how do you handle missing parameters?
Assume -a, -b, -c all take one parameter.
How do you parse:

$ sample -a one -b -c two

Is that:
-a => one
-b => -c
rest: two

Or does that cause a parsing error, because -b has no parameter?

What if -b has an optional parameter?
Does that mean -c is set to two?

As I recall, there are various different syntaxes for CLI lines, and
these handle the above example in different ways.
I'm not even sure there are any standards for these syntaxes.
This makes it all rather messy and complicated.

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

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

Re: VALIDATOR-Issues while upgrading VALIDATOR JAR

[sebb]

On Mon, 4 Feb 2019 at 09:11, Ananda Krishna Sridhar
 wrote:
>
> Hi,
>
> Recently we have upgraded Apache Commons validator jar to version 1.6 in our 
> product after which we are seeing the below exception:
> java.lang.IllegalArgumentException: Resources cannot be null.

Please provide the full exception trace - or at least the lines that
relate to Commons Validator.

Exceptions such as the one above can have various different causes.

> Note:We have added all the required dependencies for this jar as mentioned in 
> the below link:
> https://commons.apache.org/proper/commons-validator/dependencies.html
>
> Can you please guide us on this.
>
> Regards,
> Ananda Krishna S
>

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

Re: [openpgp] OpenPGP update?

[sebb]

On Mon, 21 Jan 2019 at 22:42, Andreas Beeker  wrote:
>
> > You have to use https: in order to have write access.
> > http: is read-only.
>
> Thank you sebb for pointing this out.
>
> It's working now and I've created a Jenkins job to keep the snapshot repo 
> uptodate:
> https://builds.apache.org/view/P/view/POI/job/POI-Commons-OpenPGP/
>
> I didn't find a Jenkins subfolder for the commons parts and so put it under 
> POI
> for the time being ...
>
> I hope this was ok, after asking for someone to push the changes, I was 
> redirected to myself ...
>
> I don't intend to do a release for now, having openpgp in the snapshot repo 
> is sufficient for
> using it in our release process

Huh?

ASF releases must not depend on a SNAPSHOT.

> and I'm not familiar with the commons release procedure,
> let alone being far away from the PMC.
>
> Andi
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [openpgp] OpenPGP update?

[sebb]

On Sat, 19 Jan 2019 at 23:08, Andreas Beeker  wrote:
>
> Hi Gilles,
>
> sorry for not responding immediately, but I had to sort out something on my 
> other projects first.
>
> > The Commons PMC has voted write-access to all Apache committers.
> > [It does not necessarily work right away; please test.]
>
> I've tried to commit, but to no avail - see the log below [1].
>
> I'm usually dealing with a maintained branch of the commons project (like 
> commons-compress), so it would be fine for me, if you commit the patch 
> without trying to fix the svn permissions, but of course I'll retry it 
> otherwise.
>
> Best wishes,
> Andi
>
>
> [1]
>
> kiwiwings:~/project/commons-openpgp$ svn status
> ?   .idea
> ?   svn-commit.tmp
>
> --- Changelist 'SANDBOX-508 - OpenPGP - Upgrade bouncycastle':
> M   pom.xml
> M src/main/java/org/apache/commons/openpgp/BouncyCastleKeyRing.java
> M 
> src/main/java/org/apache/commons/openpgp/BouncyCastleOpenPgpStreamingSignatureVerifier.java
> M 
> src/main/java/org/apache/commons/openpgp/BouncyCastleOpenPgpStreamingSigner.java
>
>
> kiwiwings:~/project/commons-openpgp$ svn info
> Path: .
> Working Copy Root Path: /home/kiwiwings/project/commons-openpgp
> URL: http://svn.apache.org/repos/asf/commons/sandbox/openpgp/trunk

You have to use https: in order to have write access.
http: is read-only.

> Relative URL: ^/commons/sandbox/openpgp/trunk
> Repository Root: http://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1851691
> Node Kind: directory
> Schedule: normal
> Last Changed Author: sebb
> Last Changed Rev: 1556339
> Last Changed Date: 2014-01-07 21:12:37 +0100 (Di, 07 Jan 2014)
>
>
> kiwiwings:~/project/commons-openpgp$ svn up
> Updating '.':
> At revision 1851691.
>
>
> kiwiwings:~/project/commons-openpgp$ svn commit
> svn: E175013: Commit failed (details follow):
> svn: E175013: Access to '/repos/asf/!svn/me' forbidden
> svn: E175013: Your commit message was left in a temporary file:
> svn: E175013: '/home/kiwiwings/project/commons-openpgp/svn-commit.2.tmp'
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: Help with migrating one of OpenJPA classes to commons-collections4

[sebb]

On Mon, 17 Dec 2018 at 15:38, Gary Gregory  wrote:
>
> I am on the road driving this week, my availability is limited.
>
> WRT being a RM, I think you need PMC karma for that. Sebb might be able to
> confirm.

Creating the dist/dev release candidate only requires project
committer karma; Commons requires the same for dist/release

I don't know about Nexus; I imagine at least LDAP commons committer
membership is required.

There's no harm in trying to create an RC.

> Gary
>
> On Mon, Dec 17, 2018, 03:59 Gilles 
> > Hi.
> >
> > On Mon, 17 Dec 2018 15:12:16 +0700, Maxim Solodovnik wrote:
> > > Hello Gary,
> > >
> > > Is there any progress? :)
> >
> > Suggestion: Be the release manager of 4.3.
> >
> > Regards,
> > Gilles
> >
> > >
> > > On Tue, 4 Dec 2018 at 00:07, Gary Gregory 
> > > wrote:
> > >
> > >> [...]
> >
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >

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

Re: [net] Version 3.7

[sebb]

On 21 August 2018 at 18:10, eddma01  wrote:
> Is there a date when commons-net 3.7 is estimated to be released?

Not as yet.

> Need to move away from vulnerability in 3.6.
>

Which vulnerability?

>
> --
> Sent from: 
> http://apache-commons.680414.n4.nabble.com/Commons-User-f735979.html
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: commons-lang class JsonToStringStyle does not escape double quote in a string value

[sebb]

Ticket exists:

https://issues.apache.org/jira/browse/LANG-1395

No patch as yet.

On 9 May 2018 at 13:46, Martin Gainty  wrote:
> can you submit a JIRA ticket with patch?
>
>
> Martin
>
> 
> From: Jim Gan 
> Sent: Tuesday, May 8, 2018 8:10 PM
> To: user@commons.apache.org
> Subject: commons-lang class JsonToStringStyle does not escape double quote in 
> a string value
>
> If string value contains double quote,   JsonToStringStyle generates
> invalid json string.
>
> Here is the detail :
>
> The code at line 2609  needs to escape the double quote before appending it
> to the buffer.
>
>
> https://github.com/apache/commons-lang/blob/c614fbcc79615f93d2c60a153db6e82d7474c425/src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
> [https://avatars3.githubusercontent.com/u/47359?s=400=4]
>
> apache/commons-lang
> github.com
> commons-lang - Mirror of Apache Commons Lang
>
>
>
>
> line 2608 and line 2609
>
>private void appendValueAsString(final StringBuffer buffer,
> final String value) {
> buffer.append('"').append(value).append('"');
> }
>
>
> Jim

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

Re: [exec] Executed command can't open file argument

[sebb]

On 3 May 2018 at 22:35, Mark Trolley <marktrol...@gmail.com> wrote:
> On Thu, May 3, 2018 at 4:34 PM, sebb <seb...@gmail.com> wrote:
>> On 3 May 2018 at 17:18, Mark Trolley <marktrol...@gmail.com> wrote:
>> It may be that quotes are being added to the parameter - I assume the
>> file name does not have quotes.
>>
>> Quoting is necessary for protecting spaces on a shell command-line,
>> but not when the parameters are being passed directly to a program as
>> separate parameters.
>>
> This lead me to the solution, I had to use addArgument with
> handleQuoting set to false and it started working. Thanks everyone for
> your help.

Thanks for letting us know it's been solved.

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

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

Re: [exec] Executed command can't open file argument

[sebb]

On 3 May 2018 at 17:18, Mark Trolley  wrote:
> I'm not sure how to respond to my own thread so I am hoping sending a
> reply to my own sent message will do it.
>
> I experimented and discovered the problem is in the spaces in the
> filename argument. If the file is renamed to not have spaces the
> execution succeeds. However, this doesn't work for my usecase because
> I want to parse the filename for information to get metadata I'll use
> later.

It may be that quotes are being added to the parameter - I assume the
file name does not have quotes.

Quoting is necessary for protecting spaces on a shell command-line,
but not when the parameters are being passed directly to a program as
separate parameters.

It would be useful to know if the AtomicParsley app puts quotes around
file names in error messages.

I seem to remember some issues with inappropriate quoting of
parameters a long time ago, but I thought they had been resolved.
Maybe not. Or maybe the issue is with the substitution map processing
- can you try without that?

Might also be worth trying the command-line approach.

BTW for checking parameters a script is not ideal because the shell
may get involved.

It's easy enough to write a Java program to print out its parameters
(or use one of the scripting languages).
That should behave closer to the AtomicParsley app.

> @Guang Chao - I can't respond directly to your message because I
> didn't receive it in my mail, but I changed the command being executed
> to "/usr/bin/whoami" and confirmed that the Java code is running as my
> user, so there is no permission issue.
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Travel Assistance applications for ApacheCon NA 2018 are now open!

[Sebb]

The Travel Assistance Committee (TAC) are pleased to announce that travel 
assistance applications for ApacheCon NA 2018 are now open!

We will be supporting ApacheCon NA Montreal, Canada on 24th - 29th September 
2018

TAC exists to help those that would like to attend ApacheCon events, but are 
unable to do so for financial reasons.
For more info on this years applications and qualifying criteria, please visit 
the TAC website at < http://www.apache.org/travel/ >. Applications are now open 
and will close 1st May.

Important: Applications close on May 1st, 2018. Applicants have until the 
closing date above to submit their applications (which should contain as much 
supporting material as required to efficiently and accurately process their 
request), this will enable TAC to announce successful awards shortly afterwards.

As usual, TAC expects to deal with a range of applications from a diverse range 
of backgrounds. We therefore encourage (as always) anyone thinking about 
sending in an application to do so ASAP.  
We look forward to greeting many of you in Montreal

Kind Regards,
Gavin - (On behalf of the Travel Assistance Committee)
-- 

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

Re: [lang]

[sebb]

Thanks; fixed

On 13 November 2017 at 14:11, i...@flyingfischer.ch
 wrote:
> In case nobody has realized yet:
>
> The download links under
> https://commons.apache.org/proper/commons-lang/download_lang.cgi are
> broken since the release of Apache commons-lang3-3.7.
>
> Markus
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [net] Problem with completePendingCommand and large files > 600MB

[sebb]

Note: curl supports an FTP range parameter.
It seems it does this by sending ABOR after the required data has arrived.

However I just tried and it does not work with the server I used.

You could try using it with your server and see if it works:

$ curl -v -r nnn-mmm -o file URL

If so you may be able to use ABOR in your app for that server.


On 25 October 2017 at 23:57, sebb <seb...@gmail.com> wrote:
> What you are doing is stopping reading from the server before the file
> has been fully sent.
> Unless the server is expecting that, it may complain (the fact that it
> works for smaller files may be because the server has already sent the
> data).
>
> AFAICT there is no standard way to tell the server to only send a
> portion of the file.
>
> A work-round would be to fetch all the data but stop writing it to
> disk when you have got what you want.
>
> Another way might be to cancel the transfer after enough data has been 
> received.
> However that relies on the server being able to process control
> channel requests whilst sending data.
>
> Or just live with the error message.
>
> It's not a bug in NET.
>
>
> On 25 October 2017 at 23:30, Bernd Eckenfels <e...@zusammenkunft.net> wrote:
>> 426 sounds like a server error, did you try to use a different client with 
>> your server?
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> 
>> From: SeungWook Kim <seungwook@weather.com>
>> Sent: Wednesday, October 25, 2017 6:34:02 PM
>> To: user@commons.apache.org
>> Subject: [net] Problem with completePendingCommand and large files > 600MB
>>
>> Hi,
>>   I am having a problem with commons-net version* 3.6* and with large files
>>> 600MB and offset and length that does not include the whole file.
>>
>> I have included the test code below that appears to fail with large files >
>> 600 MB and an offset and length that does not include the whole file. If I
>> choose a smaller file like 90KB with offset and length, it works
>> successfully. If I choose a large file > 600MB with offset and length that
>> INCLUDES the entire file, it also works successfully. The
>> completePendingCommand replies back with "426 Failure writing network
>> stream" when the file is large > 600MB AND the offset and length is not the
>> entire file.
>>
>>   I believe this is a bug but not sure. I did a quick look in the postings
>> and did not see anything that is exactly like it. Any feedback is greatly
>> appreciated.
>>
>>
>>
>> *** Need to specify serverName, userName,...absOutputFile below***
>> ***Start of Test code***
>>
>> public class FtpTest {
>> private static Logger log = LoggerFactory.getLogger(FtpTest.class);
>>
>> private static final int DEFAULT_TIMEOUT = 10*1000;
>>
>> @Before
>> public void setup() {
>>
>> }
>>
>> @Test
>> public void test() {
>> String serverName = "***";
>> String userName = "***";
>> String password = "***";
>> String absRemoteFileName = "***";
>> final long offset = ***;
>> final long length = ***;
>> String absOutputFile = "***";
>>
>> FTPClient ftpClient = new FTPClient();
>> try {
>> ftpClient.connect(serverName);
>> int reply = ftpClient.getReplyCode();
>> if (!FTPReply.isPositiveCompletion(reply)) {
>> String lastReply = ftpClient.getReplyString();
>> fail(lastReply);
>> }
>> ftpClient.addProtocolCommandListener(new
>> PrintCommandListener(new PrintWriter(System.out),
>> true));
>> ftpClient.setKeepAlive(true);
>> ftpClient.setSoTimeout(DEFAULT_TIMEOUT); //set to 10 seconds
>> //turn on SO_LINGER w/ timeout of 0 to cause connection to be
>> aborted immediately and to discard any
>> // pending data.
>> ftpClient.setSoLinger(true, 0);
>> if(ftpClient.login(userName, password)) {
>> ftpClient.enterLocalPassiveMode();
>> if(FTPReply.isPositiveCompletion(ftpClient.getReplyCode()))
>> {
>> log.info("Successfully connected in Passive Mode and
>> logged into {}", serverName);
>>
>> ftpClient.setFileTransferMode(FTP.STREAM_TRANSFER_MODE);
>> ftpCli

Re: [net] Problem with completePendingCommand and large files > 600MB

[sebb]

What you are doing is stopping reading from the server before the file
has been fully sent.
Unless the server is expecting that, it may complain (the fact that it
works for smaller files may be because the server has already sent the
data).

AFAICT there is no standard way to tell the server to only send a
portion of the file.

A work-round would be to fetch all the data but stop writing it to
disk when you have got what you want.

Another way might be to cancel the transfer after enough data has been received.
However that relies on the server being able to process control
channel requests whilst sending data.

Or just live with the error message.

It's not a bug in NET.


On 25 October 2017 at 23:30, Bernd Eckenfels  wrote:
> 426 sounds like a server error, did you try to use a different client with 
> your server?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: SeungWook Kim 
> Sent: Wednesday, October 25, 2017 6:34:02 PM
> To: user@commons.apache.org
> Subject: [net] Problem with completePendingCommand and large files > 600MB
>
> Hi,
>   I am having a problem with commons-net version* 3.6* and with large files
>> 600MB and offset and length that does not include the whole file.
>
> I have included the test code below that appears to fail with large files >
> 600 MB and an offset and length that does not include the whole file. If I
> choose a smaller file like 90KB with offset and length, it works
> successfully. If I choose a large file > 600MB with offset and length that
> INCLUDES the entire file, it also works successfully. The
> completePendingCommand replies back with "426 Failure writing network
> stream" when the file is large > 600MB AND the offset and length is not the
> entire file.
>
>   I believe this is a bug but not sure. I did a quick look in the postings
> and did not see anything that is exactly like it. Any feedback is greatly
> appreciated.
>
>
>
> *** Need to specify serverName, userName,...absOutputFile below***
> ***Start of Test code***
>
> public class FtpTest {
> private static Logger log = LoggerFactory.getLogger(FtpTest.class);
>
> private static final int DEFAULT_TIMEOUT = 10*1000;
>
> @Before
> public void setup() {
>
> }
>
> @Test
> public void test() {
> String serverName = "***";
> String userName = "***";
> String password = "***";
> String absRemoteFileName = "***";
> final long offset = ***;
> final long length = ***;
> String absOutputFile = "***";
>
> FTPClient ftpClient = new FTPClient();
> try {
> ftpClient.connect(serverName);
> int reply = ftpClient.getReplyCode();
> if (!FTPReply.isPositiveCompletion(reply)) {
> String lastReply = ftpClient.getReplyString();
> fail(lastReply);
> }
> ftpClient.addProtocolCommandListener(new
> PrintCommandListener(new PrintWriter(System.out),
> true));
> ftpClient.setKeepAlive(true);
> ftpClient.setSoTimeout(DEFAULT_TIMEOUT); //set to 10 seconds
> //turn on SO_LINGER w/ timeout of 0 to cause connection to be
> aborted immediately and to discard any
> // pending data.
> ftpClient.setSoLinger(true, 0);
> if(ftpClient.login(userName, password)) {
> ftpClient.enterLocalPassiveMode();
> if(FTPReply.isPositiveCompletion(ftpClient.getReplyCode()))
> {
> log.info("Successfully connected in Passive Mode and
> logged into {}", serverName);
>
> ftpClient.setFileTransferMode(FTP.STREAM_TRANSFER_MODE);
> ftpClient.setFileType(FTP.BINARY_FILE_TYPE);
> ftpClient.setRestartOffset(offset);
> File writeToFile = new File(absOutputFile);
>
> try (InputStream inputStream =
> ftpClient.retrieveFileStream(absRemoteFileName);
>  OutputStream outputStream =
> FileUtils.openOutputStream(writeToFile)) {
> if(inputStream == null || outputStream == null) {
> fail("One of the input/output stream is null");
> }
> final int BUFFER_SIZE = 4096;
> byte[] buffer = new byte[BUFFER_SIZE];
> int bytesRead;
> int len = (int)length;
> int bufferSize = length > BUFFER_SIZE ? BUFFER_SIZE
> : len;
> while ((bytesRead = inputStream.read(buffer, 0,
> bufferSize)) != -1) {
> len -= bytesRead;
> bufferSize = len > BUFFER_SIZE ? BUFFER_SIZE :
> len;
>
> outputStream.write(buffer, 0, bytesRead);
>
> 

Re: Release BCEL 6.1?

[sebb]

On 12 September 2017 at 14:05, Andreas Sewe  wrote:
> Hello Benedikt,
>
>>> is there anything I can do to help?
>>
>> No, not really. There where some discussions on the ML regarding breaking 
>> changes. I’m not sure we reached consensus there. I’ll probably go an push 
>> out RC1 to see how people feel about the breaking changes. Would be nice, I 
>> you could share your thoughts about that too.
>
> pushing out an RC1 first is a good idea (does "pushing out" include
> deploying to Maven Central?).

No, only formal releases go to MC...

> As SpotBugs uses BCEL quite heavily, this
> would give us the opportunity to report any breakage early.

... However the RC will be available at a public URL for devs to test.

The URL is not published to the general public.
If you join the dev list you can help to test the RC from the info in
the RC VOTE.

CI builds are also normally available via the ASF snapshot repo.
Ask on the dev list if you cannot find them.

>>> We at SpotBugs are holding our breath [1] for an official BCEL 6.1.0
>>> release, which we would like to include in our own upcoming 3.1.0
>>> release -- rather than including a self-built BCEL 6.1.0 snapshot.
>>
>> Sorry, I’m doing this on my spare time and I had some busy weeks lately. 
>> I’ll try to get to it this weekend.
>
> No problem. I'm also just a weekend committer to SpotBugs, so we are in
> the same boat.
>
> Best wishes,
>
> Andreas
>
> --
> Codetrails GmbH
> The best code possible
>
> Robert-Bosch-Str. 7, 64293 Darmstadt
> Phone: +49-6151-276-7092
> Mobile: +49-170-811-3791
> http://www.codetrails.com/
>
> Managing Director: Dr. Marcel Bruch
> Handelsregister: Darmstadt HRB 91940
>

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

Re: [digester] Typo in legacy download links

[sebb]

Hopefully now fixed

On 6 June 2017 at 15:16, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> It looks like the download links for older versions aren't pointing to
> the right place on this page:
> https://commons.apache.org/proper/commons-digester/download_digester.cgi
>
> I needed a copy of commons-digester-2.1-bin.tar.gz and the link
> instead points to commons-digester3-3.1-bin.tar.gz
>
> The ZIP and source links also seem to be broken similarly: they all
> have a stray "3" in the middle of their URLs.
>
> Thanks,
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJZNrlJAAoJEBzwKT+lPKRYWRsQALghBMfr0trv9zk0anvjTv+I
> gTRPJTsLwORe/d+kQVmZItxiQzsGBJ8DH8j7ZSXIjdl0qcAVPC69N58uXatB2+Fj
> RXKZm04Z081a3xfoIJr+EAOLntQhpuJODqDV8DL9zwzTw4VwVNOECx3okGcW/12i
> 7YrP+ngy9Z2Zm6FOsrm/2/pf03N31zb8Qo2ErhzOGrP2OyxfUAlZ14OJNFDaYIjj
> JwMPqEvfAJG3Ki3Z2qeyz/CyNC4N/Ln2BTYqQ+STONl+GwET9eI0iLQQzsAdfp5P
> SdconpSHVoEXhxAcYBblE0rYDjxtbG+mh+JdYU92AXLqiIeF4WMQzYt40Aeo+wXE
> 8H0MR8QHG7P6ZmnNjGXNLINvlAZYm4i2LYY6bU+0EInUTKGApmiUmP0J9hJ6pY/8
> /wiNm88hjgTqN61Jx5Kb5HHzPLsJShKKuAI+N0Ak1wPGRe44qhDt1ysFekVJIRkk
> 1ig2datzVDtGeEGQ5mmtMc+tdMNXcg+vDntQYt3NilSxKqUaFivIpWVUu5LXekY9
> 8Ozp2L4ZjWjgviCsBEQ8PFOTiplMtY3EhZlAm5DdBnQVowV5Tfii3I4gTqI5PCNq
> eGQsj738u1QwEj0gfH5RVQIdWh3bFWmRxALf+0L5zP/SKvw1naetRklJvgDGtGgw
> CVlA127QprKKJxztb0jH
> =glDw
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: Apache's Maven repository missing commons-io, most versions

[sebb]

On 30 March 2017 at 16:29, Matt Sicker <boa...@gmail.com> wrote:
> A lot of old artifacts uses the groupId == artifactId convention. I don't
> know when that changed to using org.apache.foo as the groupId, but I'm
> guessing it was sometime around the advent of Maven Central.

Possibly.

Commons components are gradually moving from commons-abc to
org.apache.commons.abc.
However that can only be done if the Java package name is also changed.
As that is disruptive, it's only done when an API breakage is essential.

https://wiki.apache.org/commons/MavenAndClasspath

> On 30 March 2017 at 10:26, Russell Bateman <r...@windofkeltia.com> wrote:
>
>> Wow. I believe the problem is that I'm a blind idiot. I had been trying to
>> use:
>>
>> 
>>   *org.apache.commons*
>>   commons-io
>>   2.5
>> 
>>
>> The groupIdwas wrong and I just wasn't seeing it. (In my defence, there
>> are some Apache groupIds that include "apache" in path elements, like
>> Apache /commons-csv/, I'm used to looking at.)
>>
>> Many thanks to sebb for his patience.
>>
>>
>>
>> On 03/30/2017 08:35 AM, Dave Newton wrote:
>>
>>> On Thu, Mar 30, 2017 at 10:27 AM, sebb <seb...@gmail.com> wrote:
>>>
>>>> On 30 March 2017 at 15:09, Russell Bateman <r...@windofkeltia.com>
>>>> wrote:
>>>> 
>>>>  commons-io
>>>>  commons-io
>>>>  2.5
>>>> 
>>>>
>>>> Can you give me a Maven replacement for what's at:
>>>>> https://mvnrepository.com/artifact/commons-io/commons-io/2.5
>>>>>
>>>>> I don't understand why this page exists since it clearly doesn't lead to
>>>>> fulfilling my build's need for /commons-io-2.5.jar/. I use Maven a lot
>>>>> and
>>>>> have for a long time, but I'm completely stumped by this issue.
>>>>>
>>>> This worked fine for me; I guess I'm not understanding the issue.
>>>
>>> Dave
>>>
>>> -
>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: user-h...@commons.apache.org
>>>
>>>
>>
>
>
> --
> Matt Sicker <boa...@gmail.com>

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

Re: Apache's Maven repository missing commons-io, most versions

[sebb]

On 30 March 2017 at 15:09, Russell Bateman <r...@windofkeltia.com> wrote:
> Sebb,
>
> Thanks for responding, but I probably need some help here making your
> suggestion(s) work. To begin with,
>
> http://repo.maven.org/maven2/commons-io/commons-io/
>
> yields nothing in the browser or using curl:
>
> ~/Downloads $ curl http://repo.maven.org/maven2/commons-io/commons-io/
> curl: (6) Could not resolve host: repo.maven.org

Sorry, that should be

http://repo.maven.apache.org/maven2/commons-io/commons-io/

or
http://repo1.maven.org/maven2/commons-io/commons-io/
seems to work

But you should not need the URL if you are using Maven to build.

> Do I need something special in /~/.m2/settings.xml/? (I don't have one.) or
> in my /pom.xml/ file(s)?


commons-io
commons-io
2.5


> If it's only that the groupIdhas changed, what is
> it?

As above.
[It's not really changed - the one you mention at the start of this
thread is not currently used.]

> Can you give me a Maven replacement for what's at:
> https://mvnrepository.com/artifact/commons-io/commons-io/2.5
>
> I don't understand why this page exists since it clearly doesn't lead to
> fulfilling my build's need for /commons-io-2.5.jar/. I use Maven a lot and
> have for a long time, but I'm completely stumped by this issue.

You just need to include the correct dependency as above.

> Thanks.
>
>
>
>
>
> On 03/29/2017 06:24 PM, sebb wrote:
>>
>> On 30 March 2017 at 01:20, sebb <seb...@gmail.com> wrote:
>>>
>>> Try
>>>
>>> http://repo.maven.org/maven2/commons-io/commons-io/
>>>
>>> IO used to have a different group id.
>>
>> I mean, still has a different gid.
>>
>> The entry under
>> https://repo.maven.apache.org/maven2/org/apache/commons/commons-io/1.3.2
>>
>> is a relocation pom. Probably that version was accidentally released
>> with the wrong gid.
>>
>>> On 30 March 2017 at 00:31, Russell Bateman <r...@windofkeltia.com> wrote:
>>>>
>>>> As I attempt to build, I find
>>>>
>>>>
>>>> https://repo.maven.apache.org/maven2/org/apache/commons/commons-io/2.5/commons-io-2.5.jar
>>>>
>>>> to yield a 404. When I go look there, only 1.3.2 exists and even that,
>>>> though there are JARs galore, has a /pom.xml/ that basically refers
>>>> Maven to
>>>> Maven Central. Must I then put something into my /pom.xml/ that deters
>>>> Maven
>>>> from ever looking for anything in /repo.maven.apache.org/? It seems
>>>> strange
>>>> that Apache would offer a Maven repository that's missing an important
>>>> library (for me, at least). Until now, I haven't had this experience
>>>> with
>>>> other Apache Commons libraries.
>>>>
>>>> Please advise, thank you!
>>>>
>>>> Russ
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>

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

Re: Apache's Maven repository missing commons-io, most versions

[sebb]

On 30 March 2017 at 01:20, sebb <seb...@gmail.com> wrote:
> Try
>
> http://repo.maven.org/maven2/commons-io/commons-io/
>
> IO used to have a different group id.

I mean, still has a different gid.

The entry under
https://repo.maven.apache.org/maven2/org/apache/commons/commons-io/1.3.2

is a relocation pom. Probably that version was accidentally released
with the wrong gid.

> On 30 March 2017 at 00:31, Russell Bateman <r...@windofkeltia.com> wrote:
>> As I attempt to build, I find
>>
>> https://repo.maven.apache.org/maven2/org/apache/commons/commons-io/2.5/commons-io-2.5.jar
>>
>> to yield a 404. When I go look there, only 1.3.2 exists and even that,
>> though there are JARs galore, has a /pom.xml/ that basically refers Maven to
>> Maven Central. Must I then put something into my /pom.xml/ that deters Maven
>> from ever looking for anything in /repo.maven.apache.org/? It seems strange
>> that Apache would offer a Maven repository that's missing an important
>> library (for me, at least). Until now, I haven't had this experience with
>> other Apache Commons libraries.
>>
>> Please advise, thank you!
>>
>> Russ

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

Re: Apache's Maven repository missing commons-io, most versions

[sebb]

Try

http://repo.maven.org/maven2/commons-io/commons-io/

IO used to have a different group id.

On 30 March 2017 at 00:31, Russell Bateman  wrote:
> As I attempt to build, I find
>
> https://repo.maven.apache.org/maven2/org/apache/commons/commons-io/2.5/commons-io-2.5.jar
>
> to yield a 404. When I go look there, only 1.3.2 exists and even that,
> though there are JARs galore, has a /pom.xml/ that basically refers Maven to
> Maven Central. Must I then put something into my /pom.xml/ that deters Maven
> from ever looking for anything in /repo.maven.apache.org/? It seems strange
> that Apache would offer a Maven repository that's missing an important
> library (for me, at least). Until now, I haven't had this experience with
> other Apache Commons libraries.
>
> Please advise, thank you!
>
> Russ

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

[ANNOUNCE] Apache Commons Validator 1.6 released

[sebb]

The Apache Commons Team is pleased to announce the release of Apache
Commons Validator 1.6

Apache Commons Validator provides the building blocks for both client side
validation and server side data validation. It may be used standalone or
with a framework like Struts.

The main changes are:

* Modulus Ten Check Digit Implementation
* Generic CreditCard validation (syntax and checkdigit only; does not check IIN)
* CreditCard validation specification by numeric range

Details of all the changes in 1.6 can be found in the changelog:

http://commons.apache.org/proper/commons-validator/changes-report.html

1.6 is fully binary compatible to the last release. No client code
changes are required to migrate from version 1.4.x (or later) to 1.6.
The minimum required JDK version for this release is 1.6.

However note that the Javascript code has been dropped, see
https://issues.apache.org/jira/browse/VALIDATOR-371

Source and binary distributions are available for download from the Apache
Commons download site:

http://commons.apache.org/proper/commons-validator/download_validator.cgi

When downloading, please verify signatures using the KEYS file available at

http://www.apache.org/dist/commons/KEYS

Alternatively the release can be fetched from Maven Central:


  commons-validator
  commons-validator
  1.6


For complete information on Commons Validator, including instructions on
how to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons Validator website:

http://commons.apache.org/proper/commons-validator/

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

[ANNOUNCE] Apache Commons NET 3.6 released

[sebb]

The Apache Commons team are pleased to announce the release of
Commons Net version 3.6.

This is a bug fix release. All users are encouraged to upgrade to 3.6.

For details of the fixes and new features please see:

http://www.apache.org/dist/commons/net/RELEASE-NOTES.txt

[Also included with the binary and source archives]

The changes are also available at:
http://commons.apache.org/net/changes-report.html

Binary and source archives are available from:

http://commons.apache.org/proper/commons-net/download_net.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

Please see the Apache Commons Net website for full details:

http://commons.apache.org/net/

The Maven coordinates are:

commons-net
commons-net
3.6

Enjoy!

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

Re: [NET] Errorhandling of "bad" FTP Servers

[sebb]

On 23 January 2017 at 07:31, Oliver Zemann  wrote:
>
>
>>> Yes, but apache commons sends first FEAT when i use autodetectUTF8(),
>>> which
>>> is imo wrong.
>>> The javadoc states that autodetectUTF8() has to be used before connect(),
>>> but i dont understand why.
>>
>> setAutodetectUTF8 only sets a flag which is consulted during connect;
>> it does not send anything to the server.
>
> When autodetectUTF8() is set to true, after the connect, apache commons net
> sends a FEAT to check if the server supports UTF8. This is what FileZilla
> does not. Therefore, with FileZilla its working.
> When i remove autodetectUTF8(true) in my code, it works. But thats no
> solution to me because i would like to have UTF8 support.
>>
>>
>>> FileZilla first connects and does the login() and after that it uses the
>>> FEAT command to check if the server supports UTF8.
>>> The server behaves "bad" of that FEAT command, because it sends 211 END
>>> but
>>> then outputs MODE Z (which should before 211 END). And FEAT is issued
>>> because of autodetectUTF8()
>>
>> That is perfectly reasonable behaviour for FileZilla and for Commons NET.
>
> commons net sends the FEAT _before_ the USER command is send. Thats a big
> difference in FileZilla and commons net.

But it does so only if setAutodetectUTF8 is true.

So another workround is not to set that.

But in any case, the server would still send the MODE Z incorrectly,
as proven by the FileZilla session log.

>>
>> No, there is no such method.
>>
>> You could try calling getReply() and catching IO errors.
>> However if there is no data to read that will likely hang.
>> It so, try setting a timeout.
>>
>> You could also try subclassing FTPClient and then you can access the
>> _controlInput_ field.
>> This is where the replies are read from.
>>
>> However reading from the control channel may cause NET to break in subtle
>> ways.
>
> Thanks, guess i will try it that way.
>>
>> AFAIK this is the first time this problem has been reported.
>> Which seems odd if there really are thousands of servers with this
>> behaviour.
>
> I did not mean "thousands of servers with this behaviour" i meant: there are
> thousands of servers i access, i can contact them and tell them they have
> broken ftp server software, but they probably simply don't care.
>
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [NET] Errorhandling of "bad" FTP Servers

[sebb]

On 22 January 2017 at 16:37, Oliver Zemann  wrote:
>
>> Please prefix the subject line with the Commons Component in future (as
>> above)
>
> Sorry, next time i will do that.
>>
>>
>> On 22 January 2017 at 09:12, Oliver Zemann 
>> wrote:
>>>
>>> Hi, i would like to know how to handle FTP Servers that do not behave
>>> like
>>> they should (or behave different than most others).
>>> For example, currently i would like to connect to one of those servers
>>> which
>>> sends " MODE Z" directly after a login (USER) which is interpreted wrong
>>> by
>>> apache commons ftp, as its assumed that there should be \d\d\d \w* like
>>> "220
>>> all good my friend"
>>> But its simply: " MODE Z"
>>>
>>> Here is a log from filezilla which can handle this behaviour:
>>> 09:58:24Trace:CFtpControlSocket::SendNextCommand()
>>> 09:58:24Befehl:USER someUser
>>> 09:58:24Trace:CFtpControlSocket::OnReceive()
>>> 09:58:24Antwort:331  [33m ~wait~ user ok, password?
>>> 09:58:24Trace:CFtpControlSocket::SendNextCommand()
>>> 09:58:24Befehl:PASS ***
>>> 09:58:25Trace:CFtpControlSocket::OnReceive()
>>> 09:58:25Antwort:230  [32m.::WAIT::. welcome!.
>>
>> The login has completed here
>
> Yes, but apache commons sends first FEAT when i use autodetectUTF8(), which
> is imo wrong.
> The javadoc states that autodetectUTF8() has to be used before connect(),
> but i dont understand why.

setAutodetectUTF8 only sets a flag which is consulted during connect;
it does not send anything to the server.

> FileZilla first connects and does the login() and after that it uses the
> FEAT command to check if the server supports UTF8.
> The server behaves "bad" of that FEAT command, because it sends 211 END but
> then outputs MODE Z (which should before 211 END). And FEAT is issued
> because of autodetectUTF8()

That is perfectly reasonable behaviour for FileZilla and for Commons NET.

> Would it be possible to read from _controlInput_ until null is returned?
> Seems like someone else encountered something with another server, and
> therefore __ lenientCheck() exists?
>>>
>>> 09:58:25Befehl:FEAT
>>> 09:58:25Trace:CFtpControlSocket::OnReceive()
>>> 09:58:25Antwort:211-Extension supported
>>> 09:58:25Antwort: MDTM
>>> 09:58:25Antwort: MDTM
>>> 09:58:25Antwort: MDTM MMDDHHMMSS[+-TZ];filename
>>> 09:58:25Antwort: SIZE
>>> 09:58:25Antwort: SITE PSWD;EXEC;SET;INDEX;ZONE;CHMOD;MSG
>>> 09:58:25Antwort: XCRC filename;start;end
>>> 09:58:25Antwort:211 End
>>> 09:58:25Status:Der Server unterstützt keine Nicht-ASCII-Zeichen.
>>> 09:58:25Status:Angemeldet
>>> 09:58:25Antwort: MODE Z
>>> 09:58:25Trace:Unexpected reply, no reply was pending. <
>>> something like this in apache commons ftp???
>>
>> Note that FileZilla detects this as an error, so clearly this is not
>> expected behaviour.
>>
>> Commons NET only looks for  a reply when one is expected, so it cannot
>> detect this.
>> AFAICS changing this would require a major rewrite.
>> Since the server appears to be broken, it's not worth doing this.
>
> That means, if a server answers a request wrong (like on that server with
> FEAT, because MODE Z should be before 211 END), all further communication
> with apache commons net ftp is impossible to that server because
> _controlInput_ is not "cleared"?
> Is there some kind of "clearControlInput()" method the user can invoke to
> "clear" all (possible) invalid data to make the ftp client more "stable"
> when it has to deal with such ftp servers? Because then i could simply call
> "clearControlInput()" each time before i send my commands.

No, there is no such method.

You could try calling getReply() and catching IO errors.
However if there is no data to read that will likely hang.
It so, try setting a timeout.

You could also try subclassing FTPClient and then you can access the
_controlInput_ field.
This is where the replies are read from.

However reading from the control channel may cause NET to break in subtle ways.

>>
>>> Some information: i dont have control over that server. I dont know what
>>> software the server is running.
>>
>> Try contacting the server maintainers to raise the issue of the
>> server's bad behaviour
>
> Unfortunately this is one of many thousands of servers, located somewhere...
> china, russia, usa etc.

AFAIK this is the first time this problem has been reported.
Which seems odd if there really are thousands of servers with this behaviour.

> I guess some of those servers are even not maintained anymore. So this is
> not a solution. I have to somehow handle those servers :(
>
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

Re: [NET] Errorhandling of "bad" FTP Servers

[sebb]

Please prefix the subject line with the Commons Component in future (as above)

On 22 January 2017 at 09:12, Oliver Zemann  wrote:
> Hi, i would like to know how to handle FTP Servers that do not behave like
> they should (or behave different than most others).
> For example, currently i would like to connect to one of those servers which
> sends " MODE Z" directly after a login (USER) which is interpreted wrong by
> apache commons ftp, as its assumed that there should be \d\d\d \w* like "220
> all good my friend"
> But its simply: " MODE Z"
>
> Here is a log from filezilla which can handle this behaviour:
> 09:58:24Trace:CFtpControlSocket::SendNextCommand()
> 09:58:24Befehl:USER someUser
> 09:58:24Trace:CFtpControlSocket::OnReceive()
> 09:58:24Antwort:331  [33m ~wait~ user ok, password?
> 09:58:24Trace:CFtpControlSocket::SendNextCommand()
> 09:58:24Befehl:PASS ***
> 09:58:25Trace:CFtpControlSocket::OnReceive()
> 09:58:25Antwort:230  [32m.::WAIT::. welcome!.

The login has completed here

> 09:58:25Trace:CFtpControlSocket::SendNextCommand()
> 09:58:25Befehl:SYST
> 09:58:25Trace:CFtpControlSocket::OnReceive()
> 09:58:25Antwort:215 Java (SE) Platform SE 6.0
> 09:58:25Trace:CFtpControlSocket::SendNextCommand()
> 09:58:25Befehl:FEAT
> 09:58:25Trace:CFtpControlSocket::OnReceive()
> 09:58:25Antwort:211-Extension supported
> 09:58:25Antwort: MDTM
> 09:58:25Antwort: MDTM
> 09:58:25Antwort: MDTM MMDDHHMMSS[+-TZ];filename
> 09:58:25Antwort: SIZE
> 09:58:25Antwort: SITE PSWD;EXEC;SET;INDEX;ZONE;CHMOD;MSG
> 09:58:25Antwort: XCRC filename;start;end
> 09:58:25Antwort:211 End
> 09:58:25Status:Der Server unterstützt keine Nicht-ASCII-Zeichen.
> 09:58:25Status:Angemeldet
> 09:58:25Antwort: MODE Z
> 09:58:25Trace:Unexpected reply, no reply was pending. <
> something like this in apache commons ftp???

Note that FileZilla detects this as an error, so clearly this is not
expected behaviour.

Commons NET only looks for  a reply when one is expected, so it cannot
detect this.
AFAICS changing this would require a major rewrite.
Since the server appears to be broken, it's not worth doing this.

> 09:58:25Antwort:211 End
> 09:58:25Trace:Unexpected reply, no reply was pending.
> 09:58:25Status:Empfange Verzeichnisinhalt...
> 09:58:25Trace:CFtpControlSocket::SendNextCommand()
> 09:58:25Trace:CFtpControlSocket::ChangeDirSend()
> 09:58:25Befehl:PWD
> 09:58:25Trace:CFtpControlSocket::OnReceive()
> 09:58:25Antwort:257 "/"  [34m<<<>>>OK<<<>>> Logged in ;).
>
> That "MODE Z" is leading to an exception when i use FTPClient::login()
> In __getReply(boolean reportReply)  i can see that its trying to convert the
> first 3 chars to a digit, which is of course impossible if its "Z MODE" and
> not a number.
>
> So i am wondering whats the best way to handle such servers? Or is this a
> bug in apache commons ftp? Do i have to implement all calls myself and dont
> rely on login() logout() etc. from apache commons to be able to handle such
> behaviours?

This seems to be a bug in the server.
It is not supposed to send unsolicited data on the command channel.

You might be able to subclass one of the FTP classes and over-ride one
of the methods so it ignores MODE Z if it's not expected.

> Some information: i dont have control over that server. I dont know what
> software the server is running.

Try contacting the server maintainers to raise the issue of the
server's bad behaviour

> Regards
> Oli
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: Why just got java.net.SocketTimeoutException: Read timed out

[sebb]

HttpClient is no longer part of Commons, see:

http://hc.apache.org/

Also, HttpClient v3.1 is now EOL; see:

http://hc.apache.org/httpclient-legacy/index.html

Please refer to the above websites for info on mailing lists etc.


On 9 January 2017 at 09:02, xiaoyu  wrote:
> Hello, everyone:
>
>I  am developing a file transport tool using httpclient V3.1
>
>Now I get "java.net.SocketTimeoutException: Read timed out" when I was 
> trying to upload a file to the sever(Tomcat V7.5.35)
> java.net.SocketTimeoutException: Read timed out
>  at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(Unknown Source)
> at java.io.BufferedInputStream.fill(Unknown Source)
> at java.io.BufferedInputStream.read(Unknown Source)
> at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
> at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
> at 
> org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
> at 
> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
> at 
> org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
> at 
> org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
> at 
> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
> at 
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
> at 
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
> at 
> com.xiaoyu.tool.transport.transport.http.HttpUploadThread.run1(HttpUploadThread.java:111)
> at 
> com.xiaoyu.tool.transport.transport.UploadFile.beginUpload(UploadFile.java:174)
> at 
> com.xiaoyu.tool.transport.transport.UploadFile.doUpload(UploadFile.java:118)
> at com.xiaoyu.tool.transport.transport.UploadFile.run(UploadFile.java:109)
> at java.lang.Thread.run(Unknown Source)
>
>But I have set server_socket_timeout to zero, which means  an infinite 
> timeout according the API
>
> HttpConnectionManagerParams params = new 
> HttpConnectionManagerParams();
> int SOCKET_NO_TIME_OUT = 0;
> params.setSoTimeout(SOCKET_NO_TIME_OUT);
>
>So why I got this excetpion here ?
>Any help would mean a lot.
>Thank you !
>
>
>
> xiaoyu
>
>
> ---
> Confidentiality Notice: The information contained in this e-mail and any 
> accompanying attachment(s)
> is intended only for the use of the intended recipient and may be 
> confidential and/or privileged of
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of 
> this communication is
> not the intended recipient, unauthorized use, forwarding, printing,  storing, 
> disclosure or copying
> is strictly prohibited, and may be unlawful.If you have received this 
> communication in error,please
> immediately notify the sender by return e-mail, and delete the original 
> message and all copies from
> your system. Thank you.
> ---

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

Re: DomainValidator - new TLDs

[sebb]

On 15 December 2016 at 11:57, Iñaki Dominguez
 wrote:
> Hello!!
>
> Do you know when the next release is going to be publshed?

No, there is no release schedule.
It depends on when there is someone to organise the release.

> On the class DomainValidator are not all the TLDs. The last valid TLD is
> from March of 2016, and there are some relevante TLDs (like .blog) that are
> not included.

The TLD lists get updated far too frequently to generate a new release
each time.

So the current version of DomainValidator allows the user to provide
as many additional TLDs etc as they want (and even remove them).

http://commons.apache.org/proper/commons-validator/javadocs/api-1.5.1/org/apache/commons/validator/routines/DomainValidator.html#updateTLDOverride(org.apache.commons.validator.routines.DomainValidator.ArrayType,%20java.lang.String[])

> Thank you very much.
>
> --
>
> Iñaki Domínguez
> *Kuorum.org *
> CTO y co-fundador
> T +34 660 010 443 <%2B34%20651%20035%20718>
> inaki.doming...@kuorum.org 
>
> ᐧ

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

Re: namespaces in XML configurations

[sebb]

It may be valid XML, but AFAICT the scope of a namespace is the
enclosing element.

So 'x' is only defined in the head, but is being used in the body.

Try what happens when the namespace is defined and used only in the
body element.


On 20 November 2016 at 00:34, Matt Sicker  wrote:
> Considering that's valid XML, that certainly sounds like a bug. Could you
> file an issue on jira for it?
> https://issues.apache.org/jira/browse/CONFIGURATION
>
> On 19 November 2016 at 17:52, Claude Warren  wrote:
>
>> I am attempting to use configuration2 for the first time and have run into
>> what I think is a bug.
>>
>> {noformat}
>> http://www.xml.com/books;
>> xmlns:h="http://www.w3.org/HTML/1998/html4;
>> xmlns:x='http://xenei.org'>
>>  Book Review
>>  
>>   
>>hoo
>>XML: A Primer
>>
>> 
>>  AuthorPrice
>>  PagesDate
>> 
>>  Simon St. Laurent
>>  31.98
>>  352
>>  1998/01
>> 
>>
>>   
>>  
>> 
>> {noformat}
>>
>> will parse but
>>
>> {noformat}
>> http://www.xml.com/books;
>> xmlns:h="http://www.w3.org/HTML/1998/html4;>
>>  Book
>> Review
>>  
>>   
>>hoo
>>XML: A Primer
>>
>> 
>>  AuthorPrice
>>  PagesDate
>> 
>>  Simon St. Laurent
>>  31.98
>>  352
>>  1998/01
>> 
>>
>>   
>>  
>> 
>> {noformat}
>>
>> will not.
>>
>> Note the only difference is  that the namespace for "x" is not declared on
>> the first element.  Is this a bug or intended?
>>
>> Claude
>>
>>
>> --
>> I like: Like Like - The likeliest place on the web
>> 
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>
>
>
>
> --
> Matt Sicker 

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

Re: Multipart download in FTPClient

[sebb]

Are you referring to Commons NET FTPClient?

If so, that has methods for writing the data to an output stream as it arrives:

http://commons.apache.org/proper/commons-net/javadocs/api-3.5/org/apache/commons/net/ftp/FTPClient.html#retrieveFile(java.lang.String,%20java.io.OutputStream)

This does not take more memory for larger files.

See also the example app:

https://commons.apache.org/proper/commons-net/#Examples

Source:

https://commons.apache.org/proper/commons-net/examples/ftp/FTPClientExample.java

You can run the FTPClientExample as indicated above:

java -jar [path]/commons-net-examples-3.5 FTPClientExample -b user
pass host remote local
or
java -jar [path]/commons-net-examples-3.5 FTPClientExample -b -A host
remote local
for anonymous login

The -b is binary mode, which is almost certainly needed for large
files, which are unlikely to be text.



On 8 November 2016 at 13:04, Sreejith S  wrote:
> Hi All,
>
> When dealing with large files , say 1 G, FTPClient end up in a memory
> exception. Does FTPClient supports multi part download option ? I feel this
> would be the solution to solve this memory issue.
>
> Any pointers please.
>
> Thanks,
> Sreejith
>
> --
>
>
> *Sreejith.S*
> https://github.com/srijiths/
> http://srijiths.wordpress.com/
> tweet2sree@twitter 

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

Re: Re: Re: [cli2] Cannot build

[sebb]

On 19 October 2016 at 14:26, Gerhard Brandl <gerhard.bra...@gmx.de> wrote:
> On 18. Oktober 2016 at sebb <seb...@gmail.com> wrote:
>> On 17 October 2016 at 20:36, Gerhard Brandl <gerhard.bra...@gmx.de> wrote:
>> > On 17. Oktober 2016 um 18:36 sebb <seb...@gmail.com> wrote
>> >>
>> >> On 17 October 2016 at 15:57, Gerhard Brandl <gerhard.bra...@gmx.de> wrote:
>> >>> Dear CLI2 community,
>> >>>
>> >>> please see also my question on stackoverflow 
>> >>> (http://stackoverflow.com/q/40072241/6825374),
>> >>> but I copy it here for your convenience.
>> >>>
>> >>> I would like to use the current version of 
>> >>> org.apache.commons:commons-cli2:2.0-SNAPSHOT.
>> >>> As I cannot find a compiled jar for downloading, I would like to build 
>> >>> it on my own.
>> >>> Thus I checked out http://svn.apache.org/repos/asf/commons/trunks-sandbox
>> >>
>> >> Why did you checkout that particular tree?
>> >>
>> >> The CLI2 code is at:
>> >>
>> >> http://svn.apache.org/repos/asf/commons/sandbox/cli2/trunk/
>> >
>> > Thanks!
>> > I checked this out, but also receive this error
>> >
>> > C:\Users\Gerhard\Documents\Projects\asf_commons_sandbox_cli2_trunk>mvn 
>> > clean package
>> > [INFO] Scanning for projects...
>> > [ERROR] [ERROR] Some problems were encountered while processing the POMs:
>> > [FATAL] Non-resolvable parent POM for 
>> > org.apache.commons:commons-cli2:2.0-SNAPSHOT: Could not find artifact 
>> > org.apache.commons:commons-sandbox-parent:pom:10-SNAPSHOT and 
>> > 'parent.relativePath' points at wrong local POM @ line 19, column 11
>> >  @
>> > [ERROR] The build could not read 1 project -> [Help 1]
>> > [ERROR]
>> > [ERROR]   The project org.apache.commons:commons-cli2:2.0-SNAPSHOT 
>> > (C:\Users\Gerhard\Documents\Projects\asf_commons_sandbox_cli2_trunk\pom.xml)
>> >  has 1 error
>> > [ERROR] Non-resolvable parent POM for 
>> > org.apache.commons:commons-cli2:2.0-SNAPSHOT: Could not find artifact 
>> > org.apache.commons:commons-sandbox-parent:pom:10-SNAPSHOT and 
>> > 'parent.relativePath' points at wrong local POM @ line 19, column 11 -> 
>> > [Help 2]
>> > [ERROR]
>> > [ERROR] To see the full stack trace of the errors, re-run Maven with the 
>> > -e switch.
>> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> > [ERROR]
>> > [ERROR] For more information about the errors and possible solutions, 
>> > please read the following articles:
>> > [ERROR] [Help 1] 
>> > http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
>> > [ERROR] [Help 2] 
>> > http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
>> >
>>
>> Edit pom.xml:
>>
>> -10-SNAPSHOT
>> +10
>>
>
> Great! Successfully compiled :-)
> As I also asked for help in stackoverflow, shall I answer my stackoverflow 
> request

yes please

> or would you like to do it?
>
>
>> >> However it is quite old.
>> >>
>> >> So why not use CLI instead?
>> >
>> > I like the Options-Model as described here 
>> > https://commons.apache.org/sandbox/commons-cli2/manual/options.html
>> > I think with this I can have some command line statements like this
>> >
>> > -v | -h | -c  -r  [-o  -l ]
>> >
>> > Does this also work with CLI (1.3.1 or 1.4)
>>
>> Sorry, I don't know.
>
> OK, I will open an separate thread for this usage question.

thanks

> BTW: cli2 works for my little example like described above.
>
> Bye
>  Gerhard
>
>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: Re: [cli2] Cannot build

[sebb]

On 17 October 2016 at 20:36, Gerhard Brandl <gerhard.bra...@gmx.de> wrote:
> On 17. Oktober 2016 um 18:36 sebb <seb...@gmail.com> wrote
>>
>> On 17 October 2016 at 15:57, Gerhard Brandl <gerhard.bra...@gmx.de> wrote:
>>> Dear CLI2 community,
>>>
>>> please see also my question on stackoverflow 
>>> (http://stackoverflow.com/q/40072241/6825374),
>>> but I copy it here for your convenience.
>>>
>>> I would like to use the current version of 
>>> org.apache.commons:commons-cli2:2.0-SNAPSHOT.
>>> As I cannot find a compiled jar for downloading, I would like to build it 
>>> on my own.
>>> Thus I checked out http://svn.apache.org/repos/asf/commons/trunks-sandbox
>>
>> Why did you checkout that particular tree?
>>
>> The CLI2 code is at:
>>
>> http://svn.apache.org/repos/asf/commons/sandbox/cli2/trunk/
>
> Thanks!
> I checked this out, but also receive this error
>
> C:\Users\Gerhard\Documents\Projects\asf_commons_sandbox_cli2_trunk>mvn clean 
> package
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for 
> org.apache.commons:commons-cli2:2.0-SNAPSHOT: Could not find artifact 
> org.apache.commons:commons-sandbox-parent:pom:10-SNAPSHOT and 
> 'parent.relativePath' points at wrong local POM @ line 19, column 11
>  @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project org.apache.commons:commons-cli2:2.0-SNAPSHOT 
> (C:\Users\Gerhard\Documents\Projects\asf_commons_sandbox_cli2_trunk\pom.xml) 
> has 1 error
> [ERROR] Non-resolvable parent POM for 
> org.apache.commons:commons-cli2:2.0-SNAPSHOT: Could not find artifact 
> org.apache.commons:commons-sandbox-parent:pom:10-SNAPSHOT and 
> 'parent.relativePath' points at wrong local POM @ line 19, column 11 -> [Help 
> 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2] 
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
>

Edit pom.xml:

-10-SNAPSHOT
+10


>> However it is quite old.
>>
>> So why not use CLI instead?
>
> I like the Options-Model as described here 
> https://commons.apache.org/sandbox/commons-cli2/manual/options.html
> I think with this I can have some command line statements like this
>
> -v | -h | -c  -r  [-o  -l ]
>
> Does this also work with CLI (1.3.1 or 1.4)

Sorry, I don't know.

> Bye
>  Gerhard
>
>> > Then I installed maven:
>> > C:\Users\Gerhard\Documents\Projects\asf_commons_trunks-sandbox\cli2>mvn -v
>> > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
>> > 2015-11-10T17:41:47+01:00)
>> > Maven home: c:\Program Files (x86)\apache-maven-3.3.9\bin\..
>> > Java version: 1.8.0_65, vendor: Oracle Corporation
>> > Java home: C:\Program Files\Java\jdk1.8.0_65\jre
>> > Default locale: de_DE, platform encoding: Cp1252
>> > OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>> >
>> > OK, looks good :-)
>> >
>> > Concerning to "asf_commons_trunks-sandbox\cli2\README.txt" I executed
>> >
>> > C:\Users\Gerhard\Documents\Projects\asf_commons_trunks-sandbox\cli2>mvn 
>> > clean package
>> >
>> > [INFO] Scanning for projects...
>> > [ERROR] [ERROR] Some problems were encountered while processing the POMs:
>> > [WARNING] 'parent.relativePath' of POM 
>> > org.apache.commons:commons-cli2:2.0-SNAPSHOT 
>> > (C:\Users\Gerhard\Documents\Projects\asf_commons_trunks-sandbox\cli2\pom.xml)
>> >  points at org.apache.commons:commons-sandbox-aggregator instead of 
>> > org.apache.commons:commons-sandbox-parent, please verify your project 
>> > structure @ line 19, column 11
>> > [FATAL] Non-resolvable parent POM for 
>> > org.apache.commons:commons-cli2:2.0-SNAPSHOT: Could not find artifact 
>> > org.apache.commons:commons-sandbox-parent:pom:10-SNAPSHOT and 
>> > 'parent.relativePath' points at wrong local POM @ line 19, column 11
>> >  @
>> > [ERROR] The build could not read 1 project -> [Help 1]
>> > [ERROR]
>> > [ERROR]   Th

Re: [cli2] Cannot build

[sebb]

On 17 October 2016 at 15:57, Gerhard Brandl  wrote:
> Dear CLI2 community,
>
> please see also my question on stackoverflow 
> (http://stackoverflow.com/q/40072241/6825374), but I copy it here for your 
> convenience.
>
> I would like to use the current version of 
> org.apache.commons:commons-cli2:2.0-SNAPSHOT. As I cannot find a compiled jar 
> for downloading, I would like to build it on my own. Thus I checked out 
> http://svn.apache.org/repos/asf/commons/trunks-sandbox

Why did you checkout that particular tree?

The CLI2 code is at:

http://svn.apache.org/repos/asf/commons/sandbox/cli2/trunk/

However it is quite old.

So why not use CLI instead?

> Then I installed maven:
> C:\Users\Gerhard\Documents\Projects\asf_commons_trunks-sandbox\cli2>mvn -v
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T17:41:47+01:00)
> Maven home: c:\Program Files (x86)\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_65, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_65\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>
> OK, looks good :-)
>
> Concerning to "asf_commons_trunks-sandbox\cli2\README.txt" I executed
>
> C:\Users\Gerhard\Documents\Projects\asf_commons_trunks-sandbox\cli2>mvn clean 
> package
>
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [WARNING] 'parent.relativePath' of POM 
> org.apache.commons:commons-cli2:2.0-SNAPSHOT 
> (C:\Users\Gerhard\Documents\Projects\asf_commons_trunks-sandbox\cli2\pom.xml) 
> points at org.apache.commons:commons-sandbox-aggregator instead of 
> org.apache.commons:commons-sandbox-parent, please verify your project 
> structure @ line 19, column 11
> [FATAL] Non-resolvable parent POM for 
> org.apache.commons:commons-cli2:2.0-SNAPSHOT: Could not find artifact 
> org.apache.commons:commons-sandbox-parent:pom:10-SNAPSHOT and 
> 'parent.relativePath' points at wrong local POM @ line 19, column 11
>  @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project org.apache.commons:commons-cli2:2.0-SNAPSHOT 
> (C:\Users\Gerhard\Documents\Projects\asf_commons_trunks-sandbox\cli2\pom.xml) 
> has 1 error
> [ERROR] Non-resolvable parent POM for 
> org.apache.commons:commons-cli2:2.0-SNAPSHOT: Could not find artifact 
> org.apache.commons:commons-sandbox-parent:pom:10-SNAPSHOT and 
> 'parent.relativePath' points at wrong local POM @ line 19, column 11 -> [Help 
> 2]
> [ERROR] ...
>
> I am quite sure I´ve done a simple error. Can you please help me?
>
> Regards!
>  Gerhard
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [imaging] Changing compile baseline of library to JDK7

[sebb]

May I ask why a minium of Java 7 is a problem for some people?

It would be useful to know this when considering other updates.

On 11 October 2016 at 17:10, Thad Humphries  wrote:
> Yes. I've had to pull commons-imaging from my apps and replace it with
> JAI-IMAGEIO. JAI is old and unsupported, but its jar files still work with
> Java 6. (There are also older versions of Twelve Monkeys that work with
> Java 6. https://github.com/haraldk/TwelveMonkeys)
>
> On Tue, Oct 11, 2016 at 11:38 AM, Sergio Matone  wrote:
>
>> I would like to express my disappoint since the library, which was working
>> perfectly, is now compiled using Java 7 without issuing a version.
>>
>> I understand that the library is in SNAPSHOT, but why it wasn't issued at
>> least a 1.0.0 version, tagging the Java 6 version.
>> You broke builds of several of my programs in production. That's not the
>> way Apache usually behaves.
>>
>> Sergio
>>
>
>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 121-24)

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

Re: [imaging] IptcBlock is not public

[sebb]

On 10 October 2016 at 19:26, Gupta, Tapan  wrote:
> We are using snapshot for commons-imaging.
> Today when we ran maven clean package we got new snapshot jar and we are now 
> getting below error
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcBlock is not public in 
> org.apache.commons.imaging.formats.jpeg.iptc; cannot be accessed from outside 
> package

Sorry, that was an error. Now fixed.
It looked like the class was not used outside the package.

Clearly the unit tests need enhancing.

> final List newBlocks = 
> metadata.photoshopApp13Data.getNonIptcBlocks();
> What is the alternative way to do above?
>
> 
> org.apache.commons
> commons-imaging
> 1.0-SNAPSHOT
> 

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

Re: [imaging] Unable to download the binary from any mirror or archive site.

[sebb]

On 6 October 2016 at 03:01, Justin Compson <justincomp...@yahoo.com> wrote:
> Understood that the code hasn't been released but I thought that users could 
> use the snapshot version?  I'm just trying to use the samples given and I'm 
> unable to even utilize the samples.

Snapshots are works in progress and may be in any state.
They are intended for developers who understand the restrictions,
limitations and risks.

> I don't recall where I got the source but I think it was here:
> https://github.com/apache/commons-imaging

That is a mirror of the current trunk, so is a work-in-progress and
may not even compile.

> I even tried the Sanselan version and was unable to get that working either.  
> Is there a place where I can get the binary version of either?  I've had 
> trouble with the import statements and then executing my test programs 
> primarily because of the taginfo class.

The Sanselan version is available from the Download link on the
Commons Imaging site which currently leads to

http://commons.apache.org/proper/commons-imaging/download_sanselan.cgi


> All I'm really trying to grab is camera make, and a few other things to 
> rename my images for personal sorting purposes and planned on using Imaging 
> as I've had other success with Apache libraries.

If you download the Sanselan source as well as the binary, it looks
like there are some samples in the test tree - there's one called
MetadataExample.java that might be suitable as a starting point.

Note that the Sanselan 0.97-incubating release is also available from
Maven Central.

> Thanks for any help.
>
> ----
> On Wed, 10/5/16, sebb <seb...@gmail.com> wrote:
>
>  Subject: Re: [imaging] Unable to download the binary from any mirror or 
> archive site.
>  To: "Commons Users List" <user@commons.apache.org>, "Justin Compson" 
> <justincomp...@yahoo.com>
>  Date: Wednesday, October 5, 2016, 6:31 PM
>
>  On 27 September 2016 at
>  21:13, Justin Compson
>  <justincomp...@yahoo.com.invalid>
>  wrote:
>  > Hi,
>  >
>  > I'm trying to leverage the commons
>  imaging library but I'm unable to download the binary
>  from any mirror or archive site.
>
>  That's because the code has not yet been
>  released.
>
>  > I have found
>  some source files in other locations but I've been
>  unable to get them to work either.  I don't use an IDE,
>  I'm just using the command line in windows.
>  >
>  > I've been able to
>  successfully implement MySQL and fileuploader without issue
>  so I'm not sure what I'm doing wrong here.
>  >
>  > When I am able to
>  compile a project with what I believe is a valid .jar file
>  it still can't find all of the classes:
>
>  Where did you get the
>  source?
>
>  > Z:\Web Projects\Java
>  Code>java -cp . MetadataExample2
>  >
>  Error: A JNI error has occurred, please check your
>  installation and try again
>  > Exception in
>  thread "main" java.lang.NoClassDefFoundError:
>  org/apache/commons/imaging/formats/tiff/taginfos/TagInfo
>  > at
>  java.lang.Class.getDeclaredMethods0(Native Method)
>  > at
>  java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
>  > at
>  java.lang.Class.privateGetMethodRecursive(Class.java:3048)
>  > at
>  java.lang.Class.getMethod0(Class.java:3018)
>  > at
>  java.lang.Class.getMethod(Class.java:1784)
>  > at
>  sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
>  > at
>  sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
>  > Caused by:
>  java.lang.ClassNotFoundException:
>  org.apache.commons.imaging.formats.tiff.taginfos.TagInfo
>  > at
>  java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>  > at
>  java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>  > at
>  sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>  > at
>  java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>  > ... 7 more
>  >
>  > I'm convinced it
>  is just my jar file isn't setup right and I'd rather
>  use a compiled version than doing it on my own as I'm by
>  no means an expert.
>  >
>  > Please help!
>  >
>  > Thanks,
>  >
>  > Justin Compson
>  >
>  >
>  -
>  > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>  > For additional commands, e-mail: user-h...@commons.apache.org
>  >
>

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

Re: [imaging] Unable to download the binary from any mirror or archive site.

[sebb]

On 27 September 2016 at 21:13, Justin Compson
 wrote:
> Hi,
>
> I'm trying to leverage the commons imaging library but I'm unable to download 
> the binary from any mirror or archive site.

That's because the code has not yet been released.

> I have found some source files in other locations but I've been unable to get 
> them to work either.  I don't use an IDE, I'm just using the command line in 
> windows.
>
> I've been able to successfully implement MySQL and fileuploader without issue 
> so I'm not sure what I'm doing wrong here.
>
> When I am able to compile a project with what I believe is a valid .jar file 
> it still can't find all of the classes:

Where did you get the source?

> Z:\Web Projects\Java Code>java -cp . MetadataExample2
> Error: A JNI error has occurred, please check your installation and try again
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/commons/imaging/formats/tiff/taginfos/TagInfo
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
> at java.lang.Class.getMethod0(Class.java:3018)
> at java.lang.Class.getMethod(Class.java:1784)
> at 
> sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
> at 
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.imaging.formats.tiff.taginfos.TagInfo
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 7 more
>
> I'm convinced it is just my jar file isn't setup right and I'd rather use a 
> compiled version than doing it on my own as I'm by no means an expert.
>
> Please help!
>
> Thanks,
>
> Justin Compson
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [dbcp] Problem downloading Apache Commons DBCP 2.2 for JDBC 4.1 (Java 7.0+)

[sebb]

Download page should be OK now; remember to refresh the browser cache
if necessary.

On 13 September 2016 at 23:41, sebb <seb...@gmail.com> wrote:
> Sorry, it looks like the website was inadvertently updated to 2.2 in
> advance of its release.
>
> The latest release is 2.1.1, which you can get from
>
> http://www.apache.org/dyn/closer.cgi/commons/dbcp/binaries/
>
> The KEYS have to be obtained from
>
> https://www.apache.org/dist/commons/KEYS
>
> and the sigs/hashes from
>
> https://www.apache.org/dist/commons/dbcp/binaries/
>
>
> We'll try and fix the website soon.
>
> On 13 September 2016 at 21:37, David Elliott <david.elli...@evariant.com> 
> wrote:
>> Hi,
>>
>> I've tried, I think, every mirror including the backups and I'm getting 404 
>> not found on all of them.
>>
>> Do you know why I'm unable to download Apache Commons DBCP 2.2 for JDBC 4.1 
>> (Java 7.0+)?
>>
>> The URL I'm hitting is this: 
>> https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi?Preferred=http%3A%2F%2Fwww-eu.apache.org%2Fdist%2F
>>
>> Thanks,
>>
>> David
>>
>>
>>
>> ---
>> David Elliott
>> Global Delivery & Operations | Operations Engineer
>>
>> Evariant(r)
>> MOVING HEALTHCARE 
>> AHEAD(tm)<http://www.evariant.com/?utm_source=email_medium=email_campaign=signature_content=signature>
>>
>> c: (512) 423-9756 (preferred phone #)
>> o: (888) 444-3598 x274
>> Connect with us on: LinkedIn<https://www.linkedin.com/company/evariant> | 
>> Twitter<https://twitter.com/evariant> | 
>> Facebook<https://www.facebook.com/Evariant>
>>

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

Re: [dbcp] Problem downloading Apache Commons DBCP 2.2 for JDBC 4.1 (Java 7.0+)

[sebb]

Sorry, it looks like the website was inadvertently updated to 2.2 in
advance of its release.

The latest release is 2.1.1, which you can get from

http://www.apache.org/dyn/closer.cgi/commons/dbcp/binaries/

The KEYS have to be obtained from

https://www.apache.org/dist/commons/KEYS

and the sigs/hashes from

https://www.apache.org/dist/commons/dbcp/binaries/


We'll try and fix the website soon.

On 13 September 2016 at 21:37, David Elliott  wrote:
> Hi,
>
> I've tried, I think, every mirror including the backups and I'm getting 404 
> not found on all of them.
>
> Do you know why I'm unable to download Apache Commons DBCP 2.2 for JDBC 4.1 
> (Java 7.0+)?
>
> The URL I'm hitting is this: 
> https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi?Preferred=http%3A%2F%2Fwww-eu.apache.org%2Fdist%2F
>
> Thanks,
>
> David
>
>
>
> ---
> David Elliott
> Global Delivery & Operations | Operations Engineer
>
> Evariant(r)
> MOVING HEALTHCARE 
> AHEAD(tm)
>
> c: (512) 423-9756 (preferred phone #)
> o: (888) 444-3598 x274
> Connect with us on: LinkedIn | 
> Twitter | 
> Facebook
>

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

Re: Prefix for mails to user@commons.apache.org?

[sebb]

On 30 August 2016 at 22:14, Thomas Brand  wrote:
>
> Hi,
> i understand that using the list-id in the header is the correct thing to
> do, and using that id is certainly an elegant way to i.e. automatically
> file these messages into its own folder. However setting up filters isn't
> sometimes easy or limited and mails end up flat. Please have a look at
> this screenshot part:
> http://picpaste.com/pics/inbox_list_messages-AZ0VF5BA.1472591249.png
> It must be obvious that a tag *in the subject* can be helpful. If along
> "tagged" messages, there are messages from random people with random
> subjects, it makes it harder at least in that scenario i'm using mail
> (blame on how).

Note that there are lots of ASF mailing lists.
Indeed there are lots of ASF user mailing lists.
And other organisations have user mailing lists too.
So the feature would only work if the full mailing list id was used.

Also the Commons mailing lists cover multiple components; the
convention is to prefix the subject with the [component] name.
So the full subject for this mail would become:

user@commons.apache.org [ALL] Prefix for mails to user@commons.apache.org?

> These few additional bytes wouldn't be a waste of anything IMHO. :)

It's not just a few bytes, and it does cause problems:
As far as I can tell from the screenshot you referenced, the prefix
would result in truncation of the actual subject.

> Cheers
> Thomas
>
> On Tue, August 30, 2016 18:57, Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>>
>> Matt,
>>
>>
>> On 8/30/16 12:01 PM, Matt Sicker wrote:
>>
>>> Oh, I thought he was talking about subprojects, not lists. Yeah,
>>> the List-Id and other List-* headers are good enough for this normally.
>>
>> .. or the "TO" or "CC" headers. Any client should be able to route
>> messages based upon those.
>>
>> - -chris
>>
>>
>>> On 30 August 2016 at 10:49, Paix, Manfred 
>>> wrote:
>>>
>>>

 I don't like an additional prefix in the subject line, the
 subproject like [math] should be enough.

 -Ursprüngliche Nachricht- Von: Matt Sicker
 [mailto:boa...@gmail.com] Gesendet: Dienstag, 30. August 2016
 17:43 An: Commons Users List Betreff: Re: Prefix for mails to
 user@commons.apache.org?

 The List-Id header only says which list it's from, not which
 subproject it's in.

 On 30 August 2016 at 10:23, Thomas Brand  wrote:


> On Tue, August 30, 2016 17:18, Mark Thomas wrote:
>
>> On 30/08/2016 16:14, Thomas Brand wrote:
>>
>>
>>>
>>> Hi, when i receive mail from other lists, they have a
>>> subject like
> [listname]
>
>>> subject, which akes it easy to quickly sort and overview mails
>>> from multiple lists in one box (i.e. the inbox). It also makes
>>> it easier to quickly filter from spam messages. Would it be
>>> possible that listserver from user@commons.apache.org would
>>> automagically prefix
 the subject?
>>
>> Unlikely.
>>
>>
>>
>> The ASF mail server sets the List-Id mail header which can be
>> used for sorting / filtering.
>>
>> Mark
>>
>>
>
> I see, fair enough. Would it hurt though if there would be this
> redundancy for dumber
 clients?
> Greetings
>
>
>
>
> ---
> -
>
>> - -
>>
>
>
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>>
> For additional commands, e-mail: user-h...@commons.apache.org
>
>
>


 -- Matt Sicker 


 -



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



>>>
>>>
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>>
>> iQIcBAEBCAAGBQJXxbruAAoJEBzwKT+lPKRY1H8P/RRvlJ5WS3QxtM4X0oBBgHw8
>> X2LxZCDF65NFz8eh/c/70E7PlmsQlr4UoigwlPwUrjXUwETle7CZMuU1AnOWXQBB
>> c7NhuKMp0CdCnGw+EMaFoFmVFtD6MJgCFD8MqvSZTZ4+phy/MREh+ZKMkrutn40o
>> yoEmeyP+aTRDOERfgHvhRQ+VJRmuasCg8wiP1oTvx1hbuYSKWpVXYrV2K5suJpjT
>> bxUfqfIHkQAjwxNJX4XD0WlkwvE7xtLAKCsFlhcGTo7v7YyVK2X1EHR2xlrSL7ui
>> MBrvE/KtLfG+d852OXcJnAnvIaCLQBMrb2qOBd5Xjaz05Ms3JtakUGibbG1mDdr2
>> Tcsi86kpv0Uiuy4GETiZtNh7zV6NPzHepXVHY68gYSErvfkyljeiObPFDYGD4GJG
>> TVwrLBIWl79VBE8TPqnjGD/NbalfQwcOd9ct3ygINWpFI+Ti5K3yHRwFpo/qBR8G
>> KTLABbK2UIje/is4roJc2YEmQWYSttxboCTIEbriLOO4+9uAJ5HYxRGT57jSSmwe
>> f93HReSFAt6HWomXFlBtHp+GUHjn7C+YCAAJLQ8TvFFyey0HvpHv5P1ZpKB2XRmr
>> LhV6FjcKZLfSBHWXp8BbvzAF60p6W/L2Tw3Z3F4kJiCFYqJofeU3/pZDu8xJJRDC
>> 1N8PK6wSHpucC1e8q9zD
>> =+0El
>> -END PGP SIGNATURE-
>>
>>
>> 

Re: NPE in getRemoteAdress

[sebb]

FTPClient instances are independent; each can be used by a separate thread.
However note that the instances are not inherently thread-safe.

So either create the instance in the same thread that does the download.

Alternatively, create the client before creating the thread, and
ensure that the client is only used by the new thread once created.

On 30 August 2016 at 20:53, Oliver Zemann <oliver.zem...@gmail.com> wrote:
> Seems like that made it. I  used a new FTPClient for each file to download,
> that worked now in the JUnit. Will try it this weekend to get the same in my
> application. Thanks!
>
>
> Am 30.08.2016 um 16:23 schrieb sebb:
>>
>> On 29 August 2016 at 18:28, Oliver Zemann <oliver.zem...@gmail.com> wrote:
>>>
>>> My download method looks like this:
>>>
>>> private void downloadDirectory(FTPClient client, String sourceDir, String
>>> destDir,
>>> ScheduledExecutorService
>>> scheduledExecutorService) throws IOException {
>>>
>>>  final FTPFile[] ftpFiles = client.listFiles(sourceDir);
>>>  for (final FTPFile ftpFile : ftpFiles) {
>>>
>>>  //skip . and ..
>>>  if (ftpFile.isDirectory() && (ftpFile.getName().equals(".")
>>> ||
>>> ftpFile.getName().equals(".."))) {
>>>  continue;
>>>  }
>>>
>>>  if (ftpFile.isDirectory()) {
>>>  downloadDirectory(client, sourceDir + ftpFile.getName(),
>>> destDir + "/" + ftpFile.getName(), scheduledExecutorService);
>>>  } else {
>>> //scheduledExecutorService.submit(new
>>> DownloadRunnable(destDir, ftpFile, sourceDir, client));
>>>  FileOutputStream fos = new
>>> FileOutputStream(ftpFile.getName());
>>>  client.retrieveFile(sourceDir + ftpFile.getName(), fos
>>> );
>>>  fos.flush();
>>>  fos.close();
>>>  }
>>>  }
>>>  }
>>>
>>> When i run it like this, it works and it downloads the files. But when i
>>> use
>>> the scheduledExecuterService, it fails.
>>> So i replaced the 2 lines with my download method (where it uses the
>>> inputstream) to see what happens:
>>>
>>>   } else {
>>> //scheduledExecutorService.submit(new
>>> DownloadRunnable(destDir, ftpFile, sourceDir, client));
>>>  new File(destDir).mkdirs();
>>>  final File outFile = new File(destDir,
>>> ftpFile.getName());
>>>  final FileOutputStream fos = new
>>> FileOutputStream(outFile);
>>>  final InputStream inputStream =
>>> client.retrieveFileStream(sourceDir + ftpFile.getName());
>>>
>>>  byte[] buffer = new byte[8096];
>>>  int len = -1;
>>>  try {
>>>  len = inputStream.read(buffer, 0, buffer.length);
>>>  } catch (Exception ex) {
>>>  ex.printStackTrace();
>>>  }
>>>  while (len != -1) {
>>>  fos.write(buffer, 0, len);
>>>  len = inputStream.read(buffer);
>>>  if (Thread.interrupted()) {
>>>  throw new InterruptedException();
>>>  }
>>>  }
>>>  client.completePendingCommand();
>>> //informListenersWeFinishedOneFile(sourceDir +
>>> ftpFile.getName(), bytesWritten);
>>>  fos.flush();
>>>  fos.close();
>>>  }
>>>  }
>>>
>>> That works too?!
>>>
>>> I will go deeper into that at weekend and check whats going on, but at
>>> the
>>> moment i really dont understand it. Maybe some kind of concurrency
>>> problem
>>> with FTPClient?
>>
>> That seems the most likely.
>>
>> FTPClient is not guaranteed to be thread-safe.
>> I'm not sure that the java.io classes such as InputStream are thread
>> safe either.
>>
>>> Am 29.08.2016 um 01:40 schrieb Martin Gainty:
>>>>
>>>> possible timeout waiting for FTP to reply
>>>> examples.ftp.FTPClientExample says to increase FTP reply tim

Re: NPE in getRemoteAdress

[sebb]

On 29 August 2016 at 18:28, Oliver Zemann  wrote:
> My download method looks like this:
>
> private void downloadDirectory(FTPClient client, String sourceDir, String
> destDir,
>ScheduledExecutorService
> scheduledExecutorService) throws IOException {
>
> final FTPFile[] ftpFiles = client.listFiles(sourceDir);
> for (final FTPFile ftpFile : ftpFiles) {
>
> //skip . and ..
> if (ftpFile.isDirectory() && (ftpFile.getName().equals(".") ||
> ftpFile.getName().equals(".."))) {
> continue;
> }
>
> if (ftpFile.isDirectory()) {
> downloadDirectory(client, sourceDir + ftpFile.getName(),
> destDir + "/" + ftpFile.getName(), scheduledExecutorService);
> } else {
> //scheduledExecutorService.submit(new
> DownloadRunnable(destDir, ftpFile, sourceDir, client));
> FileOutputStream fos = new
> FileOutputStream(ftpFile.getName());
> client.retrieveFile(sourceDir + ftpFile.getName(), fos );
> fos.flush();
> fos.close();
> }
> }
> }
>
> When i run it like this, it works and it downloads the files. But when i use
> the scheduledExecuterService, it fails.
> So i replaced the 2 lines with my download method (where it uses the
> inputstream) to see what happens:
>
>  } else {
> //scheduledExecutorService.submit(new
> DownloadRunnable(destDir, ftpFile, sourceDir, client));
> new File(destDir).mkdirs();
> final File outFile = new File(destDir, ftpFile.getName());
> final FileOutputStream fos = new FileOutputStream(outFile);
> final InputStream inputStream =
> client.retrieveFileStream(sourceDir + ftpFile.getName());
>
> byte[] buffer = new byte[8096];
> int len = -1;
> try {
> len = inputStream.read(buffer, 0, buffer.length);
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> while (len != -1) {
> fos.write(buffer, 0, len);
> len = inputStream.read(buffer);
> if (Thread.interrupted()) {
> throw new InterruptedException();
> }
> }
> client.completePendingCommand();
> //informListenersWeFinishedOneFile(sourceDir +
> ftpFile.getName(), bytesWritten);
> fos.flush();
> fos.close();
> }
> }
>
> That works too?!
>
> I will go deeper into that at weekend and check whats going on, but at the
> moment i really dont understand it. Maybe some kind of concurrency problem
> with FTPClient?

That seems the most likely.

FTPClient is not guaranteed to be thread-safe.
I'm not sure that the java.io classes such as InputStream are thread
safe either.

>
> Am 29.08.2016 um 01:40 schrieb Martin Gainty:
>>
>> possible timeout waiting for FTP to reply
>> examples.ftp.FTPClientExample says to increase FTP reply timeout with -w
>> parameter
>>   if (args[base].equals("-w")) {
>> controlKeepAliveReplyTimeout = Integer.parseInt(args[++base]);}
>> or with FTPClient:ftpClient.setControlKeepAliveReplyTimeout(2000); //2 sec
>> reply timeout
>> ?
>> Martin
>> __
>>
>>
>>
>>> Date: Sun, 28 Aug 2016 20:06:46 +0200
>>> From: e...@zusammenkunft.net
>>> To: user@commons.apache.org
>>> CC: oliver.zem...@gmail.com
>>> Subject: Re: NPE in getRemoteAdress
>>>
>>> Hello,
>>>
>>> I am not sure about your NPE, but this code here ignores the result of
>>> the read call. It cannot deal with short reads:
>>>
>>>   Am Sun, 28 Aug 2016
>>> 15:50:36 +0200 schrieb Oliver Zemann :

 byte b[] =new byte[4096];
 while (inputStream.read(b) != -1) {
fos.write(b);
bytesWritten += b.length;
>>>
>>>
>>> Gruss
>>> Bernd
>>>
>>> -
>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: user-h...@commons.apache.org
>>>
>>
>
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [FTP] Create new client for retrieveFileStream()?

[sebb]

On 1 May 2016 at 16:16, Mailing User  wrote:
> I searched Google for examples uses of Apache Commons FTP library, but only 
> found very basic examples. For efficiency and not to reach user limit, I used 
> only one client.
>
> When I called mlistFile(), I got an 
> "java.lang.ArrayIndexOutOfBoundsException: length=1; index=1." at
> String entry = getReplyStrings()[1].substring(1);
>
> I found that at that time, getReplyStrings returned a String array that had 
> only one element, and it was
> 226 Successfully transferred "/somefile.mp4"
> instead of the expected
> 250-Listing /somefile.mp4
>  type=file;size=1834618;modify=20090501101746; /somefile.mp4
> 250 End
>
> It seems that the response for MLST was mixed with a file close 
> (InputStream.close()) response. What is the best way to avoid this? Should I 
> use a separate client for retrieveFileStream()?

The Javadoc

http://commons.apache.org/proper/commons-net/javadocs/api-3.4/org/apache/commons/net/ftp/FTPClient.html#retrieveFileStream(java.lang.String)

says:

"To finalize the file transfer you must call completePendingCommand
and check its return value to verify success. If this is not done,
subsequent commands may behave unexpectedly. "



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

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

[ANNOUNCE] Apache Commons Validator 1.5.1 released

[sebb]

The Apache Commons Team is pleased to announce the release of Apache
Commons Validator 1.5.1

Apache Commons Validator provides the building blocks for both client side
validation and server side data validation. It may be used standalone or
with a framework like Struts.

The main changes are:
* DomainValidator.ArrayType is not public Fixes VALIDATOR-386.
  This now allows the TLD lists to be overriddent using
DomainValidator#updateTLDOverride [1]
* EmailValidator fixes
* Mastercard Series 2 BIN ranges (active from October 2016)
* Updated to the TLD list dated Mon Apr 25 07:07:01 2016 UTC

Details of all the changes in 1.5.1 can be found in the changelog:

http://commons.apache.org/proper/commons-validator/changes-report.html

1.5.1 is fully binary compatible to the last release. No client code
changes are required to migrate from version 1.4.x (or later) to 1.5.1.
The minimum required JDK version for this release is 1.6.

However note that the Javascript code has been dropped, see
https://issues.apache.org/jira/browse/VALIDATOR-371

Source and binary distributions are available for download from the Apache
Commons download site:

http://commons.apache.org/proper/commons-validator/download_validator.cgi

When downloading, please verify signatures using the KEYS file available at

http://www.apache.org/dist/commons/KEYS

Alternatively the release can be fetched from Maven Central:

  commons-validator
  commons-validator
  1.5.1



For complete information on Commons Validator, including instructions on
how to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons Validator website:

http://commons.apache.org/proper/commons-validator/


[1] 
http://commons.apache.org/proper/commons-validator/javadocs/api-1.5.1/org/apache/commons/validator/routines/DomainValidator.html#updateTLDOverride%28org.apache.commons.validator.routines.DomainValidator.ArrayType,%20java.lang.String[]%29

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

Re: [CSV] Error: End-of-File, expected line

[sebb]

On 22 April 2016 at 11:43, Robert Onslow  wrote:
> Hi!
>
> I'm reading CSV encoded in UTF-16:
>
> Reader reader  = new BufferedReader(new InputStreamReader(new
> FileInputStream(source), "UTF-16"));
> //Ignore 2 bytes of format data
> reader.read();
> CSVParser parser = format.parse(reader)
>
> The CSV, with record separators 0D0A,  is consumed correctly except I
> get thie above error at the end of the parse
>
> The file ends with 0D0A
>
> Does anyone know what the problem may be here, please?

I'm guessing, but it sounds like CSV was expecting more input.
Is the file syntactically complete?

> Thanks
>
> Robert
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [net] Getting MalformedServerReplyException in FTPClientExample Class

[sebb]

On 2 April 2016 at 01:04, Emerson Castañeda <eme...@gmail.com> wrote:
> On Apr 2, 2016 1:33 AM, "sebb" <seb...@gmail.com> wrote:
>>
>> On 1 April 2016 at 23:17, Emerson Castañeda <eme...@gmail.com> wrote:
>> > Hello
>> >
>> > I'm using FTPClientExample
>> > <
> https://commons.apache.org/proper/commons-net/examples/ftp/FTPClientExample.java
>>class
>> > with these parameters:
>>
>> Which version?
>
> 3.4
>>
>> >
>> > java FTPClientExample -l -p SFTP 192.158.76.218:22 user pwd
>> >
>> >
>> > I'm getting this exception:
>> >
>> > Could not connect to server.
>> > org.apache.commons.net.MalformedServerReplyException: Could not parse
>> > response code.
>> > Server Reply: SSH-2.0-OpenSSH_5.3
>> > at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:336)
>> > at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:292)
>> > at org.apache.commons.net.ftp.FTP._connectAction_(FTP.java:418)
>> > at
>> > org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:966)
>> > at
>> > org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:954)
>> > at
>> >
> org.apache.commons.net.ftp.FTPSClient._connectAction_(FTPSClient.java:222)
>> > at
> org.apache.commons.net.SocketClient.connect(SocketClient.java:189)
>> > at
> org.apache.commons.net.SocketClient.connect(SocketClient.java:209)
>> > at lib_ftputility.FTPClientExample.main(FTPClientExample.java:311)
>>
>> There should be some more output before the exception.
>
> No more output.

Note the Server Reply:

SSH-2.0-OpenSSH_5.3

A normal server reply should be something like

220 SSH-2.0-OpenSSH_5.3

(Try a different server and see)

The server you are testing against is broken.

So the following response is the correct behaviour:

MalformedServerReplyException: Could not parse response code.

>>
>> >
>> > Thanks in advance for your support
>> >
>> >
>> > Emerson
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>

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

Re: [net] Getting MalformedServerReplyException in FTPClientExample Class

[sebb]

On 1 April 2016 at 23:17, Emerson Castañeda  wrote:
> Hello
>
> I'm using FTPClientExample
> class
> with these parameters:

Which version?

>
> java FTPClientExample -l -p SFTP 192.158.76.218:22 user pwd
>
>
> I'm getting this exception:
>
> Could not connect to server.
> org.apache.commons.net.MalformedServerReplyException: Could not parse
> response code.
> Server Reply: SSH-2.0-OpenSSH_5.3
> at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:336)
> at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:292)
> at org.apache.commons.net.ftp.FTP._connectAction_(FTP.java:418)
> at
> org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:966)
> at
> org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:954)
> at
> org.apache.commons.net.ftp.FTPSClient._connectAction_(FTPSClient.java:222)
> at org.apache.commons.net.SocketClient.connect(SocketClient.java:189)
> at org.apache.commons.net.SocketClient.connect(SocketClient.java:209)
> at lib_ftputility.FTPClientExample.main(FTPClientExample.java:311)

There should be some more output before the exception.

>
> Thanks in advance for your support
>
>
> Emerson

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

Re: Problems with encoding UTF-8 for åäö

[sebb]

Nor have you specified which Commons component you are using.

There are at least two that can be used to send e-mails.

On 23 March 2016 at 11:23, Maria Jimena Sanchez <jimesanc...@gmail.com> wrote:
> Are you using the correct UTF-8 symbol? We still can't see how you assign
> content to the subject variable
>
> On Wed, Mar 23, 2016, 8:17 AM <lars.z.carls...@teliasonera.com> wrote:
>
>> Hi
>> I have the problem on Hotmail.com i attach the complete method.
>>
>>
>> private void sendEmail(String sender, String recipient, String
>> subject,
>> String body) throws IOException {
>> String server;
>> List ccList = new ArrayList();
>> Writer writer;
>> SimpleSMTPHeader header;
>> SMTPClient client;
>>
>> header = new SimpleSMTPHeader(sender, recipient, subject);
>> header.addHeaderField("Content-Type", "text/plain;
>> charset=" + "UTF-8");
>> client = new SMTPClient("UTF-8");
>> client.connect(server);
>>
>> client.login();
>>
>> client.setSender(sender);
>> client.addRecipient(recipient);
>>
>> for (String recpt : ccList) {
>> client.addRecipient(recpt);
>> }
>>
>> writer = client.sendMessageData();
>>
>> if (writer != null) {
>> writer.write(header.toString());
>> writer.write(body);
>> writer.close();
>> client.completePendingCommand();
>> }
>>
>> client.logout();
>> client.disconnect();
>> }
>>
>>
>> ---
>> Lars Carlsson
>> Phone: +46702507901
>> 
>> From: sebb [seb...@gmail.com]
>> Sent: Wednesday, March 23, 2016 11:39 AM
>> To: Commons Users List
>> Subject: Re: Problems with encoding UTF-8 for åäö
>>
>> On 23 March 2016 at 10:20,  <lars.z.carls...@teliasonera.com> wrote:
>> > Hi
>>
>> What software are you having a problem with?
>> This list applies to multiple components.
>>
>> > I have a problem that some mail clients show the wrong encoding for
>> Swedish characters (åäö). I try setting the message encoding to UTF-8 but
>> it did't work i most have forgot something in the code.
>> > If you see any anything wrong in the code.
>>
>> The code does not show how the subject variable is created.
>>
>> >
>> >
>> > Java code:
>> > --
>> > header.addHeaderField("Content-Type", "text/plain; charset=" + "UTF-8");
>> > client = new SMTPClient("UTF-8");
>> > client.connect(server);
>> >
>> > client.login();
>> >
>> > client.setSender(sender);
>> > client.addRecipient(recipient);
>> >
>> > for (String recpt : ccList) {
>> > client.addRecipient(recpt);
>> > }
>> >
>> > writer = client.sendMessageData();
>> >
>> > if (writer != null) {
>> > writer.write(header.toString());
>> > writer.write(body);
>> > writer.close();
>> > client.completePendingCommand();
>> > }
>> >
>> > client.logout();
>> > client.disconnect();
>> >
>> >
>> > Raw message in Thunderbird using source view:
>> >
>> 
>> > Content-Type: text/plain; charset="UTF-8"
>> >
>> > Subject: äåö
>> > 
>> > X-STA-Spam: subject:?? ?? spec:disguised to:2**0 header:To:1
>> > X-BTI-AntiSpam:
>> score:0,sta:7/030,dnsbl:off,sw:off,bsn:none,spf:off,bsctr:off,dk:off,pbmf:none,ipr:0/3,trusted:yes,ts:no,bs:no,ubl:off
>> > Received-SPF: none
>> > 
>> > MIME-Version: 1.0
>> >
>> >
>> > åäö
>> >
>> > -
>> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: user-h...@commons.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>>

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

Re: Problems with encoding UTF-8 for åäö

[sebb]

On 23 March 2016 at 10:20,   wrote:
> Hi

What software are you having a problem with?
This list applies to multiple components.

> I have a problem that some mail clients show the wrong encoding for Swedish 
> characters (åäö). I try setting the message encoding to UTF-8 but it did't 
> work i most have forgot something in the code.
> If you see any anything wrong in the code.

The code does not show how the subject variable is created.

>
>
> Java code:
> --
> header.addHeaderField("Content-Type", "text/plain; charset=" + "UTF-8");
> client = new SMTPClient("UTF-8");
> client.connect(server);
>
> client.login();
>
> client.setSender(sender);
> client.addRecipient(recipient);
>
> for (String recpt : ccList) {
> client.addRecipient(recpt);
> }
>
> writer = client.sendMessageData();
>
> if (writer != null) {
> writer.write(header.toString());
> writer.write(body);
> writer.close();
> client.completePendingCommand();
> }
>
> client.logout();
> client.disconnect();
>
>
> Raw message in Thunderbird using source view:
> 
> Content-Type: text/plain; charset="UTF-8"
>
> Subject: äåö
> 
> X-STA-Spam: subject:?? ?? spec:disguised to:2**0 header:To:1
> X-BTI-AntiSpam: 
> score:0,sta:7/030,dnsbl:off,sw:off,bsn:none,spf:off,bsctr:off,dk:off,pbmf:none,ipr:0/3,trusted:yes,ts:no,bs:no,ubl:off
> Received-SPF: none
> 
> MIME-Version: 1.0
>
>
> åäö
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

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

Re: [IO] Java 1.4 compatible release

[sebb]

http://commons.apache.org/proper/commons-io/

Select 'Release Notes'

Scroll to the bottom


On 3 March 2016 at 04:30, Dehan De Croos  wrote:
> hi I/O Team,
>
> What is the final commons release available, which is compatible with
> java 1.4 ?
>
> best regards,
> *Dehan de Croos*

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

Re: 3.4 bin incomplete?

[sebb]

The binary and sources can be downloaded from the usual place, i.e

http://commons.apache.org/proper/commons-lang/download_lang.cgi

The Central Maven repo has the sources in the usual place:

http://repo1.maven.org/maven2/org/apache/commons/commons-lang3/3.4/

Note that the source is in a separate jar from the binaries, as per usual.


On 27 January 2016 at 23:12, David Conklin  wrote:
> Could someone send me the missing files?
>
>
>   From: David Conklin 
>  To: "user@commons.apache.org" 
>  Sent: Sunday, January 24, 2016 7:14 PM
>  Subject: 3.4 bin incomplete?
>
> Hi,
> First time here!  Hope I'm doing this right!
> I've run into a problem where I'm supposed to dl'd the 
> common-lang[version]-sources.jar and ... -test.jar and they didn't come with 
> the latest version (see Lang – Home).  I went down to "
>
> |   |
> |   |   |   |   |   |
> | Lang – HomeCommons Lang The standard Java libraries fail to provide enough 
> methods formanipulation of its core classes. Apache Commons Lang 
> providesthese extra methods.  |
> |  |
> | View on commons.apache.org | Preview by Yahoo |
> |  |
> |   |
>
> The latest stable release of Lang is 3.4. You may:
>- Download 3.4"
>
> Thanks for your time!
> David Conklin
>
>
>

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

Re: [commons-io] TeeInputStream that ignores skip/reset?

[sebb]

I'm not sure what the use case for this is, apart from avoiding the
bug in DigestingInputStream.
Which can be avoided by not using skip/reset.

I'm not sure that skip/reset make any sense for a DigestingInputStream anyway.


On 16 December 2015 at 12:19, Allison, Timothy B.  wrote:
> All,
>   Over on Tika, we'd like a DigestingInputStream that ignores skip/reset 
> (unlike Java's v <= 1.8 [0]).  Before we reinvent the wheel, is there an 
> InputStream similar to TeeInputStream that ignores skip/reset, so that the 
> Digester would only see the stream as if it were read sequentially without 
> skip/reset?
>   If we do reinvent the wheel, should we contribute this InputStream to 
> commons-io as an alternate to TeeInputStream?
>   Or, even more generally, are there other recommendations for handling this? 
>  Thank you!
>
>  Best,
>
>  Tim
>
> [0] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201508.mbox/%3CDM2PR09MB07135F86C7AC6981F1BB216BC78A0%40DM2PR09MB0713.namprd09.prod.outlook.com%3E

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

[ANNOUNCE] Apache Commons NET 3.4 released

[sebb]

The Apache Commons team are pleased to announce the release of
Commons Net version 3.4.

This is a bug fix release. All users are encouraged to upgrade to 3.4.

For details of the fixes and new features please see:

http://www.apache.org/dist/commons/net/RELEASE-NOTES.txt

[These are also included with the binary and source archives]

The changes are also available at:
http://commons.apache.org/net/changes-report.html

Binary and source archives are available from the usual download
locations.

Please see the Apache Commons Net website for full details:

http://commons.apache.org/net/

The Maven coordinates are:

commons-net
commons-net
3.4

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

Re: [exec] - Simple Copy using Apache Commons

[sebb]

Don't build the command line yourself, let Exec do it:

http://commons.apache.org/proper/commons-exec/commandline.html#Building_the_Command_Line_Incrementally

On 26 August 2015 at 03:34, Tech Dev techdev...@gmail.com wrote:
 Hi,

 I am trying to execute a copy command using Apache Commons Exec API. Below
 is my effort :

 String initialCommand = scp -i;
 String privateKey = /Users/TD/.ssh/id_rsa;
 String currentFile = /Users/TD/One.txt;
 String target = r...@my.server.com:;

 // Space is present in destination
 String destination=/Leo/Ta/San Diego;
 destination=destination.replaceAll( ,  );

 String completeCommand = initialCommand +   + privateKey +   +
 currentFile +   + target + destination;
 System.out.println(completeCommand);

 CommandLine commandLine = new CommandLine(completeCommand);

 System.out.println(commandLine.toString());
 DefaultExecutor executor = new DefaultExecutor();
 executor.setExitValue(0);
 executor.execute(commandLine);

 Output :

 scp -i /Users/TD/.ssh/id_rsa /Users/TD/One.txt 
 r...@my.server.com:/Leo/Ta/San\
 Diego

 scp -i /Users/TD/.ssh/id_rsa /Users/TD/One.txt 
 r...@my.server.com:/Leo/Ta/San/
 Diego

 I am noticing that backslash is getting updated and also my command is not
 running with error No such file or directory.

 I am new to this library. Any suggestion would be appreciated.

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

Re: [lang] StringUtils.equals bug on non-Strings with identical leading prefix

[sebb]

On 10 August 2015 at 19:14, Aman Agarwal aman.agar...@twosigma.com wrote:
 StringUtils.equals(cs1,cs2) delegates to CharSequence.regionMatches(...) in a 
 way that causes IndexOutOfBounds when either of cs1/cs2 isn't a String.



 Specifically, comparing foo and foobar for non-String CharSequences bombs 
 due to CharSequenceUtils.regionMatches(cs1, false, 0, cs2, 0, 
 Math.max(cs1.length(), cs2.length())) because regionMatches doesn't check for 
 input exhaustion.

I can confirm the problem.
The existing tests don't show it because they use Strings rather than
(say)  StringBuffer.

Created a JIRA:

https://issues.apache.org/jira/browse/LANG-1162

Note: if you find any other such issues, it would be very helpful if
you could file a JIRA issue, as per

http://commons.apache.org/proper/commons-lang/issue-tracking.html

Thanks!



 Bug appears in default.



 -  Aman


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

Re: [daemon] How to daemonize a Java app that has a private default constructor

[sebb]

On 28 July 2015 at 00:56, Bill Durant bdur...@g2ss.com wrote:
 Greetings:

 I have Java application that has a private default constructor in order to
 support the singleton pattern.

 When I try to daemonize the application with jsvc, I get the following
 exception:

 java.lang.IllegalAccessException: Class
 org.apache.commons.daemon.support.DaemonLoader can not access a member of
 class example.App with modifiers private
 at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101)
 at java.lang.Class.newInstance(Class.java:432)
 at
 org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:190)
 Cannot load daemon
 Service exit with a return value of 3

 Is it not possible to daemonize a Java application that has a private
 default constructor with jsvc?

I would try writing a wrapper (with a public constructor) that creates
the singleton.

 Thanks!

 Bill



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


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

Re: [JCS] Region No longer alive so returning false for key

[sebb]

On 6 July 2015 at 15:15, Tim Cronin t...@outboundengine.com wrote:
 AuxDiskCache is throwing error that it can't create the directory but it
 already exists.

 localhost-startStop-1 2015-07-06 14:01:30,006 ERROR
 org.apache.commons.jcs.auxiliary.disk.AbstractDiskCacheAttributes - Failed
 to create directory C:\java\tomcat\temp\oeserver-cache

 I tested mkdirs and it follows what the javadoc says
 http://docs.oracle.com/javase/8/docs/api/java/io/File.html#mkdirs--. the
 code needs to check if the dir already exists:

 the function should be as follows:

 /**
  * Sets the diskPath attribute of the DiskCacheAttributes object
  * p
  * @param diskPath The new diskPath value
  */
 public void setDiskPath( File diskPath )
 {
 this.diskPath = diskPath;

 if(!this.diskPath.exists())
 {
 boolean result = this.diskPath.mkdirs();

 if (!result)
 {
 log.error(Failed to create directory  + diskPath);
 }
 }
 }

That can still theoretically fail if something else creates the
directory in the meantime.
Also exists() will return true for a file as well as a directory.

Please see:

https://issues.apache.org/jira/browse/JCI-67




 On Mon, Jul 6, 2015 at 8:37 AM, Tim Cronin t...@outboundengine.com wrote:

 is there any documentation on migrating from 1.3 to 2?

 the JCSAdmin.jsp the FAQ link is broken. moved due to package change
 http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/admin/JCSAdmin.jsp?view=log


 On Mon, Jul 6, 2015 at 7:37 AM, Tim Cronin t...@outboundengine.com wrote:

 i understand that 1.3 is old and the 2 branch will be the way going
 forward but...

 this happens on our production server and really don't want to run beta
 code on it.

 i've played with the beta code and it requires code changes on our side
 as well.

 On Sun, Jul 5, 2015 at 10:25 AM, Thomas Vandahl t...@apache.org wrote:

 On 02.07.15 15:13, Tim Cronin wrote:
  JCS 1.3
 
  i periodically get the above error.
 
  what do i need to do to recover from this?
 

 First of all I'd suggest to try out commons-jcs 2.0-beta1. It contains
 numerous fixes and cleans up the lifecycle of most of the JCS manager
 classes. If that doesn't help, come back and ask again as this would
 require deeper digging.

 Bye, Thomas.

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





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

Re: [configuration] Apache Commons Configuration Version 2

[sebb]

On 9 May 2015 at 21:07, Ralph Goers ralph.go...@dslextreme.com wrote:
 You can publish an alpha or a beta and still change the API. That really 
 isn’t locked in until the first official GA release.

In theory, perhaps, at least with an alpha release.

However how many people take note of the alpha/beta status of the code?

Any project that depends on an alpha/beta release ought itself to be
labelled as alpha/beta - does that happen?
If not, then downstream projects may get a nasty shock.

 Ralph

 On May 7, 2015, at 3:44 AM, sebb seb...@gmail.com wrote:

 Yes, it might cause a problem to publish an RC.

 Any publication to Maven Central effectively freezes the current public API.
 If a problem is then found, generally the only solution that avoids
 jar hell is to release a new version with different package name and
 different Maven coords - i.e. effectively a different product.
 This will not be a drop-in replacement, and will require source code
 changes by anyone using it.

 On 7 May 2015 at 03:54, DiFrango, Ronald (CONT)
 ronald.difra...@capitalone.com wrote:
 Yeah, I would prefer to avoid the snap-shot repo, so if nothing else I'll 
 build a version locally and upload it to our local Nexus.

 One question, if this is close, would it hurt to pulish an RC into Maven 
 Central?

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: Wednesday, May 06, 2015 9:20 PM
 To: Commons Users List
 Subject: Re: [configuration] Apache Commons Configuration Version 2

 You should also be able to get it from the ASF snapshot repo.

 However note that such artifacts may change or disappear at any time, so 
 should only be used for testing.

 On 6 May 2015 at 20:07, Oliver Heger oliver.he...@oliver-heger.de wrote:
 Hi Ron,

 Am 06.05.2015 um 03:38 schrieb DiFrango, Ronald (CONT):
 Oliver,

 I guess I could build it from source and store it in our local Nexus 
 until a release version is built.


 this is of course possible. I do not expect major or breaking changes
 until the final release.

 Thanks for your feedback, this is indeed motivating :-)

 Oliver

 Ron DiFrango

 -Original Message-
 From: DiFrango, Ronald (CONT) [mailto:ronald.difra...@capitalone.com]
 Sent: Tuesday, May 05, 2015 4:23 PM
 To: Commons Users List
 Subject: RE: [configuration] Apache Commons Configuration Version 2

 Oliver,

 I figured it would be something like that and that's understandable as is 
 the time-table.  We definitely like the feature set of 2.x as it supports 
 many of the uses cases more naturally than 1.x so would like to move 
 forward with it.

 But I can't unless it's in maven central.

 Thanks,

 Ron


 -Original Message-
 From: Oliver Heger [mailto:oliver.he...@oliver-heger.de]
 Sent: Tuesday, May 05, 2015 4:20 PM
 To: Commons Users List
 Subject: Re: [configuration] Apache Commons Configuration Version 2

 Hi Ron,

 Am 05.05.2015 um 22:09 schrieb DiFrango, Ronald (CONT):
 All,

 Is Apache commons configuration in maven central or some other repo?  
 I'm using Gradle and pointing to an internal Nexus repo that is a proxy 
 for Maven central and I can't resolve it as follows:

 compile group: 'org.apache.commons', name: 'commons-configuration2', 
 version: '2.0-alpha2'



 because it is only an alpha release, this version has not been deployed 
 to a public Maven repository. We did this by intension to avoid potential 
 jar hell if there are still binary incompatible changes before the final 
 release.

 I am working to get the final version 2.0 out, but unfortunately my time 
 is currently pretty limited. So I cannot predict a release schedule.

 Oliver

 Thanks,

 Ron

 

 The information contained in this e-mail is confidential and/or 
 proprietary to Capital One and/or its affiliates. The information 
 transmitted herewith is intended only for use by the individual or 
 entity to which it is addressed.  If the reader of this message is not 
 the intended recipient, you are hereby notified that any review, 
 retransmission, dissemination, distribution, copying or other use of, or 
 taking of any action in reliance upon this information is strictly 
 prohibited. If you have received this communication in error, please 
 contact the sender and delete the material from your computer.


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

 

 The information contained in this e-mail is confidential and/or 
 proprietary to Capital One and/or its affiliates. The information 
 transmitted herewith is intended only for use by the individual or entity 
 to which it is addressed.  If the reader of this message is not the 
 intended recipient, you are hereby notified that any review, 
 retransmission, dissemination, distribution, copying or other

Re: [configuration] Apache Commons Configuration Version 2

[sebb]

Yes, it might cause a problem to publish an RC.

Any publication to Maven Central effectively freezes the current public API.
If a problem is then found, generally the only solution that avoids
jar hell is to release a new version with different package name and
different Maven coords - i.e. effectively a different product.
This will not be a drop-in replacement, and will require source code
changes by anyone using it.

On 7 May 2015 at 03:54, DiFrango, Ronald (CONT)
ronald.difra...@capitalone.com wrote:
 Yeah, I would prefer to avoid the snap-shot repo, so if nothing else I'll 
 build a version locally and upload it to our local Nexus.

 One question, if this is close, would it hurt to pulish an RC into Maven 
 Central?

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: Wednesday, May 06, 2015 9:20 PM
 To: Commons Users List
 Subject: Re: [configuration] Apache Commons Configuration Version 2

 You should also be able to get it from the ASF snapshot repo.

 However note that such artifacts may change or disappear at any time, so 
 should only be used for testing.

 On 6 May 2015 at 20:07, Oliver Heger oliver.he...@oliver-heger.de wrote:
 Hi Ron,

 Am 06.05.2015 um 03:38 schrieb DiFrango, Ronald (CONT):
 Oliver,

 I guess I could build it from source and store it in our local Nexus until 
 a release version is built.


 this is of course possible. I do not expect major or breaking changes
 until the final release.

 Thanks for your feedback, this is indeed motivating :-)

 Oliver

 Ron DiFrango

 -Original Message-
 From: DiFrango, Ronald (CONT) [mailto:ronald.difra...@capitalone.com]
 Sent: Tuesday, May 05, 2015 4:23 PM
 To: Commons Users List
 Subject: RE: [configuration] Apache Commons Configuration Version 2

 Oliver,

 I figured it would be something like that and that's understandable as is 
 the time-table.  We definitely like the feature set of 2.x as it supports 
 many of the uses cases more naturally than 1.x so would like to move 
 forward with it.

 But I can't unless it's in maven central.

 Thanks,

 Ron


 -Original Message-
 From: Oliver Heger [mailto:oliver.he...@oliver-heger.de]
 Sent: Tuesday, May 05, 2015 4:20 PM
 To: Commons Users List
 Subject: Re: [configuration] Apache Commons Configuration Version 2

 Hi Ron,

 Am 05.05.2015 um 22:09 schrieb DiFrango, Ronald (CONT):
 All,

 Is Apache commons configuration in maven central or some other repo?  I'm 
 using Gradle and pointing to an internal Nexus repo that is a proxy for 
 Maven central and I can't resolve it as follows:

 compile group: 'org.apache.commons', name: 'commons-configuration2', 
 version: '2.0-alpha2'



 because it is only an alpha release, this version has not been deployed to 
 a public Maven repository. We did this by intension to avoid potential jar 
 hell if there are still binary incompatible changes before the final 
 release.

 I am working to get the final version 2.0 out, but unfortunately my time is 
 currently pretty limited. So I cannot predict a release schedule.

 Oliver

 Thanks,

 Ron

 

 The information contained in this e-mail is confidential and/or 
 proprietary to Capital One and/or its affiliates. The information 
 transmitted herewith is intended only for use by the individual or entity 
 to which it is addressed.  If the reader of this message is not the 
 intended recipient, you are hereby notified that any review, 
 retransmission, dissemination, distribution, copying or other use of, or 
 taking of any action in reliance upon this information is strictly 
 prohibited. If you have received this communication in error, please 
 contact the sender and delete the material from your computer.


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

 

 The information contained in this e-mail is confidential and/or proprietary 
 to Capital One and/or its affiliates. The information transmitted herewith 
 is intended only for use by the individual or entity to which it is 
 addressed.  If the reader of this message is not the intended recipient, 
 you are hereby notified that any review, retransmission, dissemination, 
 distribution, copying or other use of, or taking of any action in reliance 
 upon this information is strictly prohibited. If you have received this 
 communication in error, please contact the sender and delete the material 
 from your computer.


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

 

 The information contained in this e-mail is confidential and/or proprietary 
 to Capital One