Re: [io] ClosedOutputStream#flush

[Elijah Zupancic]

Please omit this line from the program:

BufferedOutputStream bout = new BufferedOutputStream(fout, 9);

On Tue, Aug 15, 2017 at 6:12 PM, Elijah Zupancic  wrote:
> I inspected the code path and I think this bug has merit. Consider the
> following sample application:
>
> import org.apache.commons.io.IOUtils;
> import org.apache.commons.io.output.CloseShieldOutputStream;
>
> import java.io.BufferedOutputStream;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.nio.charset.StandardCharsets;
>
> public class BrokenShield {
> public static void main(String[] argv) throws IOException {
> File file = File.createTempFile("broken-shield", "txt");
>
> byte[] arbitraryData = "Hello World 
> ".getBytes(StandardCharsets.UTF_8);
>
> FileOutputStream fout = new FileOutputStream(file);
> BufferedOutputStream bout = new BufferedOutputStream(fout, 9);
> CloseShieldOutputStream cout = new CloseShieldOutputStream(fout);
>
> try {
> // This should work because we haven't tried to close the stream
> cout.write(arbitraryData);
>
> // Here we pretend this is some stupid library that insists on
> // closing a stream when it shouldn't.
> cout.close();
>
> // After we try to close the stream, new data can't be written to
> // the stream. For example: cout.write(arbitraryData);
> // Would throw an exception like:
> // java.io.IOException: write(72) failed: stream is closed
>
> // However, if we call flush(), no exception is thrown - this is
> // inconsistent with the behavior of write()
> cout.flush();
> } finally {
> // We properly close the stream we have to use the underlying
> // stream like you would expect.
> fout.close();
> }
>
> try (FileInputStream fin = new FileInputStream(file)) {
> String data = IOUtils.toString(fin, StandardCharsets.UTF_8);
> System.out.println(data);
> }
> }
> }
>
> On Thu, Aug 10, 2017 at 4:54 PM, Tomas Celaya  wrote:
>> Would anyone mind taking a look at this issue regarding the flush method on
>> ClosedOutputStream?
>>
>> https://issues.apache.org/jira/browse/IO-546
>>
>> The change is relatively trivial and the attached patch includes a test
>> case. I understand the impact is significant but I think it would make
>> ClosedOutputStream behave more consistently with what a user would expect.
>>
>> – Tomas Celaya

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

Re: [io] ClosedOutputStream#flush

[Elijah Zupancic]

I inspected the code path and I think this bug has merit. Consider the
following sample application:

import org.apache.commons.io.IOUtils;
import org.apache.commons.io.output.CloseShieldOutputStream;

import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.charset.StandardCharsets;

public class BrokenShield {
public static void main(String[] argv) throws IOException {
File file = File.createTempFile("broken-shield", "txt");

byte[] arbitraryData = "Hello World ".getBytes(StandardCharsets.UTF_8);

FileOutputStream fout = new FileOutputStream(file);
BufferedOutputStream bout = new BufferedOutputStream(fout, 9);
CloseShieldOutputStream cout = new CloseShieldOutputStream(fout);

try {
// This should work because we haven't tried to close the stream
cout.write(arbitraryData);

// Here we pretend this is some stupid library that insists on
// closing a stream when it shouldn't.
cout.close();

// After we try to close the stream, new data can't be written to
// the stream. For example: cout.write(arbitraryData);
// Would throw an exception like:
// java.io.IOException: write(72) failed: stream is closed

// However, if we call flush(), no exception is thrown - this is
// inconsistent with the behavior of write()
cout.flush();
} finally {
// We properly close the stream we have to use the underlying
// stream like you would expect.
fout.close();
}

try (FileInputStream fin = new FileInputStream(file)) {
String data = IOUtils.toString(fin, StandardCharsets.UTF_8);
System.out.println(data);
}
}
}

On Thu, Aug 10, 2017 at 4:54 PM, Tomas Celaya  wrote:
> Would anyone mind taking a look at this issue regarding the flush method on
> ClosedOutputStream?
>
> https://issues.apache.org/jira/browse/IO-546
>
> The change is relatively trivial and the attached patch includes a test
> case. I understand the impact is significant but I think it would make
> ClosedOutputStream behave more consistently with what a user would expect.
>
> – Tomas Celaya

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

Re: [vfs] Wiki update for Manta VFS provider

[Elijah Zupancic]

Hi Bernd or whoever can help this happen,

I haven't heard back from you nor seen any updates, so I wanted to offer a
reminder.

Thanks,
Elijah

On Mon, Oct 3, 2016 at 9:56 PM, Elijah Zupancic  wrote:

> Hi Bernd,
>
> Could you add the following:
>
> commons-vfs-manta - VFS provider for Joyent's Manta Object Store
>
> With the link: https://github.com/joyent/commons-vfs-manta
>
> Thanks,
> Elijah
>
> On Mon, Oct 3, 2016 at 6:35 AM,  wrote:
>
>> Hello Elija,
>>
>> I can do that for you, let me know the wording and link you want to be
>> included.
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> From Win 10 Mobile
>>
>> Von: Elijah Zupancic
>> Gesendet: Montag, 3. Oktober 2016 14:16
>> An: Commons Developers List
>> Betreff: [vfs] Wiki update for Manta VFS provider
>>
>> I just finished writing the first version of a VFS provider for the open
>> source object store Manta (https://www.joyent.com/manta).
>>
>> I would like to add a line under "Related Projects" on the VFS Wiki for:
>> https://github.com/joyent/commons-vfs-manta and I don't have access to
>> make
>> this change myself.
>>
>> Is there someone who can do this one line addition for me?
>>
>> Thanks,
>> Elijah Zupancic
>>
>>
>

Re: [vfs] Wiki update for Manta VFS provider

[Elijah Zupancic]

Hi Bernd,

Could you add the following:

commons-vfs-manta - VFS provider for Joyent's Manta Object Store

With the link: https://github.com/joyent/commons-vfs-manta

Thanks,
Elijah

On Mon, Oct 3, 2016 at 6:35 AM,  wrote:

> Hello Elija,
>
> I can do that for you, let me know the wording and link you want to be
> included.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> From Win 10 Mobile
>
> Von: Elijah Zupancic
> Gesendet: Montag, 3. Oktober 2016 14:16
> An: Commons Developers List
> Betreff: [vfs] Wiki update for Manta VFS provider
>
> I just finished writing the first version of a VFS provider for the open
> source object store Manta (https://www.joyent.com/manta).
>
> I would like to add a line under "Related Projects" on the VFS Wiki for:
> https://github.com/joyent/commons-vfs-manta and I don't have access to
> make
> this change myself.
>
> Is there someone who can do this one line addition for me?
>
> Thanks,
> Elijah Zupancic
>
>

[vfs] Wiki update for Manta VFS provider

[Elijah Zupancic]

I just finished writing the first version of a VFS provider for the open
source object store Manta (https://www.joyent.com/manta).

I would like to add a line under "Related Projects" on the VFS Wiki for:
https://github.com/joyent/commons-vfs-manta and I don't have access to make
this change myself.

Is there someone who can do this one line addition for me?

Thanks,
Elijah Zupancic

Re: [CHAIN] Why does ConextMap extend ConcurrentHashMap instead of delegating to a Map?

[Elijah Zupancic]

Oh, no blame taken. I'm actually really excited about all of the changes.
Unfortunately, I've been missing for a while due to increased work
responsibilities.

The changes are all things way beyond what I was initially envisioning as a
2.0. What led me to contribute was that I was using Chain and getting
really frustrated about how "old" it felt as a consumer of the library. I
wanted generics and extensibility. Also, I suspected that the library had a
lot of serious thread safety issues and I didn't have the time to address
those. I noticed that those are starting to get dealt with! Anyways, in the
process of working on the project, I saw that a lot else was possible, but
I had to hold back because my time was limited. I think you are doing great
work and I'm happy to see a 2.0 get closer toward release.

Thanks,
-Elijah


On Thu, Jun 27, 2013 at 4:17 AM, Benedikt Ritter  wrote:

> Hi Elijah,
>
> nice to have you with us again :-)
>
>
> 2013/6/26 Elijah Zupancic 
>
> > Hi Benedikt,
> >
> > I made the decision to inherit from ConcurrentHashMap because the
> original
> > implementation was inheriting from HashMap. I was doing an incremental
> > refactoring approach and there was never a good justification for that
> > design rather I was trying to make evolutionary improvements. Being able
> to
> > plug in any map implementation would be a far better design. As for the
> > original design decision to use a HashMap, I have no insight. There were
> > quite a few design enigmas that I encountered, however if you look at the
> > date of the original project I don't think it is unusual.
> >
>
> Thanks for the insights! My mail was not intended to blame you. You did
> great work on chain.
> Would be great if you could manage to share your thoughts about the
> upcoming design changes.
>
> Benedikt
>
>
> >
> > Best of luck,
> > -Elijah
> >
> >
> > On Tue, Jun 25, 2013 at 11:24 AM, Benedikt Ritter  > >wrote:
> >
> > > I have created CHAIN-101 [1]
> > >
> > > Benedikt
> > >
> > > [1] https://issues.apache.org/jira/browse/CHAIN-101
> > >
> > > Am 24.06.2013 um 20:57 schrieb Adrian Crum <
> > > adrian.c...@sandglass-software.com>:
> > >
> > > > I have always preferred the "has-a" approach over the "is-a"
> approach.
> > > It makes things easier to refactor down the road.
> > > >
> > > > -Adrian
> > > >
> > > > On 6/24/2013 7:30 PM, Benedikt Ritter wrote:
> > > >> Hi,
> > > >>
> > > >> I just wonder why ContextMap inherits from ConcurrentHashMap. This
> > > seems like an unnecessary restriction. The context interface makes
> > > explicit, that implementations do not have to be thread safe. Beside
> that
> > > we loose all thread safety a ConcurrentHashMap provides with our
> > > not-so-thread-safe implementations in ContextMap and ContextBase. I'd
> > > suggest to switch from an inheritance based approach to a delegation
> > based
> > > approach. That leaves users with the liberty to choose what ever
> > underlying
> > > Map implementation they like for their context.
> > > >>
> > > >> WDYT?
> > > >> Benedikt
> > > >>
> -
> > > >> 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
> > >
> > >
> >
> >
> > --
> > -Elijah
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
-Elijah

Re: [CHAIN] Thoughts about o.a.c.chain2.Chain, o.a.c.chain2.Command and the base classes

[Elijah Zupancic]

+1 to everything.

With regards to an enum for status, wouldn't it be better to use a class so
that consumers could subclass it and add their own states if needed?

Thanks,
-Elijah


On Sat, Jun 22, 2013 at 4:30 AM, Benedikt Ritter wrote:

>
> Am 22.06.2013 um 12:57 schrieb Simone Tripodi :
>
> > Hi Jonas,
> >
> >>
> >> I will provide a patch for
> >> CHAIN-98tomorow. The
> >> patch will only cover the refactoring of CONTINUE and
> >> COMPLETED processing results.
> >>
> >
> > nice to read that, looking forward to the patch! :)
> >
> >> But, I do not understand how exceptions should be handled in this
> context.
> >> A exception listener filters the exceptions and returns ABORTED if
> >> appropriate?
> >
> > let's postpone it and keep CONTINUE and COMPLETED only ATM - Benedikt
> > is working on an exception listener, let's see how it evolves and
> > let's evaluate later if/how ABORTED will be introduced.
>
> Yeah, well I'm not really working on it. But I'll do as soon as I got the
> time :)
>
> Benedikt
>
> >
> > Thanks in advance, all the best!
> > -Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://twitter.com/simonetripodi
> >
> > -
> > 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
>
>


-- 
-Elijah

Re: [CHAIN] Why does ConextMap extend ConcurrentHashMap instead of delegating to a Map?

[Elijah Zupancic]

Hi Benedikt,

I made the decision to inherit from ConcurrentHashMap because the original
implementation was inheriting from HashMap. I was doing an incremental
refactoring approach and there was never a good justification for that
design rather I was trying to make evolutionary improvements. Being able to
plug in any map implementation would be a far better design. As for the
original design decision to use a HashMap, I have no insight. There were
quite a few design enigmas that I encountered, however if you look at the
date of the original project I don't think it is unusual.

Best of luck,
-Elijah


On Tue, Jun 25, 2013 at 11:24 AM, Benedikt Ritter wrote:

> I have created CHAIN-101 [1]
>
> Benedikt
>
> [1] https://issues.apache.org/jira/browse/CHAIN-101
>
> Am 24.06.2013 um 20:57 schrieb Adrian Crum <
> adrian.c...@sandglass-software.com>:
>
> > I have always preferred the "has-a" approach over the "is-a" approach.
> It makes things easier to refactor down the road.
> >
> > -Adrian
> >
> > On 6/24/2013 7:30 PM, Benedikt Ritter wrote:
> >> Hi,
> >>
> >> I just wonder why ContextMap inherits from ConcurrentHashMap. This
> seems like an unnecessary restriction. The context interface makes
> explicit, that implementations do not have to be thread safe. Beside that
> we loose all thread safety a ConcurrentHashMap provides with our
> not-so-thread-safe implementations in ContextMap and ContextBase. I'd
> suggest to switch from an inheritance based approach to a delegation based
> approach. That leaves users with the liberty to choose what ever underlying
> Map implementation they like for their context.
> >>
> >> WDYT?
> >> Benedikt
> >> -
> >> 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
>
>


-- 
-Elijah

[chain2] Release Status

[Elijah Zupancic]

Hi Simo and everyone else,

I'm working on a project that I would like to bring in the release
version of chain2 rather than the snapshot. What other things do we
need to finish up on in order for us to cut a release?

Thanks,
-Elijah

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

Re: [chain2] ServiceLoader in Chain2 to load Jackson supported formats

[Elijah Zupancic]

I vote for going to Java 6. Java 6 is end of life in November, so it
seems a bit silly to support two end of life versions of Java. One
seems sufficient. That said - I may be breaking from the consensus
here at the Apache Commons.

-Elijah

On Mon, Aug 6, 2012 at 8:13 AM, Simone Tripodi  wrote:
> Hi all guys,
>
> I am prototyping the Jackson support as described in CHAIN-76 and
> found an elegant solution with ServiceLoader to support, via Jackson,
> multiple format support without hardcoding them in the ConfigParser
> code but rather loading available parsers at runtime.
>
> Since [chain2] hasn't been published yet and my prototype would
> require an API which is not available on Java5, we have 3 options:
>
>  * using the [discovery] component
>
>  * using a backport[1] component I wrote time ago for java5 (it's ALv2)
>
>  * upgrade to java6
>
> The second option sounds to me the more reasonable since uses java
> standard APIs and is Java6 compatible, while keeping Java5 backward
> compatibility...
>
> WDYT?
> Many thanks in advance, all the best!
> -Simo
>
> [1] http://99soft.github.com/backport-spi/
>
> 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
>



-- 
-Elijah

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

Re: [chain2] ChainConfigurationException?

[Elijah Zupancic]

It should be fixed in 1366598.

Thanks,
-Elijah

On Fri, Jul 27, 2012 at 10:13 PM, Elijah Zupancic  wrote:
> Bingo. Just ran the build with the 1.6 jdk and I get the failure.
> Attempting to fix now.
>
> Thanks,
> -Elijah
>
> On Fri, Jul 27, 2012 at 7:20 PM, Elijah Zupancic  wrote:
>> Hi Simon,
>>
>> I don't know what went wrong. I've been using the Jdk 1.7 with maven 3.0.4
>> and it has been building many times for me. I must have missed something. I
>> won't be able to work on it for another couple of hours.
>>
>> As for the ChainConfigurationException, my thought was that it should be a
>> more generic exception and not limited to the configuration modules. What
>> are your thoughts?
>>
>> Thanks,
>> -Elijah
>>
>>
>> On Friday, July 27, 2012, Simone Tripodi wrote:
>>>
>>> Hi Elijah,
>>>
>>> I think something went wrong during the refactoring - when tried to
>>> recompile, the core module fails for the following reason:
>>>
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
>>> (default-compile) on project commons-chain2-core: Compilation failure
>>> [ERROR]
>>> /commons-chain/core/src/main/java/org/apache/commons/chain2/ChainConfigurationException.java:[43,8]
>>> cannot find symbol
>>> [ERROR] symbol  : constructor
>>> RuntimeException(java.lang.String,java.lang.Throwable,boolean,boolean)
>>> [ERROR] location: class java.lang.RuntimeException
>>>
>>> Moreover: shouldn't the ChainConfigurationException class be moved in
>>> the configuration APIs module?
>>>
>>> TIA!
>>> -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
>>>
>>

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

Re: [chain2] ChainConfigurationException?

[Elijah Zupancic]

Bingo. Just ran the build with the 1.6 jdk and I get the failure.
Attempting to fix now.

Thanks,
-Elijah

On Fri, Jul 27, 2012 at 7:20 PM, Elijah Zupancic  wrote:
> Hi Simon,
>
> I don't know what went wrong. I've been using the Jdk 1.7 with maven 3.0.4
> and it has been building many times for me. I must have missed something. I
> won't be able to work on it for another couple of hours.
>
> As for the ChainConfigurationException, my thought was that it should be a
> more generic exception and not limited to the configuration modules. What
> are your thoughts?
>
> Thanks,
> -Elijah
>
>
> On Friday, July 27, 2012, Simone Tripodi wrote:
>>
>> Hi Elijah,
>>
>> I think something went wrong during the refactoring - when tried to
>> recompile, the core module fails for the following reason:
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
>> (default-compile) on project commons-chain2-core: Compilation failure
>> [ERROR]
>> /commons-chain/core/src/main/java/org/apache/commons/chain2/ChainConfigurationException.java:[43,8]
>> cannot find symbol
>> [ERROR] symbol  : constructor
>> RuntimeException(java.lang.String,java.lang.Throwable,boolean,boolean)
>> [ERROR] location: class java.lang.RuntimeException
>>
>> Moreover: shouldn't the ChainConfigurationException class be moved in
>> the configuration APIs module?
>>
>> TIA!
>> -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
>>
>

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

Re: [chain2] ChainConfigurationException?

[Elijah Zupancic]

Hi Simon,

I don't know what went wrong. I've been using the Jdk 1.7 with maven 3.0.4
and it has been building many times for me. I must have missed something. I
won't be able to work on it for another couple of hours.

As for the ChainConfigurationException, my thought was that it should be a
more generic exception and not limited to the configuration modules. What
are your thoughts?

Thanks,
-Elijah

On Friday, July 27, 2012, Simone Tripodi wrote:

> Hi Elijah,
>
> I think something went wrong during the refactoring - when tried to
> recompile, the core module fails for the following reason:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
> (default-compile) on project commons-chain2-core: Compilation failure
> [ERROR]
> /commons-chain/core/src/main/java/org/apache/commons/chain2/ChainConfigurationException.java:[43,8]
> cannot find symbol
> [ERROR] symbol  : constructor
> RuntimeException(java.lang.String,java.lang.Throwable,boolean,boolean)
> [ERROR] location: class java.lang.RuntimeException
>
> Moreover: shouldn't the ChainConfigurationException class be moved in
> the configuration APIs module?
>
> TIA!
> -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: [chain2] configuration façade APIs

[Elijah Zupancic]

I didn't know that Jackson supported YAML. Wow, that sounds like a
great solution.

-Elijah

On Fri, Jul 27, 2012 at 2:08 AM, Simone Tripodi
 wrote:
> Hi all [chain2] people,
>
> looks like what we have in /trunk is good already to cut a first RC -
> anyway I would like to spur all involved people to be more "visionary"
> and do more work now :P
>
> Just to put more food for thoughts, for the configuration side: I
> would like to invite you on evaluating the Jackson[1] library wich is
> natively JSON and now supports data binding for more formats[2], XML,
> YAML and Smile included!
> Hopefully, with Jackson we could get rif of the Digester and have a
> universal underlying parser wich supports more formats... how does it
> sound? Maybe we won't need multiple config submodules anymore!
>
> About licensing, Jackson is available under ALv2.
>
> This is something that worths investigate - WDYT?
>
> all the best, have a nice day!
> -Simo
>
> [1] http://wiki.fasterxml.com/JacksonHome
> [2] http://www.cowtowncoder.com/blog/archives/2012/04/entry_472.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Fri, Jul 27, 2012 at 3:55 AM, Elijah Zupancic  wrote:
>> For this particular project I would rather take the approach of writing a
>> [configuration] based configuration and then extending [configuration]  to
>> support other formats.
>>
>> -Elijah
>>
>> On Thursday, July 26, 2012, Simone Tripodi wrote:
>>
>>> Hi Oliver,
>>>
>>> we are on the same path!!! I had the idea of realizing an "universal"
>>> parser (XML/JSON/YAML/INI) just writing XML readers adapters :)
>>>
>>> good thought!
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>> On Thu, Jul 26, 2012 at 9:37 PM, Oliver Heger
>>>  wrote:
>>> > Slightly off-topic:
>>> >
>>> > Do you think the following approach could work: Consider there is a
>>> central
>>> > component - e.g. [flatfile] in sandbox - which implements parsers for
>>> > various text-base formats like YAML, JSON, CSV, ... and a generic
>>> mechanism
>>> > for transforming the parsed data into XML SAX events. Then in theory it
>>> > would be possible that all XML-based Commons components like [digester],
>>> > [configuration], or [jelly] could directly read such formats.
>>> >
>>> > WDYT?
>>> > Oliver
>>> >
>>> > Am 26.07.2012 16:10, schrieb Simone Tripodi:
>>> >
>>> >> Good!
>>> >>
>>> >> hopefully Bruno can provide some help/advice to Elijah!
>>> >>
>>> >> Thanks,
>>> >> -Simo
>>> >>
>>> >> http://people.apache.org/~simonetripodi/
>>> >> http://simonetripodi.livejournal.com/
>>> >> http://twitter.com/simonetripodi
>>> >> http://www.99soft.org/
>>> >>
>>> >>
>>> >> On Thu, Jul 26, 2012 at 3:43 PM, Bruno P. Kinoshita
>>> >>  wrote:
>>> >>>
>>> >>> +1
>>> >>>
>>> >>> I used SnakeYaml in a project [1] that parses TAP test streams and in
>>> >>> some Jenkins plug-ins, and had a look at the source code too. It works
>>> very
>>> >>> well with the latest YAML spec and the source code is very neat and
>>> with
>>> >>> many tests.
>>> >>>
>>> >>> TestNG uses SnakeYaml for parsing YAML configuration of test suites too
>>> >>> [2].
>>> >>>
>>> >>> [1] http://www.tap4j.org
>>> >>> [2] https://github.com/cbeust/testng/blob/master/pom.xml#L124
>>> >>>
>>> >>> Bruno P. Kinoshita
>>> >>> http://kinoshita.eti.br
>>> >>> http://tupilabs.com
>>> >>>
>>> >>>> 
>>> >>>> From: Simone Tripodi 
>>> >>>> To: Commons Developers List 
>>> >>>> Sent: Thursday, 26 July 2012 4:58 AM
>>> >>>> Subject: Re: [chain2] configuration façade APIs
>>> >>>>
>>> >>>>> I may draft up

