from:"Bernd"

The issues of the j.u.Random implementation are only for the default 
implementation, if you provide a different algorithm (from Securearandom or any 
distribution from RNG) you can avoid it (if needed)

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Fri, Dec 30, 2016 at 10:50 PM +0100, "Gilles" <gil...@harfang.homelinux.org> 
wrote:










On Fri, 30 Dec 2016 18:22:37 +0000 (UTC), Bernd Eckenfels wrote:
> Hello,
> You suggested to use UniformRandomProvider in TEXT-36.
> I suggest to use j.u.Random because it is a common (interface like)

I know that already.
To advance the discussion, could you please comment on the issues
in the document I referred to below?

> type which is easy to provide any alternative random provider you
> would want (on protected method to implement)

See document.

> - just like InputStream
> is a commonly subtyped base class.

Comparison is not reason.
Perhaps "InputStream" is not as flawed as "Random"...

> In a lot of situations people will be happy with j.u.R

I bet that in the majority of those cases, they are happy
because they don't know better (a variation on "security
through obscurity").  I was among them a year ago.

Anyways my proposal takes care of people who'd insist on getting
randomness from "Random"; they'll choose the corresponding bridge,
with the knowledge that an LCG generator fails ~70 tests of
uniformity whereas state-of-the-art RNG algorithms fail 1 or 2
(see reports in RNG's user guide).

> or they can
> use SecureRandom (which also implements j.u.R),

Yet another flaw of old JDK's design decisions...
Anyways, the bridge allows this equally well.

> but if the need more
> control over the RNG or the distribution they can easily adjust. No
> multi-module or optional dependency is needed for that.
> And the RNG->j.u.Random bridge can be provided in RNG for other uses 
> as well.

I already wrote that such a bridge exists (see Javadoc of RNG's
"commons-rng-simple" module).
It is a sub-par solution.
There is no reason to stick to java.util.Random.

Where is the problem with a modular component?
This will be transparent to the average user (who, by the way,
wouldn't care less if there were a mandatory dependency on
Commons RNG).
For those who want more control of dependencies, it also won't
be a problem to state explicitly which bridge they want to use.


Gilles

>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
>
>
>
> On Fri, Dec 30, 2016 at 7:11 PM +0100, "Gilles"
>  wrote:
>
>
>
>
>
>
>
>
>
>
> On Fri, 30 Dec 2016 17:30:17 + (UTC), Bernd Eckenfels wrote:
>> Sorry I meant *uniform* distribution
>>
>> Gruss
>> Bernd
>>
>>
>>
>>
>>
>> On Fri, Dec 30, 2016 at 5:58 PM +0100, "Bernd Eckenfels"
>>  wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hello,
>> I am somewhat unclear, why would you require a random distribution
>> (Interface).
>
> Who said?
>
>> Is there no better more generic Interface in RNG-API?
>
> Have you had a look at
>
> 
> http://commons.apache.org/proper/commons-rng/commons-rng-client-api/index.html
> ?
>
>> Having said that I still think j.u.Random is fine
>
> Have you read
>
> 
> http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html
> ?
>
> Why use a poor algorithm when using a better one is as easy?
>
>> - but if not maybe a
>> byte or int Provider would be better than a specific interface for
>> the
>> random source.
>
> I don't follow.
> How do you define this "Provider" if not with an interface?
>
> Gilles
>
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>>
>>
>>
>>
>> On Fri, Dec 30, 2016 at 5:04 PM +0100, "Jörg Schaible"
>>  wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Gilles wrote:
>>
>>> Hi.
>>>
>>> On Fri, 30 Dec 2016 09:40:20 -0500, Rob Tompkins wrote:
>>>> Hello all,
>>>>
>>>> Personally, I would like to resolve the TEXT-36 and TEXT-42 Jira
>>>> tickets before proceeding with the release, but I wanted to check
>>>> to
>>>> see if anyone else has any opinions on what work needs to be
>>>> completed
>>>> before the release.
>>>>
>>>> Regarding TEXT-36: 'Dependency on “Commons RNG” ‘, I’m relatively
>>>> indifferent here, I just want some other’s to weigh in as to their
>>>> thoughts before deciding to leave in the dependency
&g

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Hello,
You suggested to use UniformRandomProvider in TEXT-36.
I suggest to use j.u.Random because it is a common (interface like) type which 
is easy to provide any alternative random provider you would want (on protected 
method to implement) - just like InputStream is a commonly subtyped base class.
In a lot of situations people will be happy with j.u.R or they can use 
SecureRandom (which also implements j.u.R), but if the need more control over 
the RNG or the distribution they can easily adjust. No multi-module or optional 
dependency is needed for that.
And the RNG->j.u.Random bridge can be provided in RNG for other uses as well.

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Fri, Dec 30, 2016 at 7:11 PM +0100, "Gilles" <gil...@harfang.homelinux.org> 
wrote:










On Fri, 30 Dec 2016 17:30:17 + (UTC), Bernd Eckenfels wrote:
> Sorry I meant *uniform* distribution
>
> Gruss
> Bernd
>
>
>
>
>
> On Fri, Dec 30, 2016 at 5:58 PM +0100, "Bernd Eckenfels"
>  wrote:
>
>
>
>
>
>
>
>
>
>
> Hello,
> I am somewhat unclear, why would you require a random distribution
> (Interface).

Who said?

> Is there no better more generic Interface in RNG-API?

Have you had a look at
   
http://commons.apache.org/proper/commons-rng/commons-rng-client-api/index.html
?

> Having said that I still think j.u.Random is fine

Have you read
   
http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html
?

Why use a poor algorithm when using a better one is as easy?

> - but if not maybe a
> byte or int Provider would be better than a specific interface for 
> the
> random source.

I don't follow.
How do you define this "Provider" if not with an interface?

Gilles

>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
>
>
>
> On Fri, Dec 30, 2016 at 5:04 PM +0100, "Jörg Schaible"
>  wrote:
>
>
>
>
>
>
>
>
>
>
> Gilles wrote:
>
>> Hi.
>>
>> On Fri, 30 Dec 2016 09:40:20 -0500, Rob Tompkins wrote:
>>> Hello all,
>>>
>>> Personally, I would like to resolve the TEXT-36 and TEXT-42 Jira
>>> tickets before proceeding with the release, but I wanted to check 
>>> to
>>> see if anyone else has any opinions on what work needs to be
>>> completed
>>> before the release.
>>>
>>> Regarding TEXT-36: 'Dependency on “Commons RNG” ‘, I’m relatively
>>> indifferent here, I just want some other’s to weigh in as to their
>>> thoughts before deciding to leave in the dependency
>>
>> I don't follow.
>> Currently, there is no dependency towards RNG.
>>
>> Personally, I'm in favour of an API that "advertizes" and recommends
>> usage of its RNG sibling component.  [As [TEXT] is, admittedly, a
>> high-level component (and it already depends on [LANG]).]
>>
>> However a consensual proposal would be to define a custom interface
>> (see JIRA discussion), and define the API around it.
>>
>> [TEXT] should be made "multimodule"; it could then provide bridges
>> (cf. JIRA comment) in separate modules:
>>
>>   * commons-text-core (algos)
>>   * commons-text-commons-rng-bridge (from
>> "o.a.c.rng.UniformRandomProvider")
>>   * commons-text-jdk-bridge (from "java.util.Random")
>>
>> The dependency towards Commons RNG thus becomes optional.
>> But application developers have to explicitly choose an
>> implementation (which is good).
>
> You can achieve something similar by declaring commons-rng as 
> optional. If
> you introduce an API for the random functionality and one 
> implementation is
> based on commons-rng, any user will have to declare this dependency 
> on his
> own if he like to use this implementation.
>
> We have a similar setup in vfs where you have to declare jsch as 
> dependency
> on your own if you want SSH support for the protocol in use.
>
>>> and making more
>>> progress on the best pattern after the 1.0 release.
>>
>> API decisions must be made before a major release.
>>
>> The best pattern is the above (IMHO, and as per Jochen's note):
>> higher flexibility and higher correctness.
>
> Cheers,
> Jörg
>


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

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Sorry I meant *uniform* distribution

Gruss
Bernd





On Fri, Dec 30, 2016 at 5:58 PM +0100, "Bernd Eckenfels" 
<e...@zusammenkunft.net> wrote:










Hello,
I am somewhat unclear, why would you require a random distribution (Interface). 
Is there no better more generic Interface in RNG-API? Having said that I still 
think j.u.Random is fine - but if not maybe a byte or int Provider would be 
better than a specific interface for the random source.

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Fri, Dec 30, 2016 at 5:04 PM +0100, "Jörg Schaible" <joerg.schai...@gmx.de> 
wrote:










Gilles wrote:

> Hi.
> 
> On Fri, 30 Dec 2016 09:40:20 -0500, Rob Tompkins wrote:
>> Hello all,
>>
>> Personally, I would like to resolve the TEXT-36 and TEXT-42 Jira
>> tickets before proceeding with the release, but I wanted to check to
>> see if anyone else has any opinions on what work needs to be
>> completed
>> before the release.
>>
>> Regarding TEXT-36: 'Dependency on “Commons RNG” ‘, I’m relatively
>> indifferent here, I just want some other’s to weigh in as to their
>> thoughts before deciding to leave in the dependency
> 
> I don't follow.
> Currently, there is no dependency towards RNG.
> 
> Personally, I'm in favour of an API that "advertizes" and recommends
> usage of its RNG sibling component.  [As [TEXT] is, admittedly, a
> high-level component (and it already depends on [LANG]).]
> 
> However a consensual proposal would be to define a custom interface
> (see JIRA discussion), and define the API around it.
> 
> [TEXT] should be made "multimodule"; it could then provide bridges
> (cf. JIRA comment) in separate modules:
> 
>   * commons-text-core (algos)
>   * commons-text-commons-rng-bridge (from
> "o.a.c.rng.UniformRandomProvider")
>   * commons-text-jdk-bridge (from "java.util.Random")
> 
> The dependency towards Commons RNG thus becomes optional.
> But application developers have to explicitly choose an
> implementation (which is good).

You can achieve something similar by declaring commons-rng as optional. If 
you introduce an API for the random functionality and one implementation is 
based on commons-rng, any user will have to declare this dependency on his 
own if he like to use this implementation.

We have a similar setup in vfs where you have to declare jsch as dependency 
on your own if you want SSH support for the protocol in use.

>> and making more
>> progress on the best pattern after the 1.0 release.
> 
> API decisions must be made before a major release.
> 
> The best pattern is the above (IMHO, and as per Jochen's note):
> higher flexibility and higher correctness.

Cheers,
Jörg


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

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Hello,
I am somewhat unclear, why would you require a random distribution (Interface). 
Is there no better more generic Interface in RNG-API? Having said that I still 
think j.u.Random is fine - but if not maybe a byte or int Provider would be 
better than a specific interface for the random source.

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Fri, Dec 30, 2016 at 5:04 PM +0100, "Jörg Schaible" <joerg.schai...@gmx.de> 
wrote:










Gilles wrote:

> Hi.
> 
> On Fri, 30 Dec 2016 09:40:20 -0500, Rob Tompkins wrote:
>> Hello all,
>>
>> Personally, I would like to resolve the TEXT-36 and TEXT-42 Jira
>> tickets before proceeding with the release, but I wanted to check to
>> see if anyone else has any opinions on what work needs to be
>> completed
>> before the release.
>>
>> Regarding TEXT-36: 'Dependency on “Commons RNG” ‘, I’m relatively
>> indifferent here, I just want some other’s to weigh in as to their
>> thoughts before deciding to leave in the dependency
> 
> I don't follow.
> Currently, there is no dependency towards RNG.
> 
> Personally, I'm in favour of an API that "advertizes" and recommends
> usage of its RNG sibling component.  [As [TEXT] is, admittedly, a
> high-level component (and it already depends on [LANG]).]
> 
> However a consensual proposal would be to define a custom interface
> (see JIRA discussion), and define the API around it.
> 
> [TEXT] should be made "multimodule"; it could then provide bridges
> (cf. JIRA comment) in separate modules:
> 
>   * commons-text-core (algos)
>   * commons-text-commons-rng-bridge (from
> "o.a.c.rng.UniformRandomProvider")
>   * commons-text-jdk-bridge (from "java.util.Random")
> 
> The dependency towards Commons RNG thus becomes optional.
> But application developers have to explicitly choose an
> implementation (which is good).

You can achieve something similar by declaring commons-rng as optional. If 
you introduce an API for the random functionality and one implementation is 
based on commons-rng, any user will have to declare this dependency on his 
own if he like to use this implementation.

We have a similar setup in vfs where you have to declare jsch as dependency 
on your own if you want SSH support for the protocol in use.

>> and making more
>> progress on the best pattern after the 1.0 release.
> 
> API decisions must be made before a major release.
> 
> The best pattern is the above (IMHO, and as per Jochen's note):
> higher flexibility and higher correctness.

Cheers,
Jörg


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

Re: [ALL] Changing the commons process

2016-12-24 Thread Bernd Eckenfels

Hello Ralph, besides the strange .pgp.asc files (and I think some components 
don't have that problem) the component releases should not need to actually 
delete artifacts in the staged repo when running the documented release 
goal/profile.
You can in the POM control what is attached for some plugins (like assembly) 
and for others you could use the build helper to detach.
Are there any commons projects which requires manual deletes? We should fix 
them not only to reduce work, but also to ensure a repeatable build. (This does 
not look like a general process problem to me, it's more like POM nuances)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

On Sun, Dec 25, 2016 at 12:02 AM +0100, "Apache" <ralph.go...@dslextreme.com> 
wrote:

Maven is going to publish all the artifacts that are built to the repository.  
This isn’t necessarily a bad thing as people can look at them all in one place 
during the vote. But after the vote is approved anything that a user wouldn’t 
ever want in a maven build should be deleted before the release button is 
pushed. This includes things like examples and the whole distribution. During 
the vote the release manager should be downloading everything from the 
repository so he can validate the build any way. It is a simple matter to take 
the distribution files and commit them where they belong.

All the things you are discussion here are what I have been dealing with for 
the last several years in Log4j 2. The steps in the release process aren’t what 
cause me pain. It is simply the time it takes to run a release build, verify 
it, fix any problems, and then run it again as needed - all of which I do 
before I send out a vote email.  I don’t really see any way to make that 
shorter.

Ralph

> On Dec 24, 2016, at 3:28 PM, Charles Honton  wrote:
> 
> I tested IDEs with a non-standard packaging of  -sources.jar; java sources 
> were inside of src/main/java/ folder.
> - Eclipse was able to use.
> - IntelliJ was able to use with a few extra clicks.
> - Netbeans was NOT able to use.
> I don’t think this option should be pursued further.
> 
> A better alternative to consider is what the maven projects do.  They release 
> a -source-release.zip at https://www.apache.org/dist/maven/ which is also 
> pushed to maven central.  This zip looks to be similar to a maven predefined 
> ‘project’ assembly.
> 
> The maven plugins inherited pom  contains the following:
>
>
>  apache-release
>  
>
>  
>  
>org.apache.maven.plugins
>maven-assembly-plugin
>
>  
>org.apache.apache.resources
>apache-source-release-assembly-descriptor
>1.0.6
>  
>
>
>  
>source-release-assembly
>package
>
>  single
>
>
>  true
>  
>source-release
>  
>  posix
>
>  
>
>  
>  
>  
>true
>org.apache.maven.plugins
>maven-deploy-plugin
>
>  true
>
>  
>  
>org.apache.maven.plugins
>maven-source-plugin
>
>  
>attach-sources
>
>  jar-no-fork
>
>  
>
>  
>  
>org.apache.maven.plugins
>maven-javadoc-plugin
>
>  
>attach-javadocs
>
>  jar
>
>  
>
>  
>  
>  
>org.apache.maven.plugins
>maven-gpg-plugin
>
>  
>sign-release-artifacts
>
>  sign
>
>  
>
>  
>
>  
>
>

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

Re: [ALL] Changing the commons process

2016-12-23 Thread Bernd Eckenfels

Hello,
I think hybrid -sry/source does not work very well, since the IDE expect a 
package-like directory structure. I am not sure it would work with src/main/ 
prefix.

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Fri, Dec 23, 2016 at 11:33 PM +0100, "Gary Gregory" <garydgreg...@gmail.com> 
wrote:










On Fri, Dec 23, 2016 at 12:54 PM, Charles Honton  wrote:

> Several recent email threads have discussed our parent pom and release
> process.  The process we have derive from Apache Common’s rich history
> which pre-dates many current distribution practices.  I’d like to summarize
> several quirks with our current releases:
> The official release source tarball contains just the sources, not all the
> project files.  Building the artifact from just the src directory without
> the pom would be extremely difficult.
> The commons parent pom attaches the source tarball to the maven release
> for the side effects of signing/checksumming the source tarball.  This
> induces a manual step of removing the source tarballs from the staging
> repository.
> We publish convenience binaries to https://www.apache.org/dist/
> commons/XXX/binaries.  I doubt anyone consumes these binaries.  Most
> developers use Maven Central.  Extremely security conscious downstream
> projects consume the distribution source tarballs.
> The distribution artifacts are doubled in size by providing both .zip and
> tar.gz versions.
> Slightly different artifacts are published to Apache Distribution Site vs
> Maven Central.
>
> Now the questions:
>
> 1. Are there any concerns with publishing the source and source-test jars
> produced by maven-source-plugin as the official distribution artifacts?


You cannot build from the -source jars so that would not work. We could ADD
stuff to these jars to make them the same as the -src.zip files. Then we do
not need the -src.zip/tar.gz files.



> This would make the official distribution artifacts published to
> https://www.apache.org/dist/commons/XXX/source the same as the
> convenience source artifacts published to Maven Central.
>
> 2. Are there concerns with not publishing the convenience binaries to
> https://www.apache.org/dist/commons/XXX/binaries?  Alternatively, are
> there concerns with using the the jar produced by maven-jar-plugin as the
> convenience binary artifact?  This would make the convenience binary
> artifact published to https://www.apache.org/dist/commons/XXX/binaries
> the same as the convenience binary artifacts published to Maven Central.
>

Since the binaries are conveniences, we can do whatever we want IMO.


>
> Some background information to help contemplate these questions:
>
> When releasing a package, Apache Commons publishes the official source
> tarball at https://www.apache.org/dist/commons/XXX/source.  The Apache
> Release Policy  release-contain> and Release Signing Policy  
> release-distribution.html#sigs-and-sums> require:
> “Every ASF release must contain a source package, which must be sufficient
> for a user to build and test the release provided they have access to the
> appropriate platform and tools”
> "Every artifact distributed to the public through Apache channels MUST be
> accompanied by one file containing an OpenPGP compatible ASCII armored
> detached signature and another file containing an MD5 checksum.” (.asc file
> and .md5 file)
>
> Apache Commons also distributes convenience binaries at
> https://www.apache.org/dist/commons/XXX/binaries. These convenience
> binaries must also be signed and checksummed.
>
> For even more convenience, Apache Commons also publishes packages to Maven
> Central.  Maven Central policy  pages/requirements.html> requires:
> “Projects with packaging other than pom have to supply JAR files that
> contain Javadoc and sources.”
> “All files deployed need to be signed with GPG/PGP and a .asc file
> containing the signature must be included for each file.”
> A pom file with
> Correct Coordinates
> Project Name, Description and URL
> License Information
> Developer Information
> SCM Information


A lighter weight system would:

- Publish the same as we do now to Maven Central PLUS adding all of the
files needed to build to *-sources.jar files such that they become the same
as *-src.zip/*-src.tar.gz files.
- Publish the *-sources jar file to https://www.apache.org/dist/
commons/XXX/source instead of the *-src.zip/*-src.tar.gz files.
- Stop publishing *-bin files

The question is, if we publish a build-able *-source.jar file to
https://repository.apache.org/content/repositories/releases/org/apache/commons/,
why do we need to double that up and ALSO publish to
https://www.apache.org/dist/commons/XXX/source ?

Not publishing to https://www.apache.org/dist/commons/
 would really simplify
things

Re: [ALL] Changing the commons process

2016-12-23 Thread Bernd Eckenfels

Am Fri, 23 Dec 2016 12:54:14 -0800
schrieb Charles Honton <c...@honton.org>:

> The
> official release source tarball contains just the sources, not all
> the project files.  Building the artifact from just the src directory
> without the pom would be extremely difficult.

Can you name a component where this is true? Afaik all Commons
components have a full featured source archive which is buildable and a
limited source attachment for maven.

> The commons parent pom
> attaches the source tarball to the maven release for the side effects
> of signing/checksumming the source tarball.

Only for the -src classifier, this is Maven best practice since IDEs
can download and display this.

> This induces a manual
> step of removing the source tarballs from the staging repository.

I dont think removing them is the actual intention.

> We
> publish convenience binaries to
> https://www.apache.org/dist/commons/XXX/binaries.  I doubt anyone
> consumes these binaries.  Most developers use Maven Central.

This depends entirely on the project type they are used in. I would not
divert from this as it helps to actually find the artifacts and
especially release notes.

> Extremely security conscious downstream projects consume the
> distribution source tarballs. The distribution artifacts are doubled
> in size by providing both .zip and tar.gz versions.

Why would we care?

> Slightly
> different artifacts are published to Apache Distribution Site vs
> Maven Central.

Uh, how can that happen, the release process verifies the checksums.

Gruss
Bernd

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

Re: (DBUTILS-131) Speedup query calls without parameters

2016-12-10 Thread Bernd Eckenfels

Hello,
What database system/driver did you test? Did you test repeating statements or 
not. Because some drivers optimize statement caches only for prepared 
statements. This also means it should be configurable.

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Sat, Dec 10, 2016 at 10:34 PM +0100, "Yair Lenga (JIRA)" <j...@apache.org> 
wrote:










Yair Lenga created DBUTILS-131:
--

 Summary: Speedup query calls without parameters
 Key: DBUTILS-131
 URL: https://issues.apache.org/jira/browse/DBUTILS-131
 Project: Commons DbUtils
  Issue Type: Improvement
Affects Versions: 1.6
Reporter: Yair Lenga


The current 'query' methods takes sql (with ? placeholders), and list of 
parameters to fill the place holders. The implementation is using a prepared 
statement to speed up the call.

I've observed that for statements without any ? placeholders, performance can 
be improved by using the statement interface. Using this path eliminate extra 
roundtrip and work that is needed to create the prepared statement (I believe 
it's implemented - on Sybase - as light weight stored proc). 

My proposal: modify the code in the method that implement the query:
private  T  [More ...] query(Connection conn, boolean closeConn, String sql, 
ResultSetHandler rsh, Object... params)

and use 'Statement', instead of preparedStatement if there are no params 
(params == null || params.size() == 0 )

In my application, large number of (parameter-less) SQL statement are generated 
on-the-fly, and the result set is converted to BeanList. We measured 50% 
speedup using statements, instead of prepared statements for this case.

We will be happy to submit a fix or help with testing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: VFS - CIFS (Sandbox) Query

2016-12-06 Thread Bernd Eckenfels

Hello,
I hink it is pretty complete (work is never done I guess, but if you miss 
something it would be good to know what it is exactly).
If your question is in regards to the sandbox, then I am afraid as long as we 
do not have a license-compatible library for CIFS we can not officially release 
that component (In this case sandbox does not mean incomplete).
The most likely development is that the sandbox is dropped, hopefully somebody 
would release a forked binary outside the ASF. (Not sure how that would be done 
in regards to package naming).
Gruss
Bernd
-- 
http://bernd.eckenfels.net

_
From: A, Karthik (Karthik(R)) <anan...@avaya.com>
Sent: Dienstag, Dezember 6, 2016 4:34 PM
Subject: VFS - CIFS (Sandbox) Query
To:  <dev@commons.apache.org>


Hi,

Can you please tell me when the VFS - CIFS implementation is expected to be 
completed? A rough estimate would help me plan my work.

Thanks for the great APIs that you guys are providing!

Regards,
Karthik

Re: svn commit: r1771815 - /commons/proper/daemon/trunk/src/native/windows/src/service.c

2016-11-28 Thread Bernd Eckenfels

Hello Mark,

are we sure the removed TODO is not related with apxPoolAlloc() return
code?

(I also miss the inserted closing brace, does it still compile? Is that
a different commit?)

Gruss
Bernd


 Am Mon, 28 Nov 2016 21:04:06 -
schrieb ma...@apache.org:

> Author: markt
> Date: Mon Nov 28 21:04:06 2016
> New Revision: 1771815
> 
> URL: http://svn.apache.org/viewvc?rev=1771815=rev
> Log:
> Fix regression in r1771804
> 
> Modified:
> commons/proper/daemon/trunk/src/native/windows/src/service.c
> 
> Modified: commons/proper/daemon/trunk/src/native/windows/src/service.c
> URL:
> http://svn.apache.org/viewvc/commons/proper/daemon/trunk/src/native/windows/src/service.c?rev=1771815=1771814=1771815=diff
> ==
> --- commons/proper/daemon/trunk/src/native/windows/src/service.c
> (original) +++
> commons/proper/daemon/trunk/src/native/windows/src/service.c Mon Nov
> 28 21:04:06 2016 @@ -147,7 +147,7 @@ apxServiceOpen(APXHANDLE
> hService, LPCWS lpService->stServiceEntry.szObjectName[0] = L'\0'; }
> if (!QueryServiceConfigW(lpService->hService, NULL, 0, )) {
> -if (GetLastError() == ERROR_INSUFFICIENT_BUFFER)
> +if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) {
>   // This is expected. The call is expected to fail
> with the required // buffer size set in dwNeeded.
>   // Clear the last error to prevent it being logged
> if a genuine @@ -157,7 +157,6 @@ apxServiceOpen(APXHANDLE hService,
> LPCWS apxLogWrite(APXLOG_MARK_SYSERR);
>  }
>  }
> -/* TODO: Check GetLastError  ERROR_INSUFFICIENT_BUFFER */
>  lpService->stServiceEntry.lpConfig =
> (LPQUERY_SERVICE_CONFIGW)apxPoolAlloc(hService->hPool, dwNeeded);
>  return QueryServiceConfigW(lpService->hService,
> 
> 


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

Re: [VOTE] Accept Commons RDF as a new component

2016-11-24 Thread Bernd Eckenfels

(... sorry got interrupted)
... there are arguments for a commons component, but it could also be arguments 
having a dedicated community. So I wanted to express that with an abstain.

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Thu, Nov 24, 2016 at 4:02 PM +0100, "Bernd Eckenfels" 
<e...@zusammenkunft.net> wrote:










Hello,
Thank you for the summmary. I was aware of the incubation and the discussion on 
rdf-dev. There are arguments for a common component, 

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Thu, Nov 24, 2016 at 12:05 PM +0100, "Sergio Fernández" <wik...@apache.org> 
wrote:










Hi Bern

On Wed, Nov 23, 2016 at 8:12 PM, Bernd Eckenfels 
wrote:

> +0 Undecided as there where no activity on commons-dev it feels to me
> like an other home would be better
>

That topic was already discussed:
http://markmail.org/message/u6wumpabst35xknn

Basically we felt Commons RDF was in a too early stage that it'd require a
dedicate mailing list for its conception. That's why the component was
moved to incubation first, so all discussion actually happened at
dev@commonsrdf.a.o. If the vote successes, we already agreed to accommodate
the new component to the Commons PMC conventions (i.e., move all
discussions to dev@commons.a.o using [RDF] as subjects' prefix).

I hope that explanation would satisfy your question, and you'll cast again
your vote.

Thanks.

Best,




Am Wed, 23 Nov
> 2016 13:47:03 + schrieb Stian Soiland-Reyes :
>
> > [Note: this is the Commons PMC vote on dev@commons - there's a
> > concurrent IPMC VOTE thread on general@incubator]
> >
> > Since Commons RDF entered incubation, it has evolved the understanding
> > of its purpose, developed and released code base that is now
> > stabilizing, moving towards a 1.0.0 release.
> >
> > Although the Commons RDF developer community is small it has continued
> > to grow interest, and Apache Commons feels like a natural home for the
> > component; as intended when this podling was started. We appreciate
> > all the help we have received from Commons while incubating, in
> > particular Gary and Benedikt!
> >
> >
> > The Commons RDF podling has voted to graduate from the Incubator
> > to join Apache Commons as a new component:
> >
> > https://lists.apache.org/thread.html/886ed903b3649203c794f7b7409f31
> 1b2391ebef1d9157177ba943b6@%3Cdev.commonsrdf.apache.org%3E
> >
> >
> > This email carries over 3 Commons PMC binding votes from
> > dev@commonsrdf:
> >
> >
> > +1 Stian Soiland-Reyes (Commons PMC binding)
> > +1 Benedikt Ritter (Commons PMC binding)
> > +1 Gary Gregory (Commons PMC binding)
> >
> >
> > Proposed component name: rdf
> >
> > Proposed package name: org.apache.commons.rdf
> >
> > Source code of RDF component:
> > https://git-wip-us.apache.org/repos/asf?p=incubator-commonsrdf.git
> > https://github.com/apache/incubator-commonsrdf
> >
> > Incubator releases:
> > http://archive.apache.org/dist/incubator/commonsrdf/
> >
> > Website:
> > http://commonsrdf.incubator.apache.org/
> >
> > Project Maturity report (more links from there):
> > https://github.com/apache/incubator-commonsrdf/blob/master/MATURITY.md
> >
> >
> > This email propose a VOTE to accept Commons RDF as a new component of
> > Apache Commons.
> >
> >
> > Formally the Apache Incubator PMC will also need to agree the
> > graduation, a concurrent vote thread is on
> >
> > https://lists.apache.org/list.html?gene...@incubator.apache.org
> >
> >
> >
> >
> > Please VOTE on graduating Commons RDF as new component:
> >
> > [ ] +1 Yes, accept Commons RDF as new component
> > [ ]  0 Undecided
> > [ ] -1 No, because...
> >
> >
> > This vote will be open for at least 72 hours, let's say 2016-11-26
> > 17:00 UTC.
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co

Re: [VOTE] Accept Commons RDF as a new component

2016-11-24 Thread Bernd Eckenfels

Hello,
Thank you for the summmary. I was aware of the incubation and the discussion on 
rdf-dev. There are arguments for a common component, 

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Thu, Nov 24, 2016 at 12:05 PM +0100, "Sergio Fernández" <wik...@apache.org> 
wrote:










Hi Bern

On Wed, Nov 23, 2016 at 8:12 PM, Bernd Eckenfels 
wrote:

> +0 Undecided as there where no activity on commons-dev it feels to me
> like an other home would be better
>

That topic was already discussed:
http://markmail.org/message/u6wumpabst35xknn

Basically we felt Commons RDF was in a too early stage that it'd require a
dedicate mailing list for its conception. That's why the component was
moved to incubation first, so all discussion actually happened at
dev@commonsrdf.a.o. If the vote successes, we already agreed to accommodate
the new component to the Commons PMC conventions (i.e., move all
discussions to dev@commons.a.o using [RDF] as subjects' prefix).

I hope that explanation would satisfy your question, and you'll cast again
your vote.

Thanks.

Best,




Am Wed, 23 Nov
> 2016 13:47:03 + schrieb Stian Soiland-Reyes :
>
> > [Note: this is the Commons PMC vote on dev@commons - there's a
> > concurrent IPMC VOTE thread on general@incubator]
> >
> > Since Commons RDF entered incubation, it has evolved the understanding
> > of its purpose, developed and released code base that is now
> > stabilizing, moving towards a 1.0.0 release.
> >
> > Although the Commons RDF developer community is small it has continued
> > to grow interest, and Apache Commons feels like a natural home for the
> > component; as intended when this podling was started. We appreciate
> > all the help we have received from Commons while incubating, in
> > particular Gary and Benedikt!
> >
> >
> > The Commons RDF podling has voted to graduate from the Incubator
> > to join Apache Commons as a new component:
> >
> > https://lists.apache.org/thread.html/886ed903b3649203c794f7b7409f31
> 1b2391ebef1d9157177ba943b6@%3Cdev.commonsrdf.apache.org%3E
> >
> >
> > This email carries over 3 Commons PMC binding votes from
> > dev@commonsrdf:
> >
> >
> > +1 Stian Soiland-Reyes (Commons PMC binding)
> > +1 Benedikt Ritter (Commons PMC binding)
> > +1 Gary Gregory (Commons PMC binding)
> >
> >
> > Proposed component name: rdf
> >
> > Proposed package name: org.apache.commons.rdf
> >
> > Source code of RDF component:
> > https://git-wip-us.apache.org/repos/asf?p=incubator-commonsrdf.git
> > https://github.com/apache/incubator-commonsrdf
> >
> > Incubator releases:
> > http://archive.apache.org/dist/incubator/commonsrdf/
> >
> > Website:
> > http://commonsrdf.incubator.apache.org/
> >
> > Project Maturity report (more links from there):
> > https://github.com/apache/incubator-commonsrdf/blob/master/MATURITY.md
> >
> >
> > This email propose a VOTE to accept Commons RDF as a new component of
> > Apache Commons.
> >
> >
> > Formally the Apache Incubator PMC will also need to agree the
> > graduation, a concurrent vote thread is on
> >
> > https://lists.apache.org/list.html?gene...@incubator.apache.org
> >
> >
> >
> >
> > Please VOTE on graduating Commons RDF as new component:
> >
> > [ ] +1 Yes, accept Commons RDF as new component
> > [ ]  0 Undecided
> > [ ] -1 No, because...
> >
> >
> > This vote will be open for at least 72 hours, let's say 2016-11-26
> > 17:00 UTC.
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co

Re: [Filter] Better name? (Was: [math] IIR filter library [...])

2016-11-24 Thread Bernd Porr


Hi Gilles,

I like the idea of "SigProc". Filter is a bit too narrow especially when 
we also include more exoctic processing and/or analysis etc.


In terms of complex: the filter package uses complex numbers but that's 
totally transparent to the user so for those who are not into DSP might 
not look it up there. Also, if we add FIR filter design at some point 
then that's usually done with the Fourier Transform.


How would you organise the different sub-packages in SigProc? Let say we 
have IIR, Kalman and FIR. At least IIR and Kalman consist of approx 10 
java files so ideally they should live in subdirectories at least so we 
could create sub-packages then?


Best,
/Bernd

On 23/11/16 13:34, Gilles wrote:

Hi Bernd, Eric (and others).


I was about to request a JIRA project for the "filter" component.[1]

The name "FILTER" is not taken (as a JIRA project) but it would
be better if we are sure that the name will stick (rather than have
to later change the JIRA id or keep one that would not be close to
the component's name.

How about "Sig(nal) Proc(essing)"?

Alternatively, would there be any sense to develop this codebase as
a module within the "Commons Complex" project.[2]
IOW, is it foreseen that "Filter" will depend on any code other than
what is going to end up in the "Complex" project?[3]


Regards,
Gilles

[1] Currently, an empty directory in the "sandbox" SVN repository.
[2] Currently, an empty git repository.
[3] AFAICT: Classes from
  o.a.c.math4.complex
  o.a.c.math4.analysis.solvers
  o.a.c.math4.transform
packages.


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



--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

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

Re: [VOTE] Accept Commons RDF as a new component

2016-11-23 Thread Bernd Eckenfels

+0 Undecided as there where no activity on commons-dev it feels to me
like an other home would be better

Am Wed, 23 Nov
2016 13:47:03 + schrieb Stian Soiland-Reyes :

> [Note: this is the Commons PMC vote on dev@commons - there's a
> concurrent IPMC VOTE thread on general@incubator]
> 
> Since Commons RDF entered incubation, it has evolved the understanding
> of its purpose, developed and released code base that is now
> stabilizing, moving towards a 1.0.0 release.
> 
> Although the Commons RDF developer community is small it has continued
> to grow interest, and Apache Commons feels like a natural home for the
> component; as intended when this podling was started. We appreciate
> all the help we have received from Commons while incubating, in
> particular Gary and Benedikt!
> 
> 
> The Commons RDF podling has voted to graduate from the Incubator
> to join Apache Commons as a new component:
> 
> https://lists.apache.org/thread.html/886ed903b3649203c794f7b7409f311b2391ebef1d9157177ba943b6@%3Cdev.commonsrdf.apache.org%3E
> 
> 
> This email carries over 3 Commons PMC binding votes from
> dev@commonsrdf:
> 
> 
> +1 Stian Soiland-Reyes (Commons PMC binding)
> +1 Benedikt Ritter (Commons PMC binding)
> +1 Gary Gregory (Commons PMC binding)
> 
> 
> Proposed component name: rdf
> 
> Proposed package name: org.apache.commons.rdf
> 
> Source code of RDF component:
> https://git-wip-us.apache.org/repos/asf?p=incubator-commonsrdf.git
> https://github.com/apache/incubator-commonsrdf
> 
> Incubator releases:
> http://archive.apache.org/dist/incubator/commonsrdf/
> 
> Website:
> http://commonsrdf.incubator.apache.org/
> 
> Project Maturity report (more links from there):
> https://github.com/apache/incubator-commonsrdf/blob/master/MATURITY.md
> 
> 
> This email propose a VOTE to accept Commons RDF as a new component of
> Apache Commons.
> 
> 
> Formally the Apache Incubator PMC will also need to agree the
> graduation, a concurrent vote thread is on
> 
> https://lists.apache.org/list.html?gene...@incubator.apache.org
> 
> 
> 
> 
> Please VOTE on graduating Commons RDF as new component:
> 
> [ ] +1 Yes, accept Commons RDF as new component
> [ ]  0 Undecided
> [ ] -1 No, because...
> 
> 
> This vote will be open for at least 72 hours, let's say 2016-11-26
> 17:00 UTC.
> 


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

Re: [complex] commons-complex module

2016-11-18 Thread Bernd Porr


Hi Eric,

how do we move this forward? I cannot commit to the CVS so shall I send 
you patches and you work them in or what is the workflow?


Best
/Bernd

On 26/10/16 13:48, Eric Barnhill wrote:

On Wed, Oct 26, 2016 at 2:25 PM, Gilles <gil...@harfang.homelinux.org>
wrote:




It sounds like you can create your new component on top of math4, correct?



Would you rather reply to the technical arguments put forward in the
preceding paragraph?

I've already answered your question many times (see the archive).

You do not need anything else? Aside from a better component name IMO.

"filter" is way to generic for me.



Is that the crux of the matter?
"Math" wasn't too generic perhaps?

Gilles



Hi Gilles, I read this email differently than you. My understanding is that
Gary is open to a filter subproject but would just like a different name
(to which Bernd replied).

But, I don't really know what he meant by the expression "built on top of
math 4". I did not interpret it as putting all these new modules in math4 .

Eric



--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

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

Re: commons-filter sandbox is operational

2016-11-05 Thread Bernd Porr


Hi Eric,

the error came from not having a site subtree. I've added one. That 
needs to change so that it fits into the numbering scheme of the 
library. I guess it will be a sub-topic in the filter.xml?


Either way "mvn site" works now to get it going.

/Bernd

On 02/11/16 09:09, Eric Barnhill wrote:

Hi Bernd,

looks like I need org/sonatype/aether/graph/DependencyFilter .

Any ideas where to find that?

Complete stack trace  below Bernd's reply.

Eric


On Tue, Nov 1, 2016 at 5:50 PM, Bernd Porr <m...@berndporr.me.uk> wrote:


Thanks, Eric for setting up a sandbox project. What is required for "mvn
site"?

/Bernd


On 01/11/16 16:17, Eric Barnhill wrote:


I have set up a sandbox project for commons-filter in the commons sandbox
subversion repository.

I used models in the sandbox for LICENSE.txt, NOTICE.txt and the pom.xml,
and set up a folder tree for src . mvn install runs successfully, mvn site
does not.

The pom model I used (cli2) had jira-related tags. I do not appear to have
the authority to create a JIRA project. Should I create a JIRA for this
project? If so, am I missing this option because I have not yet linked my
Apache JIRA with my apache.org ID? And if so, can anyone tell me a way to
link them?

Thanks,
Eric



--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

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






[WARNING] Error injecting:
org.apache.maven.reporting.exec.DefaultMavenReportExecutor
java.lang.NoClassDefFoundError: org/sonatype/aether/graph/DependencyFilter
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
at java.lang.Class.getDeclaredConstructors(Class.java:2020)
at
com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
at
com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
at
com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:658)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:882)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:805)
at
com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:282)
at
com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:214)
at
com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:1006)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1038)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1001)
at
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at
org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
at
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at
com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at
org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at
org.codehaus.plexus.Def

Re: commons-filter sandbox is operational

2016-11-04 Thread Bernd Porr


Hi Eric,

there hasn't been any documentation except of javadoc on it. I've added 
a page in the APT format. msv site requires documentation. Not sure 
what's required here.


Best,
/Bernd

On 02/11/16 09:09, Eric Barnhill wrote:

Hi Bernd,

looks like I need org/sonatype/aether/graph/DependencyFilter .

Any ideas where to find that?

Complete stack trace  below Bernd's reply.

Eric


On Tue, Nov 1, 2016 at 5:50 PM, Bernd Porr <m...@berndporr.me.uk> wrote:


Thanks, Eric for setting up a sandbox project. What is required for "mvn
site"?

/Bernd


On 01/11/16 16:17, Eric Barnhill wrote:


I have set up a sandbox project for commons-filter in the commons sandbox
subversion repository.

I used models in the sandbox for LICENSE.txt, NOTICE.txt and the pom.xml,
and set up a folder tree for src . mvn install runs successfully, mvn site
does not.

The pom model I used (cli2) had jira-related tags. I do not appear to have
the authority to create a JIRA project. Should I create a JIRA for this
project? If so, am I missing this option because I have not yet linked my
Apache JIRA with my apache.org ID? And if so, can anyone tell me a way to
link them?

Thanks,
Eric



--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

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






[WARNING] Error injecting:
org.apache.maven.reporting.exec.DefaultMavenReportExecutor
java.lang.NoClassDefFoundError: org/sonatype/aether/graph/DependencyFilter
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
at java.lang.Class.getDeclaredConstructors(Class.java:2020)
at
com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
at
com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
at
com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:658)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:882)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:805)
at
com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:282)
at
com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:214)
at
com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:1006)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1038)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1001)
at
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at
org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
at
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at
com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at
org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
at
org.codehaus.plexus.DefaultPlexus

