On 23/01/2014 12:22, Rémy Maucherat wrote:
> 2014/1/23 Mark Thomas
>
>> http://people.apache.org/~markt/dev/2014-01-23-tccl-tc8-v2.patch
>>
>> It was easier to write, removes more code and the result is easier to
>> read. Unless there are objections I plan to commit this along with some
>> additi
2014/1/23 Mark Thomas
> http://people.apache.org/~markt/dev/2014-01-23-tccl-tc8-v2.patch
>
> It was easier to write, removes more code and the result is easier to
> read. Unless there are objections I plan to commit this along with some
> additional work to migrate other code that is currently do
On 23/01/2014 09:00, Mark Thomas wrote:
> On 22/01/2014 22:03, Rémy Maucherat wrote:
>> 2014/1/22 Mark Thomas
>
>>> I'll see what folks think of the patch so far and maybe explore the
>>> entry/exit option as well.
>>>
>> The first patch however looks more complicated than the "dumb" way IMO.
>
On 22/01/2014 22:03, Rémy Maucherat wrote:
> 2014/1/22 Mark Thomas
>> I'll see what folks think of the patch so far and maybe explore the
>> entry/exit option as well.
>>
> The first patch however looks more complicated than the "dumb" way IMO.
The variation of the code that needs to be run (ret
2014/1/22 Mark Thomas
> I thought about that. There is some coupling between the entry and
> exit methods (the class loader) that the caller would need to retain
> and some standard try/finally plumbing.
>
> There is also an optimisation not to try to change the class loader if
> there is no need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/01/2014 20:48, Christopher Schultz wrote:
>> I'll start again and address my primary concern - the duplicate
>> code. The other aspects I'm happy to think about / discuss
>> further with a view to possibly coming back to them later.
>
> Could t
On 22/01/2014 10:21, Mark Thomas wrote:
> I'll start again and address my primary concern - the duplicate code.
> The other aspects I'm happy to think about / discuss further with a view
> to possibly coming back to them later.
This is the sort of thing I was thinking about:
http://people.apache.
Mark,
On 1/22/14, 5:21 AM, Mark Thomas wrote:
> On 22/01/2014 09:42, Konstantin Kolinko wrote:
>> 2014/1/22 Mark Thomas :
>
>
>
>>> I've been looking at this some more with an eye to reducing code
>>> duplication. I think the thread binding listener could be merged with
>>> the ContainerListene
On 22/01/2014 09:42, Konstantin Kolinko wrote:
> 2014/1/22 Mark Thomas :
>> I've been looking at this some more with an eye to reducing code
>> duplication. I think the thread binding listener could be merged with
>> the ContainerListener. I can't see a good reason to keep them apart at
>> this
2014/1/22 Konstantin Kolinko
> Thus I think that the calls to ContextBindings.bindThread(...) /
> unbindThread(...) as performed by those StandardContext methods are
> needed only during some initial set up. Using them as general methods
> would be a waste. Those methods are overly synchronize
2014/1/22 Mark Thomas :
> On 16/01/2014 15:08, Mark Thomas wrote:
>> On 15/01/2014 15:59, Rémy Maucherat wrote:
>>> 2014/1/15 Mark Thomas
>>>
If folks integrating with Tomcat need to extend / replace what is
currently in StandardContext.bindThread() and
StandardContext.unbindTh
2014/1/22 Mark Thomas
> I've been looking at this some more with an eye to reducing code
> duplication. I think the thread binding listener could be merged with
> the ContainerListener. I can't see a good reason to keep them apart at
> this point. With this in mind, the changes I'm planning are:
On 16/01/2014 15:08, Mark Thomas wrote:
> On 15/01/2014 15:59, Rémy Maucherat wrote:
>> 2014/1/15 Mark Thomas
>>
>>>
>>> If folks integrating with Tomcat need to extend / replace what is
>>> currently in StandardContext.bindThread() and
>>> StandardContext.unbindThread() having a listener for this
On 15/01/2014 15:59, Rémy Maucherat wrote:
> 2014/1/15 Mark Thomas
>
>>
>> If folks integrating with Tomcat need to extend / replace what is
>> currently in StandardContext.bindThread() and
>> StandardContext.unbindThread() having a listener for this rather than
>> having to extend StandardContex
2014/1/15 Mark Thomas
>
> If folks integrating with Tomcat need to extend / replace what is
> currently in StandardContext.bindThread() and
> StandardContext.unbindThread() having a listener for this rather than
> having to extend StandardContext makes sense to me.
>
Ok.
>
> I'm not sure I foll
On 14/01/2014 17:03, Rémy Maucherat wrote:
> Hi,
>
> In Tomcat, entering a context is done simply by setting the context
> classloader and sometimes firing some random events (like the ones from the
> ServletRequestListener). This isn't so good for integration and could use
> improvements, in addi
Hi,
In Tomcat, entering a context is done simply by setting the context
classloader and sometimes firing some random events (like the ones from the
ServletRequestListener). This isn't so good for integration and could use
improvements, in addition to at least one place where this is not done at
al
17 matches
Mail list logo
