Re: Xerces Question

Bill Barker wrote: > I've been trying to set up a CLIENT-CERT authentication for MemoryRealm > (one > of the few that handles it :). The CN for the cert has embedded " > characters in it. It seems that xerces chokes on attributes that have > " embedded in them (which I had learned was the only r

Re: Tomcat - JBoss integration and clustering of course :)

Filip Hanik wrote: > So for Tomcat 5, I'd like to learn more on how this is changed so that all > the features in clustering are still usuable in an embedded environment. For tomcat5 the "recomended" way to embed will be JMX. The embedding app ( jboss for example ) will need to create at least

Re: [VOTE] [4.1.24] Stability rating

Remy Maucherat wrote: > Remy Maucherat wrote: >> >> [ ] Alpha >> [ ] Beta >> [X] Stable (GA) >> Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ContainerBase.java

Remy Maucherat wrote: > [EMAIL PROTECTED] wrote: >> costin 2003/03/20 07:55:29 >> >> Modified:catalina/src/share/org/apache/catalina/core >> ContainerBase.java >> Log: >> Fix valve registration. >> Few methods to simplify registration. >> >> You'll se

Re: Cluster wide deployment, question

Filip Hanik wrote: > I'm about to implement cluster wide deployment. > Who should initiate the call to deploy cluster wide, should it be the > StandardHostDeployer or the manager servlet? What do you mean ? When an app is deployed on one host in the cluster do you plan to copy it to all instances

Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Remy Maucherat wrote: > Hi, > > It is not very convinient or easy to insert the declarations for > compiled JSPs into the webapp's web.xml file. It also has the > disadvantage of adding a lot of mess in the web.xml, which the user may > not like. > > For that reason, I propose that Tomcat parses

Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

