If the trafic becomes too big, we should definitely separate them, but
what is big remain open ( tomcat-users is huge, I just can't read it
without headaches - that's where a split will be most needed )
Exact, we'll have to split at some time just to be able to
see if the question is related to
+1 ( part of it has already been moved ).
But if we do that, I would propose to _move_ it, not copy.
Does it means that TC 3.3.1 will require and use part of J-T-C
instead of keeping its own copy ?
If we move more and more logic and code in j-t-c, we may need
to have soon a specific
If we move more and more logic and code in j-t-c, we may need
to have soon a specific jakarta-tomcat-connectors dev-list ?
There is today low java in jtc, mainly native code.
If all the 'ORB' java code is moved to j-t-c, for jk,
next maybe warp, and coyote also, we'll need to split
the
Catch me if I'm wrong, but currently j-t-c is dependent on tomcat
code, right? I make this statement without having actually looked at
the code for the connectors. I'm going by recent discussions about
how an API change in Catalina broke the build for a connector.
some very small
On Fri, 14 Dec 2001, Paul Speed wrote:
Catch me if I'm wrong, but currently j-t-c is dependent on tomcat
code, right? I make this statement without having actually looked at
the code for the connectors. I'm going by recent discussions about
how an API change in Catalina broke the build for
Kevin Seguin wrote:
Catch me if I'm wrong, but currently j-t-c is dependent on tomcat
code, right? I make this statement without having actually looked at
the code for the connectors. I'm going by recent discussions about
how an API change in Catalina broke the build for a
+1 ( part of it has already been moved ).
But if we do that, I would propose to _move_ it, not copy.
Costin
On Thu, 13 Dec 2001, Kevin Seguin wrote:
it seems like a bunch of the stuff in the org.apache.tomcat.util.net package
in tomcat 3.x would be useful outside the scope of tomcat 3.
+1 ( part of it has already been moved ).
by part, you mean o.a.t.util.buf|collections|http|res, right?
But if we do that, I would propose to _move_ it, not copy.
ideally, you'd move the rcs archives to maintain history. however, doing
that would presumably break all tomcat 3.x
On Thu, 13 Dec 2001, Kevin Seguin wrote:
ideally, you'd move the rcs archives to maintain history. however, doing
that would presumably break all tomcat 3.x builds. i guess the next best
alternative would be to move the rcs archives.
For now just import the current snapshot. Short term, we
: org.apache.tomcat.util.net package in tomcat 3.x
+1 ( part of it has already been moved ).
But if we do that, I would propose to _move_ it, not copy.
Costin
On Thu, 13 Dec 2001, Kevin Seguin wrote:
it seems like a bunch of the stuff in the org.apache.tomcat.util.net
package
in tomcat 3.x
I would prefer to keep Tomcat 3.3.x able to build independently
of JTC for now.
Larry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 13, 2001 12:12 PM
To: Tomcat Developers List
Subject: RE: org.apache.tomcat.util.net package
+1
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Enviado el: jueves 13 de diciembre de 2001 20:00
Para: 'Tomcat Developers List'
Asunto: RE: org.apache.tomcat.util.net package in tomcat 3.x
I would prefer to keep Tomcat 3.3.x able
12 matches
Mail list logo
