Bill Barker wrote:
The way that the admin works at the moment, any change you make only affects
the currently running instance of Tomcat unless you hit the Commit Changes
button. With my patch, that doesn't change. If I create the context.xml
file when you do a Create Context action, then you
Bill Barker wrote:
The Adapter implementation is expecting that the requestURI is of type BYTE.
It doesn't deal well with type STRING.
I don't think the latest 5.0.x code has these limitations anymore.
Rémy
-
To unsubscribe,
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
The major problem is intercepting the changes. It can be done:
- inside the jmx impl ( interceptors, etc )
- using the property changed events
- by wrapping each mbean when it is registered.
One important question is if we need
Hi,
I'd like to nominate Peter Rossbach pr _at_ objektpark.de as a
committer on the Tomcat project. Peter submitted a significant amount of
useful patches for Tomcat, and wants to contribute more.
He has my +1.
Rémy
-
To
Shapira, Yoav wrote:
Hi,
I think a gradual transition might be OK. Server.xml, as Remy said, nicely conveys
the structure of the server's configuration. That's possible to replicate in a JMX-
or JBoss-style configuration file, but it tends to look uglier and more verbose IMHO.
However, your
Lars J. Nilsson wrote:
Hello all,
Referencing a Servlet input stream - by calling
ServletRequest.getInputStream(), which propagates down to
CoyoteRequest.getInputStream() - in Tomcat 4/5 stops POST'ed body
parameters from being parsed. See usingInputStream instance member
declared at
Hi,
I'd like to make this feature less hardcoded (right now, it's ugly ;) ).
A first step would be to extract the code to another helper class, but
that's all I can think of. Does anyone have any ideas ?
Rémy
-
To unsubscribe,
Shapira, Yoav wrote:
Hi,
I've done a bit of work in this space. One approach that I've seen work with very complex object graphs is:
- Have an interface, e.g. XMLRepresentationI, with one method,
String toXML();
- Have every object along the graph that needs to be saved implement this interface,
Costin Manolache wrote:
Remy Maucherat wrote:
Hi,
I'd like to make this feature less hardcoded (right now, it's ugly ;)
). A first step would be to extract the code to another helper class,
but that's all I can think of. Does anyone have any ideas ?
What I tried earlier ( but didn't finish
Shapira, Yoav wrote:
Hi,
Looks like Remy beat me to it ;)
Sorry, I forgot about those emails.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Costin Manolache wrote:
The major problem is intercepting the changes. It can be done:
- inside the jmx impl ( interceptors, etc )
- using the property changed events
- by wrapping each mbean when it is registered.
One important question is if we need to save server.xml, or
just say that
[EMAIL PROTECTED] wrote:
luehe 2004/07/27 17:43:44
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Fixed Bugtraq 6152759 (Default charset not included in Content-Type
response header if no char encoding was specified).
According
Henri Gomez wrote:
Service Client Fnac.com wrote:
Chère Cliente, Cher Client,
Merci de nous avoir contactés.
Vous venez d'envoyer un message à une adresse ne permettant pas
de recevoir d'e-mail.
Pour trouver les réponses à vos questions sur vos commandes, sur
les produits, sur le site, consultez
Remy Maucherat wrote:
Cool. So after all the efforts I'm doing to optimize, you casually add
GC, because the servlet API is completely stupid ?
So -1 for your patch: you need to rework it. I also didn't read all
that funny stuff in the specification, so where does it come from ? ;)
I thought
Remy Maucherat wrote:
Bill Barker wrote:
- Remove Deployer and DefaultContext. The new stuff looks like a better
replacement.
I did that but didn't commit yet. The management side for the default
context would need to be redone (it's not very difficult, I think).
The clustering will need updates
Shapira, Yoav wrote:
Hi,
You know, I've been meaning to address the Undeploy considered dangerous bugzilla item by adding a JavaScript confirmation dialog around the undeploy action in the HTML manager. Too bad I hadn't gotten around to it before your mishap ;(
I would have clicked yes: I
Henri Gomez wrote:
It seems we didn't got this CC in tc-dev :
Henri Gomez wrote:
I made some benchs on my Linux Fedora Core 2
on a P4 2.8ghz / 1Gb RAM :
Apache 2 alone 1202 req/s
TC/Coyote 883 req/s
One thing I noticed when looking at Tomcat 5.0.x is that its default,
Filip Hanik - Dev wrote:
The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The
Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where
Ok. Well, I think
Jan Luehe wrote:
Bill,
then I'd suggest simply
doing:
setCharacterEncoding(getCharacterEncoding());
in Response.getWriter (since the spec only requires that we identify the
charset when using a Writer, and we don't really know what it is when
using
OutputStream).
The problem with this is that
Bill Barker wrote:
This message is intended only for the use of the person(s) listed
above as the intended recipient(s), and may contain information that
is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
Jan Luehe wrote:
yes, sorry, I had forgotten about that case.
Believe, I didn't commit yesterday's patch simply because
I don't have anything better to do. It's come up as a compliance
issue which had been masked by an unrelated problem that was fixed.
I thought the issue caused enough trouble
Bill Barker wrote:
My guess would be File.getCanonicalPath() in FileDirContext.
There's a cache for that, so canonicalization will happen only once in a
while. I don't understand how it can possibly be a performance issue.
Rémy
Bill Barker wrote:
I'll volunteer for the admin webapp stuff. I enjoy deleting stuff from
there ;-).
It's at the end of my list right now, so I wont't get there for a while.
I committed a few things:
- The new deployer is getting there. Missing is the support for the
manager webapp, but this
Graham Leggett wrote:
Remy Maucherat wrote:
Until I'm shown a mod_proxy (with HTTP) with performance close to
mod_jk, my opinion is that we can't use it.
As I've pointed out already, mod_proxy is a framework. The performance
numbers quoted tested mod_proxy_http, not mod_proxy, which doesn't do
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK pool
at the moment?
I enabled JMX HTTP adaptor via mx.enabled=true. Obviously
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not
only once, but for every Coyote JK pool configured in
Graham Leggett wrote:
Remy Maucherat wrote:
The framework itself could be designed in a way which would end up
hurting performance. It did happen in Tomcat in the past, and I don't
know about mod_proxy since I haven't looked at it, but it could happen.
All the framework does is determine
Costin Manolache wrote:
Remy Maucherat wrote:
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK
pool at the moment?
I enabled JMX HTTP adaptor via mx.enabled=true. Obviously
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor
not only once
I committed a few things:
- The new deployer is getting there. Missing is the support for the
manager webapp, but this won't be too hard to write.
- I redid partially the naming. Now the NamingResource object is the
main object, and Context is not polluted.
My list is:
- Update manager webapp,
jean-frederic clere wrote:
We have noted that mod_proxy + mod_proxy_http are slow compared with
mod_jk.
I think that the next step should be to try to find why instead
writting a new modules. May be a quick hacked mod_proxy_ajp to replace
mod_proxy_http is the first step.
Note that I am a bit
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK
pool at the moment?
I enabled JMX HTTP adaptor via mx.enabled=true. Obviously
org.apache.jk.common.JkMX tries
[EMAIL PROTECTED] wrote:
billbarker2004/07/26 10:04:04
Modified:webapps/docs changelog.xml
Log:
Fix version #.
What ever the next version is that is released from here, it is not going to be called 5.0.x.
I did refer to that with the 5.5 revision number, because the API
isn't
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Both difference and similarity :-).
Eclipse ( osgi actually ) has a similar flat loader implementation,
but with finer control over what is exported/imported and pretty
strong versioning. In addition osgi supports permissions
Bill Barker wrote:
I'm with Graham on this. Personally, I have very little interest in a
mod_ajp module, but I am interested in proxy_ajp, proxy_lb, etc. Of course,
since j-t-c has long doubled as j-t-sandbox, this means that I'm +0 for
committing your stuff there.
I think Mladen's initiative
Bill Barker wrote:
It hurts my eyes to see the Socket in the o.a.c.connector.Request :). Now
that Remy has gotten rid of the o.a.catalina.Request, there isn't any reason
for it to be there. However, I thought I should give people a chance to
veto removing it before I put the work in (I'm lazy
Shapira, Yoav wrote:
* Default global and per-host configurations:
- conf/engine/host/context.xml.default
- conf/engine/host/web.xml.default
- conf/context.xml
- conf/web.xml
This will lead to the removal of the DefaultContext interface, since
this will fully replace the functionality (while being
Costin Manolache wrote:
Don't know what dependency injection is, but I hope the next spec
won't invent yet another way to do configuration.
Sorry for using hype words. I got contaminated, it can happen to
anyone. I'll try to shake it off now. I apologise to the community
for that, and I won't
Costin Manolache wrote:
Both difference and similarity :-).
Eclipse ( osgi actually ) has a similar flat loader implementation,
but with finer control over what is exported/imported and pretty
strong versioning. In addition osgi supports permissions on importing
packages.
The reloading of
Filip Hanik - Dev wrote:
ok, there are two very simple memory friendly ways to do sticky load balancing.
And as a matter of fact, this is how some hardware loadbalancers do it.
1. Set a cookie on the clients machine - no server memory to hold a map
2. If the client doesn't accept cookies, do a
I've had a few more feature ideas (actually, it's more tweaks and simple
things than big development for the most part), and I'm refining the way
I'll be implementing the new deployer.
* Parse element Context (if context config file) in HostConfig, for
className, path and docBase attributes.
Tim Funk wrote:
*Changes to tomcat*
Add a proxy mode flag to allow for the X- headers to pass
authentication and other variables.
Add to the manager(?) app and method to expose all the URL spaces
availble.
Minor changes to fix getRemoteAddr() to show the client, not the
apache server.
Pros -
Henri Gomez wrote:
I made some benchs yesterday on my laptop between :
- TC 3.3.2/Coyote
- Apache 2.0.49 alone (simple html file)
- Apache 2.0.49 + jk 1.2.6 + TC 3.3.2/jk2
- Apache 2.0.49 + jk 1.2.6 + 2 * TC 3.3.2/jk2
- Apache 2.0.49 + mod_proxy + TC 3.3.2 (Coyote 1.1).
I'll redo them today on a
Graham Leggett wrote:
Remy Maucherat wrote:
It's cool to have one less thing to configure, but it seems to me
jvmRoute is the most reliable and efficient way of doing stickiness
Can you describe the jvmRoute method to me?
It's really dumb: we append the node name to the session id when it's
Henri Gomez wrote:
I made some benchs on my Linux Fedora Core 2
on a P4 2.8ghz / 1Gb RAM :
Apache 2.0.50 in
- Apache 2.0.50 alone (simple html file)
- TC 3.3.2/Coyote 1.1
- Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2
JkMount /examples/* local
worker.local.port=8009
worker.local.host=localhost
Graham Leggett wrote:
jean-frederic clere wrote:
I also I have some (40) errors with concurrency 300 but Tomcat and
Apache are in 2 different machines:
+++
[Thu Jul 22 11:39:39 2004] [error] [client 172.25.182.35] proxy:
DNS lookup failure for: pgtr0327.mch.fsc.net returned by
Shapira, Yoav wrote:
Hola,
* Redo naming resources configuration using setAllProperties rule to
make the XML less verbose.
Example:
Resource name=bean/MyBeanFactory auth=Container
type=com.mycompany.MyBean
factory=org.apache.naming.factory.BeanFactory
bar=23/
I
Costin Manolache wrote:
Quick question - did you had any discussion on class loaders for 5.next?
It's one area I'm playing with, I want to make sure I'm not going in
oposite direction :-)
I'll tweak the StandardCL to do a bit the same as the WebappCL (ie, try
to make it faster). I'll also
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Quick question - did you had any discussion on class loaders for
5.next?
It's one area I'm playing with, I want to make sure I'm not going in
oposite direction :-)
I'll tweak the StandardCL to do a bit the same
Graham Leggett wrote:
Henri Gomez wrote:
And what about using AJP/1.3 instead of HTTP for connection to tomcat ?)
In all my deployments of tomcat I have never seen the point of a custom
protocol that did exactly what HTTP does, so all my tomcat deployments
are all HTTP, with a simple mod_proxy
Shapira, Yoav wrote:
Hi,
Unfortunately, now that I've moved to Tomcat 5, I discover that the bug
is still quite present. There is now a nice getURI() method along with
the previous getURL() method. Unfortunately, getURLs() does not use
getURI( file ).toURL() or any such as it would need to for
Costin Manolache wrote:
Well, the mod_proxy + enhancements for sticky session + enhancements for
passing auth info sounds reasonable - and if nobody wants the JMX
support, then maybe we won't need to write a new connector anyway :-)
Remy will be happy - we'll only use the http connector.
I
Jess Holle wrote:
One issue here:
When Apache and Tomcat are used together via AJP13:
1. The host, port, protocol, etc, are exactly that at the Apache
level, i.e. one's web app sees Apache and Tomcat as 1 entity.
This is a very good thing overall compared to reverse proxying (if
Jess Holle wrote:
Agreed -- but that won't fix the issue.
So can we fix it in 5.0.x or not?
Possibly, but it's risky.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Henri Gomez wrote:
Now what about the mod_proxy load-balancing add-on ?
The thing I'm most happy about with the simple load balancing + sticky
session + failover is that the development would be short (hopefully),
be bundled with Apache quickly, and could really help people's
experience with
Henri Gomez wrote:
Of course, I want a module designed for Apache 2.x (2.0/2.1). Apache 1.3
could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2.
No more code complexity to handle all the web-servers around,
we should focus on Apache 2.x.
Yes. A lot of the complexity is to allow
Henri Gomez wrote:
Second reference to mod_coyote ?
Should we retains this one ?
Maybe ;)
We have two connectors planned. This one will use AJP, while the other
would use JNI, so we need two, different, non confusing names. So naming
this mod_jk3 would be bad, just like naming the two
Costin Manolache wrote:
Mladen Turk wrote:
Hi,
All (except Costin) developers has to say something, so my conclusion is
that we are not dead after all ;)
I'm alive as well, and I have something to say - I spent last few
weekends playing with coyote and tomcat, probably in few weeks I'll
have
Costin Manolache wrote:
What complexity does JNI add to jk2 ? There are separate files, using
the same protocol.
The real important lesson in Jk2 is that JNI works faster and better
if it is not used to pass objects.
The only 2 JNI models that actually work are jk2 protocol
marshalling, pass
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
What complexity does JNI add to jk2 ? There are separate files,
using the same protocol.
The real important lesson in Jk2 is that JNI works faster and better
if it is not used to pass objects.
The only 2 JNI models
Slobodan Vujasinovic wrote:
I'm member of 'Enhydra Development Team' and we are currently developing
Application Server (Enhydra-Lite) based on Tomcat5.0.
I'm developing a side tool (EnTray - system tray administration tool (used
for starting/stopping server actions, accessing deployed
Costin Manolache wrote:
Remy Maucherat wrote:
I think you're mixing the Java side with the native side. I think the
Java side should obviously use JMX to monitor what's going on with
Tomcat. However, the native side will just recieve proprietary messages.
We have to keep the native side as small
Filip Hanik (lists) wrote:
hi Remy,
Time will open up in a week or so. And yes, I am wide open to any ideas.
My personal feeling about the farm deployer, is that it would work exactly
like auto deployment to Tomcat, and maybe just an entry in web.xml makes it
send to other servers.
Yes for the
Endre Stølsvik wrote:
On Thu, 15 Jul 2004, jean-frederic clere wrote:
|
|
| 2. workers2.properties - workers2.xml using apr_utils xml support.
| Get rid of 'assumed' properties like figuring out the context from url.
| Get rid of copying mappings from 'default' to virtual hosts.
| Of course,
Endre Stølsvik wrote:
| Cool that you have useful stuff to contribute. I'll kick you out of
this
| list, and recommend you don't come back.
I should have added if you keep this attitude at the end.
But isn't -kicking me off the list- rather harsh? I didn't flame
anyone in
particular, or
jean-frederic clere wrote:
My idea is about a new module, only Apache 2.x for now, which will
make use of SetEnv, SetEnvIf, BrowserMath and Location
directives to redirect some URLs to tomcats via AJP.
Everything in httpd.conf, probably that is a good idea. Reusing existing
directives also.
Many
My turn :)
Sorry, I won't help code it (well, maybe a little for the Java part); so
I don't know if I have a say in any decision, but I though I should
participate as well.
- it should be simpler than JK 1 or 2
- it should have a name which doesn't confuse folks :)
- Apache 2.x specific using
My updated TODO. So I'll do the deployer next, followed by trying to
optimize startup time.
Then, there's tweaking.
Filip, do you have time to refactor the clustering soon ? I think we
should tweak your farming feature as well, as it should likely be done
the way the manager servlet is
Jess Holle wrote:
Just a note:
Please allow the anti-locking stuff to be skipped on Windows as well.
[Some of us value performance over deployment convenience.]
Yes, of course. In production, many people don't use hot deployment (it
doesn't give good enough QoS right now, IMO).
- Possibly
[EMAIL PROTECTED] wrote:
PS: DefaultContext handling is very complicated. I hope we start a talk about
cleaner and better support for 5.next release.
I've been thinking about that for weeks, but I haven't found anything
really simpler yet. Some solutions I've thought about include JMX tricks
or
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
PS: DefaultContext handling is very complicated. I hope we start a
talk about
cleaner and better support for 5.next release.
I've been thinking about that for weeks, but I haven't found anything
really simpler yet. Some solutions I've thought about
Shapira, Yoav wrote:
Hi,
5.0.27-beta has been out for a few weeks, the TCKs pass, the tester and
watchdog tests pass, and there has been positive feedback for it on the
user list without any show stopper bug reports. This change is simply a
label change and minor website update, no code change or
Peter Rossbach wrote:
Hey,
the problem with 5.0.27 is not the NullPointerException check.
My problem is, that the 5.0.27 autodeployment for war's with
META-INF/context.xml
included not work as before. Currently the HostConfig generate a
directory at conf/engine/host/warname.xml/.
Ok, no problem
Henri Gomez wrote:
Well I don't see why the Client Support of Fnac is subscribed here,
so I strongly suggest mailing list manager to remove it.
I'm on a modem this week :/
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Henri Gomez wrote:
Remy ?
Henri Gomez wrote:
Take a look in jakarta-tomcat-connectors (ie:
http://apache.fastorama.com/dist/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz)
jakarta-tomcat-connectors\http11\src\java\org\apache\coyote\http11
Thanks, found it in
Jess Holle wrote:
I'll play with this as I have time, but I'll be doing the same sort of
thing with our own app first.
As I see it (and I could be offbase, of course, as I've not had time to
code this), one just needs a pluggable SPI sort of interface responsible
for:
1. A singleton
Jess Holle wrote:
Though I also really like Java 5's [yep, another neat numbering change
from Sun :-)] built-MBeans for JVM monitoring, I'd *really* like to see
a JSR 160 solution in Tomcat that works in Java 1.4.x and Java 1.5 (aka 5).
Is this the plan/hope? At a high level it does not look
Jess Holle wrote:
In my case even with 1.5 I need a pluggable (2) from above. Why?
Because I need to work with port ranges and grab the first free port
(with MBeans then proxied to a daemon with a consistent port #). 1.5
has no automatic machinery for this as best I can tell.
It's true that
Jeanfrancois Arcand wrote:
Remy Maucherat wrote:
Remy Maucherat wrote:
My upcoming change list:
- Attempt to redo a bit the deployer:
* remove the CL code which is there to avoid JAR locking (or at least
allow disabling this feature for non-Windows OSes); when enabling
anti locking
code, move
Peter Rossbach wrote:
Tomcat 5.5 Proposal:
There's no Tomcat 5.5 ;)
Adding More Flexibility to Config Listener and Deployer
Peter Roßbach Frank Wegmann
Cool, you're not compliaining about the ex-Logger anymore :)
Overall, I think I like it some ideas from your email. I have
modifications planned
/ not only for server.xml, also for
context.xmls :-)
I hope the first implementation is ready at this weekend.
Sure, show me the code.
see some comments directly at the 5.next topics.
Remy Maucherat schrieb:
My upcoming change list:
- Attempt to redo a bit the deployer:
* remove the CL code which
Peter Rossbach wrote:
Hey Remy,
OK, I am do my best that the save factory implementation work at weekend.
A good patch is better than a rushed patch ;)
I'm so tired of Windows right now ...
But few of the developers wan't work at linux :-\ ...
Yes, but the fact that M$ failed to address core
Remy Maucherat wrote:
My upcoming change list:
- Attempt to redo a bit the deployer:
* remove the CL code which is there to avoid JAR locking (or at least
allow disabling this feature for non-Windows OSes); when enabling anti
locking
code, move everything to a temp deploy folder where
My upcoming change list:
- Attempt to redo a bit the deployer:
* remove the CL code which is there to avoid JAR locking (or at least
allow disabling this feature for non-Windows OSes); when enabling anti
locking
code, move everything to a temp deploy folder where everything will be
referenced
Amy Roh wrote:
Hi Tomcat-Dev folks,
about the good old days
Oh, you mean Sun is picking up the tab ? ;)
I am not sure who on this list will be attending the conference
but you are all welcome.
Still no JavaOne for me this year.
Rémy
Peter Rossbach wrote:
Hello Remy,
I have problems to configure the new logger system.
Can you send a log4J example to demonstrate the new commons-log Logger
concept.
How I can configure a log4J system?
I have no success with add log4j.jar and log4j.xml to system class path
via setclasspath.bat
Peter Rossbach wrote:
Hello Remy,
I have made a deeper look at the current cvs logger code stage:
1) ContainerBase.getLogger()
With first getLogger call the Log was build with a strange name!
public Log getLogger() {
if (logger != null)
return (logger);
String
Peter Rossbach wrote:
Hello Remy,
with your Logger naming convention log4j not working
log4j:ERROR Parsing error on line 57 and column 99
log4j:ERROR Attribute value
org.apache.catalina.core.CatalinaBase.[].[localhost
].[Catalina] of type ID must be a name.
With this logger naming convention it
Bill Barker wrote:
Except that I can't see why you would want to use the
'Tomcat.[].[Catalina].[localhost].[myapp]' name except in a 'category'
element. Here, the name is defined to be CDATA so you should be fine (or it
is a log4j bug :).
Maybe Peter is stressed up because he's going to
Thorsten Kamann wrote:
hello Remy, hello Peter,
I am following your dicussion about the new logging in the tomcat cvs.
I have some question about this changes:
1. Old configurations in the server.xml and context.xml is not valid,
because the old logger with Logger ... / is defined?
2. How can I
Peter Rossbach wrote:
Also I thing the the current implementation is not compatible with all
Tomcat 5 releases
How we want migrate all the current Tomcat projects? How we made Logger
configuration
at runtime? Hmm. :-(
How about continuing using the Tomcat 5.0.x branch instead ?
About the
Thorsten Kamann wrote:
When this branch is so very different from the current 5.0.x, why ist
thne name not 6.x?
Because it doesn't implement a new spec, and there's no release plan
anyway at this time.
This is only a dream. In a hosting enviroment every customer will
logging different. We offer
[EMAIL PROTECTED] wrote:
remm2004/06/23 01:25:04
Modified:catalina/src/share/org/apache/catalina/valves
RequestDumperValve.java RequestFilterValve.java
JDBCAccessLogValve.java ErrorReportValve.java
Henri Gomez wrote:
This commit was sponsored by Eclipse 3 RC 1 and its refatoring
features :) Somehow, they spell that refactoring in the menus, but
it's evidently a mistake, as the features are powerful enough to
warrant the Genuine Refatoring (R) label.
Great use of Eclipse.
Eclipse 3 RC3 is
Remy Maucherat wrote:
Remy Maucherat wrote:
- Move to concrete classes for request/response, and remove all of the
RTTI done in Catalina's pipeline
Ok, I'm almost done with the first part of the refatoring (thanks to
Eclipse 3) :)
I think I'll commit when I'm done with the next two items, so
Peter Lin wrote:
I see your back from vacation. I hope it was restful.
No, no, I was doing a training in Vienna ;)
I've started
working on porting CLIPS 6.2 from C to Java. Once that is done, I will
donate it back to CLIPS community (since it's public domain software),
donate it as a project to
Bill Barker wrote:
TC 3.3 has o.a.t.u.xml.* which is uses instead of Digester. If it helps
with re-inventing wheels, you could take a look at it.
Yes, it's also in TC 4. I think it has limitations when compared to the
digester. Overall, the biggest problem of the digester might be the huge
Remy Maucherat wrote:
- Move to concrete classes for request/response, and remove all of the
RTTI done in Catalina's pipeline
Ok, I'm almost done with the first part of the refatoring (thanks to
Eclipse 3) :)
I think I'll commit when I'm done with the next two items, so that all
the big core
Shapira, Yoav wrote:
Hi,
FYI on this release: It is a CVS branch point for TOMCAT_5_0, so those
of you building from CVS directly should know that new stuff is going to
start appearing on HEAD that may reduce stability temporarily (you can
follow tomcat-dev discussions in the 5.next threads for
[EMAIL PROTECTED] wrote:
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=23914.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Shapira, Yoav wrote:
Hi,
I think I will tag and release 5.0.27 on Thursday evening (EDT time
zone), and branch TOMCAT_5_0 at that point.
The commons-dbcp (1.2.1) and commons-pool (1.2) dependency updates will
get into this build, as will commons-collections-2.1.1. The
commons-beanutils,
- Move to concrete classes for request/response, and remove all of the
RTTI done in Catalina's pipeline
- Use Tomcat 4.0 beta valve pattern
- Redo logging using commons-logging, and remove Logger
- Fork commons-digester, to remove what we don't need (many fancy
features provided by beanutils, and
601 - 700 of 2871 matches
Mail list logo
