Re: [JXPath] Release 1.4

On Nov 18, 2015 4:18 AM, "Benedikt Ritter" wrote: > > Hello Uwe, > > 2015-11-17 6:22 GMT+01:00 Uwe Barthel : > > > Hi, > > > > If there is any 1.4 release planned? > > > > Not only this resolved item JXPATH-131 is really interesting to find in a > > new

Re: [JXPath] Release 1.4

2015-11-18 16:45 GMT+01:00 Gary Gregory : > On Nov 18, 2015 4:18 AM, "Benedikt Ritter" wrote: > > > > Hello Uwe, > > > > 2015-11-17 6:22 GMT+01:00 Uwe Barthel : > > > > > Hi, > > > > > > If there is any 1.4 release planned? > > >

RE: [VFS] Further changes to HDFS Provider for alternate configuration support

I have opened issue https://issues.apache.org/jira/browse/VFS-586 with my proposed patch attached, and these questions included in the issue. Updated the patch with some things I noticed after the initial post also. Thanks, ~Roger -Original Message- From: dlmar...@comcast.net

Re: [JXPath] Release 1.4

Hi, I could take a look at the open issues. There are 33 open issues in jira (https://issues.apache.org/jira/issues/?jql=project%20%3D%20JXPATH%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29) and 3 open pull requests. But, I'm looking forward to a early release and

Re: [JXPath] Release 1.4

The POM is missing compiler settings for source and target Java versions. I think this should be set in this POM and not inherited. Gary On Wed, Nov 18, 2015 at 12:39 PM, Uwe Barthel wrote: > Hi, > > I could take a look at the open issues. > There are 33 open issues in

[MATH] Comment request for MATH-1291 and MATH-1292: Patches to ComplexUtils and LaguerreSolver to match proposed ComplexUtils nomenclature

I have filed two trivial JIRA issues, MATH-1291 and MATH-1292 and request comment. I would like to replace a current method "convertToComplex" with "real2Complex" so that it matches the nomenclature of the other proposed methods for ComplexUtils currently in my fork (these are in issue

Re: [JXPath] Release 1.4

Hello Uwe, 2015-11-17 6:22 GMT+01:00 Uwe Barthel : > Hi, > > If there is any 1.4 release planned? > > Not only this resolved item JXPATH-131 is really interesting to find in a > new release. > > Which Apache Commons committer is ready to bring JXPath one step forward > and

Re: [JXPath] Release 1.4

On Wed, Nov 18, 2015 at 1:09 PM, Benedikt Ritter wrote: > 2015-11-18 21:46 GMT+01:00 Gary Gregory : > > > The POM is missing compiler settings for source and target Java > versions. I > > think this should be set in this POM and not inherited. > > > >

Eirik Bjørsnøs' notsoserial deserialization protection agent, for Commons?

Hi Commons PMC, I'd like to introduce Eirik Bjørsnøs to this list (CCed) as the author of the https://github.com/kantega/notsoserial agent. I tested his agent in a variety of scenarios and it looks to me like a great solution for the COLLECTIONS-580 deserialization issue, for cases when one

Re: Eirik Bjørsnøs' notsoserial deserialization protection agent, for Commons?

Using the agent in (and only in) whitelist mode is a pretty strong and quick security measure. Calling this a "great solution" still goes against my inner developer soul though. It's pragmatic and a good tool - that I am on board with. (Cool stuff, Eirik) Yet it feels a bit like putting a thumb

Re: Eirik Bjørsnøs' notsoserial deserialization protection agent, for Commons?

On Wed, Nov 18, 2015 at 7:16 PM, Torsten Curdt wrote: > ...it feels a bit like putting a thumb into a hole to stop the water. > People need to re-think their use of reflection and serialization - not > cover up bad engineering practices... Absolutely - but depending on people's

Re: Eirik Bjørsnøs' notsoserial deserialization protection agent, for Commons?

Le 19/11/2015 01:24, Bertrand Delacretaz a écrit : On Wed, Nov 18, 2015 at 7:16 PM, Torsten Curdt wrote: ...it feels a bit like putting a thumb into a hole to stop the water. People need to re-think their use of reflection and serialization - not cover up bad engineering

[LANG] Why is project.build.sourceencoding set to ISO-8859-1?

Hi, see above... Does anybody know why we don't we use UTF-8? Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter

Re: [LANG] Why is project.build.sourceencoding set to ISO-8859-1?

Le 19/11/2015 08:03, Benedikt Ritter a écrit : > see above... Does anybody know why we don't we use UTF-8? Because we don't use any non latin character in the source code (yet) ? - To unsubscribe, e-mail:

Re: [JXPath] Release 1.4

2015-11-18 21:46 GMT+01:00 Gary Gregory : > The POM is missing compiler settings for source and target Java versions. I > think this should be set in this POM and not inherited. > Fixed in revision 1715068. > > Gary > > On Wed, Nov 18, 2015 at 12:39 PM, Uwe Barthel