Re: commons-filter sandbox is operational

2016-11-01 Thread Bernd Porr

Thanks, Eric for setting up a sandbox project. What is required for "mvn 
site"?


/Bernd

On 01/11/16 16:17, Eric Barnhill wrote:

I have set up a sandbox project for commons-filter in the commons sandbox
subversion repository.

I used models in the sandbox for LICENSE.txt, NOTICE.txt and the pom.xml,
and set up a folder tree for src . mvn install runs successfully, mvn site
does not.

The pom model I used (cli2) had jira-related tags. I do not appear to have
the authority to create a JIRA project. Should I create a JIRA for this
project? If so, am I missing this option because I have not yet linked my
Apache JIRA with my apache.org ID? And if so, can anyone tell me a way to
link them?

Thanks,
Eric



--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

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

Re: [complex] commons-complex module

2016-10-25 Thread Bernd Porr


Hi all,

I agree that 'filter' is slightly problematic but I'd say because it's 
been used in different contexts and often misleading. However, I cannot 
think of a better word. That also depends where we place 2D image 
processing. They are also called filters. For IIR , Kalman(and possibly 
FIR) filters these are causal digital filters as they essentially behave 
as an analogue circuit in a digital form. For the casual (!) user of 
filters they'd probably just look for a filter...


/Bernd

