Maybe we should rename the AddHeader to SetHeader and add new Method which extend on this named AddHeader. This method should be marked as deprected. Then we can later remove it.
Same to the handler. What you guys think ? bye Norman Am Montag, den 29.05.2006, 15:02 +0200 schrieb Stefano Bagnara: > Norman Maurer wrote: > > Same szenario on the AddHeader mailet. > > This make me think twice on the previous issue. > Unfortunately we can't change AddHeader to SetHeader for the backward > compatibility issue (right?) > is it better to have consistency between the 2 "processor" classes or is > it better to name the new the right way? > > I don't know. > > Stefano > > > Am Montag, den 29.05.2006, 12:08 +0200 schrieb Stefano Bagnara: > >> Norman Maurer wrote: > >>> Hi guys, > >>> > >>> when working on junit test for AddHeaderHandler i notice that the > >>> AddHeaderHandler use setHeader(String name, String value); . So it not > >>> add a header, it set a header. This is not what i espected when i read > >>> the Handlername. > >>> > >>> So for me are 2 solutions: > >>> > >>> 1. Rename the AddHeaderHandler to SetHeaderHandler > >> +1 > >> > >>> 2. use addHeader(String name, String value) instand of setHeader(String > >>> name, String value) > >>> i prefer the first. What the you think ? > >> So do I: The most common usage is replacing/setting headers. Almost no > >> one use multiple header values. > >> > >> Stefano > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > !EXCUBATOR:1,447af2bf37029524914484! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
