Re: [VOTE] minimal JSR 154 only distribution

Bill Barker wrote: > Urm, err, the users that can't read may include you ;-). Jon withdrew the > vote above. This means that this is officially 'not getting anywhere', at > least until Jon re-submits his re-worked proposal. The fact that Jon withdrew the vote doesn't change any of the arguments

[PROPOSAL][TOMCAT5] plugins directory

There are several things we discussed last week, and few seem to have enough consensus. This is an initial proposal - I expect it to change quite a bit. I think it's very important and will affect almost everyone - so please send at least a numeric vote, and if possible comments or sugestions. If

Re: [PROPOSAL][TOMCAT5] plugins directory

Remy Maucherat wrote: >> 8. Tomcat should work with no config file - using only JMX API calls >> to load it and configure a set of plugins ( profile ), using whatever >> class loader and layout the embeding application ( ant, etc ) wants. > > +1. > > #7: The configuration mechanism I added shoul

Re: [PROPOSAL][TOMCAT5] plugins directory

Sorry for the late reply, I had no mail for few days. Jeanfrancois Arcand wrote: >>1. Add a new plugins/ directory. All tomcat components will eventually >>be migrated from server/lib and common/lib into one of the plugins >>subdirectories. ( it can be called modules/ or something else ). >> > +1

Re: [4.1.17] [VOTE] Stability rating

Remy Maucherat wrote: > > [ ] Alpha > [ ] Beta > [X] Stable (General Availability) > > Reason (optional): > > > > Thanks for voting and for testing 4.1.17 Alpha! > > Remy -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: Upgrade to Tomcat 4.1.17 - server has reset connection

Matt Raible wrote: > I upgraded my site to use Tomcat 4.1.17 tonight. While this fixed all > my previous ClassNotFound errors for the hsql jdbc driver (in Tomcat > 4.0.6), I started getting a new error: > > 17-Dec-2002 10:02:52 PM org.apache.jk.common.ChannelSocket > processConnection > INFO: se

RE: Upgrade to Tomcat 4.1.17 - server has reset connection

g for the next release. For 4.1.17 - you'll have to configure the logger. Costin Matt Raible wrote: > You are correct - I am using Apache 1.3. Is there anyway I can change > this log message setting? > > Thanks, > > Matt > >> -Original Message- >

Re: [PROPOSAL] EL Transition to Jakarta Commons

+1 Is the EL depenent on javax.servlet or javax.servlet.jsp, or is it completely independent and useable in non-servlet-container environments ? BTW, another option that can be considered is what Sam Ruby mentioned few times on jakarta-general or community, i.e. just lower the walls between jak

j-t-c/util, 3.3 and logging

Is it ok if I change util.thread and util.net to commons-logging ? That would mean c-l will be required for tomcat3.3, and thread and net would use c-l instead of the Log. It should be easy to modify the util.Log implementation in 3.3 to support commons-logging API, or implement util.Log using co

Re: [PROPOSAL] EL Transition to Jakarta Commons

Jan Luehe wrote: > Costin, > >> +1 >> >> Is the EL depenent on javax.servlet or javax.servlet.jsp, or is it >> completely independent and useable in non-servlet-container environments >> ? > > There are some dependencies on servlet containers. For example, the EL > supports implicit objects, on

Re: j-t-c/util, 3.3 and logging

Bill Barker wrote: >> Is it ok if I change util.thread and util.net to commons-logging ? >> That would mean c-l will be required for tomcat3.3, and thread >> and net would use c-l instead of the Log. > > TC 3.3.2-dev already requires c-l. The o.a.t.u.** classes in j-t are > already using it. So

Re: j-t-c/util, 3.3 and logging

Bill Barker wrote: >> > Last time I checked, o.a.t.u.log.Log already implements o.a.c.l.Log. >> >> I know, but it needs a factory and manifest to be useable >> as a c-l impl. ( I never tried it - it may work if someone already >> added this ) > > I'll look into adding a factory to qlog (since I

