At this stage, I unit test reproducing the issue would be helpful.
On 16.08.2012 19:21, Chris Rompot wrote:
We are doing the same with a HashMap, except our key is an class (with
appropriately implemented hashCode()) composed of two String attributes.
Robert Voliva-2 wrote:
We're using a String, the context name, as the Map's Key.
private final Map<String, LoggerContext> synchronizedContextMap;
this.synchronizedContextMap = Collections.synchronizedMap(new
HashMap<String, LoggerContext>());
On Thu, Aug 16, 2012 at 11:20 AM, ceki <c...@qos.ch> wrote:
On 16.08.2012 18:01, Chris Rompot wrote:
Ceki Gulcu wrote:
If my memory serves me correctly, the context selection code has not
changed significantly since 0.9.28.
How do you perform context selection? Is it JNDI based? Again, what
happens when you revert to logback 0.9.28?
--
Ceki
http://tinyurl.com/proLogback
We recently noticed the same problem using logback-classic version
1.0.6.
We
store our LoggerContexts as values of a static HashMap. I have verified
that
the keys used to retrieve the appropriate LoggerContext have distinct
hash
codes. In the example that we noticed, the appropriate context was used
on
2012-08-15 11:48:58 - 15:48:07 after which it was no longer used. Log
entries that should have gone to it were mixed in with those for a newly
created context from 2012-08-15 15:48:28 on.
LoggerContext does not implement hashCode() nor equals(). What is the key
used to retrieve values in the map?
--
Ceki
http://tinyurl.com/proLogback
--
Ceki
http://tinyurl.com/proLogback
_______________________________________________
Logback-user mailing list
Logback-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-user
