On Tue, Sep 2, 2008 at 8:20 AM, Costin Manolache [EMAIL PROTECTED] wrote:
On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
A LOT OF STUFF WHICH CAN BE FOUND IN THE ARCHIVES
Cool. In a nutshell - I like all the ideas.
But while I like the idea of
On Thu, Sep 4, 2008 at 12:47 AM, Jason Brittain [EMAIL PROTECTED]wrote:
On Tue, Sep 2, 2008 at 8:20 AM, Costin Manolache [EMAIL PROTECTED] wrote:
On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
A LOT OF STUFF WHICH CAN BE FOUND IN THE ARCHIVES
Costin Manolache wrote:
A LOT OF STUFF WHICH CAN BE FOUND IN THE ARCHIVES
Cool. In a nutshell - I like all the ideas.
But while I like the idea of ditching Valves/LifecycleListeners - how
does this work when the component needs to work across multiple
ServletContext's? The only reason I see
On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
A LOT OF STUFF WHICH CAN BE FOUND IN THE ARCHIVES
Cool. In a nutshell - I like all the ideas.
But while I like the idea of ditching Valves/LifecycleListeners - how does
this work when the component
On Sat, 2008-08-30 at 20:44 -0700, Costin Manolache wrote:
- Valves/LifecycleListeners versus plain Filters and listeners
Personally, I think the strong type barrier between userland and the
container is nice.
Access to low-level container objects ( which is the 'barrier' you mention
If you read this far - I don't want to start a flame war, but I appreciate
all feedback :-). My current goal is to
'graduate' the first 2 components, the others can stay longer in sandbox or
be moved out - but since they rely on
the first 2 I would have to clone a lot of tomcat code. I think
I for one happen to think this is a great idea (generally).
More specifically, for at least one small web application (where Tomcat is
stripped down and embedded), I have been tempted to strip out the servlet
support code (for a number of reasons).
On Sat, Aug 30, 2008 at 12:13 AM, Costin Manolache [EMAIL PROTECTED] wrote:
and easier to embed variant. I think it's time to see what can be
contributed back to tomcat main branch, what can be
released, and what needs to be retired or moved out.
Overall, a huge +1. I think this is the best
On Fri, 2008-08-29 at 21:13 -0700, Costin Manolache wrote:
I think moving forward, for tomcat-7 and beyond - it would be worth
reconsidering some of the 10-year-old decisions, and
tomcat-lite can be a good example on how things can be done
differently:
I still don't intend to participate in
Remy Maucherat wrote:
I am interested to look at the code like the proxy, and see if what it
can do.
I have been longing for a Java-based load-balancing proxy replacement
for Apache httpd. Essentially with non-blocking IO it would seem high
time to replace Apache httpd with a Java-based
Thanks for all the answers so far - I'll start a new thread for the first
part of the process,
with more details on the coyote changes. The help I need most is review and
comments
from people who spent most time with coyote. The goal of tomcat-lite is to
be small and simple -
hopefully it wont
Hi,
About 2 years ago (closer to 3) I started a sandbox experiment with the goal
of refactoring tomcat to a smaller
and easier to embed variant. I think it's time to see what can be
contributed back to tomcat main branch, what can be
released, and what needs to be retired or moved out.
The code
Hi,
About 2 years ago (closer to 3) I started a sandbox experiment with the goal
of refactoring tomcat to a smaller
and easier to embed variant. I think it's time to see what can be
contributed back to tomcat main branch, what can be
released, and what needs to be retired or moved out.
13 matches
Mail list logo
