Re: svn commit: r1487173 - /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java

[Stefan Bodewig]

On 2013-05-29,  wrote:

> Unnecessary @SuppressWarnings("unchecked") - these are not used for casts

javac was whining until I added them, strange.

Stefan

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

Re: svn commit: r1486348 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ZipFile.java test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java

[Stefan Bodewig]

On 2013-05-28, Gary Gregory wrote:

> On Tue, May 28, 2013 at 2:08 PM, sebb  wrote:

>> On 25 May 2013 18:47,   wrote:

>>>+ import java.util.Deque;

>> That requires Java 1.6; Compress currently targets 1.5

> Well, let's change the requirement to Java 6 for Compress 1.6.

Not necessary in this case IMHO.  The Deque is never exposed to the user
so I can change it to LinkedList (the Deque implementation actually
used) without feeling bad.

I'll take care of it.

Stefan

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

[SCXML]How to get event payload in Listener.onTransition

[zn]

I have a derivate class for SCXMLListener. How to get event payload in 
onTransition method?
I can get it from rootContext.get("_eventdata").
I don't want to hardcode it, is there any other method?

Re: svn commit: r1486348 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ZipFile.java test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java

[sebb]

Turns out that a List is sufficient; no need for a Deque.

Fixed in http://svn.apache.org/r1487167

On 28 May 2013 19:08, sebb  wrote:
> On 25 May 2013 18:47,   wrote:
>> Author: bodewig
>> Date: Sat May 25 17:47:00 2013
>> New Revision: 1486348
>>
>> URL: http://svn.apache.org/r1486348
>> Log:
>> provide access to all entries of a given name in ZipFile, COMPRESS-227
>
> -1, see below
>
>> Modified:
>> 
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>> 
>> commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java
>>
>> Modified: 
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java?rev=1486348&r1=1486347&r2=1486348&view=diff
>> ==
>> --- 
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>>  (original)
>> +++ 
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>>  Sat May 25 17:47:00 2013
>> @@ -25,9 +25,12 @@ import java.io.RandomAccessFile;
>>  import java.util.Arrays;
>>  import java.util.Collections;
>>  import java.util.Comparator;
>> +import java.util.Deque;
>
> That requires Java 1.6; Compress currently targets 1.5
>

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

Re: [Math] Accepting contributions (Was: svn commit: r1486982 - ...)

[Gilles]

On Tue, 28 May 2013 20:47:30 +0200, Thomas Neidhart wrote:

On 05/28/2013 08:20 PM, Gilles wrote:

On Tue, 28 May 2013 16:04:32 -, t...@apache.org wrote:

Author: tn
Date: Tue May 28 16:04:32 2013
New Revision: 1486982

URL: http://svn.apache.org/r1486982
Log:
[MATH-851] Added method MathArrays.convolve, thanks to Clemens 
Novak

for the patch.


-1

A significant part of this small patch (code and doc) contains 
formatting
mistakes and non-conventional notations, as was indicated in the 
comments.
If someone took the time to review something, please take it into 
account.


The unit test is also not correctly defined; we agreed that newer 
code

should test _one_ thing per test method.
Also, precondition checks should use the "expected" attribute of the
"@Test" annotation.


Most of the suggestions were already corrected by the OP with an 
updated
patch, the rest I changed to the usual style I use when committing 
(see

the commit log).


My reply was based on reading the diff.

[Are you really using capital letters as variable names?]


Efficiency-wise, I wonder about the condition nested inside the
double-loop:

  if ((j > -1) && (j < N) ) {
  yn = yn + x[j] * h[k];
  }


yes I agree, this could be further improved.

As was also suggested in the comments, a "real" application (and/or 
a
discussion on the "dev" ML, preferably initiated by the OP) would 
have

been welcome to assess the pertinence of including this code in the
proposed form.


It is also present in numpy (see

http://docs.scipy.org/doc/numpy/reference/generated/numpy.convolve.html)
so I guess there will be a practical use for it.


By this post, I ask whether it is sufficient reason for committing
sub-par code that is currently not used by anyone.
I suggested the OP 3 ways to start getting involved; the absence of
reaction was IMHO reason enough not to rush including this code.
[It has obviously nothing to do with judging that convolution is not
worth implementing.]

CM needs contributors, right; but it is quite unrelated to piling up
unused/untested code.
At one point, some years ago, there was a sort of acknowledgment that
submitting a contribution was accompanied with an informal commitment
to maintain it.
Lacking that either gives more work to current committers or lowers
the average quality of the library.


Regards,
Gilles


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

[VOTE] Release Commons Parent 30-RC1

[Gary Gregory]

Hello All,

This is a VOTE to release Commons Parent 30-RC1.

The main changes in this release are RAT configuration changes:
- updated excludes: added .pmd and download_*.cgi
- changed excludes so child POM excludes will be appended to the parent list
- duplicated settings in build section so they apply to standalone
invocations
Coverage tool:
Made JaCoCo an optional profile
Restored Cobertura as an optional profile

Changes in this version include:

Changes:
o   rat-maven-plugin   0.8 -> 0.9
o   maven-project-info-reports-plugin  2.6 -> 2.7

This VOTE by LAZY-CONSENSUS is open for at least 72 hours until May 31 2012
at 18:00 PM EST.

The files:

https://repository.apache.org/content/repositories/orgapachecommons-024/

The tag:

https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/30-RC1

The site: None.

Thank you,
Gary Gregory

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit: r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/ src/java/org/apache/commons/dbcp2/cpdsadapter/ src/

[Emmanuel Bourg]

Le 28/05/2013 21:47, Gary Gregory a écrit :

> Something seems out of bounds here. Strictly speaking I know we deliver
> sources and we provide a jar as a convenience.
> 
> The source we deliver comes with a clear definition through the POM on how
> to build it. We say, the source is Java version X and the target Java
> version Y, where usually X=Y.

Actually no, it doesn't say that. The source version is not an
environment specification, it's a language level specification
(5=generics, 6=@Override in interfaces, 7=Project Coin features, etc).
And the target version specifies the compatible VMs. There is no
assumption on the available libraries.


> The safe thing to do as a builder is to build with a Java version that
> matches the source version set in the POM.

Sure that would be ideal, but that's not the reality. In the real world
folks have to compile DBCP 1.x with Java 7 because they can't support
Java 6 any longer.


> The result of using a new Java version than that is undefined because who
> knows what future JDKs will require.

That's our responsibility as developers and maintainers to ensure our
components are still usable with newer versions of Java. At least for
the components with a significant user base, and DBCP is clearly one of
them.

Honestly, if we can't release a Java 7 compatible version of DBCP 1.x we
should stop pretending that the source code is our primary deliverable,
because this source code has been broken with the latest version of Java
for nearly 2 years now.


Emmanuel Bourg




signature.asc
Description: OpenPGP digital signature

Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit: r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/ src/java/org/apache/commons/dbcp2/cpdsadapter/ src/

[Gary Gregory]

On Tue, May 28, 2013 at 3:24 PM, Emmanuel Bourg  wrote:

> Le 28/05/2013 19:50, Phil Steitz a écrit :
>
> > Looks complicated and painful.  I would rather put energy into
> > getting dbcp 2.0 out the door and aim for the following:
> >
> > DBCP 1.3.x JDK 1.4-1.5
> > DBCP 1.4.x JDK 1.6
> > DBCP 2.xJDK 1.7
>
> Unfortunately that doesn't solve the issue for the Linux distros
> compiling everything from the source. They have to support softwares
> depending on DBCP 1.x, and as they move to Java 7 they will have to
> support DBCP 1.x with Java 7+ for some time.
>

Something seems out of bounds here. Strictly speaking I know we deliver
sources and we provide a jar as a convenience.

The source we deliver comes with a clear definition through the POM on how
to build it. We say, the source is Java version X and the target Java
version Y, where usually X=Y.

The safe thing to do as a builder is to build with a Java version that
matches the source version set in the POM.

The result of using a new Java version than that is undefined because who
knows what future JDKs will require.

I do not see a nice and clean solution aside from the one suggested by Phil.

Gary




>
>
> Emmanuel Bourg
>
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit: r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/ src/java/org/apache/commons/dbcp2/cpdsadapter/ src

[Emmanuel Bourg]

Le 28/05/2013 19:50, Phil Steitz a écrit :

> Looks complicated and painful.  I would rather put energy into
> getting dbcp 2.0 out the door and aim for the following:
> 
> DBCP 1.3.x JDK 1.4-1.5
> DBCP 1.4.x JDK 1.6
> DBCP 2.xJDK 1.7

Unfortunately that doesn't solve the issue for the Linux distros
compiling everything from the source. They have to support softwares
depending on DBCP 1.x, and as they move to Java 7 they will have to
support DBCP 1.x with Java 7+ for some time.


Emmanuel Bourg




signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1486348 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ZipFile.java test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java

[Oliver Kopp]

Hi,

Gary wrote:
> I'd rather see developers getting and staying involved than clamping new
> versions down with old EOL'd JREs.

According to http://www.oracle.com/technetwork/java/eol-135779.html,
Java 6 already had its EOL on Feb 2013.
Java 7 will have its EOL on March 2015 :).

