getThreadLocalVariable or getThreadLocalContext?
On Thu, Oct 3, 2013 at 9:21 PM, Senaka Fernando wrote:
> Hi Sameera,
>
> I believe that eventually, we should end up getting rid of everything
> #getCurrentContext,
> and then renaming #getThreadLocalVariable to #getCurrentContext isn't it?
> IM
On Thu, Oct 3, 2013 at 9:21 PM, Senaka Fernando wrote:
> Hi Sameera,
>
> I believe that eventually, we should end up getting rid of everything
> #getCurrentContext,
> and then renaming #getThreadLocalVariable to #getCurrentContext isn't it?
> IMHO, the thread local story was needed to differenti
Hi Sameera,
I believe that eventually, we should end up getting rid of everything
#getCurrentContext,
and then renaming #getThreadLocalVariable to #getCurrentContext isn't it?
IMHO, the thread local story was needed to differentiate between the
thread-local model and the non-thread-local model in
Hi Sanjiva,
This method first check whether an instance of the CarbonContext is stored
in the MessageContext, if not checks in the ConfiguratoinContext. If both
of these checks fails, this method returns the thread local variable. This
has caused issues during this 4.2.0 release. Thats why we thou
Sameera isn't CarbonContext.getCurrentContext() supposed to return the
context associated with the current thread???
On Tue, Oct 1, 2013 at 11:45 AM, Sameera Jayasoma wrote:
> Hi Folks,
>
> Some of you may be wondering why we are doing this change now. The
> simplest reason is, to ensure the co
Hi Folks,
Some of you may be wondering why we are doing this change now. The simplest
reason is, to ensure the consistency of its usage.
Over the past few years somehow we've ended up adding more methods to this
API and also ended up putting two different set of APIs for setting and
getting the C
