fine in reasonably extensive use with Apache 2.0.47 on
Windows and some quick tests on Solaris 9 and AIX 4.3.3 with Apache 1.3.28.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Were there any changes since the test release, i.e. does the tagging
reflect (minus release notes, etc) the test release?
[I'm asking as I've built binaries for all platforms I need from the
test release and would like to avoid rebuilding all of them]
Glenn Nielsen wrote:
Glenn Nielsen wro
was tagged as
mod_jk_1_2_5.
So yes, you can use binaries built from that source as mod_jk 1.2.5
release binaries.
Regards,
Glenn
Jess Holle wrote:
Were there any changes since the test release, i.e. does the tagging
reflect (minus release notes, etc) the test release?
[I'm asking as
unfamiliar system with almost no gnu tools
(e.g. you're lucky to have gcc) and have to build mod_jk needing
autoconf, m4, libtool, etc, etc, becomes a real hassle! Enough of one
that I've been using makefiles from previous mod_jk releases instead.
--
likely to be considered "stable" once
J2EE 1.4 is? Or is a 5.0.15 coming down the pipe shortly?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Remy Maucherat wrote:
Jess Holle wrote:
Now that J2EE 1.4 is going final this week, what is the ETA for a
stable Tomcat 5.0.x release?
It was my understanding that some Tomcat 5.0.x releases *might* have
been considered stable, but this label was not considered since J2EE
1.4 was not yet
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
Jess Holle wrote:
Now that J2EE 1.4 is going final this week, what is the ETA for a
stable Tomcat 5.0.x release?
It was my understanding that some Tomcat 5.0.x releases *might*
have been considered stable, but this label was not
ay well have already seen/heard, the official press
statements are now saying that the 24th, i.e. next Monday, is now the
official spec, etc, release date.
Looking forward to 5.0.15 stable :-)
--
Jess Holle
-
To unsubscribe, e-ma
J2EE 1.4 has been released!
As I understand (from personal use as well as that from lurking here),
Tomcat 5.0 should be ready to be tagged any day as 5.0.15 and to achieve
a "stable" rating.
--
Jess Holle
Jess Holle wrote:
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wr
Tomcat 5's tomcat.exe and tomcatw.exe do not work in the manner then
used to in Tomcat 4.1.29.
Can someone please point me to information on the changes?
Or is the intent that tomcat.exe should work as it did in 4.1.29? [In
which case, it clearly does not.]
--
Jess
ht result or... what?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I don't have a vote, i.e. I'm not a committer, but for what it's worth:
Remy Maucherat wrote:
Release 5.0.16 as Stable ?
[*X*] Yes
[ ] No
I saw no issues (other than an issue with javac, not Tomcat) with 5.0.15
and have not seen any with 5.0.16 either.
--
Jess Holle
he response commited.
Is this as per the spec? Or is this an odd corner case?
[The fact that we have code that does a setContentLength(0) seems to be
an odd corner case in and of itself... I've worked around this in our
code by ensuring that this call is always made after all other headers
produce a hash of headers and toss them at code which
simply spits them at the response in hash order -- with a few special
cases to use more specific methods where possible).
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL
Dan Johnsson wrote:
Jess Holle wrote:
Tim Funk wrote:
Section 5.5 of the spec:
When a response is closed, the container must immediately flush all
remaining content in the response buffer to the client. The
following events indicate that the servlet has satisfied the request
and that the
course
the next layer of Tomcat needs to wait on the thread pool anyway, so I'm
not sure what the real benefit over a reasonably sized mod_jk[2]
connection pool really is...
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
o are forced to care about rigorous i18n to
tell our customers to use Tomcat 4.1 or pay for a commercial servlet
engine if they want later spec compliance.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional c
Remy Maucherat wrote:
Jess Holle wrote:
Remmy, et al:
The API is *not* optional. It is a required part of the servlet spec.
Great. I didn't know that ;-)
How about:
- Not CCing me. I'm subscribed to tomcat-dev already. thanks.
Sorry.
- There's big threads, commit messages (i
Remy Maucherat wrote:
Jess Holle wrote:
- There's big threads, commit messages (incl recent ones), and bugs
on this issue. How about reading that before writing an email about
how bad things are.
I did search the archives for such threads before even filing my
duplicate bug, so appar
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
For example:
remm2003/12/10 14:26:28
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
mbeans-descriptors.xml
Log:
- Add a
led a new bug and argued to high hell...
--
Jess Holle
7;d suggest that the out-of-the-box default settings be for the
suggested Sun techniques to work...
--
Jess Holle
/.
If there are reasons this is unworkable, then these should be worked out
with Sun so they stop telling everyone that this approach works. Until
then obnoxious ignoramouses like me will try to do what Sun says, fail
with Tomcat, and blame Tomcat.
--
Jess Holle
ritical if it was initially broken in 5.0.17!
--
Jess Holle
Filip Hanik wrote:
I dont think setting maxSpareThreads==maxThreads is a good solution to a
problem as this memory leak. I still have to verify that that would actually
solve the problem
if we don't want to remove request info, let
jspc) only 899 were
successfully compiled by 5.0.17. I looked into this further and
discovered that 5.0.16 misreported 3 failures as successes as the jspc
task failed but did not signal such. Thus Tomcat 5.0.17 is a nice
improvement in this re
f 992 failed to
compile with 5.0.16 but were not noted as failures only to be noted as
such by 5.0.17.
Which means that neither our JSPs nor 5.0.16 was that far amiss -- but
5.0.17 is a definite improvement in this regard.
--
Jess Holle
eparable, etc. It
would be great if someone could go one step further and produce a
seamlessly Tomcat pluggable, JTA-only sub-distribution of JBoss -- or
just an Ant script to produce that from a normal JBoss distro or CVS label.
--
Jess Holle
---
marks are often full of lies, I think it is in everyone's best
interest to keep an eye out for opportunities to ensure Tomcat 5 remains
competetive in terms of performance and scalability.
--
Jess Holle
-
To unsubscribe, e-ma
Jeanfrancois Arcand wrote:
Release 5.0.18 as Stable:
[X ] Yes
[ ] No
I don't actually have a vote (not being a commiter or any such), but I'd
ditto the stable rating for 5.0.18.
--
Jess Holle
-
To unsubscribe, e-ma
Remy Maucherat wrote:
Jess Holle wrote:
Any and all performance improvements would be greatly appreciated.
For those who have not seen it, Sun is touting their "SunONE is
better performed / more scalable than Apache 2 + Tomcat" benchmark.
While Tomcat and mod_jk[2]'s sole
In general, I agree that general benchmarks are useless and can be
slanted towards any alternative you choose.
Also I agree that Tomcat generally seems to perform quite well and reliably.
--
Jess Holle
Peter Lin wrote:
As usual, these types of comparisons aren't really useful or even desi
area, we effectively use whatever Tomcat uses while in the servlet
engine in any case. We're therefore at Collections 2.1 as Tomcat is.
Are there plans to move Tomcat to Jakarta Collections 3.0?
--
Jess Holle
-
To unsubscri
Remy Maucherat wrote:
Jess Holle wrote:
Can anyone shed any light on the plans for Tomcat using Jakarta
Collections 3.0?
I ask as we currently bundle Jakarta Collections for use in and out
of the servlet engine. We wish to use a consistent version
throughout. Given that Tomcat bundles
file system mappings to WebDAV
(and the OS X one sounds nice), but unfortunately for those who produce
servers that would like to be able to just expose themselves to clients
via WebDAV this is essentially useless for >>90%
Julian Reschke wrote:
Jess Holle wrote:
WebDAV seems to be largely an empty promise due to the lack of
reasonable, compatible clients.
>>90% of all clients are Microsoft Windows.
Microsoft Windows' Web Folders support WebDAV to a *small* degree.
Yet the way this is integrated
to Tomcat and
you're set. Right?
[At that point Tomcat would be kind of like what NetBeans tries to be in
this regard, which is pretty nice -- all other aspects of NetBeans aside.]
--
Jess Holle
re of
the user-community to these modules (rather than them just getting
overlooked since they're "in there somewhere") and allows separate
release points -- which is a dual-edged sword...
--
Jess Holle
-
To un
was a better idea for
a production system -- but there was a good deal of dissent on this
question...
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Remy Maucherat wrote:
As discussed previously.
What's the status of the JK 2 release ?
Also, I've been seeing mutterings of a JK 1.2.6 release -- any status on
that?
[Ping and pong, etc, would be nice to have in a released, citable version!]
--
*really* like to see
a JSR 160 solution in Tomcat that works in Java 1.4.x and Java 1.5 (aka 5).
Is this the plan/hope? At a high level it does not look too nasty to do
this
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PR
Remy Maucherat wrote:
Jess Holle wrote:
Though I also really like Java 5's [yep, another neat numbering
change from Sun :-)] built-MBeans for JVM monitoring, I'd *really*
like to see a JSR 160 solution in Tomcat that works in Java 1.4.x and
Java 1.5 (aka 5).
Is this the plan/hope?
Remy Maucherat wrote:
Jess Holle wrote:
I'll play with this as I have time, but I'll be doing the same sort
of thing with our own app first.
As I see it (and I could be offbase, of course, as I've not had time
to code this), one just needs a pluggable SPI sort of interface
Remy Maucherat wrote:
Jess Holle wrote:
In my case even with 1.5 I need a pluggable (2) from above. Why?
Because I need to work with port ranges and grab the first free port
(with MBeans then proxied to a daemon with a consistent port #). 1.5
has no automatic machinery for this as best I can
Ditto. I started just using CVS-latest for mod_jk and mod_jk2 some time
back as the gap between new, stable feature/fix content and release
labels was just too great. Overall CVS-latest has been more stable than
the last labels for some time now
David Rees wrote:
Rainer Jung wrote:
the
I have no vote -- but I'd say YES to stable if I had one
Shapira, Yoav wrote:
Hi,
5.0.27-beta has been out for a few weeks, the TCKs pass, the tester and
watchdog tests pass, and there has been positive feedback for it on the
user list without any show stopper bug reports. This change is simpl
contains all the other settings for that web
app. This is doubly true when you want that single conf file to cover
mod_jk and mod_jk2 bases so you can quickly and easily toggle between
the two in case of issues.
Having to merge per-web-app configurations into a single XML file would
be a mess
Mladen Turk wrote:
-Original Message-
From: Jess Holle
If you're proposing getting rid of JkUriSet, DON'T!
That's exactly what I whish to do.
It is *very* helpful to be able to mount URI's for a specific
web app in an Apache .conf file that contains all
Mladen Turk wrote:
From: Jess Holle
I can see eliminating all web-server-specific configuration
options in the long-term -- though keeping the existing
options around for a while as deprecated alternatives would
be nice, i.e. to give everyone a conversion grace period.
Well, you have
oach does not pollute the result with
any additional server-specific or Tomcat-specific baggage. It just
makes management and automated configuration/installation much more
workable.
--
Jess Holle
-
To unsubscribe, e-mail:
Mladen Turk wrote:
-Original Message-
From: Jess Holle
Who ever asked the poor apache admin about the TC's config ater all?
It really does not matter who the admin is. Even a
sophisticated admin is going to want to have file
modification dates they can trust on va
Both approaches have their advantages
Just don't loose the multi-file configuration flexibility given by JkUriSet.
Also, having either XML-based configuration *or* pure .conf
configuration would be more easily understood than the current
workers2.properties details.
Mladen Turk wrote:
-O
Angus Mezick wrote:
-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Mladen Turk wrote:
-Original Message-
From: Bill Barker
Having the option to do per-host and even per-context configs
makes life much easier for admins of servers that support it.
Otherwise
Jess Holle wrote:
Both approaches have their advantages
Just don't loose the multi-file configuration flexibility given by
JkUriSet.
Gack, I meant "lose". I did one of my own pet-peeve typos
Also, having either XML-based configuration *or* pure .conf
configuration would
es.
- Externalize configuration saving out of StandardServer
- And the ongoing: allow all config/management through JMX (actually, we
could consider going to a JMX config format)
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Remy Maucherat wrote:
Jess Holle wrote:
Just a note:
Please allow the anti-locking stuff to be skipped on Windows as
well. [Some of us value performance over deployment convenience.]
Yes, of course. In production, many people don't use hot deployment
(it doesn't give good enough QoS
real error!]
--
Jess Holle
Cavan Morris wrote:
Andy Armstrong wrote:
I have concrete examples of people giving up on Tomcat altogether for
no other reason than the fact that they couldn't get JK configured.
By comparison the rest of the task of configuring Tomcat is a walk in
the park. P
Andy Armstrong wrote:
Jess Holle > Getting the IIS connectors to work with IIS 6 appears to
be rocket
science though. [Dang thing just shows a red down arrow on the
filter whatever you do without giving any real error!]
Heh. Having spent two days getting the filter to work on IIS I'm
Costin Manolache wrote:
Jess Holle wrote:
Andy Armstrong wrote:
Jess Holle > Getting the IIS connectors to work with IIS 6 appears
to be rocket
science though. [Dang thing just shows a red down arrow on the
filter whatever you do without giving any real error!]
Heh. Having spent two d
had a stable module for this (whether or not it was from the ASF
itself), I would think this would be a good step to get these folk to
shift to Apache.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additio
Costin Manolache wrote:
Jess Holle wrote:
Maybe the best response to this would be to update the docs and say
"tomcat IIS 6 is not supported, plese contact microsoft and ask them
to do it". They have plenty of developers and money - they could
send a check to Andy and Henri, or do i
Costin Manolache wrote:
Jess Holle wrote:
Henri Gomez wrote:
It's better then having people struggle with mod_jk config and
feeling it's tomcat developer's job to support IIS.
You could also suggest IIS users to switch to Apache 2.0.50 for
Windows :)
I'd love to -- and have.
I actually built this yesterday upon rediscovering it -- and it seems to
work fine.
Unfortunately:
1. The licensing is unclear.
2. There appears to be no active maintenance or support of this module.
I'm thus more than a little reluctant to put too many eggs in this basket.
--
Jess
ould be integrated into Tomcat 5 so that this issue
ceases to be an issue for everyone using Tomcat.
--
Jess Holle
se patches in my own distribution,
but I always like to see a single, consistent fix for everyone.
--
Jess Holle
e bad
URL handling in the first place).
Agreed -- but that won't fix the issue.
So can we fix it in 5.0.x or not?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cisely as sent, whereas Tomcat pre-processes them a
bit more than picky, low-level request parsing code can accept.
[Yes, the "picky" code is *too* picky, but it isn't mine :-)]
--
Jess Holle
like a great project, but a *separate* project and
module.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
pport regular expressions, for example:
That would be a hard requirement for our usage as well. A huge reason
for using Apache is to serve the static content at that level.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED
timeout to make these sockets more or less
persistant. Also socket keep alive could be specified to avoid
firewall cut connexions without activity.
The keep alive stuff turns out to be a hard requirement for many
deployments.
--
Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
One issue here:
When Apache and Tomcat are used together via AJP13:
1. The host, port, protocol, etc, are exactly that at the Apache
level, i.e. one's web app sees Apache and Tomcat as 1
entity. This is a very good thing overall compar
Remy Maucherat wrote:
Jess Holle wrote:
Agreed -- but that won't fix the issue.
So can we fix it in 5.0.x or not?
Possibly, but it's risky.
So you'd recommend that I just patch my own distribution, then?
[Changing getURL() to convert to a URI first worked fine in 4.1.24...
Okay, I'll just change getURL() to be identical to getURI() and all
should be well for me.
Shapira, Yoav wrote:
Hi,
And wait for a 5.1 release, which may not be long in the making.
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Jess Holle [mailto:[
s information leaves most people
attempting this configuration completely lost -- and they just give up.
I have filed this as bug 30239
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30239>.
That's it for the moment
--
Jess Holle
customers, but overall I think Apache 2 is better solution
and a better use of the community's time. Now if someone could take
over ownership/maintenance for mod_auth_sspi, I'd feel better about IIS
support slowly withering away
--
Jess Holle
Ari Suutari wrote:
Hi,
I think
a modified Tomcat and have come to noting each and
every deviation (change or addition) from the standard Tomcat release
upon which I'm based for this reason.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED
g only a single
non-standard line of code per XML or XSLT factory.
--
Jess Holle
Shapira, Yoav wrote:
Hola,
I must say I don't fully understand the above. So what exactly will
happen if the common/endorsed directory is removed? What will stop
working and on which platform(s)? Are there any spec
chema yet...
+1 of dropping Xerces ;-)
Couldn't the use of XML be forced in a manner that is completely
independent of JAXP? This could try for the 1.5 Xerces (once at
startup) and then fail over to the 1.4 Xerces which it would always
deliver
from a
classloader even with delegation disabled.
Xerces would certainly load.
Do you really need Xerces' JAXP rather than that in 1.4?
--
Jess Holle
Jeanfrancois Arcand wrote:
Jess Holle wrote:
Costin Manolache wrote:
To make things a bit more interesting, I believe there are some
checks in JDK1.4 to prevent you to override rt.jar classes. That's
what "endorsed" really does, allow you to bypass those checks.
I don't thi
The offer to do this is great, but I am more than a little curious:
Why would anyone bother with a 4.1.x upgrade at this point? 5.0.27 is
faster, more stable, etc, at this point as best I can tell.
--
Jess Holle
Keith Wannamaker wrote:
Yoav, I haven't RM'd a release yet but if you or
t for Tomcat 5 for future releases that could
be backed into previous ones...
I'm sure different people have different reasons.
Yes, I echo Yoav's sentiment, though that the community needs to focus
on 5.0.x and beyond and really help push mindshare away from 3.x and 4.x
releases.
out a point
release with much less effort.
Unless your app is not moving into the future this should have already
been done with 5.x by this point (just possibly not yet deployed) -- right?
--
Jess Holle
-
To unsubscribe, e
lease.
--
Jess Holle
Shapira, Yoav wrote:
Hi,
I agree with Jess, this is the wrong direction in principle. We're
encouraging users to stick with 4.1.x if we do this release.
Normally we have just an informal "if everyone is OK with this, I'd like
to push out release X on this day
are a lot more than "because it
is there".
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Agreed. Isn't the issue that the JAXP in Tomcat's endorsed is
incompatible with 1.5?
Joseph Shraibman wrote:
I don't know why you want to get rid of endorsed. Sure java 5.0 will
have an up to date xerces, but it will get out of date in the future,
so you might as well keep the endorsed direct
I would *guess* that those not bothering to move from 1.3 (for whatever
reason) are mostly the same folk who won't upgrade to a more recent
Tomcat version anyway.
--
Jess Holle
Shapira, Yoav wrote:
Hola,
"Write once, run anywhere" - why would you choose a target that will
onths, but I'd guess that
though 1.5 could be the default, 1.4 support will be needed for up to 12
months after Sun's initial 1.5.0 release.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional c
in cases, etc)
3. Narrower platform mix to mess with supporting / answering
questions on, etc.
--
Jess Holle
Any chance of a 5.0.30 with this resolved in the near future?
[I take it you're back from vacation, Yoav, as I see CVS commit notices
with your name on them.]
--
Jess Holle
Shapira, Yoav wrote:
Hi,
Thanks for spotting and reporting this issue. While Tomcat 5.0.x
doesn't officially su
*guessing* this may have something to do with the following change
log entry:
30984 <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30984>:
Added compilerTargetVM option to Jasper. (yoavs)
--
Jess Holle
Java 5
is fine, but having hooks into sun.* or MX4J or whatever classes
is no good
--
Jess Holle
Remy Maucherat wrote:
Dominik Drzewiecki wrote:
I couldn't get the attach to process thing to work, though (=
without a port). Is it supposed to be doable ?
Neither have I (I am talki
multi user setup would run FAT and expect security, so you
are fine allowing anything you want on FAT (at least, I can't see how
it makes stuff more secure).
Ah...
All my file systems are NTFS...
--
Jess Holle
-
To unsubscri
Costin Manolache wrote:
Jess Holle wrote:
In general the same-user, same-machine stuff works great (including
with Tomcat 5) if you specify
-Dcom.sun.management.jmxremote
as part of the command line.
Again - remember not everyone is using Sun JDK1.5 implementation.
My understanding is Macs
et of patches that (1) defaults the source release to
1.3 as well and (2) allows this to be controlled in a completely
independent and analogous manner to target release.
I would appreciate seeing this in 5.0.30 :-)
--
Jess Holle
--- JspC.java 2004-10-05 13:30:36.0 -0500
+++ JspC.jav
isteners and filters]
--
Jess Holle
aking this
action)?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I've been trying hard to verify something:
Is the cachesize configured with mod_jk per process in a multi-child
Apache? I'd *assume* so, but I know where assuming tends to get me....
--
Jess Holle
-
To unsubscri
, what else
is missing to have Tomcat 5.0.20 be every bit as good as 5.0.19 but with
more bug fixes?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Remy Maucherat wrote:
Jess Holle wrote:
Can you elaborate on "may not be very useful"?
Generally, people expect to be able to run a binary out of the box.
I concur that this is the normal expectation and that the Tomcat group
should pressure the board to ease up.
If they don't
It is my understanding mod_jk2 2.0.4 is due this week and that the plan
is to release mod_jk 1.2.6 shortly thereafter.
Is this still accurate?
Any further light that can be shed on this (e.g. how long to expect to
wait for 1.2.6) would be appreciated.
--
Jess Holle
1 - 100 of 198 matches
Mail list logo
