I misunderstood CHAIN-53 then. On Tue, Aug 16, 2011 at 4:29 PM, Elijah Zupancic <eli...@zupancic.name> wrote: > 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 Set<Entry<String, >>> Enumeration<String>> when by all indications it actually should have >>> been returning Set<Entry<String, 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 Command<T 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 >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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