The main point is to _not_ hack anything, but just use the standard. If you precompile your app - and include jasper-runtime.jar in WEB-INF/lib - the result should work in _any_ container - the precompiled jsps are _just_ regular servlets that happen to use a lib and extend from a base class. That

Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Remy Maucherat wrote: >> I agree that using ant replace is a hack - the right solution would be to >> read the XML with DOM, insert the elements in the right place, and save >> back ( DOM - so we don't loose comments ). Or even read it as a file, and >> use regexp. No problem if we save the origin

Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Remy Maucherat wrote: > Costin Manolache wrote: >> The main point is to _not_ hack anything, but just use the standard. >> >> If you precompile your app - and include jasper-runtime.jar in >> WEB-INF/lib - the result should work in _any_ container - the precompiled

[PROPOSAL] Distributing the .jar files as binaries in release

We currently distribute .tar.gz / .zip with the full tomcat as well as RPM, .so, .exe. I would like to start adding .jar files as part of the release process for tomcat - eventually even for 4.1.24 ( we just need to upload the current jars as a separate download ). The proposal is very simple:

Re: [PROPOSAL] Distributing the .jar files as binaries in release

Remy Maucherat wrote: > No, sorry, I don't like the whole idea. We also have some work left to > do to split the main Catalina JAR. I'm quite happy with the current > distributions overall, and users apparently are also. The current distribution remains - I'm just proposing to also distribute ind

Re: [PROPOSAL] Distributing the .jar files as binaries in release

Remy Maucherat wrote: > > If it's just to be used for build tools, then it's ok (and no need for a > proposal, it just needs to get done). The trouble starts if users start > thinking they can use that to upgrade to a newer release, just by > upgrading one or two JARs (or ever worse, mixing compo

Re: [PROPOSAL] Distributing the .jar files as binaries in release

Remy Maucherat wrote: >> For example if we fix something in jk - should we have to make a full >> new release of tomcat ? Same for jasper, catalina, etc. > > Yes, we do. We release stable builds based on multiple components. We > can't support pick and choosing (latest big example: Xerces, which

RE: [4.1.23] Deprecating mod_webapp

George Sexton wrote: > Before anyone writes this kind of thing they should examine a > representative number of web applications and find out how many would > actually benefit. I.E. how many "web applications" have significant It is a bit late - the code for this kind of thing is already written

Re: [PROPOSAL] Distributing the .jar files as binaries in release

Henri Gomez wrote: >> - the jar names should be fully versioned ( otherwise we can't keep >> more than a version in the dist dir ), and a symbolic link will point to >> the latest release. >> We would have: >> catalina.jar -> catalina-4.1.24.jar >> tomcat-util.jar -> tomcat-util-4.1.24.jar >>

RE: [GUMP] Build Failure - jk2

Ignacio J. Ortega wrote: > I'm trying to fix the failure below when building libjkjni.so .. > > Anyone knows what happens here ? > > I've tried to see what the difference is between mod_jk2 for apache 2 > that builds ok, and one difference i found is that mod_jk2 is linked > against APR without

Re: [PROPOSAL] Distributing the .jar files as binaries in release

Henri Gomez wrote: > To follow a Packaged approach, ie using rpm/deb, tc5/tc4.1 should > have its own jars and dependencies on externals jar (logging, mx4j.). > > With this way it's easy to maintain a tomcat version with up to date > externals jars (assuming they are backward compatible). Yes -

Re: [PROPOSAL] Distributing the .jar files as binaries in release

Henri Gomez wrote: > That's why the idea of using a repository of jars is a good idea : > > /usr/share/java/log4j-1.1.3.jar > /usr/share/java/log4j-1.2.7.jar > /usr/share/java/log4j-1.2.8.jar > /usr/share/java/log4j.jar -> log4-1.2.8.jar > > /usr/share/java/mx4j-jmx-1.1.1.jar > /usr/share/java/m

Re: TC5 JMX

Amy Roh wrote: > Costin, > > It doesn't seem like mbeans are created appropriately when logger, realm, > and valve are dynamically added after start. Is the mbean registration > code listening to those events? It should. For valve - I think it works now ( I'll make a commit soon with few more

Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Craig R. McClanahan wrote: > Many app servers have private deployment descriptors for "extra" > information, similar to what Remy is proposing -- indeed, one could claim > that Tomcat does this already with how we use $CATALINA_HOME/conf/web.xml > to set default behavior (well, at least until Cost

Re: TC5 JMX

Amy Roh wrote: >> I moved the valve registration in addValve(). > > Cool. I think logger and realm registration should be in setLogger and > setRealm as well so mbeans can get registered correctly. Also, > deregistration for old mbean should happen when new logger or realm is > null. +1 :-) F

Re: [5.0] Monitor servlet

Remy, Could you move the manager servlets to webapps/manager ? As you can see, I can't touch build.xml without breaking something :-). I would also like to move the coyote/tomcat5 code in catalina - and eventually coyote/tomcat4 to jakarta-tomcat-4 and same for 3.3 ( preserving the same packag

Re: [5.0] Monitor servlet

Remy Maucherat wrote: > I've committed a rough version of the monitoring servlet. It will > display status information for all Coyote connectors, using JMX > exclusively. I don't think there's any statistic missing (the amount of > meaningful status information available to a Java program is defin

Re: [5.0] Monitor servlet

Remy Maucherat wrote: > Remy Maucherat wrote: >> Costin Manolache wrote: >> >>> Remy, >>> Could you move the manager servlets to webapps/manager ? As you can >>> see, I can't touch build.xml without breaking something :-). >>> >>>

Re: [5.0] Monitor servlet

have to install WindowsXP to see the tomcat page ? ) Costin > > -Tim > > Costin Manolache wrote: >> Remy Maucherat wrote: >> >> >>>I've committed a rough version of the monitoring servlet. It will >>>display status information for all Coyote con

Re: [5.0] Monitor servlet

re doing instead of just inventing one. Apache doesn't seem to generate an XML or other complexities - and there are apps that can parse it and do whatever they need to do. Costin > > -Tim > > Costin Manolache wrote: >> Tim Funk wrote: >> >> >>&g

Re: [5.0] Monitor servlet

Remy Maucherat wrote: >> No, just return HTML in the first place. > > Feel free to revert to the previous version. > > -1 from me for server side XSL (we're doing a monitor servlet, not a > bring-ther-server-to-its-knees monitor servlet). > >> I just don't understand - when you can just displa

Re: [5.0] Monitor servlet

Remy Maucherat wrote: > Costin Manolache wrote: >> Remy Maucherat wrote: >> >> >> >>>>No, just return HTML in the first place. >>> >>>Feel free to revert to the previous version. >>> >>>-1 from me for server side

Moving org.apache.coyote.tomcat5

To remove one of the circular deps and simplify the build - I will move the tomcat5-specific part of coyote to jakarta-tomcat-catalina. This way we have a one way dependency between catalina and coyote. I'll keep the package name so no other change will be needed ( except the build file - to jar

Re: TC5 Servlet unavailable error

Amy Roh wrote: > It seems like when context is stopped and restarted, servlet always > returns "unavailable". You can generate an error by saving your changes > in admin by "commit". Then any process after that returns admin servlet > unavailalbe. > > Mar 31, 2003 4:48:29 PM org.apache.catalina

Re: TC5 Servlet unavailable error

Amy Roh wrote: >> Amy Roh wrote: >> >> > It seems like when context is stopped and restarted, servlet always >> > returns "unavailable". You can generate an error by saving your >> > changes >> > in admin by "commit". Then any process after that returns admin >> > servlet unavailalbe. >> > >> >

Re: Why does Tomcat use xerces under java 1.4 instead of the internal jvm classes?

Jean-Francois Arcand wrote: > Because the xerces version bundled with 1.4 is an older one, doesn't > support XML schema properly, and contains bugs (and is not as performant > as the 2.x version) Isn't Crimson in JDK1.4 ? I remember we decided to disable XML schema validation. At least in tomca

Re: disable jmx option in tc5

Amy Roh wrote: > Just out of curiosity, is there a simple way to disable jmx in tc5 other > than changing tomcat code to avoid registration/unregistration manually > which won't be trivial. Just out of curiosity, why would you want to do this ? The whole point of using ( and requiring ) JMX is t

Re: Why does Tomcat use xerces under java 1.4 instead of the internal jvm classes?

Jean-Francois Arcand wrote: >>At least in tomcat5 I never use xerces - only the bundled parser, and so >>far I've seen no problems. >> > Crimson is a very good parser, and it still faster that Xerces in some > case. The only reason I see for bundling xerces is for when we turn on > validation & th

Re: [4.1.x] Next release

Remy Maucherat wrote: > Hi, > > As far as I am concerned, the focus for the next stable 4.1.x release > will be on small fixes. I do not want to introduce new features or > changes which would affect Tomcat's behavior. I think the ETA for that > next stable release could be within one to two mont

Re: [4.1.x] Next release

Remy Maucherat wrote: > Could I get some details on that filter/facade bug ? Yes, Filter.init() is called with the Context object instead of the facade. While Servlet.init() is called correctly. This may allow access to the internals, and is just weird ( getting different context objects in t

Re: disable jmx option in tc5

Amy Roh wrote: >>>Just out of curiosity, is there a simple way to disable jmx in tc5 other >>>than changing tomcat code to avoid registration/unregistration manually >>>which won't be trivial. >> >> >> Just out of curiosity, why would you want to do this ? > > I don't. I was just thinking of d

Re: [4.1.x] Next release

Remy Maucherat wrote: > Costin Manolache wrote: >> Remy Maucherat wrote: >> >> >>>Could I get some details on that filter/facade bug ? >> >> >> Yes, Filter.init() is called with the Context object instead of the >> facade. While Servlet.in

Re: Why does Tomcat use xerces under java 1.4 instead of the internal jvm classes?

Jean-Francois Arcand wrote: > > > Costin Manolache wrote: > >>Jean-Francois Arcand wrote: >> >> >> >>>>At least in tomcat5 I never use xerces - only the bundled parser, and so >>>>far I've seen no problems. >>>&g

Re: disable jmx option in tc5

Remy Maucherat wrote: > Costin Manolache wrote: >> Hmmm. We could use the "jsr77" option ( that is now in 4.1.x ) and >> generate JSR77 names only if it is on. >> >> Or we could just use the other kind of names allways - and have a >> separate module th

Re: Connector issues

Sorry for the delay. IMO the right solution is to fix #10229 for coyote. There are a lot of problems in the old connectors - even if mod_jk2 is not yet as stable as mod_jk1, the java side and coyote are far better than the old impl. I'm +0 on fixing the MBean exception - AFAIK upgrading commons

Re: [5.0] More dependencies

Bill Barker wrote: > I know that at one point there was a problem if you enabled the JMX consol > (e.g. set mx.port=9000 in jk2.properties). I don't remember if that's > been fixed. I think the bug was in our code - i.e. we didn't call stop. I remember fixing it in jk, if you start the adapter u

Re: [5.0] More dependencies

Remy Maucherat wrote: > In this email, I forgot to speak about other commons (and others) > dependencies. Thanks for all the volunteering, BTW, it really helps > (damn day job ...) :) +1 :-) > JMX: I think we should try to ship with JMX 1.2 + a JSR 160 > implementation if possible. I really hop

Re: [5.0] Commons dependencies

Remy Maucherat wrote: > - modeler: Basis for Tomcat 5 JMX features, with a lot of new > impressively efficient functionality since release 1.0; again, a > critical component [Costin (do you have enough time to continue being > the RM of that component ?)] I have very little free time - if anyone

RE: [5.0] Commons dependencies

Shapira, Yoav wrote: > > Howdy, > >>The Commons web pages have some notes for doing Commons releases at: >> >> http://jakarta.apache.org/commons/releases.html > > Those instructions seem clear enough. I volunteer to be the release > manager for modeler 1.0 ;) +1 :-) > There seem to be no b

Re: FAQ location

Tim Funk wrote: > Currently I have the FAQ at: > http://tomcatfaq.sourceforge.net/ > > I have just finished tweaking it (and added some more content) into the > look and feel used by the rest of the tomcat site. You can see it here: > http://cvs.apache.org/~funkman/faq/ > > (I is horrible on gra

Re: FAQ location

Bill Barker wrote: >> > Is there any preference to where the FAQ should live? >> >SourceForge? (Status quo) >> >My public_html account on cvs.apache.org? >> >Merged under jakarta-tomcat-site? (Then anyone with access may make >> >edits) Other? >> >> +1 for moving it on jakarta-tomc

Re: [5.0] Xerces 2 impact on startup

Remy Maucherat wrote: > Just an observation ... > When I remove Xerces 2.3 and rely on the Crimson parser integrated in my > new JDK (Sun 1.4.2 beta), startup time goes down 20%. Impressive > difference (I would have thought the later 2.x releases would improve > performance :-( ). Well, you know

Re: commons-sandbox/daemon

Bill Barker wrote: > Ok, yes I know that this should go to commons-dev, but I don't monitor > that list as closely and all of the active developers hang-out here. > > I would like to make some changes to native/unix/native, and (keeping with > commons conventions) should ask first. I already hav

Re: [5.0] Draft release plan

Remy Maucherat wrote: > Hi, > > I have committed a rather generic release plan draft for TC 5.0. I have > no problem trying to shorten the release cycle if people want to (but > then, some people will have to step up and get their hands dirty > contributing to the docs and fixing bugs). I doubt

Re: SIP Servlet revisited

Brian Olsen wrote: > Hey Guys, > > A little over a year ago the posibility for making an implementation of > the SIP Servlet specification using Tomcat was shortly talked about > (see > http://www.mail-archive.com/[EMAIL PROTECTED]/msg25333.html) > > I have done some tests and looked into what p

Re: [5.0] Removing session recycling code

+1 The session is a long-lived object, so the improvement on recycling is minor. Costin Remy Maucherat wrote: > Hi, > > I'd like to completely remove session recycling code from TC 5, as it is > a potentially dangerous feature (which has been disabled in TC 4.1.x) > and does not bring any ac

Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session SimpleTcpReplicationManager.java

I remember making a change in 5.0 jasper to make it configurable on a per-page basis. I agree that tag pooling has some cases where it is less efficient, but there are also many pages where it is much better. Costin Bill Barker wrote: > > - Original Message - > From: "Remy Maucherat" <

Re: Object pooling performance

Glenn Nielsen wrote: > Remy Maucherat wrote: >> Bill Barker wrote: >> >>> Now, if we could only convince the Jasper developers of this ... ;-). >> >> >> Tag pooling is definitely not the same situation and use case as session >> pooling. Tag pooling *is* useful in many cases. >> > > There are

RE: Object pooling performance

Marc Saegesser wrote: > Another thing to consider when evaluating object pooling is the expected > lifetime of the objects. On modern JVMs with generational memory stores, > objects with a short lifespan (say the duration of a single HTTP request) > will probably never leave the nursery. Pooling

Re: Soft termination: a demonstration

If I understand correctly, you modify the bytecode to insert checks before it loops back ? Pretty cool. I haven't looked too much at the code - do you do it via a generic ClassLoader ? Are you interested to contribute this to tomcat, or it's just a demo ? I'm wondering if the JVM itself wouldn't

Re: [5.0] [PROPOSAL] Make output buffer size limit configurable

Remy Maucherat wrote: > Bill Barker wrote: >>>How about making the output buffer size limit configurable? >>>(A value of "-1" could mean indefinite growth, if people know what they >>>are doing.) >> >> I also dislike the proposal, but since it's configurable, and off by >> default >> I can limit

Re: [PROPOSAL] Add Post to the clear list for protected pages

Bill Barker wrote: > At the moment (with the default settings), Tomcat 4.1.x and higher add > HTTP headers to non-SSL protected pages to prevent intermediate proxies > from > caching them. According to the HTTP/1.1 RFC (and even the HTTP/1.0 RFC), > POSTed pages are not allowed to be cached by pr

Re: [5.0] Tester

What about "anteater" ? Costin Tim Funk wrote: > Is there any chance we'd want to use Latka instead? (Which uses > HttpClient) > > -Tim > > Remy Maucherat wrote: >> I have put the tester back in activity for TC 5 (and it caught the >> failure for error pages), but unfortunately there are a f

Re: [5.0] Servlet logging and error messages

Remy Maucherat wrote: > I'm working on the following changes: > > - Stripping out all the Catalina related part of the stack trace in the > HTML generated by the ErrorReportValve; that eases debugging. +1 > - When an exception occurs, and it is a ServletException, I think the > root cause shoul

Re: [VOTE] Tomcat 5.0 release plan

Remy Maucherat wrote: > I have updated the dates mentioned in the release plan (given that > Tomcat 5 can't go to beta before the end of last month ;-) ). It now > calls for a beta before the 15th of August, which means either Tomcat > 5.0.6 or 5.0.7 would have to be declared beta to fit the sched

Re: [5] Jasper currently requires a 1.4 JVM

Remy Maucherat wrote: > Bill Barker wrote: >> o.a.j.compiler.JspUtil.makeJavaPackage currently is calling String.split. >> This means that you currently can't use Jasper (at least for compiling) >> with >> a 1.3.x JVM. Since Tomcat isn't a J2EE 1.4 container I can't see any >> justification in th

Re: System.out refs

Tim Funk wrote: > When I was looking at o.a.c.core.ApplicationDispatcher.java, I noticed it > used 2 different logging styles: > > - Commons Logging > - log() which tries to use context.getLogger(), and if null uses > System.out > > Shouldn't the log() method use commons-logging if context.getLo

Re: [OT] New job

Remy Maucherat wrote: > This is OT, sorry. > > I've accepted a position of Consultant at the JBoss Group, where I will > help maintain the JBoss / Tomcat integration (which has become > especially important since their decision to use Tomcat as their default > servlet container in the upcoming JB

Re: Chuid - merging code from daemon into jk2

Bojan Smojver wrote: > Quoting [EMAIL PROTECTED]: > >> In order to change the uid from root to a regular user, you will add >> user.name=... >> user.group=... >> in jk2.properties. > > I'm not too familiar with this - which part here is running as root? If you want to start tomcat on port 80

RE: Spec question: RE BUG 12052

John Trollinger wrote: > I can agree that mod_jk can be seen as part of the servlet container, > but > I wonder how you are going to "fake" tomcat into thinking the request > came from > port 80 when it really came from port 8009 and what other implication / > assumptions > would occur because

RE: Spec question: RE BUG 12052

Ryan Lubke wrote: > >> The port MUST be the one in the Host Header if one is present,and should >> be present if the request is HTTP1.1 compliant, >> > What if the Host header is supplied, but the value is empty. This seems > legal per section 14.23 of the HTTP/1.1 RFC? It is legal in the cas

RE: Spec question: RE BUG 12052

Ignacio J. Ortega wrote: >> De: Bojan Smojver [mailto:[EMAIL PROTECTED]] >> Enviado el: 28 de agosto de 2002 15:27 >> Para: Tomcat Dev List >> Asunto: Spec question: RE BUG 12052 > >> of load balancers and firewalls, so it is unrealistic to expect to >> return port numbers that it doesn't know a

Re: Spec question: RE BUG 12052

To answer my own email - with a summary: - what the user really wants is to know how to form URLs - that's how the server name and port are used in most cases - the real problem is getServerName(). In CGI it is the 'canonical' name. A server may have multiple aliases for a host, and in many ca

Vacation

FYI: I'll be in vacation between Sep 1 and Sep 21. I'll read the mail from time to time, but probably not answer too much. I'm 'pre' voting +1 on the release of tomcat4.1 and on the release of jk1.2 and jk2.0beta - preferably using the same tag and date. I consider all of them stable and good e

Re: [4.1.10] New test milestone released

Not the lucky one... Something like: "> It'll fist generate a duplicated declaration ( once at top level, once at block level ) for _jspx_sub_1, and then look for a variable named 'sub' that is not declared. Costin ( about to leave in vacation :-) Remy Maucherat wrote: > A new test mil

Re: jakarta-servleapi-5

AFAIK jakarta-servletapi is considered a separate project - no idea why and how. I think it's the PMC who can decide about this - a project can't vote to get commit access to a different project. I have no idea how this was set up - but in any case you have my +1 on changing access, and if th

Re: [POLL] aprize jk2

Mladen Turk wrote: > I would like to make a poll (something non-obligatory as a vote) about > using apr/apr-util inside the jk2. The reason is quite simple, we have > lots of extra code that we either duplicate or just mimic. Since the APR > is already default for Apache2 and IIS, IMO there is no

RE: [JK2] uriMap vhosts

My only requirement: make sure whatever we define as mapping in jk2 ( i.e. jk_map, etc ) works identically with the in Apache. IMO this is an important use case, with JkSet ( i.e. use the native apache mapper, bypassing jk_map). Jk_map should use mappings as close as possible to ap

Re: [JK2] uriMap vhosts

Mladen Turk wrote: > 1. Making some sort of _default_ mappings > These mappings are for every host on the server (both default and every > vhost). > There is no particular reason for that except that the > workers2.properties can be smaller. > > 2. Making vhost:port scheme > Using general vhost

Re: cvs commit: jakarta-tomcat/src/shell tomcat.bat tomcat.sh

Bill Barker wrote: > > - Original Message - > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, September 18, 2002 9:21 PM > Subject: cvs commit: jakarta-tomcat/src/shell tomcat.bat tomcat.sh > > >> billbarker2002/09/18 21:21:17 >> >> Modified:src/shell t

RE: [POLL] aprize jk2

Mladen Turk wrote: > Hi, glad to see you rised from the death :) Unfortunately - it's back from vacation. Besides getting in the right timezone, I have to get re-adjusted with using a computer and reading mail... >> Let's tag/branch the workspace as jk2.0, with the current >> code ( as beta >

Re: mod_jk 1.2.0 release proposal

Henri Gomez wrote: >>> - Tag JTC as mod_jk 1.2.0 and prepare tarball, >>> which will contains only : >>> >>> jk/native >>> jk/docs (generated from xdocs and without jk2 parts) > > Do you agree to remove jk2 docs from jk release ? > Just to avoid confusion... +1 We should add the first

Re: jk doc

I'm impressed. I think I should consider taking more vacation ! :-) I'll review it and send comments ( or commit ) if I find anything. Henri Gomez wrote: > The JK doc is allready available for comments and revue at : > > http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/relea

Re: Problem with Tomcat 3.3.2-dev and classloader for JMX

Bill Barker wrote: > > - Original Message - > From: "Henri Gomez" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, September 19, 2002 4:25 AM > Subject: Problem with Tomcat 3.3.2-dev and classloader for JMX > > >> I've got a problem in loading MX4J and it's http adaptato

Re: Problem with Tomcat 3.3.2-dev and classloader for JMX

Henri Gomez wrote: >> Not sure I agree ( completely ). >> >> In theory, jmx is a 'system' API, and we can expect it to be in >> common. J2EE has it, catalina has it, etc. So we need to make sure >> it's security works and it is safe. >> >> I agree - it is much 'safer' to keep in in container/.

Re: Problem with Tomcat 3.3.2-dev and classloader for JMX

Henri Gomez wrote: >> With JDK1.4 - this is not possible anyway ( unless reverse loader >> is used to load org.apache.xalan classes ). > > Interesting point here, will it be possible when using jdk 1.4 > to use a specific xalan at least for webapp ? It is certainly possible to use a different x

Re: [POLL] Tomcat 3.3.2 updates

Henri Gomez wrote: > Hi to all, > > If you tracked the discussion about MxInterceptor and it's > use in Tomcat 3.3.2-dev you should know that we have some > modification to Tomcat 3.3.2 jars layout to be able to > use MxInterceptor : > > 1) mx4j and mx4j-tools should goes in lib/common > > 2)

Re: [VOTE] [4.0.5] [4.1.12] Security releases

Remy Maucherat wrote: > A security vulnerability which affects all releases of Tomcat 4.x has > been discovered. > > It is proposed that new Tomcat 4.0.x and 4.1.x releases are made, at > which time the exploit will be publicized. The security advisory will > also include an easy workaround to p

Re: Tomcat startup is slow

Chenthil Kumaran I wrote: > Hi, > > I am using tomcat 4.0.4 it seems to be slower compared to > tomcat > 3.3.x. Is there any way i can speedup the tomcat initialization. > (I > have already costomised server.xml to my need) > > I have one more doubt is there a way by which i ca

Re: [JK2] new uriMap using hostname:port

All that matter to me is to preserve the equivalence with 'native' apache config. In other words, [uri:HOST:PORT/URL] properties Must be equivalent with ServerAlias ... JkUriSet By this criteria, I would prefer use of '_default_' for the default server. For the syntax of HOST,

Re: cvs commit: jakarta-tomcat/src/shell tomcat.bat tomcat.sh

Bill Barker wrote: > I went ahead and converted most of j-t o.a.t.util.** to use > commons-logging. At the moment, since o.a.t.u.depend and o.a.t.u.compat > are in the System ClassLoader, then commons-logging needs to be there as > well. +1 We shoud do it for j-t-c o.a.t.util as well, if not a

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriEnv.c

As I mentioned, I prefer doing this _after_ jk2.0 ( i.e. the first milestone), possibly in a branch. Alternatively, you can use ifdefs - but please keep the old code at least for a while. When we decide to require apr, all the old code can/should be removed - the pools, socket, etc. We keep it

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS

Glenn Nielsen wrote: > Tomcat SecurityManager XML Policy configuration > --- > > I have finished implementing support within Tomcat for using XML based > security policy > files. This was proposed and discussed on the list back 3-4 months ago. > > I

Re: JK2 2.0.0 Release proposal

+1 and thanks for steping up :-) Mladen Turk wrote: > Hi, > > Since there is no major showstoppers and > a) The vhosts should work now > b) Socket BUG 12346 is solved > > Here is the release plan: > > 1. 09/25/2002 - Freeze the further development. > > 2. 09/26/2002 - If there is no major

RE: JK2 2.0.0 Release proposal

Mladen Turk wrote: > Contin wrote: >> >> Let's call this a 'milestone' or 'build', as is done in 4.x >> and apache. >> > > So JK2_0_BETA as tag name and jk2.0-beta as build name, but > I would reather prefer only numbers an just said "OK jk-2.0.0 is Beta > version". I think the way it works (

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS

Glenn, As a new feature, you need a majority of votes and at least 3 +1. My vote is -1 ( but is not a veto ). Only commits can be vetoed, and I'll probably do so if castor is used - all tomcat is using digester style for xml processing, and we have a proposal to use JNDI to abstract XML processi

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS

Glenn Nielsen wrote: > This code only does validation when the container is started or > when a web application context is reloaded. The current implementation > using the standard policy file does the same thing only not with XML. ??? Doing XML schema validation on each server start and weba

[5.0] Build issue - where is jasper.runtime.el and why is it checked in as binary ?

See the subject :-) I'm talking about jasper2/lib/jsp2el.jar - it contains org.apache.jasper.runtime.el classes. There is no reason to check in the binary and not the sources ! -- Costin -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [5.0] Build issue - where is jasper.runtime.el and why is it checked in as binary ?

