On Mon, 18 Mar 2002, Bill Barker wrote:
I can see that this is going to make life difficult for ApacheConfig. Yes,
hopefully we can deprecate it soon. But in the mean time, I'd personally
prefer that the port is a property of the worker.ajp13. So your example
would be:
On Wed, 20 Mar 2002, Larry Isaacs wrote:
I believe it is an appropriate time to release the HEAD of jakarta-tomcat
as Tomcat 3.3.1. Also, as part of this release, I play to sync up
the jakarta-tomcat-connectors/utils to ensure that there are no
regressions in its tomcat-utils.jar with
On Wed, 20 Mar 2002, GOMEZ Henri wrote:
could we use for example
worker.ajp13.channel=socket,8009
worker.ajp13.channel=unix,path
The problem is that the communication channel and the protocol are
distinct entities.
You can add a new channel with it's own properties ( like JNI,
or
This also solves another problem - Apache2.0+JNI worker. It's exactly the
same, it acts similary with a load balancer ( multiple processes listening
on the same port ), and we want the jni worker to take the load if no
session.
Wouldn't be simpler if you just patch worker_lb ? Say if a
On Thu, 21 Mar 2002, Remy Maucherat wrote:
below). The Coyote connector will *not* be enabled by default, but will
appear commented out in the default server.xml configuration file.
+1 on enabling it by default, commenting out the old connector.
I also plan to make a Coyote 1.0 beta 4 at
On Fri, 22 Mar 2002, Remy Maucherat wrote:
below). The Coyote connector will *not* be enabled by default, but will
appear commented out in the default server.xml configuration file.
+1 on enabling it by default, commenting out the old connector.
I didn't propose to do that, because,
Hi,
I just checked in 2 docs for jk2, one describing the general model and one
start of the config manual.
It's obviously subject to change.
I think I found a solution to address Henri's comments about
worker/channel configuration - that is to reverse things.
Worker is an extremely
On Fri, 22 Mar 2002, GOMEZ Henri wrote:
channel.socket.local.port=8009
channel.socket.local.lbfactor=1
channel.socket.local.secretkey=...
good, a channel indicate transport,
a worker should be a layer upper, it use a channel
for transport and channel could be virtual (ie lb)
did
On Sat, 23 Mar 2002, GOMEZ Henri wrote:
I documented 2 properties, to be used to override the default
when new protocols/apis are added:
channel.socket.local.protocol=ajp13 ( it could be WARP, or IIOP or RPC )
ok, that's what I looked for
channel.socket.local.api=ajp13 ( api means
On Tue, 26 Mar 2002, Ignacio J. Ortega wrote:
De: Kin-Man Chung [mailto:[EMAIL PROTECTED]]
Enviado el: martes 26 de marzo de 2002 0:37
Nice to hear that, one comment, there is a jakarta-tomcat-jasper
repository with code Costin and Mel did some time ago as an initial
effort to refactor
On Mon, 25 Mar 2002, Kin-Man Chung wrote:
I have noticed that the current Jasper does a lot of string manipulations
very slowly, e.g. there are unnecessary copying or concatenations, and
the uses of String where StringBuffer should be used. Hopefully I can
avoid all of these.
But I don't
On Mon, 25 Mar 2002, Kin-Man Chung wrote:
I wasn't really serious when I suggested that Jasper generates byte codes.
Xalan is doing that already ( actually XSLTC ), and it's not very
difficult since we generate quite simple code, unlikely to be optimized
by javac too much.
It'll work only
+1
The plan ( after I finish native2 ) is to try using the 4.0/3.3
connector code from Coyote for jk2 ( the java side ), so this
will not be duplicated.
Costin
On Tue, 26 Mar 2002, GOMEZ Henri wrote:
Now that there is a build dir for jtc I'd like to populate
it with a bunch of rpm and
On Tue, 26 Mar 2002, Louis Tribble wrote:
Henri Gomez wrote:
May be because of license of javacc ;-)
That hasn't stopped Velocity from using it. But in any case, there
was an announcement on the JavaCC list a couple of days ago
that JavaCC will be open sourced over the next few months.
On Wed, 27 Mar 2002, Kin-Man Chung wrote:
I checked out jakarta-tomcat-jasper briefly looked at the files there.
I agree with you (and constin) that it can be used as a repository for
jasper2.
However, files and directory structures are too different from the one
used in tomcat 4, and I
On Wed, 27 Mar 2002, Kin-Man Chung wrote:
Pulling codes out of iteration tag bodies is very high on my list of
optimizations that I wnat to do. I don't think we can do much about
general scriplets that contain loops, though.
But before we start on jasper optimization work, we'll need
On Thu, 28 Mar 2002 [EMAIL PROTECTED] wrote:
Maybe I've not kept up on the docs enough but ...
I do think this thread, highlights a general confusion around tomcat.
Over the last couple of years, there have been many
mod_jk/jk2/webapp/warp/?? implementations, ajp versions etc, and even
On Fri, 29 Mar 2002, Sam Ewing wrote:
Hi Costin,
- mod_jserv implements ajp12
- mod_jk implements ajp12, ajp13, jni
- mod_jk2 implements ajp13 ( and one of my goals for
I looked at
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/config/ajp.html
This says that This implementation
On Fri, 29 Mar 2002, Sam Ewing wrote:
Thank Constin,that really helped. Are there any
advantages of WARP over APJ? I mean why would I want
to use one over the other?
I have no idea :-) If you care how strings and ints are encoded,
or what's the packet structure probably you would pick
one.
I would be -1 on this - the JDK documentation clearly defines the
intended behavior of the ext directory, and this would create confusion
and unpredictible behavior. I expect a file in ext/ to be included
_before_ tomcat classes - the way java documents it.
( I don't use ext/, but
On Mon, 1 Apr 2002, Patrick Luby wrote:
Costin,
The problem with the default JVM behavior can cause your application to
crash or behave in unexpected ways if there are incompatible jars
installed in the jre/lib/ext directory.
Then report the bug to the JVM people :-)
The method that
On Mon, 1 Apr 2002, Patrick Luby wrote:
BTW, I can eliminate the use of a separate classloader and put the
jre/lib/ext directory in the existing catalinaLoader and sharedLoader
instances. However, to do this, I need to change the getClassPath()
method in JspEngineContext.java so that it
On Mon, 1 Apr 2002, Patrick Luby wrote:
Remy and Costin,
I will reverse the patch since there are enough -1s on this. One
question: should we continue to set the -Djava.ext.dirs= in the
wrapper scripts? This disables the extensions but without any code
change to Tomcat. Or do we want to
Patrick,
Are you sure we need all this ? The .sh/.bat is already too complex.
A simple check ( in java ) for the things that we care about should be
more than enough, adding another config option and env variable is too
much.
The intent of the ext/ is to simplify the user's life - so they
I will apply the patch to 1.3.
Are we still maintaining the second copy of jk in 3.3 tree ?
Larry - can we start removing the duplicated util and c code ?
IMHO the j-t-c code ( the 'native1' side ) is as stable as the
one in 3.3, and it would simplify our life to deal with a single
one.
I'll start updating the IIS stuff - there are 2 dirs in jk1 - iis and
isapi. Which one is used ?
From what I can read 'isapi' is newer and seems more generic, is this
right ? Do we need both for jk2 ?
( BTW, lots of duplicated code will go away or be moved to the core,
and the registry
On Tue, 2 Apr 2002, GOMEZ Henri wrote:
Thank Constin,that really helped. Are there any
advantages of WARP over APJ? I mean why would I want
to use one over the other?
The protocol difference is not significant - both are encoding
strings and ints in an efficient ( but non-standard ) way,
On Tue, 2 Apr 2002, Larry Isaacs wrote:
I have some updates almost ready that use the util source
out of j-t-c rather than its local copy. I was also going
to have it build and include http11 and coyote as well.
I haven't had the time to play much with these. I would,
at minimum, add a
On 3 Apr 2002, Bojan Smojver wrote:
I've committed a patch to mod_jk.c (apache 1.3) that changes aplog_error
into ap_log_error (which I found to be the proper call in Apache 1.3),
but since I'm not all that familiar with Apache, I'm not 100% sure I did
the right thing. Could some of the
On Wed, 3 Apr 2002, Kin-Man Chung wrote:
It's great that you are doing performance evaluation for different versions
of tomcat. Can your jstl run in tc3 and tc4 without change? Can we
separated performance attributed to containers as opposed to those attributed
to jasper? For those jasper
Hi,
In order to merge the connector-related code in Coyote and jk, I need
a different abstraction. Processor takes InputStream/OutputStream params,
and assumes the connector will listen on the port, etc.
The problem is that it doesn't map to things like JNI and is hard to
abstract things like
On Thu, 4 Apr 2002, Bill Barker wrote:
It's fine with me. I also have a slight preference for the 33 ThreadPool,
but it's not a big deal either way.
If we're going to move the socket handling into o.a.c.http11, what about
importing o.a.t.util.net? It should mean that Tomcat 4.x should be
On Fri, 5 Apr 2002, Remy Maucherat wrote:
There is no problem if we use 2 Http11Protocol, one with ThreadPool the
other with 4.0 threads. Right now I'm working on the TP one.
We don't need two, so I'll try yours ;-)
Do you plan to write the Http11ProtocolHandler ?
Already done, but I
2 questions ( for Remy ):
- is anyone using the getSocket() method in CoyoteRequest ? It's obvious
this can't work for other protocols, and extracting SSL info is
specific to the SSL impl and should be done at the protocol layer.
- Any reason for not extending HttpBaseRequest ?
Costin
--
On Fri, 5 Apr 2002, Remy Maucherat wrote:
Some valves in the Catalina pipeline use that.
It probably should be done at the protocol layer, but I can't do that for
compatibility reasons, so I think the socket should be set as a note in the
Request object (as is suggested in the commented
On 5 Apr 2002, Eric Rescorla wrote:
Remy Maucherat [EMAIL PROTECTED] writes:
On Fri, 5 Apr 2002, Remy Maucherat wrote:
I have big doubts the code that calls getSocket() can even work with ajp
or pureTLS or other things. Probably a good idea to find where it is and
call the right
On Mon, 8 Apr 2002, jean-frederic clere wrote:
It would be nice to have /usr/local/apache/conf/jk2.properties when httpd is
configured to be in /usr/local/apache (instead of /conf/jk2.properties in the
son processes...).
My first idea is to add makeRoot() in jk_ws_service_t. But I have
On Mon, 8 Apr 2002 [EMAIL PROTECTED] wrote:
My first idea is to add makeRoot() in jk_ws_service_t. But I have the problem
that apache needs a pool (not a jk_pool) to call ap_server_root_relative().
Where could I get the pool?
Actually, that would be a good idea too ( adding another
On Mon, 8 Apr 2002, Larry Isaacs wrote:
Hi Costin,
I'm curious as to the reason to have connectors_util.jar instead
of just using the tomcat-utils.jar built by j-t-c/util?
We have 2 'sets' of utils - one in j-t-c/util, one in j-t.
We also have 2 lib dirs - lib/common and lib/container.
On Mon, 8 Apr 2002, Remy Maucherat wrote:
I'd like those two to stay the way they are. They're not related to the
hooks or actions. I/O should be handled as a special case IMO; faster +
simpler. (could you remove the comments ?)
Ok, but at least add a second parameter ( Request, Response,
On Mon, 8 Apr 2002, Larry Isaacs wrote:
It's not so much having one util jar, but understanding the differences
between jakarta-tomcat-connectors' tomcat-util.jar and connectors_util.jar.
If they are the same, then I would prefer to use a single name.
They are certainly not the same ( or
Ok, ok. I'll work around it.
Costin
On Tue, 9 Apr 2002, Remy Maucherat wrote:
On Mon, 8 Apr 2002, Remy Maucherat wrote:
I'd like those two to stay the way they are. They're not related to the
hooks or actions. I/O should be handled as a special case IMO; faster +
simpler.
Hi,
As you noticed, we will use coyote for connector and avoid
the duplication. There are few more things that need to be
fixed, but it seems everything will actually work better.
I still like the idea of packing the connector as a
webapp and doing all config in web.xml - but having
more
On Tue, 9 Apr 2002, Larry Isaacs wrote:
The instructions for installing Coyote on Tomcat 3.3.x say to
replace connectors_util.jar with j-t-c's tomcat-utils.jar. Since
j-t-c tomcat-utils are a subset of tomcat-utils.jar from container/
Sorry, I didn't read the instructions for Coyote - I'm
On Tue, 9 Apr 2002, Remy Maucherat wrote:
public class CoyoteResponse
@@ -485,6 +485,7 @@
throws IOException {
// Writing leftover bytes
outputBuffer.close();
+coyoteResponse.finish();
}
This is called no matter what right
I'll commit a fix.
Larry, is it ok if we call the buildfile for j-t-c from 3.3's build.xml ?
( 4.0 is doing that too ).
The problem is the order which may be tricky - tomcat33 depends on j-t-c
utils and it will copy coyote. But coyote depens on tomcat33 beeing build,
so it can find the
On Tue, 9 Apr 2002, Remy Maucherat wrote:
BTW, this is a very cool idea - it avoids one copy and allocations,
and simplifies the code. But it deserves a comment :-).
Yes, indeed. I worked hard so that there wouldn't be any useless copy.
Yes, excelent !.
One question for future
On Tue, 9 Apr 2002, Remy Maucherat wrote:
( this used to be in the 3.3-specific code, and is needed to construct
redirects, etc )
+//The info from socket is usually acurate
+// req.setServerPort(80);
That's not good. If no host is specified with
On Tue, 9 Apr 2002, Remy Maucherat wrote:
Can you add a small comment in Response and clearly indicate who should
call it - I'm fine with any, but we should do it consistenlty in the 2
adapters and in the 2 protocols.
The class which is implementing the Adapter interface is calling it
On Tue, 9 Apr 2002, Bill Barker wrote:
+
+remoteAddrMB = coyoteRequest.remoteAddr();
+ remoteHostMB = coyoteRequest.remoteHost();
+ serverNameMB = coyoteRequest.serverName();
+
+
This forces the lookup to always be per-request, when it would be much nicer
to
On Tue, 9 Apr 2002, Remy Maucherat wrote:
port if it is not the standard one.
But if the Host header is correct, it'll allways be the same thing as
the getPort on socket - if it's https on standard port, the port will
be 443 as the default, etc.
Even if the port in the host header
On Tue, 9 Apr 2002, Remy Maucherat wrote:
Yes, that's what the fixed patch does.
So I did it right, I think :)
Thanks.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
On Tue, 9 Apr 2002, Bill Barker wrote:
Unless I'm missing something.
These fields are recycled per-request, so we lose the value of
remoteHost/remoteAddr and will have to look it up again. If the buffers are
identical, then the o.a.c.Request field is recycled as well. At least for
Bill,
Do you think we can move to CoyoteInterceptor2 and Protocol ?
It seems to be working for both http and ajp - it is still
less stable than your original one, but I think we're close.
Your call.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands,
On Tue, 9 Apr 2002, Bill Barker wrote:
I'm +1 for this. But for at least a little while, I'd rather just deprecate
CoyoteInterceptor and related classes.
It seems Remy already removed the old connector for 4.0. If we need it' we
can get it back from the CVS :-)
Costin
--
To unsubscribe,
This is mostly a reminder of the previous discussion, and an update
wrt. the java side, now based on coyote.
We agreed ( I hope :-) that mod_jk ( C ) needs a better config, and
we agreed that the new config must support both user-editable and
runtime changes ( like discovery, etc - where the
Need help and feedback...
As you know, the new Coyote supports both HTTP/1.1 and JK. And the new
JK supports some new communication channels and APR functions that need JNI.
The 'idealistic' goal was to do that transparently - using System.load(),
so that the user will not have to set
On Thu, 11 Apr 2002, Remy Maucherat wrote:
-- Degrade to the socket port on HTTP/1.0 requests with a
Host header
but no port number.
if you are under a nat, dafaulting to the socket port maybe no correct,
you could have tomcat in 8080, and the request would be redirected
+1.
However I have a small question - if we do use JMX by default ( and we
should), then we should take into account JMX persistence - i.e. saving
the file automatically when the user uses JMX to alter config.
We'll have to deal with the same thing in mod_jk - so a consistent
policy would
On Thu, 11 Apr 2002, jean-frederic clere wrote:
The 'idealistic' goal was to do that transparently - using System.load(),
so that the user will not have to set LD_LIBRARY_PATH. We would set
aprHome in jk2.properties - and that's it.
Something like ld.config or crle also helps.
It's
On Thu, 11 Apr 2002, Bill Barker wrote:
We do use the port number from the header, if the port is present. The
current code handles HTTP/1.0 clients much the same way as Http10Interceptor
does. Since the main HTTP/1.0 client that uses Tomcat is Watchdog, I don't
really like enforcing the
On Fri, 12 Apr 2002, Ignacio J. Ortega wrote:
Hola a todos:
I'm in the process to have a build of mod_jk2 for Win32, modiying needed
build.xml files aling the way, i imagine that unix domain sockets stuff
need , needs to be ifdefed for win32, i'm right?
Are there more things that need
On Fri, 12 Apr 2002, Larry Isaacs wrote:
I think the new dependencies in Tomcat 3.3.x are making it
difficult to get things set up successfully in Gump. The
most recent change to the jakarta-tomcat.xml definition
file in Gump has the comment:
remove dependency on tomcat-util as it causes
On Fri, 12 Apr 2002, Pier Fumagalli wrote:
Then it won't work... BTW, I hope you guys are not trying to load APR from
the VM, right? Because if so, I _really_ want to see how you can do it on
Mach-O kernel based Oses :)
mod_jk2 is using APR, and on the java side the JNI and Unix socket
On Fri, 12 Apr 2002, Ignacio J. Ortega wrote:
I've defined HAVE_UNIXSOCKETS, and i'm making the ifdefs with that it
seems to me a little better, i think that not having unix sockets ( at
least with that name :) maybe is more common than only win32?..
That's fine. The goal is to be able to
On Fri, 12 Apr 2002, Remy Maucherat wrote:
In HTTP/1.0, looking at the Host header is non standard. We can look at it
if it is there (and I believe we do; if we don't it is very simple to change
that), but in the end the HTTP/1.0 protocol is inefficient broken in many
The Host header is not
On Fri, 12 Apr 2002, Pier Fumagalli wrote:
The _ONLY_ solution is to either force a GLOBAL loading of (let's say) APR
by a third library which is loaded LOCALLY and loads APR globally (a let's
say JNI-APR liaison) but at that point the linkage may fail, and you have
to handle all the cases
On Fri, 12 Apr 2002, Ignacio J. Ortega wrote:
This way there is no need to ifdef unix sockets, thanks :)), but it's
done now ;), so should i commit this change?
Of course.
FYI - I'm cleaning the jni worker now ( I want to have all components in
a working state before a beta release for
On Fri, 12 Apr 2002, Ignacio J. Ortega wrote:
Mostly compiling, i about to commit in half of an hour..
How to deal with content-length apr_off_t? here is defined as __int64,
and code is using int and unsigned, and i got a warning about precision
lost, maybe use apr_off_t where now is
Remy,
Is there any standard option/way to redirect stderr and stdout to files ?
( for Catalina ) ? ( in java - not in the .sh/.bat )
If not, what would be the best place to put them ?
I want to remove JniMain and start tomcat/catalina directly, without
intermediary - the only thing that's
On Sat, 13 Apr 2002, Sam Ruby wrote:
Ignacio J. Ortega wrote:
We need to fix gump, not tomcat..
So... where is your patch?
I had one (other) person ask me for commit access... again without a patch.
I ultimately made the fix suggested... and this morning you see the result.
It
On Sat, 13 Apr 2002, Remy Maucherat wrote:
I think it would be a good idea to release a new Coyote beta.
Can we also include the java side of jk ?
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
On Sat, 13 Apr 2002, Remy Maucherat wrote:
On Sat, 13 Apr 2002, Remy Maucherat wrote:
I think it would be a good idea to release a new Coyote beta.
Can we also include the java side of jk ?
Yes, I was planning to include Coyote JK 2 (I consider it to be part of
Coyote, just like
On Sat, 13 Apr 2002, Ignacio J. Ortega wrote:
Hola a todos:
I'm in the process of take control of our Gump descriptors, and i think
we should do it in our own CVS Tree, which tomcat subprojects want to
have his own gump descriptor committed?
i'm +1 for all our repositories j-t, j-t-c ,
On Sat, 13 Apr 2002, Remy Maucherat wrote:
- JK 2 protocol handler, with support for the AJP 1.4 protocol
Let's call it ajp13 for now, to avoid further confusion :-)
I think we also agreed to keep the protocol unchanged in the near
future ( even if additional APIs/functions could be
Nice fix.
Can you re-do the patch against j-t-c ? That's the code we are going to
use in the future releases of tomcat (both 3.3.x and 4.0 ). It should be
easy, the code is similar.
I'll port the fix to jk2 in j-t-c ( actually, already done - commit
follows )
Costin
On Mon, 15 Apr 2002,
We're working on that :-)
It seems tomcat-util.jar was not available in the gump run,
hopefully next gump will see it.
Costin
On 16 Apr 2002, Craig McClanahan wrote:
This email is autogenerated from the output from:
On Thu, 18 Apr 2002, Ignacio J. Ortega wrote:
( I know Nacho will be very disapointed, but I think it's the right
thing to do ... )
I am, I am, :)
it's sad but i will survive, but Why ?
Why I added .dsp and Makefiles ? Because most people are used with
'make' or MSVC, and we
Getting close, all channels and workers seem to be in a good shape.
2 more things before we can freeze it:
- Finish the shm object and get worker_lb to update automatically based
on the shared memory ( plus tomcat to register itslef and a tool to
add/remove/set workers ).
- Port the IIS
On Thu, 18 Apr 2002, Ignacio J. Ortega wrote:
IIS.., well the differences between jk and jk2 are so high, my first try
was lost in the way to adapt the existing ISAPI code, next i will try
to use mod_jk2 as base to start, adding IIS things along the way..
It's mostly a matter of removing
On Thu, 18 Apr 2002, Remy Maucherat wrote:
What is the problem with 4.1 ? The differences with 4.0 should be minimal.
If it's a mapping bug, one difference is that the protocol handler has to
fill out the decodedURI field of the request. Since it's part of the HTTP
and URI specs, I moved it
On Thu, 18 Apr 2002, GOMEZ Henri wrote:
In Coyote, there's:
- the container adapters (for 3.3, 4.0, 4.0-HEAD)
- the external API (request, response, and a couple other things)
JK 2 and HTTP/1.1 are protocol handlers for Coyote.
Thanks for that.
Coyote + HTTP/1.1 proto handler in
On Thu, 18 Apr 2002, Ignacio J. Ortega wrote:
What you can do is start with jk_service_iis.c ( based on
jk_service_apache13 ) - and move the few methods related with
request.
Mind Reading?? this is done already :) not committed but done, mainly
refactoring existing ISAPI code,
On Thu, 18 Apr 2002, GOMEZ Henri wrote:
Happy to see how jk and coyote fit well together ;)
Well, it certainly saved me a lot of time. Plus the joy of
breaking Gump.
It works amazingly well - I expected some pain in getting
the JNI worker for tomcat4.x ( especially 4.1 ) - it turned
out all
On Thu, 18 Apr 2002, Remy Maucherat wrote:
I don't know any differences in the thread handling between 4.0 and 4.1.
What is the problem ?
You're right, my mistake.
There are 2 problems.
The first was that when you call main(), the method will never return.
In 3.x main() starts some
On Thu, 18 Apr 2002, Remy Maucherat wrote:
If someone can confirm that the incompatibility between 4.0-HEAD and JK 2 is
now fixed, I'd like to put out a new Coyote beta release.
It also fixes some SSL configuration problems with Tomcat 4.x, and a few
cosmetic fixes.
I got jk2/java working
jkjava:
[echo] Logging:
/home/rubys/jakarta/jakarta-commons/logging/dist/commons-logging.jar
[javac] Compiling 39 source files to
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/classes
[javac]
I am also interested in MinTC.
But I must say I understand Remy's point about 'rudeness'. I don't
like bloat and I would love to see more modularization ( in
4.x and 3.x and most of the programs I know ). But this should
be done by contributing to the project, not by creating
a fork.
And if
I have to admit not having read the MinTC source, however, I thought
the tomcat community uses/develops multiple implementations of many
interfaces. Most of the http/socket/auth?/config (xml
file/ajp-webapp/admin) code is effectively multiple implementations of
the same interfaces. Isn't
On Fri, 19 Apr 2002, Rolf Veen wrote:
Remy Maucherat wrote:
I will veto this (or vote against, if it's a majority vote). It has been
very clear for a while that the Tomcat project has to provide one and only
one servlet container for a particular version of the specifications.
That
On Fri, 19 Apr 2002, Ignacio J. Ortega wrote:
Hola a todos:
I'm trying to get to compile the JNI part of JK2 in win32, again with my
legendary naiveness ;), how is suppoussed we deal with signals in
win32?? just add another ifdef here with a HAVE_UNIX_SIGNALS ?
It shouldn't have any
On Fri, 19 Apr 2002, Ignacio J. Ortega wrote:
Update, after merging few dozens cvs conflicts :-)
:-) , sorry bout that, I'll try to follow up your changes this evening (
here ), please wait for commits..
Today is shared memory-day, I'll not touch the IIS.
Costin
--
To unsubscribe,
Christopher,
I think a more modular 4.0 would be a step forward - and it
seems many others agree. But what you are doing is a fork by
all definitions that I know.
As I said, I do agree with Remy - if you care about tomcat
you should 'persist' in pushing for your ideas and find ways to
work
On Fri, 19 Apr 2002, Ignacio J. Ortega wrote:
Hola a Todos:
How can i use jk2 to read and parse an arbitrary properties file?
jk2_config_read()
It'll read the properties into the jk_map ( without doing the ${}
substitution ! - you must do it after you read ).
The only 'special' thing
Hi Glenn,
Could you update at least the apache2 connector ? This features makes
sense on all servers actually ( i.e. IIS, etc ) - but we should have it
at least in 1.3 and 2.0.
Also, any chance to update this on native2 ? I'll do it later if you don't
have the time.
Costin
On 21 Apr
On Mon, 22 Apr 2002, Glenn Nielsen wrote:
Hmmm, this gives me an incentive to play around with Apache 2.0.
It's a nice server :-)
What would help the most is a 'common' implementation - i.e. have as much
as possible independent of the server.
Also, any chance to update this on native2 ?
On Mon, 22 Apr 2002, GOMEZ Henri wrote:
To keep things simple and use existing code, I think we should use
the current marshalling/demarshalling code ( ajp13 ) to store/get
informations from each slot.
Why not just use native read/write on int/strings ?
If we treat shm as a byte[] and
+1 from me.
Having a cross-platform and consistent installer would be good for tomcat.
My only concern - I hope the 'one licence' would cover all versions of
tomcat and more than one release manager ( and maybe it can be assigned to
Mr. Gump and automated ).
Costin
On Tue, 23 Apr 2002, Remy
I believe Apache httpd server is using MSI and InstallShield -
and this is neither cross-ASF nor free.
I'm not sugesting an exclusive deal with InstallAnywhere -
we can try one of the OSS installers in parallel ( if
someone has the time to do so ) and if they provide the
same features, we'll
+1
Costin
On Wed, 24 Apr 2002, Remy Maucherat wrote:
I'd like to call for a vote on the Apache Tomcat 4.1 Release Plan.
The vote will run until 04/26, and will be followed, if the Release Plan is
accepted, by a vote for the release of Apache Tomcat 4.1 Beta 1.
ballot
[ ] +1 I approve
201 - 300 of 668 matches
Mail list logo