On 25-Oct-16 23:00, Gary Gregory wrote:

On Tue, Oct 25, 2016 at 12:07 PM, Eric Barnhill <ericbarnh...@gmail.com>
wrote:


On Tue, Oct 25, 2016 at 7:32 PM, Gary Gregory <garydgreg...@gmail.com>
wrote:


I am against this constant spinning out.

Gary



The proposed commons-filter is not a spin out. There was one filter in math
and it didn't belong there. Now we have at least couple of people around
who know signal processing and would like to make a commons-filter package.
Virtually none of which is coming from commons-math except dependencies.
Does such a package suit commons? I think so. Filtering is needed from
image processing to statistics. Others can vote no if they disagree.

Complex was in math too. Did it belong there? In C++ or Python, complex is
just another data type, like String. Its placement in math was not
straightforward. A self contained component to handle complex data types
seems more sensible to me than having it in Math. In any case Gilles is
making me a branch to populate, so that I can propose this component later,
IIUC.


It sounds like you can create your new component on top of math4, correct?
You do not need anything else? Aside from a better component name IMO.
"filter" is way to generic for me.

Gary



Eric






--
http://www.eigenproductions.co.uk
http://www.linux-usb-daq.co.uk
http://www.berndporr.me.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069


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

Re: [math] IIR filter library (Butterworth,Bessel,...)

