Was 1.2.14.1 ever officially released?
If not, will it be soon?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Where are the zip/tar balls of the sources for those wishing to jump the
gun? [I assume they're not changing at this point...]
Jean-frederic Clere wrote:
Jess Holle wrote:
Was 1.2.14.1 ever officially released?
I have to annonce it ;-)
If not, will it be soon?
--
Jess Holle
this should actually make Josh's
task easier.
--
Jess Holle
Jess Holle wrote:
Fenlason, Josh wrote:
Where could I find the 1.2.14-dev source bundle? Thanks. , Josh.
I'm betting you have to snag it with an SVN client. Am I right? If
so, is it just a simple/default latest setting to get
Fenlason, Josh wrote:
Where could I find the 1.2.14-dev source bundle? Thanks.
,
Josh.
I'm betting you have to snag it with an SVN client. Am I right? If so,
is it just a simple/default latest setting to get this?
--
Jess Holle
Out of curiosity, is a mod_jk 1.2.14 vote set to occur at some point?
Or are there known issues with 1.2.13 at this point? [My understanding
is that the odd-even release # model is now being followed -- correct?]
--
Jess Holle
case?
[I stopped using prefork on all platforms when moving to Apache 2.]
--
Jess Holle
Mladen Turk wrote:
Hi,
Here are the brief results for Tomcat HEAD:
Server Threads Pause (ms) Error(%) Rate (req/sec)
Apache2.0.49500 1000 1.74 124.2
Http11Protocol 500 1000
. to take a step forward in
terms of performance, etc, without requiring native code? [I'm not
saying NIO covers all the bases APR would or is as fast. Rather
wondering whether performance efforts should not remain in the pure Java
space until that is truly exhausted.]
--
Jess Holle
Remy Maucherat
to me.
javac is not a panacea but it support Java 5 quite nicely right now.
[I'm using NetBeans 4, so I'm unaffected by Eclipse's move -- it just
baffles me.]
--
Jess Holle
Remy Maucherat wrote:
Tim Funk wrote:
Is there a reason _jspx_dependants is a Vector - why not an
ArrayList? This would
with.]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
differently (they're
almost Microsoft like in that respect...) -- and people obviously use
the path of least resistance, i.e. whatever their distro provides.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
something here? [For now I have been configuring
to have only 2 worker processes on UNIX for a little redundancy but each
with a cachesize of 1/2 my Tomcat max threads setting.]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL
,
I'm lazy and won't be building/patching my own before this given that
I'm on vacation with the family.]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
both
the patch submitter and committer in the change log.
As a sometime patch submitter, I appreciate this.
--
Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
Jess Holle wrote:
Okay, I did a bit more digging.
*If*:
* Your web app contains log4j.jar *and* commons-logging.jar.
* You do not have log4j installed in any of Tomcat's own lib
directories.
* You use a JNDI or other contextual classloader
web app but not using the LoggerRepository I
designated for my web app...
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
), but it's similar to JNDI handling.
Understood. I've already got reasonable JNDI-based approach -- assuming
the static loggers are to be cleaned up any time in the near future.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED
the loggers are, but I guess more
thorough debugging on my part is in order. Perhaps I am mistaken and
these are Tomcat loggers, but are specific to my web app.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Jess Holle wrote:
Remy Maucherat wrote:
BTW, JBoss (supposedly, I didn't check personally) uses
commons-logging everywhere, and the logging implementation used is
log4j.
That works since *everything* uses log4j. The issue is with Tomcat
is really one of *not* having log4j at the Tomcat level
want to install my
LoggerRepository controlling MBeans up at this level as well -- as
log4j's MBeans have issues and using log4j loggers means you don't
get the (admittedly sparse) java.util.logging MBean coverage.
--
Jess Holle
Jess Holle wrote:
I have been trying to get really serious about
P.S. Why does Tomcat use Commons Logging rather than UGLI?
Jess Holle wrote:
I had e-mailed this to users mailing list, but I have what I believe
is a more dev follow-on question:
Is there a good way to get my own start/stop action called at a
per-VM level?
This is assuming I end up
...
--
Jess Holle
Yoav Shapira wrote:
UGLI is far from mature enough to be used by Tomcat at this point. When
log4j 1.3 is out, we'll see.
Yoav
-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 4:17 PM
To: Tomcat Developers List
Subject: Re: Web apps vs
and bizarre when log4j is used in a web app but Tomcat itself does not
have log4j installed, but this is only part of the issue.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
that log4j loggers are not JMX-exposed, I'd like to put
some MBeans to do this up at the Tomcat application level. I do
this in my web app, but I'd like to have the Tomcat-level MBeans
installed even without any of my web apps installed.
--
Jess Holle
Yoav Shapira wrote:
Hola,
Your approach
Bill Barker wrote:
- Original Message -
From: Jess Holle [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Thursday, March 17, 2005 2:25 PM
Subject: Re: Web apps vs. Logging vs. Tomcat
Just one more stupid question:
How/where would I register/deregister
Remy Maucherat wrote:
Jess Holle wrote:
Why out of curiosity? I don't have a pro-UGLI ax to grind here, but
Commons-Logging's behavior in Tomcat is really undesirable as is.
It would be the same anyway: the loading configuration and the logger
instances will be tied to the webapp classloader
automated generation of MBean
descriptions, operation parameter names, impacts, etc, from MBean
interface Javadoc, formal parmeter names, annotations, etc, quite
simple. A little more elbow grease and the descriptions are localized
(based on the server's locale).
--
Jess Holle
to tellNew() and expire() is
rather telling.
I plan to rework this code along the lines of tellNew() and expire() to
get proper functionality
--
Jess Holle
Attached is a patch (against the latest 5.5.x source) that addresses
this issue.
--
Jess Holle
Jess Holle wrote:
It appears that the activate() and passivate() routines of
StandardSession are not functioning properly. [I've only tested
5.0.30, but 5.5.x seem to have identical erroneous
this to everyone else's attention.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
a JDT
that fully supports Java 5.
I realize this is not a Tomcat issue as much as a JDT issue -- except
that Tomcat 5.5 uses JDT by default. I also realize scriptlets are
considered evil -- but they, and hard requirements for Java 5 *now*, are
a fact of life for some of us.
--
Jess Holle
A related question would be when will the JDT embedded in Tomcat 5.5
support Java 5 language compilation.
--
Jess Holle
Yoav Shapira wrote:
Hi,
Tomcat is not a full J2EE container, only a Servlet and JSP container.
Accordingly, J2EE spec releases don't matter per-se. They only matter
Apache 2.1/2.2 -- which means it has not yet arrived
for the majority of us.
I personally applaud Mladen for his efforts to fix/improve/maintain
mod_jk given that that is the reality for most of us.
--
Jess Holle
-
To unsubscribe, e
).
Ideas?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
You can and have fixed CLASSPATH in the past.
Use of the JRE's lib/ext or lib/endorsed is different -- and not
reasonably solvable, though.
--
Jess Holle
Remy Maucherat wrote:
Tim Funk wrote:
I'm going to abstain from voting since I am unable to adequately
test. But I did find one item which
I'm not a commiter, but...
I tried with our app on Windows (didn't get time for Solaris and AIX
yet) and it worked just fine.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
noticed the ability to monitor the currentThreadsBusy in
ThreadPool.]
Am I (hopefully) overlooking this in the existing MBean stack? Or are
these candidates for addition?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED
closure.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
that it is running 15 times as often!
Agreed! I think the 5.0.30 FileStore and JDBCStore implementations are
extraordinarily silly in this regard!
Please see my patches to StoreBase, FileStore, and JDBCStore in this regard.
--
Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
[Yes, the Request change would still be necessary to prevent the
chance of requests randomly getting their sessions passivated and
recycle after they findSession() but before access().]
A session can be passivated at any (bad) time (which will screw up
Remy Maucherat wrote:
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at this
moment in this case).
Ok, but I still dislike the patch ;)
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear
Remy Maucherat wrote:
Jess Holle wrote:
It is not useful without the rest of the changes as without the rest
of the changes there are intolerable race conditions.
Right. I suppose that's the end of the discussion then, it would be a
waste of time to continue. -1 for your patch.
If you really
Remy Maucherat wrote:
Jess Holle wrote:
Where have I faked robustness? I will not claim I actually achieve
it, but I certainly tried, fixed real race condition cases, and don't
know of ones I missed.
The only race condition that I can possibly imagine is on accessCount,
which I think
passivated and recycle after
they findSession() but before access().]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
() call in swapIn() --
though other unbalanced calls might benefit from some debug code in
endAccess() as well...).
--
Jess Holle
Jess Holle wrote:
On further analysis it seems that StandardSession is only constructed
by ManagerBase and indirectly from SimpleTcpReplicationManager via
And finally, here are the patches against 5.5.6 (same as HEAD at this
moment in this case).
--
Jess Holle
Jess Holle wrote:
Here's the patches against 5.5.4
Jess Holle wrote:
For those who tried finding through the patches only to find that
they did not properly map against CVS (as I just
Jess Holle wrote:
Remy Maucherat wrote:
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at
this moment in this case).
Ok, but I still dislike the patch ;)
I'd appreciate comments as to what's wrong with the patch :-)
Sorry I missed your previous comments somehow
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear issues
in this area of the code that I cannot ignore if I am to depend on
PersistentManager.
* Extremely
over the
current code, so I'd appreciate it if someone reviewed them a bit --
especially the 5.5.6 versions as it would be good to see this merged in
to 5.5.x at least.
--
Jess Holle
Jess Holle wrote:
A week or two ago I found I had need of the persistent session
manager, PersistentManagerBase
Here's the patches against 5.5.4
Jess Holle wrote:
For those who tried finding through the patches only to find that they
did not properly map against CVS (as I just used 'diff -u' in a
directory not in a proper CVS tool...), please see the attached patch
files against 5.0.30 (which were
of the patches are against
5.0.30, but I could update them for 5.5.x if there was sufficient
interest (e.g. if a committer was interested in committing them).
--
Jess Holle
[EMAIL PROTECTED]
--- StandardSession-5.0.30.java 2004-12-13 21:28:06.0 -0600
+++ StandardSession.java2004-12-13 21:28
should be resolved? I'm digging around, but my experience with all of
the pieces involved is rather limited.
--
Jess Holle
()
would suffice.
Suggestion would be appreciated!
--
Jess Holle
Jess Holle wrote:
I have dire need to use PersistentManager, which is experimental at
this time.
Looking in the source, I note 2 FIXME comments -- one of which seems
to clearly indicate a race condition. It actually occurs twice
After no more betas are in order is the plan to release a stable 1.2.7
or to bump the version up to 1.2.8 at that point?
[Sorry for the question but I seem to recall both possibilities being
uttered previously.]
--
Jess Holle
P.S. Thanks to all for all the hard work on JK 1.2.7, especially
this
direction at this time.]
Any/all pointers in this regard would be appreciated.
Thanks for your time.
--
Jess Holle
[EMAIL PROTECTED]
Remy Maucherat wrote:
Jess Holle wrote:
I have a need to passivate HttpSessions on a more aggressive basis
than that of timing them out.
Default behavior is to time out a sessions after 30 minutes of
inactivity -- which is fine.
Rather I need to be able to passivate sessions to disk after say
see any from the brief description
I've given...]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
It's called persistent manager, and it's the same place as the
standard manager, in the session package.
There's even docs:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html
Thanks for the pointer!
It appears to have
Jess Holle wrote:
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
It's called persistent manager, and it's the same place as the
standard manager, in the session package.
There's even docs:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html
Thanks for the pointer
change. [I actually ended up using jconsole
to visually diff between a working Tomcat instance of an older
version and 5.5.3.]
--
Jess Holle
and mod_jk/mod_proxy_ajp, right?]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Mladen Turk wrote:
Hi all,
I've done some JK commits that I've been testing for a long time.
The major addition is socket timeout that was missing, causing
couple of minutes delays on some platforms if tomcat was down.
Also I've back ported the load balance algorithm from proxy_balancer,
that
Mladen Turk wrote:
Jess Holle wrote:
Mladen Turk wrote:
I've done some JK commits that I've been testing for a long time.
Have you updated the docs for the lb_factor and socket_timeout changes?
That's the thing I'm planing for the all next week.
I would like to rewrite the entire JK docs using
I believe is the case in
5.5), then just having your Xerces (which should have such a META-INF
entry) in your web app should suffice.
But honestly, Xerces 1.4.4!?! That's positively ancient.
--
Jess Holle
-
To unsubscribe, e
I accidentally got Windows end-of-line sequences in the last set of
patches. Here's a better set.
--
Jess Holle
Jess Holle wrote:
Okay, I now (belatedly) understand the problem.
The issue is that by default Jaspper is setting the target release to
1.3 but leaving the source release unspecified
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.java-new
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 support J2SE
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 talking
stupid. No 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
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
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
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
not
run
, 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 commands, e-mail
/ answering
questions on, etc.
--
Jess Holle
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
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 think we managed to get
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 another RM
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.
--
Jess Holle
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
.
--
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 and then a vote
because it
is there.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-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 specific pointers to
bug
;-)
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, etc.
Just a thought
--
Jess Holle
of 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
-- 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
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 Holle
that this issue
ceases to be an issue for everyone using Tomcat.
--
Jess Holle
in my own distribution,
but I always like to see a single, consistent fix for everyone.
--
Jess Holle
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]
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
, but a *separate* project and
module.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
, 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]
For additional commands, e
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 compared
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...]
--
Jess Holle
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:[EMAIL
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. Please
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
thinking
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 days
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 additional commands, e-mail
1 - 100 of 196 matches
Mail list logo
