[chain] Example tests using Mockito
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
[chain] Proposed patch to the Command interface
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 CommandK, V, C extends MapK, V {
+/** 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;
/**
* pCommands should return codeCONTINUE_PROCESSING/code 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
Re: [chain] Proposed patch to the Command interface
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 eli...@zupancic.name 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 CommandK, V, C extends MapK, V {
+ /** 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;
/**
* pCommands should return codeCONTINUE_PROCESSING/code 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] CHAIN-66 Finished - Cookbook updated for new generics API
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
[chain] Checkstyle / PMD fixes are complete
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 simonetrip...@apache.org 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 eli...@zupancic.name 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] Next steps for release?
-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
Re: [VOTE] Release Apache Commons-DbUtils 1.5 based on RC1
+1 -Elijah On Mon, Jul 16, 2012 at 6:29 AM, Bill Speirs bill.spe...@gmail.com wrote: +1 Bill- On Mon, Jul 16, 2012 at 8:44 AM, Simone Tripodi simonetrip...@apache.orgwrote: 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 simonetrip...@apache.org 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
Re: [chain] javadoc tags
Great questions. I'm eager to find out what everyone thinks. -Elijah On Wed, Jul 18, 2012 at 1:46 PM, Simone Tripodi simonetrip...@apache.org 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 simonetrip...@apache.org 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: [chain2] dropping @Deprecated methods
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 simonetrip...@apache.org 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
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 eli...@apache.org 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 simonetrip...@apache.org 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
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 simonetrip...@apache.org 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 eli...@apache.org wrote: On Thu, Jul 19, 2012 at 4:27 PM, Elijah Zupancic eli...@apache.org 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 simonetrip...@apache.org 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
[BCEL] Faq update?
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] configuration façade APIs
Thanks! On Sat, Jul 21, 2012 at 11:54 PM, Simone Tripodi simonetrip...@apache.org 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 simonetrip...@apache.org 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
Re: [chain2] configuration façade APIs
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 oliver.he...@oliver-heger.de 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 oliver.he...@oliver-heger.de 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 simonetrip...@apache.org 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 simonetrip...@apache.org 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
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 simonetrip...@apache.org 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 eli...@apache.org 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 oliver.he...@oliver-heger.de 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 oliver.he...@oliver-heger.de 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 simonetrip...@apache.org 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 simonetrip...@apache.org 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] serialVersionUID
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
[digester] Documentation link broken
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] configuration façade APIs
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 eli...@apache.org 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 simonetrip...@apache.org 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 eli...@apache.org 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 oliver.he...@oliver-heger.de 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 oliver.he...@oliver-heger.de 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 simonetrip...@apache.org 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 simonetrip...@apache.org 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
Re: [chain2] serialVersionUID
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 joerg.schai...@scalaris.com 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: [io] Problem with the FileUtils.byteCountToDisplaySize() method
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 simonetrip...@apache.org 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 ninju.bo...@technologypartners.co 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.comailto: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] configuration façade APIs
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 K, V, C extends MapK, V
CatalogFactoryK, V, C 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
oliver.he...@oliver-heger.de 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
oliver.he...@oliver-heger.de 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://www.99soft.org/
On Mon, Jul 23, 2012 at 7:01 AM, Elijah Zupancic eli...@apache.org
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
oliver.he...@oliver-heger.de 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
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.
Thanks,
-Elijah
On Wed, Jul 25, 2012 at 3:36 PM, Elijah Zupancic eli...@apache.org 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 K, V, C extends MapK, V
CatalogFactoryK, V, C 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
oliver.he...@oliver-heger.de 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
oliver.he...@oliver-heger.de 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://www.99soft.org/
On Mon, Jul 23, 2012 at 7:01 AM, Elijah Zupancic eli...@apache.org
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
Re: [chain2] serialVersionUID
@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 brunodepau...@yahoo.com.br wrote: From: Benedikt Ritter benerit...@gmail.com To: Commons Developers List dev@commons.apache.org Sent: Thursday, 26 July 2012 3:28 PM Subject: Re: [chain2] serialVersionUID 2012/7/26 sebb seb...@gmail.com: On 26 July 2012 18:29, Brent Worden brent.wor...@gmail.com wrote: On Thu, Jul 26, 2012 at 3:48 AM, sebb seb...@gmail.com wrote: On 25 July 2012 07:54, Jörg Schaible joerg.schai...@scalaris.com wrote: sebb wrote: On 24 July 2012 09:11, Jörg Schaible joerg.schai...@scalaris.com 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 svuid, but as in my current timezone the svuid is 20120727 too, I would have to take some action, like waiting until the next day, increase the time precision (+ timezone?) or ask here in the mailing list for help. What would be the correct action in situations like this? And as I'm very lazy, I really like using the Eclipse feature to generate the svuid automagically (I believe it uses JDK serialver tool), but with some practice I could get used to using any other standard adopted by a project too :-) Just my 0.02 cents. Hope that helps. -Bruno Thanks, Brent - 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 Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - 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
Re: [chain2] configuration façade APIs
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 oliver.he...@oliver-heger.de 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 brunodepau...@yahoo.com.br 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 simonetrip...@apache.org To: Commons Developers List dev@commons.apache.org 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] configuration façade APIs - followup
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 simonetrip...@apache.org 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
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 simonetrip...@apache.org 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 eli...@apache.org 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 oliver.he...@oliver-heger.de 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 brunodepau...@yahoo.com.br 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 simonetrip...@apache.org To: Commons Developers List dev@commons.apache.org 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 - - 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?
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 javascript:; For additional commands, e-mail: dev-h...@commons.apache.orgjavascript:;
Re: [chain2] ChainConfigurationException?
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 eli...@apache.org 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?
It should be fixed in 1366598. Thanks, -Elijah On Fri, Jul 27, 2012 at 10:13 PM, Elijah Zupancic eli...@apache.org 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 eli...@apache.org 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] ServiceLoader in Chain2 to load Jackson supported formats
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 simonetrip...@apache.org 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
[chain2] Release Status
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: [CHAIN] Why does ConextMap extend ConcurrentHashMap instead of delegating to a Map?
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 benerit...@gmail.comwrote: 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
Re: [CHAIN] Thoughts about o.a.c.chain2.Chain, o.a.c.chain2.Command and the base classes
+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 benerit...@gmail.comwrote: Am 22.06.2013 um 12:57 schrieb Simone Tripodi simonetrip...@apache.org: Hi Jonas, I will provide a patch for CHAIN-98https://issues.apache.org/jira/browse/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?
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 brit...@apache.org wrote: Hi Elijah, nice to have you with us again :-) 2013/6/26 Elijah Zupancic eli...@zupancic.name 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 benerit...@gmail.com 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
[chain] Multiple types in map keys in test cases
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
[chain] Apache Chain v2 Proof of Concept
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 CommandT extends Context {
...
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
Re: [chain] Apache Chain v2 Proof of Concept
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 gudnabr...@gmail.com 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 eli...@zupancic.name 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 CommandT extends Context {
...
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
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 SetEntryString,
EnumerationString when by all indications it actually should have
been returning SetEntryString, String[]. 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
simonetrip...@apache.org 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 eli...@zupancic.name 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 gudnabr...@gmail.com 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 eli...@zupancic.name
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 CommandT extends Context {
...
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
Re: [chain] Apache Chain v2 Proof of Concept
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 pbened...@apache.org 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 eli...@zupancic.name 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 SetEntryString,
EnumerationString when by all indications it actually should have
been returning SetEntryString, String[]. 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
simonetrip...@apache.org 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 eli...@zupancic.name
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 gudnabr...@gmail.com 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 eli...@zupancic.name
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 CommandT extends Context {
...
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
Re: [chain] Apache Chain v2 Proof of Concept
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 gudnabr...@gmail.com 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 eli...@zupancic.name 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 CommandT extends Context {
...
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
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
simonetrip...@apache.org 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 gudnabr...@gmail.com 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 gudnabr...@gmail.com 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 eli...@zupancic.name
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 gudnabr...@gmail.com 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 eli...@zupancic.name
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 CommandT extends Context {
...
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
Re: [chain][discuss] v2 upgrade - follow-up
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 simonetrip...@apache.orgwrote: 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 simonetrip...@apache.org 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 gudnabr...@gmail.com 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 simonetrip...@apache.org 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][v2] clever context
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 niall.pember...@gmail.com wrote: On Mon, Sep 5, 2011 at 12:21 PM, James Carman ja...@carmanconsulting.com 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 pbened...@apache.org 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 rocketra...@fastmail.fm wrote: On 09/04/2011 04:00 PM, James Carman wrote: On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi simonetrip...@apache.org 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][v2] clever context
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 HashMapString,
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.
I'm of the opinion that standardizing on String or ? extends
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.
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
niall.pember...@gmail.com wrote:
On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi simonetrip...@apache.org
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
MapString,Object 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
niall.pember...@gmail.com wrote:
On Mon, Sep 5, 2011 at 12:21 PM, James Carman
ja...@carmanconsulting.com 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 pbened...@apache.org
wrote:
I want to get rid of it extending
Re: [chain][v2] clever context
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 ContextK extends Object, V extends Object extends MapK, V
Then ContextBase.java would be defined like so:
public class ContextBase extends ConcurrentHashMapString, Object
implements ContextString, Object {
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
niall.pember...@gmail.com wrote:
On Fri, Sep 9, 2011 at 12:25 AM, Elijah Zupancic eli...@zupancic.name 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 HashMapString,
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 ? extends
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
niall.pember...@gmail.com wrote:
On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi simonetrip...@apache.org
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
Re: [chain][v2] clever context
Paul,
You may be right. Which one is more idiomatic?
Thanks,
-Elijah
On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict pbened...@apache.org wrote:
On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic eli...@zupancic.name 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 ContextK extends Object, V extends Object extends MapK,
V
Isn't that identical to?
public interface ContextK, V extends MapK, V
Then ContextBase.java would be defined like so:
public class ContextBase extends ConcurrentHashMapString, Object
implements ContextString, Object {
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
Specifying Object for V would be the most likely use case. On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict pbened...@apache.org wrote: On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi simonetrip...@apache.org 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: ContextString, String properties = new ContextBaseString, String(); 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 - follow-up
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 simonetrip...@apache.orgwrote: 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 - follow-up
, 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 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 simonetrip...@apache.orgwrote: 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
Re: [chain][v2] clever context - follow-up
I just submitted a patch to jira as CHAIN-58. This changes Context to ContextK,V. Thanks, -Elijah On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi simonetrip...@apache.orgwrote: 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 ContextK, V and then use interface composition to define other things like: public interface PropertyContext extends ContextString, Object, MapString, Object It can be done... I think :-) Paul On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi simonetrip...@apache.org 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 CommandK, V, C extends ContextK, V :? 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 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 simonetrip...@apache.orgwrote: 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
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.orgwrote:
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 ContextK, V extends MapK, V {
}
you can easily note that, in Command interface (just to mention one)
compiler complains:
Context is a raw type. References to generic type ContextK, V
should be parametrized
and we can not just ignore it... that's why I thought that adopting
the signature CommandK, V, C extends ContextK, V 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
simonetrip...@apache.org 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
ContextK,V.
Thanks,
-Elijah
On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi
simonetrip...@apache.orgwrote:
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 ContextK, V and then use interface
composition to define other things like:
public interface PropertyContext extends ContextString, Object,
MapString, Object
It can be done... I think :-)
Paul
On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
simonetrip...@apache.org 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
CommandK, V, C extends ContextK, V :?
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
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
simonetrip...@apache.orgwrote:
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
Re: [continuum] BUILD FAILURE: Apache Commons - Commons Chain - Default Maven 2 Build Definition (Java 1.5)
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 simonetrip...@apache.orgwrote: 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 contin...@apache.org wrote: Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=12403projectId=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 Errors: 0 Success Rate: 99 Total time: 1.1960001 Test Failures:
Re: [continuum] BUILD FAILURE: Apache Commons - Commons Chain - Default Maven 2 Build Definition (Java 1.5)
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 simonetrip...@apache.orgwrote: 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 contin...@apache.org wrote: Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=12403projectId=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 Errors: 0 Success Rate: 99 Total time: 1.1960001 Test Failures:
Re: [chain][v2] clever context - follow-up
,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.CommandC) 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 eli...@zupancic.name
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.orgwrote:
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 ContextK, V extends MapK, V {
}
you can easily note that, in Command interface (just to mention one)
compiler complains:
Context is a raw type. References to generic type ContextK, V
should be parametrized
and we can not just ignore it... that's why I thought that adopting
the signature CommandK, V, C extends ContextK, V 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
simonetrip...@apache.org 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
ContextK,V.
Thanks,
-Elijah
On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi
simonetrip...@apache.orgwrote:
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 ContextK, V and then use interface
composition to define other things like:
public interface PropertyContext extends ContextString, Object,
MapString, Object
It can be done... I think :-)
Paul
On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
simonetrip...@apache.org 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
CommandK, V, C extends ContextK, V :?
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
use auto-complete, automatic code refactoring tools and static
code
analysis
tools
Re: [chain][v2] clever context - follow-up
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 eli...@zupancic.namewrote:
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
simonetrip...@apache.orgwrote:
Hi Elijah,
by default Maven doesn't show warnings, you have to modify the pom.xml
in that way:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.1/version
configuration
source${maven.compile.source}/source
target${maven.compile.target}/target
compilerArgument-Xlint:all/compilerArgument
showWarningstrue/showWarnings
/configuration
/plugin
{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.Entryjava.lang.String,java.lang.Object
[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.Entryjava.lang.String,java.lang.Object
[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.Entryjava.lang.String,java.lang.Object
[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.Mapjava.lang.String,java.lang.Object
[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.Mapjava.lang.String,java.lang.Object
[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.Mapjava.lang.String,java.lang.String
[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.Mapjava.lang.String,java.lang.String
[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.Mapjava.lang.String,java.lang.String[]
[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.Mapjava.lang.String,java.lang.String[]
[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: java.util.Mapjava.lang.String,java.lang.String
[WARNING]
/Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[169,11]
[unchecked] unchecked conversion
found : java.util.Map
required: java.util.Mapjava.lang.String,java.lang.String
[WARNING]
/Users/simonetripodi
Re: [chain][v2] chain-58
/commons-chain/src/main/java/org/apache/commons/chain/web/ChainResources.java:[191,16]
[dep-ann] deprecated name isnt annotated with @Deprecated
[WARNING]
/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.CommandC
[WARNING]
/Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/config/ConfigRegisterRule.java:[101,43]
[unchecked] unchecked method invocation:
CaddCommand(java.lang.String,org.apache.commons.chain.CommandC) 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.CommandC) 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 eli...@zupancic.name
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.orgwrote:
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 ContextK, V extends MapK, V {
}
you can easily note that, in Command interface (just to mention one)
compiler complains:
Context is a raw type. References to generic type ContextK, V
should be parametrized
and we can not just ignore it... that's why I thought that adopting
the signature CommandK, V, C extends ContextK, V 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
simonetrip...@apache.org 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
ContextK,V.
Thanks,
-Elijah
On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi
simonetrip...@apache.orgwrote:
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 ContextK, V and then use interface
composition to define other things like:
public interface PropertyContext extends ContextString, Object,
MapString, Object
It can be done... I think :-)
Paul
On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
simonetrip...@apache.org 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
CommandK, V, C
Re: Commons VFS support for Amazon S3?
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 ralph.go...@dslextreme.comwrote: 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 liviu.tu...@gmail.com 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 garydgreg...@gmail.com 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 liviu.tu...@gmail.com 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 mailto:liviu.tu...@gmail.com M: +44 (0)7917696626 W: http://about.me/liviutudor 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] towards 2.0
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 simonetrip...@apache.orgwrote: 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 MapK,V 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
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 eli...@zupancic.namewrote: 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 simonetrip...@apache.orgwrote: 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 MapK,V 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] release roadmap
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 simonetrip...@apache.org 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] release roadmap
FYI, I am also updating the examples in the /apps folder. -Elijah On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi simonetrip...@apache.org 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 eli...@zupancic.name 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 simonetrip...@apache.org 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
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 simonetrip...@apache.orgwrote: 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 eli...@zupancic.name wrote: FYI, I am also updating the examples in the /apps folder. -Elijah On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi simonetrip...@apache.org 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 eli...@zupancic.name 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 simonetrip...@apache.org 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
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 simonetrip...@apache.org 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 eli...@zupancic.name 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 simonetrip...@apache.orgwrote: 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 eli...@zupancic.name wrote: FYI, I am also updating the examples in the /apps folder. -Elijah On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi simonetrip...@apache.org 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 eli...@zupancic.name 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 simonetrip...@apache.org 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
[chain] Changing from Exception to RuntimeException
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();
CommandString, Object, ProfileContext 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] Changing from Exception to RuntimeException
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 simonetrip...@apache.org 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 ja...@carmanconsulting.com
wrote:
I hate checked exceptions. +1
On Sat, Mar 3, 2012 at 11:07 PM, Elijah Zupancic eli...@zupancic.name
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();
CommandString, Object, ProfileContext 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
Re: [VOTE] Promote [csv] to Commons proper
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 ebo...@apache.org 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
[chain] Forking to a 2.0?
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 CommandMyContext * 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
Re: [chain] Forking to a 2.0?
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 simonetrip...@apache.org 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 davidkarl...@gmail.com wrote: +1 Den 28. juli 2011 06:42 skrev Paul Benedict pbened...@apache.org 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 eli...@zupancic.name 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 CommandMyContext * 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
Re: [chain] Upgrading to Maven parent version 21
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 simonetrip...@apache.org 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 eli...@zupancic.name 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
Re: [chain] Upgrading to Maven parent version 21
Here is the output from SVN diff: Index: pom.xml === --- pom.xml (revision 1152492) +++ pom.xml (working copy) @@ -21,7 +21,7 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-parent/artifactId -version15/version +version21/version /parent modelVersion4.0.0/modelVersion groupIdcommons-chain/groupId 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 phil.ste...@gmail.com 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
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 simonetrip...@apache.org 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 davidkarl...@gmail.com wrote: Try nuking the local maven repository in case something is corrupt? Den 31. juli 2011 17:07 skrev Elijah Zupancic eli...@zupancic.name følgende: Here is the output from SVN diff: Index: pom.xml === --- pom.xml (revision 1152492) +++ pom.xml (working copy) @@ -21,7 +21,7 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-parent/artifactId - version15/version + version21/version /parent modelVersion4.0.0/modelVersion groupIdcommons-chain/groupId 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 phil.ste...@gmail.com 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
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: [logging] logging vs slf4j
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 rocketra...@fastmail.fm 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: [vfs] Wiki update for Manta VFS provider
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 <eli...@apache.org> 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, <e...@zusammenkunft.net> 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
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: [io] ClosedOutputStream#flush
Please omit this line from the program:
BufferedOutputStream bout = new BufferedOutputStream(fout, 9);
On Tue, Aug 15, 2017 at 6:12 PM, Elijah Zupancic <eli...@apache.org> 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 <tomas.cel...@joyent.com> 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
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
