[EMAIL PROTECTED] a écrit :
hgomez 2003/10/01 00:54:09
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
More setters for gzip compression support.
Here is the correction for getRemoteAddr(), getRemoteHost(),
getRemotePort().
I
Do you agree to use Coyote2 as the default HTTP connector for Tomcat 3.3.2 ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Remy Maucherat a écrit :
[EMAIL PROTECTED] wrote:
hgomez 2003/10/01 02:43:40
Modified:catalina/src/conf server.xml
Log:
Add comments about gzip settings
+
+!-- Note : To use gzip compression you could set the following
properties :
+
+
Remy Maucherat a écrit :
Henri Gomez wrote:
[EMAIL PROTECTED] a écrit :
hgomez 2003/10/01 00:54:09
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
More setters for gzip compression support.
Here is the correction
Remy Maucherat a écrit :
Henri Gomez wrote:
Urg.
Should I back port change to coyote_10 ?
I'd prefer using the Coyote HEAD in TC 4.1, I think. I'm sick of all
those branches ;-)
+1, less branches, less works
Remy Maucherat a écrit :
Henri Gomez wrote:
Remy Maucherat a écrit :
Henri Gomez wrote:
Urg.
Should I back port change to coyote_10 ?
I'd prefer using the Coyote HEAD in TC 4.1, I think. I'm sick of all
those branches ;-)
+1, less branches, less works
I'll try to build it, and see
Larry Isaacs a écrit :
I have my 3.3.2-dev builds running again. Currently it uses
the MAIN branch of JTC to build util and the coyote_10
branch to build coyote/http11. Once upon a time, I thought there
was a reason that 3.3.2-dev couldn't use MAIN for coyote.
I'm not sure what that reason was
Remy Maucherat a écrit :
Remy Maucherat wrote:
Henri Gomez wrote:
I'll try to build it, and see if it works. I'll also diff the adapter
between the two branches, to see if there aren't any forgotten patches.
If it works well, we can try to include that with 4.1.28.
It doesn't look good: j-t
Remy Maucherat a écrit :
Henri Gomez wrote:
Remy Maucherat a écrit :
Remy Maucherat wrote:
Henri Gomez wrote:
I'll try to build it, and see if it works. I'll also diff the
adapter between the two branches, to see if there aren't any
forgotten patches.
If it works well, we can try to include
[EMAIL PROTECTED] a écrit :
larryi 2003/10/01 19:50:59
Modified:.build.xml
Log:
Update to build using MAIN branch of JTC coyote and http11. The jars are
a little different from coyote_10 version.
Thanks Larry
Remy Maucherat a écrit :
Usually, when a Tomcat branch nears its release, a new branch is created.
However, I only have a few feature ideas that make some sense, and the
problem is that they are minor evolutions (hence, they could perfectly
fit inside the 5.0 branch). This includes:
-
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only
solution. We already have the jvmRoute mechanism, but I think it needs
more examples/documentation so that people start using it.
So you want to do a
Henri Gomez a écrit :
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only
solution. We already have the jvmRoute mechanism, but I think it needs
more examples/documentation so that people start using
Jean-Francois Arcand a écrit :
Henri Gomez wrote:
Henri Gomez a écrit :
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure
tomcat-only
solution. We already have the jvmRoute mechanism, but I think it
needs
more
Henri Gomez a écrit :
Jean-Francois Arcand a écrit :
+1
The security mechanism in TC 4.x and higher (due to digester)
avoid me to use such easy configuration tuning and so we have
to stay with Tomcat 3.3.x for now.
I'm probably missing something herewhy the digester suffer from
Craig R. McClanahan a écrit :
Henri Gomez wrote:
Jean-Francois Arcand a écrit :
Henri Gomez wrote:
Henri Gomez a écrit :
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure
tomcat-only
solution. We already have
Henri Gomez a écrit :
Henri Gomez a écrit :
Jean-Francois Arcand a écrit :
+1
The security mechanism in TC 4.x and higher (due to digester)
avoid me to use such easy configuration tuning and so we have
to stay with Tomcat 3.3.x for now.
I'm probably missing something herewhy
Henri Gomez a écrit :
Henri Gomez a écrit :
Henri Gomez a écrit :
Jean-Francois Arcand a écrit :
+1
The security mechanism in TC 4.x and higher (due to digester)
avoid me to use such easy configuration tuning and so we have
to stay with Tomcat 3.3.x for now.
I'm probably missing
Remy Maucherat a écrit :
[EMAIL PROTECTED] wrote:
jfclere 2003/10/03 03:05:57
Modified:http11/src/java/org/apache/coyote/http11 Constants.java
Log:
getBytes() uses platform's default charset... Bad on my EBCDIC machine!
/**
@@ -239,8 +256,28 @@
/**
* Ack
[EMAIL PROTECTED] a écrit :
mturk 2003/10/04 02:20:59
Modified:jk/native/common jk_ajp_common.c
Log:
Normal C compiler doesn't allow to declare variables
like C++ does.
Revision ChangesPath
1.40 +15 -21
Hi to all,
What about using regexp in HTTP 1.1 connector to include/exclude
browser which could/couldn't use gzip compression ?
May be it could be use also to drop to HTTP 1.0 browser which
claims to be 1.1 compatible, but are not.
CF: Apache HTTPD server
Remy Maucherat a écrit :
Henri Gomez wrote:
Hi to all,
What about using regexp in HTTP 1.1 connector to include/exclude
browser which could/couldn't use gzip compression ?
May be it could be use also to drop to HTTP 1.0 browser which
claims to be 1.1 compatible, but are not.
CF: Apache HTTPD
Remy Maucherat a écrit :
Henri Gomez wrote:
Remy Maucherat a écrit :
Henri Gomez wrote:
Hi to all,
What about using regexp in HTTP 1.1 connector to include/exclude
browser which could/couldn't use gzip compression ?
May be it could be use also to drop to HTTP 1.0 browser which
claims
Well I take my inspiration from what is done in some TC 4.1 Valves...
I know ;-)
Some problematic stuff went away, though (the various mappers), but some
remain.
This feature would really need to be seriously optimized, as ideally
this would be enabled by default.
We could do better as
Remy Maucherat a écrit :
Henri Gomez wrote:
Could I commit my changes and start working on an optimizing version ?
Yes, of course. There's no big rush to start optimizing this ;-) (it's
really disabled by default, right ?)
Yes, since the restrictedUserAgents and restrictedUserAgents are set
Shouldn't we upgrade TC 4.1 and JTC to regexp 1.3 ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
What about the idea to add notes in HTTP 1.1 connector ?
It will mimic the way HTTPD teams using BrowserMatch :
- Disable HTTP 1.0 for some browsers
BrowserMatch Mozilla/2 nokeepalive
BrowserMatch MSIE 4\.0b2; nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch RealPlayer 4\.0
Remy Maucherat a écrit :
Henri Gomez wrote:
Remy Maucherat a écrit :
+0 if disabled by default; -1 otherwise.
All this stuff is inefficient, as it uses Strings. Ie, we take the
byte array we have for the header value, convert it to a String, and
then regexp will likely convert it to something
[EMAIL PROTECTED] a écrit :
remm2003/10/07 06:25:17
Modified:catalina/src/conf server.xml
Log:
- The connector class being used by Tomcat 4.1 doesn't have the
appropriate setters, nor the set-any-property mod that is in 5.0.
As a result, the example won't work right now
[EMAIL PROTECTED] a écrit :
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23675.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
[EMAIL PROTECTED] a écrit :
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23675.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Remy Maucherat a écrit :
Henri Gomez wrote:
Henri Gomez a écrit :
Note: I really love Xerces' error messages.
Great it seems to works with :
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd
Ignacio J. Ortega a écrit :
Hola a todos:
(Many time from my last post, things are settling here, so hope i will
contribute some code in future :) shields up, nacho will be messing
things shortly, now i'm only moderating our lists, and as some person
said time ago moderation is to coding what
FYI :
---BeginMessage---
On 9 Oct 2003, at 08:37, Noel J. Bergman wrote:
Leif,
No worries about time. You replied before I left for the road, and I
won't
be posting this reply until at least 15 hours after your note.
The platform is Solaris. The application is Tomcat. The major
problem is
Remy Maucherat a écrit :
For 4.1.28:
ballot
[ ] Alpha
[ ] Beta
[ ] Stable
/ballot
For 5.0.13:
ballot
[ ] Alpha
[ ] Beta
/ballot
They didn't include my late patch to remove setKeepAlive from JTC ?
We should avoid problem with JDK 1.2/1.3 users ,(
Remy Maucherat a écrit :
Mladen Turk wrote:
One question.
Why do we need to vote on that?
AFAICT the 4.1.27 was stable.
and the 5.0.12 was Beta.
IMHO we should vote on Release/DoNotRelease.
If for example the 5.0.13 is a less quality code then 5.0.12 do not
release at all,
or vote for a Stable,
Mladen Turk a écrit :
-Original Message-
From: jean-frederic clere
Remy Maucherat wrote:
Ignacio J. Ortega wrote:
Sorry to disagree, but it's impossible to build the said binaries
without expensive compilers. (please do not suggest Cygwin)
Why? Is the Makefile broken?
Doesn't
In TC 4.1.x and 5.0.x there is support for endorsed lib but
nothing like this in tc 3.3.2-dev.
Since we may have people (including myself), who will have
to use SDK 1.4.x with Tomcat 3.3.2, I like to add such feature
to Tomcat 3.3.2-dev.
I was thinking put the endorsed in lib/endorsed, ie next
to
Henri Gomez a écrit :
Remy Maucherat a écrit :
Henri Gomez wrote:
Henri Gomez a écrit :
Note: I really love Xerces' error messages.
Great it seems to works with :
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
Bill Barker a écrit :
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, October 13, 2003 1:28 AM
Subject: TC 3.3.2-dev and endorsed lib
In TC 4.1.x and 5.0.x there is support for endorsed lib but
nothing like this in tc
Bill Barker a écrit :
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, October 13, 2003 2:09 AM
Subject: Re: TC 3.3.2-dev and endorsed lib
Bill Barker a écrit :
- Original Message -
From: Henri Gomez [EMAIL
Remy Maucherat a écrit :
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I like basing the resolution on the host appBase a lot more.
Well it will be problematic for all
Remy Maucherat a écrit :
Henri Gomez wrote:
Remy Maucherat a écrit :
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I like basing the resolution on the host appBase
Remy Maucherat a écrit :
Glenn Nielsen wrote:
Henri Gomez wrote:
Remy Maucherat a écrit :
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I like basing the resolution
CF w3c.org
... relative URIs are relative to the location of the resource within
which the entity declaration occurs.
http://www.w3.org/TR/REC-xml#sec-external-ent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
The base should be the location of web.xml (la prochaine fois j'envoie
un mail en français :---)
+1 ;-)
Time for a Tomcat Dev French Forum, to fix these language problems ? ;)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie :
!ENTITY appset1 SYSTEM appset1.xml
!ENTITY appset2 SYSTEM appset2.xml
In Digester.java, at least in the 1.5 release, resolveEntity return
null if publicId is null even if
Craig R. McClanahan a écrit :
Henri Gomez wrote:
CF w3c.org
... relative URIs are relative to the location of the resource within
which the entity declaration occurs.
http://www.w3.org/TR/REC-xml#sec-external-ent
As long as Tomcat uses the Digester.parse() entry point that takes
Bill Barker a écrit :
You will probably get more traction by posting to commons-dev. While
tomcat-dev still has a couple of commons committers (and, no, I'm not one of
them) that hang out here, its not like the old days :(.
Sure but Remy has written the Digester so it must still be commiter :-)
Bill Barker a écrit :
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 14, 2003 12:42 AM
Subject: Re: Digester and external entities with systemId only : Was:
Important requirement : Re: [next] What's next
Jean-Francois Arcand a écrit :
Henri Gomez wrote:
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie :
!ENTITY appset1 SYSTEM appset1.xml
!ENTITY appset2 SYSTEM appset2.xml
In Digester.java, at least in the 1.5 release
As described above, you're trying to use an illegal URL, which goes
above the top of the webapp's namespace. You'll need to use absolute
file: or http: type URLs, or provide your own EntityResolver that
does whatever you want it to do.
The only way to developpers and admins to have it works
Hi to all,
Now that jk seems stabilized a bit, should we focalize on jk2 ?
For instance I added some features to jk (ping/pong) which should be
ported to jk2.
Also I wonder if APR is mandatory for jk2.
I'd like to use APR as a facade to all Operating System calls.
The goal is to hide all the
Mladen Turk a écrit :
+1 to use the APR as mandatory for the mod_jk.
You can rename it to the mod_jk2 after that easily :-)
Heu, the idea is to make jk2 (native2) apr mandatory.
We'll keep jk as it is today.
* the plan
- update jk2 (native2) to use APR only
- port jk add-ons like ping/pong to
Remy Maucherat a écrit :
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its build
scripts. This would add an additional degree of configurability
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can put
${foo.bar} in server.xml, and it will be replaced with the property
value (like in Ant). I didn't know this was present in 3.3.
Yes it was in TC 3.3.1 and
Remy Maucherat a écrit :
Henri Gomez wrote:
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can
put ${foo.bar} in server.xml, and it will be replaced with the
property value (like in Ant). I didn't know
jean-frederic clere a écrit :
Henri Gomez wrote:
Mladen Turk a écrit :
+1 to use the APR as mandatory for the mod_jk.
You can rename it to the mod_jk2 after that easily :-)
Heu, the idea is to make jk2 (native2) apr mandatory.
We'll keep jk as it is today.
* the plan
- update jk2 (native2
Ok, about everybody seems to agree on using apr for jk2
(still waiting Nacho for IIS).
APR side will be to :
- Update doc to indicate that APR is mandatory
- Remove #idef APR
- Use APR for all OS operation and sus will save us from
handling all the #include for all the diverses IO operation
Mladen Turk a écrit :
-Original Message-
From: [EMAIL PROTECTED]
1.17 +17 -0
jakarta-tomcat-connectors/jk/native2/common/jk_channel_un.c
1.6 +3 -3
jakarta-tomcat-connectors/jk/native2/common/jk_mutex.c
1.57 +34 -1
Mladen Turk wrote:
-Original Message-
From: Henri Gomez
Ok, about everybody seems to agree on using apr for jk2
(still waiting Nacho for IIS).
IIS uses APR by default (staticaly linked) for a long time.
APR side will be to :
- Update doc to indicate that APR is mandatory
- Remove
Mladen Turk wrote:
-Original Message-
From: Henri Gomez
I'd like to know who could works on jk2 evolution.
+1
Thanks.
I can (not before friday):
1. Change all the (quasi boolean) functions to return the apr_status_t
instead int (0, 1)
2. aprize jk2_log to use the apr_file_t
3
Mladen Turk wrote:
-Original Message-
From: Henri Gomez
You should know what apr call should be used to mimic select
isn't it ?
PING/PONG right?
Nothing that simple :-).
The magick is apr_poll.
It will require some modifications to the channel in general.
hasinput method has been
jean-frederic clere wrote:
Henri Gomez wrote:
Ok, about everybody seems to agree on using apr for jk2
(still waiting Nacho for IIS).
APR side will be to :
- Update doc to indicate that APR is mandatory
- Remove #idef APR
- Use APR for all OS operation and sus will save us from
handling all
Hi
I could get jkstatus via :
http://mysystem/jkstatus/
But it failed to find
http://mysystem/jkstatus/jkstatus?cfgOrig=1
http://mysystem/jkstatus/jkstatus?cfgParsed=1
http://mysystem/jkstatus/jkstatus?scoreboard=1
My original conf was :
[status:]
info=Status worker, displays runtime
Angus Mezick wrote:
Tried tomcat-user, they don't have a clue about this it seems.
I have this on my jkStatus page when using jk2.
id namelb_factor lb_valueroute errorState
gracefulepCount errorTime
2 web02WWW:8019 1 43 web02WWW:8019 N
Angus Mezick wrote:
Where? I looked there (I think). Could have missed it but I don't see
and documentation on status aside from how to create it. Can you please
tell me the exact page you looked at before replying to my mail that
references epCount, errorTime, lb_value, and lb_factor?
Should
Angus Mezick wrote:
All for jk2.
-Original Message-
From: Henri Gomez [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2003 8:26 AM
To: Tomcat Developers List
Subject: Re: Jkstatus, What does it mean?
Angus Mezick wrote:
Where? I looked there (I think). Could have missed
Done. The machine where it runs is stable but inside FSC firmwall.
Could we copy it somewhere on apache.org to have it mirrored ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
jean-frederic clere wrote:
Henri Gomez wrote:
Done. The machine where it runs is stable but inside FSC firmwall.
Could we copy it somewhere on apache.org to have it mirrored ?
I have copied and adapted it to my account in minotaur.
So we'll have an URL available
Costin Manolache wrote:
Henri Gomez wrote:
And no the who's who ;)
I'd like to know who could works on jk2 evolution.
Until December is very unlikely I'll have any free time.
I would like to help with the unix domain channel and JNI - but
it'll be very limitted... Sorry.
You're more than
Andy Armstrong wrote:
I'm trying to bring the Domino connector up to date with the latest
codebase and I'm running into a problem with connection reuse. The
characteristic is that with connection reuse working normally the first
message from Domino to Tomcat round trips without any problem but
Andy Armstrong wrote:
I'm trying to bring the Domino connector up to date with the latest
codebase and I'm running into a problem with connection reuse. The
characteristic is that with connection reuse working normally the first
message from Domino to Tomcat round trips without any problem but
Andy Armstrong wrote:
Henri Gomez wrote:
Could you get an ethereal dump ?
That mail coincided exactly with my trying to remember whether I had a
network tracing tool installed on this PC - and fortunately I do :)
Ethereal dump coming up.
In such case ethereal is allways your friend.
I'll
Remy Maucherat wrote:
Hi,
I'd like to make a small proposal to do property replacement. Included
are changes that should be made in the digester, and that I'll post on
commons-dev if I have approval.
- Add a get/setProperty to Container. This would allow a property
inheritance across
Glenn Nielsen wrote:
+1
I can help out.
This is a significant change for a minor revision to 2.0.4,
perhaps we should bump it to 2.1 or even 3.0?
Since it's an 'internal rewrite', it should stay 2.x, may be
2.1 could be the right name
But first we should cleanup all jk2 from #iddef APR defines
Mladen Turk wrote:
From: Bill Barker
I could get on-board with this, after Mladen's suggestion to
change the return-type of most methods to jk_status_t.
Without this, mod_jk2 is hopelessly broken (and I'll contunue
to ignore it :).
It's to apr_status_t ;-).
Sill, takes a bit more time
Andy Armstrong wrote:
Andy Armstrong wrote:
UK time here. Still trying to get Ethereal to trace local (intra
machine) traffic. I'm not around tomorrow so it may be Monday before
there's anything to dissect.
Monday came and went. Is anyone else interested in the detail of what
follows
Andy Armstrong wrote:
Henri Gomez wrote:
That's as far as I've got and I'm just wondering whether it'd be nice
to write an Ethereal packet dissector for AJP 1.3 or whether that
would count as displacement activity. Is there anything specific I
should be looking for Henri?
There is allready
Andy Armstrong wrote:
Henri Gomez wrote:
The ajp13 disector was introduced in ethereal some months ago
And I now have a copy of it rather than last year's model :)
Anyway, the conversation looks like this in summary and a (naive)
analysis of the contents of the packets doesn't yield anything
Andy Armstrong wrote:
Henri Gomez wrote:
- FORWARD REQUEST
- SEND HEADERS
- SEND BODY CHUNK
- END RESPONSE (REUSEP:1)
OK, that's enough of a difference to explain what I'm seeing...
May be something to do with chunk encoding which has been modified
in ajp13/jk (after your works on domino I
Andy Armstrong wrote:
Henri Gomez wrote:
- FORWARD REQUEST
- SEND HEADERS
- SEND BODY CHUNK
- END RESPONSE (REUSEP:1)
OK, that's enough of a difference to explain what I'm seeing...
May be something to do with chunk encoding which has been modified
in ajp13/jk (after your works on domino I
Hi to all,
Some people ask me for jk 1.2.5 iSeries binaries.
I will build it but where should I upload it to make it later
replicated on mirrors site ?
Regards
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Brian Maher a écrit :
I noticed this message from Glenn Nielsen recently on this mailing list:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg47341.html
It appears that hgomez submitted a bunch of code that allows you to
configure a ping/pong mechanism that helps it detect hung tomcats.
Glenn Nielsen a écrit :
Henri Gomez wrote:
Hi to all,
Some people ask me for jk 1.2.5 iSeries binaries.
I will build it but where should I upload it to make it later
replicated on mirrors site ?
Look in CVS at j-t-c/jk/HOW-TO-RELEASE
Thanks, upload done
Brian Maher a écrit :
On Mon, 27 Oct 2003, Henri Gomez wrote:
If the thread on java side is a long running task or a blocking task,
it should be handled by the servlet engine and sus some watchdog support
should be added in Tomcat.
In you're exemple I didn't know how the thread could be ever
Ding/Dong,
What's the status of jk2 use APR ?
Mladen did you are still with works in progress ?
Regards
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Henri Gomez a écrit :
Mladen Turk a écrit :
From: Henri Gomez
Ding/Dong,
What's the status of jk2 use APR ?
Mladen did you are still with works in progress ?
I'm in a few deadline loops, again ;-).
So if nobody beets me before weekend I'll commit the needed changes.
Ok we could until
Bernhard Erdmann a écrit :
Hi,
how can I customize Apache's error page if mod_jk2 does not get a usable
worker (Tomcat is down)?
Using Apache 2.0.47, mod_jk2 2.0.2 and Tomcat 4.1.24 running on Linux I
get an error message when the servlet engine is stopped (Tomcat is
down):
The servlet container
Hristo Stoyanov a écrit :
Hi all-
I am using Tomcat (as part of JSWDP1.3) and would like to pre-compile my JSPs with Jasper2 in my Ant script. Jasper2 requires commons-logging.jar, which, for some unexplicable reason, starts asking for classes in log4j.jar (why is this idiotic behaviour of
Bernhard Erdmann a écrit :
Henri Gomez wrote:
[...]
The first sentence (The servlet container is temporary unavailable or
being upgraded) comes from mod_jk2
(jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/common/jk_worker_lb.c):
#define NO_WORKER_MSG The servlet container is temporary
Mladen Turk a écrit :
From: Henri Gomez
Bernhard Erdmann a écrit :
Henri Gomez wrote:
I'd like Apache to use its configured ErrorDocument 500
when Tomcat is
down instead of mod_jk2 printing its own error statement.
Ok, we could make it in the new jk2 reworks (Mladen ?)
Perhaps to make
Mladen Turk a écrit :
As said in the subject...
plus the jk_pool and jk_channel socket are marked as deprecated.
Couple of things to do.
1. APR-ize jk_file_logger to use apr_file API instead stdio's FILE.
2. All methods will return apr_status_t instead int (work in progress).
3. Henri, what about
Ok,
Who is handling today the many configure/m4 suggestions ?
BTW, I'm using Redhat 9.0 and the apr-config is available so it should
be a common situation even when it's a distro and not by hand build
-
To unsubscribe, e-mail:
jean-frederic clere a écrit :
Kurt Miller wrote:
Thanks to jean-frederic clere for input on this. Ok, here goes
again... ;-)
Attached is a patch that makes the following changes for building jk2 via
configure and make:
1) Introduces a new configure argument called
--enable-apr-threads=val for
[EMAIL PROTECTED] a écrit :
Oups, Eclipse didn't understand the patch files (/dev/null) and
sus garbage jk_apxs.m4, correct file to be commited right now...
hgomez 2003/11/04 04:48:05
1.7 +131 -1jakarta-tomcat-connectors/jk/support/jk_apxs.m4
Index: jk_apxs.m4
Amy Roh a écrit :
ApacheCon 2003 will be held in Las Vegas this November 16-19. Who is going
to be there from Tomcat Dev? Maybe we can coordinate Tomcat get together...
:-)
Hum, a little too distant from France ;(
-
To
Hi to all,
I would like to propose you a new tomcat commiter, Kurt Miller
which as proposed many usefull patches for JK2.
Since we want to deprecated jk and focus jk2, we need
more people involved on jk2.
Vote please.
-
To
Kurt Miller a écrit :
From: Glenn Nielsen [EMAIL PROTECTED]
Perhaps the mod_jk connector should not be released with Tomcat 4/5 since
it
has its own release cycle and we are already doing separate releases of
these.
Regards,
Glenn
Would this work...
When a stable version of mod_jk or
jean-frederic clere a écrit :
Henri Gomez wrote:
Hi to all,
I would like to propose you a new tomcat commiter, Kurt Miller
which as proposed many usefull patches for JK2
Since we want to deprecated jk and focus jk2, we need
more people involved on jk2.
Vote please.
Ok, it seems that nobody
501 - 600 of 1126 matches
Mail list logo
