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 it themself
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.
Unfortunately, some
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:
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 be more easily
- 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 right now
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
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 by comparison for such use cases
--
Jess
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 the other
settings
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
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: [EMAIL PROTECTED
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 various
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:
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? At a high
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
responsible
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
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 PROTECTED]
For additional commands, e-mail
Is there a timeframe for moving to Commons DBCP and Pool 1.2?
Just curious
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Shapira, Yoav wrote:
Hi,
OK, if we already have an established practice to continue development on HEAD, that's OK. I'll branch TOMCAT_5_0 when I tag 5.0.27 then.
Wouldn't you branch it now prior to any non-5.0 work being done on HEAD?
--
Jess Holle
is preferable.
--
Jess Holle
Jeff Tulley wrote:
For a third time, we have had a defect logged on the fact that I
introduced a bug into JNDIRealm while adding a new filtering feature.
The fix was very simple and has been made, but post-release of 4.1.30.
That, and the admin application largely
enhancements, including...
Perhaps Tomcat 4.1.x's verbage should be more like Tomcat 4.0.x's, i.e.
state that it is an old production quality release...
--
Jess Holle
Shapira, Yoav wrote:
Hi,
It's unlikely you'll see a 4.1.x release for any one feature, unless
it's a critical security fix. 4.1.x will have
Glenn Nielsen wrote:
On Wed, Apr 14, 2004 at 03:04:51PM -0500, Jess Holle wrote:
Jan Luehe wrote:
Sandy McArthur wrote:
Does this mean J2SE 1.3 support is no more?
On Apr 14, 2004, at 1:45 PM, [EMAIL PROTECTED] wrote: \
Log:
Added support for exception chaining
Remy Maucherat wrote:
(personally, I don't care about JDK 1.3 support anymore)
I'll strongly ditto that
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
of Tomcat as well), I do believe a statement
that this and future versions of Tomcat shall require Java 2 v1.4 or
higher should accompany the first public release after any change
requiring Java 2 v1.4 for basic functionality.
--
Jess Holle
something portable between 2.3 and
2.4 here.
[Replying on mailing list as Bugzilla is down.]
Actually you can -- but you have to check the servlet engine spec
version and have different logic branches for each version.
It's ugly, but it is doable.
--
Jess Holle
Thanks!
It works great.
--
Jess Holle
NormW wrote:
Good morning.
Add the _keyword only_ (forwardURIEscaped) in the workerEnv section in
workers2.properties. (ie, it is _not_ used in an 'zzz = xxx' format
statement.
Norm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS
is considered as good as CVS head for a little while...)
--
Jess Holle
Henri Gomez wrote:
Remy Maucherat wrote:
ballot
Release 5.0.22 as Stable:
[ ] Yes
[ ] No
/ballot
I've tested the new Windows wrapper, and it did work for me (and it
looks as if we did hire some M$ guy to do its UI). However, some more
to try to get as many of the fixes
in process into each public release -- rather than having to refer the
masses to CVS for weeks...
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Remy Maucherat wrote:
Jess Holle wrote:
I'm not a committer, but...
Given the number of did you get _ important fix xyz _? mails,
it seems to make sense to re-tag.
It has been a while since a public release and it would be nice to
have a public release with this latest flurry of fixes
I also tried this and everything worked nicely.
NormW wrote:
Good morning All.
Just tried Jean's recent change to mod_jk2.c and _pleased_ to say JkUriSet
now registers correctly the same as a [uri] section, and can access /admin
with only a Location in the httpd.conf. I did note there were
it if this could be incorporated into the
Jasper/Tomcat source stream.
--
Jess Holle
[EMAIL PROTECTED]
Sorry, I should have said mod_alias, not mod_dir...
--
Jess Holle
Jess Holle wrote:
mod_jk2 2.0.4 seems to have the same issues that several mod_jk 1.2.x
releases had with mod_dir.
Specifically something like:
Alias /MyWebApp D:\my_app_view\Myapp/codebase
Directory D:\my_app_view\Myapp
Henri Gomez wrote:
Jess Holle wrote:
Sorry, I should have said mod_alias, not mod_dir...
With Apache 1.3 or 2.0 ?
2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not
bothered with mod_jk2 with Apache 1.3 -- I just use mod_jk there on an
old with old sort of principle.]
I
as necessary if the Tomcat group is not flexible in this matter.
--
Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
I'm not arguing with the overall intent of your change. Rather I
believe that calling the constructor during compilation is wasteful
and improper as the environment *can* differ
down to the bare
essentials. There are larger reasons for me needing to take this sort
of approach...
--
Jess Holle
P.S. I see warnings that worker is deprecated and that I should use
group in the logs. Is this just a change in terminology? Where does
it all apply?
Jess Holle wrote:
jean-frederic clere wrote:
Settings and test case of course more than welcome :=}
I think I have reproduced it with the following:
+++
Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples
Location /examples/servlet/*
JkUriSet group ajp13:pgtr0327:8009
for uri and
match_type suffix sounds weird for me.
And using a VirtualHost works around the problem... (That is why I
have not dectected it before).
And to re-iterate 2.0.2 does not have this issue.
--
Jess Holle
-
To unsubscribe, e
:-)
getConstructor() will only return public constructors (as per Javadoc
and the Java sources), so that's handled already.
I'll add and test the missing line (or possibly 2) shortly.
Thanks for the help.
--
Jess Holle
-
To unsubscribe
Jess Holle wrote:
Kin-Man Chung wrote:
Your test for bad beans is much weaker than what it is now. For
instance,
you do not catch the case where the bean class is abstract.
Ah, yes, you are correct. That can also be easily checked with an
additional line of code, of course.
However, I am
as
there are important fixes and enhancements in mod_jk2 2.0.4. Without
this working, however, 2.0.4 is a non-starter for me.
--
Jess Holle
P.S. I can certainly give more details, file a bugzilla bug, etc, as
necessary. I just got back from vacation, tried out mod_jk2 2.0.4 and
wanted to get
Jess Holle wrote:
Works just great in quick testing at least.
I'm still waiting for my precompilation script to return to determine
whether Jasper still compiles everything it used to (and should have).
Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages
(which Tomcat 5.0.19
that what they're doing is completely wrong.
Overall, however, the change in 5.0.20 still seems questionable -- at
least with respect to the many other details (e.g. that the default
causes new failures, that the compiler flag is not accessible via
JspC.main(), etc...)
--
Jess Holle
if
errorOnUseBeanInvalidClassAttribute is set to false.
This should be more efficient, avoid breaking pages using beans with
non-trivial environmental constraints for successful construction, and
follow the letter of the spec better as I see it.
--
Jess Holle
Tim Funk wrote:
http://nagoya.apache.org/bugzilla
P.S. Nothing in the quoted spec segments implies that the JSP compiler
should attempt to actually *instantiate* beans at compile time or expect
that that should work.
--
Jess Holle
Jess Holle wrote:
Based on the given bug id, I would propose a different implementation
than that found
is fine as long as that's understood by the user
community.
Personally, JavaService and an Ant script to produce the right
(enormous) command line for seem to do the trick nicely -- with Tomcat
4.1.x and 5.0.x.
--
Jess Holle
Is there a source tarball for 2.0.4 available for download somewhere yet?
--
Jess Holle
Henri Gomez wrote:
jk2 2.0.4 has been tagged.
jk2_2_0_4
We're now in HEAD at 2.0.5-dev
-
To unsubscribe, e-mail: [EMAIL PROTECTED
installing and removing my service with procrun.
--
Jess Holle
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 I might suggest
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
Remy Maucherat wrote:
Jess Holle wrote:
One area of immediate concern: Is jmx.jar an additional top-level jar
that must be added to CLASSPATH or java command lines to run Tomcat?
Or is it automatically picked up by Bootstrap, etc, as before? [This
will clearly affect a number automated
just enough for our application's needs, but none
of it is specific to them.
--
Jess Holle
Tim Stewart wrote:
Hey Jess,
I would be interested in seeing your ant scripts to configure tomcat and
apache. Would you mind posting a URL or sending them to me?
Thanks,
Tim
- Original Message
Works just great in quick testing at least.
I'm still waiting for my precompilation script to return to determine
whether Jasper still compiles everything it used to (and should have).
--
Jess Holle
Remy Maucherat wrote:
The new build is now available (a bit late, but with additional fixes
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 unsubscribe, e-mail
this
action)?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
]
--
Jess Holle
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!]
--
Jess Holle
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]
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 unsubscribe, e
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
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% of the market.
--
Jess Holle
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 into the OS
?
[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
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 unsubscribe, e-mail: [EMAIL
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 goal is not to scale
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 desirable
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-mail: [EMAIL PROTECTED
Jeanfrancois Arcand wrote:
ballot
Release 5.0.18 as Stable:
[X ] Yes
[ ] No
/ballot
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
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
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, lets fix it.
Filip
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 regard!
--
Jess Holle
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
default settings be for the
suggested Sun techniques to work...
--
Jess Holle
a new bug and argued to high hell...
--
Jess Holle
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 commands, e-mail
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 (incl recent ones
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 apparently
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
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]
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
.
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
are assigned.]
--
Jess
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 PROTECTED
I don't have a vote, i.e. I'm not a committer, but for what it's worth:
Remy Maucherat wrote:
ballot
Release 5.0.16 as Stable ?
[*X*] Yes
[ ] No
/ballot
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
or... what?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 wrote:
Jess Holle
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 Holle
/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-mail: [EMAIL PROTECTED
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
an 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.
--
Jess Holle
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
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 I've built binaries
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
Is there a new estimate for the Tomcat 3.3 release date?
The classloader separation and performance improvements are really
attractive, but I really need to know when to expect their availability or
they're of no use (until well after their release).
--
Jess Holle
-Original Message
101 - 196 of 196 matches
Mail list logo
