On Tue, 25 Sep 2001, Bojan Smojver wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Hi Bojan,
> >
> > +1 - looks very good, it'll be a great 'first commit'.
> >
> > ( 'normal' case with only global modules is not affected in any way, and
> > for local modules it'll do the right thing, and update the con
[EMAIL PROTECTED] wrote:
>
> Hi Bojan,
>
> +1 - looks very good, it'll be a great 'first commit'.
>
> ( 'normal' case with only global modules is not affected in any way, and
> for local modules it'll do the right thing, and update the context ).
Thanks. Wouldn't be able to do any of it withou
Hi Bojan,
+1 - looks very good, it'll be a great 'first commit'.
( 'normal' case with only global modules is not affected in any way, and
for local modules it'll do the right thing, and update the context ).
Costin
On Tue, 25 Sep 2001, Bojan Smojver wrote:
> This seems to do the trick. I've
@@ -184,6 +184,14 @@
ContextManager cm=ctx.getContextManager();
if( fullReload ) {
+Vector sI=new Vector(); // saved local interceptors
+BaseInterceptor[] eI;// all exisiting interceptors
+
+// save the ones wit
One thing to note about interceptors is that the behavior is intended to
be as close as possible with Apache modules, IIS filters and NES SAFs.
If you read the docs for the 3 web servers you'll notice an amazing
similarity between their extension mechanism ( which at least in Apache is
als
Excellent,
Please switch from GPL to Apache...
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> -Original Message-
> From: Antony Bowesman [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 22, 2001 7:47 AM
>
> Hi Filip,
>
> Filip Hanik wrote:
> >
> > Hi,
> > I'm currently part of a project that is writing an open source
> > Tomcat book, http://sourceforge.net/projects/tomcatbook.
Hi Filip,
Filip Hanik wrote:
>
> Hi,
> I'm currently part of a project that is writing an open source
> Tomcat book, http://sourceforge.net/projects/tomcatbook.
>
> I have written a document that explains the Tomcat interceptor
> design and how to build your own inte
talk to the dudes. I forsee that
the Tomcat project could reference the book as a documentation. The outline
of the book actually covers almost everything you can do with Tomcat and
Apache together. I just wrote the chapter on the interceptors because I have
dug around alot in the code :)
> - e
that could be improved :-).
Costin
On Fri, 18 May 2001, Filip Hanik wrote:
> Hi,
> I'm currently part of a project that is writing an open source Tomcat book,
> http://sourceforge.net/projects/tomcatbook.
>
> I have written a document that explains the Tomcat interce
Hi,
I'm currently part of a project that is writing an open source Tomcat book,
http://sourceforge.net/projects/tomcatbook.
I have written a document that explains the Tomcat interceptor design and
how to build your own interceptors. I would be happy to receive feedback on
this document fro
>>
>> Right but generally the good frameworks go
>> specificity -> general -> specificty
>
>This seems to describe TC3-HEAD, with the general interface for modules
>being plugged (as interceptors) into specific parts of the
>request/response processing.
Right. But
i's
> >VCL or Java's Swing. And in database interface libraries...
> >
> >In all of these you find events (Hooks) named "onThis", "beforeThat"
> >and "afterSomethingElse". And all this frameworks are built using
> >Object Oriented Pro
Damn, that is somethink I would like very much to see.
Many people indent HTML with spaces - those who code by hand.
Some of them (size conscious) unindent them for production
and sometimes partially indent again for fixing something!
And we often use "font" tags everywhere because of browsers
Quoting "Craig R. McClanahan" <[EMAIL PROTECTED]>:
> You would still need to wrap the response, for example, if your Valve
> wanted to
> modify the data content of the response (such as applying compression,
> or an XSLT
> transformation).
Ok.
BTW, I think compression should be part of the HTT
Remy Maucherat wrote:
> Quoting Jon Stevens <[EMAIL PROTECTED]>:
>
> > on 1/19/01 11:51 AM, "Craig R. McClanahan"
> > <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Agreed ... I'm talking about the *Apache Tomcat* release cycle, where
> > we
> > > agreed in the release plan to have a feature freeze / b
Quoting Jon Stevens <[EMAIL PROTECTED]>:
> on 1/19/01 11:51 AM, "Craig R. McClanahan"
> <[EMAIL PROTECTED]>
> wrote:
>
> > Agreed ... I'm talking about the *Apache Tomcat* release cycle, where
> we
> > agreed in the release plan to have a feature freeze / bug fix round on
> 4.0,
> > and work tow
on 1/19/01 11:51 AM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:
> Agreed ... I'm talking about the *Apache Tomcat* release cycle, where we
> agreed in the release plan to have a feature freeze / bug fix round on 4.0,
> and work towards a production quality release quickly. API surgery is n
Jon Stevens wrote:
> on 1/19/01 9:38 AM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
>
> > Impact on the overall
> > 4.0 release cycle is more problematic -- I think we would want to do this in a
> > new
> > beta round and add a week of intensive testing to make sure nothing got
> > destab
on 1/19/01 9:38 AM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:
> Impact on the overall
> 4.0 release cycle is more problematic -- I think we would want to do this in a
> new
> beta round and add a week of intensive testing to make sure nothing got
> destabilized.
Remember that Sun does not
Jon Stevens wrote:
> on 1/18/01 4:28 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
>
> > If you change the names and parameter orders a little, you have just quoted
> > the
> > new api for javax.servlet.Filter in the 2.3 Proposed Final Draft.
> >
> > I'd be game to change the Valve APIs
that realy cuts down development complexity.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 19, 2001 05:54
>
> P.S. Those are just few of the reasons behind the 3.x Interceptors. It
> would be great if someone would want
As a "piping" mechanism (as opposed to a "hooking" one) the kind
of thing Donald described is my favorite one.
My other $0.02 are that I agree 100% with Jon on this. People will
get confused if you have 2 different ways of using valves from a
minor version to the other.
Have fun,
Paulo Gaspar
>
Hi Pete,
My goal is to explain why and how interceptors are used in
tomcat3.x. While other solution exist,
the design of tomcat3.x is based on certain design patterns that have
certain advantages ( and disadvantages).
The reasons for choosing this pattern:
1. One of the goals is to integrate
on 1/18/01 4:28 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:
> If you change the names and parameter orders a little, you have just quoted
> the
> new api for javax.servlet.Filter in the 2.3 Proposed Final Draft.
>
> I'd be game to change the Valve APIs to conform to this kind of pattern
Peter Donald wrote:
> [snip]
> I am not saying that Catalinas concept of a valve is completely correct (it
> uses the Anti-Pattern Subvertion of Control - yuck !!) but it is definetly
> a step in the right direction. Personally if I was doing it then I would
> implement Inversion of Control and y
e interface libraries...
>
>In all of these you find events (Hooks) named "onThis", "beforeThat"
>and "afterSomethingElse". And all this frameworks are built using
>Object Oriented Programming Techniques.
I think you are mixing concerns here. I have worked with multi
> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 18, 2001 23:04
>
> One appropriate question to ask yourself, when comparing, is
> "what does having 15
> entry points give me that I cannot get with a single entry point
> approach"? I
on 1/18/01 2:03 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:
> IMHO, copying a web server (written in C, by the way) architecture, in and
> of itself, is not a compelling argument to influence the design of a servlet
> container written in an object oriented language like Java.
+1
-jon
All this will be reviewed and documented - if the release proposal is
> accepted. I would really like to have the 3.x Interceptors discussed in
> detail and any sugestion incorporated ( before the proposed beta).
>
> > control/access to the internals, though does raise the question, how many
oposal is
accepted. I would really like to have the 3.x Interceptors discussed in
detail and any sugestion incorporated ( before the proposed beta).
> control/access to the internals, though does raise the question, how many
> are enough? Are those enough because they now cover all the functiona
31 matches
Mail list logo