How about switching to a Builder like we have been doing for Appenders?
Gary
On Thu, Oct 5, 2017 at 11:38 AM, Mikael Ståldal wrote:
> The specific case is KafkaManager constructor. Can we just add a new
> parameter, or should we overload?
>
>
> On 2017-10-05 19:02, Matt Sicker wrote:
>
>> Since
The specific case is KafkaManager constructor. Can we just add a new
parameter, or should we overload?
On 2017-10-05 19:02, Matt Sicker wrote:
Since appenders are usually final classes, I think the only compatibility
there is calling compatibility. For managers, users can extend the classes,
s
"Within reason" should be the operative term here... IOW, let's not
handcuff ourselves unless necessary.
Gary
On Thu, Oct 5, 2017 at 11:02 AM, Matt Sicker wrote:
> Since appenders are usually final classes, I think the only compatibility
> there is calling compatibility. For managers, users can
Since appenders are usually final classes, I think the only compatibility
there is calling compatibility. For managers, users can extend the classes,
so implementation compatibility would make sense.
On 5 October 2017 at 11:53, Mikael Ståldal wrote:
> We try to keep binary compatibility for appe
Since they are not something end users would normally not be accessing via an
API, I think my answer would be No, it is not essential that binary
compatibility be maintained with managers.
Ralph
> On Oct 5, 2017, at 9:53 AM, Mikael Ståldal wrote:
>
> We try to keep binary compatibility for ap
We try to keep binary compatibility for appenders and layouts in
log4j-core. Does that apply to the managers used by appenders as well?