2016-10-25 Thread Bernd Porr

Thanks.

That's quite a lot of stuff in there and to be honest I'm not sure how
to use the library by looking at the documentation (which just contains
the PLL papers) and/or code.

Again here most code works on 'array = filter (array)' and not 'sample =
filter(sample)' (see for example CascadeFilter.java). If you filter a
whole array then you can just use the convolution operation or just use
the Fourier Transform to manipulate the frequencies and transform it
back. That's what my students had to do for their 1st assignment and now
we move on to causal (realtime) processing with FIR/IIR filters.

Costas loops: For these to work we just need a lowpass filter (a causal
one for real applications). The rest is just multiplication/addition and
a digital oscillator (I use the Cordis algorithm for it). Actually, I
prefer the 2nd gen Costas Loop:
https://www.youtube.com/playlist?list=PLvUvEbh7a8u-_YCPNEIrjdnD1jxPW7dVk

Stripping it down to what I think common math should provide is: it's a
causal filter which is easy to set up (2 commands max). As I said before
I prefer IIR esp with JAVA's slow processing but if you have a super
efficient (causal / sample by sample) FIR implementation which can also
design its own low/high/band/stopband filter via different methods then
I think we should also add this. For example filters based on sinc
functions and windowed with a choice of standard windows would be nice.

/Bernd

On 25/10/16 12:33, Arne Ploese wrote:
> Am Montag, den 24.10.2016, 10:26 +0100 schrieb Bernd Porr:
>> Opps. Link doesn't work.
> Sorry, here we are https://sourceforge.net/projects/dsp4j/.
>
> there are subprojects fms(https://de.wikipedia.org/wiki/Funkmeldesystem
> ) and zvei(https://de.wikipedia.org/wiki/5-Ton-Folge)
> I grap the audiosignal off a 4m receiver @22kHz. The (frequency shift
> modulated) FMS data is decoded with a costas loop.
>
> Arne
>
>
>
>> Do you mean the OCTAVE/MATLAB "filter" command? If you limit that to
>> FIR
>> coefficients then that's equivalent literally to a convolution
>> operation
>> which we already have. (that FIR filtering is the convolution
>> function I
>> have to de-bunk every year in my DSP class because in teaching
>> nothing
>> is filtered in realtime so an FIR filter is sold literally as a
>> convolution operation, however the FIR filter does a convolution as
>> any
>> other filter but it performs it with the help of a delay line which
>> is
>> implemented usually as a ring buffer).
>>
>> Perhaps before we talk about different things.
>>
>> Can we all agree on the definition of an FIR filter:
>> https://en.wikipedia.org/wiki/Finite_impulse_response
>> it takes one sample in and spits one out by using a delay line.
>> Usually
>> implemented as a ring buffer. In C that can be done very elegantly
>> with
>> pointer gymnastics:
>> https://github.com/berndporr/fir1
>> Arne, do you have an efficient way of doing that in JAVA? That would
>> be
>> nice.
>>
>> Best,
>> /Bernd
>>
>> On 24/10/16 09:28, Arne Ploese wrote:
>>> Am Samstag, den 22.10.2016, 23:25 +0100 schrieb Bernd Porr:
>>>
>>> (...)
>>>
>>>> I'm not too crazy about proper FIR filters in JAVA because even
>>>> in
>>>> C++ 
>>>> they are just too slow and one would need to write them as JNI
>>>> calls
>>>> to 
>>>> C to make them run fast enough (for example a 50Hz notch for ECG
>>>> at
>>>> 1kHz 
>>>> requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure
>>>> how 
>>>> excited people here are about C/JNI calls. However the FIR
>>>> filter 
>>>> _design_ = creating an impulse response is useful for a-causal
>>>> offline 
>>>> computation using the convolution operation (but the 1D
>>>> convolution
>>>> is 
>>>> already implemented isn't it?).
>>> If the Just In Time compiler of the runtime kicks in, it will go
>>> fast...
>>> You can avoid wrapper code (get|set) and access the fields directly
>>> -
>>> ist will improve speed even more. Here is an example of a java
>>> filtering (converted form the signalprocessing package of octave) I
>>> did
>>> a couple of years ago:
>>>  https://sourceforge.net/projects/dsp4
>>>
>>> (...)
>>>
>>> Arne
>>>
>>> -
>>> 
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.ap

Re: [math] IIR filter library (Butterworth,Bessel,...)




On 24/10/16 14:26, Gilles wrote:

Hi.


[...]


The next step, then (I think) is that as a committer, I can submit a
proposal to get this idea established in the Incubator as a podling
for a
commons sub-project.


I suggest to use the sandbox, within "Commons".

Stupid queston: where do I find that?

In terms of directory structure. Just now the "filter subdir" contains a 
couple of classes all belonging to the Kalman filter.


Then I'll be adding a couple of classes belonging the IIR filters.

At some point somebody will be adding classes for FIR filters.

Perhaps one could create subdirs:

filter - Kalman
   - IIR
   - FIR
   - ...

What do you think?




Thanks!


The one technical question I have is whether it is okay to use Math
3.x as
a dependency for now, presumably substituting spin-out former math
components in later, to ensure that all of our dependencies are actively
maintained. I am going to assume this is okay for reasons of momentum.

I think Math 3.x should be fine. I had it at 3.2 and now changed it to
3.6.1 and it works fine. All filters generate the right response.


If you need to depend on "Commons Math", please depend on the
development version (a.k.a. CM version 4), as it is from there
that code must extracted to create candidate components.
That makes sense. I use heavily the Complex numbers of Commons Math and 
the Laguerre root finder. No other dependencies.




Whatever you need to depend on for the "filter" package is a
strong candidate to examine thoroughly and revamp, if necessary,
for inclusion in a component of its own (or "filter" itself).

No sure what you mean by this. Can give an example?

So, that do I need to do at this point?

Best,
/Bernd



Best regards,
Gilles



[...]



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



--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

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

Re: [math] IIR filter library (Butterworth,Bessel,...)

P.S.: Just tested it with 3.0.0. There the Laguerre Root function is not
yet implemented. For 3.0.0 we needed to exclude the Bessel filter. That
works from 3.1.0.


On 24/10/16 10:25, Eric Barnhill wrote:
> Hi Bernd, sounds like we agree on basically everything there is to do.
>
>
>> I've spent the weekend adding maven support to the IIRJ library. So now
>> a simple "mvn install" does the job. Also done the testing properly with
>> "mvn test" which generates all the different kinds of impulse responses
>> and puts them in different subdirs for evaluation.
>> https://github.com/berndporr/iirj
>
> I can confirm that this builds on Ubuntu Mate 16.04 .
>
> The next step, then (I think) is that as a committer, I can submit a
> proposal to get this idea established in the Incubator as a podling for a
> commons sub-project.
>
> The one technical question I have is whether it is okay to use Math 3.x as
> a dependency for now, presumably substituting spin-out former math
> components in later, to ensure that all of our dependencies are actively
> maintained. I am going to assume this is okay for reasons of momentum.
>
> So now I must go find a potential project champion..back soon. :)
>
> Best,
> Eric
>

-- 
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
University of Glasgow
School of Engineering
Rankine Building, Oakfield Avenue,
Glasgow, G12 8LT


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

Re: [math] IIR filter library (Butterworth,Bessel,...)

Hi Eric,

On 24/10/16 10:25, Eric Barnhill wrote:
> Hi Bernd, sounds like we agree on basically everything there is to do.
>
>
>> I've spent the weekend adding maven support to the IIRJ library. So now
>> a simple "mvn install" does the job. Also done the testing properly with
>> "mvn test" which generates all the different kinds of impulse responses
>> and puts them in different subdirs for evaluation.
>> https://github.com/berndporr/iirj
>
> I can confirm that this builds on Ubuntu Mate 16.04 .
Thanks for testing. I'm working with xenial actually.
>
> The next step, then (I think) is that as a committer, I can submit a
> proposal to get this idea established in the Incubator as a podling for a
> commons sub-project.
Thanks!
>
> The one technical question I have is whether it is okay to use Math 3.x as
> a dependency for now, presumably substituting spin-out former math
> components in later, to ensure that all of our dependencies are actively
> maintained. I am going to assume this is okay for reasons of momentum.
I think Math 3.x should be fine. I had it at 3.2 and now changed it to
3.6.1 and it works fine. All filters generate the right response.
>
> So now I must go find a potential project champion..back soon. :)
Excellent. :)
/Bernd
>
> Best,
> Eric
>

-- 
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
University of Glasgow
School of Engineering
Rankine Building, Oakfield Avenue,
Glasgow, G12 8LT


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

Re: [math] IIR filter library (Butterworth,Bessel,...)

Opps. Link doesn't work.

Do you mean the OCTAVE/MATLAB "filter" command? If you limit that to FIR
coefficients then that's equivalent literally to a convolution operation
which we already have. (that FIR filtering is the convolution function I
have to de-bunk every year in my DSP class because in teaching nothing
is filtered in realtime so an FIR filter is sold literally as a
convolution operation, however the FIR filter does a convolution as any
other filter but it performs it with the help of a delay line which is
implemented usually as a ring buffer).

Perhaps before we talk about different things.

Can we all agree on the definition of an FIR filter:
https://en.wikipedia.org/wiki/Finite_impulse_response
it takes one sample in and spits one out by using a delay line. Usually
implemented as a ring buffer. In C that can be done very elegantly with
pointer gymnastics:
https://github.com/berndporr/fir1
Arne, do you have an efficient way of doing that in JAVA? That would be
nice.

Best,
/Bernd