Re: [VOTE] Tomcat 4.1.18 release

I think we don't have too many choices here - it's something we must do. +1 Costin Remy Maucherat wrote: > A bug exists (unfortunately) in Tomcat 4.1.16 and Tomcat 4.1.17 which > causes the servlet Writer to stay in an invalid state after an > IOException occurs (99% of the time caused by an a

RE: j-t-c/util, 3.3 and logging

Larry Isaacs wrote: > I hope to spend some cycles advancing a Tomcat 3.3.2 release > over the holidays. I'm not assuming I can finish, but hopefully > a Tomcat 3.3.2 release can be made in January. I'll also try > to get back up to speed with Tomcat 4 & 5 and J-T-C. I hope we'll reach a decisio

Re: subclass ThreadPool from GenericObjectPool?

Michael wrote: > Has anyone considered subclassing ThreadPool from commons-pool's > GenericObjectPool? > > I'd be willing to work on it. Can you list any benefits on doing that ? Any missing feature we'll gain ? ThreadPool seems to work fine. Costin -- To unsubscribe, e-mail:

Re: implement ThreadPool with GenericObjectPool?

Michael wrote: > Costin Manolache wrote: > >>Can you list any benefits on doing that ? >> > The usual: code that's also used and tested by other projects; code that > more people are familiar with; not further reinventing code. What projects are using commons-po

Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java

[EMAIL PROTECTED] wrote: > Modified:coyote/src/java/org/apache/coyote/tomcat4 > CoyoteConnector.java > Log: > Adding the 'maxKeepAliveRequests' attribute to the Connector. The code > in the Protocol and Processor has been there for a very long time. > > I'

RE: error-page status codes broken, no response to bugzilla report

It is on my todo list ( I also need this to work, at least for 500 ). Do you have a patch ? Costin Donald Ball wrote: > Are any tomcat developers going to express any interest in this issue? I > frankly consider being completely ignored to be quite rude and a poor way > to interact with the at-l

Re: [PATCH] Re: implement ThreadPool with GenericObjectPool?

Michael wrote: the debugging feature (JMX support) you're adding. JMX is not a debugging feature - it's monitoring/control. It would allow people to see how many threads are used, to eventually stop threads or change the parameters dynamically. I know what JMX itself is--I'm going by the

Re: tcpNoDelay for http11/coyote connectors - but not for JK et.al.

Dirk-Willem van Gulik wrote: > > Any special reason why the so-usefull (I am generating small gif's with a > quick turn around time) tcpNoDelay config directive is not (documented) as > available across all connectors ? The old and common reason - nobody sent the documentation patch yet :-) Cos

Re: [PATCH] Re: ThreadPool

Michael wrote: > Costin Manolache wrote: > >> You're probably right that addThread() doesn't need to be public - but >> I don't think it hurts too much either. > > It does when you're trying to refactor a class. It forces you to ask > whether the

RE: Questions related to a port of the IIS-connector to Domino I plan to provide

Mladen Turk wrote: > Seems that Domino 6 is using its own JVM (think that the one (IBM 1.3.1) > comes with installation) and you have collision problem cause you are > loading another JVM in the process. > > There could be a problem with that if Domino already loads JVM, cause > you can load JVM

Re: [PATCH] Re: ThreadPool

Craig R. McClanahan wrote: >> It would actually be a pretty good solution IMO. A single thread checking >> the files for modification in all contexts is better ( again IMO ) than >> one thread per context. Same for checking sessions. >> >> The coding is a bit trickier ( and there are some issues

Re: [PATCH] Re: ThreadPool

Craig R. McClanahan wrote: > I like using the custom Ant tasks included with Tomcat 4.1 for > manipulation via manager, so that I can create a "reload" target. If you > don't use Ant, it's just as easy to leave a browser window open to: I don't know if you looked at the JMX ant tasks in modeler

Re: [PATCH] Re: ThreadPool

Remy Maucherat wrote: > BTW, can't Linux 2.5/2.6 handle thousands of threads without any problem > ? I remember reading an iterview of Ingo who said JVM performance and > thread handling should be way better in 2.6. > The idea is that there's nothing wrong with designing with threads in > mind (I

Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml

Are you going to port this to jk2 :-) ? One issue: I'm not sure JavaGroup is doing the synchronous(?) replication of session data - there is a delay between a change is made on one worker and the moment this is known on all other workers. If you don't route back to the same worker - you'll loo

Re: [5.0] Input optimization

Great ! Costin Remy Maucherat wrote: > I've committed input optimization similar to the OutputBuffer used in > the Coyote adapter. It appears to work ok (although > BufferedWriter.readLine still needs to be implemented). > > I'm against porting this patch to 4.1.x, as it is a risky change (whi

Re: [5.0] Input optimization

Remy Maucherat wrote: > Costin Manolache wrote: >> Great ! > > If you could come up with a better name for the "substract" method ;-) > It's supposed to be the opposite of append. > > The optimization works good. It should help WebDAV as well as web >

Re: cvs commit: jakarta-tomcat-5/resources mbeans.xml

Remy Maucherat wrote: > [EMAIL PROTECTED] wrote: >> costin 2003/01/05 22:09:47 >> >> Added: resources mbeans.xml >> Log: >> A small test file for the 'jmx-ified' config / profile. >> >> Each component will be defined as an mbean - with explicit control >> over class loader

Re: cvs commit: jakarta-tomcat-5/resources mbeans.xml

Remy Maucherat wrote: > [EMAIL PROTECTED] wrote: >> costin 2003/01/05 22:09:47 >> >> Added: resources mbeans.xml >> Log: >> A small test file for the 'jmx-ified' config / profile. >> >> Each component will be defined as an mbean - with explicit control >> over class loader

Re: [PATCH] forward instead of redirect for welcome files

Matt Parker wrote: > > On Mon, 2003-01-06 at 12:14, Hans Bergsten wrote: >> Matt Parker wrote: >> > I'd like to suggest that catalina perform a forward, rather than a >> > redirect, for requests that end with '/'. With a redirect, special >> > configuration is necessary for proxy servers to work

Re: [PATCH] forward instead of redirect for welcome files

Matt Parker wrote: >> The welcome-file-list can include more than index.html - you may have >> foo/index.html, etc ( i.e. things in other dirs ). That means #anchors >> would break if we don't do redirect. > > This argument would apply equally to Apache's current implementation. > You can specify

Re: [PATCH] forward instead of redirect for welcome files

Matt Parker wrote: > On Mon, 2003-01-06 at 14:43, Hans Bergsten wrote: >> Okay, that's different. Maybe I misread your patch, but to me it looked >> as if you changed the behavior when there's no trailing slash. > > Actually my patch is forwarding under both circumstances, but according > to SRV.

RE: Unable to compile class for JSP

Just had the same problem - it seems JDK1.4 on windows has an interesting behavior - it will not load javac from tools.jar unless it is included in endorsed. I'm not a big windows user - if someone could confirm, we need to change the scripts. I see this behavior with (at least) 1.4.0-b92. Costin

Re: Unable to compile class for JSP

ly tested tomcat4.1 with JDK1.4.0-b92 on w2k and xp ) Costin > > -- Jeanfrancois > > Costin Manolache wrote: > >>Just had the same problem - it seems JDK1.4 on windows has an interesting >>behavior - it will not load javac from tools.jar unless it is included in >&

RE: [PATCH] forward instead of redirect for welcome files

Please at least make it optional - with the default beeing the current behavior. Costin Matt Parker wrote: > Here's the new version of the patch. the code to redirect if there is no > trailing slash remains untouched, but it now forwards if there is a > trailing slash. i've included more conte

JMX-RI-1.2 problems

You may have noticed - tomcat doesn't work with JMX 1.2 The main problem is that the spec now requires the type to be JNI-style ( [Ljava.lang.String; instead of java.lang.String[] ). That would require a change in mbeans-descriptos.xml - but I'm not sure if mx4j would still work after that. There

ClassLoader problems

Ok, that's another really strange JDK1.4 problem. I hate class loaders. It works perfectly fine with JDK1.3 - but fails with JDK1.4.1. Needless to say - tomcat-coyote is in lib, and if I enable -verbose:class it actually displays a line showing ActionHook is loaded - only to throw the exception f

Re: JMX-RI-1.2 problems

Amy Roh wrote: > If you need new additions and fixes in JMX1.2, then switching to 1.2 > sounds > good to me. What other changes are needed to make it work with JMX1.2? I > can volunteer to make the changes (especially in mbeans-descriptors.xml) > if you point me to the list of changes. The bui

Re: ClassLoader problems

Once again - debugging it is close to impossible ( just like most classloader problems), but luckily I guessed how to fix it - just remove the "endorsed" property and it works again... What "endorsed dirs" has to do with ActionHook - I don't know. Costin Costin Manol

Re: Duplicate session IDs are *common*

Schnitzer, Jeff wrote: > For whatever reason, be it the seed algorithm or the hashing algorithm > or something else that degenerates the randomness - the duplicate > session ID problem is very, very common. > > I discovered this problem because a few of our users suddenly found > themselves with

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java StandardManager.java

I'll fix it. That's what happens when you let a program do the editing for you. Costin Jeanfrancois Arcand wrote: > Hi Costin, > > I was under the impression, as a convention, that we don't import using > * (java.util.*). I find it more easier when all the classes are > namedand from what

RE: Duplicate session IDs are *common*

Schnitzer, Jeff wrote: > I've already patched the 4.1.12 version we are running with the fix that > is currently in CVS. Unfortunately our only notification of when the > problem occurs is when users notice (which they probably wouldn't unless > they acquired an administrative session) and choose

Re: Duplicate session IDs are *common*

The check will verify that the session id doesn't duplicate another active session. If the session expires - it is still possible ( even if extremely unlikely ) that a user will reuse the same browser window and get into someone's else session. I think this is as likely as someone using a random

Re: Duplicate session IDs are *common*

Eric Rescorla wrote: > Jim Jagielski <[EMAIL PROTECTED]> writes: > >> Eric Rescorla wrote: >> > >> > Glenn Olander <[EMAIL PROTECTED]> writes: >> > > 5) The strength of the PRNG is largely irrelevant >> > > >> > > As a user, I wouldn't trust any solution which lacks a check for >> > > duplicate