Debian stable supports JRE 6 and 7 "on most archs"; Google App Engine
also supports Java 6 and 7.

Cheers,

Oliver

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

Re: [Math] Accepting contributions (Was: svn commit: r1486982 - ...)

[Thomas Neidhart]

On 05/28/2013 08:20 PM, Gilles wrote:
> On Tue, 28 May 2013 16:04:32 -, t...@apache.org wrote:
>> Author: tn
>> Date: Tue May 28 16:04:32 2013
>> New Revision: 1486982
>>
>> URL: http://svn.apache.org/r1486982
>> Log:
>> [MATH-851] Added method MathArrays.convolve, thanks to Clemens Novak
>> for the patch.
> 
> -1
> 
> A significant part of this small patch (code and doc) contains formatting
> mistakes and non-conventional notations, as was indicated in the comments.
> If someone took the time to review something, please take it into account.
> 
> The unit test is also not correctly defined; we agreed that newer code
> should test _one_ thing per test method.
> Also, precondition checks should use the "expected" attribute of the
> "@Test" annotation.

Most of the suggestions were already corrected by the OP with an updated
patch, the rest I changed to the usual style I use when committing (see
the commit log).

> Efficiency-wise, I wonder about the condition nested inside the
> double-loop:
> 
>   if ((j > -1) && (j < N) ) {
>   yn = yn + x[j] * h[k];
>   }

yes I agree, this could be further improved.

> As was also suggested in the comments, a "real" application (and/or a
> discussion on the "dev" ML, preferably initiated by the OP) would have
> been welcome to assess the pertinence of including this code in the
> proposed form.

