Mark Thomas wrote:
Using externals wasn't something I had thought of but if offers a nice
way to provide all the source for one version in a single chekcout. We
now have tomcat/current/5.5.x that uses externals to link in all the
various modules.
That's actually what I was thinking
Could we just move all in tomcat5.5 ( and HEAD ) into one repository (
say, tomcat ) ?
Like:
tomcat/
tomcat/catalina
tomcat/connectors
tomcat/jasper
tomcat/build ( or something else - jakarta-tomcat-5 is just the top
level build and utils )
There is little benefit those days in having 4
Remy Maucherat wrote:
Jan Luehe wrote:
As a reminder, CVS shound't be used anymore.
I commited a bunch of small changes, don't know how easy it'll be to get
them in after the switch to svn. Let me know if there's a problem, I can
roll them back.
BTW - I had some of the changes in
BTW - there are still few files missing, but the end result is a 1.2M
jar containing all deps, that can be run with java -jar and only
requires a webapps/ dir in the current dir.
Costin
[EMAIL PROTECTED] wrote:
costin 2005/09/28 23:07:24
Modified:.build.xml
Log:
Add a
I have few weeks, I'm trying to sync up some of the few changes I made
in the last year before the code is moved to svn and try a bit more
the 'embedded' scenario ( both single-jar tomcat - that actually works
well, and also coyote-only ).
I uploaded 2 jars at
William A. Rowe, Jr. wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
I doubt that filling the inbox with the bug reports or commit messages
will make anyone care more ( or make anyone read them when they don't
want to ) :-) It seems most people use filters anyway, and those who
don't
Mark Thomas wrote:
Mladen Turk wrote:
Costin Manolache wrote:
Hi,
Also, I would like to add another directory under j-t-c, with a build
file and few classes for a 'mini' experiment - i.e. using the
connector standalone, as a minimal http server, and also a target to
build a minimal
The current servlet spec doesn't requires J2SE 5.0 - only the next one (
another stupid forced, unjustified transition IMO ).
I would assume JDK1.4 will be supported for a while, as long as the
current version of the servlet spec is in use.
Tomcat3.3, which supports JDK1.1, has been maintained
Bill Barker wrote:
- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: tomcat-dev@jakarta.apache.org
Sent: Thursday, September 08, 2005 10:56 PM
Subject: Small refactoring in Http11Processor
Hi,
I have a small patch, spliting the JMX-dependent code in
Http11Processor
Remy Maucherat wrote:
So I, for one, would be most appreciative of splitting the traffic; I
already do split it in my email client, but I think this would be a
help to many participants. [Especially if, for example, you want the
dev@ traffic to go to a higher priority email account, and have
@@
* @author Remy Maucherat
* @author Costin Manolache
*/
-public class Http11Protocol implements ProtocolHandler, MBeanRegistration
+public class Http11Protocol extends Http11BaseProtocol implements
MBeanRegistration
{
public Http11Protocol() {
-cHandler = new Http11ConnectionHandler
Nathan Bubna wrote:
On 8/23/05, Remy Maucherat [EMAIL PROTECTED] wrote:
Nathan Bubna wrote:
hey folks,
i'm a developer on the VelocityTools subproject, and we recently came
across an issue with the use of commons-logging in Tomcat 5.5.9.
by default, we configure our example applications to
With worker - it may work. However you may find mod_jk inprocess to be
slower than ajp and mod_proxy ( or comparable in speed ), this is due to
the way parameters are passed as strings ( i.e. lots of unoptimized
char-byte conversion ).
Porting to 5.5.x shouldn't be hard - the interface
Did tomcat move to svn already ?
Costin
[EMAIL PROTECTED] wrote:
Author: markt
Date: Sun Aug 14 04:48:32 2005
New Revision: 232601
URL: http://svn.apache.org/viewcvs?rev=232601view=rev
Log:
Remove CVS closure warning from SVN
Removed:
tomcat/watchdog/branches/tc4.1.x/WARNING.txt
Bill Barker wrote:
Costin Manolache [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Bill Barker wrote:
If I understand you correctly, you want MsgAjp to use ByteBuffer instead
of byte []. At the cost of never supporting JDK 1.3 ever again, this
would probably actually improve
Bill Barker wrote:
If I understand you correctly, you want MsgAjp to use ByteBuffer instead
of byte []. At the cost of never supporting JDK 1.3 ever again, this
would probably actually improve the performance of ChannelSocket (after
changing it to use a blocking SocketChannel).
The
Mladen Turk wrote:
Scott Marlow wrote:
Hi,
I wonder if anyone has any feedback on a performance change that I am
working on making.
Can you compare the performance of you code with the standard
implementation when the concurrency is lower then maxThreads
value?
I see no point to make patches that
Remy Maucherat wrote:
I looked at this yesterday, and while it is a cool hack, it is not that
useful anymore (and we're also not going to use the concurrent utilities
in Tomcat, so it's not really an option before we require Java 5). The
main issue is that due to the fact keepalive is done in
Mladen Turk wrote:
Costin Manolache wrote:
I'm still trying to understand the APR connector, but from what I see
it is still mapping one socket ( 'keep alive' connection ) per thread.
No it doesn't. If the connection is keep-alive, and there is no activity
for 100ms, the socket is put
Remy Maucherat wrote:
Keith Wannamaker wrote:
If no one else is concerned that Tomcat 5.5 doesn't work by default
Any other nonsensical statement to make ? The only thing that does not
work is opening third party documents from the website, due to IE's
broken handling of this.
How about a)
Remy Maucherat wrote:
Need to identify just how much of the jakarta-* CVS will go with
Tomcat. Watchdog + ServletAPI modules?
That's undecided. Would the old projects would remain at Jakarta, or
would they be covered by the new project ?
Why would they remain in jakarta ? They have the same
Tim Funk wrote:
Looks good. Just an idea, it may be nice to have the 3 new lists
tomcat-bug - bug updates from bugzilla. When I subscribe to other groups
tomcat-cvs - Same as tomcat-bug but just for cvs commits.
tomcat-gump - For deaths by gump. If your not a committer - these are
This has
Kurt Miller wrote:
From: Yoav Shapira [EMAIL PROTECTED]
Below is the draft resolution we agreed on previously, so it should be
pretty close. We need to make sure the PMC names are correct and
complete.
Congrats to Remy and thanks everyone for voting, and of course thanks
Henri
;)
Yoav
While
Remy Maucherat wrote:
Kurt Miller wrote:
From: Yoav Shapira [EMAIL PROTECTED]
Below is the draft resolution we agreed on previously, so it should be
pretty close. We need to make sure the PMC names are correct and
complete.
Congrats to Remy and thanks everyone for voting, and of course thanks
Mladen Turk wrote:
Henri Gomez wrote:
I could provide Linux binaries for Suse 8.0 PPC and Suse SLES 9 but
it's up to distributions mainteners to provide such binaries (via
rpm/deb).
Take a look at jpackage for many Linux RPM binaries
Yes, that is my opinion too.
We should focus on providing a
Jim Jagielski wrote:
I would recommend that before anyone responds, we decide who should
rec' and tally the votes. Also, votes should only be counted
from those who will be on the new PMC.
So before the vote:
1. Finalize list of PMC members
(all current committers)
2. Determine who to
Yoav Shapira wrote:
The initial Tomcat PMC chair should be:
[ +1 ] Remy Maucherat
[ ] Yoav Shapira
Next year I'll switch, Yoav is great - I just think Remy deserves to be
the first chair...
Costin
-
To unsubscribe, e-mail:
Remy Maucherat wrote:
Costin Manolache wrote:
Yoav Shapira wrote:
If Remy is interested, I think it would be fair to have a vote. If
whoever is first later decide he had too much politics/admin pains -
we'll have a backup ready :-)
At this point, I think I cannot avoid being a candidate. Yoav
Jim Jagielski wrote:
The PMC Chair has ultimate authority, since the position is board
appointed and results in the Chair being a VP of the ASF. There's
no precedent for sharing the role or having a co-Chair. The PMC
Chair is the point man for the PMC.
Yes, we know - that's one of the reasons some
Yoav Shapira wrote:
NOW, THEREFORE, BE IT FURTHER RESOLVED, that [XXX]
be appointed to the office of Vice President, Apache Tomcat, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
Jim Jagielski wrote:
Yoav Shapira wrote:
Hi,
I could... But there's the question of whether we want all committers on the
PMC or just the active ones. The avail file has, in addition to the people
I already listed:
duncan,jon,rubys,akv,jhunter,preston,shemnon,shachor,bergsten,gonzo,mode,har
Yoav Shapira wrote:
Hi,
I would like to propose Remy == XX ( he can obviously refuse, but I
hope he will not do that ). Obvious reasons on why he is the best
choice, so I don't think consensus will be a problem - only his
acceptance ( it'll not involve too much coding :-).
I was thinking
Yoav Shapira wrote:
Howdy,
I think the idea of rotating ( let's say yearly ? ) would be an excelent
one - it'll avoid having people serve for too much ( and sometimes avoid
bad habbits - like forgeting to ask the community before making
important decisions :-)
That's a decent plan. What do the
Yoav Shapira wrote:
Hola,
What do you guys (parties in the subject) have to say about that?
Lat's put all the cards on the table, do what ever is needed and move
forward. I'm getting tired of all that politic bullshit, but I'm also
aware it must be done. So ... Remy, Yoav?
I'm waiting to hear
Mladen Turk wrote:
@if %1 == install goto cmdInstall
@if %1 == uninstall goto cmdUninstall
@if %1 == start goto cmdStart
@if %1 == stop goto cmdStop
@if %1 == restart goto cmdRestart
echo Usage
goto cmdEnd
I assume the '.bat' is the only option - i.e. could you use arbitrary
Both +1, of course.
I guess you meant 'commiters for jakarta tomcat project' :-)
Costin
Mladen Turk wrote:
I'd like to nominate Jim Jagielski ([EMAIL PROTECTED]) and
William A. Rowe ([EMAIL PROTECTED]) as commiters for the
JTC connectors.
Both of them are long time ASF members. Jim is even a
William A. Rowe, Jr. wrote:
At 06:31 AM 2/21/2005, Mladen Turk wrote:
Unlike any other java or java/jni implementations
it does not tries to make a java as a service, but
rather makes a batch (.bat) file as a service.
IIUC, that means;
1. service signals (shutdown etc) aren't recognized by cmd
no problems in the last year
of use.
Docs are docs :) Yep, they'll need updating.
Build scripts. Do you have scripts that check modules out of cvs? If
so I imagine the ant support for svn might be a big deal. Unsure what
it's like.
Hen
On Thu, 03 Feb 2005 21:32:41 -0800, Costin Manolache
[EMAIL
I assume this is going to be a compile/configure time option ?
What about using a different approach - generate multiple .so files, one
with common/base/non-optional functionality, and one for each optional
library. Compile time options makes it hard to distribute compiled
binaries and add more
What about:
- add this information to the bug report
- send a patch to the FAQ or edit a wiki page ( well, the tc wiki is not
very used, but probably google will find this if anyone has a similar
problem ). Or post it in your weblog/site/etc for google to find.
It should be obvious changing the
Al Sutton wrote:
Is there any reason why it doesn't try localhost first? Using localhost
before anything else would have the following benefits;
a) Would ensure that only really strange network configs would be affected
(i.e. those where localhost is not the local host).
b) Make use of the speed
Is this mandatory ? I suspect there'll be a lot of build
script/doc/habits/tool changes involved. CVS is working reasonably well
at the moment, and a lot of tools have (finally) very good support for it.
Costin
Henri Yandell wrote:
Just wondering if the Tomcat community have any thoughts on a
[EMAIL PROTECTED] wrote:
3) Cygwin is definatley NOT a good platform for testing Linux bugs on.
However testing with all possible linux distributions is not a good
choice either.
And distributions based on 'latest' version of everything plus all kind
of experimental/non stable/vendor specific
] Behalf Of Costin Manolache
Sent: 02 February 2005 21:22
To: tomcat-dev@jakarta.apache.org
Subject: Re: DO NOT REPLY [Bug 9] - Shutdown script down not work
[EMAIL PROTECTED] wrote:
3) Cygwin is definatley NOT a good platform for testing Linux bugs on.
However testing with all possible linux
Remy Maucherat wrote:
Allistair Crossley wrote:
*rotfl* that's not Remy at all! ;)
Those viruses are annoying, since I cannot prevent them from reaching
the list :( As long as they use a valid subscriber's address, I cannot
do anything. I suppose it would be caught by a spam filter though.
Rmy
The only way to do in-process with apache on unix is to use a
multithreaded MPM and a small number of processes ( and lots of
threads). JNI is not much more efficient than IPC - or at least not
in the simplistic use. Even the applets in mozilla/konqueror/etc run out
of process on unix ( but
To be honest, I don't like where this is going. I think access to native
functionality for tomcat is great - and starting with functionality
provided by apr is ok. But there is a lot outside apr, and if this
becomes 'apr - java interface', it won't be easy to add.
So maybe it would be better to
A lot of the code is actually specific to the now-dead Jk2 - if the
native jk2 is gone, probably you should clean up this side as well.
- org.apache.jk.apr - the not-quite apr jni layer that connects to the
native objects, as well as 'in-process' launcher ( I doubt it can be
used by jk1.x ),
Bill Barker wrote:
- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: tomcat-dev@jakarta.apache.org
Sent: Wednesday, January 12, 2005 4:14 AM
Subject: Re: Deprecation and JK2
A lot of the code is actually specific to the now-dead Jk2 - if the
native jk2 is gone, probably
Mladen Turk wrote:
Hi,
Here is the work in progress for a new project I named apr-java.
It offers a 'thin' layer using JNI over APR library.
The initial code that I wrote over a year now had
two way api, but I've decided to leave only
Java-APR.
I also have a working set of configure and make files
Remy Maucherat wrote:
Costin Manolache wrote:
Maybe:
* @author Jason Hunter, as part of the book Java Servlet Programming
* (O'Reilly). See a href=http://www.servlets.com/book;
* http://www.servlets.com/book/a for more information.
?
I think it is fair to respect the author wish for attribution
Jason Hunter wrote:
nor see why we need an exception for such a such a small amount of code.
You need an exception because (a) the code was included from a third
party codebase and (b) a lot of research and testing went into compiling
the map used by the mapper.
I can easily add an @author tag
Maybe:
* @author Jason Hunter, as part of the book Java Servlet Programming
* (O'Reilly). See a href=http://www.servlets.com/book;
* http://www.servlets.com/book/a for more information.
?
I think it is fair to respect the author wish for attribution.
Given that the board recomends against @author
Why don't you check in some of this to j-t-c or some 'proposal' area ?
AFAIK apr has a lot of functionality, but not everything is included.
It would be nice if it is not limited to apr.
Usually with JNI the hardest part is to build, distribute and then set
it up and debug ld_library_path issues.
Benson Margulies wrote:
For systems with a /proc file system with these statistics, this doesn't
require any JNI ...
Yes, there are a lot of ways to workaround java limitations. /proc is
one. But even on linux, a lot is not exposed via /proc, but ioctl.
I guess the goal is not to implement
level API
2. use apr-java to wrap apr
3. wrap apr-java with mbeans
or
something completely different?
peter
On Mon, 03 Jan 2005 11:21:55 -0800, Costin Manolache
[EMAIL PROTECTED] wrote:
Benson Margulies wrote:
For systems with a /proc file system with these statistics, this doesn't
require any JNI
Mladen Turk wrote:
Peter Lin wrote:
I'm thinking of adding system load stats to the status servlet. What
do other's think about it? It would use JNI to call a native lib and
it would only work on unix, but it would be good to have.
Well, I'm working over a year now on a project that I've called
Peter Lin wrote:
I'm thinking of adding system load stats to the status servlet. What
do other's think about it? It would use JNI to call a native lib and
it would only work on unix, but it would be good to have. I would also
update JMeter in the process to display the system load average.
peter
native code?
peter
On Fri, 31 Dec 2004 13:13:54 -0800, Costin Manolache
[EMAIL PROTECTED] wrote:
Peter Lin wrote:
I'm thinking of adding system load stats to the status servlet. What
do other's think about it? It would use JNI to call a native lib and
it would only work on unix, but it would be good
Mladen Turk wrote:
jean-frederic clere wrote:
Mladen Turk wrote:
Costin Manolache wrote:
Are you joking :-) ?
If we can not alloc couple of bytes from the system, then the
entire system is unstable.
Or that the process that makes the malloc() has reached a configurable
limit of the amount
Mladen Turk wrote:
David Rees wrote:
Are you sure it's a good idea to wait until it crashes rather than
fail in a controlled method? How much overhead is there to check
aw-name for NULL? Can't be much...
Yes I am.
Look, if the system can not alloc 1000 bytes of memory what's
the purpose to
Remy Maucherat wrote:
Jan Luehe wrote:
Bill Barker wrote:
In the case I was referring to, some project was storing a
servlet request (facade) in a ThreadLocal and, due to a bug in their
code, was hanging on to it beyond the request's lifetime. This was
happening only under rare circumstances.
Garrison, Meg wrote:
Hi Leslie,
I'm also willing to maintain the HP OpenVMS scripts. Rather than create
a whole new project (tomcat-contrib) maybe it would be possible for the
Tomcat folks to grant us commit access to a single module/folder in
their CVS library (a contrib folder of some sort).
Shapira, Yoav wrote:
Hi,
Another option for now is to setup a SourceForge project for this. I'd
be glad to link to it from our docs/FAQs/wiki pages. You (two) could be
its committers, and we could work together to get additional
contributors setup there.
There has to be a critical mass...
It
Remy Maucherat wrote:
- Allowing pluggability for commons-modeler
Can you elaborate a bit more on this ? The basic functionality of
modeler is to take an object and a descriptor and return an mbean.
This can be made pluggable - a simple interface with a single method is
probably enough to hide
Henri Gomez wrote:
True, in ASF land as in other community, it's the users and
developpers base which make a solution/product successfull or
forgotten.
BTW, jk 1.2.x is allready very stable and should stay like this for now :
- JK 1.2.x is now on bug-fix only mode.
- AJP_PROXY/MOD_PROXY for Apache
Henri Gomez wrote:
Well JK using APR will be a good solution for every webservers but Apache 1.3.x.
Apache 2.x came with APR, IIS, Domino and others should have no
problems to use an external APR library (.so, .dll).
So the remaining question will be shoud we drop Apache 1.3.x support
in future
Remy Maucherat wrote:
- Backport JNI from JK2 with lots improvements.
I still don't see benefits in JNI as a transport for JK. Only trouble
(no matter how I look at it, it seems like it would actually make the
whole system much less robust) and complexity.
Did I miss something ?
I have to agree
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 don't have 1.5 yet,
Remy Maucherat wrote:
Remy Maucherat wrote:
- Decent default java.util.logging configuration
I don't see any sensible configuration given what the standard handlers
are (limited rotation options, little possibility of avoiding hardcoding
logfiles paths, etc). Also, the reload operation is not
Mladen Turk wrote:
Costin, can you elabborate the purpose of the patch?
Perhaps I've missed few discussions.
There are few goals:
- allow tomcat components ( connector, valves, etc ) to be
added/removed/upgraded dynamically, at runtime - without requiring a
full restart.
- cleanup the startup
Mladen Turk wrote:
Costin Manolache wrote:
Mladen Turk wrote:
Costin, can you elabborate the purpose of the patch?
Perhaps I've missed few discussions.
There are few goals:
- allow tomcat components ( connector, valves, etc ) to be
added/removed/upgraded dynamically, at runtime - without
Mladen Turk wrote:
Costin Manolache wrote:
Mladen Turk wrote:
What about commons-deamon?
What about it :-) ?
Daemon is a different level - it's about launching a resident process
(or service in windows ). No connection with how the process is loading
its classes.
Sure, but the wheel
Remy Maucherat wrote:
I didn't have time to look at the code yet, though.
Wait a week or 2 - the loader part is fine, but the catalina side is
still a bit messy and I need to find a good way to integrate with the
build ( to make it completely optional/isolated - I don't want to affect
the 5.5
Remy Maucherat wrote:
Dominik Drzewiecki wrote:
Why don't we dump the JkMX and just settle for the facilities provided
by Java 5 configurable via standard system properties:
-Dcom.sun.management.jmxremote alone for local JVM monioring
or
-Dcom.sun.management.jmxremote
Hi,
Not sure what's the new policy for loading the Jmx RMI connector.
jk2.properties was a hack - and now that it is removed, I was wandering
if we have any official mechanism.
I had a small class that hooked in the connector, and I now refactored
it to a webapp - nothing fancy ( it's not even
I checked in the first part - I'm still working on making build.xml
changes and the catalina-side code.
It is certainly experimental code for now - I think it works better than
Bootstrap/etc, but the reloading of connectors/etc is still very tricky
( it kind of works, but I still don't have a
Bill Barker wrote:
- Original Message - From: Costin Manolache
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 05, 2004 10:06 PM
Subject: JMX Remote connection
Hi,
Not sure what's the new policy for loading the Jmx RMI connector.
jk2.properties was a hack - and now
Remy Maucherat wrote:
Hi,
- I'll add a thread pool similar to the one in Tomcat 4.0, as an
optional policy to the current one; the idea is that it's very dumb, and
could be more stable in some environments (that RH 9 thing ...), but is
not as efficient as the current one; I'll do some
Bill Barker wrote:
- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 9:01 AM
Subject: Re: More needed connector refactoring
Remy Maucherat wrote:
Hi,
- I'll add a thread pool similar to the one in Tomcat 4.0
I had a small vacation, and managed to make some of the changes in the
classloader/module area. I'm not completely done - but I want to
eventually start checking in some of the code ( if nobody objects ).
To avoid breaking anything, I started a new package (
o.a.tomcat.util.loader ), and
Mladen Turk wrote:
Shapira, Yoav wrote:
http://www.theserverside.com/talks/VendorPerspectives/Mainsoft/interview
.tss
Yes, indeed :)
Almost a year ago I proposed a project that would enable Tomcat to
seemesly integrate the legacy code. Something like moving the
perspective from being an backend to
Remy Maucherat wrote:
The vote result is:
- the release plan seems to be mostly ok
- it is acceptable to use the J2SE 1.4 API for this release (only Costin
seems to disagree with that); I expect this will allow using things like
the NIO API without any difficulties or the need for compatibility
Remy Maucherat wrote:
ballot
I approve the release plan:
[X] Yes
[ ] No
/ballot
ballot
Tomcat 5.5 should use the following API set for the coding:
[X] J2SE 1.3
[ ] J2SE 1.4
[ ] J2SE 5.0
/ballot
Actually - use target=1.3 - but the distribution should be 1.4 based
(i.e. no Xerces ).
I'm also ok
Remy Maucherat wrote:
Please make sure target=1.3 is present in all javac tasks :-)
Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to
replace jakarta-regexp use with Java regexp. Obviously people who don't
want to upgrade (ex: I saw a really funny thread on tomcat-user
Shapira, Yoav wrote:
Hi,
Please make sure target=1.3 is present in all javac tasks :-)
Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to
I'm also not big on JDK 1.3 as the default target. I'm +0 on adding a
javaTarget build.properties attribute that users can set to 1.3 but
Shapira, Yoav wrote:
It depends how you define support, right? Does support mean by
default everything is configured for JDK 1.3, and Tomcat is built with
target=1.3 ? Or does it means there's an easy way to set this target
parameter (e.g. a build.properties setting) and build your own Tomcat
Remy Maucherat wrote:
I'm planning to do the following changes to packaging:
- removing commons-launcher from the final distribution (I see little
use of it, since we have good scripts and native wrappers available); it
will stay as a dependency to launch stuff during the build process
- new
What does that leave us with in terms of distros? Let me try:
[Source distros, same as today]
- jakarta-tomcat-5.5.0-src.zip
- jakarta-tomcat-5.5.0-src.tar.gz
[Binary distros]
- jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin
- jakarta-tomcat-5.5.0.tar.gz - for JRE 5.0, no Admin
-
Remy Maucherat wrote:
No, you misunderstood.
- jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin
- jakarta-tomcat-5.5.0.tar.gz - for JRE 5.0, no Admin
- jakarta-tomcat-5.5.0.exe - for Windows, everything
- jakarta-tomcat-5.5.0-compat.zip - for JRE 1.4 (a few additional JARs,
not the whole thing)
I think we long ago agreed not to vote -1 just because you want somebody
to work on a different codebase :-)
If Keith has an itch in 4.1 branch - and if he can find 2 more +1 votes,
than it's his right to have a release, and the 4.1 branch will become
maintained. A branch is maintained if
Bill Barker wrote:
Are endorsed jars getting loaded somewhere else other than Bootstrap?
Using the default startup scripts, they are loaded into the System CL
(the
only way a delegating CL can find them :).
You mean -Djava.endorsed.dirs in catalina scripts, correct?
Yup.
BTW, why do they need
Jeanfrancois Arcand wrote:
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat
5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the
Petr Jiricka wrote:
Costin Manolache wrote:
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat
5.1? Since we're gearing up for JDK 1.5, we might want
To clarify: I wasn't proposing to remove the separate product
installation and runtime, but the contrary - to make that the default.
Right now tomcat operates in 2 modes - one where CATALINA_HOME is
identical with CATALINA_BASE, and one where you have them separate (
like you use ).
I think it
Are you talking about the compiler in eclipse ?
Does it allow a way to set up to use jikes ?
Costin
Remy Maucherat wrote:
Hi,
I've changed my mind a lot on this particular subject, but I'm still
investigating.
I'm looking at JDT right now, for use in Jasper, to replace Ant + javac
task as the
What I did is add
target=1.3 source=1.3
on each javac target in build.xml files failing under 1.5.
Also in Eclipse java/compiler/compliance - 1.3, and same in idea.
This lets me compile with 1.5 or eclipse ( I have it set to generate
classes in the same dir ant would compile - so ant is only
Remy Maucherat wrote:
Remy Maucherat wrote:
Hi,
I've changed my mind a lot on this particular subject, but I'm still
investigating.
I'm looking at JDT right now, for use in Jasper, to replace Ant +
javac task as the default Java compiler. It might be mature enough,
and would run with a JRE. It
The trick is to get all dependencies. Do an ant download, then create
project for repository, tomcat-connectors, tomcat-catalina, jasper,
servletapi ( with the obvious dependencis ). Eclipse will find all
source trees and jars, then compile without problems. Same works
in Idea.
Costin
Hiller,
William A. Rowe, Jr. wrote:
At 02:15 PM 8/7/2004, Costin wrote:
Now let's see how to get this in Apache2.0...
Gonna try to make that happen, if I can somehow merge history (ick)
It would be great if we would have at least one or 2 people who are committers in both projects. Since we can't
1 - 100 of 737 matches
Mail list logo