Re: Duplicate session IDs are *common*

Eric Rescorla wrote: > Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes: > >> > ID provides a statistical probability of collision so low that >> > there is no need to explicitly check for uniqueness. >> >> Or just add a syncronized i++ to make sure. > Yes. > > There's nothing wrong with what y

Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

Jeanfrancois Arcand wrote: > Hi Costin, (you beat me on the proposal :-) ) Actually - this is a different story ( JMX-enabling different componets). I'll check in similar additions to ValveBase, BaseContainer, CoyoteConnector. The idea is for each component to be aware of its name and domain,

JSR77 names for Context ( and ServletWrapper )

I'm not very familiar with the /admin - how difficult would it be to change the naming format for Contexts ? JSR77 defines some pretty clear names for Context and Servet - and I think we should use that where possible. Another issue I have is the name of the Valves, which uses the hashcode of

Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

Bill Barker wrote: >> Jeanfrancois Arcand wrote: >> >> > Hi Costin, (you beat me on the proposal :-) ) >> >> Actually - this is a different story ( JMX-enabling different componets). >> I'll check in similar additions to ValveBase, BaseContainer, >> CoyoteConnector. >> > > I currently have custom

Re: Duplicate session IDs are *common*[GFI-T105-3E21F8D3D7B6FFDE]

Impressive. Could you make a small modification and run the same test with 20 concurent threads ? I checked the code and we have plenty of syncs, but you never know. Interesting - java.util.Random is not synchronized, so it is very likely that 2 threads calling the method at the same time will g