On 24/10/16 09:28, Arne Ploese wrote:
> Am Samstag, den 22.10.2016, 23:25 +0100 schrieb Bernd Porr:
>
> (...)
>
>> I'm not too crazy about proper FIR filters in JAVA because even in
>> C++ 
>> they are just too slow and one would need to write them as JNI calls
>> to 
>> C to make them run fast enough (for example a 50Hz notch for ECG at
>> 1kHz 
>> requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how 
>> excited people here are about C/JNI calls. However the FIR filter 
>> _design_ = creating an impulse response is useful for a-causal
>> offline 
>> computation using the convolution operation (but the 1D convolution
>> is 
>> already implemented isn't it?).
> If the Just In Time compiler of the runtime kicks in, it will go
> fast...
> You can avoid wrapper code (get|set) and access the fields directly -
> ist will improve speed even more. Here is an example of a java
> filtering (converted form the signalprocessing package of octave) I did
> a couple of years ago:
>  https://sourceforge.net/projects/dsp4
>
> (...)
>
> Arne
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-- 
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
University of Glasgow
School of Engineering
Rankine Building, Oakfield Avenue,
Glasgow, G12 8LT

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

Re: [math] IIR filter library (Butterworth,Bessel,...)

2016-10-23 Thread Bernd Porr



On 23/10/16 19:28, Eric Barnhill wrote:
>>
>>> Interesting! I think also looking at what is already existing in
>> the commons library your contribution is clearly on the image processing
>> side. Is that right? It's badly needed. I also would love to have it.
>> Crucial point here is that this is in signal processing terminology
>> a-causal so you essentially have all the data before you start processing
>> it (= Fourier Transform, convolution).
>>
> Yes, I work with 3+D complex valued images so I am always extending code to
> handle these cases. This is how I started contributing here.
>
>
>> Looking at what is missing in the apache commons just now is:
>> - IIR filters + design (my IIRJ)
>> - 2D (image) filtering/convolution (your JVCL)
>> - FIR filters (causal with delay line) + design (linear phase filters)
>>
> I agree this would be a great set of tools.
>
> Regarding image processing, a source that needs to be considered, to avoid
> being redundant, is ImgLib2. ImgLib2 a great library (inherently ND and
> generically typed) but I find the learning curve on ImgLib to be pretty
> steep and the approach quite specialized. So the question for a possible
> commons contribution is, is there room for a more "everyday" filtering
> library fitting the commons mission, which benefits from being more readily
> intuitive than ImgLib2? I think probably so. Certainly nothing out of line
> with the more base components of commons-math.
I'd say 2D/3D convolutions with any kernel size and taking care of
boundary conditions are something which is pretty generic and should be
as part of a math library. It can be used for image processing but also
for other tasks.
>
> As an example in my case, I am interested in extending my image processing
> filters to ND but I am not sure this makes sense for commons -- probably
What do you mean with ND?
> methods overloaded for 2D and 3D would suffice, and if I want to get
> fancier I should develop within ImgLib.
>
> I'm not too crazy about proper FIR filters in JAVA because even in C++ they
>> are just too slow and one would need to write them as JNI calls to C to
>> make them run fast enough (for example a 50Hz notch for ECG at 1kHz
>> requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how excited
>> people here are about C/JNI calls. However the FIR filter _design_ =
>> creating an impulse response is useful for a-causal offline computation
>> using the convolution operation (but the 1D convolution is already
>> implemented isn't it?).
>
> The commons math guidelines, which I assume for now extend to spin-off
> projects, are here http://commons.apache.org/proper/commons-math/ . One
> stipulation is no external dependencies beyond commons-math and the Java
> SDK. This is one reason I have not tried to integrate my convolution
> library which has JOCL and JTransforms dependencies.
Well, that's the reason why I'm offering my IIR library because it has
no other dependency than commons math. Actually the laguerre solver from
commons math makes the Bessel filter design short and sweet.
I guess somebody more senior here needs to comment on the dependencies.
>
> Though I should emphasize that I am a noob myself, I would suspect that
> high-performance aspects of signal processing requiring native calls
> probably don't suit commons terribly well and should perhaps be some sort
> of extension library. That's certainly something I would be happy to work
> on too. For example, maybe a base commons-filter library could be worked
> out, which could be readily extensible with JNI, GPU, etc.
I'd also say that in the 1st instance any low level calls should be
avoided and then JNI can be added as an option. That's the reason why I
like the IIR filter because it makes sense in JAVA and then if somebody
wants to use it for audio then I could add the JNI implementation if
there is demand.

I've spent the weekend adding maven support to the IIRJ library. So now
a simple "mvn install" does the job. Also done the testing properly with
"mvn test" which generates all the different kinds of impulse responses
and puts them in different subdirs for evaluation.
https://github.com/berndporr/iirj

Best,
/Bernd
>
> Eric
>

-- 
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
University of Glasgow
School of Engineering
Rankine Building, Oakfield Avenue,
Glasgow, G12 8LT


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

Re: [math] IIR filter library (Butterworth,Bessel,...)

2016-10-22 Thread Bernd Porr




On 22/10/16 19:54, Eric Barnhill wrote:




It will be a good fit if the code comes with developer(s) willing
to provide support too.

Yes of course I would provide support and of course see it through to
the release. That comes without saying.



Myself as well. One possibility would be to use this new code to spin off
the "filter" component and take it further at the same time. Right now I
believe the filter component only consists of a Kalman filter(!). IIR
filters could be used to turn the filter library into something much more
substantial.
Indeed. The Kalman filter class is fine but of course that's only a tiny 
part of signal processing.




I have a whole convolution library I wrote at:
https://github.com/ericbarnhill/JVCL  which includes GPU based finite
differences convolutions which are quite speedy (and as always,
complex-friendly). With Bernd contributing IIR methods these could be some
useful complementary FIR methods. But I think it may violate commons
protocols due to the extra dependency on JOCL.

Interesting! I think also looking at what is already existing in
the commons library your contribution is clearly on the image processing 
side. Is that right? It's badly needed. I also would love to have it. 
Crucial point here is that this is in signal processing terminology 
a-causal so you essentially have all the data before you start 
processing it (= Fourier Transform, convolution).
Then on the other hand if you have realtime streaming data from an ADC 
it's just scalars as they show up sample by sample at your input (ADC, 
etc): scalar = myFilter(scalar) which is what both FIR and IIR filters 
do - well at least how I've been teaching it to my students for 10 
years. ;). Then in terms of the filter design the IIR filters are 
derived from analogue filters whereas FIR realtime filters use the 
(mirrored) impulse response for its coefficients.

Looking at what is missing in the apache commons just now is:
- IIR filters + design (my IIRJ)
- 2D (image) filtering/convolution (your JVCL)
- FIR filters (causal with delay line) + design (linear phase filters)
I'm not too crazy about proper FIR filters in JAVA because even in C++ 
they are just too slow and one would need to write them as JNI calls to 
C to make them run fast enough (for example a 50Hz notch for ECG at 1kHz 
requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how 
excited people here are about C/JNI calls. However the FIR filter 
_design_ = creating an impulse response is useful for a-causal offline 
computation using the convolution operation (but the 1D convolution is 
already implemented isn't it?).




Also worth mentioning,  I have a good deal of wavelet code in Java and have
given some thought to designing a nice match between OO design and wavelet
analyses. This could become part of the filter package.
Wavelets come very handy for many applications. It would be good to be 
able to generate them in 1D and 2D. Plus also the scaling function. If 
eventually we had an effective FIR filter as a JNI call then these could 
be also used for example for realtime ECG heartbeat detection.


/Bernd




-  Eric



--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

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

Re: [math] IIR filter library (Butterworth,Bessel,...)

2016-10-22 Thread Bernd Porr

Hi both,

great to get such a positive response.


On 22/10/16 15:59, Gilles wrote:
> Hello.
>
> On Sat, 22 Oct 2016 12:51:03 +0200, Eric Barnhill wrote:
>> Dear Bernd,
>>
>> Thank you for this interesting contribution. I use these sorts of
>> filters
>> frequently so I will be interested to give it a look. I just build my
>> Butterworths in k space so I will be interested to see how yours work
>> differently.
Sorry I meant I used the laguerre solver for Bessel. I'm sure we both
did a similar approach for Butterworth.
Either way the library is written in a way that it's very modular and
you can do it the traditional way by providing analogue lowpass
poles/zeroe and then the library does the rest for you or you can
directly put complex conjugate pairs into a biquad cascade. Hoping that
people also come up with other filter patches such as Linkwitz, for example.
>>
>> The math package is in flux as others can tell you,
>
> This is a mild description... ;-)
>
> To better appreciate the situation, I suggest to browse through the
> "dev" ML archive (starting around last May).
OK. I'll have a read!
>
> The bottom line is that we critically need contributors to help
> maintain, and continue developing, selected packages from the
> Commons Math codebase.
I'd be up for it (obviously with reason). I've been teaching DSP for
many years and now developing a couple of Android apps for which I need
filters so that will be ongoing and happy to maintain packages and add
new ones.
>
>> however I think such
>> functionality fits the commons mission quite well and I am certainly
>> happy
>> to help support the code to give it a home here some how.
>
> It will be a good fit if the code comes with developer(s) willing
> to provide support too.
Yes of course I would provide support and of course see it through to
the release. That comes without saying.
>
>>
>> Best,
>> Eric
>> On 22 Oct 2016 01:35, "Bernd Porr" <m...@berndporr.me.uk> wrote:
>>
>>> Dear all,
>>>
>>> I've created an IIR filter library:
>>> https://github.com/berndporr/iirj
>>>
>>> It's a re-coded version of my / Vinnie's DSP library originally written
>>> in C++. I've spent quite some time to make it work with the apache
>>> Complex type and I've also used the polynomial solver for the
>>> Butterworth filters.
>>>
>>> It implements Butterworth, Elliptic, Bessel and Chebyshev Type I. The
>>> library is very modular and adding new filter types is easy as adding
>>> different filter topologies.
>>>
>>> Is there interest in fully integrating this into math commons?
>
> In "Commons Math" per se, no (cf. above) but as its own component,
> yes.
>
>>> I'm aware that I don't have any maven script just now and the
>>> documentation is probably not complete for apache but before I
>>> embark on
>>> it I'd rather ask if there is interest.
>
> If Eric is willing to help you, it's a good start; but you
> should also be willing to stay around here long enough to
> work with us towards an official release of that code.
> And if, in addition, you can offer advice, and help with
> other tasks, that will be really great.
Sure. Def happy to stay on till the release and the ongoing maintenance.
That's what I had in mind anyway. It's rather that I need you especially
in terms of the build scripts which I have been avoiding for too long
and need to catch up with them.
>
> Welcome and best regards,
> Gilles
Thanks!
Best regards
/Bernd
>
>>>
>>> Best,
>>> /Bernd Porr
>>> -- 
>>> www:http://www.berndporr.me.uk/
>>> http://www.linux-usb-daq.co.uk/
>>> http://www.imdb.com/name/nm3293421/
>>> Mobile: +44 (0)7840 340069
>>> Work:   +44 (0)141 330 5237
>>> University of Glasgow
>>> School of Engineering
>>> Rankine Building, Oakfield Avenue,
>>> Glasgow, G12 8LT
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-- 
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
University of Glasgow
School of Engineering
Rankine Building, Oakfield Avenue,
Glasgow, G12 8LT


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

[math] IIR filter library (Butterworth,Bessel,...)

2016-10-21 Thread Bernd Porr

Dear all,

I've created an IIR filter library:
https://github.com/berndporr/iirj

It's a re-coded version of my / Vinnie's DSP library originally written
in C++. I've spent quite some time to make it work with the apache
Complex type and I've also used the polynomial solver for the
Butterworth filters.

It implements Butterworth, Elliptic, Bessel and Chebyshev Type I. The
library is very modular and adding new filter types is easy as adding
different filter topologies.

Is there interest in fully integrating this into math commons?

I'm aware that I don't have any maven script just now and the
documentation is probably not complete for apache but before I embark on
it I'd rather ask if there is interest.

Best,
/Bernd Porr
-- 
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
University of Glasgow
School of Engineering
Rankine Building, Oakfield Avenue,
Glasgow, G12 8LT

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

Re: Help with task: Random number generators

2016-10-15 Thread Bernd Eckenfels

Hello,

you can get the current version from the Git repos as linked here:

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

You can review the classes or generate the JavaDoc to provide the list
here with your findings. I think it would best to provide a list before
we then create tasks/issues out of it (in case any are required)

As the release is immanent, it would be good to do that quickly (but of
course if you come around to do it later it is still valuable for
forthcoming releases).

Thank you for your help and contributions. 

Gruss
Bernd

 Am Sat, 15 Oct 2016 09:53:15 -0600
schrieb Angelsdeamons69 <angelsdeamon...@gmail.com>:

> I would like to help out with the task listed at
> https://helpwanted.apache.org/task.html?532e1a73
> 
> 
> 
> Sent from my Sony Xperia™ smartphone

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

Re: [Fileupload] CVE security page and site distribution

2016-06-30 Thread Bernd Eckenfels

Hello,

I pushed a security report for commons fileupload (incl. the 3 CVEs I
could find).

http://svn.apache.org/viewvc?rev=1750857=rev

Please somebody have a look and publish the site (I dont trust my
tooling with this). After the push it needs to be linked from the
commons-security page as well.

Gruss
Bernd


 Am Thu, 30 Jun 2016 10:46:12 +
schrieb Benedikt Ritter <brit...@apache.org>:

> We still need to create a security site. Commons Compress can be used
> as an example for this. I don't have time to do it right now.
> 
> Benedikt
> 
> Benedikt Ritter <brit...@apache.org> schrieb am Do., 30. Juni 2016 um
> 12:41 Uhr:
> 
> > Hello Bernd,
> >
> > I've fixed this in revision 14202 in the dist area. Does this work
> > for you?
> >
> > Benedikt
> >
> > Bernd <e...@zusammenkunft.net> schrieb am Di., 28. Juni 2016 um
> > 13:38 Uhr:
> >
> >> Hello,
> >>
> >> I was trying to come up with a Victims-cve-db entry for
> >> CVE-2016-3092 and I
> >> noticed a few odd things (
> >> https://github.com/victims/victims-cve-db/pull/47
> >> ):
> >>
> >> a) the original mail from Jochen did contain a link to a security
> >> page but Commons FileUpload does not have one:
> >>
> >>
> >> http://mail-archives.us.apache.org/mod_mbox/www-announce/201606.mbox/%3c45a20804-abff-4fed-a297-69ac95ab9...@apache.org%3E
> >>
> >> ->
> >> https://commons.apache.org/proper/commons-fileupload/security.html
> >>
> >> b) the change for the release notes is only in trunk, not published
> >> to the site or the archives. This makes it hard to link to a
> >> definitive source.
> >>
> >> Gruss
> >> Bernd
> >>
> >
> 

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

[Fileupload] CVE security page and site distribution

2016-06-28 Thread Bernd

Hello,

I was trying to come up with a Victims-cve-db entry for CVE-2016-3092 and I
noticed a few odd things (https://github.com/victims/victims-cve-db/pull/47
):

a) the original mail from Jochen did contain a link to a security page but
Commons FileUpload does not have one:

http://mail-archives.us.apache.org/mod_mbox/www-announce/201606.mbox/%3c45a20804-abff-4fed-a297-69ac95ab9...@apache.org%3E

-> https://commons.apache.org/proper/commons-fileupload/security.html

b) the change for the release notes is only in trunk, not published
to the site or the archives. This makes it hard to link to a
definitive source.

Gruss
Bernd

Re: [VOTE] Move Apache Commons Primitives to dormant

2016-06-13 Thread Bernd Eckenfels

+1 (binding)

> [X] +1, yes move Primitives to dormant

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

[VFS] CI in POM?

2016-06-08 Thread Bernd Eckenfels

Hello,

continuum-ci.apache.org seems to be gone, or at least it is not
responding right now. In the VFS POM we have a CI section (from the
parent) poiting to this CI. 

Should this be replaced by some other integration server, if yes, where
is the Job currently setup?

(And I havent found the info on the commons.apache.org site easily,
should we do something about that?)

I think there is somewhere a Jenkins running (for us?)

Gruss
Bernd

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

[Result][VFS] Switch to Git

2016-06-03 Thread Bernd Eckenfels

Hello,

There was no objection to switching VFS project to Git as the primary
source control. Here are the people participated (I also vote +1):

Bernd Eckenfels
Gary Gregory
Dave Brosius
Woonsan Ko
Josh Elser
Ralph Goers
Jochen Wiedmann
Christopher


How to proceed? Open an Infra ticket?

Gruss
Bernd


 Am Wed, 25 May 2016 22:20:28 +0200
schrieb Bernd Eckenfels <e...@zusammenkunft.net>:

> Hello,
> 
> I would like to be able to use Git with the Apache Commons VFS repo.
> As we agreed upon I call out the intention to do this and ask you for
> your oppinion.
> 
> Now that we have the 2.1 release out of the way the switch wont affect
> any planned steps. 
> 
> Anybody opposed to this move? I will probably need a few days to come
> back to this, so this poll with lazy consensus is open for at least 5
> days.
> 
> Gruss
> Bernd


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

Re: [VOTE] Release Apache Commons FileUpload 1.3.2 based on RC1

2016-05-25 Thread Bernd Eckenfels

+1 (binding)

i do have some remarks/discussion points:

RELEASE-NOTES.txt contains the site link as http instead of https, I
had the impression we wanted to switch the defaults?

Is the site planned to be "rolled back" to 1.3.2 or will it stay
1.4-SNAPSHOT?

Gruss
Bernd


Am Mon, 23 May 2016 15:23:46 +
schrieb Benedikt Ritter <brit...@apache.org>:

> It has been a long time since the last release of Apache Commons
> FileUpload, so I'd like to release Apache Commons FileUpload 1.3.2
> based on RC1.
> 
> Apache Commons FileUpload 1.3.2 RC1 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/fileupload (rev
> 13750)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1173/commons-fileupload/commons-fileupload/1.3.2/
> 
> These are the Maven artifacts and their hashes
> 
> commons-fileupload-1.3.2-javadoc.jar
> (SHA1: 12bbb300a1b61e038defb1dee85e8302d6f1bbaa)
> commons-fileupload-1.3.2-sources.jar
> (SHA1: 23996750d5a80dc74dad55633c2a0f3db91462cb)
> commons-fileupload-1.3.2-test-sources.jar
> (SHA1: 2df285ad143910759a3763fcec0cd58e8525d881)
> commons-fileupload-1.3.2-tests.jar
> (SHA1: 310e3713308073a0392be30c129b55e872fe48f6)
> commons-fileupload-1.3.2,jar
> (SHA1: 5d7491ed6ebd02b6a8d2305f8e6b7fe5dbd95f72)
> commons-fileupload-1.3.2.pom
> (SHA1: a4c3e5d590c2e83bba42768c5b5fbef43219b5c4)
> 
> Details of the change since 1.3.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/fileupload/RELEASE-NOTES.txt
> 
> http://home.apache.org/~britter/commons/fileupload-1.3.2-rc1/changes-report.html
> 
> I have tested this with:
>   JDK 1.6 and Maven 3.2.5
>   JDK 1.7 and Maven 3.3.9
>   JDK 1.8 and Maven 3.3.9
> Note that commons-fileupload should be JDK 1.5 compatible, but I
> don't have a JDK 1.5 installation on my MacBook. If someone could
> check the build with JDK 1.5, that would be great!
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/fileupload/tags/FILEUPLOAD_1_3_2_RC1
>  (rev 1745203)
> 
> Site:
>   http://home.apache.org/~britter/commons/fileupload-1.3.2-rc1/
> (note some *relative* links are broken and the 1.3.2 directories are
> not yet created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 1.3):
> 
> http://home.apache.org/~britter/commons/fileupload-1.3.2-rc1/clirr-report.html
> (note that the API additions have been introduced in 1.3.1 not in
> 1.3.2)
> 
> RAT Report:
> 
> http://home.apache.org/~britter/commons/fileupload-1.3.2-rc1/rat-report.html
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now,
> i.e. sometime after 17:30 CEST 26-May 2016
> 
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] +0 OK, but really should fix...
> [ ] -1 I oppose this release because...
> 
> Thanks!
> Benedikt


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

[Poll][VFS] Switch to Git

2016-05-25 Thread Bernd Eckenfels

Hello,

I would like to be able to use Git with the Apache Commons VFS repo. As
we agreed upon I call out the intention to do this and ask you for your
oppinion.

Now that we have the 2.1 release out of the way the switch wont affect
any planned steps. 

Anybody opposed to this move? I will probably need a few days to come
back to this, so this poll with lazy consensus is open for at least 5
days.

Gruss
Bernd

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

Re: Interest in some code to read DMG files?

2016-05-21 Thread Bernd Eckenfels

Hello Christofer,

there is no low level filesystem image or arhive file code in VFS, so I
think it would be better to add it to commons-compress. We could then
add a VFS provider on top of it for more FS abstractions.

When implementing it, it might be good to adhere to the NIO filesystem
abstraction API, as this is a possible candidate for VFS to envolve to.
(I think commons-compress does not have a abstraction API for this).

Are you planning to support writing/creating images as well?

Gruss
Bernd



 Am Sat, 21 May
2016 08:10:12 + schrieb Christofer Dutz <christofer.d...@c-ware.de>:

> Hi,
> 
> 
> for the Apache Flex project I have been working hard on some code to
> unpack DMG images as all libs I could find were GPL I implemented
> everything by reading the specs. I am not quite finished. The DMG
> part is finished, now I'm working on parsing the mac filesystem
> BTree ... will still take a while, but I think locating this code in
> the Apache Flex project doesn't seem to be the right place. After
> reading the Apache Commons VFS release earlier today I think this
> would be the best place to put it.
> 
> 
> Is there any interest in this?
> 
> 
> Chris
> 


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

Re: [VOTE] Apache Commons VFS 2.1 rc2

2016-05-17 Thread Bernd

Hello,

Thanks Josh!

This is a binding +1

(however I have some minor optional points which could be fixed in another
RC or before releasing the repo):


2016-05-12 5:29 GMT+02:00 Josh Elser :

> All,
>
> Please consider the following for Apache Commons VFS2 version 2.1 (rc2).
>
> Maven repository:
> https://repository.apache.org/content/repositories/orgapachecommons-1166


- The files *.asc.md5 and *.asc.sha1 are normally deleted according to
commons procedure (not sure why). I think you can do that before the repo
is submitted.

+ all *.sha1, *.md5 and *.asc verified in
orgapachecommons-1166/org/apache/commons/commons-vfs2-distribution/2.1/


>
> Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
>

> MD5  commons-vfs-distribution-2.1-bin.tar.gz
> 8cc35a3169e1faee727c5af94c7dd904
> SHA1 commons-vfs-distribution-2.1-bin.tar.gz
> 72b7557c4e8b1789b8aa0a9c1e0cb2c9daecec30
> MD5  commons-vfs-distribution-2.1-src.tar.gz
> a182ac642874e85fbc7d1086f7663482
> SHA1 commons-vfs-distribution-2.1-src.tar.gz
> e42ac2053deb314277213e43f6f1d6b43eff3de9
>
> MD5  commons-vfs-distribution-2.1-bin.zip b512a45c63d824eef826f174fd7a9245
> SHA1 commons-vfs-distribution-2.1-bin.zip
> 886cb5a430da58b3a68e2abf297b6f735d3ffaf0
> MD5  commons-vfs-distribution-2.1-src.zip 29645a0ad091c15b2cf76b619c33069f
> SHA1 commons-vfs-distribution-2.1-src.zip
> 5824cf4d802865b5e93ff62c90affa58df6c4384
>
> + verified


> Signed with 4677D66C from
> https://dist.apache.org/repos/dist/release/commons/KEYS


+ verified
- PGP signature is SHA1 but I guess it is (still) fine
- Cant verify the key on a trusted path, but thats not a Commons
requirement.