Re: [chain2] configuration façade APIs - followup

[Elijah Zupancic]

Simo,

I love ALL of those ideas. It took me quite a bit of time to get to
where we are now and I considered it a first draft that we would then
refactor from. So, yes please!

-Elijah

On Fri, Jul 27, 2012 at 4:16 AM, Simone Tripodi
 wrote:
> Hi Elijah/all,
>
> I just checked out latest modifications to see the changes - well done
> and thanks for leading that! - I have few questions:
>
>  * the main façade is a little "obscure" to me - how the parser
> returns the Catalog/Chain to Parser clients? Would it be useful adding
> a method (or modify the current parse() signature) to get the built
> object? I maybe missed something, can we clarify?
>
>  * would it be useful adding a parser factory á-la slf4j?
>
>  * what about reorganizing the configuration stuff in the following dirs:
>
> configuration
> ├── api
> ├── xml\
> ...
> └── yaml
>
> ? if you agree I can quickly take care of it, it is a matter of minutes
>
> 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
>



-- 
-Elijah

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

Re: [chain2] configuration façade APIs

[Elijah Zupancic]

For this particular project I would rather take the approach of writing a
[configuration] based configuration and then extending [configuration]  to
support other formats.

-Elijah

On Thursday, July 26, 2012, Simone Tripodi wrote:

> Hi Oliver,
>
> we are on the same path!!! I had the idea of realizing an "universal"
> parser (XML/JSON/YAML/INI) just writing XML readers adapters :)
>
> good thought!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Thu, Jul 26, 2012 at 9:37 PM, Oliver Heger
>  wrote:
> > Slightly off-topic:
> >
> > Do you think the following approach could work: Consider there is a
> central
> > component - e.g. [flatfile] in sandbox - which implements parsers for
> > various text-base formats like YAML, JSON, CSV, ... and a generic
> mechanism
> > for transforming the parsed data into XML SAX events. Then in theory it
> > would be possible that all XML-based Commons components like [digester],
> > [configuration], or [jelly] could directly read such formats.
> >
> > WDYT?
> > Oliver
> >
> > Am 26.07.2012 16:10, schrieb Simone Tripodi:
> >
> >> Good!
> >>
> >> hopefully Bruno can provide some help/advice to Elijah!
> >>
> >> Thanks,
> >> -Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://simonetripodi.livejournal.com/
> >> http://twitter.com/simonetripodi
> >> http://www.99soft.org/
> >>
> >>
> >> On Thu, Jul 26, 2012 at 3:43 PM, Bruno P. Kinoshita
> >>  wrote:
> >>>
> >>> +1
> >>>
> >>> I used SnakeYaml in a project [1] that parses TAP test streams and in
> >>> some Jenkins plug-ins, and had a look at the source code too. It works
> very
> >>> well with the latest YAML spec and the source code is very neat and
> with
> >>> many tests.
> >>>
> >>> TestNG uses SnakeYaml for parsing YAML configuration of test suites too
> >>> [2].
> >>>
> >>> [1] http://www.tap4j.org
> >>> [2] https://github.com/cbeust/testng/blob/master/pom.xml#L124
> >>>
> >>> Bruno P. Kinoshita
> >>> http://kinoshita.eti.br
> >>> http://tupilabs.com
> >>>
>  
>  From: Simone Tripodi 
>  To: Commons Developers List 
>  Sent: Thursday, 26 July 2012 4:58 AM
>  Subject: Re: [chain2] configuration façade APIs
> 
> > I may draft up a prototype using YAML as a configuration source, just
> > to make sure that it in fact is a good abstraction. I noticed that
> the
> > SnakeYaml parser is under the Apache 2.0 license
> > (http://code.google.com/p/snakeyaml/). I'm assuming that it wouldn't
> > be a problem to take it as a dependency.
> 
> 
>  +1!
> 
>  -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: [chain2] serialVersionUID

[Elijah Zupancic]

@Benedikt - This reply isn't addressed to you I just replied to your
message to continue the thread.

Wow, folks. I had no idea that the serialization id would be such a
big deal. I jumped the gun and checked in ids done in the date format
because it sounded like a good enough solution. I really don't have an
opinion on what approach that we use as long as we all agree on it.

I think that the date can work because we rarely update the ids.
Furthermore, all that matters is that a given id has been incremented
from the last id.

In the end, I will change all of the ids to whatever format that we
decide on. Do we want to have a vote or something about this?

Thanks,
-Elijah

On Thu, Jul 26, 2012 at 11:52 AM, Bruno P. Kinoshita
 wrote:
>
>
>>
>> From: Benedikt Ritter 
>>To: Commons Developers List 
>>Sent: Thursday, 26 July 2012 3:28 PM
>>Subject: Re: [chain2] serialVersionUID
>>
>>2012/7/26 sebb :
>>> On 26 July 2012 18:29, Brent Worden  wrote:
>>>> On Thu, Jul 26, 2012 at 3:48 AM, sebb  wrote:
>>>>> On 25 July 2012 07:54, Jörg Schaible  wrote:
>>>>>> sebb wrote:
>>>>>>
>>>>>>> On 24 July 2012 09:11, Jörg Schaible  
>>>>>>> wrote:
>>>>>>>> Hi Elijah,
>>>>>>>>
>>>>>>>> Elijah Zupancic wrote:
>>>>>>>>
>>>>>>>>> Thanks Jörg!
>>>>>>>>>
>>>>>>>>> It sounds like we will need to change them all in chain because we
>>>>>>>>> have changed the package name.
>>>>>>>>
>>>>>>>> Well, since they are all different objects now, the Java runtime will 
>>>>>>>> not
>>>>>>>> try to match them anyway, so it is for this special case not really
>>>>>>>> required.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>
>>>>>>>> However, if you consider a change, I'd like to propose to use 
>>>>>>>> everywhere
>>>>>>>> a constant that reflects the day of change:
>>>>>>>>
>>>>>>>> servialVersionUID = 20120724L; // format MMDD
>>>>>>>>
>>>>>>>> It's easier then to keep track of changes.
>>>>>>>
>>>>>>> +0
>>>>>>>
>>>>>>> Ideally the svuid is only changed when necessary.
>>>>>>> I don't think the id should be updated just because a new method was
>>>>>>> added, or code was updated.
>>>>>>>
>>>>>>> The danger with using the date is that maintainers may update the id
>>>>>>> whenever the source is updated.
>>>>>>
>>>>>> I did not say that.
>>>>>
>>>>> I know; but the fact that the id is a date may (mis)lead maintainers
>>>>> into updating it too often.
>>>>>
>>>>> If we do decide to use the day, maybe it should have a comment such as:
>>>>>
>>>>> // MMDD date of last change to serialized form.
>>>>>
>>>>>> - Jörg
>>>>>>
>>>>
>>>> Since the serialized form will never change without a release, the
>>>> svuid could also be aligned to the component version.
>>>
>>> Yes, but the same issue applies: it may not be necessary to change the
>>> svuid for each new version.
>>> This is particularly true of patch releases.
>>>
>>
>>I really don't see an issue here. People who have commit access know
>>what they do and their commits get reviewed by the ML. People who
>>don't have commit access will get a double review. First from the
>>person who applies a patch and then from the ML. I like Jörgs approach
>>(and I have adopted it for my work).
>>
>>Benedikt
>
> Hi all,
>
>
> I'm no specialist in Java serialization, but I have one question (that may be 
> stupid so I apologize in advance :-) about using a date as svuid.
>
>
> Say that someone from Japan (GMT +9) commits a class to [functor] using svuid 
> 20120727 at 00:30 AM. Then some 12 hours later I (based in Brazil, GMT -3) 
> find a bug in his class, modify a field or move the class to some other 
> package.
>
>
> Then I would have to update the 

Re: [chain2] configuration façade APIs

[Elijah Zupancic]