Re: Any idea about jakarta-modeler module?

Try build it from sources. Things will stabilize shortly ( I hope ) Costin Dhurandhar Bhatwadekar wrote: > I am trying to build the tomcat with first downloading > the other components. (in jakarta-tomcat-4.0, run ant > download.) > My problem is as follows: > jakarta-tomcat-connectors require

Re: jdk support in Tomcat 5

Filip Hanik wrote: > hi there, > I am rewriting the session replication for tomcat 5 to be more efficient. > Can I use jdk1.4 features such as java.nio packages for that ? Sure. Just make sure conditional compilation will work ( i.e. someone with JDK1.3 will still be able to build tomcat ). If

Re: [JMX hooks/handler] was Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

Jeanfrancois Arcand wrote: >>Actually - this is a different story ( JMX-enabling different componets). >>I'll check in similar additions to ValveBase, BaseContainer, >>CoyoteConnector. >> > Humm..I would like to be able to support hooks/Valves also using one > approach. I'm not an expert with JMX,

ServletException and JDK1.4

Could we change the ServletException class to pass up the Throwable ? This way JDK1.4 getCause() and the better stack trace would work. Costin -- To unsubscribe, e-mail: For additional commands, e-mail:

PROPOSAL/VOTE: JMX hook mechanism

I don't know if we can get consensus or not - but IMO this is the right solution, and I'm not going to look for another one. I decided to make this proposal - to get this out of my list. Tomcat is composed of multiple components. We agreed that JMX is the right way to configure and manage the co

