On Mon, 30 Apr 2001, GOMEZ Henri wrote:
> >damn! i wasn't expecting that complex of an answer ;)
>
> The difficulty is in the difference between TC 3.2/3.3 and 4.0
> and the how the connector are written. They're just to highly
> linked in the tomcat core !
Well, someone can reimplement the pr
On Mon, 30 Apr 2001, kevin seguin wrote:
> that's what i've decided to do. my goal is to first get things working,
> at least minimally, then i (or someone else) can address load-balancing
> later. my gut feeling, though, after spending some time on ajp13 and
> tomcat 4 is it's certainly possib
What about creating a directory jakarta-tomcat/src/doc/notes and
checking in all the "relevant" mail - like this one ? I'm talking about
proposals, technical notes, etc.
Searching the mail archive to find "good stuff" is hard ( given the
noise), and maybe someone could turn various mails into do
On Fri, 27 Apr 2001, Steve Downey wrote:
> The only downside I see is that the security manager triggers the use of
> URLClassloader on a per JSP page basis. As I understand it, this class is
> broken w.r.t. Java 1.1.
Ok, now I'm completely confused - what's the relation between
doPriviledged a
Glenn, I hope you're around...
Can you explain ( again ) the rationale for the doPriviledged() in
PageContextImpl ?
>From what I see, the release() doesn't do anything special, and
init() does only the System.getProperty - but there are other ways to do
that without a full Priviledged.
3.3 s
Hi,
There are few diffs between the runtime for 1.1 and 1.2.
Some of them are obviously due to API changes ( additions mostly,
only one change that I could identify - JspInclude ).
Most are due to changes/fixes that went only in one branch ( various
optimizations for 3.3, security manager for 4
One change - the Constants is used for "constnats" and for logging and
localization.
Constants.message() and getString() will be removed ( both 1.1 and 1.2
runtimes ), moved to JspFactoryImpl.ContainerLiaiason.
I would also like to move some of the constants that are specific to a
particular cl
Hi Mel,
I noticed you used jakarta-tomcat/src/jasper34 for your protoype classes.
If you don't mind, I would like to move them in proposals/jasper34/,
and keep the work in jasper34 in the experimental area until it's ready.
I'll do a small commit - I did a refactoring for the runtime ( 1.1
> While you are at it, the current convention in Tomcat is to use spaces
> rather than embedded tabs for indentation. I know some of the old code
Is it a convention or an absolute requirement ?
Costin
( waiting for the space police to remove my tabs :-)
One quick comment - this should be provided by the servlet container.
( i.e. make sure that destroy() is not called while a servlet is in
progress ). Of course, JspServlet is overriding the container and manage
it's own servlets.
I'll look at the code and try to port it to 3.3 - and send more c
On Tue, 24 Apr 2001, Marc Saegesser wrote:
> Costin, Henri,
>
> You both asked about some simple patches for Tomcat 3.2.2. There will be
> another (hopefully the last) beta release for 3.2.2, so go ahead and commit
> those changes.
Thanks.
> I'm working a bug in Jasper that will certainly re
On Tue, 24 Apr 2001, Brad Cox wrote:
> >In 3.3 we package all the tests as self-contained wars, and the admin has
> >a web-based runner - but it needs more polishing to make it really easy to
> >use.
>
> That's roughly how I meant for a gui to work. A few text boxes for
> options every novice m
Dan,
It seems the most requested ( and important) feature for mod_jk is simpler
configuration - and I think we can do many simple things with a lot of
effect ( sending the config automatically is one - and quite easy ).
Regarding the use of mod_jk for tomcat4 - I would sugest a different
aproac
On Tue, 24 Apr 2001, Brad Cox wrote:
> At 7:23 AM -0700 04/24/2001, [EMAIL PROTECTED] wrote:
> >Anyway - a cleaner solution ( IMHO ) is to just set "stoped" and do a
> >bogus connection. That's what I did in 3.3 - and seems to work fine.
>
> That does sound better. I really hope this gets nailed
Hi Peer,
Great fix - thank's.
I will do the fix in 3.3, and if Marc makes another beta ( for jsp fixes
) it would be great if he takes this one in.
Marc - I know the code pretty well, and this line should have been in. I
don't think it'll affect any other piece of code, getHandlerForPath is
On Tue, 24 Apr 2001, Brad Cox PhD wrote:
> At 7:19 PM -0700 04/23/2001, [EMAIL PROTECTED] wrote:
> >On Mon, 23 Apr 2001, Arun Katkere wrote:
> >In general you need to do something to unblock the accept thread, and 3.2
> >doesn't have this in.
>
> Yes, I remember now. You're absolutely right. You
On Mon, 23 Apr 2001, Arun Katkere wrote:
> In my experience (having started/stopped Tomcat engine programatically via
> ContextManager API in a loop 100s of times), server socket is always closed
> correctly. And looking at 3.2.2 beta 3 source code, both PoolTcpEndpoint and
> SimpleTcpEndpoint cl
On Mon, 23 Apr 2001, Craig R. McClanahan wrote:
> > Yes, I think the session manager should be a separate module, with minimal
> > dependencies on other components.
>
> Given that the 4.0 architecture exists, works fine, lasts a long time,
> ... what you'd want, then, is for the existing Catalin
Fixed for 3.3, I'm not sure it's very easy for 3.2.2.
The threads are waiting in accept, so one solution is to set "stopped" and
make a dummy connection. The problem is that there are few places that
need to be fixed to support stop/start ( another bug was that logger and
session expirer thread
Typos...
> That doesn't mean 3.3 _modules_ are restricted in any way to JDK1.1.
> Tomcat has already at least 2 modules that are JDK1.2 compatible.
Are using JDK1.2 specific features.
>
> The restriction ( the way I understand it at least ) is that tomcat4
> should provide a (basic) se
On Mon, 23 Apr 2001, Craig R. McClanahan wrote:
> 3.3 wants to maintain JDK 1.1 compatibility -- at least that's the last I
> heard; maybe attitudes are changing.
My attitude is changing indeed - I would like to propose J2ME
compatibility for tomcat 3.3 :-)
( the only problem is one class that
+1
Costin
On Sun, 22 Apr 2001, Kief Morris wrote:
> I would like to propose Bip Thelin as a new committer. He has made a number
> of contributions of patches over the past several months, including SSI and
> JDBCRealm, and most recently, is doing solid work on session persistence.
>
> Kief
>
On Mon, 23 Apr 2001, Steve Downey wrote:
> 360 and 412 look like they might cause me some headaches. Are you -1 on
> fixing them, or -0? That is, should I bother or not?
I'm +1 on fixing them - the list reflects what I think whould have high
priority ( i.e. things fixed in 3.2 but not 3.3, spec
Hi,
I finished reviewing bugs marked as LATER with ID<500.
There are 5 bugs that we should fix for 3.3:
345 - Date header
348 - Security roles
375 - // security checking - revert to paranoid path checks
454 - mod_jk spawning (hunged ) apache processes when tomcat is down
( maybe later -
Hi Jochen,
Thank you for this patch - it is something very needed. I don't think this
can make it for 3.2.2 release ( but it can be made available for people to
compile as a separate module), but it'll be available for 3.3 ( I hope
in the default distribution - but we do have the option of makin
> > - "commons"-style components. Even if we'll use explicit interfaces for
> > ...
>
> I'll need to review the commons project to adopt any
> standards that are in play there, but I don't see a
> problem. This brings up some things I'll need to know
The important ideas ( for this discussion )
Hi Mel,
As you know, we are on the same page on the main issue ( refactoring
jasper), but there are few details... ( sorry for responding so late)
First, I think we need to agree on the goals :-) Your proposal is great,
but I would like to make explicit the following ( at least ):
- clean sepa
On Thu, 19 Apr 2001, GOMEZ Henri wrote:
> What about checking also the build.sh for Tomcat 3.3 :)
What about removing the build.sh/build.bat completely ( at least from
3.3).
It used to be a workaround, when ant didn't had support for classpath.
Proposal: remove build.sh/build.bat, use "ant".
On Thu, 19 Apr 2001, GOMEZ Henri wrote:
> >I think Dan is right on this one - improving the configuration
> >of mod_jk
> >is probably the most important thing, and merging with mod_webapp and
> >porting it's protocol and config mechanism would be a good way
> >to do that.
>
> I agree that int
Hi,
> yesterday I played around with the source code of mod_jk because it does
> not work for HP-UX 11. In order to test some things, I need to know
> something about the expected behaviour (the Faq-O-Matic is out of order
> at the moment):
That's great, can you compile it ? ( there is a bug in
Henri,
I think Dan is right on this one - improving the configuration of mod_jk
is probably the most important thing, and merging with mod_webapp and
porting it's protocol and config mechanism would be a good way to do that.
I think the best way to do that would be a revolution ( like jasper34
Hi Bojan,
It's the third ( no time ), I am deep into some charset bugs and jasper
and most developers are busy with various projects.
You may file a feature request on bugzilla, attach you patch - this way
it'll be recorded.
Or send few more patches ( there are many open bugs, most of them are
> Why not use mod_webapp/mod_jk to start the
> web-connector sub-project allowing us to remove many question
> related to connectors from Tomcat user/dev lists ?
>
> The same web-connector project could be used against
> Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat.
> Any project unde
On Tue, 17 Apr 2001, Craig R. McClanahan wrote:
> * Configuration complexity - The above issues can often be dealt with
> by tediously configuring everything twice (once in web.xml and once
> in httpd.conf). A better approach would be to make ajp12/ajp13
> auto-configure Apache from the we
On Tue, 17 Apr 2001, Jon Stevens wrote:
> > mod_jk is the de-facto standard to link a web server (not only
> > Apache) to tomcat. mod_webapp is really new and having it
> > incompatible with mod_jk will raise more questions and requests
> > than necessary.
>
> Huh? mod_jk is not 100% compatible
On Fri, 13 Apr 2001, Glenn Nielsen wrote:
> I have tested Tomcat 3.2.2 B3 with and without the Java SecurityManager
> on a Solaris x86 system using J2SE 1.3. I found one minor problem in
> the tomcat.policy file, after fixing that all watchdog test were OK.
>
> I committed the changes to the to
Hi,
While Mel is working on the JspServlet proposal, I thought it would be a
good idea to send my notes on jasper.
I looked at both "branches" of jasper, with the idea of trying to merge
them while preserving each "personality".
As I expected, most of the code is still common, with only few va
On Thu, 12 Apr 2001, Glenn Nielsen wrote:
> Reloading is not an issue in the Tomcat 4 version of Jasper. It no longer
> uses the .java/.class versioning system because it uses a URLClassLoader for
> each JSP page compiled into a servlet. That way if the page is recompiled
> the URLClassLoader f
Please, don't start this ( again ). You can read the archives ( every six
months some smart people ask this question ), or check other mailing lists
for the same question.
Use whatever other people are using in that project. In tomcat you'll
notice the 4 space indentation, and 09 ( TAB ) is use
On Thu, 12 Apr 2001, Luise Massimo wrote:
> Hi all,
> i have a simple question for which i haven't found an answare by myself: why
> for the same JSP page tomcat generate a new java/class file in work dir for
> every modification ?
Reloading issues.
"Normal" reloading ( that is used for regula
On Wed, 11 Apr 2001, Greg Wilkins wrote:
> [EMAIL PROTECTED] wrote:
>
> > That's reasonably easy to do ( in 3.3 workspace the Log is just an
> > independent class ,with no dependency on tomcat internals - except that
> > it's in tomcat.util.log package ).
>
> The only hestiation I have with
Hi,
If you want to save us a lot of time, could you get a demo of OptimizeIt
or JProbe ( or use -hprof option in java ) and send the result.
( either of those will show you the allocated objects - if there is a leak
then you'll see it there, just run 1 requests, GC, repeat few
times, and lo
Hi Jan,
> > Under tomcat 3.2.1, a request for "blah/" generates a 302 redirect to
> (also 3.3m2)
> > "blah/index.jsp" rather than just serving up the content of index.jsp!
> Currently, it appears that if I wish to avoid broadcasting my use of
> JSPs, I've just got to code servlets and use thos
Thanks Bojan,
I'll try to find the problem.
The SessionIdGenerator ( or another module that generates random ids
) should fill the id with random during ServerSession initialization.
session.setState( ... ) should notify all modules that a session object
was created ( or recycled ) and needs
On Tue, 10 Apr 2001, Mel Martinez wrote:
> The design philosophy used is to create a 'toolkit' of
> factory and accessor methods for creating and
> accessing services required by Jasper adapter
> implementations such as JspServlet, JspC and
> JspInterceptor.
The "toolkit" idea is perfect for wha
On Tue, 10 Apr 2001, Greg Wilkins wrote:
> >...
> > The end result will be a more portable jasper - that will be usable in
> > multiple containers with minimal pain ( and with enough hooks to allow the
> > container to provide specific features and optimizations ).
>
> Excellent - That sounds m
On Tue, 10 Apr 2001, Bojan Smojver wrote:
> > The code if the option "useDevRandom" is not set is the same as before.
> > If you set useDevRandom="true" then /dev/random will be used.
>
> Very cool. Where do I whack this option? server.xml? I know it must be a
> silly question to ask on Tomc
On Mon, 9 Apr 2001, Jon Stevens wrote:
> on 4/9/01 2:13 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > We are planning a small refactoring of jasper ( at least for tomcat3.3,
> > but one goal would be to merge the 2 branches we have in jakarta ). I
> > don't know when this will happen,
Hi Greg,
We are planning a small refactoring of jasper ( at least for tomcat3.3,
but one goal would be to merge the 2 branches we have in jakarta ). I
don't know when this will happen, but I know few people are looking
into that.
Mel already made a proposal for improving JspServlet, and I will
On Sat, 7 Apr 2001, Marc Saegesser wrote:
> The problem really lies in the implementation of
> sun.net.www.protocol.file.FileURLConnection. Costin's idea of creating a
> Tomcat implementation that works the way we need it to work has some merit.
> I'll look at what it would take implement a URLC
Marc,
What about removing the use of URL ? We can create a local URL object that
works in a deterministic way - that would be much cleaner than guessing
the OS and doing workarounds.
Costin
On Fri, 6 Apr 2001, Marc Saegesser wrote:
> As usual, the problem turned out to be deeper then I first
On Thu, 5 Apr 2001, Jon Stevens wrote:
> on 4/5/01 10:13 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > So we need to fix it :-) After all that's one of the diferences between
> > the zillion templating systems and jsp - a spec with a wide variety of
> > implementations that improve.
>
On Thu, 5 Apr 2001, Mel Martinez wrote:
> The above paragraph describes a 'fundamental issue'
> that has absolutely nothing to do with the Java Server
> Pages specification and, rather, entirely to do with a
> particular implementation of the specification. As
And most of the other arguments ar
On Tue, 3 Apr 2001, Amy Roh wrote:
> (1) According to NCSA "virtual gives a virtual path to a document on the
> server." So no matter which context you're in, should try to access "test.txt" on your server's
> root, right? Does virtual have to start with "/" always? I would think
> so. If no
Hi Victor,
Could you send the patches too :-)
Costin
On Mon, 2 Apr 2001, Vitayaudom, Victor wrote:
> Please note patch 1 and especially 4.
>
> Just helping out.
> -Victor
>
>
> patchfile1.txt
> --
> I'm interested in sending a patches to fix a problem I'm
> encountering.
yOn Sat, 31 Mar 2001, Craig R. McClanahan wrote:
> On 31 Mar 2001 [EMAIL PROTECTED] wrote:
>
> > After all the generated code depends anyway on the details of the jasper
> > runtime - it extends jasper.runtime.HttpJspBase.
>
> Don't forget that you cannot make this assumption universally.
Hi Mark,
> I am rather confused as to which CVS tag I should be working against. Out
> of the following list of tags, which should I be using?
The main branch ( i.e. "cvs co jakrata-tomcat" - without a -r ) is the
development version.
Each tag marks a release point.
For each stable release
On Fri, 30 Mar 2001, Marc Saegesser wrote:
> 1. Classes loaded by the container take precedence over classes from Jar
> files in WEB-INF/lib. In tomcat 3.x there really isn't anything we can do
> about this. The Servlet 2.3 (Proposed Final Draft) specification allows
> containers to let classe
On Fri, 30 Mar 2001, Mel Martinez wrote:
> I don't have the time to do much more than that! That
> Damn Day Job(tm) keeps getting in the way! :-)
Yea, believe me, I know what you mean, you're not the only one :-)
Costin
On Fri, 30 Mar 2001, Mel Martinez wrote:
> --- Steve Downey <[EMAIL PROTECTED]> wrote:
>
> I must admit to not being totally sure whether
> co-opting the current 'Constants' and 'Options' class
> families is the best naming for this, but they do
> clearly indicate the difference in scope. I coul
On Thu, 29 Mar 2001, Mel Martinez wrote:
> activities that should be orthogonal. The only
> dependency should be that the Compiler is a consumer
> of the products of the Mangler.
+1
> I think the problem starts with the idea to make a
> JspLoader that 'loads JSP files just as if they were
Jsp
On Thu, 29 Mar 2001, Steve Downey wrote:
> doing some static analysis, based on class use of other classes, it looks
> like this constellation of classes could easily be factored out into their
> own package:
>
> org.apache.jasper.compiler.Compiler
> org.apache.jasper.compiler.Mangler
> or
On Wed, 28 Mar 2001, Matthew L Daniel wrote:
> > ( BTW, my interest is more in the jsp->java convertor area, I would be
> > interested to try a more customizable generator that would use XSL
> > templates, but that depends on a modularization and refactoring that would
>
> I remember back i
Mel,
Regarding the names and the scope of the changes.
If we are going to do some refactoring ( and that's going to require
work and testing anyway), then we should do it on a slightly broader
scope, not only local to the servlet interface.
Instead of org.apache.jasper.servlet33, I would sugge
On Wed, 28 Mar 2001, Steve Downey wrote:
> The second most common cause of bugs in Jasper is confusion over when to use
> File.separator and when to use '/'. It's hard to keep track of, since Jasper
> does deal with both files and URIs. And the File methods are used to
> regularize some URIs.
>
On Tue, 27 Mar 2001, Craig R. McClanahan wrote:
> > The glass is half-full as well - because at least with
> > the servlet api it is _possible_ to implement those
> > services portably and thus provide a portable JSP
> > compiler.
> >
>
> When Tomcat 4.0 was created, one of the goals was to eli
> > - JspServlet must manage the servlet lifecycle - the container can no
> > longer treat jsp-generate-servlets the same as regular servlets
> >
>
> This is a limitation of the servlet api and thus the
> lack of access to a consistent set of servlet engine
> features necessary for full servlet
>
> 1) I don't off-hand know of any other generalized way to make a portable JSP
> compiler that can be plugged into any servlet 2.2 engine other than as a
> servlet. I'm not sure how that limits us feature-wise, other than the fact
> that it adds a layer of indirection between the request on th
Hi Casey,
There is a small problem when building with jikes. The
TagPoolInterceptor depends on jasper runtime, which depend on the servlet
api - I think it should be moved into the facade ( for now ). We do need a
serious refactoring of jasper - and that would clarify a lot of
things. There is no
On Mon, 26 Mar 2001, Steve Downey wrote:
> > 1. The jsp->java translator.
> >
> > 2. The java->class compiler
> >
> > 3. The Mangler ( managing name mappings )
> >
> > 4. Runtime - that should be completely independent of all
> > other pieces,
> > since jasper-generated servlets should run
> However, this does point to the need for default
> behavior of tomcat session generation code (or any
> interceptor or module code) in the absence of expected
> configuration info in server.xml.
That's a good point, but I'm wondering how could it be implemented.
The whole idea of modules is tha
> 1. In general the Java SecurityManager implemenation in Tomcat 4
> and Jasper has significant improvements and is much cleaner.
True. The SecurityManager in 3.3 is working fine for now ( Glenn is also
the main author for the 3.x sandboxing ), with all watchdog passing - but
a refactoring will
> Temporary(?) fix to stop crashes when creating a new Session in
> embedded use of Jasper (i.e. as standalone JspServlet ). Problem may
> occur in other situations as well, I'm not sure.
>
> Problem: When
> SimpleSessionStore.SimpleSessionManager.getNewSession() is called (as a
> result
Hi Mel,
In my view, jasper is composed from at least 5 big components:
1. The jsp->java translator.
2. The java->class compiler
3. The Mangler ( managing name mappings )
4. Runtime - that should be completely independent of all other pieces,
since jasper-generated servlets should run withou
Hi,
The thread pool changes are almost done, with better interfaces and
monitoring and even less coupling ( it no longer uses the Log, but
generates Events - the only dependency is now JDK1.1 ).
The code is almost the same as functionality ( except for additional
sugar ), and should replace the
On Sat, 24 Mar 2001, Ignacio J. Ortega wrote:
> Hola a Todos:
>
> Why is needed the core classes on the commons classloader?
Well, it's not needed - i.e. it should work very well with it in
the container classloader. If you want to move it - I'm fine.
It was helping in the ProfileLoader - sinc
Hi Mel,
I'm working on the SimpleSessionStore, it had problems with recycling the
ServerSession objects and I tried to fix them while removing some
complexity and spaghetti code.
I'll check that - probably after this weekend I'll be done with the
session and threading changes.
Regarding Messa
On Fri, 23 Mar 2001, GOMEZ Henri wrote:
> >Since mod_jk is using just a few APR-like functions, the transition
> >woulnd't be difficult - but it's important to do it at the right time.
> >
> >And IMHO that should come as a decision from tomcat-dev - I would feel
> >very bad if Henri or Dan would
On Fri, 23 Mar 2001, Casey Lucas wrote:
>
> I noticed that for PageContextImpl you made a comment about removing
> the log dependency. Was this just because it was used on a case that
> "shouldn't happen" or is there another reason why jasper components
> shouldn't rely on tomcat logging code?
I don't think we can or should do anything about that.
Even if it would be possible to find a workaround ( and that may take a
huge amount of work ), fact is that the JVM will still have a bug and some
user code ( servlet, etc ) may make it hung in production environment.
So you should consid
On Wed, 21 Mar 2001, Aaron Mulder wrote:
> I'm wondering if Tomcat won't eventually have a separate custom DD
> for WARs (like WEB-INF/tomcat-web.xml or whatever), in which case we'd
> want to create a Tomcat plugin in addition to the standard servlet spec.
That would be great, a deploymen
On Thu, 22 Mar 2001 [EMAIL PROTECTED] wrote:
> You are 100% correct. Let me give a bit more detail. Covalent is
> currently using APR in many of our modules that work with Apache 1.3.
> This is actually harder than a module that works with a different web
> server, because there are some overla
The original intention for mod_jk was to use APR whenever it's ready. Gal
wrote most of the "general" code trying to stay as close as possible to
APR semantics.
Since mod_jk is using just a few APR-like functions, the transition
woulnd't be difficult - but it's important to do it at the right t
On Wed, 21 Mar 2001, Mel Martinez wrote:
> StringManager's getString() currently deals with the
> MissingResourceException by simply returning a String
> consisting of a warning message about not being able
> to find the particular key. I don't think that is
> correct behavior. I think it shoul
On Thu, 22 Mar 2001, Ignacio J. Ortega wrote:
> better.., not only 4.0.. This are really great news, but i continue
> thinking it's better to spread resposabilities a s much a we can, and
> bugzilla components are a great way to spread such resposabilities..
A big +1 !
Henri and Dan are a perfe
What about 33 sec. ? It matches the version :-)
( seriously - does the HTTP spec have any number ? If not, can we use
whatever apache is using ? )
In any case - 300s is better than no timeout - and if it's too much we can
reduce it later ( and make it configurable anyway ).
Costin
On Wed, 2
On Wed, 21 Mar 2001, Casey Lucas wrote:
>
>
> Casey Lucas wrote:
> >
> > Just curious... why did you take out the buffer size double? Is that too
> > much memory to sacrifice? Someone ? recently sent this in as a performance
> > improvement patch.
Ops :-)
No, there is no problem with doub
On Wed, 21 Mar 2001, Mel Martinez wrote:
> Would the following be an acceptable solution?
>
> We change the
> Constants.message(key,args,verbosityLevel) method
> behavior so that if getString(key,args) throws
> a missing resource exception that it logs using the
> key itself as the log message.
Mike,
I'm not sure I understand ( not your mail - the "available" definition ).
Isn't availabe supposed to return how many bytes can be returned without a
read() on the "primary" source ( that would block ) ?
What you describe is slightly different - and I'm not sure it's a good
idea. In any
Hi Claude,
It would be great if you could help improve the
scalability - it's a difficult task, and we need
all the help we can get :-)
If tomcat shuts down with 150 threads I would suspect
it's a JVM problem - I did tests up to 200 threads.
It is slow - but that's a different issue ( 3.3 will
Hi Tal,
The timeout patch will certainly go into tomcat3.3, and I think Marc will
add it to 3.2 also - it's a good solution and I don't think it can brake
anything.
I was thinking about what we can do for a more general solution - and
looking at the code I think there are few easy things that n
Hi,
I volunteered to resolve the charset issues, the problem is very complex
and difficult ( and I had very little time for that ). (I'm also an 8859-2
user).
In other words - I need help ( patches, ideas, code to reproduce etc
) ... This is too big and scary issue - and I don't feel confident e
Hi,
I had a (long) weekend without computers. But I still found one and read
the mail once - and your report is very serious and important ( and not
easy to fix ). You have (at least ) my full attention. The read
timeout will be checked in soon - but the general problem ( with a servlet
hanging
On Fri, 16 Mar 2001, Pier P. Fumagalli wrote:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > I still think it would be a good idea to merge mod_jk and mod_webapp, even
> > if Pier is not going to touch 3.x code. Some of the ideas are good, and
> > getting them into mod_jk will be good for
Hi,
Please vote for Casey Lucas as commiter.
Casey is working on various optimizations in Jasper, with some
very promising results ( tag pooling ). He is working on supporting
both branches of jasper, and create container-specific adapters.
Costin
Dan, Henri,
Remember the goal - to have a high quality connector and servlet
container.
Whatever brings us closer to that is good.
Right now there are 3-4 people fixing bugs and working on mod_jk - and you
2 have probably the most knowledge about it.
I was hoping that by moving it in a sepa
On Thu, 15 Mar 2001, Paulo Gaspar wrote:
> What hapenned to 3.3 nightly builds?
>
> Not much at:
> http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3/
I'm working on it :-)
Sorry about that.
Costin
+1
Costin
On Thu, 15 Mar 2001, Dan Milstein wrote:
> I would like to propose Mike Braden ([EMAIL PROTECTED]) as a new
> committer. He has contributed very useful patches to the user docs, has
> fixed bugs in the ApacheConfig class, and has been a helpful presence on
> this list, both in discus
+1 for 3.3
+1 for 3.2 if the code change is just adding few methods ( that can't
affect anyone ) and a one line change in StaticInterceptor
( and if the release manager is comfortable with that - but that's the
default :-)
Costin
On Wed, 14 Mar 2001, Arieh Markel wrote:
> We are about to rele
On Wed, 14 Mar 2001, Dan Milstein wrote:
> I don't see the advantages to having a separate project for the connectors.
> Can someone explain that to me?
I don't think the proposal meant a separate top level project, with
separate list, etc.
It meant to decouple mod_jk and the connector from to
401 - 500 of 806 matches
Mail list logo