Remy Maucherat wrote: > Costin Manolache wrote: >> See the subject :-) >> >> I'm talking about jasper2/lib/jsp2el.jar - it contains >> org.apache.jasper.runtime.el classes. There is no reason to check in the >> binary and not the sources ! > > The

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS

be 5.0 ). If you want, create a proposal/ subdir and put it there. When it's no longer experimental you can reopen the issue. But integration with the rest of tomcat configuration is pretty important. That's my opinion - and aparently Remy expressed some concerns as well. You still n

Re: [POLL] aprize jk2

> I have just a question what happends with jni (we have to use the same > threads for JVM and Apache)? Yes. That's how the jni is designed to work - avoiding thread switching and doing all processing in the request thread ( just like mod_perl or mod_php would do it ) is important. However tha

Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability

Jon Scott Stevens wrote: > Unlike JSP, we don't store (or encourage people to store) .vm files in the > webroot. They can be anywhere on the fileystem and with custom resource > loaders could even be stored in a database on another machine somewhere. Well, this is not a very good policy IMO. Sel

Re: [POLL] Tomcat 3.3.2 updates

Bill Barker wrote: > My first choice is still for split-jars in j-t-c util. In TC 4.1.x/5.0 > both > jars go to server/lib (same as 3.3 lib/container). So Costin's dream of > every servlet being able to access JMX still requires a [VOTE]. :-) In > 3.3 > we can send one to lib/container and one

RE: [POLL] Tomcat 3.3.2 updates

Larry Isaacs wrote: > A first pass implementation, derived from what you have > done, can be found here: > > Great ! However, I remain to the opinion that JMX is a fundamental API that should be available to all applications, and it should p

<    1   2   3   4   5   6   7   8   >