Remy Maucherat wrote:
Hi,
Would it be possible to release a new version of native so that it works
on my setup ?
Sure. Jean-Frederic was RM for the last one.
I can do it if he doesn't have the time.
Regards
--
^(TM)
-
To
[EMAIL PROTECTED] wrote:
Author: rjung
Date: Tue Sep 16 13:05:34 2008
New Revision: 696032
URL: http://svn.apache.org/viewvc?rev=696032view=rev
Log:
Improve sed expresion added in r695003.
LDFLAGS could already include Wl,, so we shouldn't
add them a second time.
Problem reported by Brian
Rainer Jung wrote:
...
Why not making something like:
dnl
dnl APR_REMOVEFROM(variable, value)
dnl
...
This looks more simpler to me, compared to hard-to-read regex
sed rules.
Yep, done in r697070.
Ups, entschuldingug bitte Herr Jung, missed that :)
Cheers
--
^(TM)
Rainer Jung wrote:
Hi Mladen,
any thoughts, how we could make configuring connection_keepalive better?
Of course by introducing even more attributes we can keep the individual
CPING timeouts, but I don't really see a reason. I want to get the
attributes right, before we release this nice
Henri Gomez wrote:
Hi to all,
Did some of you experienced problems with mod_jk 1.2.26 (and maybe
earlier release) and Apache 2.x ErrorDocument directive.
In one of my configuration I set :
ErrorDocument 404 /gen_error404.html
ErrorDocument 500 /gen_error500.html
ErrorDocument 503
Henri Gomez wrote:
Hum good idea.
Same thing for 404/500/503 I suppose.
Sure.
if (!r-sent_bodyct r-status = HTTP_BAD_REQUEST) {
...
return r-status;
}
Regards
--
^(TM)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Henri Gomez wrote:
Same thing for 404/500/503 I suppose.
Sure.
if (!r-sent_bodyct r-status = HTTP_BAD_REQUEST) {
...
return r-status;
}
I added to the conf/web.xml :
error-page
error-code404/error-code
location/empty-error.html/location
/error-page
error-page
Rainer Jung wrote:
I have some spare time later this week and next weekend and plan to
finally do the IIS chunked encoding stuff. If we don't find anything
else important we should be able to have a testing tar ball at the end
of the month and soon after start the releasing process. We are a
Dan Bush wrote:
I don't think this
would impact mod_jk because I believe that is configurable via a
directive.
Not jet. However the next version we are going to release (1.2.27)
will have that feature.
Think your question was raised few times, but the answer was always
-1, cause per servlet
Tim Whittington wrote:
This has broken the build on Windows also.
The addition of the log statement pushed the declaration of char* buff below
it out of the beginning of the block, and VC is being pedantic about the C
declaration rules.
Done, thanks.
Cheers
--
^(TM)
Hi,
I'd like to create a branch of connectors
for native component so it depends on the
new APR 1.3.x API
The new API offers some essential features targeted
explicitly for pool issues usage in
high level languages like Java.
So, my idea is to branch the current trunk
as
Mark Thomas wrote:
I would like to propose creating two new products in bugzilla:
- Tomcat mod_jk
+1
- Tomcat APR-native
Tomcat Native
(we have tomcat-native-x.x.x, not tomcat-apr-native)
Regards
--
^(TM)
-
To
Rainer Jung wrote:
Mladen Turk schrieb:
The native external is used in the dist.xml build file in order to
include the tcnative sources in the TC src release. So either we need to
adjust this part of TC build process, or simply switch the external for
TC 6.0.x to the 1.1 branch (and keep TC
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 both branches ? I
assume there will be
features that can only be done in 1.3.
Right.
1.1.x will be in bug fixing mode
Also, if we
Costin Manolache wrote:
What is the apr version in common linux distros ?
Depends, Httpd 2.2.something+ relies on APR 1.3. SVN as well,
so eventually distros will pick it up.
Well, that's a bit tricky - people don't upgrade prod servers easily.
My concern is mostly about possibility
[EMAIL PROTECTED] wrote:
Author: rjung
Date: Fri Oct 3 12:37:13 2008
New Revision: 701507
URL: http://svn.apache.org/viewvc?rev=701507view=rev
Log:
Add retry_wait for AJP13 workers.
If a request fails, sleep a configurable time
before each following retry.
Remember: this has nothing to do with
Mark Thomas wrote:
These have been created and I have moved bugs from Tomcat 4/5/6 to these
products based on component and/or presence of strings like isapi in the
summary.
Cool.
I have checked the open bugs. I have also set the component (mod_jk/isapi
etc) where I thought it was sensible
Rainer Jung wrote:
a) Refactor
---
I would suggest we move the retry handling of get_endpoint into
ajp_get_endpoint() and derive any configuration options of the retry
behaviour from the AJP 13 worker, not the LB worker.
That makes sense. It's a logical place for it.
Also the
Eiji Takahashi wrote:
Hi.
I think that retry_interval can be set also with LB.
Is it correct?
+directive name=retry_interval workers=AJP,SUB default=100
required=false
Sure, it's a work in progress.
Thanks for keeping an eye.
Regards
--
^(TM)
Filip Hanik - Dev Lists wrote:
very true, didn't realize so many places referenced it, however, this
gets confusing
-public static final String SESSION_COOKIE_NAME = JSESSIONID;
+public static final String SESSION_COOKIE_NAME =
+
Rainer Jung wrote:
[EMAIL PROTECTED] schrieb:
Author: mturk
Date: Mon Oct 6 07:28:20 2008
New Revision: 702160
URL: http://svn.apache.org/viewvc?rev=702160view=rev
Log:
Implement global shared memory lock for IIS. With IIS 6+ we don't have a single
process any more
I also noticed, that the
Rainer Jung wrote:
[EMAIL PROTECTED] schrieb:
Author: mturk
Date: Mon Oct 6 07:28:20 2008
New Revision: 702160
URL: http://svn.apache.org/viewvc?rev=702160view=rev
Log:
Implement global shared memory lock for IIS. With IIS 6+ we don't have a single
process any more
I was talking to someone
Hi,
I'd like to tag and release 1.2.27 pretty soon (this week)
Here is the release snapshot for testing.
http://people.apache.org/~mturk/jk-1.2.27-dev/
The binaries provided are for win32 for tester
convenience. Please test, and if nothing bad found
I'll tag the 1.2.27 in cca. 36 hours.
Rainer Jung wrote:
I justed committed a critical fix. If multiple requests trigger
initialization of the isapi redirector in parallel, then memory
corruption can arise. This has been observed in real production.
OK. Cool.
I like the idea of thoroughly testing snapshots before tagging,
Rainer Jung wrote:
Mladen Turk schrieb:
Rainer Jung wrote:
I like the idea of thoroughly testing snapshots before tagging, because
although version numbers are cheap (in subversion), user confusion also
easily arises from missing (i.e. non-released) versions.
Sounds reasonable. I'll prepare
The Apache Tomcat team announces the immediate availability of
Apache Tomcat Connectors 1.2.27-dev-704800 for testing.
Apache Tomcat Connectors version 1.2.27-dev contains
numerous of bug fixes over previous 1.2.26 version and lots
of new features.
The complete changelog with all fixes and new
Lorenz Breu wrote:
Hi folks,
Socket.class and the native network.c files. The java code specifies a
recvFrom() method (capital F) whereas the native code defines a
recvfrom() function (all lowercase)... A quick rebuild of the tomcat
sources after renaming the java method recvfrom() seems to
Rainer Jung wrote:
Since there's likely no realiable and easy way to get that info, it
looks like a good idea to add it to the README on the download page.
Sure README should be present.
Anyhow, like you deducted it was Apr 1.2.8 and
OpenSSL 0.9.8i
Regards
--
^(TM)
Rainer Jung wrote:
URL: http://svn.apache.org/viewvc?rev=707645view=rev
Log:
Change logging attempts from ERROR to INFO. They can happen multiple times, so
log as ERROR only once
+if (rc == JK_FALSE) {
+jk_log(l, JK_LOG_INFO,
+ All tomcat instances failed, no more
Hi,
I plan to tag the TOMCAT_NATIVE_1_1_16 later today.
The current trunk has few fixes over released 1.1.15
Improved IPV6 checking, building against APR 1.3
(not mandatory, but allows to build), and one API typo.
Since we are in the release mania any objections to that?
Regards
--
^(TM)
jean-frederic clere wrote:
Mladen Turk wrote:
Hi,
I plan to tag the TOMCAT_NATIVE_1_1_16 later today.
The current trunk has few fixes over released 1.1.15
Improved IPV6 checking, building against APR 1.3
(not mandatory, but allows to build), and one API typo.
Since we are in the release mania
Henri Gomez wrote:
Didn't you have the same problem with 1.2.26 and SuSe
(or was it someone on the users list)?
Yes I do still the same distro (SLES 10)
And they didn't fix that for more then a year?
Should I say anything else ;)
Cheers
--
^(TM)
Hello to the Tomcat team,
Native 1.1.16 has been available for testing for almost a week,
so I would like to proceed with the release vote.
If you want to take a look, the final source distribution can be
downloaded from:
http://tomcat.apache.org/dev/dist/tomcat-connectors/native/source/
Some
Filip Hanik - Dev Lists wrote:
The async close is important to 'long-polling' which is what bayuex does.
if you have 20 second timeout, there is a chance that the client could
reuse the connection after it has received the 'end chunk' (0) from the
server, and sends a new request.
if there is
Lorenz Breu wrote:
hi guys
so did i get this right, you released version 1.1.16 of tomcat native?
Still in the voting process.
it's not on the homepage yet and i am having trouble finding the exact
location of the code of the actual release, could you tell me if the
typos in multicast.c
Just an reminder that the voting is still on ;)
I'll wait another 48 hrs, and if not voted
seems we'll have to forget about this version.
Mladen Turk wrote:
Hello to the Tomcat team,
Native 1.1.16 has been available for testing for almost a week,
so I would like to proceed with the release
Mladen Turk wrote:
Hello to the Tomcat team,
Native 1.1.16 has been available for testing for almost a week,
so I would like to proceed with the release vote.
So far only one binding vote has been recorded
(Thanks Henri), and mine by presumption.
So, Native 1.1.16 won't be released due
[EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?rev=714108view=rev
Log:
User build.properties.default for tcnative like
we do for tomcat.
Remove unused version.number.
Add version details to build.properties.default
and remove from build.xml.
Added:
Rainer Jung wrote:
Mladen Turk schrieb:
We have now two branches 1.1 and trunk
So in trunk the version is 1.2.x
The second branch is:
https://svn.apache.org/repos/asf/tomcat/connectors/branches/native/1.1.x
So I suppose those changes has to go in there as well.
It would be probably easier
Mladen Turk wrote:
Mladen Turk wrote:
Hello to the Tomcat team,
Native 1.1.16 has been available for testing for almost a week,
so I would like to proceed with the release vote.
So far only one binding vote has been recorded
(Thanks Henri), and mine by presumption.
So, Native 1.1.16
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
You are the chair... and further you had called the vote. Feel free
to reverse yourself :)
Wow, and I thought the chair is the slave that
collects and writes board reports ;)
Cheers
--
^(TM
sebb wrote:
I happened to spot the following in ssl.c:
static int jbs_gets(BIO *b, char *out, int outl)
...
int l = (int)strlen(J2S(o));
if (l outl) {
strcpy(out, J2S(o));
ret = outl;
}
...
return ret;
It looks a bit odd to me - I would have expected it to return l rather
than outl.
Rainer Jung wrote:
a) bundling native and org/apache/tomcat/jni code in one place in svn
and releasing together
or
b) separating only the native implementation
Option a) was used cause we didn't have separate tcnative
release when it was introduced.
Since this is now a separate
Rainer Jung wrote:
On 02.01.2009 08:25, Mladen Turk wrote:
Rainer Jung wrote:
a) bundling native and org/apache/tomcat/jni code in one place in svn
and releasing together
or
b) separating only the native implementation
Option a) was used cause we didn't have separate tcnative
release
Rainer Jung wrote:
On 02.01.2009 11:57, Mladen Turk wrote:
It doesn't mater if the API is stable or not.
Tomcat will just depend on tomcat-native-1.xx.noarch.bin.zip and use the
pre-compiled .jar
(like any other jakarta-commons component for example)
OK, I think that's exactly what I meant
The Apache Tomcat team is proud to announce the immediate
availability of Tomcat Native 1.1.16 stable. This build
contains a small number of bug fixes over the previous
release.
Please refer to the changelog:
http://tomcat.apache.org/native-doc/miscellaneous/changelog.html
for a complete list of
Lorenz Breu wrote:
just to let you know, the typos in jni/native/multicast.c are still
there
I'm afraid they are.
This is just late administrative message following
the 1.1.16 release.
However will be releasing 1.1.17 pretty soon
with those things fixed (already done in SVN)
Regards
--
The Travel Assistance Committee is now accepting applications for those
wanting to attend ApacheCon EU 2009 between the 23rd and 27th March 2009
in Amsterdam.
The Travel Assistance Committee is looking for people who would like to
be able to attend ApacheCon EU 2009 who need some financial
Lorenz Breu wrote:
i tried to build the tcnative libraries on my windows xp x86 machine
using ms visual studio 2008, but it keeps telling me the project file is
corrupted and can't be opened. this happens for both 1.1.15 and 1.1.16
versions of tc-native. any ideas?
Make sure it has DOS (CRLF)
Lorenz Breu wrote:
hi once again
i have been trying to figure out why my tomcat native based mina
acceptor won't join a speicified multicast group. the call goes through
Multicast.join() over the tomcat native code to apr_mcast_join which in
turn calls do_mcast in the apr multicast.c file. then
Lorenz Breu wrote:
hi once again
i have been trying to figure out why my tomcat native based mina
acceptor won't join a speicified multicast group. the call goes through
Multicast.join() over the tomcat native code to apr_mcast_join which in
turn calls do_mcast in the apr multicast.c file. then
Lorenz Breu wrote:
Try Multicast.loopback if Multicast.join fails.
Win32 is pretty weired, and not sure why the join doesn't work.
I suppose the multicast group needs to exists before joining.
no cigar. i first expected an APR_ENOTIMPL or even a failure, but i get
APR_SUCCESS all the way...
Hi,
We have a bug in 1.2.27 that cause core in some configuration
scenarios (#46352). The fix is in the SVN for more then a month.
Beyond that there are two additional bug fixes
one preventing Netware build, and other fixing IIS
advanced configuration (#46579)
There are also few valuable
Tim Whittington wrote:
I¹d appreciate a fix for
https://issues.apache.org/bugzilla/show_bug.cgi?id=46416 so I can build on
Windows without local patches.
Recent APR version have that included.
Can you check the current trunk version?
Regards
--
^(TM)
Rainer Jung wrote:
+if (aw-addr_sequence != aw-s-addr_sequence) {
+aw-addr_sequence = aw-s-addr_sequence;
+aw-host = aw-s-hostname;
Should we copy the string here?
Nope, the string is now in shared memory.
In theory we don't care about ajp-host
we just need that for a
Rainer Jung wrote:
On 19.02.2009 16:28, mt...@apache.org wrote:
Author: mturk
Date: Thu Feb 19 15:28:47 2009
New Revision: 745898
URL: http://svn.apache.org/viewvc?rev=745898view=rev
Log:
Update uriworkermap on watchog interval
Modified:
Rainer Jung wrote:
On 25.02.2009 13:44, Mladen Turk wrote:
Concerning host vs. hostname: I would prefer to keep the variable names
the same. I can do the change. Do you prefer host in both cases, or
hostname? I think host makes somes sense, because it reflects the
workers.properties
Rainer Jung wrote:
On 25.02.2009 13:56, Mladen Turk wrote:
Rainer Jung wrote:
On 19.02.2009 16:28, mt...@apache.org wrote:
Author: mturk
Date: Thu Feb 19 15:28:47 2009
New Revision: 745898
URL: http://svn.apache.org/viewvc?rev=745898view=rev
Log:
Update uriworkermap on watchog interval
Rainer Jung wrote:
On 19.02.2009 16:39, Mladen Turk wrote:
Hi,
We have a bug in 1.2.27 that cause core in some configuration
scenarios (#46352). The fix is in the SVN for more then a month.
Beyond that there are two additional bug fixes
one preventing Netware build, and other fixing IIS
Rainer Jung wrote:
Do you want to do the next steps, or should I?
BTW, I'd like that we this time use the common
httpd 2.0 and 2.2 versions for producing the
binaries. For 2.0 I'd suggest 2.0.52 (or 2.0.49)
and for 2.2 version 2.2.3.
For 1.3, 1.3.23 should be fine.
All later versions have
Mark Thomas wrote:
I stumbled across some code in trunk for this. I had a poke around and as far as
I can tell this hasn't been supported for quite some time. What do people think
about removing it from mod_jk and trunk?
It is already disabled by default. You need a special configure flag
Rainer Jung wrote:
On 05.03.2009 10:03, Mark Thomas wrote:
Mladen Turk wrote:
Mark Thomas wrote:
I stumbled across some code in trunk for this. I had a poke around and
as far as
I can tell this hasn't been supported for quite some time. What do
people think
about removing it from mod_jk
Rainer Jung wrote:
On 05.03.2009 07:50, Mladen Turk wrote:
Rainer Jung wrote:
Do you want to do the next steps, or should I?
BTW, I'd like that we this time use the common
httpd 2.0 and 2.2 versions for producing the
binaries. For 2.0 I'd suggest 2.0.52 (or 2.0.49)
and for 2.2 version
Costin Manolache wrote:
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.
LOL. But don't forget the good old one ...
What goes around, comes around
Cheers
--
^(TM)
Rainer Jung wrote:
On 05.03.2009 15:23, Rainer Jung wrote:
Hi,
I uploaded testing tarballs of mod_jk 1.2.28-dev to
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source
CAUTION: at this point in time the web server still shows the older
revision 750390. The revision I uploaded last
Rainer Jung wrote:
On 06.03.2009 08:39, Mladen Turk wrote:
Can you cc the dist files to your people's dir as well
Did that:
http://people.apache.org/~rjung/mod_jk-dev/
OK, I'll build the bins from there
But as described above, it would be nice to first check BZ 46808 before
building
I'll bring that to dev list ...
bugzi...@apache.org wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #4 from Rainer Jung rainer.j...@kippdata.de 2009-03-06 00:13:55
PST ---
So having the new busy in shm is on purpose, and we have three of those:
a) one for the
Huge one Rainer ;)
Rainer Jung wrote:
We have three busy counters:
a) one for the lb in total
b) one for each lb sub
c) one for each ajp worker
In status worker we use only a) and c). In lb we use a) and b). Your
comment to BZ 46808 seems to indicate, that using c) instead ob b) in lb
Rainer Jung wrote:
On 06.03.2009 13:32, Mladen Turk wrote:
Huge one Rainer ;)
I know, but I went through it in depth.
Rainer Jung wrote:
We have three busy counters:
a) one for the lb in total
b) one for each lb sub
c) one for each ajp worker
In status worker we use only a) and c
Rainer Jung wrote:
On 06.03.2009 14:19, Mladen Turk wrote:
JkMount /foo aw
JkMount /bar aw
Now, if /bar is slow and gets timeout it would mean that
/foo will be banned as well (although it might work perfectly)
But I see your point. Since configured it should be banned
immediately. However
Rainer Jung wrote:
On 06.03.2009 13:32, Mladen Turk wrote:
For the rest it's simply too much to cope in a single email ;)
I put the force recovery fix and the else suggestion in a patch at:
http://people.apache.org/~rjung/mod_jk-dev/patches/local_states.patch
Everything apart from Hunk
Rainer Jung wrote:
On 06.03.2009 13:32, Mladen Turk wrote:
For the rest it's simply too much to cope in a single email ;)
I put the force recovery fix and the else suggestion in a patch at:
http://people.apache.org/~rjung/mod_jk-dev/patches/local_states.patch
I've added 'in_error' for ajp
Rainer Jung wrote:
On 07.03.2009 09:00, mt...@apache.org wrote:
Summary:
I still like the idea of using the error_time. Each OK request will
reset it, and that's fine. As long as there's something good coming back
we have a global chance. But if there are no OK's for some time we
should
Rainer Jung wrote:
On 07.03.2009 15:23, Mladen Turk wrote:
Rainer Jung wrote:
On 07.03.2009 09:00, mt...@apache.org wrote:
After 10 seconds or after 60 seconds: I think 60 seconds is pretty
long, but I would accept as a compromise :)
Let's use the recover_wait_time here, or if you still
Weibin Yao wrote:
The document said:This directive configures the watchdog thread interval in
seconds. from http://tomcat.apache.org/connectors-doc/reference/apache.html.
But the source code of mod_jk 1.2.27 ,mod_jk.c, line 2842-line 2843:
/* apr_sleep() uses microseconds */
rj...@apache.org wrote:
Author: rjung
Date: Fri Mar 13 11:44:35 2009
New Revision: 753212
URL: http://svn.apache.org/viewvc?rev=753212view=rev
Log:
Addition to r753147:
Use strlen to compare for identity without patching
the string to make it zero-terminated.
Cool, much better!
Thanks
--
Henri Gomez wrote:
For now, I still can't build it on i5/OS ;-(
Well if you don't came up with the patches,
(or someone else) we cannot postpone the
release because no one else has access to
that OS. At least some build log might
help, but it's up to maintainer to test
and eventually propose
Rainer Jung wrote:
I added a comment with a non spec compliant workaround to BZ41263.
We'll seee, whether we can make the AJP Tomcat connectors hack aware,
i.e. allow them to get the remotePort from the REMOTE_PORT env var when
set.
Only if you make sure that the REMOTE_PORT is always
Rainer Jung wrote:
On 21.03.2009 13:23, Mladen Turk wrote:
Rainer Jung wrote:
I added a comment with a non spec compliant workaround to BZ41263.
We'll seee, whether we can make the AJP Tomcat connectors hack
aware, i.e. allow them to get the remotePort from the REMOTE_PORT env
var when set
Apache Tomcat Connectors 1.2.28 is:
[X] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are
Regards
--
^(TM)
Rainer Jung wrote:
On 21.03.2009 14:12, Mladen Turk wrote:
I should read the entire logic before posting.
I missed it's an env var.
Sorry for the noise ;)
No problem at all. Better safe than sorry.
I just committed a change to TC trunk and backport proposals to pick up
the REMOTE_PORT env
rj...@apache.org wrote:
Author: rjung
Date: Mon Mar 23 17:54:41 2009
New Revision: 757470
URL: http://svn.apache.org/viewvc?rev=757470view=rev
Log:
Set remote port for AJP connectors from the optional request
attribute AJP_REMOTE_PORT.
Backport of r756926 and r757223.
Now when thinking of
Rainer Jung wrote:
On 23.03.2009 19:31, Mladen Turk wrote:
I read the remote_addr as a string that can recreate
the FULL remote address on the container side.
We need to change JK and TC in a way, that old versions of each work
together compatibly with new version.
Sure.
Changing
Rainer Jung wrote:
Hello,
I'm thinking about branching JK, so adding
http://svn.apache.org/viewvc/tomcat/connectors/branches/jk1.2.x
and initially populate the branch with the contents of the 1.2.28 tag.
The motivation is to stabilize 1.2 and restrict further changes on 1.2
to patches only.
jean-frederic clere wrote:
Mladen Turk wrote:
Rainer Jung wrote:
Hello,
I'm thinking about branching JK, so adding
http://svn.apache.org/viewvc/tomcat/connectors/branches/jk1.2.x
and initially populate the branch with the contents of the 1.2.28 tag.
The motivation is to stabilize 1.2
Costin Manolache wrote:
I was thinking more as
- when all the new features are implemented and we have a replacement
protocol that has been
around ( optional ) for a while - drop the old code and branch 1.3.
This is certainly one approach, but from my humble
experience that won't do any
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
association to 'jk'? It seems it would benefit the effort if
Mark Thomas wrote:
All,
I have been looking at trunk for opportunities to remove duplicate / obsolete
code. We currently have two BIO AJP connectors:
- org.apache.jk.server.JkCoyoteHandler
- org.apache.coyote.ajp.AjpProtocol
I would like to remove org.apache.jk.server.JkCoyoteHandler and
Yoav Shapira wrote:
Apache Tomcat v5.5.17 is:
[X] Stable - no major issues
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
The provided tomcat-users.xml is obviously used
as an example.
Can we tweak that so that it actually allows
the admin and manager users?
The purpose would be the same (example), but
it will allow to run the provided web apps without
additional editing.
Any objections if I put the 'real'
Peter Rossbach wrote:
Yes, defaults are very fine, but secret parameter need active user
interaction.
I didn't say it will be enabled by default.
If commented out like in tc6, it would need an user intervention
anyhow, so the user uncommenting the credentials should be
aware of the
Remy Maucherat wrote:
Are you posting this proposal because some people find it too difficult ?
I'm posting that because I find it difficult.
I always forget the usernames and roles :)
Anyhow, It's not a big deal.
Sorry for the noise :)
Regards,
Mladen.
Javier Iglesias wrote:
Hi there,
sorry to disturb with such a silly question:
where can I find the Apache Tomcat logo in vector
format (svg, eps, pdf, ai, ...)?
It's still in Jakarta repository:
http://cvs.apache.org/viewcvs.cgi/jakarta/site/xdocs/images/logos/tomcat.eps?rev=126640view=log
Javier Iglesias wrote:
Thanks Mladen,
Good point! It should go to our svn thought.
I cleaned up the file, added the colors
according to tomcat.apache.org, converted to svg.
It would be nice to have colored .eps.
My Photoshop does not support .svg :)
Regards,
Mladen.
Remy Maucherat wrote:
Mladen Turk wrote:
It would be nice to have colored .eps.
My Photoshop does not support .svg :)
Bleh. I would recommend using Gimp (and svg) instead, and I think it's a
great contribution from Javier.
Right, The GIMP rulez ... removing Photoshop :)
Of course, thanks
Martin Goldhahn wrote:
Hi!
I did some modifications to the Jakarta ISAPI filter in
connectors/trunk/jk/native. It would be nice to see most of them
included the distribution.
Like explained in the bz..
This connector is unsupported!
Use native/iis instead for using iside Microsoft IIS.
Other
Markus Schönhaber wrote:
Could you please explain the reason for this change?
Sure :)
Using APR_UNSPEC was introduced to make the APR Connector also listen on
IPv6 addresses if no specific address is configured - this way
resembling the behaviour of the Base Connector.
Markus Schönhaber wrote:
You might also want to change
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
I will. Just needed a second confirmation if it's working as expected.
Regards,
Mladen.
-
To
David Rees wrote:
OK, I see that mladen has recently checked in some jk changes. As soon
as he gives the word, I'll check out the latest from SVN and do some
testing.
Think I'm done with all the patches I had on my schedule.
Feel free to check the HEAD.
Regards,
Mladen.
Costin Manolache wrote:
are quite different,
I want to have it simpler and smaller than the apr model. I think old-style
connector
should be deprecated, since JDK1.5 is now required there is no point in
having it.
Sorry for stealing the thread ;)
What about old jk2 connectors found again in
301 - 400 of 1171 matches
Mail list logo
