Re: MinTC, got problem while try to run java -jar mtc.jar
Although MinTC uses the Catalina framework, it isn't actually an official part of Tomcat, so questions about it are probably best kept to [EMAIL PROTECTED] Exception in thread main java.lang.NoClassDefFoundError: mtcserver I'll take a look and email you privately. Thanks for the feedback! -cks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
Probably a little late: [X] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: Actually, I'm probably closer to a +0 for the next few weeks, slowly transitioning back into being able to help implement after that. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Performance Test Workload: HelloWorld Servlet
I'm getting unusual preliminary results on some
performance tests against a very simple servlet, and
I'd like to see what results other people get. If
you're going to run the tests yourself, don't look at
my results ahead of time if you can resist (they're at
the bottom of the message)
I'm http_load'ing against 4.0.3 and 4.1 HEAD using
8 threads and 0,1,8,16 and 32k response sizes. I ran
http_load on one machine and Tomcat on another. I ran
a couple rounds before the final test at each response
size to let the jit warm things up.
The server.xml I used just declares a single HTTP
connector and a simple Engine/Host/Context. No logging,
valves, etc.
The results are preliminary because I haven't done the
appropriate system tuning and didn't bother with the
proper controls on what was running on my test box, I
have a sneaking suspicion I'm a few days out of date
on HEAD.etc, etc. Note also that hitting a single URL
over and over is a totally bogus way to test
performance, but relative results between different
versions of the same software can be interesting.
-
public class HelloServlet extends HttpServlet {
private static byte[] buf;
private static int sz = 32*1024;
public void init() throws ServletException {
buf = new byte[sz];
for(int i=0; isz; i++)
buf[i] = 88; // ASCII 'X'
}
public void doGet(HttpServletRequest req, HttpServletResponse rsp)
throws IOException, ServletException
{
OutputStream ostr = rsp.getOutputStream();
ostr.write(buf);
}
}
-
PRELIM RESULTS
MinTC is included for comparison, since it uses the 4.0.3
HTTP connector but attempts to improve the Catalina side
of things. It's sort of the converse of the 4.1
Connector improvements. But it's not finished so it's not
really a fair comparison. Think of it as an upper bound on
where relatively unsophisticated Catalina optimizations
can get you.
I'm running Linux with kernel 2.4.17, and Java HotSpot(TM)
Client VM (build 1.3.1_02-b02). The results are better
with the server VM, but it didn't look like the startup
scripts were running Tomcat that way.
All results are in bogo-cps (bogus connections-per-second).
Note that the idea is not to test against other web servers
(except possibly Apache as a baseline), but against versions
of Tomcat. The 32k results are saturating the local network.
4.0.3 4.1.X MinTC
0k/8 881 9601059
1k/8 855 9161010
8k/8 719 732 767
16k/8 520 533 532
32k/8 319 320 320
Ignore the absolute numbers, yours will be very different.
(I'm too lazy to normalize them). I'll hold off on
conclusions until I get some feedback about whether other
people are getting similiar results (or if my test setup
was a little too preliminary)
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Performance Test Workload: HelloWorld Servlet
Remy Maucherat wrote: So to summarize, the old connector *may* look ok in very specific synthetic benchmarks (you chose the right one; I hope you didn't choose that one to try to prove that Coyote sucks, or something like it), but actually, it has (big) issues. All these could be refactored, but it would take a lot of time, and you would end up with something like Coyote in the end. Two things: - I'm purposefully not addressing anything but performance claims and performance goals in this thread. Otherwise things get too muddled. I understand that there are other considerations. - I chose the test based on Costin's feedback of the sort of tests he was using[1]. I may be a suspicious SOB, but I strive to be an intellectually honest suspicious SOB. What can I say, I was born in Missouri[2] If you provide more details about what tests you are using (and you've made a start at it, thanks), then I can add those to the list. The more details the better. But it's generally up to the person making performance claims to provide pointers to the benchmarks details that provide evidence for their claims, both so other people can see the particular test biases, and so they can run them themselves. If you've already done that, I apologise, it's a royal pain finding good keywords for archive searches. A pointer would be appreciated. Just to be safe: Questioning your performance claims does not mean that I'm implying you are dishonest or incompetent. I am honestly operating on the assumption that you are neither. But I am assuming that you might be mistaken. [1] http:[EMAIL PROTECTED]%3e [2] http://www.sos.state.mo.us/archives/history/slogan.asp frothy eloquence neither convinces nor satisfies me. I am from Missouri. You have got to show me. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Performance Test Workload: HelloWorld Servlet
[EMAIL PROTECTED] wrote: Let me know when you have the results with the writer. Costin, thanks for the further details. Rather than a higher level discussion (followed by me spending more time running benchmarks, followed by more high-level discussion), could could you give a pointer to where you posted your results, and possibly the servlet code that you used? Hints, keywords, whatever is fine, I don't mind digging around in the archives more. I'm a little concerned about any further rounds of you picked just exactly the wrong test. Actual results would help me avoid repeated trips to the list to confirm my tests, and actual code would help me understand _exactly_ what assumptions you were making. Thanks, -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Perf. Test Workload: Long Running CPU/mem/etc
Pier Fumagalli wrote: And not just numbers in terms of reqs/sec, but also in comparison to a long-run test with % of CPU time used, and IO usage (uptime)... Pier, I'd like to run some tests along these lines, but they're a major pain to set up, so it's worth a little up-front discussion of the methodology. Feedback from someone who's actually experienced the problems would help define reasonable boundaries for a useful test: - How long? Minutes (under high load), hours, days? If, for example, the problem is with light load over days, it might be reasonable to aproximate it with a heavy load over minutes. I'll be looking through the archives and bug lists, but any direct feedback on especially problematic areas is appreciated. - What sort of load profile? The more specific the better. A single URL over and over is easy (and easy to analyze), but a mix is more realistic. Also, static files or just servlets? JSP? etc. It's easy to move into the dreaded general overall test of performance trap, so maintaining a tight focus is important. - Stats? CPU, disk usage, memory, etc. But it gets to be a problem to measure all of those things in a way that applies cross-platform, so I'd prefer to base the statistics collected on specific problems. (Memory usage climbs, so we monitor that, CPU usage goes up, so we monitor that). There's a bit of a focus issue here, too. I need to be careful to avoid turning this into a regression test. (A regression load test would be good, but that's not this) I think you could argue that tomcat gets slower over time is a performance thing, but tomcat crashes under heavy load is just a bug. If there's already a thread on this in the archives, pointers, keywords, bug#'s, etc. are much appreciated. Thanks, -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
[EMAIL PROTECTED] wrote: On Mon, 24 Jun 2002, Remy Maucherat wrote: However, it sounds generic, and not at all dependent on Tomcat, so that's why I think it would be a lot better in the commons. Maybe watchdog would be a better place for it. Watchdog is an official TCK, so it's probably a little off focus to put Tomcat-specific performance workloads there. What I'm talking about is not generic at all, it's a Tomcat-specific development tool (like the internal regression tests) and of little interest outside Tomcat I'm iffy on commons and JMeter as well. (Costin, this one's for background, not for you :-), but: I agree that writing a totally generic webapp performance suite is difficult and of limited use. That's not what I'm proposing, ref the benchmarks thread for details. ( or a -tomcat repository for all tests ) ? Do you mean move the current set of regression tests out of j-t-4/tester and j-t-4/src/catalina/test into a new repository? I agree that it's reasonable to put the Tomcat-specific regression tests and profiling workloads together in the same place. I'd like to see them all together with the normal source download, because developers should (in theory) re-run the tests before checking in changes. But since Tomcat is already divided up into multiple repositories, I'm not going to object as long as all the tomcat-specific developer tools/tests are together. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0 : benchmarks
Good proposal goals provide a way to test if the goal has been achieved and a way to argue if the goal is worthwhile. Improve performance as a goal is both untestable and impossible to argue with, so it's a badly stated goal. Remy Maucherat wrote: To evaluate code, I strongly recommend using a profiling tool instead of benchmarks, as it also helps finding places where your code is inefficient. Profiling tools and internal benchmarks answer different questions. You don't use a profiling tool instead of a benchmark, you use it with a benchmark. Talking about performance improvements without also talking about workload is pointless. Setting up some standard internal workloads has several advantages: #1) If forces you to consider what's important and what's not. In that sense, it's a very precise communication tool as much as anything else. It provides a way to nail down your goals. Saying that our goal is to improve performance is like saying our goal is to make the software better. Sure, ok, who could vote against that? Saying something like we need a 50% improvement in request processing time for servlets that produce large (50k) pages provides a testable goal to shoot for (and an opportunity for other developers to say wait, that's not a good goal to shoot for) #2) It provides a common framework. If you claim a 25% performance improvement, you've told me nothing. If you claim a 25% improvement on the helloworld servlet performance test, then I know what you mean and can try it out for myself. It's very easy to fool yourself, and a standard workload acts as a BS detector. #3) It saves time in the long run, since everyone doesn't come up with their own mini-internal performance test-suite. In fact, you generally start something like this by posting your personal performance testing setup so others can use it, and it grows from there. It doesn't have to be completely formal, it just needs to be acknowledged as an issue. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0 : benchmarks
Bill Barker wrote: I agree with Remy that any single benchmark suite isn't going to tell you how your particular web-app will perform. Bill, Actually, I agree, but this isn't what that is :-) There's a difference between: a) Benchmarks for users that compare the performance of servers against one another to help with buying decisions. These are hard to write, hard to interpret, and generally not very useful in predicting the performance of a particular user's web apps. b) Benchmarks for developers that help answer the (suprisingly difficult) question did my so called performance enhancement help or hurt? and have we met our performance goals. They also help set up a framework for talking about performance. For example, using the Apache ab utility is a quick and easy way to get a very skewed performance estimate. If there's something written down, everyone has some clue that there's a skew, and some idea about what the skew is. (b) is a much easier than than (a), because the point is to nail down the vocabulary and set up a common framework for measuring progress, not to develop some ultimate web-app performance benchmark for users. It's a purely internal thing. This isn't something I just made up :-) It's sort of software engineering conventional wisdom that internal benchmarks are necessary if you're going to make performance a development goal, and I've used them to good effect on several commercial projects. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0
Remy Maucherat wrote: I'm committing a draft for a Tomcat 5 proposal. It is a draft, so it is not in final form yet (it needs feedback for that). Re-architecting Tomcat yet again is a bad step if it's not absolutely necessary. I have some reservations. To keep from confusing the issue, I'll list them in separate messages. In criticism I will be bold, and as sternly, absolutely just with friend and foe. From this purpose nothing shall turn me. - Edgar Allen Poe while at the same time adding support for the new Servlet API 2.4 and JSP 2.0 specifications Reservation #1: There is a new architecture being proposed, but since the 2.4 API isn't out yet, all the requirements aren't available. So there's no intelligent way to judge if the architecture fits well with the primary requirement (which is being a good 2.4 container) Tomcat 5 isn't some sort of generic server framework, it's the reference implementation for the 2.4 spec. The spec is central. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0 : #1: 2.4 spec
[EMAIL PROTECTED] wrote: I hope the 2.4 API will not do any crazy things Me too. One of the things I heard mentioned was tighter integration with the NIO api's, which could affect both low and high level layers. OTOH, maybe not, I haven't seen the spec. But that's the whole point. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs
Ok, second round. People are +1'ing the _goals_ of the proposal, but I the proposal itself doesn't give sufficient detail to determine if the recommended actions will actually lead to those goals being accomplished. Some of the goals even appear to be contradictory, but there's no discussion of the inevitable engineering tradeoffs. Simplicity vs Flexibility is a big issue. For example, the Coyote framework is compatible with Tomcat 3 and Tomcat 4. This is admirable, and may lead to closer ties between the two groups of developers. BUT Coyote is also more complicated and harder to understand than the HTTP connector code in Tomcat 4 that it replaces. It does more, too, but let's face it, it's an integrated framework for writing connectors, and frameworks are harder to understand and build than single-purpose code. That isn't to say it wasn't worth it, but you've gone from only needing to understand o.a.c.connector to having to understand a whole slew of packages and patterns and conventions. There's more buy-in required. I'd like to see considerably more discussion about tradeoffs before the proposal is approved. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs
[EMAIL PROTECTED] wrote: On Fri, 21 Jun 2002, Christopher K. St. John wrote: People are +1'ing the _goals_ of the proposal, but I the proposal itself doesn't give sufficient detail ... That's exactly the target - to set the goals and the overal direction ( it's a 'long-term plan' ). The proposal lists a set of goals (like simpler and more flexibile) and a set of actions to acheive those goals (like make Coyote the core of Tomcat 5). I (more or less) agree with the goals, but I have some reservations about the proposed course of action. I would hope that many others on this list would also have questions, since the proposal itself is too vague to base a decision on. (Although your answers to my questions are helping, thanks) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs
[EMAIL PROTECTED] wrote: But most of the stuff is needed to get decent performance - and to be able to support other protocols and have better integration with the server. - What are the peformance goals? Actual numbers or a percentage improvement goal is something that I would really like to see in the proposal. - Conventional wisdom is that performance tuning code makes it more complex, not simpler. - Layering the code, so that different protocol implementation can be plugged in, is likely to reduce performance. And make the code more complicated. For best performance, you want to skip the layering and framework code entirely and make everything special-purpose. - Better integration with the server makes the code more complex. Integration with multiple servers (like Tomcat 3, Tomcat 4 and Tomcat 5) would normally add quite a bit of complexity. Performance, flexibility and simplicity are at odds with one another. This is a basic engineering truth, and you're going to have a tough time convincing me it doesn't apply here. There are many things that are hard or impossible with o.a.ajp. ... the point is you can't get too much performance without good buffer management, byte[], optimized conversions, etc. Ok, but that's an argument for rewriting o.a.ajp, not for making Coyote the core of Tomcat 5. Is there something about the interfaces defined in Catalina that makes optimizations impossible? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0 : #3 Straw Man
[EMAIL PROTECTED] wrote: I can tell I spent few months with almost daily runs in OptimizeIt and several 'ab' per day. Hold on. It sounds like you think I'm saying you didn't do your homework. I'm not saying you don't know this stuff, I'm saying that there aren't pointers to this work in the proposal. What I'm definitely not doing it taking your word for it. I don't even take my own word for stuff like this, so it has nothing to do with you personally. ab really isn't sufficent for what I'm taking about, though. It produces extremely skewed results. It's something of a blunt instrument. How about this for a concrete suggestion: Add come up with a set of benchmarks and performance goals as part of the proposal. (And yes, I'm volunteering to help) Let me ask a question - how much time have you spent benchmarking and profiling tomcat ? Part time over the course of about 4 weeks. I was investigating how much of a performance improvement I could get out of using the NIO api's for serving static files, and part of that was comparing against the performance of other servers written in Java. That was pre-Coyote, though. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0 : #3 Straw Man
Remy Maucherat wrote: - Tomcat 5 is Tomcat 4 with lots of cleanup work and modifications for whatever the 2.4 spec comes up with. There are no major architectural changes. OTOH, the 2.4 spec could be bizarre, in which case all bets are off :-) My proposal is not very different from that. Maybe I'm just hung up on some of the wording, then. I'd like to see specifically: - An item about coming up with a set of benchmarks and performance goals as a priority. My BS alarms go off when people discuss performance outside of an agreed upon set of benchmarks (even if I know them to be smart developers who probably have really done the bencharks and profiling) - Details about how the existing Catalina JXM management interfaces will be merged with Coyote JXM management code. Or at least an acknowledgement that it's an issue. - A listing of specific issues with Tomcat 4's current implementation. for example, the startup code is opaque, it's unclear what events get sent when, etc. The important thing is that there's a specific list of problems that need to be solved. - And (I may be reaching here), Coyote is moved from being core to being the connector architecture. BTW, maybe you consider all that ugly, but I don't. I find the XML Mapper / Digester pretty cool I really like the Digester. I was referring specifically to how non-optional parts of the core implementation (like ContextConfig) are added as listeners instead of being called explicitly. They look like they should be pluggable, but the way they're implemented right now, they're not. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0 : #3 Straw Man
Remy Maucherat wrote: - Details about how the existing Catalina JXM management interfaces will be merged with Coyote JXM management code. Or at least an acknowledgement that it's an issue. The beauty about JMX is that you don't have to merge anything. It's obviously a bit silly to have part of Tomcat 5 using one set of utilities for JXM, and part using something else. It definitely makes the code harder to understand and maintain. A good, higher level goal might be: - Move towards a single framework for JMX management of Tomcat 5 components. Note how this give you something concrete to shoot for (or argue with). -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache 1.3/jk2, redirects, redux
Christopher K. St. John wrote: jk/java/org/apache/jk/JkCoyoteHandler ACTION_CLOSE is getting called with no call to ACTION_COMMIT Quick fix is to have JkCoyoteHandler CLOSE commit if the response hasn't already been committed: if( !res.isCommitted() ) this.action( ActionCode.ACTION_COMMIT, param ); Looks like this may really be how it's supposed to work, so I'd like to check this change in. However, as other people are actively working on the code, I'm going to be a wimp and ask first. Background: Http11Processor.action(CLOSE) results in a call to outputBuffer.endRequest() which does the same sort of check-if-commited-and-commit check that I want to add to JkCoyoteHandler. Are there any objections? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal draft for Tomcat 5.0 : #3 Straw Man
Glenn Nielsen wrote: Proposal in General: The proposal is pretty vague on details. I have seen a number of replies stating That's an implementation detail. I for one would like to see the proposal broken out into much more detail before work starts. Perhaps we should take a step back and start asking questions first so that there is more information and consensus for a formal proposal. Questions like: 1. What code in Tomcat really smells bad? 2. Based on the previews of the Servlet 2.4 and JSP 1.3 specs, what major changes are expected. 3. Are there any major new features needed? My fear is that work on Tomcat 5 will turn into a CVS version of the wild wild west if the proposal isn't detailed enough. +1. I will be out of town this weekend. I'll be checking my mail, but I won't be able to participate as fully as I like for the next day or so. I can't expect everything to grind to a screeching halt because I'm not here. On the other hand, a discussion as important as this needs to take place over the course of a couple of normal business days so the entire community has a chance to give input. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Apache 1.3/jk2, redirects, redux
jk/java/org/apache/jk/JkCoyoteHandler ACTION_CLOSE is getting
called with no call to ACTION_COMMIT when:
- jk2 is being using with Apache 1.3 and
- there's a redirect (like with a welcome page)
Quick fix is to have JkCoyoteHandler CLOSE commit if the
response hasn't already been committed:
} else if( actionCode==ActionCode.ACTION_CLOSE ) {
org.apache.coyote.Response res=(org.apache.coyote.Response)param;
if (!res.isCommitted())
this.action(ActionCode.ACTION_COMMIT, param);
But the code is (presumably, I haven't checked) working fine
for non-Apache 1.3 setups, and I hate to make a change without
understanding where the real root of the problem is. Hints
appreciated.
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What is the Container implementation for HttpConnector
Chandra Talluri wrote: I am having trouble finding out the Container implementation for HttpConnector or any connector. I'm not sure what you mean. Connector doesn't implement Container. Or are you asking something else? Can some one tell me which is the Container and where the connector.setContainer being called org.apache.catalina.core.StandardService.setContainer() calls setContainer() on all its Connector children. Grep+xarg is a good combo if you're on Unix, or there are IDE's that will let you search the code. But that may just move your question up a level, how does StandardService.setContainer() get called, etc, etc. It's all driven off conf/server.xml using code based in org.apache.catalina.startup. The server.xml docs are a good intro to how it all fits together: http://jakarta.apache.org/tomcat/tomcat-4.0-doc/config/index.html In theory, you can set up server.xml with any sort of Container hierarchy you want. In practice, your object structure is going to look like the examples in the config docs. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Minor fix for servletapi-4 GenericServlet
Christopher K. St. John wrote: GOMEZ Henri wrote: I propose you to make a PROPOSAL for servletapi4 patch to tomcat-dev list. My proposal is ... [delete log() msgs in GenerisServlet] From my reading of the project guidelines, minor fixes like this normally go the commit-then-review route, so I'm unclear if there need to be 3 +1's before any action is taken. There's just been the one (by Remy) so far. I realize it isn't a very exciting patch :-), but minor bugs need love too, so a couple more +1's (or a -1 if there is some problem) would be nifty. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
watchdog, servletapi, karma
I'd like to check in some (fairly minor) fixes to jakarta-servletapi-4 and jakarta-watchdog-4.0, but I don't have the karma. Is it a big deal to get added? I wasn't sure if servletapi and watchdog were closely tied to tomcat or their own whole thing with separate administration. It looks like there's been no recent traffic to servletapi-dev, and minimal traffic to watchdog-dev, instead everybody just posts to tomcat-dev, so... -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: watchdog, servletapi, karma
GOMEZ Henri wrote: I'd like to check in some (fairly minor) fixes to jakarta-servletapi-4 and jakarta-watchdog-4.0, but I don't have the karma. Is it a big deal to get added? Will you apply some patches to jakarta-servletapi-4 code ? Well, I wanted to apply a patch for a bug I reported a while back where GenericServlet.init() and destroy() send messages (saying init and destroy) to log(). It's not a showstopper, but it's very annoying. If someone else wants to remove the two log() statments, that would be great. Or do you mean you (Henri Gomez) have some patches and want somebody to apply them? If I had the karma, and the patches were righteous (and I suspect they would be), then sure. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PROPOSAL] Minor fix for servletapi-4 GenericServlet
GOMEZ Henri wrote: I propose you to make a PROPOSAL for servletapi4 patch to tomcat-dev list. In the jakarta-servletapi-4 repository, the class: javax.servlet.GenericServlet has init() and destory() methods that call log(). While not specifically prohibited in the 2.3 spec, it results in unncessary output into logs. Also, it's annoying. My proposal is to remove the two log() statements from GenericServet.init() and GenericServlet.destory(). If somebody needs them for debugging, they can add them back into their local copy. This was reported as bug #7190. I've included a patch as an attachment to this message (it just removes the two log messages and updates the copyright date) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com jsa4-gensrv.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Can we write our own connector
Chandra Talluri wrote: Is it possible to write our own connector using catalina. If so can some one point me to the proper documentation It depends on exactly what you're trying to do. There are two (closely connected) ways that the term connector is used. First, Catalina has an interface called Connector that is the external hook for all request processing. Second, small-c connector normally means the code that allows a servlet container to talk to a front-end web server like Apache. Small-c connectors are generally made up of some native code that hooks into the front-end web server (like mod_jk for Apache) and some Java code over on the servlet container side. Which one do you mean? And why, exactly, do you want to do this? There may be a better way. Writing a new connector (or Connector) is certainly possible, but it's not for the faint of heart :-) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Can we write our own connector
Chandra Talluri wrote: We have our own server which accepts the data either on a TCP port or a UDP port. the data is a little vague. What does the data look like? What does the server actually do, right now? What's it for? The more specific you can be about what you're trying to do, the more likely it is you'll get an answer. Basically we want to integrate the catalina.jar and other required jars in our server so that our server can invoke the servlets. So you want two things: 1) To embed Tomcat 4 inside your application. 2) To replace Tomcat 4's default HTTP and JK connectors with your own, custom Connector that deals with your custom, unspecified, non-HTTP protocol. Is that correct? Both of those things are certainly possible (assuming your secret protocol is more or less similiar to HTTP), but neither one of them is a beginner level project. Check out the code for: org.apache.catalina.Connector org.apache.catalina.startup.Embedded Documentation-wise, what you see is what you get. You're much more likely to get an answer if you ask very specific, closed-end questions, esp. if you refer to actual code. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mx for jk
[EMAIL PROTECTED] wrote: In case you didn't noticed, I checked in a small 'magic' util that turns Jk components into dynamic MBeans. It still doesn't support the 'descriptions' and the ability to fine tune the exposed attributes/methods, that will be added later ( and will probably require xdoclet or a similar tool ). This sounds a bit like o.a.commons.modeler. (modeler provides code to fill in MBean meta-data based on an external xml file, see o.a.catalina.mbeans.mbeans-descriptors.xml) Is the magic jk code related, a replacement, or just something completely different? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Ethereal AJP13 dissector?
I was doing some debugging and sort of accidentally ended up writing most of an AJP13 dissector for ethereal. A proper dissector is much easier to deal than raw ethereal captures if you're not an AJP13 guru. It didn't occur to me until afterwards that somebody else might have already done it. If nobody has already written one (and anyone is interested) I'll clean it up and publish it. I suspect it belongs in with the rest of the dissectors over in the ethereal tree rather than in with the tomcat connector code, but I'm open to suggestions. If anyone is interested in helping to test, or wants to get a preview of AJP13 all dissected and gui'ed up, I can post the code wherever's appropriate. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ethereal AJP13 dissector? [Ethereal patch attached]
jean-frederic clere wrote: I am rewritting the Ajp protocol documentation. A protocol analyser would help me. The analyzer was written using the existing docs, so if there are problems in the docs the analyzer will be wrong as well. So please send it. (Even if it is not run and not clean). Some of the code is a bit iffy, and it's definitely a work in progress, but it runs. I did some cleanup and put in some comments. I've attached a patch to Ethereal 0.9.4, which you can get at: http://www.ethereal.com/ Make sure you have a recent version of libpcap. If you want to hack on it, there are Ethereal developer docs in docs/README.developer, but they are very out of date. Notes: It autodetects 8009 as AJP traffic. It doesn't decode FORWARD_REQUEST attributes (the optional stuff at the end). There are problems with the protocol hierarchy display. There are probably memory leaks. The protocol display could be easier to read. You need ethereal-0.9.4, I'm confident it won't work with earlier versions, and I haven't tested against CVS. There are lots of compiler warnings, many of them legitimate. Install: download and untar a clean copy of ethereal-0.9.4.tgz $ cd $PATH_TO_ETHEREAL/ethereal-0.9.4 $ patch $PATH_TO_PATCH/eth-ajp13.patch patching file Makefile.am patching file Makefile.nmake patching file packet-ajp13.c patching file packet-ajp13.h patching file register-static.c $ ./configure $ make many compiler warnings $ su # ./ethereal make sure that Edit - Preferences - Protocols - TCP Allow subdissectors to desegment TCP streams is set to true Capture - Start - Ok # try update packets in real time Surf Giggle like an anime schoolgirl as you watch the capture -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com eth-ajp13.patch.gz Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using NIO package for Tomcat connector?
Setera, Craig wrote: Using NIO would lower the number of required threads and buffers/objects that would need to be created. The core servlet model can't really be converted to using non-blocking I/O. The whole point is that your servlet gets its own thread. On the other hand, other servlet containers have been doing things like using NIO to watch idle persistent connections, and there look to be great opportunities for improving standalone Tomcat's performance in sending static files. There are some threads in the tomcat-dev archives you might want to check out. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-tomcat-connectors documentation/summaries
Ignacio J. Ortega wrote: De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 2 de mayo de 2002 5:16 For me is controversial to have a document at jakarta, that affirms Speaking of having a document at jakarta, it isn't there yet. And it won't go live unless everyone likes it (think We are the world as sung by a chorus of tomcat developers, all holding hands, etc). So no worries. I think it may have reached the better than nothing stage, and I'd like to start formatting and cleanup. That presupposes a destination. I originally talked to Henri Gomez about hanging it off a jakarta-tomcat-connectors page, but Glenn Nielsen also mentioned a Tomcat FAQ. Where should it go? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jakarta-tomcat-connectors documentation/summaries
Another update. Same disclaimers as before. FAQ's (just an idea, these don't have to be included) Q: Is mod_webapp replacing mod_jk? A: No. See below for links to documentation, then choose the one that best suits your needs. Q: Is Coyote replacing mod_jk? A: Coyote isn't the same sort of thing as mod_jk, see below in the Coyote section for more details. Q: It's all very confusing. A: Yes. A good strategy is to read through the summaries below and follow some of the documentation links. If you still have questions, try searching the tomcat-user mailing list archives, someone has probably answered the question already, there may even be a HOWTO already prepared. If that doesn't help, then you might consider posting your question to tomcat-users. non-jakarta howto's: these were culled from recent posts to tomcat-users. i have no way to judge if they are any good. it would be nice to only include the ones that someone can vouch for, but that may be too much work. the list is evolving... http://www.acg-gmbh.de/mod_jk/ Apache 2.0/Tomcat 4/mod_jk/Win32 http://www.pubbitch.org/jboss/ Apache 2.0/Tomcat 4/mod_jk2/JBoss Apache 2.0/Tomcat 4/mod_webapp/JBoss http://bruno.vernay.free.fr/HowTo/bWebServerHowTo/index.html Apache ?.?/Tomcat 4/mod_webapp/Win32 references link has list of other HOWTO's mod_jserv although it's probably still in production use at some sites, mod_jserv generally shouldn't be considered for new installations. why it was written: it was there first. where to get the source: jakarta-tomcat repository src/native/mod_jserv/ where to get documentation: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-apache-howto.html [ed] In tomcat-3.3-doc/index.html, it looks like mod_jserv is the suggested connector, and mod_jk is optional or alternative or something. It's my understanding that this is incorrect, and mod_jk should be used for new installations. It's a little confusing. unerlying protocol: AJP11 - original protocol Ajp12 - also supported in mod_jk1. works with: servlet containers: JServ Tomcat3.x as well ( which supports ajp12 ) web servers: All apache1.3 versions operating systems: ??? mod_jk why it was written: originally, clean-up of mod_jserv. Refactoring of mod_jserv to better abstract the server and protocol. features: many production users. load balancing with both tomcat 3 and tomcat 4 [EMAIL PROTECTED] Pretty good OO model, good abstraction for server and protocol, etc. future: mod_jk2, as of [30 Apr 2002] still in pre-alpha. status: in production for tomcat 3, 4. see also webapp connector. where to get the source: jakarta-tomcat-connectors/jk where to get documentation: jakarta-tomcat-connectors/jk tomcat-dev mailing list archives http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk2.html works with: servlet containers: jserv? tomcat-3 tomcat-4 web servers: domino apache 1.3 apache 2.0 (HEAD) netscape AOLServer ( not in the main tree ). IIS platforms: many. underlying protocol: AJP, see mod_jserv evolution: AJP12, binary AJP13, better SSL support. the current protocol. AJP14, there is no AJP14, it's a shelved experiment. AJP13 is flexible enough for future growth, and there's the possibility of eventually moving to an industry-standard marshalling protocol like XDR or CDR. see comments below. documentation/mailing-list/cvs comments of interest: Re: [NITPICK] didn't see this one coming... Mon, 29 Apr 2002 07:54:09 -0700 (PDT) [EMAIL PROTECTED] ... Note that mod_jk2 is not and will not be ready for 4.1 ... [EMAIL PROTECTED] Also - it's [mod_jk -ed] the area/component of tomcat with the largest number of individual commiters ( by my count at least ). And more important - one of the things that 3.x and 4.x share and seem to bring cooperation from both sides. Mod_jk v/s mod_webapp on tomcat-dev: Bill Barker wrote: mod_jk2 is the next generation of mod_jk. It is currently barely Alpha quality for Apache 2.x (and still subject to major changes from day-to-day) costin: Mod_jk works on all web servers and with all tomcat versions. Mod_jk2 will do the same. [EMAIL PROTECTED] : it started with ajp11 and ajp12 ( first text based, second binary ). Ajp12 evolved into ajp13 - using same encoding but with some extensions ( to deal with persistent connections ). GOMEZ Henri [EMAIL PROTECTED] : using jk instead of warp depend
RE: jakarta-tomcat-connectors documentation/summaries
Another update. Same disclaimers as before. FAQ's (just an idea, these don't have to be included) Q: Is mod_webapp replacing mod_jk? A: No. See below for links to documentation, then choose the one that best suits your needs. Q: Is Coyote replacing mod_jk? A: Coyote isn't the same sort of thing as mod_jk, see below in the Coyote section for more details. Q: It's all very confusing. A: Yes. A good strategy is to read through the summaries below and follow some of the documentation links. If you still have questions, try searching the tomcat-user mailing list archives, someone has probably answered the question already, there may even be a HOWTO already prepared. If that doesn't help, then you might consider posting your question to tomcat-users. non-jakarta howto's: these were culled from recent posts to tomcat-users. i have no way to judge if they are any good. it would be nice to only include the ones that someone can vouch for, but that may be too much work. the list is evolving... http://www.acg-gmbh.de/mod_jk/ Apache 2.0/Tomcat 4/mod_jk/Win32 http://www.pubbitch.org/jboss/ Apache 2.0/Tomcat 4/mod_jk2/JBoss Apache 2.0/Tomcat 4/mod_webapp/JBoss http://bruno.vernay.free.fr/HowTo/bWebServerHowTo/index.html Apache ?.?/Tomcat 4/mod_webapp/Win32 references link has list of other HOWTO's mod_jserv although it's probably still in production use at some sites, mod_jserv generally shouldn't be considered for new installations. why it was written: it was there first. where to get the source: jakarta-tomcat repository src/native/mod_jserv/ where to get documentation: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-apache-howto.html [ed] In tomcat-3.3-doc/index.html, it looks like mod_jserv is the suggested connector, and mod_jk is optional or alternative or something. It's my understanding that this is incorrect, and mod_jk should be used for new installations. It's a little confusing. unerlying protocol: AJP11 - original protocol Ajp12 - also supported in mod_jk1. works with: servlet containers: JServ Tomcat3.x as well ( which supports ajp12 ) web servers: All apache1.3 versions operating systems: ??? mod_jk why it was written: originally, clean-up of mod_jserv. Refactoring of mod_jserv to better abstract the server and protocol. features: many production users. load balancing with both tomcat 3 and tomcat 4 [EMAIL PROTECTED] Pretty good OO model, good abstraction for server and protocol, etc. future: mod_jk2, as of [30 Apr 2002] still in pre-alpha. status: in production for tomcat 3, 4. see also webapp connector. where to get the source: jakarta-tomcat-connectors/jk where to get documentation: jakarta-tomcat-connectors/jk tomcat-dev mailing list archives http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk2.html works with: servlet containers: jserv? tomcat-3 tomcat-4 web servers: domino apache 1.3 apache 2.0 (HEAD) netscape AOLServer ( not in the main tree ). IIS platforms: many. underlying protocol: AJP, see mod_jserv evolution: AJP12, binary AJP13, better SSL support. the current protocol. AJP14, there is no AJP14, it's a shelved experiment. AJP13 is flexible enough for future growth, and there's the possibility of eventually moving to an industry-standard marshalling protocol like XDR or CDR. see comments below. documentation/mailing-list/cvs comments of interest: Re: [NITPICK] didn't see this one coming... Mon, 29 Apr 2002 07:54:09 -0700 (PDT) [EMAIL PROTECTED] ... Note that mod_jk2 is not and will not be ready for 4.1 ... [EMAIL PROTECTED] Also - it's [mod_jk -ed] the area/component of tomcat with the largest number of individual commiters ( by my count at least ). And more important - one of the things that 3.x and 4.x share and seem to bring cooperation from both sides. Mod_jk v/s mod_webapp on tomcat-dev: Bill Barker wrote: mod_jk2 is the next generation of mod_jk. It is currently barely Alpha quality for Apache 2.x (and still subject to major changes from day-to-day) costin: Mod_jk works on all web servers and with all tomcat versions. Mod_jk2 will do the same. [EMAIL PROTECTED] : it started with ajp11 and ajp12 ( first text based, second binary ). Ajp12 evolved into ajp13 - using same encoding but with some extensions ( to deal with persistent connections ). GOMEZ Henri [EMAIL PROTECTED] : using jk instead of warp depend
Re: jakarta-tomcat-connectors documentation/summaries
Christopher K. St. John wrote: Another update. Same disclaimers as before. Mail client mishap, second one's a duplicate, sorry. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-tomcat-connectors documentation/summaries
Ignacio J. Ortega wrote: Re: jakarta-tomcat-connectors documentation/summaries pier: There were some other motivations when it all started... Hmmm. The theory is that the document should be absolutely 100% non-controversial. Other parts of the entry already emphasize ease of use, so I don't think removing the quote would change the meaning. Is that acceptable to everyone, including Pier? If not, let me know, otherwise the quote goes. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-tomcat-connectors documentation/summaries
Ok, I'm maybe being thick here, but I want to make sure I've got this straight. The idea is that anyone who's clueful enough to search the archives is likely to come across the term AJP14, so it's best to give them a hint (even if term isn't going to mean anything to somebody who just wants to evaluate the current set of connectors) So, to confirm: AJP13 defines marshalling protocols. It also has a command set that uses those marshalling protocols. AJP14 uses the same marshalling protocol as AJP13, but extends the command set. The distinction is important, because in the past major version number changes in AJP meant an entirely new binary protocol. AJP14 is for the future, sometime after the release of jk2. It's still being discussed. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-tomcat-connectors documentation/summaries
The following document is very incomplete, and in many cases factually incorrect. The idea is to post it now, while it's obviously in draft form, get feedback, and then clean it up and publish it wherever would be most useful (jakarta-tomcat connectors page, or the Tomcat FAQ) I'm currently tracking down user-level instructions for all the connector/webserver/container combinations I can find, so pointers to those are especially welcome. I'm not wedded to any of the listing categories, or the format, or pretty much anything else, so if you don't like it, speak up. mod_jserv why it was written: it was there first. where to get the source: java-jserv repository where to get documentation: java-jserv repository unerlying protocol: AJP11 works with: servlet containers: JServ web servers: old versions of Apache httpd operating systems: ??? underlying protocol: AJP11 mod_jk should jk2 be listed out separately? why it was written: originally, clean-up of mod_jserv. status: in production for tomcat 3, 4 where to get the source: jakarta-tomcat-connectors/jk where to get documentation: jakarta-tomcat-connectors/jk tomcat-dev mailing list archives http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk2.html primary developers: evolved from mod_jserv (see above) Gal Shachor, IBM Research, Haifa Lab. refactored mod_jserv many others? works with: servlet containers: jserv? tomcat-3 tomcat-4 web servers: domino apache 1.3 apache 2.0? netscape others? platforms: lots? it's big thing: production use underlying protocol: AJP, see mod_jserv evolution: AJP12, binary AJP13, better SSL support. the current protocol. AJP14, in testing. see comments below. special powers: load balancing with both tomcat 3 and tomcat 4 documentation/mailing-list/cvs comments of interest: Mod_jk v/s mod_webapp on tomcat-dev: Bill Barker wrote: mod_jk2 is the next generation of mod_jk. It is currently barely Alpha quality for Apache 2.x (and still subject to major changes from day-to-day) [EMAIL PROTECTED]: It works ( barely :-) with Apache2.x and 1.3. The connector for apache1.3 can be used as a basis for updating IIS/iPlanet. costin: Mod_jk works on all web servers and with all tomcat versions. Mod_jk2 will do the same. [EMAIL PROTECTED] : What we called ajp14 are a set of new APIs for config, shutdown, MD5 auth - added by Henri. Ajp14 API is not 'released', and the current plan is to postpone it after the first release of jk2 [EMAIL PROTECTED] : it started with ajp11 and ajp12 ( first text based, second binary ). Ajp12 evolved into ajp13 - using same encoding but with some extensions ( to deal with persistent connections ). GOMEZ Henri [EMAIL PROTECTED] : using jk instead of warp depend on webserver you want to have it. If need today, or tomorrow IIS/NES/DOMINO, use mod_jk, if you only need to use Apache 1.3/2.0 and have APR ready, you can use also mod_warp. costin: jk had many developers contributing to it, more than any other tomcat component ( AFAIK ). It's also a matter of evolution - mod_jk started by implementing the ajp12 protocol and beeing backward compatible with mod_jserv ( actually a lot of code has been refactored from it ). You can still use mod_jserv with 3.x, and you can use mod_jk with anything from jserv to tomcat4. webapp you might see the terms mod_webapp, webapp and WARP, being used in a confusingly similiar way, but properly: mod_webapp - the apache module portion of webapp, WARP - the underlying protocol why it was written: uses APR, tight tomcat 4 intergration status: ??? where to get the source: jakarta-tomcat-connectors/webapp where to find documentation: jakarta-tomcat-connectors/webapp http://nagoya.apache.org/~pier/ http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/webapp.html works with: tomcat versions: tomcat-4 others? web servers: apache 1.3 others? operating systems: not windows? underlying protocol: WARP special powers: tight webserver/container integration means simple deployments are very easy primary developers: Pier Fumagalli [EMAIL PROTECTED] others? mailing list/documentation comments: Pier Fumagalli [EMAIL PROTECTED] : I just said that for what matters to me (meaning, for what I use it, it works allright)... That's far
jakarta-tomcat-connectors documentation/summaries
A while back, I responded to Henri Gomez's email: We will create really soon webpages for jakarta-tomcat-connectors with an offer to summarize some of the recent discussion about the various connectors currently available for Tomcat. Not to write new docs, just summarize the existing docs and mailing list dicussions into a page with stuff like: for each connector: pointer to source, any existint docs brief (one line) summary of the idea behind it brief (one line) history underlying protocol, pointers to definition who's working on it stable/development versions of tomcat it works with standalone or front end webserver? which webservers? for each: status popularity ranking pointers to comments about it on mailing lists I need to do the research anyway, in order to decide which connectors to use, so I thought I'd offer to write it up. But ... I made the offer almost a month ago, and I wanted to double check that somebody hadn't gone out and done all the work in the meantime. So: Am I (hopefully :-) too late? Has anyone done this yet? If not, I wanted to get most of it done this weekend. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using InstallAnywhere for Tomcat installer
GOMEZ Henri wrote: I don't refuse anything, just expose that I'd rather like an OSS Java installer. I've recently been pointedly reminded that I'm not even a committer, but as the project guidelines encourage developers to comment and cast a nonbinding vote, I'll put on my flameproof suite and agree that I would prefer an OSS installer if at all possible. Using propriatary code has drawbacks like: - Unless the license is more liberal than I suspect, nobody but official Apache projects will be able to use the installer. Sometimes non-Apache projects do use Apache code, that's sort of half the advantage of being Open Source. Diluting that advantage would be a shame. - Contributing time and $$$ to a project that's being used as an advertisement for a potential competitor (that isn't contributing source code) is troubling. In this case not enough to make me (or probably anyone else) leave, but its annoying. If they want to participate, why don't they make plans to donate source code like everyone else? - If you aren't on the official list of supported platforms, you're hosed. With an OSS solution, a frustrated user of an obscure platform can make it work and then contribute the solution back to the community. - Although perhaps a verboten topic for discussion, there's the whole Open Source thing. Using a commercial installer if Open Source options are available is troubling from a philisophical standpoint. If you really buy into the advantage of Open Source, why dilute those advantages? If there's currently not an OSS solution available, then in the interest of expedience, I withdraw any objections. Which sounds sort of funny since it's nonbinding anyway, but what the heck. (Any personal email on this topic to /dev/null, keep it public please.) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using InstallAnywhere for Tomcat installer
Kevin Grey wrote: So in essence it works on any platform that has a JVM. Nah, it only works fully on officially supported platforms. Which makes sense, because the whole advantage of using a good installer is that it paves over the nasty platform-specific install issues. There's a list at: http://www.zerog.com/products_ia_01.html The key words are Support for nearly every platform. InstallAnywhere is the best for Java apps, regardless of whether its proprietary or not. I won't argue, I've never heard a bad thing said about InstallAnywhere. But totally ignoring ethical issues is a bad long-term strategy. Certainly Tomcat wouldn't exist at all if it weren't for people considering some philisophical issues. Costin's suggestion to try it out in parallel with some of the Open Source options seemed pretty reasonable. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Replacing WebappClassLoader
Volker Leidl wrote:
I tried to configure tomcat 4.0.2 to use my own class loader implementation
for web-app class loading. The documentation implies that this can be done
by secifying a loaderClass attribute in my Context/Loader element in
server.xml.
Loader specifies an org.apache.catalina.Loader object, not an
java.lang.ClassLoader. You'd need to do something like this:
package com.distributopia.mtc;
import java.io.*;
import org.apache.catalina.*;
import org.apache.catalina.loader.*;
public class TestLoader extends WebappLoader {
public TestLoader(ClassLoader parent) {
super(parent);
System.out.println(TestLoader.TestLoader(+parent+));
}
public void setDebug(int debug) {
System.out.println(TestLoader.setDebug(+debug+));
super.setDebug(debug);
}
public void start() throws LifecycleException {
System.out.println(TestLoader.start());
// instead of super.start(), do your own thing here
super.start();
}
}
Compile it, jar it up, copy it over to $TOMCAT_HOME/server/lib,
and you're set. Sort of.
Stepping through the code of org.apache.catalina.loader.WebappLoader (which
i still want to use) I found out that the loaderClass Property does get set,
but it seems to be ignored since
org.apache.catalina.loader.WebappClassLoader gets instantiated explicitly
(line 615-, cvs revision 1.12.2.5).
Is this intended? Perhaps I missed something in the code.
What the example above does is override the start() method. It
just re-dispatches it to the original, but what you'd need to do
is reimplement it to use your classloader, instead of the one
WebAppClassLoader uses.
This does not work.
Actually, neither does my suggestion, at leat not on HEAD. I
could have sworn it used to work, but maybe I just wasn't paying
enough attention to the log messages. Anyway, running the above
I get this:
ServerLifecycleListener: createMBeans: MBeanException
java.lang.Exception: ManagedBean is not found with TestLoader
at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:374)
I'll test further, but first I wanted to get some feedback on
whether I've made some stupid mistake. I kinda sorta half
suspect this is related to the way Tomcat hardcodes all the
MBeans instead of generating them dynamically using reflection,
but I'm very unsure about it.
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Replacing WebappClassLoader
Christopher K. St. John wrote: Loader specifies an org.apache.catalina.Loader object, not an java.lang.ClassLoader. You'd need to do something like this: Ack. You were talking about the loaderClass attribute, not the className attribute. I wasn't paying close enough attention, sorry. But what I suggested is probably still your best bet if you need to get this done without fixing WebappLoader to properly use the classLoader attribute. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: MinTC, terrible rudeness, persistence
Remy Maucherat wrote: It has been developed separately (by you alone), with zero input from the Tomcat community Good grief Remy, it _was_ discussed on tomcat-dev, as a quick search of the archives will show. You're spouting complete BS here, and I wish you wouldn't. You're also obviously confused about what MinTC is. It's all explained on the web page, and would be obvious to anybody who had tried to run the code, but I guess that's a bit much to expect. This is partially my fault for originally naming it MinimalTomcat. In retrospect, knowing more about the awful destructive politics on this list, the name choice was a terrible mistake. MinTC IS NOT a complete-but-minimal replacement for org.apache.catalina.core, ok? If you want to rant about MinTC, I'd appreciate it if your rants were correct in the details. So go read the web page, check the archives, take a look at the code, and _then_ come back and tell me I'm an anti-community idiot with stupid ideas, ok? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: MinTC, terrible rudeness, persistence
[EMAIL PROTECTED] wrote: The point is not about developing multiple implementations - but about beeing a part of the community and proposing/discussing changes instead of posting announcements of a fork's releases. Costin, My response got to be way too long, so here's just a summary. It comes off as a bit clipped, but that's because it's short, not because the questions were unreasonable :-) - I did discuss MinTC/MinimalTomcat on the dev list, check the archives. The topic didn't seem very popular, but I took that to mean I had weird requirements that few others shared. Later on, I started making announcements as a way to generate discussion and keep the core developers up-to-date. - It's not a fork. If it were a fork, I wouldn't care about the core code. But it's not, so I do. It's not Tomcat 4, but it is, by any reasonable definition, a version of Catalina. - It was always my intention to propose donating the code back to Apache, I should have been more clear about this. But I wanted to wait for the 1.0 release, for obvious reasons. - MinTC is not competition for Tomcat. You would have to be frigging insane to use MinTC if you could possibly use Tomcat 4 instead. But sometimes Tomcat 4 is difficult or impossible to use. That's not because Tomcat 4 is bad, it's just that it's full featured. I didn't think a patch to remove MBeans, JNDI and auto-deployment from the core would be well received :-) If you're interested, there's more detail on the MinTC page. Thanks for your feedback, -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
MinTC/Tomcat 4/Catalina. Conflict? No.
GOMEZ Henri wrote: I don't consider me a Tomcat 4.0 core committer, but that patch would have my biggest +1 on Earth! :) but a lighter TC 4.x will have my +1 and the current TC 4.0.x 'LE' mode is allready a good step in that direction. Ok, time to change the subject line. I know this isn't what you all were talking about, but I'm worried it could be confusing for those who haven't followed the whole thread: MinTC is an insanely special-purpose container. Despite the name, it isn't really a minimal-version of Tomcat 4, it's something different (see the MinTC web page for details). That's one reason I changed the name from MinimalTomcat to MinTC. Maybe the change wasn't big enough. It's open source, and I will certainly provide help to anyone who wants to do other stuff with it, but my personal focus is on one or two very specific kinds of usage. If things learned while developing MinTC turn out to be useful for the next version of Tomcat, that would be really cool, but I personally want to concentrate on keeping MinTC in its (comfortable little) niche. Again: It's open source, I'm open to suggestions on other uses, but my personal focus is very specific. Thanks for all the feedback. Even the negative stuff is good (as long as it isn't so bizarrely rude and contemptuous that I can't read it with a clear head!) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: MinTC, terrible rudeness, persistence
Skip ahead to the substantive-discussion section if you're bored with the other topics in this thread. [EMAIL PROTECTED] wrote: But what you are doing is a fork by all definitions that I know. It's an alternative implementation of some of the Catalina interfaces, but it's clearly not a fork. I'm using this as a working definition: A fork refers to what you do in a revision control system when you want to work independently on two versions of the same code. By extension, on Open Source projects it means taking a copy of the code base and making your own copy that isn't kept synchronized with the mainline branch. MinTC steals a little bit of code from some of the o.a.c.core classes, but it doesn't copy any of them. What it uses of the Catalina code, it uses completely intact (I'm currently tracking CVS HEAD). So it's not a fork. Forks suck. Alternative API implementations, on the other hand, are generally considered a good thing. Some spec processes even require them! You must at least try first. I did. Don't take my word for it, it's in the archives. substantive-discussion I rejected the idea not because it was met with hostility (I got good feedback), but because the discussion (on tomcat-dev) convinced me that it was not the right technical solution. It comes down to the fact that totally generic code has some rather extreme practical drawbacks. The classes within o.a.c.core,for example, need to be able to depend to some degree on each other's innards. As Craig said: Within a particular package (org.apache.catalina.core), I don't see a problem with the classes depending on each other's insides -- the package as a whole is designed, as a unit, to provide the required functionality for that package. o.a.c.core's required functionality is simply very different than that of MinTC. MinTC has such a different audience that it didn't seem reasonable to saddle Tomcat 4 with MinTC's requirements. Integrating the two would require that every last bit of functionality was somehow modularized out of Tomcat 4 core, and that's undesirable. It's like making a combination jackhammer and framing hammer just because they both have the word hammer in their name. Sure, you could do it, but it would be silly. Right tool for the right job, and all that. The whole write very specific tools but make them interoperate thing (The Unix Philosophy) isn't for everyone. Some people prefer other approaches, like extreme factoring and adding loads of hooks. It's all good. Knowing MinTC is a Unix-philosophy sort of project might make it easier to understand where I'm going with it. /substantive-discussion Again, the feedback is good. It all helps, especially the architecture discussion, even if it's negative. (Although I can't help but wish some of the people commenting now would have piped up earlier :-) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANN] MinTC 0.6 Alpha It's JSP-alicious
Big news for this release: initial JSP support, a sucessful test of MinTC running a simple Apache XML-RPC demo, and confirmation that MinTC will run on a Sharp Zaurus. Watchdog results: 345 TEST(S) PASSED! 3 TEST(S) FAILED!. This should be the last alpha. Check it out at: http://www.distributopia.com MinTC is sort of a bizarro-world Catalina implementation. Instead of being maxed out with features, it's small and special-purpose. It requires no local file system access, and can execute servlets and serve static content from within its jar. Think web-enabling an application's admin interface, or packaging a webapp as a zero-installation standalone application. MinTC is good for Tomcat 4 because it keeps the Catalina interfaces honest. If you're a Tomcat 4 developer it's probably worth a look just to see other implementation options. MinTC is hard to compile, and probably will remain that way until fairly late in the beta release cycle. If your webapp runs with Tomcat 4, and you'd like to see if it runs under MinTC, then drop me an email and we'll see about getting you a special build. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
MinTC, terrible rudeness, persistence
I've been informed by private email that I am terribly rude for making announcements of MinTC releases on the tomcat-dev list, and that I should not make any futher announcements. So that's it then? I've been kicked off tomcat-dev (how does that work on an open source project!?) because I've offended someone by writing code they don't like!?!? This is a bit of a problem for me, as MinTC is, technically, a version of Catalina, and should be a perfectly appropriate topic for tomcat-dev. Especially when it's one message every few weeks. MinTC is certainly not a mainline version of Tomcat 4, but it shares a significant amount of (unforked) code, and that makes it important to seek a close relationship with the people maintaining the codebase. It's a bit like sharing a telephone booth with an 800 lb gorilla: it's a bit much to hope to have any influence over what phone calls are made, but at least you can hope to make your presence know so that you don't get sat on. It's a dilemma: there's no point in having an antagonistic relationship with the core Tomcat developers, that's worse than nothing. But good grief! This is an opensource project! MinTC is a version of Catalina, where the heck else am I going to discuss it? I'm contributing bug fixes and code back to the core implementation, I'm helping to clean up the core interfaces, I'm using the Catalina code, I'm doing documentation work, but I'm not welcome? That seems so strange, and so sad. I'd like to get some feedback from someone other than the person who wrote me privately. Craig? Could you give me an opinion please? You seem to have the moral leadership role here. Anybody else, please chime in. I'm horrified that I might have been being unknowingly rude, but I'm at a loss to explain how exactly I've caused such awful offense. I honestly don't get it. Thanks, and please, as you think about your response, keep in mind that the Catalina proposal docs specifically talk about people doing exactly what MinTC does under the Catalina umbrella. Thanks, and sorry for any inadvertant rudeness, -cks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pandora's box / can of worms etc.
Paul Wallace wrote: What is MinTC? Where can I get information on it? So as not to add flames to the fire, I'm replying privately :-) http://www.distributopia.com/ It's sort of a bizarro world Tomcat. It takes the Catalina interfaces (Container,Connector,Valve,all the stuff in the org.apache.catalina package) and reimplements it for use in embedded (as in embedded-in-your-application, not embedded in-your-toaster) environments. It's substantially smaller, but it gets that by having substantially fewer features than Tomcat 4. It's in alpha. And I mean serious, dirt-under-your-fingernails after-you-compile-it-if-it-even-compiles alpha. But it's a lot of fun, and you should check it out (it's got an Apache-style license, Open Source, etc, etc) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pandora's box / can of worms etc.
Sh*t. That was supposed to be private, I wasn't trying to be cute. Apologies. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: MinTC, terrible rudeness, persistence
Craig R. McClanahan wrote: a discussion of whether you'd want to propose contributing MinTC to the standard distribution (so that it could be built from the same source repository, and probably packaged separately) -- either now or when you get a little further along at complete success in passing all the tests. I was planning to bring it up after version 1.0 was out. That makes it easier to judge the code. And, to be honest, until a couple days ago I wasn't really sure MinTC could be made fully spec compliant. Multiple classloaders hitting the same jar is kind of funky around the edges (especially on bleeping PJAE, which has the crazy 1.1 classloaders will not expose .class files through getResource() restriction. They'll give you .clazz files, though evil cackle) I was thinking something like a contrib directory might be neat, but that's getting a little ahead of things. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
o.a.c.startup.EngineConfig doesn't do anything?
I can't figure out what EngineConfig is for. It doesn't appear to do anything at all. The docs say it configures the properties of the engine and the associated defined contexts. But it doesn't. Craig? You and Pier are the only people to have touched this, and Pier just re-indented. I know it seems trivial, but dead code (that's getting maintained!) is evil. Especially when it's something as confusing as Catalina startup code. The alternative is that I'm wrong, and it is used for something. In that case, the comments should be better. I'm willing to either patch it out (should just be EngineRuleSet), or write some better comments, either way. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Corrupted Ouput - Tomcat 4.0.3
Remy Maucherat wrote: There seems to be a bug in the servlet output. Tomcat 4 does not corrupt images, binaries, or anything like that. This has been proven on and on by many people using it (like myself) on various websites. That logic doesn't work. The fact that it works for some people, even the vast majority of people, is no proof at all that it works for everyone. Claude Montpetit wrote: I may try to play with this to prove myself that the problem is in my network (clues on how to change output buffer size on V3 and V4 would be appreciated). If you have a network analyzer (like ethereal) you might want to try to get a dump of the actual IP packets. Sometimes jumping down to the lowest possible level is easier than trying to debug things from the top down. This thread might be better over on tomcat-users, or if you're actively working on it, you might try the #tomcat channel on irc.openprojects.net. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4 target JDK is 1.2? but ShutdownHook is 1.3?
cvs HEAD o.a.c.startup.Catalina has a Runtime.addShutdownHook() call, but ShutdownHooks are a 1.3 thing. I was assuming (based on the website docs) that 4.1 was supposed to be JDK 1.2+. Is that incorrect? Is JDK 1.3 the target? In an amusing (and perhaps useless) twist, MinTC (embeddable servlet container based on the Tomcat 4 architecture) now appears to run under PersonalJava. PJ is a 1.1.8 variant (it has Collections classes, plus some other stuff). Catalina based servers expand to cover the entire gamut? Java Card anyone? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Small fix for StandardServer ctr
o.a.c.core.StandardServer's ctr calls super(), but the class does not extend anything. The call is legal, but misleading. The following patch removes it. The patch is against HEAD, but it's also an issue in 4.0.x. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com stdsrvctr.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANN] MinTC 0.5 Alpha It Wants to be Your Friend
MinTC needs adventurous testers. http://www.distributopia.com Changes for 0.5 include: Initial support for error pages, better support for RequestDispatcher, more testing with J2ME/CDC, a start on supporting precompiled jsp's, and general cleanup. Watchdog conformance testing results: 342 TEST(S) PASSED! 6 TEST(S) FAILED! MinTC is a special-purpose servlet container designed to run from inside your application's jar file. It requires no local file system access, and can execute servlets and serve static content from within the jar. It's ideal for web-enabling an application's admin interface, or for packaging a webapp as a standalone application. MinTC is cool because it uses XSLT to transform web.xml and server.xml into startup and initialization code. MinTC makes use of framework classes from Tomcat 4, and is released under an Apache-style Open Source license. Note that MinTC is still in alpha, so it's a little early to be using it for production work. Testers are very welcome, however. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANN] MinimalTomcat Alpha 0.4 Small Container, Big Attitude
MinTC used to be MinimalTomcat, but MinTC is shorter. http://www.distributopia.com/servlet_stuff/catalina_mtc.html New DefaultServlet implementation allows serving files from within the jar. Now runs under IBM's J2ME/CDC environment (see website for details). Many more Watchdog tests passed: 333 TEST(S) PASSED! 15 TEST(S) FAILED! MinTC is a special-purpose servlet container designed to be embedded within distributed applications. It's meant to have a very small footprint, both in the size of its classfiles, and in its resource usage. It can be deployed along with all your webapp classes and content as a single executable jar. MinTC is built with framework code from Catalina (Tomcat 4), but uses alternate implementations of the core Catalina interfaces. This is an alpha release for developers, MinimalTomcat is not ready for production use. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardPipeline.java
Arvind Srinivasan wrote: I think the performance related change that you made to StandardPipeline can be improved upon in that it can avoid using a HashMap to store/retrieve the pipeline stage and instead simply store/retrieve it from an integer variable in the RequestBase class. Since this codepath (StandardPipeline.invokeNext) is executed many times per request, replacing the request.getNote() call with something like request.getPipelineStage() will benefit performance. I've attached a patch that implements this suggestion. The obvious implementation is to have have ValveContext hold the index. That's how I assumed it worked the first time I saw the Pipeline, Valve and ValveContext classes. I was suprised to see a ThreadLocal. Using ValveContext has the appropriate threading semantics, and it avoids hiding the index in a mystery attribute in the Request. And, (although none of this will result in a measurable performance gain) using ValveContext to hold the index should be faster, since it avoids a hashtable lookup. Using a Request note is much like using a global variable: it's hidden state. Long term that's bad, for obvious reasons. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardPipeline.java
Arvind Srinivasan wrote:
Christopher St. John wrote:
The obvious implementation is to have have ValveContext hold
the index.
But isn't a ValveContext (Pipeline) shared across requests ?
It's shouldn't be, but it is now. StandardPipeline
implements VavleContext, but there's no particular reason
to do it that way.
I think the stage has to be maintained in the Request object.
No, definitely not. Here's how MinTC (MinimalTomcat) does
it (this is alpha code, and I've deleted some of the methods
to keep the size down):
public class MinimalPipeline implements Pipeline {
class MinimalValveContext implements ValveContext {
protected int pos = 0;
public void invokeNext(Request req, Response rsp)
throws IOException, ServletException
{
Valve v = null;
if (pos == valves.size())
v = basicValve;
else
v = (Valve)valves.elementAt(pos++);
if (v!=null)
v.invoke(req, rsp, this);
}
}
protected Valve basicValve = null;
protected Vector valves = new Vector();
protected Valve[] valve_array = null;
protected Container container = null;
public void invoke(Request req, Response rsp)
throws IOException, ServletException
{
MinimalValveContext ctx = new MinimalValveContext();
ctx.invokeNext(req, rsp);
}
}
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Remy Maucherat wrote: Adding another CL layer is dangerous and makes CL slower; unless other people think this is useful I don't think we should add the feature) Another option is to use the manifest version tags to identify which versions of the servletapi (and other sensitive classes) are being used, and print out an error message if they don't match what Tomcat requires. Patrick Luby wrote: My first concern is that Tomcat always can at least run no matter what extensions that user has installed. Whether or not those extensions are accessible to Tomcat is, IMHO, a feature that we may or may not want to include. Quitely dropping extensions that the user has installed is unintuitve, and in some ways worse than the current situation. Perhaps a combination? Normal behavior is to check api versions, exit if they don't match. Fallback if it's impossible to remove the extensions is to use the java.ext.dirs= hack? That lets a user get Tomcat running no matter what, but with full awareness of the tradeoff. Either way, the current situation is a problem for many people, as can be seen by a quick scan of the tomcat-users list. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANN] MinimalTomcat Alpha 0.3 It's got moxie!
http://www.distributopia.com/servlet_stuff/catalina_mtc.html Includes a new single jar configuration. An entire servlet container, with all dependencies and webapps, can be packaged into and run from one small jar. Updated Watchdog spec conformance report: 217 TEST(S) PASSED! 131 TEST(S) FAILED! MinimalTomcat is a special-purpose servlet container designed to be embedded within distributed applications. It's meant to have a very small footprint, both in the size of its classfiles, and in its resources usage. It's built with framework code from Catalina (Tomcat 4), but uses alternate implementations of the core Catalina interfaces. This is an alpha release for developers, MinimalTomcat is not ready for production use. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: servlet.jar, /ext, MANIFEST.MF
Patrick Luby wrote: we can put -Djava.ext.dirs= as an argument in the Tomcat scripts. This argument causes the JVM to ignore any jars in its jre/lib/ext directory ... But wouldn't that mean that legitimate exetensions were ignored? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: servlet.jar, /ext, MANIFEST.MF
Patrick Luby wrote: Christopher K. St. John wrote: But wouldn't that mean that legitimate exetensions were ignored? Yes, they would be ignored. That seems a bit hostile. The majority of stuff that could go into /ext is harmless. Ignoring it punishes users who correctly install the right extensions. My proposal was based on idea that if you can't solve a hard-to-diagnose problem, you ought to at least make it obvious. I'd be worried that ignoring /ext solves one such problem but replaces it with another. jakarta-servletapi-4 packages ought to have version info in any case. jakarta-tomcat-connector packages already do. Is there a maintainer for the servletapi stuff? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: servlet.jar, /ext, MANIFEST.MF
Patrick Luby wrote: I can't help but think that there might be a way to point Tomcat to its bundled jars without losing access to any non-conflicting extensions. That would be better. (but the servletapi still should have the appropriate version info :-) ... have the class loaders in Bootstrap.java add the jars in the JVM's jre/lib/ext directory to the end of its search list. Hmm. To match the spec, I think there would need to be a new classloader on top of all of those. Something like: ExtClassLoader (pithed) | AppClassLoader (as normal) | Catalina /ext (new: loads /ext classes) | Common(as normal) ... Which means that stuff loaded from the classpath won't have access to extensions, so that's still not quite right. Since Tomcat closely controls what's on the classpath I'm not sure how much of an issues that is, but it's definitely a bit different than normal. I'd settle for just having Tomcat print an error message if there was a conflict, but if the classloader hacks can be made to work that would obviously be better. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
servlet.jar, /ext, MANIFEST.MF
The JDK documentation indicates that servlet.jar, as an official optional package, should be placed in the /lib/ext directory. [1] However, the Tomcat 4 documentation (well, the mailing list) indicates that servlet.jar should not be placed in /lib/ext. [2] Catalina should be able to detect problems using java.lang.Package methods to query the version of the provided javax.servlet packages. It looks like this would require: 1) jakara-servletapi-4 to provide a manifest with the appropriate version information. 2) Catalina to check the version information at some point, perhaps optionally. Is this a reasonable thing to do? I admit to a cosiderable amount of confusion over the balance between theory [3],[4],[5] and practice. Any feedback/clarification greatly appreciated. [1] http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html 4th paragraph of the Introduction uses servlet.jar as an example of something that definitely belongs in /ext. I'm not trying to argue about it, I'm just pointing out that the documentation conflicts with common practice. I've gotten into arguments with people who insist it's ok because of the extensions spec says, specifically, that it is. [2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5523, ref Additional Comments, also: http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg15098.html ref para starting TOMCAT-USER gets 10 or so messages a week. [3] http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html [4] http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html [5] SRV.9.7.1 Dependencies On Extensions. Yes, I know, it isn't quite the same thing. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANNOUNCE] MinimalTomcat Alpha 0.2
MinimalTomcat is a special-purpose servlet container designed to be embedded within distributed applications. It's meant to have a very small footprint, both in the size of its classfiles, and in its resources usage. It's built with framework code from Catalina (Tomcat 4), but uses alternate implementations of the core Catalina interfaces. This second alpha release includes a deployment tool that uses an XSLT transformation to convert web.xml directly into Java source code that does the equivalent series of initialization calls. Also included is a Jakarta Watchdog conformance report: 207 TEST(S) PASSED! 141 TEST(S) FAILED! You've been warned. It is available at: http://www.distributopia.com/servlet_stuff/catalina_mtc.html MinimalTomcat requires a full installation of Catalina. It has only guaranteed to work with the latest from CVS. Feedback about the build and install process is especially appreciated. Thanks. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: problem with catalina for 'non-web' application
Pier Fumagalli wrote: Jerome Bouat [EMAIL PROTECTED] wrote: What is wrong ? That tomcat is an web-application container, so, if you want to do something different, you're on your own, you shouldn't be using Tomcat... This comment puzzles me. It's generally a very good thing when people want to use your code, and it's especially good when they want to use it for something the original authors never thought of. Of course, that isn't really the case here. Tomcat 4 was (at least according to the original proposal) intended for this sort of thing. Since most of the current set of developers don't want to use it that way, it's perfectly fair to tell people they're on their own. They've got the source, right? If somebody wants something, they can implement it themselves. But to tell them Don't use Tomcat gives them a (hopefully) very wrong impression. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Running tomcat as an embedded servlet engine
WATKINS, Andy, FM wrote: Has anyone else tried to do this (run an embedded servlet engine without swathes of configuration files)? Yes, although I suspect you're looking for something a little different than what I needed. You might check out: http://www.distributopia.com/servlet_stuff/catalina_mtc.html It's not ready for prime time, but it might give you some ideas. I can't seem to find it right now, but somewhere I've got an example of using regular-old Catalina completely without config files. It was what I was trying to use before MinimalTomcat. You can do it, but it's fighting against the tide, I don't really suggest it. (Email me privately and I'll try to find the code) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How To Add a Scheduler Program Working With A Webapp In Tomcat?
Rock Luiss wrote: The scheduler program start to run when tomcat start,and exit when tomcat stop.The scheduler can send email and maintenance data in the DB. The scheduler must access other classes in the webapp. When you say must access other classes in the webapp, what do you mean exactly? Would it be enough to have a Scheduler Service that could make a normal request to the servlet at prescheduled times? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Custom Realm implementations
Dettling, Ingo wrote: Do you see a chance to make GenericPrincipal a public class in the next release? It's public in 4.0.3. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Etiquette, MinimalTomcat, Bug 6670
Craig R. McClanahan wrote: On 1 Mar 2002, Christopher K.St.John wrote: I'm stuck, and not sure how to proceed. MinimalTomcat really needs AuthenticatorBase to be core-clean. It should be pretty easy to change this particular use of StandardContext to use reflection instead. Got the new version from CVS, it works for me, thanks Craig. I'm constrained at the moment by product requirments on my day job My assumption was that if I'm complaining about it, I ought to be providing patches. In the mean time, persistence is good. :-) Speaking of persistence, what are Context.*RoleMapping() for? They look to be unused duplicates of Context.*SecurityRole() methods. I've stubbed them out in MinimalTomcat, but it's unsettling to not know what they're used for. Does anybody use them? If so, what for? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Etiquette, MinimalTomcat, Bug 6670
I'm stuck, and not sure how to proceed. MinimalTomcat really needs AuthenticatorBase to be core-clean. It may be that this is an unrealistic requirement, and it's impossible to make any use of o.a.c.Authenticator package outside of o.a.c.core.*. That would be a shame, but, as they say, you can't fight city hall. But my reading of Craig McClanahan's posting on the subject was that I should, in theory, be able to make use of the Authenticator classes. There may be practical difficulties (like the one reported in Bug 6670), but those difficulties are flaws that are a legitimate target for fixes. Here are my etiquette questions: (1) What's the deal with request for enhancement? I read this as blackhole, but I'm honestly not sure. (2) Can I change this back to being a bug? Or is that an abuse of bugzilla? (3) Is bringing up the topic in email after email until I get a response considered (a) legitimate lobbying for an important issue that affects a minority of developers and is thus overlooked, or (b) spamming. Thanks, -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Craig R. McClanahan wrote: Internal references from one package to another (say, org.apache.catalina.realm to org.apache.catalina.core) are much less desireable. ... Is it appropriate to go through the exercise of identifying the offending cases and defining proposed changes to implement them? Yah, it's definitely time for that to happen. Currently, AuthenticatorBase depends on StandardContext. It's not some deep dependency. AuthenticatorBase just wants to set its debug level to be the same as its Context. There's an instanceof check before the cast, so AuthenticatorBase doesn't actually require that its parent be a StandardContext, but it does require that StandardContext exists. It produces a 'mystery dependency' that is invisible from the outside. I may be preaching to the converted, but mystery dependencies are bad. They make the code brittle and hard to understand. They lead to spaghetti. I reported the dependency as a bug (with a patch) and the bug was changed to a feature request. I suppose it depends on how you look at it. It's certainly a bug for me. There are a couple of ways to fix the problem: 1) Delete the offending code. Easiest, and in this case probably reasonable. You'll lose the debug-setting propagation, but you can always set that manually. It's for debugging so presumably you're messing with the settings any case. My patch did this, I'd like to see it applied. 2) Move setDebug() up to the Context or Container level. They all implement setDebug() anyway, right? And it doesn't break compatibility with old code. Med/long term, this would probably be a good solution. 3) Create a Debug interface. Pretty much everything in Catalina has set/getDebug() methods, not just Containers. But it's overkill. Each new class or interface adds conceptual overhead to the system. I don't think it's worth it. Whether you like the idea of something like MimimalTomcat or not, I suspect writing it will turn up some problems (and solutions) that will improve all of the Catalina code. While we're on the subject of interfaces, what is Context.findRoleMapping() for? I've got it stubbed out in MinimalTomcat, but I'd like to know what I'm stubbing out. It used to be used in HttpRequestBase.isUserInRole(), but the call was replaced by a call to Context.findSecurityRole(). -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
o.a.c.Context.*RoleMapping() ?
I can't find anyplace that that these routines from Context are used: public void addRoleMapping(String role, String link) public String findRoleMapping(String role) public void removeRoleMapping(String role) A grep through the dev archives shows that they used to be used in HttpRequestBase.isUserInRole(), but were removed and replaced with some similiar code that uses the Conext SecurityRole routines instead (see below for cvs notification). I get the security-role-ref/*SecurityRole() thing. Are the *RoleMapping() methods still used? If so, any hints as to how and where? --88-- craigmcc01/03/26 12:02:17 Modified:catalina/src/share/org/apache/catalina/connector HttpRequestBase.java Log: Correct the implementation of HttpServletRequest.isUserInRole() so that it properly respects role name aliases defined with security-role-ref. PR: Bugzilla #1086 Submitted by: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
MinimalTomcat code
In any case, tomorrow I'll whip up a sourceball of the current MinimalTomcat code and stick it out on the net somewhere. http://www.distributopia.com/servlet_stuff/mtc-0_1.tar.bz2 It's a bzipped tar file. If you've just got to have a zip, email me. The directions assume you've got a copy of Tomcat 4 built from source. If you're not the kind of person who builds Tomcat from source, you probably won't be interested in this code. The code is alpha, and has never been tried outside my build environment. The included demo webapp uses basic authentication. The user is scott, the password is tomcat. I'd appreciate feedback. Good luck. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
I posted to the dev list earlier about needing a small, relatively lightweight version of Catalina to embed into another program. I spent the weekend putting together something that more of less fits my needs. (My needs include a relatively small jar, plus no use of the local file system) I ended up with a 260k jarfile of the catalina classes, plus another 75k or so of new Container classes. I suspect there's at least another 100k that can be trimmed. I ran into a troubling amount of coupling between the various bits of Catalina. The o.a.catalina.* classes were fairly clean, but the implementation classes tended to know a lot about each other. That made reuse difficult, since inheriting from one of the core classes ended up bringing in pretty much every class (and external dependency) in Catalina. The implementation classes obviously need to know something about each other, but there are an awful lot of hardcoded assumptions. The large number of casts makes it very hard to figure out what depends on what. Instead of trying to make the core classes more generic, I ended up writing a new set of Containers and support classes. Using the existing Catalina code made that fairly easy, but much of the code re-use was necessarily of the cut-and-paste variety. There were a couple of especially inconvenient couplings that are probably worth fixing, one trivial and one a little more serious. I've submitted both of these as bugs. First, there's an uneeded import of org.xml.sax.AttributeList in o.a.c.realm.RealmBase. That one's not such a big deal since it doesn't matter at run time. The first of the attached patches removes it. Second, there's a cast to StandardContext in AuthenticatorBase. The cast is needed because AuthenticatorBase wants to use the same debug level as its associated Context, but Container doesn't expose the any set/getDebug methods. It would be good to get rid of the cast because it's the only place that BasicAuthenticator makes assumptions about the exact type of its Context. The second patch just gets rid of the StandardContext import and cast. A better solution might be to move set/getDebug up into Container. Adding a Debug interface would work too, but that seems like overkill. The MinimalTomcat code is definitely alpha quality, and it's only meant to support the particular subset of Catalina that I happen to need right at the moment. It is not, and is not intended to be, a complete reimplementation of the Catalina core classes. On the other hand, it's substantially smaller and less complicated, while retaining the same basic architecture. If anyone's interested, feel free to email me at the address below, or respond on the list. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com AuthBaseCast.patch Description: Binary data RealmBaseImport.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Aaron Smuts wrote: I'm very interested. We should call it HouseCat. I'd like to find a home for it if it doesn't fit into tomcat. I detest housecats, but I suppose that's not really the point :-) I'm not sure my is generally useful. The basic approach probably is, but maybe not the code. I personally don't really need all the run-time event stuff (not the servlet-spec events, the Catalina internal events). I don't need JSP. I don't need run-time parsing of the config server.xml and web.xml files. I don't need the full-on security architecture (so I don't need facades and I don't need SecurityManager code). I don't need (but kinda want) the JMX management interfaces. Etc. The code I've written is only useful if you're eliminating the exact same set of things I am. Otherwise, you bloat out until you're full-on Catalina again. (OTOH, projects like Galeon managed to find generally useful subsets of Mozilla, so there's an existence proof that such a thing is possible.) But if I'm the only one use Catalina as a framework instead of as a monolithic servlet container, it isn't going to work. There's too much pressure on developers to 'cheat' and tightly couple all the implementation classes. It's just easier that way. Right now, MinimalTomcat basically can't use anything within o.a.catalina.core, but eventually all the packages will be tightly linked unless there's some sort of incentive not to. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Aaron Smuts wrote: What I'd like would be a Jakarta version of something small and simple like the oldest available Jetty version. I'll take a look. Sounds like you'll have trouble when the parent package changes. You need something new and separate. Well, the org.apache.catalina package is fairly clean, and gives the impression that it will stay that way. It does depend on o.a.c.deploy, but those are mostly little struct-like utility classes for use during Digestion. It's classes like StandardWrapper that worry me. It comes very close to being generic, but has a hardcoded cast of its Context to StandardContext. It looks an awful lot like the cast was introduced during the addition of Filters in order to avoid an api change to the Context interface. Coupling StandardWrapper to StandardContext isn't necessarily unreasonable, especially if StandardWrapper was never meant to be used outside the whole StandardEngine/Host/Context/Wrapper setup, but it does signal that the Catalina core classes are not meant to be used outside the normal Catalina channels. I'm worried that the same sort of thing will happen with, for example, the realm and authorization packages. If it does, there's really no point in having MinimalTomcat use any of the Catalina classes at all except through cut and paste. Can one of the Catalina architects (Craig?) comment? Is it reasonable to try to use Catalina as a framework like that? Or am I swimming against the tide? In any case, tomorrow I'll whip up a sourceball of the current MinimalTomcat code and stick it out on the net somewhere. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Remy Maucherat wrote: Well, it's not that I want to advocate the competition, but it seems to me that Tomcat 3 is more useful for a MiniTomcat, mainly because it requires only JDK 1.1 (smaller JDK; J2ME is based on JDK 1.1, so maybe it could end up being a target; that was one of Costin's pet projects, actually). For my purposes, it's ok to assume 1.2, so that's not an issue. If Tomcat 4 isn't meant to be used like I'm using it, then I don't really understand the point of the generic interfaces in o.a.catalina. If StandardContext is the only possible Context implementation, what's the justification for a generic Context interface? The current architecture requires an awful lot of casts, and if the only configuration allowed is: StandardEngine/StandardHost/StandardContext/StandardWrapper then most of them are unnessary. What's the point of going through hoops with the generic interfaces if you know the exact types in advance? I understand that project goals can change, but the design of the apis (not to mention the javadocs) do seem to strongly imply that something like MinimalTomcat should be legit. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
o.a.c.mbeans.*
It looks like the current mbeans code is mostly boilerplate. Is there a technical problem with using the information from mbeans-descriptors.xml to create dynamic mbeans that don't require hand-coded mbeans wrappers? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Bug 6592: hostjdoc.patch
-- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com hostjdoc.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: o.a.c.mbeans.*
Craig R. McClanahan wrote: It looks like the current mbeans code is mostly boilerplate. In what respect? Well, taking StandardHostMBean as an example, many of the methods take a String argument, convert it to an ObjectName, get the underlying object using getAttribute(), and then call the actual operation on the wrapped Catalina objects. That can all be done using introspection and the info in mbeans-descriptors.xml. I think the other methods could be similarly automated. Note that I'm clear that the normal JMX mechanisms do not provide this. RequiredModelMBean is a start, but there would need to be extra code to do the mappings between Strings, ObjectNames, and Objects. I'm suggesting that that code is for the most part boilerplate, and there's enough information available through introspection and the modeler Registry to implement a completely generic Catalina MBean that could be used in place of many/most of the existing hand-coded Catalina MBeans. Consider the following method on the o.a.c.UserDatabase interface: public Iterator getUsers(); You're right, automatically converting between the version of getUsers() that returns an Iterator and the version that returns a String[] would take an overly clever mechanism. MemoryUserDatabase MBean would be hard to get rid of. But it looks like most of the objects that need to be managed already use easy-to-recognize bean patterns for their interfaces. I'm pretty sure StandardHostMBean, for example, could be entirely eliminated. It matters in general because it adds an extra burden to Catalina developers to have to write a new hand-coded MBean every time they want to add a new kind of object. I suspect most people won't bother, especially if it's an in-house sort of thing. That still leaves the issue of adding entries to mbeans-descriptors.xml, and possibly having to rewrite parts of the admin webapp, but every little bit helps. I care because I'm trying looking at hacking up a debloated (excuse me, slimmed down :-) configuration of Catalina for use inside a tool I'm writing. Although there's a good chance there wouldn't be room for JMX, I'd like to maintain as much compatibility as possible with the standard Catalina tools. That's easy if MBeans are automagically created for me... -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Java home autodiscovery add-on
GOMEZ Henri wrote: What about adding this part in tomcat.sh (TC 3.3) and catalina.sh/jasper.sh to help them discover JAVA_HOME on at least Linux systems ? If someone forgets to set JAVA_HOME and has multiple JDK's installed, they could get a suprise. I suspect most non-beginners would rather see an error message than be suprised. I ran into this problem with a configure script that tried to be too smart about finding a JDK to use. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Java home autodiscovery add-on
GOMEZ Henri wrote: What about adding this part in tomcat.sh (TC 3.3) and catalina.sh/jasper.sh to help them discover JAVA_HOME on at least Linux systems ? If someone forgets to set JAVA_HOME and has multiple JDK's installed, they could get a suprise. That's why you could still tune the JAVA_HOME is tomcat_cfg which is read at start of script (not shown here). You're presumably trying to reduce configuration problems for beginners, but trying to find JAVA_HOME automatically is likely to increase overall confusion. Current situation: beginner (or forgetful expert) doesn't have JAVA_HOME set, trys to start catalina, gets an error message, sets JAVA_HOME, everything is fine. New situation: beginner (or forgetful expert) doesn't have JAVA_HOME set, trys to start catalina, and catalina starts. Either: 1) You got lucky, the script found the right JDK, the code runs for the moment, and the user thinks everything is ok. Until they install another JDK and suddenly catalina stops working. The user is confused. 2) You don't get lucky, the script finds and silently runs with the wrong JDK, and the user is confused. As I said, I ran into this problem with a ./configure script that was too smart for its own good. It caused more problems than it fixed. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Java home autodiscovery add-on
GOMEZ Henri wrote: Did you take a look at my scripts ? I thought I did, although I concentrated on the proposed changes to catalina.sh. This config stuff came from discution on this this list with Keith Irwin and Nicolas Mailhot :) It looks like I missed some background discussion, but the tomcat-dev archives at metronet appear to be out of date, and google didn't turn up anything. If this has all been gone over in detail before, then a pointer to a copy of the thread in the archives would probably shut me up. I was assuming: - An rpm installation would set up a series of scripts in the appropriate LSB-compliant directories. One of those scripts would be tomcat4. A user wanting to start Catalina would run tomcat4 (or put it in their rc directories to be started automatically) - A non-rpm installation would still be started by running bin/catalina.sh, just like before. This would be typical of a developer just getting started with Tomcat. So experienced and beginner will JUST have to : - Comment JAVA_HOME=/opt/IBMJava2-13 in config file for auto-exploration - Set JAVA_HOME in config file to specify WHICH JVM they want to be used with Tomcat3 (and since TC 4 use another config file, it could be used at the same time with the same or a different JVM). But that's only if you're running using a full-on RPM based installation? I doesn't really matter, though. My objection is based on the principle of least suprise, which in this case means that an installation that works should not suddenly stop working because of an unrelated change to another part of the system. If the answer is it's unwise to run with auto-discovery turned on, then why have it at all? Systems that need to run totally without configuration (from a cdrom?) would presumably need custom configuration scripts in any case. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
NanoCatalina
I'd like to embed Catalina in a distributed tool that uses servlets for its admin interface. I'm currently using a very small hand-rolled 'container' that supports just enough of the servlet spec to handle my current crop of servlets. o.a.c.s.Embedded is a start, but it's a little heavy, both in code size (lots of required jars) and resource usage (extra threads, extra objects, etc) For example: HostConfig insists on creating an extra thread to do reloadable webapps, even if no webapps are reloadable and autoDeploy is false. Not really a big a deal, but that sort of thing adds up. Before I start ripping things apart, I wanted to double check that somebody else hadn't already done the work for me. I googled around and found references to using Catalina as the servlet engine for J2EE containers, etc., but that's a slightly different thing. Does anyone have references to an existing 'NanoCatalina'? Is anyone else interested in such a beast? I suspected it might be a generally useful sort of thing to have around, but I could be wrong... -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
IOException, error-page, etc.
Tomcat 4 will never match: error-page exception-type java.io.IOException /exception-type location /ioexception.html /location /error-page because all servlet-generated IOExceptions are silently swallowed up by StandardWrapperValve before they get a chance to be handled by the ErrorReportValve. (or the ErrorReportValve, you don't even get the default stack trace page) This strikes me as bad, but there are comments in the StandardWrapperValve code that indicate it's intentional. I've searched fruitlessly (google, list archives, cvs comments, etc) for any hints about why Tomcat would want to do this. Is is a bug or a feature? If it's a bug, I'll happily submit a bugreport and patch. If it's a feature, what's the rationale? Thanks, -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
StandardSession.expire() race?
There's code in StandardSession that looks like this: public void expire(boolean notify) if (expiring) return; expiring = true; The test isn't thread safe, and it looks like it's possible to have expire() called from the StandardManager reaper thread and a servlet thread (through invalidate) simultaneously. 'expiring' is tested in other places in StandardSession, but I'm not sure enough of the possible call paths to tell offhand if they're also dangerous. I think it would be enough to declare expire volatile and put a synchronized block around the test-and-set in expire(), but I wanted to double check my logic before I submitted a patch... -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Minimalistic Docs
Anthony Holland wrote: Tomcat - A Minimalistic User's Guide There is no such word as 'minimalistic'. In the style of a member of the art movement Minimalism. In the style of a minimalist. Minimalistic. Works for me. Minimalist User's Guide would imply that the user's guide has to do with the art movement (or communism), while Minimalistic implies that the guide is in the style of, but not actually about, Minimalism. A Minimalist's Guide might work. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ApplicationFilterChain, doPrivileged()
When a SecurityManager is intalled, ApplicationFilterChain.doFilter() wraps its internalDoFilter() call with AccessController.doPrivileged(), but I'm having trouble figuring out why. doFilter() gets called from: a) StandardWrapperValve.invoke(), in which case (presumably) the container and all its ancestors in the call chain have a superset of the permissions of the Filter code, so the call to doPrivileged() doesn't matter. b) A user filter. The user filter (presumably) is in the same domain as any other filters and the servlet. And the doFilter() code is (presumably) in a domain with more permissions than the webapp code. So the call to doPrivileged wouldn't matter. I'm still fuzzy on many of the practical aspects of the 1.2 Security Architecture, and I cheerfully admit the possibility that I'm missing something obvious. Can anyone enlighten me? Or point me to some catalina specific docs? I'm clear on the other uses of doPrivileged() (like in HttpRequestBase), it's just the call in ApplicationFilterChain that has me puzzled. TIA. Minimalistic is clearly not a word. Just because a word isn't in (your) dictionary doesn't mean it isn't real. There also may be some word play involved :-) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: nbio connector
Attila Szegedi wrote: (as it stands now in JDK 1.4, a single thread can manage up to 63 channels so you still need multiple threads, only less than with blocking approach), The 63 channel limit is a Windows-only bug in the Beta, designing code around it probably isn't a good idea. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: nbio connector
Remy Maucherat wrote: With my design, you still need one thread/request but only for the time required to process container.invoke() In the real world, the servlets and JSPs are the thing which take by far the most time to complete, so I'm not sure you wouldn't end up spending a lot of time in the threaded part. There was a long discussion on the advanced-servlets list a while back. That discussion concluded that the NIO looked most promising for: - Cleanly waiting for persistent connections (which take up a connector thread but don't really need to) You can kinda sorta do this already with the existing java.io classes, but NIO is better. This is a relatively easy win. - Serving static content. It's not just the non-blocking io, serving from memory mapped files is a beguilingly easy (but maybe not always the best) way to improve file serving performance. Using NIO to reduce the time service() needed to tie up a thread is fun, but seemed unlikely to help very much in practice. And of course the optimized char conversion stuff, but that's obviously useful and therefore boring. I'm pretty sure newesh versions of Jetty include a first pass at integrating NIO, so anybody that's interested might want to take a look. There's some fairly bogus (but still kinda interesting) benchmark results using NIO-like routines to serve static files at distributopia.com. (Sun says no NIO-bmarks until it's out of beta, so I used Matt Welsh's NBIO code) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: nbio connector
[EMAIL PROTECTED] wrote: I'm not very sure about nbio - most of the time there's a lot of complexity ( and a different programming model, etc ) Yes. - and the benefits seems pretty small. It depends. Using NIO, you can serve static content as fast or faster than Apache 1.3 in pure Java, which means one less reason to use a separate front-end web server. (Of course, performance isn't the only reason to run Apache as a front end to Tomcat, but it seems to be perceived as the biggest reason) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][4 HEAD] ContainerBase javadoc typo fix
Comment typos, you think awww, who cares, and then you notice one. And it starts to gnaw at you, just a little bit at first, but then it gets worse and you can't think of anything else and your marriage falls apart and you end up frozen to death in the gutter. Best to avoid the whole thing and just fix them. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com cbasecmnt.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][4.0] ApplicationFilterChain Ctr
ApplicationFilterChain has a constructor that doesn't do anything useful. It's call to super() is a bit confusing, since it leads to the assumption that FilterChain is a class. Other interface implementations in Catalina don't bother with placeholder constructors, this patch removes the one in ApplicationFilterChain. I've been posting patches as I come across bits of code and documentation that look iffy. None of them have been showstoppers and none of them are the kind of thing normal people can work up much enthusiam about. But crappy little cleanup patches really do help in the long run. Especially documentation cleanup. I was under the impression that stuff like this didn't go through the normal code-change voting process, it just got picked up (or not) by a committer and merged in. Is that correct? Would it be more appropriate to submit bug reports? -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][4.0] ApplicationFilterChain Ctr
afiltcctr.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
StandardPipeline and ThreadLocal
The first thing that pops into my head when I see the
Pipeline pattern (and read Craig's [PROPOSAL] Tomcat
4.0-beta API Change: Valve APIs post), is something
along the lines of the psuedocode at the end of the
message.
The semantics are subtly different from the current
StandardPipeline, but I think only in bizarre cases
like if a Valve spawned a thread and then both threads
tried to call invokeNext on the same ValveContext.
It's not like the existing code is exactly broken,
but the use of ThreadLocal is certainly a little
unexpected. It violates the avoid suprising code
rule. (Well, it suprised me, anyway)
Do the semantics differ in some other way that makes
the implementation below incorrect? (Ignore bugs, you
get the idea) If not, would whoever's responsible for
that code be willing to accept a patch to get rid of
the ThreadLocal?
class ValveContext {
Pipeline p;
int i;
public void invokeNext(req, rsp) {
if (i==p.valves.length)
if (p.basic)
v = p.basic;
else
v = p.valves[i++];
if (!v) throw exception;
v.invoke(req, rsp, this);
}
}
class StandardPipeline {
Vector valves = new Vector();
Valve basic;
public void invoke(req, rsp) {
ctx = new ValveContext(0, this);
ctx.invokeNext(req, rsp);
}
}
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][4.0] remove spurious casts in ApplicationFilterChain
The fall off the end of the chain code in
ApplicationFilterChain.internalDoFilter checks if the
passed in request and response are HttpServletRequest/
Response objects. Based on the test, it casts the
objects and invokes servlet.service(). However, since
the servlet member has a static type of javax.servlet.Servlet,
the exact same method is called in both cases. The code
operates correctly (since the non-http version of the
service() method eventually invokes the correct version
of service()), but the test and cast are redundant and
confusing. The following patch removes them:
Index: ApplicationFilterChain.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java,v
retrieving revision 1.11
diff -u -r1.11 ApplicationFilterChain.java
--- ApplicationFilterChain.java 2001/10/11 23:30:58 1.11
+++ ApplicationFilterChain.java 2001/12/28 19:06:24
@@ -242,13 +242,7 @@
try {
support.fireInstanceEvent(InstanceEvent.BEFORE_SERVICE_EVENT,
servlet, request, response);
-if ((request instanceof HttpServletRequest)
-(response instanceof HttpServletResponse)) {
-servlet.service((HttpServletRequest) request,
-(HttpServletResponse) response);
-} else {
-servlet.service(request, response);
-}
+servlet.service(request, response);
support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
servlet, request, response);
} catch (IOException e) {
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][4.0] Server javadoc fix
The javadoc comments for o.a.c.Server weren't updated when the Service level was added. I removed the old bad bits and inserted some uninspired but correct new bits. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com server-javadoc.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