>
>
> SVN tag is available at
>
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.1-rc2/
> r1743451
>
> Staged Maven website:
> http://home.apache.org/~elserj/commons/commons-vfs-2.1/
>
> All reports are available in the provided staged Maven site (see "Project
> Reports" at the root-level as well as under each sub-module).
> JIRA-generated
> release notes are available in the dist.a.o "Artifacts" repository. Unit
> tests pass and the RC was built util JDK6.
>
> (For Sebb) A direct Clirr link
>
> http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>
> Changes since rc1:
>
> * Fixed more compatibility concerns against 2.0 (thanks, Greg)
> * Improved release notes (thanks, Sebb)
>
> This vote will be open for 72-hours, 2016/05/14 0400 UTC.
>
>   [X ] +1 Release these artifacts as version 2.1
>   [ ] 0  OK, but...
>   [ ] -1 I oppose these artifacts as version 2.1 because..
>
> - Josh
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Apache Commons VFS 2.1 rc1

2016-05-04 Thread Bernd Eckenfels

Thanks Stian!

Do you plan to report the noexec issue? If not let me know and I will
file one.

I thought we already had one but I cant find it.

I will do some windows tests and then vote.

Gruss
Bernd

 Am Wed, 4 May 2016 13:28:54 +0100
schrieb Stian Soiland-Reyes <st...@apache.org>:

> +1 (non-binding)
> 
> +1 signatures
> +1 hashes
> +1 LICENSE, NOTICE
> 0 README.md says 2.0
> 0 Extra README.txt (confusing)
> +1 RELEASE-NOTES.txt
> +1 mvn apache-rat:check
> +1 maven repository signatures/hashes
> +1 maven repository *distribution* matches dist/
> 0 mvn clean install OK (but 1 test fails on tmpfs)
> +1 target/*jar matches binaries
> +1 source matches svn tag (minus sandbox/ :-) )
> +1 Dependency licenses OK
> -1 Unclassified use of encryption libraries Bouncy Castle/Apache
> Mina/SSHD/Hadoop/jsch/Jetty (plus some AES128 in DefaultCryptor) - but
> Commons VFS is not classified on
> http://www.apache.org/licenses/exports/
> 
> I won't take a stand on the US Export classification requirement as
> https://issues.apache.org/jira/browse/LEGAL-250 has not been resolved
> yet.
> 
> 
> I get this test error (because my /tmp is mounted with noexec):
> 
> Tests run: 90, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.259
> sec <<< FAILURE! - in
> org.apache.commons.vfs2.provider.local.test.LocalProviderTestCase
> testExecutable(org.apache.commons.vfs2.test.PermissionsTests)  Time
> elapsed: 0.011 sec  <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.commons.vfs2.test.PermissionsTests.testExecutable(PermissionsTests.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:218)
> at junit.framework.TestCase.runBare(TestCase.java:141) at
> junit.framework.TestResult$1.protect(TestResult.java:122) at
> junit.framework.TestResult.runProtected(TestResult.java:142) at
> junit.framework.TestResult.run(TestResult.java:125) at
> junit.framework.TestCase.run(TestCase.java:129) at
> junit.framework.TestSuite.runTest(TestSuite.java:252) at
> junit.framework.TestSuite.run(TestSuite.java:247) at
> junit.extensions.TestDecorator.basicRun(TestDecorator.java:23) at
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:149)
> at junit.framework.TestResult.runProtected(TestResult.java:142) at
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
> 
> Building from /var/tmp worked.
> 
> I won't fail because of this - I'm probably special still using tmpfs
> :)   (And adding conditional testing would mean using the same APIs or
> requivalent Java 7 NIO files APIs to see if executable bit is
> supported).
> 
> 
> Checked with:
> 
> stain@biggie:/tmp/vfs/source/commons-vfs-2.1$ mvn -v
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T16:41:47+00:00)
> Maven home: /home/stain/software/maven
> Java version: 1.8.0_72-internal, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-67-generic", arch: "amd64",
> family: "unix"
> 
> On 4 May 2016 at 04:43, Josh Elser <els...@apache.org> wrote:
> > All,
> >
> > Please consider the following for Apache Commons VFS2 version 2.1
> > (rc1).
> >
> > Maven repository:
> > https://repository.apache.org/content/repositories/orgapachecommons-1163
> > Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/
> > r13511
> >
> > MD5  commons-vfs-distribution-2.1-bin.tar.gz
> > 1192914d1ba6f8ca3a2a688feeff602c
> > SHA1 commons-vfs-distribution-2.1-bin.tar.gz
> > 285097f1db6cbc9d76ae5bb3adf66a315344a864
> > MD5  commons-vfs-distribution-2.1-src.tar.gz
> > 0646187562302a7dcfbddb93204fc9eb
> > SHA1 commons-vfs-distribution-2.1-src.tar.gz
> > 24bab87fd4049b9389acd1b6e272f405630aeb25
> > MD5  commons-vfs-distribution-2.1-bin.zip
> > 3785874aa0cda64d68acbb8fb7db8bea SHA1
> > commons-vfs-distribution-2.1-bin.zip
> > 942a23fb202b89b1a8432beeb0a66469959e661d MD5
> > commons-vfs-distribution-2.1-src.zip
> > c8ef43d308bed1b3ffcb363c15285176 SHA1
> > commons-vfs-distributi

Re: [VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

2016-05-04 Thread Bernd Eckenfels

Am Tue, 03 May 2016 21:47:43 -0400
schrieb Josh Elser <els...@apache.org>:

> See the original point of me starting this thread: it was stated that 
> the sandbox (might) depend on code which is not licensed in such a 
> manner that is allowed for ASF projects.

Which is why it is not built or shipped by default and called sandbox.
(this was not my idea and before my time but I dont see a reason to
change this for this release)

Gruss
Bernd

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

Re: [VFS] Disallowed dependencies in build? (was Re: [VOTE] Apache Commons-VFS2 2.1 rc0)

2016-05-03 Thread Bernd Eckenfels

Hello,

the sandbox works perfectly fine for me. Why do you think it is not
ready for release (beside we do not want to?)

I dont think we should burden such structural and long standing changes
onto a voluntary release manager given the 2.0 had the same structure.

Gruss
Bernd


Am Tue, 3 May 2016 15:55:00 +0100
schrieb sebb <seb...@gmail.com>:

> On 3 May 2016 at 01:43, Josh Elser <els...@apache.org> wrote:
> > Binaries are not an official release anyways.
> 
> But that does not mean they can include software that is incompatible
> with the AL, because end users expect (and we tell them) that the
> software comes under AL 2.0.
> 
> Depending on incompatible software is a different thing.
> For example, most of Commons depends on Java.
> That is expected to be provided by the user, not us, so they take the
> decision on the license.
> 
> > Even so, that seems like a *very* scary thing to even have this
> > code checked into the repository if it depends on
> > incompatibly-licensed software. Am I misunderstanding this?
> 
> It depends on the exact license.
> Some incompatible dependencies are OK as binaries
> 
> http://www.apache.org/legal/resolved.html#optional
> and
> http://www.apache.org/legal/resolved.html#prohibited
> 
> But given that the sandbox does not appear to be ready to release as
> it stands, I would be inclined to move it into a branch.
> 
> > e...@zusammenkunft.net wrote:
> >>
> >> Hello,
> >>
> >> Agree, the sandbox profile should be in the site build enabled,
> >> but we cannot distribute the binaries as official release since it
> >> has dependencies which are not Apache approved (and potentially
> >> unfinished suff).
> >>
> >> Gruss
> >> Bernd
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [VFS] 2.1 Release Plan

2016-04-26 Thread Bernd Eckenfels

Hello,

see inline.

Am Tue, 26 Apr 2016 18:05:01 -0400
schrieb Josh Elser <els...@apache.org>:

> Thanks for the great details, Bernd. Some questions/comments:
> 
> I hadn't even stumbled across VFS-570 due to its lack of
> fixVersion=2.1. Are there more that need to be correctly tagged which
> could potentially block the release of 2.1?

I did not waste much time in setting/unsetting the fixversion. I
modified some severities and closed some. But the blocker bugs (the
ones I considered) are all closed.

You could do a mass change on the existing bugs, but I am sure that
causes some discussion and especially people setting the fields back to
their preferences (at least that happend a few times in the past).

> I'm not sure I follow you about the concern of using 
> maven-release-plugin with a multi-module maven project. This works
> just fine (@see other Apache maven projects I'm involved in). If
> there are demons laying in wait, I can knock them out as I find them.

Well yes, I use the release plugin aswell (in fact I did a company
internal release of VFS 2.1 with it already). I think it was also used
for the 2.0 release. But there are some things (especially the tagging
of the SVN and the tag in the POM) which is currently not very
preferable in apache commons I think. I would not use it for a release
(especially as rolling back and revovering would be painful). But I
agreee with you, it should work.

> Are there instructions on running clirr? I'm not familiar with the
> tool (and I don't see any configuration in the top-level pom.xml).

You can run the "mvn -Psandbox clean site" build (possibly follwoed by
a site tst deploy). The clirr report is part of it. I had a site build
from the snapshot on people.apache.org, but I havent checked if/how the
new server would look like. So currently you need to run it locally.

> Do you have the karma to make a 2.2 version on JIRA? That'd be a nice 
> help to start moving stuff out of 2.1 (as well as make sure things 
> sitting in Patch Available don't get forgotten).

Yes, seems like I can do it. I created 2.2.

> I would lean towards 
> the side of only putting bug-fixes into a 2.1.1 and preferring
> towards any new features/changes into a 2.2 (to closer follow the
> definition of semver). We presently have 3 major and 1 minor version
> unresolved for fixVersion=2.1 -- these where the issues I previously
> referred to that I felt OK bumping out as well.

> Gary -- "BC breakage" == base-class breakage? As in: the common 
> base-class for all of the VFS Providers has changed (and would
> require changes from anyone downstream that has built their own)?

It refers to (binary) backward compatibility. For a client a new method
in an interface is a compatible change which fits into a minor update.
However when you have to implement a interface as a VFS provider you
wont be binary and source compatible. For most classes it is not a
problem since the mehtod is provided by the AbstractBaseClass for an
interface (but not all Interfaces have that and it was never mandatory
for an provider to use them).

> I can try to start pounding on an initial RC in the evenings this
> week. I'll be sure to reach out as I need some more help/karma ;)

Anything more needed from me?

Gruss
Bernd

> 
> Gary Gregory wrote:
> > Yes, there is a BC breakage for providers, is that grounds for a
> > package and Maven coordinate rename to vfs3?
> >
> > Gary
> >
> > On Tue, Apr 26, 2016 at 12:31 PM, Bernd
> > Eckenfels<e...@zusammenkunft.net> wrote:
> >
> >> Hello Josh,
> >>
> >> I think a VFS 2.1 release would be cool and it is good that you
> >> volunteer, so I dont object. My latest todo list is here:
> >>
> >> https://wiki.apache.org/commons/VfsReleaseState
> >>
> >> As you can see, I did plan to do the release and did quite some
> >> work to get VFS into a releaseable state. But I am quite happy
> >> that you want to step in as I havent had the time to do the
> >> procedure yet.
> >>
> >> And this is not the actual release procedure (which should be
> >> doable as long as you do not try to use the release-plugin and be
> >> careful about the multi-module+sandbox nature of VFS (as opposed
> >> to other commons projects)). Also be carefull about branch and tag
> >> namings (the SVN is a bit messy in this regard).
> >>
> >> My main concern I am afraid I would not have enough capacity is
> >> because of the Clirr report and a lot of partially incompatible
> >> changes. Most of them only affect providers if they do not
> >> properly use abstract base classes, but still the list of Clirr
> >> violations is long and devel

Re: [VFS] 2.1 Release Plan

2016-04-26 Thread Bernd Eckenfels

Hello Josh,

I think a VFS 2.1 release would be cool and it is good that you
volunteer, so I dont object. My latest todo list is here:

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

As you can see, I did plan to do the release and did quite some work to
get VFS into a releaseable state. But I am quite happy that you want to
step in as I havent had the time to do the procedure yet.

And this is not the actual release procedure (which should be doable as
long as you do not try to use the release-plugin and be careful about
the multi-module+sandbox nature of VFS (as opposed to other commons
projects)). Also be carefull about branch and tag namings (the SVN is a
bit messy in this regard).

My main concern I am afraid I would not have enough capacity is because
of the Clirr report and a lot of partially incompatible changes. Most
of them only affect providers if they do not properly use abstract base
classes, but still the list of Clirr violations is long and developers
here have not yet voiced if they would accept a RC with this situation
(or not).

Anyway, I do agree that the current critical and blocker bugs are
important but should not stop the 2.1 release (especially if a 2.1.1
release aferwards is much faster to do.) It would be cool to have
VFS-570 (write suport for VFS, but even that could be delivered with
2.1.1 - it might annoy the HDFS folks a bit)

So I can help you in case you need me to sponsor some changes (I hope I
have enough karma now).

We could even make a joined RC1, I am just not sure it wont open a big
chunk of additional work.

Gruss
Bernd

 Am Tue, 26 Apr 2016 09:40:01 -0400
schrieb Josh Elser <els...@apache.org>:

> Thanks Matt and Gary.
> 
> I do recall seeing the asf-wide note that my commit-bit also applies
> to commons-*. Thanks for bringing that up. Specifically though, I am
> only interested in cutting a release -- if we can get a new release
> cut that we can use downstream, that increases the likelihood that I
> will have more things to contribute back :)
> 
> I'll pull up the thread in the archives and get back to ya'll with
> any questions I have after that.
> 
> - Josh
> 
> Matt Sicker wrote:
> > It's from the thread called "Whatever happened to commons-io 2.5?"
> > A few people stepped up to give the necessary permissions and
> > committed his GPG key.
> >
> > On 25 April 2016 at 17:10, Gary Gregory<garydgreg...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> Agreed, VFS 2.1 has been too long in the making. We can release
> >> ASAP without fixing more bugs IMO. RERO and all.
> >>
> >> As an Apache committer, your are also an Apache Commons committer,
> >> so feel free to create JIRAs, fix bugs and so on.
> >>
> >> There might be some karma issues with a non-PMC member performing a
> >> release, and I think we just went through this (sorry, I'm in
> >> settling in a new house, not much time to dig in the ML archives).
> >>
> >> Does anyone recall?
> >>
> >> Gary
> >>
> >>
> >>
> >> On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<els...@apache.org>
> >> wrote:
> >>
> >>> Hi all,
> >>>
> >>> There are presently 171 resolved issues sitting in commons-vfs2
> >>> 2.1-SNAPSHOT, with 4 outstanding (none of which look like
> >>> blockers to
> >> me).
> >>> The lack of any release of commons-vfs2 in years has been a big
> >>> problem downstream. This past weekend, I was again annoyed by
> >>> bugs that have been fixed (but not release) which is spurring me
> >>> to take some action. There have been emails reaching back as far
> >>> as 2014 asking when the next
> >> release
> >>> might be, not to mention the fact that vfs-2.0 was released in
> >>> 2011 (!).
> >>>
> >>> History aside, I'm reaching out today to:
> >>>
> >>> 1) See if anyone on the PMC has the cycles to volunteer as RM.
> >>>1a) If not, how can you empower me (or others) to make the
> >>> release on your behalf.
> >>> 2) Understand, specifically, what (if any) roadblocks exist to
> >>> release this version.
> >>>
> >>> Thanks.
> >>>
> >>> - Josh
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >>
> >> --
> >> E-Mail:

Re: commons-vfs: github pull requests

2016-03-22 Thread Bernd Eckenfels

Am Tue, 22 Mar 2016 16:33:12 +
schrieb "Epstein, Ezra" <ezra.epst...@neustar.biz>:

> Is commons-vfs being maintained?  And is GitHub the up-to-date code
> repo?

Yes, github is a mirror of the apache git repo and the apache git repo
mirrors the SVN based master. They should be in sync. The project has
some activity, unfortunatelly release preparation is a bit complicated
so we dont have an ETA.

> I notice a number of open pull requests, one from yours truly.

> 
> https://github.com/apache/commons-vfs/pulls

Well, the PR is only one day old, so...

It would be good if you can submit seperate PRs for different issues.
And we also work with JIRA bugs. But it is no problem if you suggest
changes via PR, we can handle them as well (it just takes longer).

> Just checking in to see if something more is needed for contributing
> to this project.

The details are described here, this is pretty current, but I think you
are doing fine. We discussed your report just yesterday. I think we
should get the mock http service in lace so we dont have to fix those
external URLs (again).

https://github.com/apache/commons-vfs/blob/trunk/CONTRIBUTING.md

Gruss
Bernd

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

Re: commons-vfs:org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase fails

2016-03-22 Thread Bernd Eckenfels

Hello,

I think for this test we can do fine with a (java mock) http server started for 
the particular redirection test, other provider tests do that as well.

Added benefit would be, that we can actually assert some properties of the 
request on server side.

Gruss
Bernd
-- 
http://bernd.eckenfels.net
>From Win 10 Mobile

Von: Benedikt Ritter
Gesendet: Dienstag, 22. März 2016 08:34
An: Commons Developers List
Betreff: Re: 
commons-vfs:org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase 
fails

Hi,

Bernd Eckenfels <e...@zusammenkunft.net> schrieb am Di., 22. März 2016 um
01:03 Uhr:

> Hello,
>
> I think it is a new problem. It is a bit unfortunate that those tests
> rely on external web sites (and those seeem to no longer exist).
>
> If you want, you can file the report directly in the JIRA:
>
> https://issues.apache.org/jira/browse/VFS/
>
> It seems to be safe to ignore that failure.
>

Hm, I think we should really fix this :-)
Maybe it is possible to use the Test Containers project [1] to spin up the
needed infrastructure for running the test?

Benedikt

[1] http://testcontainers.viewdocs.io/testcontainers-java/


> Gruss
> Bernd
>
>  Am Mon,
> 21 Mar 2016 21:38:46 + schrieb "Epstein, Ezra"
> <ezra.epst...@neustar.biz>:
>
> > I’ve forked and cloned the repo from GitHub and the build fails with:
> >
> >
> > Tests run: 90, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > 5.223 sec <<< FAILURE! - in
> > org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase
> >
> >
> testHttp405(org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase)
> > Time elapsed: 0.372 sec  <<< ERROR!
> >
> > org.apache.commons.vfs2.FileSystemException: Could not determine the
> > size of
> > "http://www.w3schools.com/webservices/tempconvert.asmx?action=WSDL;
> > because it is not a file.
> >
> > at
> >
> org.apache.commons.vfs2.provider.DefaultFileContent.getSize(DefaultFileContent.java:135)
> >
> > at
> >
> org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase.testHttp405(HttpProviderTestCase.java:208)
> >
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >
> ...
> > at
> > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> >
> > …
> >
> > Tests in error:
> >
> >
>  HttpProviderTestCase>AbstractProviderTestCase.runTest:218->testHttp405:208
> >   HttpProviderTestCase>» FileSystem
> >
> >
> > Is this a known issue?
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: commons-vfs: org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase fails

2016-03-21 Thread Bernd Eckenfels

Hello,

I think it is a new problem. It is a bit unfortunate that those tests
rely on external web sites (and those seeem to no longer exist).

If you want, you can file the report directly in the JIRA:

https://issues.apache.org/jira/browse/VFS/

It seems to be safe to ignore that failure.

Gruss
Bernd

 Am Mon,
21 Mar 2016 21:38:46 + schrieb "Epstein, Ezra"
<ezra.epst...@neustar.biz>:

> I’ve forked and cloned the repo from GitHub and the build fails with:
> 
> 
> Tests run: 90, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 5.223 sec <<< FAILURE! - in
> org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase
> 
> testHttp405(org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase)
> Time elapsed: 0.372 sec  <<< ERROR!
> 
> org.apache.commons.vfs2.FileSystemException: Could not determine the
> size of
> "http://www.w3schools.com/webservices/tempconvert.asmx?action=WSDL;
> because it is not a file.
> 
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getSize(DefaultFileContent.java:135)
> 
> at
> org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase.testHttp405(HttpProviderTestCase.java:208)
> 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 
...
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> 
> …
> 
> Tests in error:
> 
>   HttpProviderTestCase>AbstractProviderTestCase.runTest:218->testHttp405:208
>   HttpProviderTestCase>» FileSystem
> 
> 
> Is this a known issue?
> 


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

Re: [VOTE] Accept Chimera as new Apache Commons Component

2016-03-21 Thread Bernd Eckenfels

+1 Accept Chimera as new Apache Commons Component


Gruss
Bernd

Von: Benedikt Ritter
Gesendet: Montag, 21. März 2016 09:45
An: Commons Developers List
Cc: Hadoop Common
Betreff: [VOTE] Accept Chimera as new Apache Commons Component

Hi all,

after long discussions I think we have gathered enough information to
decide whether we want to accept the Chimera project as a new Apache
Commons component.

Proposed name: Apache Commons Crypto
Proposal text:
https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
Initial Code Base:  https://github.com/intel-hadoop/chimera/
Initial Committers (Names in alphabetical order):
- Aaron T. Myers (a...@apache.org, Apache Hadoop PMC, one of the original
Crypto dev team in Apache Hadoop)
- Andrew Wang (w...@apache.org, Apache Hadoop PMC, one of the original
Crypto dev team in Apache Hadoop)
- Chris Nauroth (cnaur...@apache.org, Apache Hadoop PMC and active
reviewer)
- Colin P. McCabe (cmcc...@apache.org, Apache Hadoop PMC, one of the
original Crypto dev team in Apache Hadoop)
- Dapeng Sun (s...@apache.org, Apache Sentry Committer, Chimera contributor)
- Dian Fu (dia...@apache.org, Apache Sqoop Committer, Chimera contributor)
- Dong Chen (do...@apache.org, Apache Hive Committer,interested on Chimera)
- Ferdinand Xu (x...@apache.org, Apache Hive Committer, Chimera contributor)
- Haifeng Chen (haifengc...@apache.org, Chimera lead and code contributor)
- Marcelo Vanzin (Apache Spark Committer, Chimera contributor)
- Uma Maheswara Rao G (umamah...@apache.org, Apache Hadoop PMC, One of the
original Crypto dev/review team in Apache Hadoop)
- Yi Liu (y...@apache.org, Apache Hadoop PMC, One of the original Crypto
dev/review team in Apache Hadoop)

Please review the proposal and vote.
This vote will close no sooner than 72 hours from now, i.e. after 0900
GMT 24-Mar 2016

  [ ] +1 Accept Chimera as new Apache Commons Component
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this because...

Thank you!
Benedikt

AW: [VOTE] Form a separate TLP based on [math]

2016-01-16 Thread Bernd Eckenfels

+0
 
(I would prefer to not see the traffic on the list)

Von: Phil Steitz
Gesendet: Samstag, 16. Januar 2016 16:19
An: Commons Developers List
Betreff: [VOTE] Form a separate TLP based on [math]

The discussion has thus far been generally favorable.  I would like
therefore to put the proposal to split [math] out into a separate
TLP to a VOTE.  Assuming a favorable vote, we can discuss how to go
about doing it.  Votes, please.  All are welcome to vote.

[ ] +1 I am in favor of this action
[ ] +0 I am OK with this
[ ] -0 OK, but...
[ ] -1 I oppose this action because...

This VOTE will run a little longer than usual - closing at 20 Jan
13:00 UTC.

Thanks!

Phil


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

[collections][site] publish security-report? (was: svn commit: r1719350 - /commons/proper/collections/trunk/src/site/xdoc/security-reports.xml)

2015-12-11 Thread Bernd Eckenfels

Hello,

I added a second CVE to the de-serialisation security-report for
ACC, I dont have the infrastrcuture handy to push the site, can
somebody do that, please?

Gruss
Bernd

URL: http://svn.apache.org/viewvc?rev=1719350=rev
Log:
security-report: added CVE-2015-7501 (Red Hat) to de-serialisaton
references

Modified:
commons/proper/collections/trunk/src/site/xdoc/security-reports.xml

Modified:
commons/proper/collections/trunk/src/site/xdoc/security-reports.xml
URL:
http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/site/xdoc/security-reports.xml?rev=1719350=1719349=1719350=diff
==
--- commons/proper/collections/trunk/src/site/xdoc/security-reports.xml
(original) +++
commons/proper/collections/trunk/src/site/xdoc/security-reports.xml Fri
Dec 11 11:39:08 2015 @@ -91,6 +91,9 @@  Vulnerability Report
for Oracle Weblogic Server: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4852;>CVE-2015-4852
+Vulnerability Report for Red Hat JBoss products:
+http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7501;>CVE-2015-7501
+(https://access.redhat.com/security/cve/cve-2015-7501;>Red Hat
Portal) Apache Commons https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread;>statement
to widespread Java object de-serialisation vulnerability



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

Re: [vfs] New Properties for FtpFileSystemConfigBuilder

2015-12-07 Thread Bernd Eckenfels

Hello Roger,

sounds useful to me. Do you plan to parse a string range ("1-100") or
define a min and max property?

Gruss
Bernd

 Am Mon, 7 Dec 2015 13:26:35 -0800
schrieb Roger Membreno <roger.membr...@celigo.com>:

> Hello Apache Community, how are you doing?
> 
> We use Commons VFS in our FTP connection projects, and for a recent
> project we only able to connect to our FTP site when using Passive
> mode.  If we used Active mode we could login to the FTP site but all
> files in the directory did not exist and could not be accessed.
> 
> Since our server is behind a firewall with NAT translation we
> determined that the data connection could not be established even if
> we opened up some ports on the firewall.  We were able to connect to
> the FTP site using a stanadalone FTPClient by setting the following
> properties to match our NAT security settings:
> setReportActiveExternalIPAddress()
> client.setActivePortRange()
> 
> With these properties set the PORT command issued by our client to
> the FTP site will create a valid data connection.  What I'd like to
> do is submit a change via GitHub that does the following:
> 1. Add "reportActiveExternalIPAddress" and "activePortRange"
> properties to the class
> org.apache.commons.vfs2.provider.ftp.FtpFileSystemConfigBuilder 2.
> Ehance createConnection in
> org.apache.commons.vfs2.provider.ftp.FtpClientFactory to read these
> new FtpFileSystemConfigBuilder properties from the config instance
> and set them on the FTPClient.
> 
> Let me know if you have any questions.  If you think this is a good
> change I'll make a new issue in JIRA for this enhancement.  I also
> think that these changes could help resolve VFS-201 (
> https://issues.apache.org/jira/browse/VFS-201)
> 


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

Re: [COLLECTIONS] Bad press on twitter following serialization issue

2015-11-11 Thread Bernd Eckenfels

Hello,

BTW Oracle issued a "Strange" Security alert:

2015-4852 was released on November 10th, 2015.

This vulnerability, which involves the Apache Commons and Oracle WebLogic 
Server, has received a CVSS Base Score of 7.5.
...

Bernd

> Am 08.11.2015 um 10:41 schrieb Benedikt Ritter <brit...@apache.org>:
> 
> Hi,
> 
> there is a lot of bad talk going on at twitter [1,2,3] and I'm wondering
> whether we should respond to this via the Apache blog.
> 
> Thoughts?
> Benedikt
> 
> [1] https://twitter.com/JustineTunney/status/662937508980723712
> [2] https://twitter.com/kennwhite/status/662709833464872960
> [3] https://twitter.com/jodastephen/status/663253106751180800
> 
> 
> -- 
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

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

Re: [COLLECTIONS] Bad press on twitter following serialization issue

Am Mon, 9 Nov 2015 09:36:41 +0100
schrieb Benedikt Ritter <brit...@apache.org>:

> Hello Bernd,
> 
> very nice. I found two typos:
> 
> "It is possible to limit the impact when using a custom
> ObjecrtInputStream which overwrites" - should be ObjectInputStream

fixed

> "However it should be clear, this is not the only known (and
> especially not yet know) gadget" - should be "and especially not yet
> known"

reworded:

However to be clear: this is not the only known and especially not
unknow useable gadget. So replacing your installations with a hardened
version of Apache Commons Collections will not make your application
resist this vulnerability.

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

Re: [COLLECTIONS] Bad press on twitter following serialization issue

Thanks Timo!

Am Mon, 9 Nov 2015 10:18:18 +0100
schrieb Timo <mailant...@gmx.de>:

> Hello Bernd,
> 
> nice article and I would be happy to see this on the ASF blog to point
> people to it.
> 
> I also found some typos:
> 
> "Both research work shows that developers"
> should be
> "Both research works show that developers"

fixed.

> 
> "final type is checked lot of code"
> should be
> "final type is checked a lot of code"

fixed.

> "sample payloads which combines classes"
> should be
> "sample payloads which combine classes"

fixed.

So here is the version with the reviews from Timo and Ben added:

Apache Commons statement to widespread Java object de-serialisation
vulnerability

Authors: Bernd Eckenfels, Gary Grogory for Apache Commons

In their
[talk](http://frohoff.github.io/appseccali-marshalling-pickles/)
"Marshalling Pickles - how deserializing objects will ruin your day" at
AppSecCali2015 Gabriel Lawrence ([@gebl](https://twitter.com/gebl)) and
Chris Frohoff ([@frohoff](https://twitter.com/frohoff)) presented
various security problems when applications accept serialized objects
from untrusted source. A major finding describes a way to execute
arbitrary Java functions and even inject manipulated bytecode when
using Java Object Serialization (as used in some remote communication
and persistence protocols).

Build on Frohoff's tool
[ysoserial](https://github.com/frohoff/ysoserial), Stephen Breen
([@breenmachine](https://twitter.com/breenmachine)) of Foxglove
Security inspected various products like WebSphere, JBoss, Jenkins,
WebLogic, and OpenNMS and describes
(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/)
for each of them various attack scenarios.

Both research works shows that developers put too much trust in Java
Object Serialization. Some even de-serialize objects
pre-authentication. When deserializing an Object in Java you typically
cast it to an expected type, and therefore Java's strict type system
will ensure you only get valid object trees. Unfortunately, by the time
the type checking happens, platform code has already created and
executed significant logic. So, before the final type is checked a lot
of code is executed from the readObject() methods of various objects,
all of which is out of the developer's control. By combining the
readObject() methods of various classes which are available on the
classpath of the vulnerable application an attacker can execute
functions (including calling Runtime.exec() to execute local OS
commands).

The best protection against this, is to avoid using a complex
serialization protocol with untrusted peers. It is possible to limit
the impact when using a custom ObjectInputStream which overwrites
[resolveClass()](http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass%28java.io.ObjectStreamClass%29)
to implement a whitelist approach. This might however not always be
possible, when a framework or application server provides the endpoint.
This is rather bad news, as there is no easy fix and applications need
to revisit their client-server protocols and overall architecture.

In these rather unfortunate situations, people have looked at the
sample exploits. Frohoff provided "gadget chains" in sample payloads
which combine classes from Groovy runtime, Sprint framework or Apache
Commons Collection. It is quite certain that you can combine more
classes to exploit this weakness, but those are the chains readily
available to attackers today.

https://twitter.com/gebl/status/662786601425080320>

Even when the classes implementing a certain functionality cannot be
blamed for this vulnerability, and fixing the known cases will also not
make the usage of serialization in an untrusted context safe, there is
still demand to fix at least the known cases, even when this will only
start a Whack-a-Mole game. In fact, it is for this reason the original
team did not think it is necessary to alert the Apache Commons team,
hence work has begun relatively late. The Apache Commons team is using
the ticket
[COLLECTION-580](https://issues.apache.org/jira/browse/COLLECTIONS-580)
(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136=1713307=1713307_format=h)
to address the issue in the 3.2 and 4.0 branches of commons-collection
by disabling de-serialization of the class InvokerTransformer. A to-do
item being discussed is whether to provide programmatic enabling of the
feature on a per-transformer basis.

There is some precendence for this, the class
com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl which is
part of Oracle and OpenJDK JREs and which allows to inject and run
bytecode, does reject deser

Blog post "commons" vulnerability

Hello Sally,

currently there is a security vulnerability doing the rounds which uses
as an example Apache Commons Collection. It is not really a bug in
Commons Collection, but there is a lot of fuzz. So since we are doing
somethign in the Apache Commons team against the problem we wanted to
make a public statement.

Here is a blog post, which was discussed on the developer mailinglist.
What is needed to get it published via ASF blogs? (i.e. do you need a
PMC vote or similiar?)

The syntax for links is markdown, you might have to replace them (so
the links are hidden). Let me know if you have some suggestions for
improvement.

Greetings
Bernd (e...@apache.org)

---
Apache Commons statement to widespread Java object de-serialisation
vulnerability

Authors: Bernd Eckenfels, Gary Grogory for Apache Commons

In their
[talk](http://frohoff.github.io/appseccali-marshalling-pickles/)
"Marshalling Pickles - how deserializing objects will ruin your day" at
AppSecCali2015 Gabriel Lawrence ([@gebl](https://twitter.com/gebl)) and
Chris Frohoff ([@frohoff](https://twitter.com/frohoff)) presented
various security problems when applications accept serialized objects
from untrusted source. A major finding describes a way to execute
arbitrary Java functions and even inject manipulated bytecode when
using Java Object Serialization (as used in some remote communication
and persistence protocols).

Build on Frohoff's tool
[ysoserial](https://github.com/frohoff/ysoserial), Stephen Breen
([@breenmachine](https://twitter.com/breenmachine)) of Foxglove
Security inspected various products like WebSphere, JBoss, Jenkins,
WebLogic, and OpenNMS and describes
(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/)
for each of them various attack scenarios.

Both research works shows that developers put too much trust in Java
Object Serialization. Some even de-serialize objects
pre-authentication. When deserializing an Object in Java you typically
cast it to an expected type, and therefore Java's strict type system
will ensure you only get valid object trees. Unfortunately, by the time
the type checking happens, platform code has already created and
executed significant logic. So, before the final type is checked a lot
of code is executed from the readObject() methods of various objects,
all of which is out of the developer's control. By combining the
readObject() methods of various classes which are available on the
classpath of the vulnerable application an attacker can execute
functions (including calling Runtime.exec() to execute local OS
commands).

The best protection against this, is to avoid using a complex
serialization protocol with untrusted peers. It is possible to limit
the impact when using a custom ObjectInputStream which overwrites
[resolveClass()](http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass%28java.io.ObjectStreamClass%29)
to implement a whitelist approach. This might however not always be
possible, when a framework or application server provides the endpoint.
This is rather bad news, as there is no easy fix and applications need
to revisit their client-server protocols and overall architecture.

In these rather unfortunate situations, people have looked at the
sample exploits. Frohoff provided "gadget chains" in sample payloads
which combine classes from Groovy runtime, Sprint framework or Apache
Commons Collection. It is quite certain that you can combine more
classes to exploit this weakness, but those are the chains readily
available to attackers today.

https://twitter.com/gebl/status/662786601425080320>

Even when the classes implementing a certain functionality cannot be
blamed for this vulnerability, and fixing the known cases will also not
make the usage of serialization in an untrusted context safe, there is
still demand to fix at least the known cases, even when this will only
start a Whack-a-Mole game. In fact, it is for this reason the original
team did not think it is necessary to alert the Apache Commons team,
hence work has begun relatively late. The Apache Commons team is using
the ticket
[COLLECTION-580](https://issues.apache.org/jira/browse/COLLECTIONS-580)
(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136=1713307=1713307_format=h)
to address the issue in the 3.2 and 4.0 branches of commons-collection
by disabling de-serialization of the class InvokerTransformer. A to-do
item being discussed is whether to provide programmatic enabling of the
feature on a per-transformer basis.

Re: [COLLECTIONS] Bad press on twitter following serialization issue