Is it possible to break into two and have ThreadContextMap2 extend them
both and maintain binary and API compatibility?
On 17 January 2017 at 11:28, Apache wrote:
> Yes, at this point it is water under the bridge. Let’s just worry about #3.
>
> Ralph
>
> On Jan 17, 2017, at 9:33 AM, Mikael Ståld
Yes, at this point it is water under the bridge. Let’s just worry about #3.
Ralph
> On Jan 17, 2017, at 9:33 AM, Mikael Ståldal wrote:
>
> It will be hard to find a suitable name for ThreadContextMap2 since it adds
> two unrelated things. Ideally it should be spitted into two interfaces, but I
It will be hard to find a suitable name for ThreadContextMap2 since it adds
two unrelated things. Ideally it should be spitted into two interfaces, but
I guess that will be hard to do without breaking binary compatibility. I
suggest we leave it as it is.
On Tue, Jan 17, 2017 at 4:40 PM, Matt Sicke
Can we rename ThreadContextMap2 to something else, deprecate it, and have
it extend the new interface? Or does that break compatibility? Because if
we can fix the naming scheme while having "alias" interfaces stay in there
(until a theoretical 3.x API), then it'd feel less dirty.
Also, Java 8 woul
BTW, shouldn't we have a putAllValues(final Map map) in
ObjectThreadContextMap?
On Tue, Jan 17, 2017 at 10:13 AM, Mikael Ståldal
wrote:
> I think we named it ThreadContextMap3 since there was already an
> ThreadContextMap2 (which is part of 2.7, and we are stuck with it).
>
> I am fine with rena
I think we named it ThreadContextMap3 since there was already an
ThreadContextMap2 (which is part of 2.7, and we are stuck with it).
I am fine with renaming it to CleanableThreadContextMap (doing it not). But
I think it should still extend ThreadContextMap2 since it is not really
independent of it
Also fine with renaming.
Sent from my iPhone
> On Jan 17, 2017, at 9:07, Remko Popma wrote:
>
> I think it was originally standalone and changed to the current extending
> interface after feedback on the mailing list.
>
> I'm fine with standalone interfaces and having the implementation imp
I think it was originally standalone and changed to the current extending
interface after feedback on the mailing list.
I'm fine with standalone interfaces and having the implementation implement
multiple interfaces.
Remko
Sent from my iPhone
> On Jan 17, 2017, at 6:25, Matt Sicker wrote:
I agree on not extending interfaces. Some of the other context map
interfaces are standalone, and I don't see why TCM2 had to extend anything.
On 16 January 2017 at 15:16, Apache wrote:
> I presume it was named ThreadContextMap3 so there could be a
> ThreadContextMap4 since 3 extends 2 and 2 ext
I presume it was named ThreadContextMap3 so there could be a ThreadContextMap4
since 3 extends 2 and 2 extends the first one. Frankly, I dislike this
practice very, very much. Instead, each interface should be named as you
suggest and NOT extend the prior interface. Instead, the implementation
10 matches
Mail list logo
