refactorings
54ad24a256 is described below
commit 54ad24a256fe377fd3cbca762e3d614e88586677
Author: remm
AuthorDate: Thu Jul 7 10:32:58 2022 +0200
Add changelog entry for the Panama refactorings
---
webapps/docs/changelog.xml | 5 +
1 file changed, 5 insertions(+)
diff --git a/webapps/docs
refactorings.
83f94f5896 is described below
commit 83f94f5896164c269ca47a68c2bb252fde92514c
Author: Mark Thomas
AuthorDate: Fri Jun 17 11:34:03 2022 +0100
Remove TODO. Addressed by previous refactorings.
---
TOMCAT-NEXT.txt | 5 -
1 file changed, 5 deletions(-)
diff --git a/TOMCAT-NEXT.txt b
Yoav Shapira wrote:
Hola,
"conf" folders, etc). I don't see any reason to change the internal
Catalina code, as the classloaders are easily configurable using
catalina.properties.
Yes, which is why I was sort of wondering why we were having this part
of the refactoring talk ;)
I think the d
Hola,
> "conf" folders, etc). I don't see any reason to change the internal
> Catalina code, as the classloaders are easily configurable using
> catalina.properties.
Yes, which is why I was sort of wondering why we were having this part
of the refactoring talk ;)
Yoav
--
n APR dependency, as long as it has some
benefits). I added back support for the Java HTTP connector (minus
HTTPS) for development purposes.
As I said, I have no intention of doing any refactoring to this, or use
any of the refactorings that may occur in the Tomcat 6 branch. My post
was to s
Costin Manolache wrote:
- the specification still recommends hiding the implementation classes
(hence the hierarchy - is that the one proven to not matter ?)
Not matter + alternative implementations.
Hiding the implementation could be done at classloader / config level if
really needed.
Possi
Hola,
> a better abstraction in place, so people who don't need APR but like to use
> NIO can
> do this in their trees.
Yeah. And in general remaining a pure Java scenario for those who
don't want the APR dependency.
> - the "classes" folders allow patching (which of course may not be that
> >
On 3/27/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
>
> Costin Manolache wrote:
> >> I didn't try to extract a superclass on my branch (most likely, I
> >> won't), but I figured making the two implementations as close as
> >> possible in terms of functionality would be the best first step. So the
Costin Manolache wrote:
I didn't try to extract a superclass on my branch (most likely, I
won't), but I figured making the two implementations as close as
possible in terms of functionality would be the best first step. So the
attributes of the connectors are about the same, and the endpoints are
On 3/27/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
>
> Costin Manolache wrote:
> >> - I did my own connector refactorings very recently, and the result can
> >> be seen here (I removed SSL support in that code, but it could be left
> >> in easily) for
Costin Manolache wrote:
- I did my own connector refactorings very recently, and the result can
be seen here (I removed SSL support in that code, but it could be left
in easily) for the java.io endpoint:
http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/apache/tomcat/util
On 3/27/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> So the new repository is here:
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
>
> - I did my own connector refactorings very recently, and the result can
> be seen here (I removed SSL support
Nice stuff, +1.
Yoav
On 3/27/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> So the new repository is here:
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
>
> - I did my own connector refactorings very recently, and the result can
> be seen here (I
Hi,
So the new repository is here:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
- I did my own connector refactorings very recently, and the result can
be seen here (I removed SSL support in that code, but it could be left
in easily) for the java.io endpoint:
http
14 matches
Mail list logo
