Hi Elijah,
don't be sorry, OSS is something (almost) everybody does in his spare time ;)
Thanks for the new patch, I'll process during the day as soon as I get
a spare time slot.
Have a nice day, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http
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
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
Hi Elijah,
by default Maven doesn't show warnings, you have to modify the pom.xml
in that way:
{code}
org.apache.maven.plugins
maven-compiler-plugin
2.1
${maven.compile.source}
${m
Hi Simo,
Funny, I don't believe think that compiler complained at all. I will double
check soon and try some other compilers and let you know soon.
Thanks,
-Elijah
On Mon, Sep 19, 2011 at 8:12 AM, Simone Tripodi wrote:
> Hi Elijah,
> I had e deeper look at your patch and raw more carefully your
Hi Paul,
thanks for the feedback!
I think that your hint is very good but I don't know why something
suggests me that there are situations - like in the web subpackage -
where having a typed Context would prevent undesirable runtime
exception.
Can I ask you please the favor of submitting a patch on
Should the context in the command be parametrized? I don't think
that's such a good idea. Isn't one of the benefits of Chain is that
you don't know which context you might be getting?
Paul
On Mon, Sep 19, 2011 at 10:12 AM, Simone Tripodi
wrote:
> Hi Elijah,
> I had e deeper look at your patch an
Hi Elijah,
I had e deeper look at your patch and raw more carefully your message,
I just have a BIG trouble: when changing the Context interface to
public interface Context extends Map {
}
you can easily note that, in Command interface (just to mention one)
compiler complains:
"Context is a
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 wr
I just submitted a patch to jira as CHAIN-58. This changes Context to
Context.
Thanks,
-Elijah
On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi wrote:
> Hi Paul!
> yes it can be done, of course :) I'm not convinced anyway by the heavy
> notation that, modifying the Context, would impact the Comma
Hi Simo,
Sorry I was late replying. I've been away at a wedding.
Honestly, I'm not a big fan of Command>. I
agree with you that the it is syntactically clunky. Moreover, I'm not
convinced that the Context design needs to be improved other than the
addition of generics. It is a simple tool that do
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 t
The basic context should be Context and then use interface
composition to define other things like:
public interface PropertyContext extends Context,
Map
It can be done... I think :-)
Paul
On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
wrote:
> Hi Elijah,
> I spent some spare time trying to f
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
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 setter
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 composit
16 matches
Mail list logo
