+1 on building with 1.5 by default, *as long as
it doesn't preventing tc from running on 1.4* (we
use tc 5.5 / Java 1.4 in production right now,
with no sign of switching JDK in the near future).
If it breaks 1.4 compatibility, wait for tc 6.0 to switch compiler version.
How about building
Yoav Shapira wrote:
Hi,
Mmm, I'm not sure. The download page is already somewhat cluttered with a
bunch of different distributions and their assorted files (zip/tar.gz, PGP and
MD5 for each, etc.) I don't want to double the number of binary distributions
per release.
And I'm even less excited
Hi,
Given the discussion on missing JSSE15SocketFactory because tomcat
5.5.12was build using JAVA
1.4, I am trying to determine if I need to rebuild the whole source tree
under JSDK 5.0 or just the missing JSSE15SocketFactory. In order to make
that judgement call, I need to understand if there is
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37407.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Author: yoavs
Date: Fri Nov 18 07:35:53 2005
New Revision: 345502
URL: http://svn.apache.org/viewcvs?rev=345502view=rev
Log:
Bugzilla 37407: http://issues.apache.org/bugzilla/show_bug.cgi?id=37407
Modified:
tomcat/container/tc5.5.x/webapps/docs/changelog.xml
Modified:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36922.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32081.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Author: yoavs
Date: Fri Nov 18 07:54:56 2005
New Revision: 345508
URL: http://svn.apache.org/viewcvs?rev=345508view=rev
Log:
Bugzilla 37284: http://issues.apache.org/bugzilla/show_bug.cgi?id=37284
Modified:
tomcat/container/tc5.5.x/catalina/src/bin/catalina.sh
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37284.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37285.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Check the build.xml files, look for 'unless'.
Probably the right solution to avoid this would be to stop using
'unless' and ant checks,
and instead move all the 'conditional' code in separate targets and
jar files. In particular, the
whole SSL stuff is an unpredictible mess.
I'm not even sure
Tomcat repackages commons-collections, so Tomcat won't know or care if you
ship the actual commons-collections jar with your application. It's looking
for classes in the org.apache.tomcat.dbcp package, not the
org.apache.commons one.
- Original Message -
From: Andy Cutright [EMAIL
Author: pero
Date: Fri Nov 18 13:07:23 2005
New Revision: 345567
URL: http://svn.apache.org/viewcvs?rev=345567view=rev
Log:
Fix that sendMessage signature at all DataSender subclasses must be changed.
Fix that socket at o.a.c.cluster.tcp.FastAsyncSocketSender can be
disconnect/connect
Modified:
thanks for the info,
cheers,
andy
-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED]
Sent: Friday, November 18, 2005 12:53 PM
To: Tomcat Developers List
Subject: Re: why is commons-collections being modified?
Tomcat repackages commons-collections, so Tomcat won't
Author: pero
Date: Fri Nov 18 13:32:27 2005
New Revision: 345579
URL: http://svn.apache.org/viewcvs?rev=345579view=rev
Log:
remove debugging statements
Modified:
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/DataSender.java
Modified:
Costin Manolache wrote:
Check the build.xml files, look for 'unless'.
Probably the right solution to avoid this would be to stop using
'unless' and ant checks,
and instead move all the 'conditional' code in separate targets and
jar files. In particular, the
whole SSL stuff is an unpredictible
On 11/18/05, Remy Maucherat [EMAIL PROTECTED] wrote:
I'm not even sure if/how can we use OpenSSL via APR ( I found some
code, and it should work ). The whole connection layer should be
It actually works.
I'm happy I got regular HTTP/APR working, wasn't easy :-)
refactored to allow
Author: markt
Date: Fri Nov 18 15:16:31 2005
New Revision: 345597
URL: http://svn.apache.org/viewcvs?rev=345597view=rev
Log:
Fix MARC links. Add actual posting addresses to hopefully stop people sending
messages to the owner address asking how to post once they have subscribed.
Modified:
Costin Manolache wrote:
So for NIO - we should create another copy of 5 large files ? Most of
the functions are complete duplicates - a simple extend would eliminate
them.
The problems are in few abstractions - like Handler - which can be
easily fixed to
accomodate NIO / APR or traditional.
On 11/18/05, Remy Maucherat [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
So for NIO - we should create another copy of 5 large files ? Most of
the functions are complete duplicates - a simple extend would eliminate
them.
The problems are in few abstractions - like Handler - which
Costin Manolache wrote:
For C++ servers - yes.
For Java servers - is anyone else using it besides tomcat ? Even in
tomcat - how many
people are using the bindings ( compared with the non-apr connector ) ?
Unfortunately - NIO is the well-accepted solution for java servers (
all except tomcat
are
On 11/18/05, Remy Maucherat [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
For C++ servers - yes.
For Java servers - is anyone else using it besides tomcat ? Even in
tomcat - how many
people are using the bindings ( compared with the non-apr connector ) ?
Unfortunately - NIO is the
22 matches
Mail list logo