Re: PROPOSAL/VOTE: JMX hook mechanism

Remy Maucherat wrote: > This looks fine. Do I get some sample code before voting, so I can see > the thing in action ? I'm working on converting Jk to Listeners. I want to first check in some changes to enable the "what is each thread doing" feature - but that would add the dependency to JMX.

Re: PROPOSAL/VOTE: JMX hook mechanism

ecome very complicated. You know my opinion on this - if you don't run the sandbox, user code can control the VM without problems ( with some JNI code - or introspection, or by overriding files ). If you run sandbox - the JMX1.2 policy-based access control should be good enough. Costin

Re: [5.0] Return of the CL bug

It won't happen in JDK1.3 It won't happen if you remove the "endorsed.dirs" from the CLI. I think endorsed is completely broken, there are many other problems and leads to undeterministic behavior. We should just remove it and add it back in JDK1.5 or when it is fixed. My +1 to remove the "endor

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

Hans Bergsten wrote: > evaluation all in one place. To make things even easier, these tag > handlers can _not_ be reused at all. Benchmarks with modern JVMs show > that the gain from reuse is not worth all the trouble. So, for new > tags we recommend using the SimpleTag API which takes care of the

Cookies, space and MSIE

It seems MSIE on mac ( aparently both 9 and X ) is failing to parse the Cookie if tomcat is used in secure mode ( with SSL enabled ). ( it doesn't matter on which platform you run tomcat - the browser is broken ). I added the extra space - and the problem went away. Remy - should we backport this

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

Bill Barker wrote: >> I saw a significant, measureable improvement in performance when I > upgraded >> our production systems to Jasper 2 with tag pooling from Jasper 1 >> without. CPU load on the production server dropped around 30%, request >> latency was >> reduced significantly, etc. The app

Re: [VOTE] Branch j-t-c for Tomcat 5

Bill Barker wrote: > I, personally, think that it's time for a branch in j-t-c. At this point, > even Tomcat 3.3 won't build against the HEAD. > > My proposal is: Revert the JMX dependencies in j-t-c, Create a branch > (e.g. > coyote_10), and re-apply the JMX patches to the HEAD branch. Tomcat

Re: [VOTE] Branch j-t-c for Tomcat 5

Glenn Nielsen wrote: >>> Before branching and having to maintain patches in two branches, >>> why not try to fix the builds and/or change the implemenation of the >>> additional JMX support so that it can be built optionally. >> >> >> Sorry, but this is not possible, and I will *not* include the

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

Bill Barker wrote: > If tag-pooling works for you, I'm happy for you. The current > implementation > doesn't work for me big time. However, I'm very interested in Costin's > claim that it can be done thread-local. One quick question ( looking at generated code ) - why is the TP limited to 5 ins

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

Remy Maucherat wrote: >>>If tag-pooling works for you, I'm happy for you. The current >>>implementation >>>doesn't work for me big time. However, I'm very interested in Costin's >>>claim that it can be done thread-local. >> >> >> One quick question ( looking at generated code ) - why is the T

Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked]

