openssl s_client ...
Type "R" ( to renegotiate ).
Unfortunately renegotiation is handled transparently and did work quite
well...
Costin
On Tue, Nov 10, 2009 at 10:53 PM, Filip Hanik - Dev Lists <
devli...@hanik.com> wrote:
> I don't think NIO allows a renegotiation as it is today. I will have
On Wed, Nov 11, 2009 at 1:36 AM, Konstantin Kolinko
wrote:
> 2009/11/10 :
> > Author: markt
> > Date: Tue Nov 10 16:57:29 2009
> > New Revision: 834544
> >
> > URL: http://svn.apache.org/viewvc?rev=834544&view=rev
> > Log:
> > Proposal for cve-2009-3555 work-around
> >
> > Modified:
> >tomcat
; On 11/11/2009 12:11 AM, Costin Manolache wrote:
>
>> openssl s_client ...
>> Type "R" ( to renegotiate ).
>>
>> Unfortunately renegotiation is handled transparently and did work quite
>> well...
>>
>>
> bummer, I will see what needs to be
new release or
switch to NIO or APR
connectors ( APR if they upgraded their openssl ).
Costin
On Wed, Nov 11, 2009 at 10:29 AM, Filip Hanik - Dev Lists <
devli...@hanik.com> wrote:
> On 11/11/2009 11:13 AM, Costin Manolache wrote:
>
>> Sorry for my confusion - didn't realize
On Fri, Nov 13, 2009 at 6:44 AM, Mark Thomas wrote:
> Ashish Jain wrote:
>
> > 4) Does this require code changes to BasicAuthenticator
> FormAuthenticator,
> > AuthenticatorBase of tomcat.
>
> Basic and form - no. Base - maybe.
>
> > Please provide your comment and suggestions.
>
> My instinct (t
Luciana Moreira Sa de Souza Signed by -
PrivaSphere AG wrote:
> Hello,
>
> I just added the patch created by Costin Manolache to prevent the MITM
> attack during re-negotiations for JSSE to our platform. I performed some
> tests and at first I found the solution quite elegant. Ne
Will we have installers for it ? Will the installer/release include the
associated libapr ? I assume both native and java
code will be included ? What additional docs will be needed ? Will tomcat
releases bundle it, or just require to download it separately ?
It would be great to have it as separa
Nice.
Few small suggestions:
- for users of ubuntu ( and probably some rpm-based distro ) - it would be
good to include the packages they should install first and have a specific
example.
apt-get install libapr1.0-dev libssl-dev
...
(specific command flags )
It would be even better to have a .d
Yes, JVM is not so good because it changes, I agree /usr/local/lib ( and the
JVM dir ) are only good for people with root access.
What about having 2 options:
- 'system' installation - /usr/local/lib
- 'local' - TOMCAT_HOME/lib/native ( or TOMCAT_HOME/lib/`arch` if same
install is shared on multip
+1
4 years ago the last version, about 8 years ago the first (or 3.0)
release...
I wish we also had a '6.x-minimal' release for people wanting something very
small ( and not using jetty ).
Costin
On Thu, Feb 14, 2008 at 4:05 PM, Mark Thomas <[EMAIL PROTECTED]> wrote:
> All,
>
> The last 3.x rel
+1
Are you going to make any difference between 4.0.x and 4.1.x ? I think we
should drop 4.0.x sooner.
Costin
On Thu, Feb 14, 2008 at 4:12 PM, Mark Thomas <[EMAIL PROTECTED]> wrote:
> All,
>
> Tomcat 4 has been in maintenance mode for some time now with nearly all
> changes either updating libr
On 3/3/08, Remy Maucherat <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2008-03-03 at 15:58 -0700, Filip Hanik - Dev Lists wrote:
>
> > Remy Maucherat wrote:
> > > This problem is a small detail. Much more should be done if you want
> to
> > > do a refactoring: both the mark functionality and readLine nee
On 3/3/08, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > On 3/3/08, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> >
> >> On Mon, 2008-03-03 at 15:58 -0700, Filip Hanik - Dev Lists wrote:
> >>
> >>
> &
What's the current status of commons-logging versus juli/logging ? Do
we still need the dep ?
Speaking of deps - I'm completely confused by tomcat-dbcp.jar - it
seems to break the build ( 'download' ) with JDK1.6, yet I can't find
any usage in the code - and just removing it doesn't seem to hurt i
> > Speaking of deps - I'm completely confused by tomcat-dbcp.jar - it
> > seems to break the build ( 'download' ) with JDK1.6, yet I can't find
> >
>
> that's because DBCP implements interfaces, and only implements the
> java.sql/javax.sql up to JDK 1.5.
>
> > any usage in the code - and just r
I had this on my computer for a while, moved at very slow pace over
the years - but it passes all 'watchdog' servlet and most jsp tests.
I'll post more when I finish sumitting.
Costin
On 3/25/08, Henri Gomez <[EMAIL PROTECTED]> wrote:
> >
> > Added:
> >
> tomcat/sandbox/tomcat-lite/tomcat-coyo
Well, if the _server machine_ is running out of memory - I think
Yourkit/Jprofiler or most java options won't help.
Just make sure you do have the -Xmx option in tomcat - and it's
reasonable ( less than 1/2 of total RAM I would guess ).
Java is very good at using -Xmx for the heap - I never seen i
I think OSGI has some good ideas - it is pretty good at handling class
loaders and loading/unloading modules. On the other side, they are
very 'framework' - and like all other frameworks you have to do all
things their way and they re-invent a lot of wheels ( from logging
APIs to almost everything
On Wed, Apr 23, 2008 at 4:35 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote:
> > Hi to all,
> >
> > Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
>
> The only thing which ever attracts you is pointless hype, it's quit
> I don't know if you noticed, but I have not really been participating in
> Tomcat's trunk development for months, and am only dealing with Tomcat
> 6.0. In trunk or any other future developments, at the moment my plan is
> only to comment (pretty much like Costin does).
I'm actually working
Well, adding OSGI-compatible manifests to the existing jars is not
that intrusive,
and could be easily done in the trunk. AFAIK an Activator is not required - i.e.
if you don't need the BundleContext or to add services, you can have a bundle
that just imports/exports packages.
I agree with Remy th
On Wed, Apr 23, 2008 at 8:36 AM, Henri Gomez <[EMAIL PROTECTED]> wrote:
>
> Silly question, but did experiments with OSGI could be done, first, in
> tomcatlight ?
>
I'm not sure it's the best idea, my goal is to move it out of sandbox,
it already has enough experiments
that need completion. and
First define 'mavenizing' please :-)
If you mean exporting tomcat components in maven repository - fine with me.
If you mean building tomcat with maven instead of ant - the opposite,
absolutely not fine.
Maintaining a separate maven build file - unofficial, i.e. the default
build instructions sti
On Wed, Apr 23, 2008 at 1:17 PM, Henri Gomez <[EMAIL PROTECTED]> wrote:
> > First define 'mavenizing' please :-)
>
> Yes
>
>
> > If you mean exporting tomcat components in maven repository - fine with
> me.
>
> It's allready done (by hand) ?
>
>
> > If you mean building tomcat with maven ins
On Wed, Apr 23, 2008 at 1:38 PM, Henri Gomez <[EMAIL PROTECTED]> wrote:
> > And that would be the reason for -1.
> > If a build system requires intrusive changes and forces a particular code
> > organization - it shouldn't be used.
>
> that's maven phylosophy, not so bad.
The layout may be
I'm not an expert, but I think I can tell you that yes, "hello world"
applications can be upgraded without stopping, real
applications can't.
As long as you use sessions or statics or you make config changes -
you have to restart the webapp.
OSGI is good of having 2 versions of a bundle running at
On Fri, Apr 25, 2008 at 12:49 AM, David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Apr 24, 2008, at 11:11 PM, Henri Gomez wrote:
>
>
> >
> > > I've heard various claims of this nature from osgi zealots, but when
> > > talking to apparent experts the only things resembling this they seemed
> to
> > >
On Mon, Apr 28, 2008 at 11:25 PM, Peter Kriens <[EMAIL PROTECTED]>
wrote:
> Tomcat to really make a lot of sense. Providing OSGi headers seems to
> fulfill
> the immediate need of several groups. However, it would be really nice if
> you
> could provide a service interface like an Http Service (
On Tue, Apr 29, 2008 at 1:44 PM, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-04-29 at 22:09 +0200, Henri Gomez wrote:
> > Just a new thread to discuss about mavenizing Tomcat (OSGI Thread is
> > allready fully loaded and really interesting).
> >
> > Costin told us he didn't want to ch
Well, IMHO the servlet spec is going from bad to worse in terms of
complexity and feature bloat, so
careful what you wish :-)
My point was mostly that we don't have to implement OSGI HttpService, it may
be ok to use them for
modularization but for servlet-specific APIs we should stick with the JSR
We already have eclipse files checked in AFAIK - that counts as the second
build system.
We used to have makefiles too, also in parallel with ant (in 3.0 times).
The goal IMO is that people who like to type mvn can do it - without any
guarantee that
the result will be identical with the official
On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens <[EMAIL PROTECTED]>
wrote:
> Regarding HttpService - I don't think it's a good idea for tomcat.
> > One of the major problems with OSGI ( and we need to make sure we don't
> > fall
> > in this trap ) is the re-invention of common APIs - logging, servle
On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists <
[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
>
> > We already have eclipse files checked in AFAIK - that counts as the
> > second
> > build system.
> > We used to have makefiles too, also in
ik - Dev Lists <[EMAIL PROTECTED]>
wrote:
> Costin Manolache wrote:
>
> > On Wed, Apr 30, 2008 at 11:31 AM, Filip Hanik - Dev Lists <
> > [EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > Costin Manolache wrote:
> > >
> > >
&g
On Wed, Apr 30, 2008 at 5:32 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
wrote:
> Costin Manolache wrote:
>
> > Aren't we in 'comit then review' mode for the trunk ?
> >
> > My understanding was that RTC is in effect for the stable releases, but
BTW - can someone remove [EMAIL PROTECTED] from tomcat-dev ?
It's quite annoying, after each mail I get an auto-reply from them... I
don't think I have karma to do it.
Costin
On Wed, Apr 30, 2008 at 6:06 PM, Costin Manolache <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 30, 200
ires that things
> that are put together are
> highly cohesive. Anyway, no dynamism is the simple instance of dynamism
> ...
>
> I think the remainder of your mail is about this decomposition into
> functional units. I wholeheartedly
> agree that you want to minimize dependenci
Sure - but as it is right now the .classpath file was broken, even if you
download the extra files - there is no mention of the jar.
The alternative fix would be to add the jars ( like we do for ant.jar,
eclipse, etc ) - but given the license and the fact that the default
build.xml excludes them -
This is a proposal for a very small change in tomcat trunk, to make tomcat
easier to use with JConsole.
Right now if you start tomcat 'out of box' and than try to inspect it with
jconsole, you'll only see the 'platform' mbeans
(memory etc). That's because tomcat doesn't use the platform mbean serve
but otherwise I don't think I did anything
> funny until within my web app.
>
>
> Costin Manolache wrote:
>
> > This is a proposal for a very small change in tomcat trunk, to make
> > tomcat
> > easier to use with JConsole.
> > Right now if you start tomc
>From Rainer's email few days ago:
http://svn.apache.org/repos/asf/tomcat/trunk/
I suppose after it's in it may be backported to the stable branches if it
works well and people like it.
Costin
On Mon, May 5, 2008 at 8:26 AM, Henri Gomez <[EMAIL PROTECTED]> wrote:
> > Providing in is just addin
And if the TCK signature tests pass - that's a bug in the tests :-).
We shouldn't touch the method signatures in servlet API.
Costin
On Tue, May 6, 2008 at 2:03 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-05-06 at 08:27 +0100, Mark Thomas wrote:
> > I am leaning towards 4 on the
Hi,
Just one small 'feature' request:
Since InstanceManager in tomcat6 is in such a package ( org.apache - do we
even have permission to use this ??),
could we have some javadocs ?
What are the current plans for the annotation processing / dep injection ?
Is this class the 'root' of all future
a
notation in order to
have the Resource injected.
I'll try searching the mail archives - the comments in the submits don't
seem to have more info than the javadocs or
comments... Again, sorry if it's something obvious.
Costin
On Sat, Jun 28, 2008 at 10:26 AM, Costin Manolach
on
is to share it.
Costin
On Sun, Jun 29, 2008 at 10:45 AM, Filip Hanik - Dev Lists <
[EMAIL PROTECTED]> wrote:
> here's some history on package etc
>
> http://tomcat.markmail.org/search/?q=InstanceManager
>
> Filip
>
> Costin Manolache wrote:
&g
On Wed, Jul 2, 2008 at 11:02 AM, David Jencks <[EMAIL PROTECTED]>
wrote:
>
> On Jun 29, 2008, at 9:43 AM, Costin Manolache wrote:
>
> Also, is there any documentation (or anyone who can explain)
>> DefaultInstanceManager.processAnnotations() ?
>>
>> Sorry, I
I think this is a nice contribution ( haven't reviewed the code in detail
yet ), but seems like a separate enough feature
to be distributed as a separate/optional package.
I can't think of any good reason to include it in the base tomcat distro (
except that a lot of other stuff is there and
should
that
shouln't be used by apps.
A small automated test would be extra nice ( if you really want feedback )
:-)
Costin
On Wed, Jul 16, 2008 at 10:45 PM, Costin Manolache <[EMAIL PROTECTED]> wrote:
> I think this is a nice contribution ( haven't reviewed the code in detail
&
On Thu, Jul 17, 2008 at 7:00 AM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
wrote:
> Remy Maucherat wrote:
>
>> On Thu, 2008-07-17 at 07:39 -0400, Yoav Shapira wrote:
>>
>>
>>> On Wed, Jul 16, 2008 at 9:47 PM, Filip Hanik - Dev Lists
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
I'd like some feedb
Following Filip's example :-)
Please check http://people.apache.org/~costin/startup/ for a new class I
would like to add to tomcat(head), and an associated example/unit test. It
allows a jetty-like mode of programmatic loading/config of tomcat, without
any config file.
I know the 'official' way t
Thanks, my +1 on committing it to tomcat, seems like a good start and a good
example on how to use the
async stuff.
Costin
On Thu, Jul 17, 2008 at 7:50 AM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
wrote:
> Costin Manolache wrote:
>
>> On Thu, Jul 17, 2008 at 7:00 AM, Filip
On Tue, Jul 22, 2008 at 10:17 AM, Filip Hanik - Dev Lists <
[EMAIL PROTECTED]> wrote:
> As promised, here is the vote for inclusion of the bayeux toolkit
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=45413
>
> I think this toolkit should
>
> [X] +1 include it as an independent component,
I'm curious - why do you think warp sounds 'better', or 'faster and more
efficient' than AJP ?
I don't remember any benchmark or major difference. And I think that was the
main reason
it was abandoned - it was just different, without 'better'. In fact there
were even talks to
abandon AJP - since it
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
wont have a lot of new code, quite the opposite, most changes
will
remove code and features ( from the coyote-standalone and tomcat-lite target
).
On Sat, Aug 30, 2008 at 2:11 PM, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-08-29 at 21:13 -0700, Costin Manolache wrote:
>
On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
>
>>
>>
>
> 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
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 Manolac
There are few issues and questions, I'm not sure its as simple as it looks
:-)
For new development - are you going to make changes in both branches ? I
assume there will be
features that can only be done in 1.3.
Also, if we have separate releases of APR - are we going to release binaries
? For bo
On Fri, Oct 3, 2008 at 10:43 AM, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
>
>> There are few issues and questions, I'm not sure its as simple as it looks
>> :-)
>>
>> For new development - are you going to make changes in
ROTECTED]> wrote:
> Costin Manolache wrote:
>
>>
>>> What is the apr version in common linux distros ?
>>>
>>>>
>>>> Depends, Httpd 2.2.+ relies on APR 1.3. SVN as well,
>>> so eventually distros will pick it up.
>>>
>&
Well, there is interest - the tomcat-lite in the sandbox does allow that (
there is even a TomcatLiteNoConnector unit test ).
The code is broken right now - in process of moving part of it to trunk and
adjusting it to be easier to digest. Will take quite a while
before it's ready for an official r
gt; to elicit this helpful information to start with -- instead of getting told
> I was posting to the wrong group and chasing my tail with it.
>
> --
> Jess Holle
>
>
> Costin Manolache wrote:
>
>> Well, there is interest - the tomcat-lite in the sandbox does allow th
I never understood the use of the manual changelog - as opposed to svn log
and good commit messages.
Could we just use that ?
Costin
On Wed, Oct 8, 2008 at 4:24 PM, Filip Hanik - Dev Lists
<[EMAIL PROTECTED]>wrote:
> I'd like for us to start using the changelog for trunk, we're losing a lot
> o
Quick update: I've been working on the async protocol and the proxy,
cleaning up a bit and adding the POST support.
I think it's getting better, but I think I'll leave it in sandbox a bit
more, so the rest of the code gets used with the stable
connectors. IMO it's pretty cool - but not ready, want
On Thu, Oct 9, 2008 at 9:18 AM, Filip Hanik - Dev Lists
<[EMAIL PROTECTED]>wrote:
> Costin Manolache wrote:
>
>> I never understood the use of the manual changelog - as opposed to svn log
>> and good commit messages.
>> Could we just use that ?
>>
> that
On Thu, Oct 9, 2008 at 11:49 PM, jean-frederic clere <[EMAIL PROTECTED]>wrote:
> Costin Manolache wrote:
>
>> On Thu, Oct 9, 2008 at 9:18 AM, Filip Hanik - Dev Lists
>> <[EMAIL PROTECTED]>wrote:
>>
>> Costin Manolache wrote:
>>>
>>&
On Fri, Oct 10, 2008 at 8:03 AM, Tim Funk <[EMAIL PROTECTED]> wrote:
> If we really prefer to be particular about change logs. Then we should
> create a BUGZILLA VERSION called trunk and potentially a new "product"
> called tomcat 7 (or tomcat-unknown). Then any fix first goes into Bugzilla
> with
I think there is a solution that would make everyone happy :-) - put this
code and
everything that depends on it in a separate module ( separate == different
release cycle and binary ). I don't know if it should be in a separate svn
tree, probably
would be better.
Then you can cut a release - and
I would go one step further and not ship jdbc-related components in the
basic distro :-),
and bundle dbcp and jdbc-related code as a separate module.
If someone is using a database - there are few setup steps anyways, and
downloading
a separate tomcat module may be the easiest of them.
From a tom
On Tue, Oct 21, 2008 at 9:00 AM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]
> wrote:
> Yoav Shapira wrote:
>
>> On Tue, Oct 21, 2008 at 11:15 AM, Filip Hanik - Dev Lists
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>> I hear both of your concerns, and I will withdraw the proposal, thanks
>>> for speaking
On Tue, Oct 21, 2008 at 1:05 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]
> wrote:
> Let's get a feel for what we think we should do.
>
> Based on
> https://issues.apache.org/bugzilla/show_bug.cgi?id=46038
>
> I believe (pick only one):
>
> a. [ ] It doesn't belong here, take it elsewhere
> b. [
+0
I kind of liked the functionality ( i.e. write a servlet and have it 'just
work', without web.xml ).
And the annotations have their own problems ( scanning all the classes ).
But to turn this around to my favorite subject - wouldn't be better to
exclude it from the
release ? Maybe this and the
It's getting spaghetti... If you really have to - no need to add 'modules' -
just have them top-level ( i.e. under asf/tomcat ).
What prevents you from tagging ? Tag is cheap AFAIK - just tag the entire
trunk.
I personally hate working with many small repos. I understand the need when
you want di
On Tue, Feb 3, 2009 at 5:14 AM, Remy Maucherat wrote:
> On Fri, 2009-01-30 at 17:44 -0700, Filip Hanik - Dev Lists wrote:
> > I would suggest
> >
> > https://svn.apache.org/repos/asf/tomcat/
> > - site
> > - tc6.0.x
> > - trunk
> > - modules <-- ADD THIS
> > - jdbc-pool
>
On Fri, Feb 6, 2009 at 3:07 PM, Remy Maucherat wrote:
> On Fri, 2009-02-06 at 14:59 -0700, Filip Hanik - Dev Lists wrote:
> > that discussion does exist if you look back into the archives
> > what has changed since then?
>
> The proposed module layout looks so-so to me, and apparently others feel
Please go ahead and remove it.
10 years ago it seemed a good idea to avoid the IPC. Now it seems even
running them
on the same machine is obsolete.
Costin
On Thu, Mar 5, 2009 at 1:03 AM, Mark Thomas wrote:
> Mladen Turk wrote:
> > Mark Thomas wrote:
> >> I stumbled across some code in trunk for
On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez wrote:
> > If you look at my message, my favourite is *not* a JK3. I'm in favor of
> jk
> > 1.3. The difference for me is that 1.3 will be very close to 1.2 without
> any
> > bug architectural changes like migrating to APR.
>
> ok.
>
> > I added some e
On Tue, Mar 24, 2009 at 8:57 AM, jean-frederic clere wrote:
> Costin Manolache wrote:
>
>> On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez
>> wrote:
>>
>> If you look at my message, my favourite is *not* a JK3. I'm in favor of
>>>>
>>> jk
On Tue, Mar 24, 2009 at 8:46 AM, Rainer Jung wrote:
> On 24.03.2009 16:29, Costin Manolache wrote:
>
>> On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez
>> wrote:
>>
>>> Why not moving into mod_proxy? If httpd were approaching a major version
>>>> cha
r operation (it's not really the case today).
>
> This AJP library could be fully APR (and so remove the pain with
> #define / #ifdef...)
>
>
> 2009/3/24 Costin Manolache :
> > On Tue, Mar 24, 2009 at 8:46 AM, Rainer Jung >wrote:
> >
> >> On 24.03.2009 1
On Wed, Mar 25, 2009 at 9:12 AM, Henri Gomez wrote:
> 2009/3/25 William A. Rowe, Jr. :
> > Mladen Turk wrote:
> >>
> >> The problem with mod_proxy and mod_cluster is the
> >> fact they are targeted for a *single* web server (httpd)
> >
> > Which varies from a one off poorly defined protocol how,
On Wed, Mar 25, 2009 at 9:42 AM, Mladen Turk wrote:
> William A. Rowe, Jr. wrote:
>
>> If there's a desire to move ahead with a new connector at the tomcat
>> project, and the branch/release approach is planned to yield stable
>> code that will improve from release to release, why even retain the
On Wed, Mar 25, 2009 at 11:17 AM, Rainer Jung wrote:
> On 25.03.2009 18:38, Costin Manolache wrote:
>
>> This thread was more about where to implement new features - if the goal
>> is
>> a 'redesign
>> from scratch' than maybe sandbox or a branch is a bet
at 5:28 PM, Rainer Jung wrote:
> On 25.03.2009 19:33, Costin Manolache wrote:
>
>> On Wed, Mar 25, 2009 at 11:17 AM, Rainer Jung> >wrote:
>>
>>> Thanks Costin for coming back to this topic. Collecting ideas for major
>>> redesigns could be done, but that was n
I wouldn't be that concerned about configuration - tomcat can still
instantiate the filter
independent of web.xml, like it does with the valve.
Or the filter could be used 'user-space', i.e. user adding the filter
explicitly and not
using the declarative security.
One of the problems with tomcat a
t it's a different one.
Costin
>
>
> On Fri, Apr 3, 2009 at 1:36 AM, Costin Manolache wrote:
>
> > I wouldn't be that concerned about configuration - tomcat can still
> > instantiate the filter
> > independent of web.xml, like it does with the valve.
> &
+1 on removing from trunk.
IMHO AJP as a protocol is a dead end - it is not worth extending, and
certainly not
worth creating a new protocol. We need to pick one of
thrift/protobuf/hessian for
marshaling, and start doing some mux-ing in the protocol. If we end up using
MINA
or some other RPC - all
On Fri, Apr 3, 2009 at 10:24 AM, Mladen Turk wrote:
> Costin Manolache wrote:
>
>> +1 on removing from trunk.
>>
>> IMHO AJP as a protocol is a dead end - it is not worth extending,
>>
>
> Agreed. It has to many limitations to satisfy the
> modern webserve
On Sat, Apr 4, 2009 at 1:10 AM, Mladen Turk wrote:
> Costin Manolache wrote:
>
>>
>>> and certainly not
>>>
>>>> worth creating a new protocol. We need to pick one of
>>>> thrift/protobuf/hessian for
>>>> marshaling, and start
On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk wrote:
> Costin Manolache wrote:
>
>> So in essence you have a new protocol but the sole
>>> difference is how you describe it.
>>>
>>>
>>
>> The API can be something like:
>> - legacyRequ
t maintain current
code ), or do some small addition to AJP, use HTTP, etc.
Costin
>
> thanks
> david jencks
>
>
> On Apr 4, 2009, at 8:42 AM, Costin Manolache wrote:
>
> On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk wrote:
>>
>> Costin Manolache wrote:
>>&
On Sat, Apr 4, 2009 at 9:30 AM, Mladen Turk wrote:
> Costin Manolache wrote:
>
>> On Sat, Apr 4, 2009 at 9:03 AM, David Jencks
>> wrote:
>>
>>
>> My understanding of 'what we talk about' is what to do with mod_jk -
>> deprecate/remove old code
On Mon, Apr 6, 2009 at 3:06 PM, Filip Hanik - Dev Lists
wrote:
> Mladen Turk wrote:
>
>> Costin Manolache wrote:
>>
>>> So in essence you have a new protocol but the sole
>>>> difference is how you describe it.
>>>>
>>>>
>>&g
One suggestion: I think it would be nice to consider scalability - if you
have one tomcat frontend forwarding to 100 backends and acting as a load
balancer - you probably can't afford one connection per thread. Many of the
http forwarders I know use a blocking http client library - I think this
wou
IMHO filters like securityfilter are the right solution for authentication,
users can
use them in any container and have full control over everything.
It is possible to add some hooks into tomcat so that filters like this can
fully replace the
built-in authentication, for example using 'magic' att
Not sure I understand the motivation for moving.
If you must do it - could you wait few days ? I have quite a few changes,
need to fix few tests. Almost done with the work project, will start having
20% time again this week.
On the move - mostly -1, I don't like tree fragmentation.
On May 19, 20
IMHO we should use the modules/ directory as a place to move stuff out
of tomcat 'core', or develop stuff that is optional and only benefits a
subset
of users. They can be included in a "tomcat-all" or "extra" download if
ready,
but they should be released independently.
Tags are pretty cheap - no
Hi,
There are some methods in SSLContext to create and use a new BIO. Are there
any examples/tests for this ? I can't find how to attach the BIO to a
socket, it seems SSL_set_bio is never called, can't figure what
SSLContext.setBIO() does.
Costin
On Tue, Jun 15, 2010 at 11:14 PM, jean-frederic clere wrote:
> On 06/16/2010 07:08 AM, Mladen Turk wrote:
> > On 06/16/2010 12:34 AM, Costin Manolache wrote:
> >> Hi,
> >>
> >> There are some methods in SSLContext to create and use a new BIO. Are
> >&g
On Thu, Jun 17, 2010 at 12:56 AM, jean-frederic clere wrote:
> On 06/16/2010 07:44 PM, Costin Manolache wrote:
> > On Tue, Jun 15, 2010 at 11:14 PM, jean-frederic clere >wrote:
> >
> >> On 06/16/2010 07:08 AM, Mladen Turk wrote:
> >>> On 06/16/2010 12:34
301 - 400 of 426 matches
Mail list logo