It is also present in numpy (see
http://docs.scipy.org/doc/numpy/reference/generated/numpy.convolve.html)
so I guess there will be a practical use for it.

Thomas

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

Re: svn commit: r1486348 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ZipFile.java test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java

[sebb]

On 28 May 2013 19:28, Gary Gregory  wrote:
> On Tue, May 28, 2013 at 2:22 PM, sebb  wrote:
>
>> On 28 May 2013 19:15, Gary Gregory  wrote:
>> > On Tue, May 28, 2013 at 2:08 PM, sebb  wrote:
>> >
>> >> On 25 May 2013 18:47,   wrote:
>> >> > Author: bodewig
>> >> > Date: Sat May 25 17:47:00 2013
>> >> > New Revision: 1486348
>> >> >
>> >> > URL: http://svn.apache.org/r1486348
>> >> > Log:
>> >> > provide access to all entries of a given name in ZipFile, COMPRESS-227
>> >>
>> >> -1, see below
>> >>
>> >> > Modified:
>> >> >
>> >>
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>> >> >
>> >>
>> commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java
>> >> >
>> >> > Modified:
>> >>
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>> >> > URL:
>> >>
>> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java?rev=1486348&r1=1486347&r2=1486348&view=diff
>> >> >
>> >>
>> ==
>> >> > ---
>> >>
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>> >> (original)
>> >> > +++
>> >>
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>> >> Sat May 25 17:47:00 2013
>> >> > @@ -25,9 +25,12 @@ import java.io.RandomAccessFile;
>> >> >  import java.util.Arrays;
>> >> >  import java.util.Collections;
>> >> >  import java.util.Comparator;
>> >> > +import java.util.Deque;
>> >>
>> >> That requires Java 1.6; Compress currently targets 1.5
>> >>
>> >
>> > Well, let's change the requirement to Java 6 for Compress 1.6.
>>
>> That is not something to be done without considering the effect on
>> downstream users.
>>
>
> Sure, but it's the same argument as always: no one forces users to update
> from one version to another. It's a choice. For transitive dependencies,
> you still have to choose to update /something/.
>
> I'd rather see developers getting and staying involved than clamping new
> versions down with old EOL'd JREs.

And the counter-arguments are the same, otherwise we might as well
update to Java 8 as soon as it is GA.

> Gary
>
>>
>> > Gary
>> >
>> >
>> >>
>> >> >  import java.util.Enumeration;
>> >> >  import java.util.HashMap;
>> >> > -import java.util.LinkedHashMap;
>> >> > +import java.util.Iterator;
>> >> > +import java.util.LinkedList;
>> >> > +import java.util.List;
>> >> >  import java.util.Map;
>> >> >  import java.util.zip.Inflater;
>> >> >  import java.util.zip.InflaterInputStream;
>> >> > @@ -83,17 +86,17 @@ public class ZipFile {
>> >> >  private static final int POS_3 = 3;
>> >> >
>> >> >  /**
>> >> > - * Maps ZipArchiveEntrys to two longs, recording the offsets of
>> >> > - * the local file headers and the start of entry data.
>> >> > + * List of entries in the order they appear inside the central
>> >> > + * directory.
>> >> >   */
>> >> > -private final Map entries =
>> >> > -new LinkedHashMap(HASH_SIZE);
>> >> > +private final List entries =
>> >> > +new LinkedList();
>> >> >
>> >> >  /**
>> >> > - * Maps String to ZipArchiveEntrys, name -> actual entry.
>> >> > + * Maps String to list of ZipArchiveEntrys, name -> actual
>> entries.
>> >> >   */
>> >> > -private final Map nameMap =
>> >> > -new HashMap(HASH_SIZE);
>> >> > +private final Map> nameMap =
>> >> > +new HashMap>(HASH_SIZE);
>> >> >
>> >> >  private static final class OffsetEntry {
>> >> >  private long headerOffset = -1;
>> >> > @@ -273,7 +276,7 @@ public class ZipFile {
>> >> >   * @return all entries as {@link ZipArchiveEntry} instances
>> >> >   */
>> >> >  public Enumeration getEntries() {
>> >> > -return Collections.enumeration(entries.keySet());
>> >> > +return Collections.enumeration(entries);
>> >> >  }
>> >> >
>> >> >  /**
>> >> > @@ -287,8 +290,7 @@ public class ZipFile {
>> >> >   * @since 1.1
>> >> >   */
>> >> >  public Enumeration getEntriesInPhysicalOrder() {
>> >> > -ZipArchiveEntry[] allEntries =
>> >> > -entries.keySet().toArray(new ZipArchiveEntry[0]);
>> >> > +ZipArchiveEntry[] allEntries = entries.toArray(new
>> >> ZipArchiveEntry[0]);
>> >> >  Arrays.sort(allEntries, OFFSET_COMPARATOR);
>> >> >  return Collections.enumeration(Arrays.asList(allEntries));
>> >> >  }
>> >> > @@ -296,12 +298,51 @@ public class ZipFile {
>> >> >  /**
>> >> >   * Returns a named entry - or {@code null} if no entry by
>> >> >   * that name exists.
>> >> > + *
>> >> > + * If multiple entries with the same name exist the first
>> entry
>> >> > + * in the archive's central directory by that name is
>> >> > + * returned.
>> >> > +  

Re: svn commit: r1486348 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ZipFile.java test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java

[Gary Gregory]

On Tue, May 28, 2013 at 2:22 PM, sebb  wrote:

> On 28 May 2013 19:15, Gary Gregory  wrote:
> > On Tue, May 28, 2013 at 2:08 PM, sebb  wrote:
> >
> >> On 25 May 2013 18:47,   wrote:
> >> > Author: bodewig
> >> > Date: Sat May 25 17:47:00 2013
> >> > New Revision: 1486348
> >> >
> >> > URL: http://svn.apache.org/r1486348
> >> > Log:
> >> > provide access to all entries of a given name in ZipFile, COMPRESS-227
> >>
> >> -1, see below
> >>
> >> > Modified:
> >> >
> >>
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
> >> >
> >>
> commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java
> >> >
> >> > Modified:
> >>
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
> >> > URL:
> >>
> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java?rev=1486348&r1=1486347&r2=1486348&view=diff
> >> >
> >>
> ==
> >> > ---
> >>
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
> >> (original)
> >> > +++
> >>
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
> >> Sat May 25 17:47:00 2013
> >> > @@ -25,9 +25,12 @@ import java.io.RandomAccessFile;
> >> >  import java.util.Arrays;
> >> >  import java.util.Collections;
> >> >  import java.util.Comparator;
> >> > +import java.util.Deque;
> >>
> >> That requires Java 1.6; Compress currently targets 1.5
> >>
> >
> > Well, let's change the requirement to Java 6 for Compress 1.6.
>
> That is not something to be done without considering the effect on
> downstream users.
>

Sure, but it's the same argument as always: no one forces users to update
from one version to another. It's a choice. For transitive dependencies,
you still have to choose to update /something/.

I'd rather see developers getting and staying involved than clamping new
versions down with old EOL'd JREs.

Gary

>
> > Gary
> >
> >
> >>
> >> >  import java.util.Enumeration;
> >> >  import java.util.HashMap;
> >> > -import java.util.LinkedHashMap;
> >> > +import java.util.Iterator;
> >> > +import java.util.LinkedList;
> >> > +import java.util.List;
> >> >  import java.util.Map;
> >> >  import java.util.zip.Inflater;
> >> >  import java.util.zip.InflaterInputStream;
> >> > @@ -83,17 +86,17 @@ public class ZipFile {
> >> >  private static final int POS_3 = 3;
> >> >
> >> >  /**
> >> > - * Maps ZipArchiveEntrys to two longs, recording the offsets of
> >> > - * the local file headers and the start of entry data.
> >> > + * List of entries in the order they appear inside the central
> >> > + * directory.
> >> >   */
> >> > -private final Map entries =
> >> > -new LinkedHashMap(HASH_SIZE);
> >> > +private final List entries =
> >> > +new LinkedList();
> >> >
> >> >  /**
> >> > - * Maps String to ZipArchiveEntrys, name -> actual entry.
> >> > + * Maps String to list of ZipArchiveEntrys, name -> actual
> entries.
> >> >   */
> >> > -private final Map nameMap =
> >> > -new HashMap(HASH_SIZE);
> >> > +private final Map> nameMap =
> >> > +new HashMap>(HASH_SIZE);
> >> >
> >> >  private static final class OffsetEntry {
> >> >  private long headerOffset = -1;
> >> > @@ -273,7 +276,7 @@ public class ZipFile {
> >> >   * @return all entries as {@link ZipArchiveEntry} instances
> >> >   */
> >> >  public Enumeration getEntries() {
> >> > -return Collections.enumeration(entries.keySet());
> >> > +return Collections.enumeration(entries);
> >> >  }
> >> >
> >> >  /**
> >> > @@ -287,8 +290,7 @@ public class ZipFile {
> >> >   * @since 1.1
> >> >   */
> >> >  public Enumeration getEntriesInPhysicalOrder() {
> >> > -ZipArchiveEntry[] allEntries =
> >> > -entries.keySet().toArray(new ZipArchiveEntry[0]);
> >> > +ZipArchiveEntry[] allEntries = entries.toArray(new
> >> ZipArchiveEntry[0]);
> >> >  Arrays.sort(allEntries, OFFSET_COMPARATOR);
> >> >  return Collections.enumeration(Arrays.asList(allEntries));
> >> >  }
> >> > @@ -296,12 +298,51 @@ public class ZipFile {
> >> >  /**
> >> >   * Returns a named entry - or {@code null} if no entry by
> >> >   * that name exists.
> >> > + *
> >> > + * If multiple entries with the same name exist the first
> entry
> >> > + * in the archive's central directory by that name is
> >> > + * returned.
> >> > + *
> >> >   * @param name name of the entry.
> >> >   * @return the ZipArchiveEntry corresponding to the given name -
> or
> >> >   * {@code null} if not present.
> >> >   */
> >> >  public ZipArchiveEntry getEntry(String name) {
> >> > -return nameMap.get(nam

Re: svn commit: r1486348 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ZipFile.java test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java

[sebb]

On 28 May 2013 19:15, Gary Gregory  wrote:
> On Tue, May 28, 2013 at 2:08 PM, sebb  wrote:
>
>> On 25 May 2013 18:47,   wrote:
>> > Author: bodewig
>> > Date: Sat May 25 17:47:00 2013
>> > New Revision: 1486348
>> >
>> > URL: http://svn.apache.org/r1486348
>> > Log:
>> > provide access to all entries of a given name in ZipFile, COMPRESS-227
>>
>> -1, see below
>>
>> > Modified:
>> >
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>> >
>> commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java
>> >
>> > Modified:
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java?rev=1486348&r1=1486347&r2=1486348&view=diff
>> >
>> ==
>> > ---
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>> (original)
>> > +++
>> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>> Sat May 25 17:47:00 2013
>> > @@ -25,9 +25,12 @@ import java.io.RandomAccessFile;
>> >  import java.util.Arrays;
>> >  import java.util.Collections;
>> >  import java.util.Comparator;
>> > +import java.util.Deque;
>>
>> That requires Java 1.6; Compress currently targets 1.5
>>
>
> Well, let's change the requirement to Java 6 for Compress 1.6.

That is not something to be done without considering the effect on
downstream users.

> Gary
>
>
>>
>> >  import java.util.Enumeration;
>> >  import java.util.HashMap;
>> > -import java.util.LinkedHashMap;
>> > +import java.util.Iterator;
>> > +import java.util.LinkedList;
>> > +import java.util.List;
>> >  import java.util.Map;
>> >  import java.util.zip.Inflater;
>> >  import java.util.zip.InflaterInputStream;
>> > @@ -83,17 +86,17 @@ public class ZipFile {
>> >  private static final int POS_3 = 3;
>> >
>> >  /**
>> > - * Maps ZipArchiveEntrys to two longs, recording the offsets of
>> > - * the local file headers and the start of entry data.
>> > + * List of entries in the order they appear inside the central
>> > + * directory.
>> >   */
>> > -private final Map entries =
>> > -new LinkedHashMap(HASH_SIZE);
>> > +private final List entries =
>> > +new LinkedList();
>> >
>> >  /**
>> > - * Maps String to ZipArchiveEntrys, name -> actual entry.
>> > + * Maps String to list of ZipArchiveEntrys, name -> actual entries.
>> >   */
>> > -private final Map nameMap =
>> > -new HashMap(HASH_SIZE);
>> > +private final Map> nameMap =
>> > +new HashMap>(HASH_SIZE);
>> >
>> >  private static final class OffsetEntry {
>> >  private long headerOffset = -1;
>> > @@ -273,7 +276,7 @@ public class ZipFile {
>> >   * @return all entries as {@link ZipArchiveEntry} instances
>> >   */
>> >  public Enumeration getEntries() {
>> > -return Collections.enumeration(entries.keySet());
>> > +return Collections.enumeration(entries);
>> >  }
>> >
>> >  /**
>> > @@ -287,8 +290,7 @@ public class ZipFile {
>> >   * @since 1.1
>> >   */
>> >  public Enumeration getEntriesInPhysicalOrder() {
>> > -ZipArchiveEntry[] allEntries =
>> > -entries.keySet().toArray(new ZipArchiveEntry[0]);
>> > +ZipArchiveEntry[] allEntries = entries.toArray(new
>> ZipArchiveEntry[0]);
>> >  Arrays.sort(allEntries, OFFSET_COMPARATOR);
>> >  return Collections.enumeration(Arrays.asList(allEntries));
>> >  }
>> > @@ -296,12 +298,51 @@ public class ZipFile {
>> >  /**
>> >   * Returns a named entry - or {@code null} if no entry by
>> >   * that name exists.
>> > + *
>> > + * If multiple entries with the same name exist the first entry
>> > + * in the archive's central directory by that name is
>> > + * returned.
>> > + *
>> >   * @param name name of the entry.
>> >   * @return the ZipArchiveEntry corresponding to the given name - or
>> >   * {@code null} if not present.
>> >   */
>> >  public ZipArchiveEntry getEntry(String name) {
>> > -return nameMap.get(name);
>> > +Deque entriesOfThatName = nameMap.get(name);
>> > +return entriesOfThatName != null ? entriesOfThatName.getFirst()
>> : null;
>> > +}
>> > +
>> > +/**
>> > + * Returns all named entries in the same order they appear within
>> > + * the archive's central directory.
>> > + *
>> > + * @param name name of the entry.
>> > + * @return the Iterator corresponding to the
>> > + * given name
>> > + * @since 1.6
>> > + */
>> > +public Iterator getEntries(String name) {
>> > +Deque entriesOfThatName = nameMap.get(name);
>> > +return entr

[Math] Accepting contributions (Was: svn commit: r1486982 - ...)

[Gilles]

On Tue, 28 May 2013 16:04:32 -, t...@apache.org wrote:

Author: tn
Date: Tue May 28 16:04:32 2013
New Revision: 1486982

URL: http://svn.apache.org/r1486982
Log:
[MATH-851] Added method MathArrays.convolve, thanks to Clemens Novak
for the patch.


-1

A significant part of this small patch (code and doc) contains 
formatting
mistakes and non-conventional notations, as was indicated in the 
comments.
If someone took the time to review something, please take it into 
account.


The unit test is also not correctly defined; we agreed that newer code
should test _one_ thing per test method.
Also, precondition checks should use the "expected" attribute of the
"@Test" annotation.

Efficiency-wise, I wonder about the condition nested inside the 
double-loop:


  if ((j > -1) && (j < N) ) {
  yn = yn + x[j] * h[k];
  }

As was also suggested in the comments, a "real" application (and/or a
discussion on the "dev" ML, preferably initiated by the OP) would have
been welcome to assess the pertinence of including this code in the
proposed form.

This is a perfect example of "someone, some day, might need this".
IMO, contributions should come from people who _actually_ use the 
proposed

code; we should not accept them as a mere coding exercises that will
potentially increase the burden on regular contributors.


Gilles


Modified:
commons/proper/math/trunk/src/changes/changes.xml


commons/proper/math/trunk/src/main/java/org/apache/commons/math3/util/MathArrays.java


commons/proper/math/trunk/src/test/java/org/apache/commons/math3/util/MathArraysTest.java

[...]



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

Re: svn commit: r1486348 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ZipFile.java test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java

[Gary Gregory]

On Tue, May 28, 2013 at 2:08 PM, sebb  wrote:

> On 25 May 2013 18:47,   wrote:
> > Author: bodewig
> > Date: Sat May 25 17:47:00 2013
> > New Revision: 1486348
> >
> > URL: http://svn.apache.org/r1486348
> > Log:
> > provide access to all entries of a given name in ZipFile, COMPRESS-227
>
> -1, see below
>
> > Modified:
> >
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
> >
> commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java
> >
> > Modified:
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
> > URL:
> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java?rev=1486348&r1=1486347&r2=1486348&view=diff
> >
> ==
> > ---
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
> (original)
> > +++
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
> Sat May 25 17:47:00 2013
> > @@ -25,9 +25,12 @@ import java.io.RandomAccessFile;
> >  import java.util.Arrays;
> >  import java.util.Collections;
> >  import java.util.Comparator;
> > +import java.util.Deque;
>
> That requires Java 1.6; Compress currently targets 1.5
>

Well, let's change the requirement to Java 6 for Compress 1.6.

Gary


>
> >  import java.util.Enumeration;
> >  import java.util.HashMap;
> > -import java.util.LinkedHashMap;
> > +import java.util.Iterator;
> > +import java.util.LinkedList;
> > +import java.util.List;
> >  import java.util.Map;
> >  import java.util.zip.Inflater;
> >  import java.util.zip.InflaterInputStream;
> > @@ -83,17 +86,17 @@ public class ZipFile {
> >  private static final int POS_3 = 3;
> >
> >  /**
> > - * Maps ZipArchiveEntrys to two longs, recording the offsets of
> > - * the local file headers and the start of entry data.
> > + * List of entries in the order they appear inside the central
> > + * directory.
> >   */
> > -private final Map entries =
> > -new LinkedHashMap(HASH_SIZE);
> > +private final List entries =
> > +new LinkedList();
> >
> >  /**
> > - * Maps String to ZipArchiveEntrys, name -> actual entry.
> > + * Maps String to list of ZipArchiveEntrys, name -> actual entries.
> >   */
> > -private final Map nameMap =
> > -new HashMap(HASH_SIZE);
> > +private final Map> nameMap =
> > +new HashMap>(HASH_SIZE);
> >
> >  private static final class OffsetEntry {
> >  private long headerOffset = -1;
> > @@ -273,7 +276,7 @@ public class ZipFile {
> >   * @return all entries as {@link ZipArchiveEntry} instances
> >   */
> >  public Enumeration getEntries() {
> > -return Collections.enumeration(entries.keySet());
> > +return Collections.enumeration(entries);
> >  }
> >
> >  /**
> > @@ -287,8 +290,7 @@ public class ZipFile {
> >   * @since 1.1
> >   */
> >  public Enumeration getEntriesInPhysicalOrder() {
> > -ZipArchiveEntry[] allEntries =
> > -entries.keySet().toArray(new ZipArchiveEntry[0]);
> > +ZipArchiveEntry[] allEntries = entries.toArray(new
> ZipArchiveEntry[0]);
> >  Arrays.sort(allEntries, OFFSET_COMPARATOR);
> >  return Collections.enumeration(Arrays.asList(allEntries));
> >  }
> > @@ -296,12 +298,51 @@ public class ZipFile {
> >  /**
> >   * Returns a named entry - or {@code null} if no entry by
> >   * that name exists.
> > + *
> > + * If multiple entries with the same name exist the first entry
> > + * in the archive's central directory by that name is
> > + * returned.
> > + *
> >   * @param name name of the entry.
> >   * @return the ZipArchiveEntry corresponding to the given name - or
> >   * {@code null} if not present.
> >   */
> >  public ZipArchiveEntry getEntry(String name) {
> > -return nameMap.get(name);
> > +Deque entriesOfThatName = nameMap.get(name);
> > +return entriesOfThatName != null ? entriesOfThatName.getFirst()
> : null;
> > +}
> > +
> > +/**
> > + * Returns all named entries in the same order they appear within
> > + * the archive's central directory.
> > + *
> > + * @param name name of the entry.
> > + * @return the Iterator corresponding to the
> > + * given name
> > + * @since 1.6
> > + */
> > +public Iterator getEntries(String name) {
> > +Deque entriesOfThatName = nameMap.get(name);
> > +return entriesOfThatName != null ? entriesOfThatName.iterator()
> > +: Collections.emptyList().iterator();
> > +}
> > +
> > +/**
> > + * Returns all named entries in the same order their contents
> > + * appear within the archive.
> > + *
> >

Re: svn commit: r1486348 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ZipFile.java test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java

[sebb]

On 25 May 2013 18:47,   wrote:
> Author: bodewig
> Date: Sat May 25 17:47:00 2013
> New Revision: 1486348
>
> URL: http://svn.apache.org/r1486348
> Log:
> provide access to all entries of a given name in ZipFile, COMPRESS-227

-1, see below

> Modified:
> 
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
> 
> commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java
>
> Modified: 
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java?rev=1486348&r1=1486347&r2=1486348&view=diff
> ==
> --- 
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>  (original)
> +++ 
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java
>  Sat May 25 17:47:00 2013
> @@ -25,9 +25,12 @@ import java.io.RandomAccessFile;
>  import java.util.Arrays;
>  import java.util.Collections;
>  import java.util.Comparator;
> +import java.util.Deque;

That requires Java 1.6; Compress currently targets 1.5

>  import java.util.Enumeration;
>  import java.util.HashMap;
> -import java.util.LinkedHashMap;
> +import java.util.Iterator;
> +import java.util.LinkedList;
> +import java.util.List;
>  import java.util.Map;
>  import java.util.zip.Inflater;
>  import java.util.zip.InflaterInputStream;
> @@ -83,17 +86,17 @@ public class ZipFile {
>  private static final int POS_3 = 3;
>
>  /**
> - * Maps ZipArchiveEntrys to two longs, recording the offsets of
> - * the local file headers and the start of entry data.
> + * List of entries in the order they appear inside the central
> + * directory.
>   */
> -private final Map entries =
> -new LinkedHashMap(HASH_SIZE);
> +private final List entries =
> +new LinkedList();
>
>  /**
> - * Maps String to ZipArchiveEntrys, name -> actual entry.
> + * Maps String to list of ZipArchiveEntrys, name -> actual entries.
>   */
> -private final Map nameMap =
> -new HashMap(HASH_SIZE);
> +private final Map> nameMap =
> +new HashMap>(HASH_SIZE);
>
>  private static final class OffsetEntry {
>  private long headerOffset = -1;
> @@ -273,7 +276,7 @@ public class ZipFile {
>   * @return all entries as {@link ZipArchiveEntry} instances
>   */
>  public Enumeration getEntries() {
> -return Collections.enumeration(entries.keySet());
> +return Collections.enumeration(entries);
>  }
>
>  /**
> @@ -287,8 +290,7 @@ public class ZipFile {
>   * @since 1.1
>   */
>  public Enumeration getEntriesInPhysicalOrder() {
> -ZipArchiveEntry[] allEntries =
> -entries.keySet().toArray(new ZipArchiveEntry[0]);
> +ZipArchiveEntry[] allEntries = entries.toArray(new 
> ZipArchiveEntry[0]);
>  Arrays.sort(allEntries, OFFSET_COMPARATOR);
>  return Collections.enumeration(Arrays.asList(allEntries));
>  }
> @@ -296,12 +298,51 @@ public class ZipFile {
>  /**
>   * Returns a named entry - or {@code null} if no entry by
>   * that name exists.
> + *
> + * If multiple entries with the same name exist the first entry
> + * in the archive's central directory by that name is
> + * returned.
> + *
>   * @param name name of the entry.
>   * @return the ZipArchiveEntry corresponding to the given name - or
>   * {@code null} if not present.
>   */
>  public ZipArchiveEntry getEntry(String name) {
> -return nameMap.get(name);
> +Deque entriesOfThatName = nameMap.get(name);
> +return entriesOfThatName != null ? entriesOfThatName.getFirst() : 
> null;
> +}
> +
> +/**
> + * Returns all named entries in the same order they appear within
> + * the archive's central directory.
> + *
> + * @param name name of the entry.
> + * @return the Iterator corresponding to the
> + * given name
> + * @since 1.6
> + */
> +public Iterator getEntries(String name) {
> +Deque entriesOfThatName = nameMap.get(name);
> +return entriesOfThatName != null ? entriesOfThatName.iterator()
> +: Collections.emptyList().iterator();
> +}
> +
> +/**
> + * Returns all named entries in the same order their contents
> + * appear within the archive.
> + *
> + * @param name name of the entry.
> + * @return the Iterator corresponding to the
> + * given name
> + * @since 1.6
> + */
> +public Iterator getEntriesInPhysicalOrder(String name) {
> +ZipArchiveEntry[] entriesOfThatName = new ZipArchiveEntry[0];
> +if (nameMap.containsKey(name)) {
> +

Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit: r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/ src/java/org/apache/commons/dbcp2/cpdsadapter/ src

[Phil Steitz]

On 5/28/13 3:58 AM, Emmanuel Bourg wrote:
> Le 11/01/2013 08:36, Mark Thomas a écrit :
>
>> We could also add the JDBC 4.1 methods to DBCP1 but I'm not sure I like the 
>> idea of three builds for that version.
> I think we should do that. Debian and Fedora maintain a patch to be able
> to build DBCP from source (see DBCP-385), but we should assume this burden.
>
> I see 3 options, either:
>
> 1. Release DBCP 1.4.1 with no-op methods throwing a
> SQLFeatureNotSupportedException or an UnsupportedOperationException.
> This is what Fedora/Debian do.
>
> 2. Release DBCP 1.5 with the fully implemented methods and Java 7 as a
> build requirement.
>
> 3. Release DBCP 1.4.1 or 1.5 with the fully implemented methods but
> using reflection, thus compiling with Java 6 or Java 7.
>
>
> What do you think ?

Looks complicated and painful.  I would rather put energy into
getting dbcp 2.0 out the door and aim for the following:

DBCP 1.3.x JDK 1.4-1.5
DBCP 1.4.x JDK 1.6
DBCP 2.xJDK 1.7

The 1.4 branch (once the 1.7 stuff is reverted) can still be used to
generate 1.3 releases.  Adding on another set of filters is in
theory possible, but painful.

So basically, we cut only pure maintenance releases for 1.3/1.4 and
put the energy into getting 2.0 out.

Phil
>
>
> Emmanuel Bourg
>
>


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

Re: [DBCP] isClosed contract (DBCP-398)

[Phil Steitz]

On 5/28/13 1:58 AM, Mark Thomas wrote:
> On 27/05/2013 15:49, Phil Steitz wrote:
>> We need to make a decision on whether or not to change the contract
>> for PoolableConnection (or DelegatingConnection or PoolGuardWrapper)
>> isClosed.  There are two changes suggested in DBCP-398:
>>
>> 1) Currently, isClosed returns true if the connection handle has
>> been closed by the client *or* the underlying connection's isClosed
>> returns true.  So if a connection has been closed server-side and
>> the driver reports this via isClosed on the physical connection,
>> DBCP clients get true returned even if they have not called close on
>> the handle.  This behavior goes back to DBCP 1.0.
> My reading of the java.sql.Connection Javadoc is that this is the
> correct behaviour.
>
> The Javadoc states:
> 
> A connection is closed if the method close has been called on it or if
> certain fatal errors have occurred.
> 
>
> Looking at the implementation of this for DelegatingConnection:
> return _closed || _conn.isClosed();
>
> The check of _closed is necessary to satisfy "if the close method has
> been called" and _conn.isClosed() is necessary to satisfy "or if certain
> fatal errors have occurred"

I guess that is defensible.  The second clause is there for the kind
of situation that we face when the underlying physical connection
has been closed without the pool or pool client's involvement.
>
> The client should not be using isClosed() to determine whether or not to
> return the object to the pool because this is guaranteed to get a leak
> if "certain fatal errors have occurred". The client should return the
> object to the pool every time and let the pool handle any invalid
> connections.

I agree with this.
>
>> 2) When a PoolableConnection is closed by the client and it has
>> already been closed server-side (i.e. the driver's isClosed returns
>> true on the physical connection) an SQLException is thrown.  This
>> behavior is newly distinguished in DBCP 1.3/1.4.  Prior to the
>> latest releases, if isClosed (with semantics above) returned true,
>> SQLException was always thrown.  In 1.3/1.4, we made close
>> idempotent, so multiple client-side calls to close no longer
>> generate an SQLException.  We decided, however, to still throw when
>> close is invoked on a connection handle whose underlying physical
>> connection's isClosed returns true.
> That seems reasonable to me. isClosed() is permitted to throw an
> SQLException so the clients have to be able to handle this. The root
> cause of the unexpected closure may or may not be an issue for the
> client. It could be expected (e.g. database was restarted) or it could
> be unexpected (indicative of a network issue between client and
> database). It is therefore important that the exception is passed to the
> client.
>
> Generally, there is little the client can do with an exception in this
> method apart from log it but that is probably what the client should be
> doing unless they really don't care about these errors.

I agree here too.  For 2.0, we may want to provide tracking for
these as we do for validation failures; but I guess in 1.x it may be
best to just leave as is.
>
>> As of now, 1.X and 2.0 code behave the same way.  We have several
>> alternatives to choose from here:
>>
>> a) Do nothing - i.e., keep the contract as it is
>> b) "Fix" in 2.0
>> c) Fix in 1.X
>>
>> If we do change the contract in 1.X, I am not sure it is OK to do
>> that in 1.3.1/1.4.1 - i.e. would have to move to 1.5, 1.7 or
>> something (recall that 1.3 is for JDK 1.4-1.5, 1.4 is JDK 1.6).
>>
>> "Fixing" 2) is straightforward.  For 1), my inclination would be to
>> just change DelegatingConnection#isClosed; but logically the least
>> change approach would be changing PoolGuardConnectionWrapper
>> (followed by PoolableConnection, DelegatingConnection).
>>
>> Whatever we decide, we should make sure to document it. 
>> Unfortunately, current behavior is not spelled out in the javadoc.
>>
>> It would be great to get some others' feedback on how best to proceed.
> My view is that the current code conforms to the Javadoc for
> java.sql.Connection and should not be changed.
>
> I'd have no objection to improving our own Javadoc to spell out that
> isClosed() should not be used as a test to determine if a connection
> should be closed (i.e. returned to the pool) or not.

I suggest then that we add comments above to the DBCP-398 and close
as WONT_FIX.

Phil
>
> Mark
>
>
> -
> 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

[Followup][Graph] the future of commons-graph and modularization

[Simone Tripodi]

Hi all guys,

here it is my proposal[1], see r1486948.

It has been quiet hard since he did not think in therms of separated
modules, so I took the freedom to relocate some classes here and
there. It is a experimental branch anyway, the purpose is just
demonstrating the PoC.

Looking forward to read your feedbacks!

Many thanks in advance, all the best,
-Simo

[1] 
http://svn.apache.org/repos/asf/commons/sandbox/graph/branches/modularization/

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sun, May 26, 2013 at 5:35 PM, Simone Tripodi
 wrote:
> Hi all, mates,
>
> after a long while I haven't touched commons-graph, I had the
> opportunity to get influenced by some activities at my paid work that
> made me think twice on what as been already done in that component,
> and would like to bring new experiences in.
>
> So, what I still like about it:
>
>  * graph APIs: the use of generics make the usage of graphes
> extensible and adaptable;
>
>  * fluent APIs: this is the most powerful feature IMHO that simplifies
> the APIs usage;
>
> What I *don't* like anymore:
>
>  * poor modularization: commons-graph is ATM a big fat monolith;
>
>  * one single entry-point; for each new family of algorithm(s), new
> methods have to be added in the main Commons-Graph class.
>
> What I would like to propose to work _in a separated branch_, is
> trying to split the big monolith in smaller modules and separate APIs
> from related implementation as much as possible.
>
> Questions are:
>
>  * WDYT? :)
>
>  * About release process: would it be acceptable, here in commons,
> release a single module - the only one that has been changed, I mean -
> without releasing the whole project?
>
>  * In case the answer to previous question is "no", would it make
> sense moving commons-graph to the Incubator (and possibly to TLP)?
>
> TIA, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/

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

Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit: r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/ src/java/org/apache/commons/dbcp2/cpdsadapter/ src/

[Gary Gregory]

On Tue, May 28, 2013 at 6:58 AM, Emmanuel Bourg  wrote:

> Le 11/01/2013 08:36, Mark Thomas a écrit :
>
> > We could also add the JDBC 4.1 methods to DBCP1 but I'm not sure I like
> the idea of three builds for that version.
>
> I think we should do that. Debian and Fedora maintain a patch to be able
> to build DBCP from source (see DBCP-385), but we should assume this burden.
>
> I see 3 options, either:
>
> 1. Release DBCP 1.4.1 with no-op methods throwing a
> SQLFeatureNotSupportedException or an UnsupportedOperationException.
> This is what Fedora/Debian do.
>

That's fine with me but I would not say this is not for a maintenance
version, it should be for a minor version.


> 2. Release DBCP 1.5 with the fully implemented methods and Java 7 as a
> build requirement.
>

Fine with me, nice and simple.


>
> 3. Release DBCP 1.4.1 or 1.5 with the fully implemented methods but
> using reflection, thus compiling with Java 6 or Java 7.
>

I do not like these kinds of solutions because I have to think twice about
what the dynamic behavior means on different platforms.

Gary


>
>
> What do you think ?
>
>
> Emmanuel Bourg
>
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[continuum] BUILD FAILURE: Apache Commons - Commons Compress -

[Continuum@vmbuild]

  Group (shared) Maven 2 Build Definition (Java 1.5)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 64
X-Continuum-Project-Name: Commons Compress

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=27001&projectId=64

Build statistics:
  State: Failed
  Previous State: Failed
  Started at: Tue 28 May 2013 12:20:06 +
  Finished at: Tue 28 May 2013 12:20:26 +
  Total time: 20s
  Build Trigger: Schedule
  Build Number: 276
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_30"
  Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_30
  Java home: /usr/lib/jvm/jdk1.6.0_30/jre
  Default locale: en_US, platform encoding: ANSI_X3.4-1968
  OS name: "linux" version: "2.6.32-41-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: bodewig @ Tue 28 May 2013 11:24:47 +
Comment: Java5 doesn't like Zip64 extra fields at all
Files changed:
  /commons/proper/compress/trunk/src/site/xdoc/zip.xml ( 1486874 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Group (shared) Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 0
Failures: 0
Errors: 0
Total time: 0.0




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

Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit: r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/ src/java/org/apache/commons/dbcp2/cpdsadapter/ src

[Emmanuel Bourg]

Le 11/01/2013 08:36, Mark Thomas a écrit :

> We could also add the JDBC 4.1 methods to DBCP1 but I'm not sure I like the 
> idea of three builds for that version.

I think we should do that. Debian and Fedora maintain a patch to be able
to build DBCP from source (see DBCP-385), but we should assume this burden.

I see 3 options, either:

1. Release DBCP 1.4.1 with no-op methods throwing a
SQLFeatureNotSupportedException or an UnsupportedOperationException.
This is what Fedora/Debian do.

2. Release DBCP 1.5 with the fully implemented methods and Java 7 as a
build requirement.

3. Release DBCP 1.4.1 or 1.5 with the fully implemented methods but
using reflection, thus compiling with Java 6 or Java 7.


What do you think ?


Emmanuel Bourg




signature.asc
Description: OpenPGP digital signature

[Graph] Missing algorithms

[Oliver Kopp]

Hi,

In a discussion with Simone, we thought it would be a good idea of having a
list of missing algorithms in Apache Commons Graph. I compiled a first shot
for such a list in https://issues.apache.org/jira/browse/SANDBOX-458.

Although there are BSD-licensed graph-libraries, jBPT is the only library
offering algorithms which are useful in the context of business process
management (BPM), especially analysis of business processes [1].
Unfortunately, jBPT is licensed under LGPL.

In the context of BPM, a transformation of different languages comes
important. For instance, it is desired to transform BPMN to BPEL to enable
the usage of Workflow Engines such as Apache ODE with BPMN as input model.
I'm in the middle of such a transformation. I've based it on jBPT since I
wasn't aware up then that LGPL causes problems. I read a BPMN file into a
graph and parse it with jBPT into an RPST [2], which is then interpreted an
transformed to BPEL. The RPST itself relies on an SPQR tree [3]. There is
an implementation for RPST based on [2], but this implementation uses a C
library being GPL-licensed. There is an improvement of the algorithm
presented in [4], but the only implementation is jBPT.

If someone supported me in getting an Apache-based SPQR and RPST
implementation, I'd be very happy.

Cheers,

Oliver


[1] Artem Polyvyanyy and Matthias Weidlich. Towards a Compendium of Process
Technologies: The jBPT Library for Process Model Analysis. Proceedings of
the Forum of the 25th International Conference on Advanced Information
Systems Engineering (CAiSE Forum'13), Valencia, Spain, 2013. To appear.

[2] Vanhatalo, J.; Völzer, H. & Koehler, J. Dumas, M. The Refined Process
Structure Tree BPM'08: Business Process Management, 6th International
Conference, BPM 2008, Springer, 2008, 5240, 100-115

[3] Gutwenger, C. & Mutzel, P. A Linear Time Implementation of SPQR-Trees
Graph Drawing, Springer Berlin Heidelberg, 2001, 1984, 77-90

[4] Polyvyanyy, A.; Vanhatalo, J. & Völzer, H. Simplified Computation and
Generalization of the Refined Process Structure Tree Web Services and
Formal Methods, Springer Berlin Heidelberg, 2011, 6551, 25-41

Re: [DBCP] isClosed contract (DBCP-398)

[Mark Thomas]

On 27/05/2013 15:49, Phil Steitz wrote:
> We need to make a decision on whether or not to change the contract
> for PoolableConnection (or DelegatingConnection or PoolGuardWrapper)
> isClosed.  There are two changes suggested in DBCP-398:
> 
> 1) Currently, isClosed returns true if the connection handle has
> been closed by the client *or* the underlying connection's isClosed
> returns true.  So if a connection has been closed server-side and
> the driver reports this via isClosed on the physical connection,
> DBCP clients get true returned even if they have not called close on
> the handle.  This behavior goes back to DBCP 1.0.

My reading of the java.sql.Connection Javadoc is that this is the
correct behaviour.

The Javadoc states:

A connection is closed if the method close has been called on it or if
certain fatal errors have occurred.


Looking at the implementation of this for DelegatingConnection:
return _closed || _conn.isClosed();

The check of _closed is necessary to satisfy "if the close method has
been called" and _conn.isClosed() is necessary to satisfy "or if certain
fatal errors have occurred"

The client should not be using isClosed() to determine whether or not to
return the object to the pool because this is guaranteed to get a leak
if "certain fatal errors have occurred". The client should return the
object to the pool every time and let the pool handle any invalid
connections.

> 2) When a PoolableConnection is closed by the client and it has
> already been closed server-side (i.e. the driver's isClosed returns
> true on the physical connection) an SQLException is thrown.  This
> behavior is newly distinguished in DBCP 1.3/1.4.  Prior to the
> latest releases, if isClosed (with semantics above) returned true,
> SQLException was always thrown.  In 1.3/1.4, we made close
> idempotent, so multiple client-side calls to close no longer
> generate an SQLException.  We decided, however, to still throw when
> close is invoked on a connection handle whose underlying physical
> connection's isClosed returns true.

That seems reasonable to me. isClosed() is permitted to throw an
SQLException so the clients have to be able to handle this. The root
cause of the unexpected closure may or may not be an issue for the
client. It could be expected (e.g. database was restarted) or it could
be unexpected (indicative of a network issue between client and
database). It is therefore important that the exception is passed to the
client.

Generally, there is little the client can do with an exception in this
method apart from log it but that is probably what the client should be
doing unless they really don't care about these errors.

> As of now, 1.X and 2.0 code behave the same way.  We have several
> alternatives to choose from here:
> 
> a) Do nothing - i.e., keep the contract as it is
> b) "Fix" in 2.0
> c) Fix in 1.X
> 
> If we do change the contract in 1.X, I am not sure it is OK to do
> that in 1.3.1/1.4.1 - i.e. would have to move to 1.5, 1.7 or
> something (recall that 1.3 is for JDK 1.4-1.5, 1.4 is JDK 1.6).
> 
> "Fixing" 2) is straightforward.  For 1), my inclination would be to
> just change DelegatingConnection#isClosed; but logically the least
> change approach would be changing PoolGuardConnectionWrapper
> (followed by PoolableConnection, DelegatingConnection).
> 
> Whatever we decide, we should make sure to document it. 
> Unfortunately, current behavior is not spelled out in the javadoc.
> 
> It would be great to get some others' feedback on how best to proceed.

My view is that the current code conforms to the Javadoc for
java.sql.Connection and should not be changed.

I'd have no objection to improving our own Javadoc to spell out that
isClosed() should not be used as a test to determine if a connection
should be closed (i.e. returned to the pool) or not.

Mark


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

Re: [chain] improving current registry and configuration APIs

[Simone Tripodi]

Hi Bene!
thanks a lot in advance! new fresh energies are required at all
levels, from giving feedbacks 'till leg-work! :)
welcome aboard!
Alles Gute!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Tue, May 28, 2013 at 8:43 AM, Benedikt Ritter  wrote:
> Hi Simo,
>
>
> 2013/5/27 Simone Tripodi 
>
>> Hi all Chain-ers,
>>
>> I had yet another small review yesterday[1] at current Configuration
>> APIs and I am not satisfied yet for the following reasons:
>>
>>  * org.apache.commons.chain2.CatalogFactory should maybe moved from
>> `core` module to the `api` module;
>>
>>  * org.apache.commons.chain2.CatalogFactory is an abstract class, but
>> the static `getInstance()` method relies to a specific concrete
>> implementation;
>>
>>  * org.apache.commons.chain2.CatalogFactory mixes the concept of
>> Factory and Registry - more I read that codebase, more I get confused,
>> IMHO it should be split in two different classes with two different
>> roles;
>>
>>  * after introducing the configuration facade APIs,
>> org.apache.commons.chain2.CatalogFactory#checkForValidConfigurationModule()
>> lost its purpose - I suggest to drop it and make the CatalogFactory
>> completely un-aware of the existence of the configuration.
>>
>>  * the most confusing part is still, IMHO, how the config APIs work:
>> the org.apache.commons.chain2.config.ConfigParser#parse(URL) method
>> parses a textual format of Chain representation and populates
>> org.apache.commons.chain2.CatalogFactory retrieving the static
>> singleton instance and populate it... IMHO, it would be easier if the
>> `parse(URL)` method just returns a CatalogFactory instance.
>>
>> This is just to start, I think much more will come when I'll have
>> another look at current codebase.
>>
>> Now, the question is: is there any committer(s)/contributor(s) that
>> can/wishes to help on the Chain component? Due to my reduced spare
>> time slot, I cannot handle it all alone and it would be good, after
>> more than one year of work, speaking about an RC :)
>>
>
> I didn't have the time to take a look at the code base, but I'm interested
> in getting involved. I will probably have a few cycles the next days. After
> I have digged into the code I'll comment on the topics you mentioned.
>
> This is going to be fun! :)
>
> Benedikt
>
>
>>
>> Many thanks in advance, all the best!
>> -Simo
>>
>> [1] http://svn.apache.org/viewvc?view=revision&revision=1486478
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> 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

[DISCUSS] Accept BeanShell to Commons Sandbox (Was: [VOTE] Accept Apache BeanShell in the Incubator)

[Simone Tripodi]

Hi all PMC members,

I started a VOTE thread in general@incubator to accept BeanShell in
the incubating projects, Bertrand Delacretaz and Ant Elder made
interesting observations (pasted below) about accepting BeanShell
directly to Commons.

I think we are in the similar past situations when we voted new
committers and accepted their donations to the Commons Sandbox - WDYT?
Would it be reasonable for that PMC accepting BS in Sandbox and accept
a couple of new committers?

Many thanks in advance, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



-- Forwarded message --
From: Bertrand Delacretaz 
Date: Mon, May 27, 2013 at 11:37 AM
Subject: Re: [VOTE] Accept Apache BeanShell in the Incubator
To: gene...@incubator.apache.org


On Sat, May 25, 2013 at 9:07 AM, ant elder  wrote:
> ...Half the committers are ASF
> members so they know what they're doing already, we're not going to teach
> Sebb anything new about doing releases...

Indeed ;-)

> ...All thats needed is a software grant and IP clearance (which from the
> previous discuss thread has already been done?) and start up right away in
> Commons...

Makes sense, I agree with you that the Incubator doesn't bring any
more value in this case...has the commons PMC been asked about this
option?

I'm changing my vote to -1, at least until this is clarified.

-Bertrand

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

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