Hans Bergsten wrote: > Without pooling With pooling Reuse w/o overhead > - > 5 threads >Avg.: 330 ms349 ms N/A >Rate:15.2/sec 13.6/sec N/A > > 2

Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked]

Hans Bergsten wrote: >>> Without pooling With pooling Reuse w/o overhead >>>- >>>5 threads >>> Avg.: 330 ms349 ms N/A >>> Rate:15.2/sec 13.6/sec N/A >

Re: Tomcat 5 target JDK1.4?

V. Cekvenich wrote: > Why? I say TC5 should require JDK1.4 or above. Why would you decide for what other people ? > TC5 is JSP2.0. > JDK1.4 is now available from multiple sources. It would make some code > and imports easier. Not everyone can play with the VM version they run. Production serve

RE: Why unpackWars=true default?

Shapira, Yoav wrote: > Hi, > >>> From my review it looks like Tomcat 4 has always defaulted to >>> unpackWARs=true. I have no problem with that being the default. >>> And it would not be good to change at this time since Tomcat 4 >>> has been released for quite a while. >> >>More importantly, i

Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked]

nk the number of tags in a page is too important - even if you have 1 complex tag - with 100 concurent users - you should see a difference. In an ideal world, all "core" tags would be recyclable and garbage-free - that may allow them to run at comparable speed with a hard-coded page

Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

Taking Glenn's post out of thread: Glenn Nielsen wrote: > Per JSP Page (current) > -- > > The current tag pool manages one or more pools of tags on a per JSP > page basis. With a synchronized method call for each get/reuse pair > for a TagHandler used in the page. That page

Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked]

Hans Bergsten wrote: > Costin Manolache wrote: >> [...] >> In an ideal world, all "core" tags would be recyclable and garbage-free - >> that may allow them to run at comparable speed with a hard-coded page. > > I think it's more important to implement

Re: Tomcat 5 target JDK1.4?

I use Idea. I should start learning vi :-) ( well, I do use emacs and vi a lot - but not for java, so I may still have a chance ... ) Costin Glenn Nielsen wrote: > This is off topic, but I do the same. > > Glenn > > Shapira, Yoav wrote: >> Howdy, >> >> >>>The first thing I ask programmers

RE: Tomcat 5 target JDK1.4?

Martin Algesten wrote: >> I use vi for at least 14 years, but for java dev I turned to >> eclipse last year, and it's hard to reswicth to vi ;) > > Wow! I tried to use Borland J something or another a long time ago and > got to frustrated that I didn't have control over what I was doing... > what

Jasper, JMX and JSR77

JSR77 defines a certain model - in particular a WebModule must include an attribute "servlets[]" that lists all the servlets in the webapp, and it also requires on JMX mbean per servlet. ( tomcat uses that to provide all kind of performance and statistical info ). The problem is - JSPs are not vi

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

