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 feed

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 week

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 discu

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 w

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 refact

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 htt

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

Performance Test Workload: Small Static File

I've changed the subject line since this is moving away from the proposal. [EMAIL PROTECTED] wrote: > > And I can assure you that everyone > working on performance seriously is running those test > and evaluating the performance periodically. > Nah, I'm not going to take your word for it.

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

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

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 st

Re: Proposal draft for Tomcat 5.0 : JMX utils

[EMAIL PROTECTED] wrote: > > I don't think model mbeans can be used for some of the > stuff that I want ( in jk ), and I think it is much easier to > use the automatic introspection based dynamic mbeans. > Hmm, I don't get it. Might be me not understanding JMX well enough (need to buy that darn

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: >

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

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 i

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

Re: Proposal draft for Tomcat 5.0 : #3 Straw Man

[EMAIL PROTECTED] wrote: > > If you can clarify your concerns - do you disagree with Coyote > entirely ( and why ), is it something missing that you want > added or something that is there and you feel shouldn't ? > Fair enough. I think part of the problem is that one of the primary goals of t

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

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

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 discussio

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. --

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,

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:

Re: [PROPOSAL] Minor fix for servletapi-4 GenericServlet

GOMEZ Henri wrote: > > Did we have to make a general announce about this API > changes ? > There are only 5 committers for servletapi-4, and none of them appears to be active right at the moment. I agree that there has been way too much discussion about what is basically a trivial fix, but I'

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 > c

Re: watchdog, servletapi, karma

Ryan Lubke wrote: > > You can send me the Watchdog patches and I'll look them over. > My original failed tests turned out to be my fault. I didn't update my servlet-test.war. I downgraded the severity of 9794 from "Blocker" to "Normal", since it turns out there really are problems. The Watchdo

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 gui

[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 res

Re: watchdog, servletapi, karma

GOMEZ Henri wrote: > > No, I saw a problem here since servlet-api-4.0 is the OFFICIAL > servlet 2.3/jsp1.2 API and may not change without (wide) notice. > Yes, but there's a difference between changing the API (which is the job of the servlet spec jsr team) and fixing bugs in the implementatio

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

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 lik

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,

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 int

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

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

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.

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 s

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 ev

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

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: <ma

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

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

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 t

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 tr

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

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 "classNam

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.apa

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 lis

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

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 obvio

Re: MinTC, "terrible rudeness", persistence

Skip ahead to the "" 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

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.

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 summar

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 suc

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: For additional commands, e-mail:

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 or

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'v

[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.distri

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

[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

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 serv

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 s

[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 T

[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:

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

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

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 class

[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) FA

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

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 harmles

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] D

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 probl

[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 imp

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_s

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

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

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: For addition

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.

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

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 i

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 HttpReq

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

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

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.ca

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

[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 ende

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 th

[PATCH] Bug 6592: hostjdoc.patch

-- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com hostjdoc.patch Description: Binary data -- To unsubscribe, e-mail: For additional commands, e-mail:

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.distribut

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 discus

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 yo

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 woul

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

IOException, , etc.

Tomcat 4 will never match: java.io.IOException /ioexception.html 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 defa

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 servl

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

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 guid

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.

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

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

  1   2   >