I may draft up a prototype using YAML as a configuration source, just
to make sure that it in fact is a good abstraction. I noticed that the
SnakeYaml parser is under the Apache 2.0 license
(http://code.google.com/p/snakeyaml/). I'm assuming that it wouldn't
be a problem to take it as a dependency.

Thanks,
-Elijah

On Wed, Jul 25, 2012 at 3:36 PM, Elijah Zupancic  wrote:
> Hi everyone,
>
> I've created a first draft of refactoring chain so that it uses a
> facade for configuration.
>
> Please see the diff attached to this ticket to get my proposed
> changes: https://issues.apache.org/jira/browse/CHAIN-72
>
> Here is a summary of what I have done:
>
> * Removed the module configuration
> * Created a new module called noop-configuration
> * Created a new module called xml-configuration
> * We now compile the web module against the noop-configuration with
> noop-configuration being scoped as provided in the pom.xml.
> * We check on class instantiation inside ChainServlet and ChainListner
> to validation that we have a valid configuration module present.
> * The ConfigParser class has a new constructor added called:
> ConfigParser(String ruleSet, ClassLoader loader) - this allows a
> ruleset class to be loaded by the classloader without tightly coupling
> the code against digester. Because we detect if the ruleset classname
> is specified in the servlet config and if it is we pass it to our
> constructor, otherwise we use the default constructor. Now we can
> remove the digester dependency from the web module.
>
> Comments:
>
> I still don't like how we store data in map with a classloader as a
> key. I understand that we can an implementation that has a factory per
> classloader, but this seems like a poor man's dependency injection.
>
> See:
>
> CatalogFactory.java:181 - public static >
> CatalogFactory getInstance() {
>
>
> Anyways, I would love to hear all of your thoughts regarding these changes.
>
> Thanks,
> -Elijah
>
> On Tue, Jul 24, 2012 at 12:43 PM, Oliver Heger
>  wrote:
>> Hi Simo and Elijah,
>>
>> Am 23.07.2012 21:55, schrieb Simone Tripodi:
>>
>>> Thanks a lot Oliver, much more than appreciated!
>>>
>>> If you could have a look at current configuration stuff at [chain2]
>>> and share what you think would be already *great*!
>>
>>
>> I had a look at the current config module. I understand Elijah's concerns
>> about a redesign of this package because the API indeed seems to be tightly
>> coupled to Digester.
>>
>> IMHO - and IIUC this is also the direction in which you are going - the
>> underlying library used for parsing XML configurations should not be visible
>> in the public API of the parser component. So you would have methods like
>>
>> Chain parseChain(URL url);
>> Catalog parseCatalog(URL url);
>>
>> Then the parsing library is an implementation detail and can be replaced if
>> necessary.
>>
>> One word about using [configuration]: Note that the philosophy of
>> [configuration] is pretty much different from [digester]. [digester] is able
>> - based on its rules - to parse a source file and transform it into a target
>> in-memory representation in a single step. [configuration] in contrast first
>> parses the file and creates an internal in-memory representation. Then you
>> have to evaluate this model (e.g. using XPath or a simplified syntax for
>> accessing hierarchal structures) and do the conversion yourself. So for the
>> use case of creating Chain objects from XML documents [digester] may be
>> better suited because the manual transformation step is not necessary.
>>
>> But in any case, the first step is to define the API of the configuration
>> parser. Then we can think about implementation strategies.
>>
>> Oliver
>>
>>
>>>
>>> then, feel free to put your hands and help us on defining the façade :)
>>>
>>> alles gute,
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>> On Mon, Jul 23, 2012 at 9:43 PM, Oliver Heger
>>>  wrote:
>>>>
>>>> Am 23.07.2012 09:00, schrieb Simone Tripodi:
>>>>
>>>>> Good morning all,
>>>>>
>>>>> so I continue proposing the already proposed roadmap: let's add the
>>>>> façade APIs for the [chain] configuration stuff, adapt the existing
>>>>> XML configuration reader, use the [configura

Re: [chain2] configuration façade APIs

[Elijah Zupancic]

Hi everyone,

I've created a first draft of refactoring chain so that it uses a
facade for configuration.

Please see the diff attached to this ticket to get my proposed
changes: https://issues.apache.org/jira/browse/CHAIN-72

Here is a summary of what I have done:

* Removed the module configuration
* Created a new module called noop-configuration
* Created a new module called xml-configuration
* We now compile the web module against the noop-configuration with
noop-configuration being scoped as provided in the pom.xml.
* We check on class instantiation inside ChainServlet and ChainListner
to validation that we have a valid configuration module present.
* The ConfigParser class has a new constructor added called:
ConfigParser(String ruleSet, ClassLoader loader) - this allows a
ruleset class to be loaded by the classloader without tightly coupling
the code against digester. Because we detect if the ruleset classname
is specified in the servlet config and if it is we pass it to our
constructor, otherwise we use the default constructor. Now we can
remove the digester dependency from the web module.

Comments:

I still don't like how we store data in map with a classloader as a
key. I understand that we can an implementation that has a factory per
classloader, but this seems like a poor man's dependency injection.

See:

CatalogFactory.java:181 - public static >
CatalogFactory getInstance() {


Anyways, I would love to hear all of your thoughts regarding these changes.

Thanks,
-Elijah

On Tue, Jul 24, 2012 at 12:43 PM, Oliver Heger
 wrote:
> Hi Simo and Elijah,
>
> Am 23.07.2012 21:55, schrieb Simone Tripodi:
>
>> Thanks a lot Oliver, much more than appreciated!
>>
>> If you could have a look at current configuration stuff at [chain2]
>> and share what you think would be already *great*!
>
>
> I had a look at the current config module. I understand Elijah's concerns
> about a redesign of this package because the API indeed seems to be tightly
> coupled to Digester.
>
> IMHO - and IIUC this is also the direction in which you are going - the
> underlying library used for parsing XML configurations should not be visible
> in the public API of the parser component. So you would have methods like
>
> Chain parseChain(URL url);
> Catalog parseCatalog(URL url);
>
> Then the parsing library is an implementation detail and can be replaced if
> necessary.
>
> One word about using [configuration]: Note that the philosophy of
> [configuration] is pretty much different from [digester]. [digester] is able
> - based on its rules - to parse a source file and transform it into a target
> in-memory representation in a single step. [configuration] in contrast first
> parses the file and creates an internal in-memory representation. Then you
> have to evaluate this model (e.g. using XPath or a simplified syntax for
> accessing hierarchal structures) and do the conversion yourself. So for the
> use case of creating Chain objects from XML documents [digester] may be
> better suited because the manual transformation step is not necessary.
>
> But in any case, the first step is to define the API of the configuration
> parser. Then we can think about implementation strategies.
>
> Oliver
>
>
>>
>> then, feel free to put your hands and help us on defining the façade :)
>>
>> alles gute,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Mon, Jul 23, 2012 at 9:43 PM, Oliver Heger
>>  wrote:
>>>
>>> Am 23.07.2012 09:00, schrieb Simone Tripodi:
>>>
>>>> Good morning all,
>>>>
>>>> so I continue proposing the already proposed roadmap: let's add the
>>>> façade APIs for the [chain] configuration stuff, adapt the existing
>>>> XML configuration reader, use the [configuration] in future releases
>>>> for new [chain] configurations.
>>>> How does it sound?
>>>
>>>
>>> +1
>>>
>>> If I can support you, let me know.
>>>
>>> @Elijah: There is a feature request for adding support for YAML [1].
>>> IIRC,
>>> it was planned as a Google Summer of Code project, but it did not
>>> succeed.
>>>
>>> Oliver
>>>
>>> [1] https://issues.apache.org/jira/browse/CONFIGURATION-201
>>>
>>>
>>>>
>>>> best,
>>>> -Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://

Re: [io] Problem with the FileUtils.byteCountToDisplaySize() method

[Elijah Zupancic]

Hi Ninju,

Could you describe the difference in functionality between the
stackoverflow answer and the current implementation in FileUtils? I
think that it would not be too hard to get the type of functionality
added if it was defined precisely.

Also, would you be willing to volunteer to add the code yourself? I'm
relatively new around here and I've found that the best way to get
something done is to offer to do it yourself.

Thanks,
-Elijah

On Wed, Jul 25, 2012 at 12:47 PM, Simone Tripodi
 wrote:
> Hi Ninju,
>
> welcome to Apache Commons! Usually these kind of questions should be
> sent to users@, while on dev@ we discuss about components development.
>
> Unfortunately I am not familiar with [io] so I am not in the position
> to reply your question.
>
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Wed, Jul 25, 2012 at 6:16 PM, Ninju Bohra
>  wrote:
>> Hello all,
>>
>> First time poster so please be kind.
>>
>> I need to convert a filesize to a human-readable String and I saw the method 
>> in FileUtils that I thought I could use.
>>
>> But I also searched StackOverflow.com and found the following question:
>>
>> http://stackoverflow.com/questions/3758606/how-to-convert-byte-size-into-human-readable-format-in-java
>>
>> It looks like the most popular answer appears to be more flexible and 
>> capable (esp. for European concerns) that what is currently in FileUtils.java
>>
>> What is the process for getting this behavior available to FileUtils.java, 
>> either as a new method(s) OR as an update to the existing implementation?
>>
>> Thanks,
>>
>> 
>> Ninju Bohra
>> (636) 534-5753 (desk)
>> (636) 675-0639 (cell)
>> ninju.bo...@technologypartners.co
>>
>
> -
> 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: [chain2] serialVersionUID

[Elijah Zupancic]

Thanks Jörg!

It sounds like we will need to change them all in chain because we
have changed the package name.

-Elijah

On Mon, Jul 23, 2012 at 10:51 PM, Jörg Schaible
 wrote:
> Hi Elijah
>
> Elijah Zupancic wrote:
>
>> Hi everyone,
>>
>> Now that we have changed the chain API to not be backwards compatible
>> in the 2.0 release, should we change the version number in the
>> serialVersionUID fields as well? It seems to me that would make sense,
>> but I'm a bit of a newbie when it comes to managing their versions. I
>> was wondering if anyone else has experience with regards to best
>> practices?
>
> The serialVersionUID of a class has to be changed if its binary layout
> changes:
> - the class or an inherited class has been renamed or moved to a different
> package
> - the field types of the (inherited) members have been changed or changed
> between transient/non-transient
> - the *order* of one of the (inherited) fields have been changed
> - serialization methods have
> (writeObject/readObject/writeReplace/readResolve) been added/removed in the
> class hierarchy in an incompatible way
> - the implementation of those methods have been changed in an incompatible
> way
>
> Basically, the serialVersionUID has to be changed if you cannot load a .ser
> file anymore with an instance of that class which was written with the old
> version.
>
> - Jörg
>
>
> -
> 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: [chain2] configuration façade APIs

[Elijah Zupancic]

I've been going through the chain source for about a day looking for a
way to decouple the digester configuration. Sadly, I don't think that
I will be able to do it without removing digester. I may just jump
ahead and remove [digester] completely and then move us to
[configuration] for creating dynamic chains. That said, my final
implementation may change because I haven't been able to prototype a
good solution yet.

Thanks,
-Elijah

On Mon, Jul 23, 2012 at 11:11 AM, Elijah Zupancic  wrote:
> Hi Simo,
>
> That sounds good to me. However, I'm having trouble separating the
> existing Catalog implementation from the rest of chain. Digester is
> tightly coupled across components, so it is a non-trivial refactor to
> make a configuration facade. I'm working on it, but it will take some
> time.
>
> Thanks,
> -Elijah
>
> On Mon, Jul 23, 2012 at 12:00 AM, Simone Tripodi
>  wrote:
>> Good morning all,
>>
>> so I continue proposing the already proposed roadmap: let's add the
>> façade APIs for the [chain] configuration stuff, adapt the existing
>> XML configuration reader, use the [configuration] in future releases
>> for new [chain] configurations.
>> How does it sound?
>>
>> best,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Mon, Jul 23, 2012 at 7:01 AM, Elijah Zupancic  wrote:
>>> Hi Oliver,
>>>
>>> Configuration seems like it might be useful if I end up redoing the
>>> XML configuration portion. Are there any plans to support YAML?
>>>
>>> Thanks,
>>> -Elijah
>>>
>>> On Sun, Jul 22, 2012 at 1:16 PM, Oliver Heger
>>>  wrote:
>>>> Hi Simo,
>>>>
>>>> Am 22.07.2012 17:54, schrieb Simone Tripodi:
>>>>
>>>>> Good point Oliver,
>>>>>
>>>>> I honestly didn't think about [configuration], please apologize! since
>>>>> [chain] already had a way to be configured via an XML wrapper around
>>>>> the Digester, we thought it would have been good having a façade and
>>>>> plug other textual format...
>>>>>
>>>>> Anyway, we are open to suggestions - what would fit better for you? Do
>>>>> you already have some hints to share?
>>>>>
>>>>> Many thanks in advance, all the best!
>>>>> -Simo
>>>>
>>>>
>>>> nothing concrete. I saw that you mentioned an XML configuration module, and
>>>> [configuration] contains a XMLConfiguration class. It also supports other
>>>> configuration file formats, e.g. properties or ini files which can be
>>>> accessed through the same Configuration interface.
>>>>
>>>> I don't know your concrete use cases. If you already have a working
>>>> implementation based on Digester, there is probably not much benefit in
>>>> switching to another API. But if you plan support for other configuration
>>>> file formats, [configuration] may be worth a look.
>>>>
>>>> Oliver
>>>>
>>>>
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>> On Sun, Jul 22, 2012 at 4:49 PM, Oliver Heger
>>>>>  wrote:
>>>>>>
>>>>>> Is there any relation or overlap to [configuration]?
>>>>>>
>>>>>> Depending on your concrete requirements, this is probably over-sized. But
>>>>>> maybe a source of inspiration?
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>> Am 22.07.2012 10:00, schrieb Elijah Zupancic:
>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> On Sat, Jul 21, 2012 at 11:54 PM, Simone Tripodi
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Just tracked CHAIN-72 and assigned to Elijah
>>>>>>>>
>>>>>>>> best,
>>>>>>>> -Simo
>>>>>>>>
>>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>>> http://simonetripodi.livejournal.com/
>>&g

[digester] Documentation link broken

[Elijah Zupancic]

I just notice that the link to Core APIs on the front page of the
Digester project is broken. It points to:
http://commons.apache.org/digester/commons-digester-3.0/core.html

When it probably should point to:
http://commons.apache.org/digester/guide/core.html

I can go ahead and fix this unless there are any objections.

-Elijah

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

Re: [chain2] serialVersionUID

[Elijah Zupancic]

Hi everyone,

Now that we have changed the chain API to not be backwards compatible
in the 2.0 release, should we change the version number in the
serialVersionUID fields as well? It seems to me that would make sense,
but I'm a bit of a newbie when it comes to managing their versions. I
was wondering if anyone else has experience with regards to best
practices?

Thanks,
-Elijah

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

Re: [chain2] configuration façade APIs

[Elijah Zupancic]

Hi Simo,

That sounds good to me. However, I'm having trouble separating the
existing Catalog implementation from the rest of chain. Digester is
tightly coupled across components, so it is a non-trivial refactor to
make a configuration facade. I'm working on it, but it will take some
time.

Thanks,
-Elijah

On Mon, Jul 23, 2012 at 12:00 AM, Simone Tripodi
 wrote:
> Good morning all,
>
> so I continue proposing the already proposed roadmap: let's add the
> façade APIs for the [chain] configuration stuff, adapt the existing
> XML configuration reader, use the [configuration] in future releases
> for new [chain] configurations.
> How does it sound?
>
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Mon, Jul 23, 2012 at 7:01 AM, Elijah Zupancic  wrote:
>> Hi Oliver,
>>
>> Configuration seems like it might be useful if I end up redoing the
>> XML configuration portion. Are there any plans to support YAML?
>>
>> Thanks,
>> -Elijah
>>
>> On Sun, Jul 22, 2012 at 1:16 PM, Oliver Heger
>>  wrote:
>>> Hi Simo,
>>>
>>> Am 22.07.2012 17:54, schrieb Simone Tripodi:
>>>
>>>> Good point Oliver,
>>>>
>>>> I honestly didn't think about [configuration], please apologize! since
>>>> [chain] already had a way to be configured via an XML wrapper around
>>>> the Digester, we thought it would have been good having a façade and
>>>> plug other textual format...
>>>>
>>>> Anyway, we are open to suggestions - what would fit better for you? Do
>>>> you already have some hints to share?
>>>>
>>>> Many thanks in advance, all the best!
>>>> -Simo
>>>
>>>
>>> nothing concrete. I saw that you mentioned an XML configuration module, and
>>> [configuration] contains a XMLConfiguration class. It also supports other
>>> configuration file formats, e.g. properties or ini files which can be
>>> accessed through the same Configuration interface.
>>>
>>> I don't know your concrete use cases. If you already have a working
>>> implementation based on Digester, there is probably not much benefit in
>>> switching to another API. But if you plan support for other configuration
>>> file formats, [configuration] may be worth a look.
>>>
>>> Oliver
>>>
>>>
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>>
>>>> On Sun, Jul 22, 2012 at 4:49 PM, Oliver Heger
>>>>  wrote:
>>>>>
>>>>> Is there any relation or overlap to [configuration]?
>>>>>
>>>>> Depending on your concrete requirements, this is probably over-sized. But
>>>>> maybe a source of inspiration?
>>>>>
>>>>> Oliver
>>>>>
>>>>> Am 22.07.2012 10:00, schrieb Elijah Zupancic:
>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> On Sat, Jul 21, 2012 at 11:54 PM, Simone Tripodi
>>>>>>  wrote:
>>>>>>>
>>>>>>>
>>>>>>> Just tracked CHAIN-72 and assigned to Elijah
>>>>>>>
>>>>>>> best,
>>>>>>> -Simo
>>>>>>>
>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>> http://simonetripodi.livejournal.com/
>>>>>>> http://twitter.com/simonetripodi
>>>>>>> http://www.99soft.org/
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 21, 2012 at 11:27 PM, Simone Tripodi
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi all guys,
>>>>>>>>
>>>>>>>> Elijah and and I had a chat and we thought that, since chain2 hasn't
>>>>>>>> released yet, we are still in time to define a façade API for textual
>>>>>>>> configurations and rename the current XML configuration module to
>>>>>>>> xml-configuration (and adapt it to new API) - new formats such as YAML
>>>>>>>> and JSON will be included in future releases.
>>>>>>

Re: [chain2] configuration façade APIs

[Elijah Zupancic]

Hi Oliver,

Configuration seems like it might be useful if I end up redoing the
XML configuration portion. Are there any plans to support YAML?

Thanks,
-Elijah

On Sun, Jul 22, 2012 at 1:16 PM, Oliver Heger
 wrote:
> Hi Simo,
>
> Am 22.07.2012 17:54, schrieb Simone Tripodi:
>
>> Good point Oliver,
>>
>> I honestly didn't think about [configuration], please apologize! since
>> [chain] already had a way to be configured via an XML wrapper around
>> the Digester, we thought it would have been good having a façade and
>> plug other textual format...
>>
>> Anyway, we are open to suggestions - what would fit better for you? Do
>> you already have some hints to share?
>>
>> Many thanks in advance, all the best!
>> -Simo
>
>
> nothing concrete. I saw that you mentioned an XML configuration module, and
> [configuration] contains a XMLConfiguration class. It also supports other
> configuration file formats, e.g. properties or ini files which can be
> accessed through the same Configuration interface.
>
> I don't know your concrete use cases. If you already have a working
> implementation based on Digester, there is probably not much benefit in
> switching to another API. But if you plan support for other configuration
> file formats, [configuration] may be worth a look.
>
> Oliver
>
>
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Sun, Jul 22, 2012 at 4:49 PM, Oliver Heger
>>  wrote:
>>>
>>> Is there any relation or overlap to [configuration]?
>>>
>>> Depending on your concrete requirements, this is probably over-sized. But
>>> maybe a source of inspiration?
>>>
>>> Oliver
>>>
>>> Am 22.07.2012 10:00, schrieb Elijah Zupancic:
>>>
>>>> Thanks!
>>>>
>>>> On Sat, Jul 21, 2012 at 11:54 PM, Simone Tripodi
>>>>  wrote:
>>>>>
>>>>>
>>>>> Just tracked CHAIN-72 and assigned to Elijah
>>>>>
>>>>> best,
>>>>> -Simo
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>> On Sat, Jul 21, 2012 at 11:27 PM, Simone Tripodi
>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>> Hi all guys,
>>>>>>
>>>>>> Elijah and and I had a chat and we thought that, since chain2 hasn't
>>>>>> released yet, we are still in time to define a façade API for textual
>>>>>> configurations and rename the current XML configuration module to
>>>>>> xml-configuration (and adapt it to new API) - new formats such as YAML
>>>>>> and JSON will be included in future releases.
>>>>>> Any objection?
>>>>>>
>>>>>> @Elijah: if you have cycles to dedicate to it, I think the façade can
>>>>>> be defined in a o.a.c.chain.config package in the core module, in that
>>>>>> way it should be quick enough going to the first release - WDYT?
>>>>>>
>>>>>> TIA!
>>>>>> -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
>>>>>
>>>>
>>>> -
>>>> 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
>>
>
>
> -
> 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: [chain2] configuration façade APIs

[Elijah Zupancic]

Thanks!

On Sat, Jul 21, 2012 at 11:54 PM, Simone Tripodi
 wrote:
> Just tracked CHAIN-72 and assigned to Elijah
>
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Sat, Jul 21, 2012 at 11:27 PM, Simone Tripodi
>  wrote:
>> Hi all guys,
>>
>> Elijah and and I had a chat and we thought that, since chain2 hasn't
>> released yet, we are still in time to define a façade API for textual
>> configurations and rename the current XML configuration module to
>> xml-configuration (and adapt it to new API) - new formats such as YAML
>> and JSON will be included in future releases.
>> Any objection?
>>
>> @Elijah: if you have cycles to dedicate to it, I think the façade can
>> be defined in a o.a.c.chain.config package in the core module, in that
>> way it should be quick enough going to the first release - WDYT?
>>
>> TIA!
>> -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
>

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

[BCEL] Faq update?

[Elijah Zupancic]

Hi there,

I was trying to figure out if BCEL supports java 1.7 yesterday. After
doing a few experiments, it appears that it somewhat supports it as it
is used in findbugs until I use 1.7 features. I think that we should
update the FAQ for the project. Any one here know more about this than
me?

Thanks,
-Elijah

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

Re: [chain2] dropping @Deprecated methods

[Elijah Zupancic]

I had a little time tonight to look at the deprecated methods again.
This time around, the dependencies made more sense, so I just cut a
patch that removes the deprecated methods. Please see:
https://issues.apache.org/jira/browse/CHAIN-71

Now, that I am a committer, can I go ahead and check in the changes
and mark the issue as fixed if I get the ok from everyone on the
mailing list?

Thanks,
-Elijah

On Fri, Jul 20, 2012 at 12:32 AM, Simone Tripodi
 wrote:
>> Then again on the other hand, keeping deprecated APIs across major
>> releases is not good. I'm very much undecided about this.
>>
>> -Elijah
>
> yup a major release with already deprecated methods doesn't look so good ;)
> I'll have a look as well to provide some feedbacks/toughts
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Fri, Jul 20, 2012 at 1:28 AM, Elijah Zupancic  wrote:
>
>>
>> On Thu, Jul 19, 2012 at 4:27 PM, Elijah Zupancic  wrote:
>>> Hi Simo,
>>>
>>> I've already partly investigated some of those methods. Some of them
>>> are still used by the chain code, so I didn't just go ahead and delete
>>> them. I believe they should be their own ticket. I would like to do it
>>> in a 2.0.1 release. I want to get the new functionality proven and
>>> burned in and then start to clean up the internals.
>>>
>>> -Elijah
>>>
>>> On Thu, Jul 19, 2012 at 4:44 AM, Simone Tripodi
>>>  wrote:
>>>> Hi all/Elijah,
>>>>
>>>> during my current inspection I noticed some @Deprecated methods in the
>>>> web module - since we are jumping to a major release, it would be good
>>>> IMHO dropping them
>>>>
>>>> WDYT? do you have a cycle to dedicate?
>>>> TIA,
>>>> -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
>>>>
>>
>> -
>> 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: [chain2] dropping @Deprecated methods

[Elijah Zupancic]

Then again on the other hand, keeping deprecated APIs across major
releases is not good. I'm very much undecided about this.

-Elijah

On Thu, Jul 19, 2012 at 4:27 PM, Elijah Zupancic  wrote:
> Hi Simo,
>
> I've already partly investigated some of those methods. Some of them
> are still used by the chain code, so I didn't just go ahead and delete
> them. I believe they should be their own ticket. I would like to do it
> in a 2.0.1 release. I want to get the new functionality proven and
> burned in and then start to clean up the internals.
>
> -Elijah
>
> On Thu, Jul 19, 2012 at 4:44 AM, Simone Tripodi
>  wrote:
>> Hi all/Elijah,
>>
>> during my current inspection I noticed some @Deprecated methods in the
>> web module - since we are jumping to a major release, it would be good
>> IMHO dropping them
>>
>> WDYT? do you have a cycle to dedicate?
>> TIA,
>> -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
>>

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

Re: [chain2] dropping @Deprecated methods

[Elijah Zupancic]

Hi Simo,

I've already partly investigated some of those methods. Some of them
are still used by the chain code, so I didn't just go ahead and delete
them. I believe they should be their own ticket. I would like to do it
in a 2.0.1 release. I want to get the new functionality proven and
burned in and then start to clean up the internals.

-Elijah

On Thu, Jul 19, 2012 at 4:44 AM, Simone Tripodi
 wrote:
> Hi all/Elijah,
>
> during my current inspection I noticed some @Deprecated methods in the
> web module - since we are jumping to a major release, it would be good
> IMHO dropping them
>
> WDYT? do you have a cycle to dedicate?
> TIA,
> -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
>

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

Re: [chain] javadoc tags

[Elijah Zupancic]

Great questions. I'm eager to find out what everyone thinks.

-Elijah

On Wed, Jul 18, 2012 at 1:46 PM, Simone Tripodi
 wrote:
> another question: since chain2 breaks all kind of backward
> compatibility with previous version... does it really makes sense
> keeping the @since tag?
>
> TIA!
>
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Wed, Jul 18, 2012 at 10:35 PM, Simone Tripodi
>  wrote:
>> Hello,
>>
>> we discussed already a lot on this for other components, anyway it
>> would be better discussing it before modifying the code:
>>
>>  * is it OK to drop @author tags? original authors, committers and
>> contributors are already mentioned in the pom
>>
>>  * @version: actually, there is a mix of $Id$, $Revision$ and $Date$
>> usage. Is it OK to replace all of them with $Id$ only?
>>
>> TIA! 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
>

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

Re: [VOTE] Release Apache Commons-DbUtils 1.5 based on RC1

[Elijah Zupancic]

+1

-Elijah

On Mon, Jul 16, 2012 at 6:29 AM, Bill Speirs  wrote:
> +1
>
> Bill-
>
> On Mon, Jul 16, 2012 at 8:44 AM, Simone Tripodi 
> wrote:
>
>> My own +1
>>
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Mon, Jul 16, 2012 at 2:43 PM, Simone Tripodi
>>  wrote:
>> > Hi all guys,
>> >
>> > I am opening the current [VOTE] thread to release Apache
>> > commons-dbutils-1.5 based on RC1.
>> >
>> > Release Notes:
>> >
>> >
>> http://people.apache.org/builds/commons/dbutils/1.5/RC1/RELEASE-NOTES.txt
>> >
>> > Tag:
>> >
>> >
>> https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_5_RC1/
>> >
>> > Site:
>> >
>> >
>> http://people.apache.org/builds/commons/dbutils/1.5/RC1/site/index.html
>> >
>> > Staging Maven Repository:
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapachecommons-054/
>> >
>> > Binaries:
>> >
>> > http://people.apache.org/builds/commons/dbutils/1.5/RC1/binaries/
>> >
>> > Vote will stay open for at least 72h and closes approximately on
>> > Thursday 19th at 12:40 GMT
>> > PMCs, please cast your votes:
>> >
>> > [ ] +1 release it
>> > [ ] +0 go ahead I don't care
>> > [ ] -1 no, do not release it because
>> >
>> > Many thanks in advance for taking part to the review process, 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
>>
>>

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

[chain] Next steps for release?

[Elijah Zupancic]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chain 2.0 is dev complete. As a newbie committer, I was wondering what
steps that I need to take in order to cut a release? Can anyone point
me at the right docs?

- -Elijah

-BEGIN PGP SIGNATURE-
Version: OpenPGP.js v0.1
Comment: http://openpgpjs.org

wsBcBAEBAgAQBQJQAGUOCRB5FXwxoG2zuAAAvHcH/0blBN8j1RoX9CaZUbs6
lKu3KNzOuIp7o3K67nfXKfzy0rpb9RHntyK7y+eB9RIpJbhYq+PCOAiBSkuA
elhqJNK2k2TWL0hMEyNajWx2rrdoNdn+4MyU6veVYFuAExhqES8dLE3Ba2IG
Zf8/tkWGEms6hQlJxWi96KeAEkDChsszFDJ6p1+x+SDHNpeBl3iE8Ck9MQBu
nNw9DvSpGiySpdBs7jzp2ClXYpWYK6/AyH8wywMPOVBveTZf6Fmb+kVMeF+x
BJxU/n2Vf/PRAJmsYIfEpVvh3eVTG6aApU6cmekDxJAy6Q/tiAqt0lP/VZmu
flWhjkmL9CGFE7nh0f70kBo=
=WfJ7
-END PGP SIGNATURE-

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

[chain] Checkstyle / PMD fixes are complete

[Elijah Zupancic]

I've finally completed the work on updating chain v2 to fix Checkstyle
/ PMD violations. It wasn't advisable to fix all of the issues, but I
have fixed the major ones. As a side note, I've intentionally left off
the javadocs for the example code that is used in the cookbook.

Please see the attached diff here:
https://issues.apache.org/jira/browse/CHAIN-69

On Mon, Apr 16, 2012 at 1:59 AM, Simone Tripodi
 wrote:
> Thanks a lot for the followup Elijah, that was something I was waiting for! :)
>
> I'll have a look at the issue tonight, stay tuned!
>
> Thanks and all the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Apr 16, 2012 at 3:59 AM, Elijah Zupancic  wrote:
>> I've just finished work on updating the cookbook for the generics api.
>> Please see the patch attached to the following issue:
>> https://issues.apache.org/jira/browse/CHAIN-66
>>
>> * Code examples in the cookbook have been added to the
>> apps/cookbook-examples project.
>> * I did not update the struts examples because I know nothing about struts.
>> * The example project does not build automatically as part of the main build.
>> * I did not do the conversion from the source cookbook.xml to its
>> intended output format. Although, it looks like an already converted
>> version is checked into source control.
>> * I updated the main pom so that it references the correct
>> checkstyle.xml rather than throw an error.
>> * I can't get the maven site to build, so if anyone wants to help with
>> that it will be appreciated.
>>
>> Thanks,
>> -Elijah
>>
>> -
>> 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

[chain] CHAIN-66 Finished - Cookbook updated for new generics API

[Elijah Zupancic]

I've just finished work on updating the cookbook for the generics api.
Please see the patch attached to the following issue:
https://issues.apache.org/jira/browse/CHAIN-66

* Code examples in the cookbook have been added to the
apps/cookbook-examples project.
* I did not update the struts examples because I know nothing about struts.
* The example project does not build automatically as part of the main build.
* I did not do the conversion from the source cookbook.xml to its
intended output format. Although, it looks like an already converted
version is checked into source control.
* I updated the main pom so that it references the correct
checkstyle.xml rather than throw an error.
* I can't get the maven site to build, so if anyone wants to help with
that it will be appreciated.

Thanks,
-Elijah

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

Re: [chain] Proposed patch to the Command interface

[Elijah Zupancic]

Well, this is embarrassing. The code that I'm suggesting adding exists
right below the line in my patch. I think I need a break.

Please disregard my previous message.

Thanks,
-Elijah


On Sun, Apr 15, 2012 at 5:33 PM, Elijah Zupancic  wrote:
> After working on a servlet with catalog support for the cookbook, I
> would like to suggest the following modification to the Command
> interface for better readability of implementations of the interface:
>
> Index: Command.java
> ===
> --- Command.java        (revision 1307931)
> +++ Command.java        (working copy)
> @@ -84,6 +84,10 @@
>  */
>
>  public interface Command> {
> +    /** Boolean value to return when processing is complete. */
> +    public static final boolean COMPLETE = true;
> +    /** Boolean value to return when processing is not complete. */
> +    public static final boolean INCOMPLETE = false;
>
>     /**
>      * Commands should return CONTINUE_PROCESSING if
> the processing
>
> I think that the simple addition of a named flag for complete or
> incomplete processing of the chain is more understandable than the
> current boolean value. Currently, "false" means keep processing and
> "true" means stop processing.
>
> Thanks,
> -Elijah

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

[chain] Proposed patch to the Command interface

[Elijah Zupancic]

After working on a servlet with catalog support for the cookbook, I
would like to suggest the following modification to the Command
interface for better readability of implementations of the interface:

Index: Command.java
===
--- Command.java(revision 1307931)
+++ Command.java(working copy)
@@ -84,6 +84,10 @@
  */

 public interface Command> {
+/** Boolean value to return when processing is complete. */
+public static final boolean COMPLETE = true;
+/** Boolean value to return when processing is not complete. */
+public static final boolean INCOMPLETE = false;

 /**
  * Commands should return CONTINUE_PROCESSING if
the processing

I think that the simple addition of a named flag for complete or
incomplete processing of the chain is more understandable than the
current boolean value. Currently, "false" means keep processing and
"true" means stop processing.

Thanks,
-Elijah

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

[chain] Example tests using Mockito

[Elijah Zupancic]

I'm busy updating the cookbook for the Chain project to use examples
that make use of the new 2.0 generics features. As part of the effort,
I'm adding the cookbook example code to the apps directory and making
all of the examples compilable with Maven. For most cases, this is
straight forward, however in some cases the cookbook uses isolated
examples that depend on resources beyond the scope of the example. For
these cases I would like to import Mockito as a dependency just to
have a clean way to stub out resources out of scope for the example.

Some key points regarding what I propose:

* Mockito will NOT be added as a dependency to any of the actual chain
source code (or tests).
* Mockito will be added as a dependency only to code usage examples.
* Mockito uses the MIT license.
* Mockito will be referenced as a library using Maven from the examples section.

Thanks,
-Elijah

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

Re: [VOTE] Promote [csv] to Commons proper

[Elijah Zupancic]

I'm not an committer, but I've been monitoring the CSV project for a
couple of years and I'm really happy to see it trying to emerge from
the sandbox. If it does go to release, I will be dropping OpenCsv and
switching to it for my projects both personal and professional.

Please accept my virtual +1 on going to release.

Thanks,
-Elijah

On Tue, Mar 6, 2012 at 9:42 AM, Emmanuel Bourg  wrote:
> Commons CSV is approaching a releasable state. Considering the general
> interest in this component I think it's time to promote it to Commons
> proper.
>
> There are a few points I'd like to address before a release:
> - Handle CSV headers, a CSV API looks incomplete to me without this
> - Examine the feasibility of adding a simple bean mapping feature
> - Extract the unicode unescaping feature as an implementation of
> java.io.Reader, and maybe contribute it to Commons IO
> - Improve the documentation
>
>
> [ ] +1 Promote it!
> [ ] -1 Let it crawl in the sandbox because...
>
> Emmanuel Bourg
>

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

Re: [chain] Changing from Exception to RuntimeException

[Elijah Zupancic]

I've uploaded the patch into the following Jira ticket:
https://issues.apache.org/jira/browse/CHAIN-67

Please have a look and tell me what you think.

Thanks,
-Elijah

On Sun, Mar 4, 2012 at 5:18 AM, Simone Tripodi  wrote:
> I agree with your thoughts Elijah, when an exception is thrown nothing
> can be done in the chain to rescue the error.
> looking forward next patch!
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sun, Mar 4, 2012 at 7:39 AM, James Carman  
> wrote:
>> I hate checked exceptions.  +1
>>
>> On Sat, Mar 3, 2012 at 11:07 PM, Elijah Zupancic  
>> wrote:
>>> As I've been working on the examples and the documentation for v2 of
>>> chain, I've noticed that the API for exception handling of Command and
>>> Chain is clunky.
>>>
>>> When executing a command like:
>>>
>>>        ProfileContext context = new ProfileContext();
>>>        Command command = new ProfileCheck();
>>>
>>>        try {
>>>            command.execute(context);
>>>        }
>>>        catch (Exception e) {
>>>            throw new RuntimeException(e);
>>>        }
>>>
>>> The user of chain has to explicitly catch Exception. If the desire was
>>> to catch the most base error and force the user to deal with it, why
>>> aren't we using Throwable? Anyways, this design leads to less than
>>> elegant code and since we will be breaking the API in v2, I would like
>>> to suggest a different approach.
>>>
>>> I suggest that Command and Chain should throw a custom exception class
>>> called ChainException that inherits from RuntimeException. And in the
>>> CommandBase, ChainBase we wrap the catch of Exception in this runtime
>>> exception. Moreover, we would attach to ChainException some optional
>>> debug information about the Context invoked when the exception was
>>> encountered. If anyone thinks that this is a good idea, I can whip up
>>> a patch quickly.
>>>
>>> Thanks,
>>> -Elijah
>>>
>>> -
>>> 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
>

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

[chain] Changing from Exception to RuntimeException

[Elijah Zupancic]

As I've been working on the examples and the documentation for v2 of
chain, I've noticed that the API for exception handling of Command and
Chain is clunky.

When executing a command like:

ProfileContext context = new ProfileContext();
Command command = new ProfileCheck();

try {
command.execute(context);
}
catch (Exception e) {
throw new RuntimeException(e);
}

The user of chain has to explicitly catch Exception. If the desire was
to catch the most base error and force the user to deal with it, why
aren't we using Throwable? Anyways, this design leads to less than
elegant code and since we will be breaking the API in v2, I would like
to suggest a different approach.

I suggest that Command and Chain should throw a custom exception class
called ChainException that inherits from RuntimeException. And in the
CommandBase, ChainBase we wrap the catch of Exception in this runtime
exception. Moreover, we would attach to ChainException some optional
debug information about the Context invoked when the exception was
encountered. If anyone thinks that this is a good idea, I can whip up
a patch quickly.

Thanks,
-Elijah

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

Re: [chain] release roadmap

[Elijah Zupancic]

Hi Simo,

I will take a look at the thin pom modules.

Right now, I'm working on editing the cookbook so that it contains
examples that include generics. As part of this, I want to create
another module under apps called cookbook-examples. In side of that
module, I would put the source code used in the cookbook. I'm having
to do this anyways because I need to verify that all of the examples
that I am editing in the cookbook actually work.

Thanks,
-Elijah

On Thu, Mar 1, 2012 at 11:58 PM, Simone Tripodi
 wrote:
> Hi Elijah,
>
> great! :) You can take in consideration to include samples in the
> maven reactor, so you can safety inherit the chain2 parent pom and
> avoiding repeat stuff, have a look at existing thin pom modules :P
>
> Samples will be anyway excluded from the deployment on Nexus, the
> `dist` module contains the needed maven-deploy-plugin settings.
>
> TIA for your effort and time!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Fri, Mar 2, 2012 at 7:52 AM, Elijah Zupancic  wrote:
>> Hi Simo,
>>
>> I saw the changes and they look great! Let's see if I can get you a patch
>> to get the 2.0 apps examples compiling. They are written to use Java 1.3
>> and we need to change the pom to support 1.5. I already have some source
>> changes for them, but I am not done with it.
>>
>> -Elijah
>>
>> On Thu, Mar 1, 2012 at 8:37 AM, Simone Tripodi 
>> wrote:
>>
>>> Hi Elijah,
>>>
>>> this is something needed indeed, thanks *a lot*!!!
>>>
>>> I don't know if you checked out updates, I switched to multi-module
>>> project structure, looks like it is complete and I just have to add
>>> the /apps in the modules list.
>>>
>>> Thanks for the hard work, all the best!
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Thu, Mar 1, 2012 at 5:33 PM, Elijah Zupancic 
>>> wrote:
>>> > FYI, I am also updating the examples in the /apps folder.
>>> >
>>> > -Elijah
>>> >
>>> > On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi
>>> >  wrote:
>>> >> Hi Elijah,
>>> >>
>>> >> no needs to learn docbook, the docbook page you see on svn repo is a
>>> >> donation from an old book. Deployed documentation is generated from
>>> >> /src/site/xdoc sources, the format is an html-alike [1] markup. Just
>>> >> run ``mvn site && open target/site/index.html` to see the produced
>>> >> documentation.
>>> >> HTH!
>>> >> -Simo
>>> >>
>>> >> [1] http://maven.apache.org/doxia/references/xdoc-format.html
>>> >>
>>> >> http://people.apache.org/~simonetripodi/
>>> >> http://simonetripodi.livejournal.com/
>>> >> http://twitter.com/simonetripodi
>>> >> http://www.99soft.org/
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Feb 27, 2012 at 7:32 PM, Elijah Zupancic 
>>> wrote:
>>> >>> Hi Simo,
>>> >>>
>>> >>> Here is my comment from the ticket: "My plan is to take this on. I'm
>>> >>> just very busy at work right now, so I've been trying to learn docbook
>>> >>> format on the bus on my way to and from work. If you want to take on
>>> >>> breaking chain into separate modules, that would be much appreciated."
>>> >>>
>>> >>> -Elijah
>>> >>>
>>> >>> On Mon, Feb 27, 2012 at 8:58 AM, Simone Tripodi
>>> >>>  wrote:
>>> >>>>
>>> >>>> Hi all guys!
>>> >>>>
>>> >>>> thanks to Elijah Zupancich's contributions, we now have a fresh new
>>> >>>> [chain] on trunk that uses generics. I can have (limited) spare time
>>> >>>> to dedicate to [chain] and I would like to put energies on it in order
>>> >>>> to have it released ASAP.
>>> >>>>
>>> >>>> This is my roadmap to have [chain] released in a short time:
>>> >>>>
>>> >>>>  * CHAIN-65
>>> >>>>  * CHAIN-66
>>&

Re: [chain] release roadmap

[Elijah Zupancic]

Hi Simo,

I saw the changes and they look great! Let's see if I can get you a patch
to get the 2.0 apps examples compiling. They are written to use Java 1.3
and we need to change the pom to support 1.5. I already have some source
changes for them, but I am not done with it.

-Elijah

On Thu, Mar 1, 2012 at 8:37 AM, Simone Tripodi wrote:

> Hi Elijah,
>
> this is something needed indeed, thanks *a lot*!!!
>
> I don't know if you checked out updates, I switched to multi-module
> project structure, looks like it is complete and I just have to add
> the /apps in the modules list.
>
> Thanks for the hard work, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Thu, Mar 1, 2012 at 5:33 PM, Elijah Zupancic 
> wrote:
> > FYI, I am also updating the examples in the /apps folder.
> >
> > -Elijah
> >
> > On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi
> >  wrote:
> >> Hi Elijah,
> >>
> >> no needs to learn docbook, the docbook page you see on svn repo is a
> >> donation from an old book. Deployed documentation is generated from
> >> /src/site/xdoc sources, the format is an html-alike [1] markup. Just
> >> run ``mvn site && open target/site/index.html` to see the produced
> >> documentation.
> >> HTH!
> >> -Simo
> >>
> >> [1] http://maven.apache.org/doxia/references/xdoc-format.html
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://simonetripodi.livejournal.com/
> >> http://twitter.com/simonetripodi
> >> http://www.99soft.org/
> >>
> >>
> >>
> >> On Mon, Feb 27, 2012 at 7:32 PM, Elijah Zupancic 
> wrote:
> >>> Hi Simo,
> >>>
> >>> Here is my comment from the ticket: "My plan is to take this on. I'm
> >>> just very busy at work right now, so I've been trying to learn docbook
> >>> format on the bus on my way to and from work. If you want to take on
> >>> breaking chain into separate modules, that would be much appreciated."
> >>>
> >>> -Elijah
> >>>
> >>> On Mon, Feb 27, 2012 at 8:58 AM, Simone Tripodi
> >>>  wrote:
> >>>>
> >>>> Hi all guys!
> >>>>
> >>>> thanks to Elijah Zupancich's contributions, we now have a fresh new
> >>>> [chain] on trunk that uses generics. I can have (limited) spare time
> >>>> to dedicate to [chain] and I would like to put energies on it in order
> >>>> to have it released ASAP.
> >>>>
> >>>> This is my roadmap to have [chain] released in a short time:
> >>>>
> >>>>  * CHAIN-65
> >>>>  * CHAIN-66
> >>>>  * CHAIN-55
> >>>>
> >>>> since some other issues are really old and never fixed, I'd tend to
> >>>> keep them open and move to release 2.1
> >>>>
> >>>> groupId:artifactId:version will be updated to
> >>>> org.apache.common:commons-chain2:2.0
> >>>>
> >>>> Does anyone have objections/suggestions/... ?
> >>>> 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
> >>>>
> >>>
> >>> -
> >>> 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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [chain] release roadmap

[Elijah Zupancic]

FYI, I am also updating the examples in the /apps folder.

-Elijah

On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi
 wrote:
> Hi Elijah,
>
> no needs to learn docbook, the docbook page you see on svn repo is a
> donation from an old book. Deployed documentation is generated from
> /src/site/xdoc sources, the format is an html-alike [1] markup. Just
> run ``mvn site && open target/site/index.html` to see the produced
> documentation.
> HTH!
> -Simo
>
> [1] http://maven.apache.org/doxia/references/xdoc-format.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Feb 27, 2012 at 7:32 PM, Elijah Zupancic  wrote:
>> Hi Simo,
>>
>> Here is my comment from the ticket: "My plan is to take this on. I'm
>> just very busy at work right now, so I've been trying to learn docbook
>> format on the bus on my way to and from work. If you want to take on
>> breaking chain into separate modules, that would be much appreciated."
>>
>> -Elijah
>>
>> On Mon, Feb 27, 2012 at 8:58 AM, Simone Tripodi
>>  wrote:
>>>
>>> Hi all guys!
>>>
>>> thanks to Elijah Zupancich's contributions, we now have a fresh new
>>> [chain] on trunk that uses generics. I can have (limited) spare time
>>> to dedicate to [chain] and I would like to put energies on it in order
>>> to have it released ASAP.
>>>
>>> This is my roadmap to have [chain] released in a short time:
>>>
>>>  * CHAIN-65
>>>  * CHAIN-66
>>>  * CHAIN-55
>>>
>>> since some other issues are really old and never fixed, I'd tend to
>>> keep them open and move to release 2.1
>>>
>>> groupId:artifactId:version will be updated to
>>> org.apache.common:commons-chain2:2.0
>>>
>>> Does anyone have objections/suggestions/... ?
>>> 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
>>>
>>
>> -
>> 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: [chain] release roadmap

[Elijah Zupancic]

Hi Simo,

Here is my comment from the ticket: "My plan is to take this on. I'm
just very busy at work right now, so I've been trying to learn docbook
format on the bus on my way to and from work. If you want to take on
breaking chain into separate modules, that would be much appreciated."

-Elijah

On Mon, Feb 27, 2012 at 8:58 AM, Simone Tripodi
 wrote:
>
> Hi all guys!
>
> thanks to Elijah Zupancich's contributions, we now have a fresh new
> [chain] on trunk that uses generics. I can have (limited) spare time
> to dedicate to [chain] and I would like to put energies on it in order
> to have it released ASAP.
>
> This is my roadmap to have [chain] released in a short time:
>
>  * CHAIN-65
>  * CHAIN-66
>  * CHAIN-55
>
> since some other issues are really old and never fixed, I'd tend to
> keep them open and move to release 2.1
>
> groupId:artifactId:version will be updated to
> org.apache.common:commons-chain2:2.0
>
> Does anyone have objections/suggestions/... ?
> 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
>

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

Re: [chain] towards 2.0

[Elijah Zupancic]

It looks like I'm getting a test failing with the patch, I will need some
more time to investigate.

It is one of these
tests: testDefault(org.apache.commons.chain2.config.ConfigParserTestCase):
Correct command count expected:<17> but was:<8>

This error message is associated with order dependent tests on chain.

I will post an update when I have a working fix.

-Elijah

On Tue, Feb 14, 2012 at 7:02 AM, Elijah Zupancic wrote:

> Hi Sebb and Simo,
>
> I just created an issue to represent the work for renaming the package and
> the artifact id.
> https://issues.apache.org/jira/browse/CHAIN-65
>
> In it, I have attached a potential patch for the rename. Please take a
> look and let me know if it works for you.
>
> Thanks,
> -Elijah
>
>
> On Tue, Feb 14, 2012 at 5:18 AM, Simone Tripodi 
> wrote:
>
>> Salut,
>>
>> >
>> > There's no need to update both the groupId and tthe artifactId.
>> > So long as the each unique package name relates to a unique
>> > groupId:artifactId pair, Maven should be able to resolve dependencies
>> > correctly.
>> >
>>
>> Yes it does, the issue is not technical but rather keeping coherence
>> with previous cases, indeed I mentioned past experiences with pool2
>> [1] (o.a.c:commons-pool2) and digester3 [2] (o.a.c:digester3) where we
>> agreed on updating both - what is the reason to make an exception with
>> chain?
>>
>> >
>> > Changing package name causes lots of work for downstream users.
>> >
>>
>> Yes, I agree, anyway we spoke about the plan of releasing a major
>> version of the [chain] component...
>>
>> > So are you sure that:
>> > - compatibilty has to be broken in order to support the changes that
>> > have been made?
>>
>> The main big impact is changing the Command/Chain#execute() method
>> signature supporting the Map as context, as we discussed last
>> year - since we
>>
>> > - there aren't any other pending API changes that would require
>> > another package rename for the next release?
>> >
>>
>> Do you mean components that dependes to chain?
>>
>> Just for the record, clirr report of chain2 [3] has been updated on my
>> personal space, so people can discuss about changes.
>>
>> thanks for the feedbacks,
>> -Simo
>>
>> [1] https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pom.xml
>> [2]
>> https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER3_3_0/pom.xml
>> [3] http://people.apache.org/~simonetripodi/chain2/clirr-report.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>>
>> >
>> > There's no need to update both the groupId and tthe artifactId.
>> > So long as the each unique package name relates to a unique
>> > groupId:artifactId pair, Maven should be able to resolve dependencies
>> > correctly.
>> >
>> > However it is easier to keep the artifactId in step with the package
>> name.
>> >
>> >> Any objection?
>> >
>> > Changing package name causes lots of work for downstream users.
>> >
>> > So are you sure that:
>> > - compatibilty has to be broken in order to support the changes that
>> > have been made?
>> > - there aren't any other pending API changes that would require
>> > another package rename for the next release?
>> >
>> >> TIA,
>> >> -Simo
>> >>
>> >> [1] https://issues.apache.org/jira/browse/CHAIN-58
>> >>
>> >> 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
>> >>
>> >
>> > -
>> > 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: [chain] towards 2.0

[Elijah Zupancic]

Hi Sebb and Simo,

I just created an issue to represent the work for renaming the package and
the artifact id.
https://issues.apache.org/jira/browse/CHAIN-65

In it, I have attached a potential patch for the rename. Please take a look
and let me know if it works for you.

Thanks,
-Elijah

On Tue, Feb 14, 2012 at 5:18 AM, Simone Tripodi wrote:

> Salut,
>
> >
> > There's no need to update both the groupId and tthe artifactId.
> > So long as the each unique package name relates to a unique
> > groupId:artifactId pair, Maven should be able to resolve dependencies
> > correctly.
> >
>
> Yes it does, the issue is not technical but rather keeping coherence
> with previous cases, indeed I mentioned past experiences with pool2
> [1] (o.a.c:commons-pool2) and digester3 [2] (o.a.c:digester3) where we
> agreed on updating both - what is the reason to make an exception with
> chain?
>
> >
> > Changing package name causes lots of work for downstream users.
> >
>
> Yes, I agree, anyway we spoke about the plan of releasing a major
> version of the [chain] component...
>
> > So are you sure that:
> > - compatibilty has to be broken in order to support the changes that
> > have been made?
>
> The main big impact is changing the Command/Chain#execute() method
> signature supporting the Map as context, as we discussed last
> year - since we
>
> > - there aren't any other pending API changes that would require
> > another package rename for the next release?
> >
>
> Do you mean components that dependes to chain?
>
> Just for the record, clirr report of chain2 [3] has been updated on my
> personal space, so people can discuss about changes.
>
> thanks for the feedbacks,
> -Simo
>
> [1] https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pom.xml
> [2]
> https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER3_3_0/pom.xml
> [3] http://people.apache.org/~simonetripodi/chain2/clirr-report.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
>
> >
> > There's no need to update both the groupId and tthe artifactId.
> > So long as the each unique package name relates to a unique
> > groupId:artifactId pair, Maven should be able to resolve dependencies
> > correctly.
> >
> > However it is easier to keep the artifactId in step with the package
> name.
> >
> >> Any objection?
> >
> > Changing package name causes lots of work for downstream users.
> >
> > So are you sure that:
> > - compatibilty has to be broken in order to support the changes that
> > have been made?
> > - there aren't any other pending API changes that would require
> > another package rename for the next release?
> >
> >> TIA,
> >> -Simo
> >>
> >> [1] https://issues.apache.org/jira/browse/CHAIN-58
> >>
> >> 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
> >>
> >
> > -
> > 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: Commons VFS support for Amazon S3?

[Elijah Zupancic]

I would love to help out with this if there is support from the Commons
community on integrating S3 functionality.

-Elijah
On Fri, Dec 23, 2011 at 5:23 PM, Ralph Goers wrote:

> I recall seeing S3 mentioned on the dev list a while ago, probably in
> reference to this project and whether we wanted to include it in VFS. It
> seems to be based on vfs2.  I didn't investigate to see what licenses its
> dependencies are under, but this project is now Apache licensed.
>
> Ralph
>
> On Dec 23, 2011, at 4:54 PM, Mark Fortner wrote:
>
> > Looks like there is an S3 plugin already.  I'm not sure what version of
> VFS
> > it works with, but it might do the trick.
> >
> > https://github.com/abashev/vfs-s3
> >
> > Hope this helps,
> >
> > Mark
> >
> >
> >
> >
> > On Fri, Dec 23, 2011 at 4:03 PM, Liviu Tudor 
> wrote:
> >
> >> D'oh, good point about unit testing, Gary! Hasn't crossed my mind what a
> >> problem this could be h food for thought I suppose…
> >> I'll go and talk to my team after the holiday season see if I can pull
> >> some resources towards this.
> >> Thanks for the heads-up!
> >>
> >>
> >> Liv
> >>
> >> Liviu Tudor
> >>
> >> E: liviu.tu...@gmail.com
> >> M: +44 (0)7917696626
> >> W: http://about.me/liviutudor
> >> Skype: liviutudor
> >>
> >> I'm nobody, nobody's perfect -- therefore I'm perfect!
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 23/12/2011 23:49, "Gary Gregory"  wrote:
> >>
> >>> The whole commons community is responsible for VFS but some developers
> >>> are more focused on a subset of commons. There are no plans that I
> >>> know of for S3. You are welcome to contribute a patch with a JIRA. The
> >>> tricky part is unit testing. Usually tests runs with every build but
> >>> in this case I am not sure how you can do this without mocking.
> >>>
> >>> Gary
> >>>
> >>> On Dec 23, 2011, at 18:38, Liviu Tudor  wrote:
> >>>
>  Hi everyone,
> 
> 
>  One of the projects I am to work on in the new year requires amongst
>  other
>  things storage of certain files in the Amazon S3. VFS sprang to mind
> as
>  I
>  knew from browsing the Commons repository that it provides an
>  abstraction
>  layer for dealing with file system ‹ however, it appears there is no
> S3
>  support in VFS. Are there plans to include this in a future release?
> If
>  so,
>  is there an estimated release date? And also who are the developers
>  responsible for this? I'm only asking because I'm thinking/hoping
> that I
>  might be able to convince my company to put some effort perhaps into
>  building S3 support into VFS ‹ and as such would be good to be in
> direct
>  contact with the lead developers on this if I manage to pull this off.
>  (Don't take this as a promise though, it's more of a dream I suppose
> at
>  this
>  stage :) But you don't find out till you try it so fingers crossed!)
> 
> 
> 
> 
>  Liv
> 
> 
>  Liviu Tudor
> 
>  E: liviu.tu...@gmail.com 
>  M: +44 (0)7917696626
>  W: http://about.me/liviutudor 
>  Skype: liviutudor
> 
>  I'm nobody, nobody's perfect -- therefore I'm perfect!
> 
> 
> 
> 
> 
> >>>
> >>> -
> >>> 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: [chain][v2] chain-58

[Elijah Zupancic]

G]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/config/ConfigRegisterRule.java:[101,55]
> [unchecked] unchecked conversion
> found   : org.apache.commons.chain.Command
> required: org.apache.commons.chain.Command
>
> [WARNING]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/config/ConfigRegisterRule.java:[101,43]
> [unchecked] unchecked method invocation:
> addCommand(java.lang.String,org.apache.commons.chain.Command) in
> org.apache.commons.chain.Catalog is applied to
> (java.lang.String,org.apache.commons.chain.Command)
>
> [WARNING]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/config/ConfigRegisterRule.java:[104,37]
> [unchecked] unchecked call to
> addCommand(org.apache.commons.chain.Command) as a member of the raw
> type org.apache.commons.chain.Chain
>
> [WARNING]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/servlet/ServletPathMapper.java:[61,18]
> [dep-ann] deprecated name isnt annotated with @Deprecated
>
> [WARNING]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/servlet/ServletPathMapper.java:[77,16]
> [dep-ann] deprecated name isnt annotated with @Deprecated
>
> [WARNING]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/servlet/PathInfoMapper.java:[61,18]
> [dep-ann] deprecated name isnt annotated with @Deprecated
>
> [WARNING]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/servlet/PathInfoMapper.java:[77,16]
> [dep-ann] deprecated name isnt annotated with @Deprecated
>
> HTH, have a nice day!!!
> All the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Sep 19, 2011 at 11:56 PM, Elijah Zupancic 
> wrote:
> > Hi Simo,
> >
> > Funny, I don't believe think that compiler complained at all. I will
> double
> > check soon and try some other compilers and let you know soon.
> >
> > Thanks,
> > -Elijah
> >
> > On Mon, Sep 19, 2011 at 8:12 AM, Simone Tripodi <
> simonetrip...@apache.org>wrote:
> >
> >> Hi Elijah,
> >> I had e deeper look at your patch and raw more carefully your message,
> >> I just have a BIG trouble: when changing the Context interface to
> >>
> >> public interface Context extends Map {
> >>
> >> }
> >>
> >> you can easily note that, in Command interface (just to mention one)
> >> compiler complains:
> >>
> >>"Context is a raw type. References to generic type Context
> >> should be parametrized"
> >>
> >> and we can not just ignore it... that's why I thought that adopting
> >> the signature Command> in the command
> >> interface is not nice but needed.
> >> More thoughts?
> >> Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://www.99soft.org/
> >>
> >>
> >>
> >> On Mon, Sep 19, 2011 at 10:01 AM, Simone Tripodi
> >>  wrote:
> >> > Hi Elijah!
> >> > great report, thanks for your effort! :)
> >> > I'll have a look at your patch as soon as I get a spare time slot,
> >> > I'll let you know ASAP!
> >> > Have a nice day, all the best!
> >> > Simo
> >> >
> >> > http://people.apache.org/~simonetripodi/
> >> > http://www.99soft.org/
> >> >
> >> >
> >> >
> >> > On Mon, Sep 19, 2011 at 3:52 AM, Elijah Zupancic <
> eli...@zupancic.name>
> >> wrote:
> >> >> I just submitted a patch to jira as CHAIN-58. This changes Context to
> >> >> Context.
> >> >>
> >> >> Thanks,
> >> >> -Elijah
> >> >>
> >> >> On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi <
> >> simonetrip...@apache.org>wrote:
> >> >>
> >> >>> Hi Paul!
> >> >>> yes it can be done, of course :) I'm not convinced anyway by the
> heavy
> >> >>> notation that, modifying the Context, would impact the Command and
> >> >>> Filter classes. I think it is because just a matter of taste :P
> >> >>> Feedbacks/suggestions/patches are welcome, if you want to provide a
> >> >>> solution feel free to fill an issue and attach a patch!!
> >> &

Re: [chain][v2] clever context - follow-up

[Elijah Zupancic]

Hi Simo and everyone else,

I finally got around to updating the patch to contain comments explaining
what the suppressed unchecked annotations are doing. The patch attached to
CHAIN-61, now has thsse additions. Now, chain *should* compile without
warnings.

Thanks and sorry about the wait,
-Elijah

On Thu, Oct 6, 2011 at 9:53 AM, Elijah Zupancic wrote:

> I've created a new bug: https://issues.apache.org/jira/browse/CHAIN-61 for
> dealing with compiler warnings. I want to have chain build cleanly before I
> work on the Context signature. I have just attached a patch for the compiler
> warnings. I have annotated with @SuppressWarnings and @Deprecated where
> appropriate.
>
> Thanks,
> -Elijah
>
>
> On Tue, Sep 20, 2011 at 1:22 AM, Simone Tripodi 
> wrote:
>
>> Hi Elijah,
>> by default Maven doesn't show warnings, you have to modify the pom.xml
>> in that way:
>>
>> {code}
>>
>>org.apache.maven.plugins
>>maven-compiler-plugin
>>2.1
>>
>>${maven.compile.source}
>>${maven.compile.target}
>>-Xlint:all
>>true
>>
>>
>> {code}
>>
>> If you try to run {{mvn clean compile}} to vanilla [chain] code, you
>> can already notice some warnings:
>>
>> $ mvn --version
>> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
>> Maven home: /Applications/apache-maven-3.0.3
>> Java version: 1.5.0_30, vendor: Apple Inc.
>> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
>> Default locale: en_US, platform encoding: MacRoman
>> OS name: "mac os x", version: "10.7.1", arch: "i386", family: "unix"
>>
>> 
>>
>> $ mvn clean compile
>>
>> [INFO] Compiling 63 source files to
>> /Users/simonetripodi/Documents/workspace/commons-chain/target/classes
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/impl/ContextBase.java:[633,46]
>> [unchecked] unchecked conversion
>> found   : java.util.Map.Entry
>> required: java.util.Map.Entry
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/impl/ContextBase.java:[652,76]
>> [unchecked] unchecked cast
>> found   : java.lang.Object
>> required: java.util.Map.Entry
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/impl/ContextBase.java:[779,48]
>> [unchecked] unchecked conversion
>> found   : java.util.Map.Entry
>> required: java.util.Map.Entry
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[133,58]
>> [unchecked] unchecked conversion
>> found   : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[133,11]
>> [unchecked] unchecked conversion
>> found   : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[145,60]
>> [unchecked] unchecked conversion
>> found   : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[145,11]
>> [unchecked] unchecked conversion
>> found   : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[157,66]
>> [unchecked] unchecked conversion
>> found   : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[157,11]
>> [unchecked] unchecked conversion
>> found   : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[169,60]
>> [unchecked] unchecked conversion
>> found   : java.util.Map
>> required

Re: [chain][v2] clever context - follow-up

[Elijah Zupancic]

e/commons/chain/config/ConfigRegisterRule.java:[104,37]
> [unchecked] unchecked call to
> addCommand(org.apache.commons.chain.Command) as a member of the raw
> type org.apache.commons.chain.Chain
>
> [WARNING]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/servlet/ServletPathMapper.java:[61,18]
> [dep-ann] deprecated name isnt annotated with @Deprecated
>
> [WARNING]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/servlet/ServletPathMapper.java:[77,16]
> [dep-ann] deprecated name isnt annotated with @Deprecated
>
> [WARNING]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/servlet/PathInfoMapper.java:[61,18]
> [dep-ann] deprecated name isnt annotated with @Deprecated
>
> [WARNING]
> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/servlet/PathInfoMapper.java:[77,16]
> [dep-ann] deprecated name isnt annotated with @Deprecated
>
> HTH, have a nice day!!!
> All the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Sep 19, 2011 at 11:56 PM, Elijah Zupancic 
> wrote:
> > Hi Simo,
> >
> > Funny, I don't believe think that compiler complained at all. I will
> double
> > check soon and try some other compilers and let you know soon.
> >
> > Thanks,
> > -Elijah
> >
> > On Mon, Sep 19, 2011 at 8:12 AM, Simone Tripodi <
> simonetrip...@apache.org>wrote:
> >
> >> Hi Elijah,
> >> I had e deeper look at your patch and raw more carefully your message,
> >> I just have a BIG trouble: when changing the Context interface to
> >>
> >> public interface Context extends Map {
> >>
> >> }
> >>
> >> you can easily note that, in Command interface (just to mention one)
> >> compiler complains:
> >>
> >>"Context is a raw type. References to generic type Context
> >> should be parametrized"
> >>
> >> and we can not just ignore it... that's why I thought that adopting
> >> the signature Command> in the command
> >> interface is not nice but needed.
> >> More thoughts?
> >> Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://www.99soft.org/
> >>
> >>
> >>
> >> On Mon, Sep 19, 2011 at 10:01 AM, Simone Tripodi
> >>  wrote:
> >> > Hi Elijah!
> >> > great report, thanks for your effort! :)
> >> > I'll have a look at your patch as soon as I get a spare time slot,
> >> > I'll let you know ASAP!
> >> > Have a nice day, all the best!
> >> > Simo
> >> >
> >> > http://people.apache.org/~simonetripodi/
> >> > http://www.99soft.org/
> >> >
> >> >
> >> >
> >> > On Mon, Sep 19, 2011 at 3:52 AM, Elijah Zupancic <
> eli...@zupancic.name>
> >> wrote:
> >> >> I just submitted a patch to jira as CHAIN-58. This changes Context to
> >> >> Context.
> >> >>
> >> >> Thanks,
> >> >> -Elijah
> >> >>
> >> >> On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi <
> >> simonetrip...@apache.org>wrote:
> >> >>
> >> >>> Hi Paul!
> >> >>> yes it can be done, of course :) I'm not convinced anyway by the
> heavy
> >> >>> notation that, modifying the Context, would impact the Command and
> >> >>> Filter classes. I think it is because just a matter of taste :P
> >> >>> Feedbacks/suggestions/patches are welcome, if you want to provide a
> >> >>> solution feel free to fill an issue and attach a patch!!
> >> >>> TIA, all the best!
> >> >>> Simo
> >> >>>
> >> >>> http://people.apache.org/~simonetripodi/
> >> >>> http://www.99soft.org/
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Fri, Sep 16, 2011 at 11:05 PM, Paul Benedict <
> pbened...@apache.org>
> >> >>> wrote:
> >> >>> > The basic context should be Context and then use interface
> >> >>> > composition to define other things like:
> >> >>> >
> >> >>> > public interface PropertyContext extends Context,
> >> >>> > Map
> >> 

Re: [continuum] BUILD FAILURE: Apache Commons - Commons Chain - Default Maven 2 Build Definition (Java 1.5)

[Elijah Zupancic]

I've finally got a little time to work on Chain again. Anyways, I have
logged this bug in Jira (https://issues.apache.org/jira/browse/CHAIN-60) and
uploaded a patch to fix it. In the future, I think it would it would be
helpful in unit test were randomized on each execution in order to prevent
this type of problem.

Now, I'll try to get cooking on the Chain generics signature issues.

Thanks,
-Elijah

On Thu, Sep 22, 2011 at 1:52 AM, Simone Tripodi wrote:

> tested both with java5 and java6 using mvn3... should we expect
> different results when using mvn2 to run tests?
> Many thanks in advance, have a noce day!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Sep 21, 2011 at 10:21 PM, Continuum@vmbuild
>  wrote:
> > Online report :
> http://vmbuild.apache.org/continuum/buildResult.action?buildId=12403&projectId=69
> >
> > Build statistics:
> >  State: Failed
> >  Previous State: Failed
> >  Started at: Wed 21 Sep 2011 20:20:51 +
> >  Finished at: Wed 21 Sep 2011 20:21:09 +
> >  Total time: 17s
> >  Build Trigger: Schedule
> >  Build Number: 10
> >  Exit code: 1
> >  Building machine hostname: vmbuild
> >  Operating system : Linux(unknown)
> >  Java Home version :
> >  java version "1.6.0_24"
> >  Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> >  Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
> >
> >  Builder version :
> >  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
> >  Java version: 1.6.0_24
> >  Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> >  Default locale: en_AU, platform encoding: UTF-8
> >  OS name: "linux" version: "2.6.32-31-server" arch: "amd64"
> Family: "unix"
> >
> >
> 
> > SCM Changes:
> >
> 
> > Changed: simonetripodi @ Wed 21 Sep 2011 20:00:30 +
> > Comment: [CHAIN-59] move layout dir to standard maven
> > Files changed:
> >  /commons/proper/chain/trunk/pom.xml ( 1173817 )
> >  /commons/proper/chain/trunk/src/assembly ( 1173817 )
> >  /commons/proper/chain/trunk/src/main/assembly (from
> /commons/proper/chain/trunk/src/assembly:1172686) ( 1173817 )
> >
>  
> /commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config-2.xml
> ( 1173817 )
> >
>  
> /commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config.xml
> ( 1173817 )
> >  /commons/proper/chain/trunk/src/test/resources ( 1173817 )
> >  /commons/proper/chain/trunk/src/test/resources/org ( 1173817 )
> >  /commons/proper/chain/trunk/src/test/resources/org/apache ( 1173817 )
> >  /commons/proper/chain/trunk/src/test/resources/org/apache/commons (
> 1173817 )
> >  /commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain
> ( 1173817 )
> >
>  
> /commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain/config
> ( 1173817 )
> >
>  
> /commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain/config/test-config-2.xml
> (from
> /commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config-2.xml:1172686)
> ( 1173817 )
> >
>  
> /commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain/config/test-config.xml
> (from
> /commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config.xml:1172686)
> ( 1173817 )
> >
> > Changed: simonetripodi @ Wed 21 Sep 2011 20:02:11 +
> > Comment: parent reference updated to version 22
> > Files changed:
> >  /commons/proper/chain/trunk/pom.xml ( 1173818 )
> >
> > Changed: simonetripodi @ Wed 21 Sep 2011 20:03:47 +
> > Comment: added missing release metadata
> > Files changed:
> >  /commons/proper/chain/trunk/pom.xml ( 1173819 )
> >
> > Changed: simonetripodi @ Wed 21 Sep 2011 20:05:35 +
> > Comment: 4 spaces replaced with 2 spaces, as generally adopted in commons
> > Files changed:
> >  /commons/proper/chain/trunk/pom.xml ( 1173821 )
> >
> >
> 
> > Dependencies Changes:
> >
> 
> > No dependencies changed
> >
> >
> >
> 
> > Build Definition:
> >
> 
> > POM filename: pom.xml
> > Goals: clean deploy
> > Arguments: --batch-mode -Pjava-1.5
> > Build Fresh: false
> > Always Build: false
> > Default Build Definition: true
> > Schedule: COMMONS_SCHEDULE
> > Profile Name: Maven 2.2.1
> > Description: Default Maven 2 Build Definition (Java 1.5)
> >
> >
> 
> > Test Summary:
> >
> 
> > Tests: 125
> > Failure

Re: [continuum] BUILD FAILURE: Apache Commons - Commons Chain - Default Maven 2 Build Definition (Java 1.5)

[Elijah Zupancic]

Ha! This was the exact error that I reported back in early August. I was
tearing my hair out trying to figure out why it only happened on my laptop
and not on any other machine. I'm so glad you found this. What exactly did
you configure differently to make this happen? On my laptop, if I ran the
tests in debug mode, this error would not occur, but it would occur in
non-debug mode.

-Elijah

On Thu, Sep 22, 2011 at 1:52 AM, Simone Tripodi wrote:

> tested both with java5 and java6 using mvn3... should we expect
> different results when using mvn2 to run tests?
> Many thanks in advance, have a noce day!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Sep 21, 2011 at 10:21 PM, Continuum@vmbuild
>  wrote:
> > Online report :
> http://vmbuild.apache.org/continuum/buildResult.action?buildId=12403&projectId=69
> >
> > Build statistics:
> >  State: Failed
> >  Previous State: Failed
> >  Started at: Wed 21 Sep 2011 20:20:51 +
> >  Finished at: Wed 21 Sep 2011 20:21:09 +
> >  Total time: 17s
> >  Build Trigger: Schedule
> >  Build Number: 10
> >  Exit code: 1
> >  Building machine hostname: vmbuild
> >  Operating system : Linux(unknown)
> >  Java Home version :
> >  java version "1.6.0_24"
> >  Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> >  Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
> >
> >  Builder version :
> >  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
> >  Java version: 1.6.0_24
> >  Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> >  Default locale: en_AU, platform encoding: UTF-8
> >  OS name: "linux" version: "2.6.32-31-server" arch: "amd64"
> Family: "unix"
> >
> >
> 
> > SCM Changes:
> >
> 
> > Changed: simonetripodi @ Wed 21 Sep 2011 20:00:30 +
> > Comment: [CHAIN-59] move layout dir to standard maven
> > Files changed:
> >  /commons/proper/chain/trunk/pom.xml ( 1173817 )
> >  /commons/proper/chain/trunk/src/assembly ( 1173817 )
> >  /commons/proper/chain/trunk/src/main/assembly (from
> /commons/proper/chain/trunk/src/assembly:1172686) ( 1173817 )
> >
>  
> /commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config-2.xml
> ( 1173817 )
> >
>  
> /commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config.xml
> ( 1173817 )
> >  /commons/proper/chain/trunk/src/test/resources ( 1173817 )
> >  /commons/proper/chain/trunk/src/test/resources/org ( 1173817 )
> >  /commons/proper/chain/trunk/src/test/resources/org/apache ( 1173817 )
> >  /commons/proper/chain/trunk/src/test/resources/org/apache/commons (
> 1173817 )
> >  /commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain
> ( 1173817 )
> >
>  
> /commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain/config
> ( 1173817 )
> >
>  
> /commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain/config/test-config-2.xml
> (from
> /commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config-2.xml:1172686)
> ( 1173817 )
> >
>  
> /commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain/config/test-config.xml
> (from
> /commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config.xml:1172686)
> ( 1173817 )
> >
> > Changed: simonetripodi @ Wed 21 Sep 2011 20:02:11 +
> > Comment: parent reference updated to version 22
> > Files changed:
> >  /commons/proper/chain/trunk/pom.xml ( 1173818 )
> >
> > Changed: simonetripodi @ Wed 21 Sep 2011 20:03:47 +
> > Comment: added missing release metadata
> > Files changed:
> >  /commons/proper/chain/trunk/pom.xml ( 1173819 )
> >
> > Changed: simonetripodi @ Wed 21 Sep 2011 20:05:35 +
> > Comment: 4 spaces replaced with 2 spaces, as generally adopted in commons
> > Files changed:
> >  /commons/proper/chain/trunk/pom.xml ( 1173821 )
> >
> >
> 
> > Dependencies Changes:
> >
> 
> > No dependencies changed
> >
> >
> >
> 
> > Build Definition:
> >
> 
> > POM filename: pom.xml
> > Goals: clean deploy
> > Arguments: --batch-mode -Pjava-1.5
> > Build Fresh: false
> > Always Build: false
> > Default Build Definition: true
> > Schedule: COMMONS_SCHEDULE
> > Profile Name: Maven 2.2.1
> > Description: Default Maven 2 Build Definition (Java 1.5)
> >
> >
> 
> > Test Summary:
> >
> 
> > Tests: 125
> > Failures: 1
> > Er

Re: [chain][v2] clever context - follow-up

[Elijah Zupancic]

Hi Simo,

Funny, I don't believe think that compiler complained at all. I will double
check soon and try some other compilers and let you know soon.

Thanks,
-Elijah

On Mon, Sep 19, 2011 at 8:12 AM, Simone Tripodi wrote:

> Hi Elijah,
> I had e deeper look at your patch and raw more carefully your message,
> I just have a BIG trouble: when changing the Context interface to
>
> public interface Context extends Map {
>
> }
>
> you can easily note that, in Command interface (just to mention one)
> compiler complains:
>
>"Context is a raw type. References to generic type Context
> should be parametrized"
>
> and we can not just ignore it... that's why I thought that adopting
> the signature Command> in the command
> interface is not nice but needed.
> More thoughts?
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Sep 19, 2011 at 10:01 AM, Simone Tripodi
>  wrote:
> > Hi Elijah!
> > great report, thanks for your effort! :)
> > I'll have a look at your patch as soon as I get a spare time slot,
> > I'll let you know ASAP!
> > Have a nice day, all the best!
> > Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://www.99soft.org/
> >
> >
> >
> > On Mon, Sep 19, 2011 at 3:52 AM, Elijah Zupancic 
> wrote:
> >> I just submitted a patch to jira as CHAIN-58. This changes Context to
> >> Context.
> >>
> >> Thanks,
> >> -Elijah
> >>
> >> On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi <
> simonetrip...@apache.org>wrote:
> >>
> >>> Hi Paul!
> >>> yes it can be done, of course :) I'm not convinced anyway by the heavy
> >>> notation that, modifying the Context, would impact the Command and
> >>> Filter classes. I think it is because just a matter of taste :P
> >>> Feedbacks/suggestions/patches are welcome, if you want to provide a
> >>> solution feel free to fill an issue and attach a patch!!
> >>> TIA, all the best!
> >>> Simo
> >>>
> >>> http://people.apache.org/~simonetripodi/
> >>> http://www.99soft.org/
> >>>
> >>>
> >>>
> >>> On Fri, Sep 16, 2011 at 11:05 PM, Paul Benedict 
> >>> wrote:
> >>> > The basic context should be Context and then use interface
> >>> > composition to define other things like:
> >>> >
> >>> > public interface PropertyContext extends Context,
> >>> > Map
> >>> >
> >>> > It can be done... I think :-)
> >>> >
> >>> > Paul
> >>> >
> >>> > On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
> >>> >  wrote:
> >>> >> Hi Elijah,
> >>> >> I spent some spare time trying to figure out how to improve the
> >>> >> Context design, I didn't have a lot of success anyway :(
> >>> >>
> >>> >>  * dropping the Map inheritance makes not easy maintaining the
> classes
> >>> >> in the 'generic' package;
> >>> >>  * adding generics in the Context to specify K,V types, makes all
> the
> >>> >> rest of the notation not so nice (IMHO), take a look as a sample a
> >>> >> Command> :?
> >>> >>
> >>> >> Do you have more ideas?
> >>> >> Many thanks in advance, all the best!
> >>> >> Simo
> >>> >>
> >>> >> http://people.apache.org/~simonetripodi/
> >>> >> http://www.99soft.org/
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Wed, Sep 14, 2011 at 4:12 AM, Elijah Zupancic <
> eli...@zupancic.name>
> >>> wrote:
> >>> >>> Hi Everyone,
> >>> >>>
> >>> >>> I don't have any votes as I'm not a commiter, but I would still
> like to
> >>> add
> >>> >>> in my suggestion.
> >>> >>>
> >>> >>> After our previous exchange, I'm of the mind that we should use the
> >>> second
> >>> >>> option - that is be collection agnostic and work by composition. I
> may
> >>> be
> >>> >>> biased towards defined getters and setters, but I really like to be
> >>> able to
> >&

Re: [chain][v2] clever context - follow-up

[Elijah Zupancic]

I just submitted a patch to jira as CHAIN-58. This changes Context to
Context.

Thanks,
-Elijah

On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi wrote:

> Hi Paul!
> yes it can be done, of course :) I'm not convinced anyway by the heavy
> notation that, modifying the Context, would impact the Command and
> Filter classes. I think it is because just a matter of taste :P
> Feedbacks/suggestions/patches are welcome, if you want to provide a
> solution feel free to fill an issue and attach a patch!!
> TIA, all the best!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 16, 2011 at 11:05 PM, Paul Benedict 
> wrote:
> > The basic context should be Context and then use interface
> > composition to define other things like:
> >
> > public interface PropertyContext extends Context,
> > Map
> >
> > It can be done... I think :-)
> >
> > Paul
> >
> > On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
> >  wrote:
> >> Hi Elijah,
> >> I spent some spare time trying to figure out how to improve the
> >> Context design, I didn't have a lot of success anyway :(
> >>
> >>  * dropping the Map inheritance makes not easy maintaining the classes
> >> in the 'generic' package;
> >>  * adding generics in the Context to specify K,V types, makes all the
> >> rest of the notation not so nice (IMHO), take a look as a sample a
> >> Command> :?
> >>
> >> Do you have more ideas?
> >> Many thanks in advance, all the best!
> >> Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://www.99soft.org/
> >>
> >>
> >>
> >> On Wed, Sep 14, 2011 at 4:12 AM, Elijah Zupancic 
> wrote:
> >>> Hi Everyone,
> >>>
> >>> I don't have any votes as I'm not a commiter, but I would still like to
> add
> >>> in my suggestion.
> >>>
> >>> After our previous exchange, I'm of the mind that we should use the
> second
> >>> option - that is be collection agnostic and work by composition. I may
> be
> >>> biased towards defined getters and setters, but I really like to be
> able to
> >>> use auto-complete, automatic code refactoring tools and static code
> analysis
> >>> tools. If we used only a Map, then the contract for a context becomes a
> >>> black box of anything. I like the way it is now where you have to
> implement
> >>> a Map on your context or extend ContextBase. I may be biased out of
> habit -
> >>> if so, please convince me (by proxy everyone else).
> >>>
> >>> Thanks,
> >>> -Elijah
> >>>
> >>> On Mon, Sep 12, 2011 at 12:04 AM, Simone Tripodi
> >>> wrote:
> >>>
> >>>> Hi all guys,
> >>>> after mails and mails of discussions, I don't think there is a general
> >>>> agreement on how Context API should look alike.
> >>>> At the end of the discussions I figured out that, briefly resuming, we
> >>>> have following proposals:
> >>>>
> >>>>  * be replaced by Map;
> >>>>  * be Collection agnostic and work by composition.
> >>>>
> >>>> Please add what is missing and correct what is wrong; we need to find
> >>>> a general agreement before to continue working toward the 2.0 release
> >>>> :)
> >>>>
> >>>> TIA, all the best!!!
> >>>> Simo
> >>>>
> >>>> http://people.apache.org/~simonetripodi/
> >>>> http://www.99soft.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
> >>
> >>
> >
> > -
> > 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: [chain][v2] clever context - follow-up

[Elijah Zupancic]

Hi Simo,

Sorry I was late replying. I've been away at a wedding.

Honestly, I'm not a big fan of Command>. I
agree with you that the it is syntactically clunky. Moreover, I'm not
convinced that the Context design needs to be improved other than the
addition of generics. It is a simple tool that does a simple thing. A
Context allows you to pass state to commands so that a command is always
stateless.

Here are some things that I like about the current context implementation
with Generics.

For example, if we have the following classes:

public class RoomContext extends HashMap implements Context
{
public static final String HOUSE_NUMBER_KEY = "houseNumber";

public RoomContext() {}

public RoomContext(Map map) {
   super(map);
}

public Integer getHouseNumber() {
 return get(HOUSE_NUMBER_KEY);
}

public void setHouseNumber(Integer houseNumber) {
 put(HOUSE_NUMBER_KEY,
}
}

public class KitchenContext extends RoomContext {
public KitchenContext() {}

public KitchenContext(Map map) {
   super(map);
}

public static final String STOVE_NAME_KEY = "stoveName";

public String getStoveName() {
return get(STOVE_NAME_KEY);
}

public void setStoveName(String name) {
put(STOVE_NAME_KEY, name);
}

}

public class BedroomContext extends RoomContext {
public BedroomContext() {}

public BedroomContext(Map map) {
   super(map);
}

public static final String BED_COLOR_KEY = "bedColor";

public String getBedColor() {
 return get(BED_COLOR_KEY);
}

public void setBedColor(String color)
 // Excuse the American spelling ;)
 put(BED_COLOR_KEY, color);
}
}

One of the nice things that I can do is this.

KitchenContext kitchen = getInstanceFromSomewhere();
BedroomContext bedroom = new BedroomContext(kitchen);

This would allow me to prepopulate a bedroom object with the relevant house
values and other values from kitchen that I might want to use in subclasses.
That said, sure - you could shoot yourself in the foot with this pattern
(just like any others). Nonetheless, I've used this type of
state inheritance in a number of sequential data processing scenarios and as
long as I only access the getters and setters in the Command class
everything is quite testable and it has a clear to understand contract.
Basically, this is an argument to leave Context inheriting from Map.

Then when the Command is defined as so:

public class RecordHouseNumber implements Command {
boolean execute(HouseContext context) throws Exception {
DataSourceOfSomeKind datasource =
SomeExternalResource.getDataSource();

datasource.storeHouseNumber(context.getHouseNumber());
}
}

I don't need to do any casting or any trickery to use beans from a context.
Also, I can just use the context in the class hierarchy that implements the
least amount of functionality needed for a given Command.

Excuse my rambling, but let's return to: Command>

I believe this is unnecessary because if we leave Command defined without
the K,V generic types like so:

public interface Command {
public static final boolean CONTINUE_PROCESSING = false;
public static final boolean PROCESSING_COMPLETE = true;

boolean execute(C context) throws Exception;
}

Then we can still access the context's generic methods when we use a command
that implements generics, like so:

public class FooContext extends HashMap implements
Context {

public  T retrieve(String K) {
return (T)get(K);
}

}

public class FooCommand implements Command {

public boolean execute(FooContext context) throws Exception {
Set> entrySet =  context.entrySet();

// do something

return true;
}
}

So, as I see it Command> is unneeded.

I will draft a patch that shows, how I would suggest the API to look with
Context instead of Context

Ok. I've talked too much. I hope I was able to communicate my ideas clearly.

Thank you,
-Elijah

On Fri, Sep 16, 2011 at 1:40 PM, Simone Tripodi wrote:

> Hi Elijah,
> I spent some spare time trying to figure out how to improve the
> Context design, I didn't have a lot of success anyway :(
>
>  * dropping the Map inheritance makes not easy maintaining the classes
> in the 'generic' package;
>  * adding generics in the Context to specify K,V types, makes all the
> rest of the notation not so nice (IMHO), take a look as a sample a
> Command> :?
>
> Do you have more ideas?
> Many thanks in advance, all the best!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Sep 14, 2011 at 4:12 AM, Elijah Zupancic 
> wrote:
> > Hi Everyone,
> >
> > I don't have any votes as I'm not a commiter, but I would still like to
> add
> >

Re: [chain][v2] clever context - follow-up

[Elijah Zupancic]

Hi Everyone,

I don't have any votes as I'm not a commiter, but I would still like to add
in my suggestion.

After our previous exchange, I'm of the mind that we should use the second
option - that is be collection agnostic and work by composition. I may be
biased towards defined getters and setters, but I really like to be able to
use auto-complete, automatic code refactoring tools and static code analysis
tools. If we used only a Map, then the contract for a context becomes a
black box of anything. I like the way it is now where you have to implement
a Map on your context or extend ContextBase. I may be biased out of habit -
if so, please convince me (by proxy everyone else).

Thanks,
-Elijah

On Mon, Sep 12, 2011 at 12:04 AM, Simone Tripodi
wrote:

> Hi all guys,
> after mails and mails of discussions, I don't think there is a general
> agreement on how Context API should look alike.
> At the end of the discussions I figured out that, briefly resuming, we
> have following proposals:
>
>  * be replaced by Map;
>  * be Collection agnostic and work by composition.
>
> Please add what is missing and correct what is wrong; we need to find
> a general agreement before to continue working toward the 2.0 release
> :)
>
> TIA, all the best!!!
> Simo
>
> http://people.apache.org/~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: [chain][v2] clever context

[Elijah Zupancic]

Specifying Object for V would be the most likely use case.

On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict  wrote:
> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi  
> wrote:
>> Hi Paul,
>> the use of that method is to automatically infer the assigned type,
>> instead of writing
>>
>>    MyPojo myPojo = (MyPojo) context.get( "myKey" );
>>
>> the retrieve method allows to
>>
>>    MyPojo myPojo = context.retrieve( "myKey" );
>>
>
> Hmm... The inference should be automatic unless you specified Object for type 
> V:
> Context properties = new ContextBase();
> String value = properties.retrieve("myKey");
>
> Paul
>
> -
> 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: [chain][v2] clever context

[Elijah Zupancic]

Paul,

You may be right. Which one is more idiomatic?

Thanks,
-Elijah

On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict  wrote:
> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic  wrote:
>> Thanks for your comments Nail.
>>
>> I think that I've come around to see your point after sleeping on it.
>> What do you think about this:
>>
>> Context.java - would be defined as so:
>>
>> public interface Context extends Map> V>
>
> Isn't that identical to?
> public interface Context extends Map
>
>> Then ContextBase.java would be defined like so:
>>
>> public class ContextBase extends ConcurrentHashMap
>>                implements Context {
>
> Paul
>
> -
> 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: [chain][v2] clever context

[Elijah Zupancic]

Thanks for your comments Nail.

I think that I've come around to see your point after sleeping on it.
What do you think about this:

Context.java - would be defined as so:

public interface Context extends Map

Then ContextBase.java would be defined like so:

public class ContextBase extends ConcurrentHashMap
implements Context {

Or we could change String to CharSequence (but I will leave that for
another discussion).

@Simo - would this negatively affect the retrieve methods that you wrote?

Thanks,
-Elijah

On Thu, Sep 8, 2011 at 5:39 PM, Niall Pemberton
 wrote:
> On Fri, Sep 9, 2011 at 12:25 AM, Elijah Zupancic  wrote:
>> Hi Niall,
>>
>> The source of the misunderstanding regarding the usage of chain may be
>> my fault. Thank you very much for piping up and letting us know some
>> of the history regarding the chain project.
>>
>> I was under the assumption that all keys of a Context were String
>> because in ContextBase in the initialization method we have:
>>
>>        // Retrieve the set of property descriptors for this Context class
>>        try {
>>            pd = Introspector.getBeanInfo
>>                (getClass()).getPropertyDescriptors();
>>        } catch (IntrospectionException e) {
>>            pd = new PropertyDescriptor[0]; // Should never happen
>>        }
>>
>>        // Initialize the underlying Map contents
>>        for (int i = 0; i < pd.length; i++) {
>>            String name = pd[i].getName();
>>
>>            // Add descriptor (ignoring getClass() and isEmpty())
>>            if (!("class".equals(name) || "empty".equals(name))) {
>>                if (descriptors == null) {
>>                    descriptors = new HashMap> PropertyDescriptor>((pd.length - 2));
>>                }
>>                descriptors.put(name, pd[i]);
>>                super.put(name, singleton);
>>            }
>>        }
>>
>> When you look at the method signature on FeatureDesriptor for
>> getName() for the following call:
>>
>> String name = pd[i].getName();
>>
>> you will see that the only acceptable choice is a string. Thus, if you
>> are subclassing ContextBase, you have to use Strings as keys in order
>> to make the BeanUtils glue work or you have to have a beanless
>> context.
>
> Yes that is certainly true with the ContextBase implementation and the
> use-case (Struts) that drove the development of Chain wanted exactly
> that - a typed bean that could be treated as a Map.
>
> http://svn.apache.org/repos/asf/struts/struts1/trunk/core/src/main/java/org/apache/struts/chain/contexts/
>
> From memory (its been a while since I committed on Struts), Struts
> only ever accessed its context through the bean properties and not
> through the Map API. However Chain's contract never limited it to that
> use-case, just provided the ContextBase implementation to make it
> easy.
>
>> I'm of the opinion that standardizing on String or > CharSequence> as the generic key for Context will make using Context
>> far more usable. Otherwise, if you use a non-string key, you will be
>> fighting many parts of the API that assume a String key.
>
> I would agree it makes it more useable where someone wants to define
> their context as a bean with strongly typed properties. But you're
> putting a limit on the API that isn't there and I can't think of a
> single benefit that this brings. If someone chooses to use
> ContextBase, then fine they accept that limitation. I don't see how
> you believe it will be more useable - seems the opposite to me if I
> can no longer do something that I used to be able to. I also don't
> understand the comment about " fighting many parts of the API" - it
> seems to me that outside of ContextBase it has no impact.
>
> Niall
>
>> Also, what made me assume that the contract was for String-only keys
>> was the fact that the test cases only use String keys (that is unless
>> my memory is failing me).
>>
>> Thanks,
>> -Elijah
>>
>> On Thu, Sep 8, 2011 at 1:53 PM, Niall Pemberton
>>  wrote:
>>> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi  
>>> wrote:
>>>> Hi Niall,
>>>> thanks for the hint!
>>>>
>>>> Anyway (DISCLAIMER: I'm putting in the original chain author's shoes,
>>>> so I couldn't say the truth) I immagine that users would be interested
>>>> on having, as a Context, not just a place where storing computed
>>>> element to be shared between chain commands, but having also th

Re: [chain][v2] clever context

[Elijah Zupancic]

Hi Niall,

The source of the misunderstanding regarding the usage of chain may be
my fault. Thank you very much for piping up and letting us know some
of the history regarding the chain project.

I was under the assumption that all keys of a Context were String
because in ContextBase in the initialization method we have:

// Retrieve the set of property descriptors for this Context class
try {
pd = Introspector.getBeanInfo
(getClass()).getPropertyDescriptors();
} catch (IntrospectionException e) {
pd = new PropertyDescriptor[0]; // Should never happen
}

// Initialize the underlying Map contents
for (int i = 0; i < pd.length; i++) {
String name = pd[i].getName();

// Add descriptor (ignoring getClass() and isEmpty())
if (!("class".equals(name) || "empty".equals(name))) {
if (descriptors == null) {
descriptors = new HashMap((pd.length - 2));
}
descriptors.put(name, pd[i]);
super.put(name, singleton);
}
}

When you look at the method signature on FeatureDesriptor for
getName() for the following call:

String name = pd[i].getName();

you will see that the only acceptable choice is a string. Thus, if you
are subclassing ContextBase, you have to use Strings as keys in order
to make the BeanUtils glue work or you have to have a beanless
context.

I'm of the opinion that standardizing on String or  as the generic key for Context will make using Context
far more usable. Otherwise, if you use a non-string key, you will be
fighting many parts of the API that assume a String key.

Also, what made me assume that the contract was for String-only keys
was the fact that the test cases only use String keys (that is unless
my memory is failing me).

Thanks,
-Elijah

On Thu, Sep 8, 2011 at 1:53 PM, Niall Pemberton
 wrote:
> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi  
> wrote:
>> Hi Niall,
>> thanks for the hint!
>>
>> Anyway (DISCLAIMER: I'm putting in the original chain author's shoes,
>> so I couldn't say the truth) I immagine that users would be interested
>> on having, as a Context, not just a place where storing computed
>> element to be shared between chain commands, but having also the
>> possibility of customizations adding, for example, shared clever
>> methods - take a look at the concrete default
>> {{org.apache.commons.chain.impl.ContextBase}} implementation where
>> there is an index of PropertiesDescriptors.
>
> I understand what Chain does - I was the last active Chain committer.
> I was also around when it was developed for Struts.
>
> You miss the point I make though. Context is currently an interface
> that extends the Map interface - it adds nothing, zilch, nada, rien to
> the Map interface
>
> public interface Context extends Map {
> }
>
> So the only thing having "Context" does is it prevents use of any
> standard Map implementation. It doesn't prevent any fancy or clever
> implementations you want to create - but just restricts what you can
> pass through the Chain.
>
> Also I just looked at your changes to the Context definition and
> you're now adding a second restriction - that the keys to the Context
> have to now be a String. Thats great for people who effectively want a
> property name - but its a new limitation for those that don't and I
> don't see any benefit to that limitation.
>
> Niall
>
>
>> Honestly thinking, after raw your message, I'd tend to agree that
>> Map would be more than enough - just for the record,
>> that's what we deed indeed in the Apache Cocoon3 Pipeline APIs - but
>> at the same time I like the idea of having dedicated Chain API as
>> shown in the current implementation.
>>
>> Hard to take a decision...
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Tue, Sep 6, 2011 at 2:19 AM, Niall Pemberton
>>  wrote:
>>> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
>>>  wrote:
 I agree with Paul here.  Extending Map (or any other class for that
 matter) when what you really want to do is encapsulate it is silly.
 Is the Context really meant to be used in any place where a Map can be
 used?  I would think not.
>>>
>>> I always thought the other way. I never understood why context wasn't
>>> just a Map, rather than a new Chain specific type extending Map.
>>>
>>> Using Map has its advantages. Firstly the contract it provides besides
>>> get/put are useful operations on the context (containsKey(), size(),
>>> entrySet() etc.etc) , secondly (if it was a "plain" Map) there are
>>> standard implementations & wrappers that can be used giving features
>>> such as concurrency, ready-only etc. and thirdly tools & libraries
>>> understand how to operate on a Map.
>>>
>>> Niall
>>>
 On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict  
 wrote:
> I want to get rid of it extending map. Have it defi

Re: [chain][v2] clever context

[Elijah Zupancic]

As a user of chain in a number of projects over the years, I've found
that the combination of extending Map and defining your own getter /
setter properties on the context to be ideal. With your own getters
and setters, you get better code completion and you have a more
old-fashioned entity object. With regards to extending Map, the nice
thing about it is that you can digest the contents of other contexts
easily. I can just take another context with a different signature and
do a .putAll and now I have all of its properties auto-magically -
even if not all of the getters / setters are present. This actually
saves time in projects - especially when dealing with large entity
(Context) objects with a lot of overlapping properties.

I'm all for having a asMap() method that externalizes map from the
Context implementation as long as we keep the ability to consume other
Contexts as a data source for population.

Thanks,
-Elijah

@Niall, sorry this isn't really a reply to what you wrote. I just
wanted to jump on the thread somewhere.

On Mon, Sep 5, 2011 at 5:19 PM, Niall Pemberton
 wrote:
> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
>  wrote:
>> I agree with Paul here.  Extending Map (or any other class for that
>> matter) when what you really want to do is encapsulate it is silly.
>> Is the Context really meant to be used in any place where a Map can be
>> used?  I would think not.
>
> I always thought the other way. I never understood why context wasn't
> just a Map, rather than a new Chain specific type extending Map.
>
> Using Map has its advantages. Firstly the contract it provides besides
> get/put are useful operations on the context (containsKey(), size(),
> entrySet() etc.etc) , secondly (if it was a "plain" Map) there are
> standard implementations & wrappers that can be used giving features
> such as concurrency, ready-only etc. and thirdly tools & libraries
> understand how to operate on a Map.
>
> Niall
>
>> On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict  wrote:
>>> I want to get rid of it extending map. Have it define as asMap()
>>> function instead. Especially since JDK 8 is bringing in extension
>>> methods, which adds new (and default) methods to all collections, it
>>> won't look very nice. Let's make a break now.
>>>
>>> On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta  wrote:
 On 09/04/2011 04:00 PM, James Carman wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi  
> wrote:
>>
>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>
>
> I believe the feature is actually called "type inference", not 
> "auto-cast."  :)

 Thanks for the explanation... I see now that via the generic method
 the compiler infers the return type from the assignment type.

 Cheers,
 Raman

 -
 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
>>
>>
>
> -
> 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: [chain][discuss] v2 upgrade - follow-up

[Elijah Zupancic]

Hi Simo,

Before we look at releasing the changes (after a trunk merge), I think that
we will need to update the documentation to include Generics and possibly
change the unit tests to use Generics. That said - I'm cautious about
changing the unit tests because they are verifying that the API works in its
current form without generics. Do you or anyone else have any thoughts on
this?

Thanks,
-Elijah

On Mon, Aug 29, 2011 at 12:53 PM, Simone Tripodi
wrote:

> Hi all guys,
> I just fixed the clirr report generation and deployed the chain2 site
> on my personal ASF space[1], in order we can discuss the patch that
> Elijah kindly provided.
> WDYT? It is IMHO acceptable in order to apply the modifications in /trunk.
> TIA, all the best!!!
> Simo
>
> [1] http://people.apache.org/~simonetripodi/chain/clirr-report.html
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Aug 23, 2011 at 10:52 AM, Simone Tripodi
>  wrote:
> > Hi Matt,
> > your suggestion makes indeed a lot of sense! I'll copy the /trunk to a
> > branch and publish the site, once applied the patch, on my home@asf as
> > soon as I have spare time today, so we can discuss together clirr
> > report results.
> > Many thanks for your hint, have a nice day!!!
> > Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://www.99soft.org/
> >
> >
> >
> > On Mon, Aug 22, 2011 at 4:46 PM, Matt Benson 
> wrote:
> >> I am generally in favor.  I think it could be good to apply his patch
> >> on a branch so we can discuss the clirr results and agree on the
> >> severity of the (IMHO forgivable) backward-compatibility breaches.
> >> Then we will understand the proper path forward with respect to
> >> versions and all the changes that cascade from the potential major
> >> version bump.
> >>
> >> Matt
> >>
> >> On Mon, Aug 22, 2011 at 1:03 AM, Simone Tripodi
> >>  wrote:
> >>> Hi all guys,
> >>> Elijah, a [chain] user, has been submitting worthy contributions[1] to
> >>> improve and actualize the commons-chains component, providing also
> >>> patches[2].
> >>> I think it is the good time to start speaking about the next [chain]
> >>> version (no new releases/development in the last months), any
> >>> objections on applying Elijah patch?
> >>> I can take care of it but please let me know if anyone else want to do.
> >>> Many thanks in advance, have a nice day!!!
> >>> Simo
> >>>
> >>> [1] http://markmail.org/message/ajh3sunrst7x5klv
> >>> [2] https://issues.apache.org/jira/browse/CHAIN-53
> >>>
> >>> http://people.apache.org/~simonetripodi/
> >>> http://www.99soft.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
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [chain] Apache Chain v2 Proof of Concept

[Elijah Zupancic]

Simo,

Bricklaying is one of those things that seem simple, but actually can
be a bit complex. So, I hope you are having fun with your project.

I just ran clirr against the 1.3 version and it showed only additions.
So, from its perspective it is backwards compatible. However, for the
one line that is incompatible, I believe that it is incompatible
because of a bug in the existing version. Do you think that it
warrants a deprecated annotation?

Now, I just checked the check-style plugin report and it looks like I
will need to update the patch so that I get 0 check style errors. I
should have that updated this weekend.

Thanks,
-Elijah

On Thu, Aug 18, 2011 at 5:44 AM, Simone Tripodi
 wrote:
> Hi all/Elijah,
> sorry for replying so late but during these days I've been working as
> bricklayer at home, fixing some stuff :P
>
> About the binary compatibility breakage, I have a (maybe silly,
> hopefully not) idea: marking @Deprecated (and justifying why in the
> javadoc) the wrong method and adding the new correct one, if possible
> (take in consideration I'm not 100% familiar with chain so maybe I'm
> just inventing).
>
> That for the purpose to have 100% binary compatibility. Did you try to
> enable the clirr-plugin[1] for maven to see which are the differences
> with the previous chain version?
>
> Many thanks in advance, hope to hear from you soon!!!
> Have a nice day, all the best,
> Simo
>
> [1] http://mojo.codehaus.org/clirr-maven-plugin/
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Aug 17, 2011 at 7:06 PM, Matt Benson  wrote:
>> BTW, please don't take the previous response as indicating any
>> negativity on my part.  Feel free to prod us as long as possible, at
>> reasonable frequency.
>>
>> Matt
>>
>> On Wed, Aug 17, 2011 at 12:04 PM, Matt Benson  wrote:
>>> Be patient, while not being so patient that you allow us to forget it.
>>>
>>> Matt
>>>
>>> On Wed, Aug 17, 2011 at 12:01 PM, Elijah Zupancic  
>>> wrote:
>>>> Hi Matt and Simo,
>>>>
>>>> I've attached the patch to the bug and fixed the issues mentioned with 
>>>> faces.
>>>>
>>>> What other steps do I need to do now?
>>>>
>>>> Thanks,
>>>> -Elijah
>>>>
>>>> On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson  wrote:
>>>>> Hi, Elijah--
>>>>>
>>>>>  I am neither a develop nor even a user of chain, so my comments will
>>>>> be high-level.  Firstly, by all means upgrade to whatever JUnit 4
>>>>> release version you like, e.g. 4.8.2.  Next, I personally am a big fan
>>>>> of Mockito, so no complaints here on that account.  I can't guarantee
>>>>> noone else would complain, but [chain] has been fairly unloved for a
>>>>> good while.  As for JSF 2.1, is there something this achieves that
>>>>> wouldn't be equally well accomplished by simply upgrading to 2.0?
>>>>> This would give [chain]'s JSF support (which I personally hadn't
>>>>> realized existed) a potentially better combination of
>>>>> doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest
>>>>> possible applicability.
>>>>>
>>>>> Finally, as you don't seem to be a committer your final submission in
>>>>> this regard would be best recommended in the form of a JIRA issue, and
>>>>> your patches in (albeit large) patch form.  In addition to this, the
>>>>> scope of these changes indicates it best IMO that you submit an
>>>>> Individual Contributor License Agreement governing your contributions
>>>>> to the ASF.  See http://www.apache.org/licenses/#clas for details on
>>>>> how to do this.
>>>>>
>>>>> Regards and welcome,
>>>>> Matt
>>>>>
>>>>> On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic  
>>>>> wrote:
>>>>>> I've just finished my proof of concept for an upgrade to Apache chain.
>>>>>> I would love to get this into a svn branch. I'm not quite sure what
>>>>>> the procedure is to do that, but the code can be found here for
>>>>>> review:
>>>>>>
>>>>>> http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz
>>>>>>
>>>>>> And here is a diff:
>>>>>>
>>>>>> http://elijah.zupancic.name/proj

Re: [chain] Apache Chain v2 Proof of Concept

[Elijah Zupancic]

Hi Matt and Simo,

I've attached the patch to the bug and fixed the issues mentioned with faces.

What other steps do I need to do now?

Thanks,
-Elijah

On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson  wrote:
> Hi, Elijah--
>
>  I am neither a develop nor even a user of chain, so my comments will
> be high-level.  Firstly, by all means upgrade to whatever JUnit 4
> release version you like, e.g. 4.8.2.  Next, I personally am a big fan
> of Mockito, so no complaints here on that account.  I can't guarantee
> noone else would complain, but [chain] has been fairly unloved for a
> good while.  As for JSF 2.1, is there something this achieves that
> wouldn't be equally well accomplished by simply upgrading to 2.0?
> This would give [chain]'s JSF support (which I personally hadn't
> realized existed) a potentially better combination of
> doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest
> possible applicability.
>
> Finally, as you don't seem to be a committer your final submission in
> this regard would be best recommended in the form of a JIRA issue, and
> your patches in (albeit large) patch form.  In addition to this, the
> scope of these changes indicates it best IMO that you submit an
> Individual Contributor License Agreement governing your contributions
> to the ASF.  See http://www.apache.org/licenses/#clas for details on
> how to do this.
>
> Regards and welcome,
> Matt
>
> On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic  wrote:
>> I've just finished my proof of concept for an upgrade to Apache chain.
>> I would love to get this into a svn branch. I'm not quite sure what
>> the procedure is to do that, but the code can be found here for
>> review:
>>
>> http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz
>>
>> And here is a diff:
>>
>> http://elijah.zupancic.name/projects/uber-diff
>>
>> At a high level, I have incorporated the following features in this
>> proof of concept:
>>
>> * Global upgrade to the JDK 1.5
>> * Added @Override annotations
>> * Upgraded to the Servlet 2.5 API
>> * Upgraded to the Faces 2.1 API
>> * Upgraded to the Portlet 2.0 API
>> * Upgraded the Maven Parent POM version
>> * Added generics support to Command so that Command's API looks like:
>>
>> public interface Command {
>> ...
>>    boolean execute(T context) throws Exception;
>> }
>>
>> * Servlet and Portlet packages now provide Genericized APIs.
>> * All dicey changes have been marked with a comment with my name: (elijah)
>>
>> More or less the work to updated Chain was straight forward albeit
>> time consuming.
>>
>> If everyone is on board for this update, I would like to upgrade the
>> test cases to use a new version of JUnit. However, this leads to a few
>> questions:
>>
>> * What version of JUnit should I use?
>> * Would it be ok to use Mockito for mocking instead of the home grown
>> mocking classes already contained in the project?
>>
>> Please let me know what you think. Getting this far has been a couple
>> weeks worth of on and off work.
>>
>> Thanks,
>> -Elijah
>>
>> -
>> 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: [chain] Apache Chain v2 Proof of Concept

[Elijah Zupancic]

Hi Paul,

I haven't heard any discussion about a pending refactor to chain in
the last month (when I proposed the patch). Could you tell me/us more
about any plans for a major refactoring?

Thanks,
-Elijah

On Tue, Aug 16, 2011 at 1:42 PM, Paul Benedict  wrote:
> I may have missed the discussion... but are we releasing a Java 5
> genericized version first before major refactoring?
>
> On Tue, Aug 16, 2011 at 3:35 PM, Elijah Zupancic  wrote:
>> Hi Simo,
>>
>> Yes, the patch is binary compatible with the old chain with one exception:
>>
>> org.apache.commons.chain.web.servlet.ServletHeaderValuesMap on line
>> 97. Previously the API was returning Set> Enumeration> when by all indications it actually should have
>> been returning Set>. I believe that I fixed a
>> previously undiscovered bug there.
>>
>> Right now, none of the unit tests are using generics and they all
>> pass. So, I assume that we have a backwards compatible API.
>>
>> Thanks,
>> -Elijah
>>
>> On Tue, Aug 16, 2011 at 2:00 AM, Simone Tripodi
>>  wrote:
>>> Hi Elijah,
>>> looking at the patch, it seems that v2.0 is binary compatible to old
>>> chain, right?
>>> I mean, if in a my hypothetical application I would upgrade to v2
>>> (generics a part) old code should continue working, right?
>>> TIA, and count also on me!
>>> All the best, have a nice day!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Aug 15, 2011 at 6:50 PM, Elijah Zupancic  
>>> wrote:
>>>> Hi Matt,
>>>>
>>>> Thanks for the advice. I've created a JIRA issue for the patch
>>>> (https://issues.apache.org/jira/browse/CHAIN-53) and signed and
>>>> submitted the CLA.
>>>>
>>>> As for JSF, I believe I made a mistake in changing the API to use the
>>>> office jsf API instead of the myfaces API that was previously being
>>>> used. I went that route because I couldn't find a 2.0 version of the
>>>> faces api in the Maven repo, but it looks like it is available on the
>>>> myfaces project site, so I will revert the dependency to using myfaces
>>>> and downgrade to 2.0.
>>>>
>>>> I'll start work on migrating the test cases / mocking to a newer junit
>>>> and mockito, when I know that the changes will be accepted.
>>>>
>>>> Thanks again for the help!
>>>>
>>>> -Elijah
>>>>
>>>> On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson  wrote:
>>>>> Hi, Elijah--
>>>>>
>>>>>  I am neither a develop nor even a user of chain, so my comments will
>>>>> be high-level.  Firstly, by all means upgrade to whatever JUnit 4
>>>>> release version you like, e.g. 4.8.2.  Next, I personally am a big fan
>>>>> of Mockito, so no complaints here on that account.  I can't guarantee
>>>>> noone else would complain, but [chain] has been fairly unloved for a
>>>>> good while.  As for JSF 2.1, is there something this achieves that
>>>>> wouldn't be equally well accomplished by simply upgrading to 2.0?
>>>>> This would give [chain]'s JSF support (which I personally hadn't
>>>>> realized existed) a potentially better combination of
>>>>> doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest
>>>>> possible applicability.
>>>>>
>>>>> Finally, as you don't seem to be a committer your final submission in
>>>>> this regard would be best recommended in the form of a JIRA issue, and
>>>>> your patches in (albeit large) patch form.  In addition to this, the
>>>>> scope of these changes indicates it best IMO that you submit an
>>>>> Individual Contributor License Agreement governing your contributions
>>>>> to the ASF.  See http://www.apache.org/licenses/#clas for details on
>>>>> how to do this.
>>>>>
>>>>> Regards and welcome,
>>>>> Matt
>>>>>
>>>>> On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic  
>>>>> wrote:
>>>>>> I've just finished my proof of concept for an upgrade to Apache chain.
>>>>>> I would love to get this into a svn branch. I'm not quite sure what
>>>>>> the procedure is to do that, but the code can be found here for

Re: [chain] Apache Chain v2 Proof of Concept

[Elijah Zupancic]

Hi Simo,

Yes, the patch is binary compatible with the old chain with one exception:

org.apache.commons.chain.web.servlet.ServletHeaderValuesMap on line
97. Previously the API was returning Set> when by all indications it actually should have
been returning Set>. I believe that I fixed a
previously undiscovered bug there.

Right now, none of the unit tests are using generics and they all
pass. So, I assume that we have a backwards compatible API.

Thanks,
-Elijah

On Tue, Aug 16, 2011 at 2:00 AM, Simone Tripodi
 wrote:
> Hi Elijah,
> looking at the patch, it seems that v2.0 is binary compatible to old
> chain, right?
> I mean, if in a my hypothetical application I would upgrade to v2
> (generics a part) old code should continue working, right?
> TIA, and count also on me!
> All the best, have a nice day!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Aug 15, 2011 at 6:50 PM, Elijah Zupancic  wrote:
>> Hi Matt,
>>
>> Thanks for the advice. I've created a JIRA issue for the patch
>> (https://issues.apache.org/jira/browse/CHAIN-53) and signed and
>> submitted the CLA.
>>
>> As for JSF, I believe I made a mistake in changing the API to use the
>> office jsf API instead of the myfaces API that was previously being
>> used. I went that route because I couldn't find a 2.0 version of the
>> faces api in the Maven repo, but it looks like it is available on the
>> myfaces project site, so I will revert the dependency to using myfaces
>> and downgrade to 2.0.
>>
>> I'll start work on migrating the test cases / mocking to a newer junit
>> and mockito, when I know that the changes will be accepted.
>>
>> Thanks again for the help!
>>
>> -Elijah
>>
>> On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson  wrote:
>>> Hi, Elijah--
>>>
>>>  I am neither a develop nor even a user of chain, so my comments will
>>> be high-level.  Firstly, by all means upgrade to whatever JUnit 4
>>> release version you like, e.g. 4.8.2.  Next, I personally am a big fan
>>> of Mockito, so no complaints here on that account.  I can't guarantee
>>> noone else would complain, but [chain] has been fairly unloved for a
>>> good while.  As for JSF 2.1, is there something this achieves that
>>> wouldn't be equally well accomplished by simply upgrading to 2.0?
>>> This would give [chain]'s JSF support (which I personally hadn't
>>> realized existed) a potentially better combination of
>>> doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest
>>> possible applicability.
>>>
>>> Finally, as you don't seem to be a committer your final submission in
>>> this regard would be best recommended in the form of a JIRA issue, and
>>> your patches in (albeit large) patch form.  In addition to this, the
>>> scope of these changes indicates it best IMO that you submit an
>>> Individual Contributor License Agreement governing your contributions
>>> to the ASF.  See http://www.apache.org/licenses/#clas for details on
>>> how to do this.
>>>
>>> Regards and welcome,
>>> Matt
>>>
>>> On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic  
>>> wrote:
>>>> I've just finished my proof of concept for an upgrade to Apache chain.
>>>> I would love to get this into a svn branch. I'm not quite sure what
>>>> the procedure is to do that, but the code can be found here for
>>>> review:
>>>>
>>>> http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz
>>>>
>>>> And here is a diff:
>>>>
>>>> http://elijah.zupancic.name/projects/uber-diff
>>>>
>>>> At a high level, I have incorporated the following features in this
>>>> proof of concept:
>>>>
>>>> * Global upgrade to the JDK 1.5
>>>> * Added @Override annotations
>>>> * Upgraded to the Servlet 2.5 API
>>>> * Upgraded to the Faces 2.1 API
>>>> * Upgraded to the Portlet 2.0 API
>>>> * Upgraded the Maven Parent POM version
>>>> * Added generics support to Command so that Command's API looks like:
>>>>
>>>> public interface Command {
>>>> ...
>>>>    boolean execute(T context) throws Exception;
>>>> }
>>>>
>>>> * Servlet and Portlet packages now provide Genericized APIs.
>>>> * All dicey changes have been marked with a comment

Re: [chain] Apache Chain v2 Proof of Concept

[Elijah Zupancic]

Hi Matt,

Thanks for the advice. I've created a JIRA issue for the patch
(https://issues.apache.org/jira/browse/CHAIN-53) and signed and
submitted the CLA.

As for JSF, I believe I made a mistake in changing the API to use the
office jsf API instead of the myfaces API that was previously being
used. I went that route because I couldn't find a 2.0 version of the
faces api in the Maven repo, but it looks like it is available on the
myfaces project site, so I will revert the dependency to using myfaces
and downgrade to 2.0.

I'll start work on migrating the test cases / mocking to a newer junit
and mockito, when I know that the changes will be accepted.

Thanks again for the help!

-Elijah

On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson  wrote:
> Hi, Elijah--
>
>  I am neither a develop nor even a user of chain, so my comments will
> be high-level.  Firstly, by all means upgrade to whatever JUnit 4
> release version you like, e.g. 4.8.2.  Next, I personally am a big fan
> of Mockito, so no complaints here on that account.  I can't guarantee
> noone else would complain, but [chain] has been fairly unloved for a
> good while.  As for JSF 2.1, is there something this achieves that
> wouldn't be equally well accomplished by simply upgrading to 2.0?
> This would give [chain]'s JSF support (which I personally hadn't
> realized existed) a potentially better combination of
> doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest
> possible applicability.
>
> Finally, as you don't seem to be a committer your final submission in
> this regard would be best recommended in the form of a JIRA issue, and
> your patches in (albeit large) patch form.  In addition to this, the
> scope of these changes indicates it best IMO that you submit an
> Individual Contributor License Agreement governing your contributions
> to the ASF.  See http://www.apache.org/licenses/#clas for details on
> how to do this.
>
> Regards and welcome,
> Matt
>
> On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic  wrote:
>> I've just finished my proof of concept for an upgrade to Apache chain.
>> I would love to get this into a svn branch. I'm not quite sure what
>> the procedure is to do that, but the code can be found here for
>> review:
>>
>> http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz
>>
>> And here is a diff:
>>
>> http://elijah.zupancic.name/projects/uber-diff
>>
>> At a high level, I have incorporated the following features in this
>> proof of concept:
>>
>> * Global upgrade to the JDK 1.5
>> * Added @Override annotations
>> * Upgraded to the Servlet 2.5 API
>> * Upgraded to the Faces 2.1 API
>> * Upgraded to the Portlet 2.0 API
>> * Upgraded the Maven Parent POM version
>> * Added generics support to Command so that Command's API looks like:
>>
>> public interface Command {
>> ...
>>    boolean execute(T context) throws Exception;
>> }
>>
>> * Servlet and Portlet packages now provide Genericized APIs.
>> * All dicey changes have been marked with a comment with my name: (elijah)
>>
>> More or less the work to updated Chain was straight forward albeit
>> time consuming.
>>
>> If everyone is on board for this update, I would like to upgrade the
>> test cases to use a new version of JUnit. However, this leads to a few
>> questions:
>>
>> * What version of JUnit should I use?
>> * Would it be ok to use Mockito for mocking instead of the home grown
>> mocking classes already contained in the project?
>>
>> Please let me know what you think. Getting this far has been a couple
>> weeks worth of on and off work.
>>
>> Thanks,
>> -Elijah
>>
>> -
>> 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

[chain] Apache Chain v2 Proof of Concept

[Elijah Zupancic]

I've just finished my proof of concept for an upgrade to Apache chain.
I would love to get this into a svn branch. I'm not quite sure what
the procedure is to do that, but the code can be found here for
review:

http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz

And here is a diff:

http://elijah.zupancic.name/projects/uber-diff

At a high level, I have incorporated the following features in this
proof of concept:

* Global upgrade to the JDK 1.5
* Added @Override annotations
* Upgraded to the Servlet 2.5 API
* Upgraded to the Faces 2.1 API
* Upgraded to the Portlet 2.0 API
* Upgraded the Maven Parent POM version
* Added generics support to Command so that Command's API looks like:

public interface Command {
...
boolean execute(T context) throws Exception;
}

* Servlet and Portlet packages now provide Genericized APIs.
* All dicey changes have been marked with a comment with my name: (elijah)

More or less the work to updated Chain was straight forward albeit
time consuming.

If everyone is on board for this update, I would like to upgrade the
test cases to use a new version of JUnit. However, this leads to a few
questions:

* What version of JUnit should I use?
* Would it be ok to use Mockito for mocking instead of the home grown
mocking classes already contained in the project?

Please let me know what you think. Getting this far has been a couple
weeks worth of on and off work.

Thanks,
-Elijah

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

[chain] Multiple types in map keys in test cases

[Elijah Zupancic]

Looking at the code here: ServletWebContextTestCase:178,640,701

// Test putAll()
Map values = new HashMap();
values.put(new Integer(1), "One"); // <-- I want to delete
this line (elijah)
values.put("2", "Two");
map.putAll(values);

The test case is testing a putAll operation with incompatible key
types if we were using generics. I'm not sure that this is a valid
test case because there I can't find any keys in the
javax.servlet.ServletContext that aren't stored as strings.
Specifically, the API is coded as following:

public Object getAttribute(String name);

Which tells us the contract for attributes keys is to use a string.
Moreover, this same pattern in unit tests is shared among other
classes in the servlet package in chain. My vote is to modify the unit
test because I believe it represents a misunderstanding of the
contract of the servlet API.

That said, I could be totally wrong and missing something key.

Thanks in advance,
-Elijah

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

Re: [logging] logging vs slf4j

[Elijah Zupancic]

Raman,

You may have proposed this earlier in the thread and I didn't catch
it. I actually like your suggestion the best, but it seems like it is
a difficult sell for a lot of people to compile against the slf4j API
for a variety of reasons that are not strictly code related.

My suggestion was intended to bridge the gap between the concerns
toward compiling directly against slf4j.

Another option is to try to work with Ceki to address some of the
concerns of the commons community with regards to using slf4j.

>From what I can tell from the thread, here are the following points
against SLF4J:

* Log4j developer V2 would like to see the Apache community support
the project rather than putting resources into slf4j.
* Slf4j apparently has some deficiencies in its API such as: "SLF4J
has to convert the EventData object to XML since SLF4J/Logback don't
provide a good way of handling this."
* Log4j V2 also implements support for the Slf4j API.
* There is a hassle with too many jars for dependencies with slf4j.
* Every time Ceki goes on vacation everything stops.
* Some have a preference for Apache driven projects.
* Figuring out the dependencies that are needed can be difficult.

If we can come to some consensus regarding this issues, then I think
there will be more traction toward Slf4j.

Thanks,
-Elijah

On Mon, Aug 8, 2011 at 2:13 PM, Raman Gupta  wrote:
> On 08/08/2011 04:56 PM, Elijah Zupancic wrote:
>> This could be done by choosing (dynamically or by configuration) the
>> logger implementation log4j / commons / slf4j / jul and then loading
>> the LoggerFactory into a wrapper class that is then called used by the
>> Commons project.
>>
>> We would then make the logger implementations a compile-time
>> dependency only and relay upon the consumer to provide them.
>>
>> I do realize that this is essentially doing a Facade on top of a
>> Facade, but it solves the problem for consumers of the library by
>> providing many options.
>>
>> So, am I crazy?
>
> If I understand you correctly, you would have this dependency chain:
>
> random-commons-project ->
>  commons-logging-wrapper ->
>    API like slf4j or logging implementation (at runtime)
>
> Plus commons-logging-wrapper requires compile-time knowledge of all
> possible target frameworks, since it is not coding to an API.
>
> Can you explain the advantage over simply coding
> random-commons-project against slf4j-api.jar? Then, you have this
> dependency chain:
>
> random-commons-project ->
>  slf4j-api ->
>    logging implementation (at runtime)
>
> And anyone can create their own slf4j compatible logging
> implementation simply by implementing the slf4j api and dropping their
> jar into their environment.
>
> Cheers,
> Raman
>
> -
> 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: [logging] logging vs slf4j

[Elijah Zupancic]

I agree with this sentiment. In the last 3 years all of the large
commercial projects that I have worked on used slf4j just for the very
reason that I needed to bridge the logging implementations in multiple
third-party libraries.

While reading this thread, one approach occurs to me that hasn't been
mentioned. Why not abstract the abstraction? My gut reaction to this
approach is negative, but I do feel that it is quite pragmatic.

This could be done by choosing (dynamically or by configuration) the
logger implementation log4j / commons / slf4j / jul and then loading
the LoggerFactory into a wrapper class that is then called used by the
Commons project.

We would then make the logger implementations a compile-time
dependency only and relay upon the consumer to provide them.

I do realize that this is essentially doing a Facade on top of a
Facade, but it solves the problem for consumers of the library by
providing many options.

So, am I crazy?
-Elijah

> Yes, the reality is large applications need to support multiple source
> frameworks and will therefore require a bunch of logging jars. Slf4j
> provides a relatively simple path to consolidating logs from jcl, jul,
> and log4j into one's chosen target framework (except for jul).
>
> With the current landscape, you are dreaming if you think one magical
> jar is going to support all use cases. This would have been simple if
> jul had been designed properly, but it wasn't.
>
> Cheers,
> Raman

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

Re: [chain] Upgrading to Maven parent version 21

[Elijah Zupancic]

[INFO] There are test failures.

Please refer to /tmp/trunk/target/surefire-reports for the individual
test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 4 minutes 8 seconds
[INFO] Finished at: Sun Jul 31 16:16:38 PDT 2011
[INFO] Final Memory: 54M/286M
[INFO] 


On Sun, Jul 31, 2011 at 10:05 AM, Simone Tripodi
 wrote:
> Hi Elijah,
> I'd investigate on Maven versions first as Phil suggested, before
> purging the local repo :P
> HTH, have a nice WE!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, Jul 31, 2011 at 6:23 PM, David Karlsen  wrote:
>> Try nuking the local maven repository in case something is corrupt?
>> Den 31. juli 2011 17:07 skrev "Elijah Zupancic" 
>> følgende:
>>> Here is the output from SVN diff:
>>>
>>> Index: pom.xml
>>> ===
>>> --- pom.xml (revision 1152492)
>>> +++ pom.xml (working copy)
>>> @@ -21,7 +21,7 @@
>>> 
>>> org.apache.commons
>>> commons-parent
>>> - 15
>>> + 21
>>> 
>>> 4.0.0
>>> commons-chain
>>>
>>> I'm getting the same result with:
>>>
>>> OpenJDK Runtime Environment (IcedTea6 1.9.8) (6b20-1.9.8-0ubuntu1~10.10.1)
>>> OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
>>>
>>> AND
>>>
>>> java version "1.6.0_16"
>>> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
>>> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
>>>
>>> Also, I'm building against
>>> http://svn.apache.org/repos/asf/commons/proper/chain/trunk
>>>
>>> I'm on Ubuntu 10.10.
>>>
>>> I have manually the the digester version higher, and all tests passed.
>>> It is only when I upgrade the parent pom that this test fails. This is
>>> even more curious now that I hear it is working on your OS X system.
>>> When I get access to another machine, I will try it elsewhere next
>>> week. Right now, I'm out in the countryside with not a lot of
>>> resources.
>>>
>>> Thanks,
>>> -Elijah
>>>
>>> On Sun, Jul 31, 2011 at 12:16 AM, Phil Steitz 
>> wrote:
>>>> On 7/30/11 11:13 AM, Elijah Zupancic wrote:
>>>>> As part of my refactoring project with Apache Chain, I've been trying
>>>>> to update dependency versions. I tried to upgrade the maven parent
>>>>> configuration and the compile worked fine, but I have been getting a
>>>>> really odd unit test failure. Moreover, I did a diff between maven
>>>>> parent pom.xml versions and nothing stood out to me as to why the
>>>>> parent pom would cause this.
>>>>
>>>> What OS and JDK are you using?  When I change the pom in trunk to
>>>> use commons-parent version 21 (with no other changes) all of the
>>>> tests run clean for me on OS X 10.7,
>>>> java version "1.6.0_26"
>>>> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)
>>>>
>>>> Digester version in the pom in trunk is 1.8.  I also tested with 2.0
>>>> and 2.1 and did not see failures with JDK above.
>>>>
>>>> Are you sure there are no other changes in the sources you are
>>>> testing against?  Does svn diff turn up any other differences?
>>>>
>>>> Phil
>>>>>
>>>>> Results :
>>>>>
>>>>> Failed tests:
>>>>> testDefaut(org.apache.commons.chain.config.ConfigParserTestCase)  Time
>>>>> elapsed: 0.034 sec  <<< FAILURE!
>>>>> junit.framework.AssertionFailedError: Correct command count
>>>>> expected:<17> but was:<19>
>>>>>         at junit.framework.Assert.fail(Assert.java:47)
>>>>>         at junit.framework.Assert.failNotEquals(Assert.java:282)
>>>>>         at junit.framework.Assert.assertEquals(Assert.java:64)
>>>>>         at junit.framework.Assert.assertEquals(Assert.java:201)
>>>>>         at
>> org.ap

Re: [chain] Upgrading to Maven parent version 21

[Elijah Zupancic]

Here is the output from SVN diff:

Index: pom.xml
===
--- pom.xml (revision 1152492)
+++ pom.xml (working copy)
@@ -21,7 +21,7 @@
 
 org.apache.commons
 commons-parent
-15
+21
 
 4.0.0
 commons-chain

I'm getting the same result with:

OpenJDK Runtime Environment (IcedTea6 1.9.8) (6b20-1.9.8-0ubuntu1~10.10.1)
OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)

AND

java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)

Also, I'm building against
http://svn.apache.org/repos/asf/commons/proper/chain/trunk

I'm on Ubuntu 10.10.

I have manually the the digester version higher, and all tests passed.
It is only when I upgrade the parent pom that this test fails. This is
even more curious now that I hear it is working on your OS X system.
When I get access to another machine, I will try it elsewhere next
week. Right now, I'm out in the countryside with not a lot of
resources.

Thanks,
-Elijah

On Sun, Jul 31, 2011 at 12:16 AM, Phil Steitz  wrote:
> On 7/30/11 11:13 AM, Elijah Zupancic wrote:
>> As part of my refactoring project with Apache Chain, I've been trying
>> to update dependency versions. I tried to upgrade the maven parent
>> configuration and the compile worked fine, but I have been getting a
>> really odd unit test failure. Moreover, I did a diff between maven
>> parent pom.xml versions and nothing stood out to me as to why the
>> parent pom would cause this.
>
> What OS and JDK are you using?  When I change the pom in trunk to
> use commons-parent version 21 (with no other changes) all of the
> tests run clean for me on OS X 10.7,
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)
>
> Digester version in the pom in trunk is 1.8.  I also tested with 2.0
> and 2.1 and did not see failures with JDK above.
>
> Are you sure there are no other changes in the sources you are
> testing against?  Does svn diff turn up any other differences?
>
> Phil
>>
>> Results :
>>
>> Failed tests:
>> testDefaut(org.apache.commons.chain.config.ConfigParserTestCase)  Time
>> elapsed: 0.034 sec  <<< FAILURE!
>> junit.framework.AssertionFailedError: Correct command count
>> expected:<17> but was:<19>
>>         at junit.framework.Assert.fail(Assert.java:47)
>>         at junit.framework.Assert.failNotEquals(Assert.java:282)
>>         at junit.framework.Assert.assertEquals(Assert.java:64)
>>         at junit.framework.Assert.assertEquals(Assert.java:201)
>>         at 
>> org.apache.commons.chain.config.ConfigParserTestCase.checkCommandCount(ConfigParserTestCase.java:316)
>>         at 
>> org.apache.commons.chain.config.ConfigParserTestCase.testDefaut(ConfigParserTestCase.java:116)
>>
>>
>> The XML file it is reading for commands contains exactly 17 commands,
>> so the data source is correct. Before I start to peel apart the XML
>> parser, I was wondering if anyone else encountered this before. Do any
>> of you have any insight into this?
>>
>> Thanks,
>> -Elijah
>>
>> -
>> 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: [chain] Upgrading to Maven parent version 21

[Elijah Zupancic]

Hi Simo,

The test passed before the upgrade. The first thing I thought was that
it was broken in trunk, but apparently that's not the case. Oddly
digester parses out 19 commands with the updated parent and 17 with
the original parent.

Thanks,
-Elijah

On Saturday, July 30, 2011, Simone Tripodi  wrote:
> Hi Elijah,
> thanks for putting effort on chain!
> Just a silly question: did the test fail also before parent upgrade?
> In that case, I'd say i is an error in /trunk.
> Unfortunately my new laptop still hasn't arrived so I can't install
> everything and check myself, otherwise I would help you a little more
> :(
> All he best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sat, Jul 30, 2011 at 8:13 PM, Elijah Zupancic  wrote:
>> As part of my refactoring project with Apache Chain, I've been trying
>> to update dependency versions. I tried to upgrade the maven parent
>> configuration and the compile worked fine, but I have been getting a
>> really odd unit test failure. Moreover, I did a diff between maven
>> parent pom.xml versions and nothing stood out to me as to why the
>> parent pom would cause this.
>>
>> Results :
>>
>> Failed tests:
>> testDefaut(org.apache.commons.chain.config.ConfigParserTestCase)  Time
>> elapsed: 0.034 sec  <<< FAILURE!
>> junit.framework.AssertionFailedError: Correct command count
>> expected:<17> but was:<19>
>>        at junit.framework.Assert.fail(Assert.java:47)
>>        at junit.framework.Assert.failNotEquals(Assert.java:282)
>>        at junit.framework.Assert.assertEquals(Assert.java:64)
>>        at junit.framework.Assert.assertEquals(Assert.java:201)
>>        at 
>> org.apache.commons.chain.config.ConfigParserTestCase.checkCommandCount(ConfigParserTestCase.java:316)
>>        at 
>> org.apache.commons.chain.config.ConfigParserTestCase.testDefaut(ConfigParserTestCase.java:116)
>>
>>
>> The XML file it is reading for commands contains exactly 17 commands,
>> so the data source is correct. Before I start to peel apart the XML
>> parser, I was wondering if anyone else encountered this before. Do any
>> of you have any insight into this?
>>
>> Thanks,
>> -Elijah
>>
>> -
>> 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

[chain] Upgrading to Maven parent version 21

[Elijah Zupancic]

As part of my refactoring project with Apache Chain, I've been trying
to update dependency versions. I tried to upgrade the maven parent
configuration and the compile worked fine, but I have been getting a
really odd unit test failure. Moreover, I did a diff between maven
parent pom.xml versions and nothing stood out to me as to why the
parent pom would cause this.

Results :

Failed tests:
testDefaut(org.apache.commons.chain.config.ConfigParserTestCase)  Time
elapsed: 0.034 sec  <<< FAILURE!
junit.framework.AssertionFailedError: Correct command count
expected:<17> but was:<19>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at 
org.apache.commons.chain.config.ConfigParserTestCase.checkCommandCount(ConfigParserTestCase.java:316)
at 
org.apache.commons.chain.config.ConfigParserTestCase.testDefaut(ConfigParserTestCase.java:116)


The XML file it is reading for commands contains exactly 17 commands,
so the data source is correct. Before I start to peel apart the XML
parser, I was wondering if anyone else encountered this before. Do any
of you have any insight into this?

Thanks,
-Elijah

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

Re: [chain] Forking to a 2.0?

[Elijah Zupancic]

Hi Simo,

That was just the type of information that I was looking for. Skipping
a logging refactor vastly simplifies the work I was planning on doing.

I won't be able to publish my proof of concept until sometime next
week because I have a vacation coming up.

Thanks,
-Elijah

On Thu, Jul 28, 2011 at 12:01 PM, Simone Tripodi
 wrote:
> Hi Elijah,
> it sounds a great interesting contribution, I haven't seen [chain]
> development activity lately so I eventually volunteer to apply the
> patch. Thanks in advance for your effort, [chain] if one of the
> components that need new energy.
>
> Two recommendations:
>
>  * we are updating components code to more recent JVM specs, please
> try to keep 1.5 as target as much as possible. take the [digester] pom
> (is the one I know more) as a good sample where starting from
>  * please don't migrate to slf4j. here at commons we continue using
> commons-logging
>
> Hope that helps and count on me if you need more infos - feel free to
> contact me even directly for trivial questions, better anyway
> discussing on public MLs.
>
> A minor note: [collections] will get a new life soon ;)
> Have a nice day, all the best!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Thu, Jul 28, 2011 at 7:27 PM, David Karlsen  wrote:
>> +1
>> Den 28. juli 2011 06:42 skrev "Paul Benedict" 
>> følgende:
>>>
>>> +1. I have done some of this privately (like generics). Having an
>>> official version would be so useful.
>>>
>>> On Wed, Jul 27, 2011 at 10:46 PM, Elijah Zupancic 
>> wrote:
>>> > Hi,
>>> >
>>> > I've been a active user for a number of years now and a big fan of the
>>> > project. I'm a total beginner when it comes to contributing on Apache
>>> > projects, so please bear with me.
>>> >
>>> > The code base for Apache Chain is starting to feel more and more
>>> > dated. I would like to see the following changes in the project:
>>> >
>>> > * Upgrading the source code to 1.6.
>>> > * Supporting generics on commands, so that we get something like
>>> > Command
>>> > * Switching the logging API over to SLF4J, so that we can swap out
>>> > logging implementations
>>> > * Using the new java.util.concurrency classes to handle thread safety as
>> needed.
>>> > * Removing deprecated methods.
>>> >
>>> > I realize that I am suggestion rather drastic API changes that may
>>> > break the existing API and that is why I'm suggesting a 2.0. I have a
>>> > prototype that I am working on and I do not see it being a lot of work
>>> > to accomplish the above tasks.
>>> >
>>> > Would a 2.0 version of Chain be useful to anyone? Or should I just
>>> > fork the project for my own needs and release it independently like
>>> > the Commons Collections with Generics?
>>> >
>>> > I know that I'm assuming a lot and diving in head first here, so thank
>>> > you ahead of time for any replies.
>>> >
>>> > -Elijah Zupancic
>>> >
>>> > -
>>> > 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
>
>

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

[chain] Forking to a 2.0?

[Elijah Zupancic]

Hi,

I've been a active user for a number of years now and a big fan of the
project. I'm a total beginner when it comes to contributing on Apache
projects, so please bear with me.

The code base for Apache Chain is starting to feel more and more
dated. I would like to see the following changes in the project:

* Upgrading the source code to 1.6.
* Supporting generics on commands, so that we get something like
Command
* Switching the logging API over to SLF4J, so that we can swap out
logging implementations
* Using the new java.util.concurrency classes to handle thread safety as needed.
* Removing deprecated methods.

I realize that I am suggestion rather drastic API changes that may
break the existing API and that is why I'm suggesting a 2.0. I have a
prototype that I am working on and I do not see it being a lot of work
to accomplish the above tasks.

Would a 2.0 version of Chain be useful to anyone? Or should I just
fork the project for my own needs and release it independently like
the Commons Collections with Generics?

I know that I'm assuming a lot and diving in head first here, so thank
you ahead of time for any replies.

-Elijah Zupancic

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