Sorry, I didn't see the patch - I was precompiling the admin and hit the problem. BTW - why don't you fix it yourself - you are committer AFAIK :-) ? Costin Hans Bergsten wrote: > [EMAIL PROTECTED] wrote: >> costin 2003/01/21 11:44:42 >> >> Modified:jasper2/src/share/org/apache/jasp

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

Jan Luehe wrote: > Jasper currently uses its own private logging facility implemented > in the org.apache.jasper.logging package. This is inconsistent with > the way the other Tomcat subsystems perform logging > (by leveraging the commons-logging package). > > Proposal is to remove org.apache.jas

Precompiled jsps

Finally - the precompilation for /admin works, just use ant build-admin-precompile The jsp-examples should be precompiled too ( unless they're intended to show how slow jsp can be on the first request). After more looking at the code - I think it is a bit too complicated to add the JMX to jas

Re: Tomcat 5 target JDK1.4?

V. Cekvenich wrote: I'm very happy that Tomcat works well on 1.4, I can't however see any reason to "requiring" 1.4, what are the benefits? Should we artificially create obstacles for the sake of it? Martin Would you be "more" happier if JDK 1.4 made tomcat faster and more stable and have l

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

Remy Maucherat wrote: > Hans Bergsten wrote: >> [EMAIL PROTECTED] wrote: >> >>> remm2003/01/22 03:40:00 >>> >>> Modified:jasper2/src/share/org/apache/jasper JspC.java >>> Log: >>> - Fix package name generation. >>> - Default to "org.apache.jsp" package name. >> >> >> Why do

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

Remy Maucherat wrote: > Jeanfrancois Arcand wrote: >> The only problem I see by removing the package org.apache.jsp is that >> when Tomcat run under the security manager, it is no longer possible to >> protect an application from package insertion/access (dangerous). >> >> It is still possible t

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime TagHandlerPool.java

[EMAIL PROTECTED] wrote: > costin 2003/01/22 11:58:45 > > Modified:jasper2/src/share/org/apache/jasper/runtime > TagHandlerPool.java > Log: > Strange - getServletConfig() returns null. Need help.. This happens because TagHandlerPools are created in the con

Re: [proposal] JK2 (WIN32) add dynamic load balancing

Mladen Turk wrote: > Hi guys, > > It's been a long time :-). > > I would like to add the dynamic load balancing to the existing one. > Since I know how to implement that only on WIN platform, I'll elaborate > that a bit. > > The WIN32 has Performance Monitor that monitors server's activity. The

RE: [proposal] JK2 (WIN32) add dynamic load balancing

Mladen Turk wrote: > > >> -Original Message- >> > >> > The WIN32 has Performance Monitor that monitors server's activity. >> > There is also and interface to that using Registry >> functions, although >> > the data isn't really stored in the registry. We could use those >> > information

Re: [proposal] add the apr_queue mechanism to apr_socket

Mladen Turk wrote: > > One more... > > Here is the scenario: > > If TC instance is too busy or reached the connection limit the next > connection is refused, causing entire worker to switch to the error > state. This isn't very smart (at least for threaded servers). > I propose that we use the

Re: Interesting

Jon Scott Stevens wrote: I wonder if one could use these techniques to hack a servlet engine somehow and get from one context to another (assuming you had access to run servlets in it...ie: shared hosting)... http://www.javaspecialists.co.za/archive/Issue014.html -jon Interesting - but it

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threadsThreadPool.java ThreadPoolMX.java

FYI: I did the same in the main branch. All of DynamicMBean features are now porte to modeler. There is no need for JMX dependency in jtc/util ( the branch is still needed in coyote, jk, http11 ) Costin [EMAIL PROTECTED] wrote: billbarker2003/01/24 20:49:24 Modified:util/java/org/ap

RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java ThreadPoolMX.java

f removing it won't break code. I know of a use in 3.3, is anyone else using it ? We definitely need a way to document what APIs are "FROZEN" ( like mozilla ). Costin > > Cheers, > Larry > >> -Original Message- >> From: Costin Manolache [mailt

Re: Trying to fix Gump

Larry Isaacs wrote: > I'm trying to get Gump working with respect to > jakarta-tomcat* projects. I need to know which projects > are intended to be dependent on jakarta-tomcat-coyote_10. > > Currently, jakarta-tomcat-coyote_10 project lists > tomcat-catalina as a dependent project, in addition t

Re: [5.0] New mapper

Remy Maucherat wrote: > (This question is for Costin) > > As I've mentioned before, I'm writing a new mapper to replace the > current 5.0 request mapper, which is a major performance problem right > now. > > The implementation goes well enough (I'll likely commit something today > or tomorrow; i

Re: Interesting

Glenn Nielsen wrote: >>> Interesting - but it won't work if the security manager is enabled. >>> If the security manager is disabled ( as it is in 99% of the cases ) - >>> there is no protection at all, if you can run servlets - you can do >>> anything a C program can. Just load a JNI library and

Re: JVM Error

I've seen similar problems - java is very sensitive to each thread beeing 'registered'. My understanding is that attaching the thread will set all the TLDs that are needed, and jk2 is calling the attach method - so I don't know what is wrong here. My bet would be on thread creation - I would add

Re: [GUMP] Build Failure - jakarta-tomcat-catalina

I'll update it - I wanted to run more tests and it seems I forgot to commit it. Sorry Costin Amy Roh wrote: > Costin, > > Did you forget to update StandardContext that works with TldConfig? The > current workspace doesn't compile due to the following error. > >> build-catalina-core: >> [j

Re: [5.0] Splitting authentication and authorization.

Wouldn't be better to just standardize on JAAS for authentication and stop using our own private interfaces ? AFAIK JAAS is included in JDK1.3+ - and available to older VMs. The only problem is getUserRoles(), which is not supported very well by JAAS. I'm fine with implementing them as valves

Re: [5.0] Splitting authentication and authorization.

Jeanfrancois Arcand wrote: > Costin Manolache wrote: > >>Wouldn't be better to just standardize on JAAS for authentication >>and stop using our own private interfaces ? >>AFAIK JAAS is included in JDK1.3+ - and available to older VMs. >> > I agree o

Re: [5.0] Splitting authentication and authorization.

It seems I missread your post, I tought you would add another authentication interface too ... But I still don't like the interface :-) I need to think about it. I'm pretty sure we can use Policy, Permission, etc without a security manager, and it would be better to go directly to use those. On

Re: [5.0] Splitting authentication and authorization.

not require the security manager ). Costin Costin Manolache wrote: > It seems I missread your post, I tought you would add another > authentication interface too ... > > But I still don't like the interface :-) > > I need to think about it. > > I'm pretty

Re: [5.0] Splitting authentication and authorization.

Jeanfrancois Arcand wrote: > Where the permission object will be created? In Authenticator? I would > prefer delegating the permission to Authorization interface (but I can > live it :-) ). There is also another problem. If the permission is not > granted, the method will return false. Then we wil

Re: [5.0] New mapper

Remy Maucherat wrote: > The mapper has a currently unused dependency on JNDI, and I plan to put > it in the org.apache.tomcat.util.http.mapper package. JNDI deps are fine - dependencies on org.apache.naming are not very good ( since tomcat can be used in an app that uses a different naming impl )

Re: [5.0] New mapper

Remy Maucherat wrote: > Speaking of which, I'm missing a registration for the hosts (I don't > know if it's defined in JSR 77). > Could we add some custom attributes on the object name for wrapper > (giving the mapping), as well as the host registration, and still comply > with the spec (I'd say

<    1   2   3   4   5   6   7   8   >