RE: Spec question: RE BUG 12052

On Fri, 30 Aug 2002, Ignacio J. Ortega wrote: > > It may very well be a security issue ( and quite a big one ! > > ). There are > > sites using all kinds of firewalls and settings in httpd.conf to > > restrict access to some hosts or ports ( say from internal network ). > > If Host: info is u

jtc/naming

Remy, I would like to create a new dir in j-t-c, for the naming contexts used in jk config and some other 'experiments'. I started few ant tasks and ant 'dynamic property' ( ${jndi:...} ) and ant jndi tasks ( jndiSet, jndiCopy, etc ). That would allow ant tasks to do automated config changes

RE: Spec question: RE BUG 12052

On Fri, 30 Aug 2002, Ignacio J. Ortega wrote: > > - Another cause to worry is the comment in apache2 core.c: > > > > There are two options regarding what the "name" of a server is. The > > "canonical" name as defined by ServerName and Port, or the "client's > > name" as supplied by a possi

Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode

On Fri, 30 Aug 2002, jean-frederic clere wrote: > I still see no good reasons to make a 'copy'... Well, for the JNI invocation ( starting the VM inprocess ) - I just want to make sure that jk is not missing any 'trick' - as you know this is a very OS-specific and delicate problem. Right now it

RE: Spec question: RE BUG 12052

On Fri, 30 Aug 2002, Ignacio J. Ortega wrote: > > Wrong, It takes the port and ServerName from the Host: header if the > Request-uri is relative ( most common case ) and from the Reqeust-Uri if > it is absolute.. rfc2616 Section 5.2 strict compliance.. The comment in apache2.0 core.c seems to s

Re: JSR77 and JSR88

On Fri, 30 Aug 2002, Damian Frach wrote: > We are now planning new features for the next Forte release. We have > plans for a JSR77 (managament) and JSR88 (deployment) implementation. > Can you give me information of your plans in this issue? We had few discussions. Tomcat is currently using a

Re: Spec question: RE BUG 12052

On Thu, 29 Aug 2002, Bill Barker wrote: > > So: getServerPort() should return the same as the CGI variable SERVER_PORT > > ( which returns the server port, not the host header ! ), meaning the > > value of the part after : in the Host header. > > > > I didn't know that the servlet spec can define

Re: Spec question: RE BUG 12052

On Wed, 28 Aug 2002, Bill Barker wrote: > > I think the decision to use the Host header is right, but > > I agree that it violates the wording in the servlet spec. > > > > The SERVER_PORT and the port in the Host: header are different > > beasts - in most use cases I've seen the user is intereste

Re: Spec question: RE BUG 12052

I think the decision to use the Host header is right, but I agree that it violates the wording in the servlet spec. The SERVER_PORT and the port in the Host: header are different beasts - in most use cases I've seen the user is interested in the second. Note that a load balancer or proxy is requ

RE: Spec question: RE BUG 12052

On 28 Aug 2002, Ryan Lubke wrote: > > 1) For me after ( another ) reading of rfc2616, from the point you named > > and following the references given there, i've found that in 5.2 seems > > to say that a empty Host: header must be responded by 400 because empty > > it is not a valid Host name.. >

RE: Spec question: RE BUG 12052

On Wed, 28 Aug 2002, Craig R. McClanahan wrote: > If you run Tomcat behind Apache using JK, the entire combination is the > "container" from the perspective of the servlet specification. The entire > combination has to meet all the spec rules or it's not compliant. > > The fact that the servlet

RE: Spec question: RE BUG 12052

On Wed, 28 Aug 2002, John Trollinger wrote: > > Consider Apache running on port 80, forwarding to Tomcat on > > 8009 (the default setup). I think it's reasonable for the > > application developer to assume that getServerPort() is going > > to return 80 and not 8009, because they should concep

Chuid - merging code from daemon into jk2

I would like to add the code dealing with 'chuid' from daemon into jk2. That will involve jk_user.c and a JkUser.java, using the regular jk communication. In order to change the uid from root to a regular user, you will add user.name=... user.group=... in jk2.properties. I would also lik

[5] UserDatabase -> DirContext

If we're using JNDI for configuration, then it's a good idea to use JNDI for user config ( tomcat-users.xml ). That would make the jndi authenticator 'first class'. In order to support jdbc 'user databases' we just need a jndi->jdbc adapter. I think that's a very nice and flexible solution - a

Re: [5] Proposal: webapp startup

Aha ! I think I got it, it has nothing to do with the naming... When I do a start() and try to do the config in the background, the 'ok' return status is not set and the main thread believe an error happened and resets the resource field. Costin On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:

Re: [5] Proposal: webapp startup

On Tue, 20 Aug 2002, Alex Chaffee / Purple Technology wrote: > There is a third option, by the way: > > 3. Wait with timeout. The request is queued, but if it takes longer > than a specified time to process (say, 20 seconds), then it returns a > 503. Probably that's the best - and should be th

Re: [5] Proposal: webapp startup

On Tue, 20 Aug 2002, Jean-francois Arcand wrote: > Actually, implementing the xml validation on/off mechanism, admin/ is > _the_ reason why Tomcat is slow at startup. There is a lot of xml files > to parse/validate in that applicationso I'm +1 to load on demand and > set validation to fals

[daemon] more comments

I did a more detailed review of the code. Haven't made any code change yet. There are some very serious issues right now. For example, the shutdown() native method just can't work - at least based on my knowledge of unix. It is executed in the child, not in parent - and it tries to access the f

[5] Proposal: webapp startup

There are several possible use cases, and I think we should try to provide options to support each one. Regardless of the startup timing, in all cases no request will be served from an webapp until all initialization is done, including load on startup servlets. There are 2 options here: 1. Wait.

Re: VOTE: Restoring Tomcat examples: Which workspace?

Regarding examples/: One think I would like to see is removal of all webapp-related config from server.xml, and moving it to webapps/examples.xml ( there is already code to support it ). Not sure how it would work with the current jmx code ( the saving part), but hopefully that will be replaced

Headers

On Tue, 20 Aug 2002, Patrick Luby wrote: > > Are you and Costin comfortable with Steve Downey's latest proposal > (headers are split on "," for only the headers explicitly defined in the > HTTP/1.1 specification)? I am not. I am ok ( and I think it is required ) to merge all headers with th

Re: Watchdog aggregation of headers may be incorrect

I think the relevant section is 4.2 - and it says: It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. So g

Re: Watchdog aggregation of headers may be incorrect

My understanding - the HTTP spec doesn't ( and can't ) define a complete list of headers supporting multiple values. That's impossible given that additional headers are supported. If the servlet spec requires getHeader() to return the 'concatenated value for multi-headers' - then the spec can't b

Re: [5] [TODO] Config first task

On second tought, it would be excelent if you can map server.xml. The only issue I have is the naming hierarcy - but we can address that later. One thing I hate in the current JNDI code is the binding on thread/class loader, etc. I understand what it is supposed to do, but we shouldn't have to

Re: [5] [TODO] Config first task

On Fri, 16 Aug 2002, Remy Maucherat wrote: > I will bootstrap the new configuration code by writing a DOM based JNDI > directory context to provide some compatibility with the current server.xml. Great. I am not very sure if we should spend too much time preserving the current server.xml. If

Re: [5.0] [PROPOSAL] Refactored mapper

On Fri, 16 Aug 2002, Patrick Luby wrote: > I really don't like this spec change either. After carefully reading the > revised wording, it still seems that spec is saying "if I can't find any > of the listed static welcome files, start looking for anything that can > serve up a response". > >

Re: [5.0] [PROPOSAL] Refactored mapper

On Fri, 16 Aug 2002, Remy Maucherat wrote: > >>The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec > >>may change to: > >> > >> The web server must append each welcome file in the order > >> specified in the deployment descriptor to the partial request and > >> check wh

Re: [5] Config

On Fri, 16 Aug 2002, Steve Downey wrote: > > This really seems to pick the best APIs for the job. > > It's a good idea to use JNDI for configuration storing indeed, as it > > allows enterprise scale deployments, and seems generally better suited > > than JMX. > > > > Remy > > > > > To the exten

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

On Thu, 15 Aug 2002, Patrick Luby wrote: > Costin, > > [EMAIL PROTECTED] wrote: > > Patrick ( if you read this ) - what's the status with the 'guess home' ? > > I can use IntrospectionUtils - it has the whole thing in it ( home/base > > setting, find in classpath ). We already need IU for jk - i

Re: [5.0] [PROPOSAL] Validation/NamespaceAware

Big +1 ! We can have a small ant-based script that can validate a webapp - find all the XMLs and TLDs and run schema and DTD validation on it. Another nice thing we could do - if someone has the time - is adding 'Serializable' to Context and all other config objects and saving a snapshot. Then

Re: [5.0] [PROPOSAL] Refactored mapper

On Thu, 15 Aug 2002, Remy Maucherat wrote: > Yes, but welcome files for non physical resources cannot be implemented > (since you have no way of asking a servlet if it can or cannot process a > resource). > I'll implement something which works and which is very close to what the > spec require

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

On Wed, 14 Aug 2002, Steve Downey wrote: > See attached patch. I added a method setHomeAndBase() and a couple of > booleans to see if they were set via setters. Ok. I made few changes, I'll commit later. Patrick ( if you read this ) - what's the status with the 'guess home' ? I can use Intros

Re: [5.0] CL delegation order (was: Re: [5][PATCH]Run Watchdog fromthe jakarta-tomcat-5 build.xml)

On Wed, 14 Aug 2002, Remy Maucherat wrote: > [EMAIL PROTECTED] wrote: > > I agree it is valuable in some cases to not delegate - but we've > > seen far too many problems. It's better to let those who > > really need this and know what they're doing turn this on. > > The thing is that it looks

Re: [5.0] CL delegation order (was: Re: [5][PATCH]Run Watchdog fromthe jakarta-tomcat-5 build.xml)

On Wed, 14 Aug 2002, Remy Maucherat wrote: > [EMAIL PROTECTED] wrote: > > I love classloaders and reverse delegation... > > Speaking of which, I think we should stop using the delegation scheme > recommended by the servlet spec (ie, look first in own repositories, > then delegate). The idea is

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

On Wed, 14 Aug 2002, Jean-francois Arcand wrote: > The problem should occurs only with Xerces 2.0.2. Is 2.0.2 bundle with > ANT 1.5? If you try with the current Xerces nightly build, it should > work. This is a big paint because Xerces 2.0.2 seems to be used > everywhereThe only solution w

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

On Wed, 14 Aug 2002, Steve Downey wrote: > First is that o.a.c.startup.CatalinaService doesn't distinguish between > catalina.home and catalina.base. setHome() actually sets both of them. > Adding a setBase() is trivial, but it affects the semantics of > initialization. Any current client expe

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

On Wed, 14 Aug 2002, Steve Downey wrote: > This patch starts up a copy of tomcat with the watchdog war files, runs > watchdog against it, and shuts down tomcat afterwards. It uses the Launcher > to run tomcat in the background, and puts the webapps, work, logs and conf > directories in a tmp d

Re: [VOTE] New committer: Jean-Francois Arcand

+1 Costin On Tue, 13 Aug 2002, Patrick Luby wrote: > I would like to propose that we add Jean-François Arcand as a Tomcat > committer. I believe he has submitted enough patches to show that he > will be a positive contributor to Tomcat 5. > > Thanks, > > Patrick > > -- To unsubscribe, e

Re: [5.0] [VOTE] Release numbering scheme and test releases

On Tue, 13 Aug 2002, Remy Maucherat wrote: > Hi, > > First, a simple vote about the version numbering scheme for Tomcat 5.0. > I think the method used for Tomcat 4.1.x is working well and promotes > quality, although it certainly delayed the apprition of a stable build > of Tomcat 4.1. > I pro

[VOTE] new commiters on tomcat-dev (fwd)

Hi, Please create the accounts for: Ian Darwin <[EMAIL PROTECTED]> Bob Herrman <[EMAIL PROTECTED]> We voted them as commiters on tomcat-dev, with no -1 and plenty of +1s. Costin -- Forwarded message -- Date: Wed, 7 Aug 2002 13:36:06 -0700 (PDT) From: [EMAIL PROTECTED] Reply-

Re: [5.0] Build notes

On Mon, 12 Aug 2002, Jean-francois Arcand wrote: > > I think that the dependency on Xerces 2.0.1 is excessively restrictive > > as well. IIRC (maybe Jean-François could provide some of the details > > he found?), Xerces 2.0.1 was the only Xerces parser that we have found > > so far that does n

Re: [4.1.9] New test milestone released

On Mon, 12 Aug 2002, Glenn Nielsen wrote: > JASPER 2 JSP Page Comiles > - > > I would also like to see Jasper 2 changed so that JSP page compiles occur > externally outside of the Tomcat4 JVM process. There are two reasons for > this: What's wrong with that ? It works j

Re: [5.0] Build notes

On Sun, 11 Aug 2002, Bill Barker wrote: > I don't know anybody that likes it, but it's required by the JSP-1.2 spec > (and still in the current draft of the JSP-2.0 spec). The TLDs may contain > Listeners, and the only way to get them registered is to scan at startup. Ops, I missed that one.

Re: [5.0] Build notes

On Sun, 11 Aug 2002, Patrick Luby wrote: > > IMHO that's _totally_ unacceptable ( having tomcat5 work only with > > xerces). > > I think that the dependency on Xerces 2.0.1 is excessively restrictive > as well. IIRC (maybe Jean-François could provide some of the details he > found?), Xerces 2

Re: [5.0] Problems

I turned off schema and dtd validation, and disabled the JMX stuff - and the startup time is down to earth ( 7 secs ). I'll try to do something about jmx ( put all the processing in a background thread ), the validation should be moved to a deploy stage. The only issue that I can't solve with

Re: [5.0] Build notes

On Sun, 11 Aug 2002, Patrick Luby wrote: > commons-digester/logging, etc. I think that this would make the build > more reliable since Tomcat 5 is dependent on very specific versions of > Apache dependencies (e.g. Xerces 2.0.1 only). IMHO that's _totally_ unacceptable ( having tomcat5 work onl

Re: [4.1.9] New test milestone released

Remy, Let's try to make 4.1.10 the 'stable' release ( and consider 4.1.9 as the 'release candidate ). I cleaned up some of the jk messages and I want to do some more watchdog tests with apache/jk. If everyone agree, I think we should also tag jk2 as 'jk2.0beta' and jk1.2.0 release, even if we d

Re: cvs commit: jakarta-tomcat-5 build2.xml

On Sun, 4 Aug 2002, Patrick Luby wrote: > I would like to see the , , and data > types and the conditional , , and elements > moved to Ant. You'll have to submit patches to ant-dev. But you can very well do the same thing with the current ant1.5 types - the syntax may be a bit more compl

Re: [5.0] Build notes

On Sun, 4 Aug 2002, Patrick Luby wrote: > Bob, > > Bob Herrmann wrote: > > $ sed -e > > 's/^base.path=\/usr\/local$/base.path=\/home\/test\/tc5\/dependson/' > > build.properties.default > t > > $ mv t build.properties.default > > You don't want to replace build.properties.default. Instead you

Re: [5] launcher/deamon

On Sat, 3 Aug 2002, Patrick Luby wrote: > Basically, commons-launcher classloads the ant.jar bundled with Tomcat 5 > (Jasper2 also classloads Ant 1.5). commons-launcher is just a wrapper > for bootstrapping Ant plus some custom tasks and data types. I don't use > Ant's scripts because Ant' bat

Re: [5] New Coyote Branch

On 2 Aug 2002, Bob Herrmann wrote: > Adding to repository "jakarta-tomcat-connectors" a directory; > > coyote/src/java/org/apache/coyote5/ You mean: coyote/src/java/org/apache/coyote/tomcat5 > and in coyote5 the Request and Response classes implement the interfaces tomcat4 Request/

Re: New coyote branch

What about this: - make the changes in CoyoteRequest - after we cleanup/enhance the ActionCode and hooking in coyote - we use it instead ( and support connector attributes and lazy eval ) BTW, it would be quite interesting to have this 'close' to the semantics of JMX notifications. It is nic

Re: New coyote branch

On Thu, 1 Aug 2002, Craig R. McClanahan wrote: > o.a.coyote.Request doesn't have setAttribute() or replaceAttribute() > methods, so I don't see why it would be affected -- only the Servlet 2.4 > version of CoyoteRequest would seem to matter. ??? Are we talking about the same thing ? j-t-c/coyot

[5] Removing some deps in o.a.catalina

This has been discussed long ago ( the MinTC thread, etc ). Curently o.a.catalina package depends on o.a.c.cluster, deploy, net, util. I would like to reduce/eliminate those dependencies. Craig, Remy - what do you think ? Costin -- To unsubscribe, e-mail: For add

Re: Daemon deps

On Thu, 1 Aug 2002, Patrick Luby wrote: > Costin, > > Remy can probably comment on the commons-daemon.jar dependency. However, > the commons-launcher.jar dependency is required for the scripts in the > bin directory. Can you expand a bit ? Catalina itself should't depend on any of those - i

Re: New coyote branch

Justy, You'll also need to change coyote.Request - since it is the real attribute store. As I mentioned, you'll need to add 2 ActionCodes. That's the correct implementation IMHO ( independent of where you put the CoyoyteRequest ). If it can wait a bit - I can help. Costin On Thu, 1 Aug 200

Daemon deps

Would it be possible to remove the dependency on Daemon ? I see no reason why Daemon couldn't use introspection to call start/stop/destroy. Costin -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: New coyote branch

On Thu, 1 Aug 2002, Craig R. McClanahan wrote: > > > Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look >like > > > jakarta-tomcat-connectors has been branched yet. I checked the archives > > > and saw the vote results where it was decided that the HEAD of > > > jaka

Re: New coyote branch

On Wed, 31 Jul 2002, Peter Lin wrote: > Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look like > jakarta-tomcat-connectors has been branched yet. I checked the archives > and saw the vote results where it was decided that the HEAD of > jakarta-tomcat-connectors wi

RE: mod_jk, mod_jk2 URI spaces

On Wed, 31 Jul 2002, Mladen Turk wrote: > > Now I propose that we make something like _not_ URI space > > filtering. Meaning that one could be able to serve every > > .html file through TC except for the /*/some_space/ location. > > Right now we are checking and hoping that the TC will accept

Re: [5.0] mbean-names

On 29 Jul 2002, Bob Herrmann wrote: > > > Same should happen for Log, assuming we get the commons-logging > > to support JMX and add a wrapper for JDK1.4 ( for log4j > > we should just use their mbean ). I assume we all agree on > > moving to commons-logging as API, and keeping the old Logging >

Re: [5.0 - config] jmx names, part 1: domains

On Mon, 29 Jul 2002, Craig R. McClanahan wrote: > > - Each webapp will be associated with one ( or more ) UserDatabases. > > A UserDatabase can be used by one or more webapss ( and other > > applications). > > > > I think a particular webapp would be associated with only one UserDatabase > (alth

[5.0] mbean-names

My comments on mbean-names.html, and possible improvements for 5.0: The biggest problem is the representation of load-balanced tomcats. This is not covered in the current model, and it should ( even if in most cases the attribute will no be used :-) In JSR77 terms, we need to add 'node' attribut

Re: catalina.mbeans package

On Mon, 29 Jul 2002, Craig R. McClanahan wrote: > > As long as we are using modeler - I think we shouldn't have to write > > _any_ custom MBean. > > > > I look forward to seeing how you plan to deal with some of the interesting > cases -- everything from the "users" MBean attribute on the > Memo

Re: [5.0 - config] jmx names, part 1: domains

On Mon, 29 Jul 2002, Craig R. McClanahan wrote: > In the current implementation, the association of webapps to user > databases is *indirect* by virtue of the Realm that is used. You can > share a single user database across webapps, if you want to, in a couple > of different ways: This is a bi

FYI: jk2.properties mx.port setting

I don't know if you are aware of this ( it is somewhere in a commit message): If you add a 'mx.port=' in jk2.properties, jk will try to load the http adapter of mx4j or jmxri. It will also expose all the jk handlers as mbeans ( in jk: domain ). You also need to copy mx4j-tools.jar in server

Re: catalina.mbeans package

On Mon, 29 Jul 2002, Craig R. McClanahan wrote: > > The only place that will prove difficult is when a component's method > implementing an operation wants an object instead of a String or primitive > (say, Container.addChild()). We also have the choice (in Tomcat 5) to > break the existing API

Re: [5.0 - config] jmx names, part 1: domains

On Mon, 29 Jul 2002, Craig R. McClanahan wrote: > > Users:type=Role,rolename=admin,database=UserDatabase > > Users:type=User,username=both,database=UserDatabase > > Users:type=UserDatabase,database=UserDatabase > > > > Yep ... the document only covers the "Catalina" names at the moment. > > In

Re: catalina.mbeans package

On Mon, 29 Jul 2002, Craig R. McClanahan wrote: > Most of the time, you want MBeans to directly delegate attribute read and > write operations to the corresponding component object. Sometimes, > though, that is not possible (for example, when the component getter takes > an actual object, and th

Re: [5.0 - config] jmx names, part 1: domains

On Mon, 29 Jul 2002, Craig R. McClanahan wrote: > I'd focus more on the 5.0 tree to do any major changes, though. Of course. > Are you talking about the UserDatabase global resource in 4.1? This is > actually a global thing, and not a Realm. See below for more. I just enabled the Http 'mbea

catalina.mbeans package

I'm a bit confused of what's in catalina.mbeans. My understanding of model mbeans is that we use the modeler and the xml description - what's the role of all the classes like LoggerMBean, etc ? There is also some logic that goes inside the Mbean wrapper that is very strange - for example Conn

[5.0 - config] jmx names, part 1: domains

Craig - I'm not sure where the current naming conventions for mbeans are defined in 4.0, and how 'frozen' they are. This mail is about the first part of the mbean name - the domain. Curently there are several 'domains' in use: - catalina - used for most catalina objects ( but not sure how this

[Logging] more issues with stack reading

Ok, back to the subject of extracting the method name from the stack trace. The problem is actually a bit more complicated and I think we're doing the wrong thing at the moment, and all proposed solutions are quite bad. What we are trying to solve: display the method and classname that makes th

Re: JSR77 & tomcat5 configuration

On Wed, 24 Jul 2002, Craig R. McClanahan wrote: > In general, my view is that the JSR-77 standards for managed object > names, and the corresponding attributes, are not fine grained enough to > deal with the actual manageable components in a servlet container. We're > going to need many more MBe

JSR77 & tomcat5 configuration

It seems JSR77 has been posted - I think everyone should read it. What's important is the set of naming conventions for the managed objects we expose - I strongly believe that we should use those names wherever we provide the equivalent functionality. For example ( on what is important for me ):

Re: [logging] Better support for stack walking

> 1. For Log4J at least, the wrapper class is 'given' to the logger > implementation via a constructor argument. No, it is passed on each call. Log4j is the easiest, it has all the support we need. > 1.a. Log.setLogWrapper/setAttribute isn't enough. Putting aside > design/style arguments,

Re: Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

On Tue, 23 Jul 2002, Craig R. McClanahan wrote: > > It's the index.jsp that worries me - combined with precompile jsps. > > > > That could be an extremely common case - and will fail with the > > current implementation. > > > > As a workaround, why don't you just include the JSP source files in

Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

On Mon, 22 Jul 2002, Craig R. McClanahan wrote: > In Servlet 2.4 (Community Draft 2), it looks like the language in Section > 9.10 that describes this hasn't changed. The basic rule is that you > combine the "partial URLs" specified in the welcome file list to the > incoming request for a "direc

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c

On 23 Jul 2002, Bojan Smojver wrote: > Before I do that, some questions about uriEnv in jk2_handler(), since > that part is very different to mod_jk. The initial test involves asking: > > if (uriEnv==NULL || strcmp(r->handler,JK_HANDLER)!= 0) uriEnv == null means no match was found. It is set

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c

On 23 Jul 2002, Bojan Smojver wrote: > Important note: > --- > THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC. > - > > Do you want me to: > > [ ] Revert it back to what it was before I put my fingers in it > [

Re: JDK 1.4 Logging

On 22 Jul 2002, Bob Herrmann wrote: > That is an interesting idea, although in my particular case, I walk > the stack a variable amount. Namely if the stack has method "log()" or > method "internalLog()" I keep unrolling the stack - this may not be > a great idea - but it gives good stack traces

Re: JDK 1.4 Logging

On 22 Jul 2002, Bob Herrmann wrote: > This could be fixed by adding these methods to Log of commons-logger > > void trace(Object msg, Throwable thr, String className, String method); > void debug(Object msg, Throwable thr, String className, String method); > void info(Object msg, Throwable th

Re: JDK 1.4 Logging

I'm close to -1 on this patch. I think the right long-term solution is to use commons-logging in all tomcat and jasper, and stop defining our interfaces. I am +1 on fixing commons-logger, this will probably be usefull for other packages that switch to commons-logger. Costin On 22 Jul 2002, B

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

On Sun, 21 Jul 2002, Bill Barker wrote: > At the moment, the servlet-mapping issue is somewhat of a red-herring, since > only 3.3.2-dev supports it (and even there, it is disabled by default). For > now, mod_jk(2) might as well assume that the physical jsp/vm file is there, > since Tomcat requir

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

On Mon, 22 Jul 2002, Bojan Smojver wrote: > > it can already map any URI. All it has to do is: > > - for each index: > > Just reading the algorithm and thinking about the implementation of it. Some of Well, don't take it as an algorithm - there are many other things to consider. > > > The

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

On Mon, 22 Jul 2002, Bojan Smojver wrote: > Quoting [EMAIL PROTECTED]: > > > > Are you referring here to mod_jk2 only or both mod_jk 1.2.0 and > > mod_jk2? > > > > I think it could be done for jk2 ( but not easy ). I'm not sure > > about 1.2 - just forwarding and letting tomcat handle > > it is

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

On Mon, 22 Jul 2002, Bojan Smojver wrote: > > You don't need to ask tomcat - jk should have all the mappings, and > > it can already map any URI. All it has to do is: > > - for each index: > > -- concatenate with the current uri > > -- do the jk mapping ( or internal redirect if you use

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

On Mon, 22 Jul 2002, Bojan Smojver wrote: > Which is how it used to be in the old code anyway. And that means that > DirectoryIndex should not be used if you don't have physical files in the right > places (with the current patch level in mod_jk 1.2.x for Apache 2) or in virtual > places (with th

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

On 22 Jul 2002, Bojan Smojver wrote: > If there is no physical file, then nothing will get done by the patch at > all (since r->finfo.filetype is 0). It won't affect mod_dir's old > behaviour at all. I'm not sure how that changes things... My question was: if you have a precompiled index.jsp, th

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c

On Sun, 21 Jul 2002, Mladen Turk wrote: > All that I'm trying is to skip the need to use the Apache machanism for > the uri-space->file-space translation. > If the TC says that _its_ uri-space can be translated to the file-space > only than map_to_storage can provide the real finfo and serve the

RE: [PROPOSAL] Split the repo's

> > jakarta-apis/jsr154/src/java > > jakarta-apis/jsr152/src/java +1 as well. Costin -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [PROPOSAL] Split the repo's

On Thu, 18 Jul 2002, Jon Scott Stevens wrote: > > But that's not the reason > > I'm voting against - we already have too many CVS trees and this is > > bad organization, it could be well placed in a single CVS in separate > > directories. > > > > Having a separate CVS for a dozen of files inste

Re: [PROPOSAL] Split the repo's

On Wed, 17 Jul 2002, Jon Scott Stevens wrote: > [X] I don't want the API's split into separate repo's > [ ] I don't care > [ ] I want the API's split into separate repo's. I'm pretty sure Jon is not proposing this for the benefit of tomcat or tomcat users, but out of his hate for JSPs. But that

Re: Missed vote

On Wed, 17 Jul 2002, Jon Scott Stevens wrote: > on 7/17/02 3:50 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > As I said, xml.apache.org is packaging 3 APIs from 3 different and > > unrelated sources in a single repo and jar ( DOM, SAX, JAXP ), and > > that was discussed and aproved by

Re: Missed vote

On Wed, 17 Jul 2002, Jon Scott Stevens wrote: > We are also talking about the next version of the Servlet API (5.0) which is > based on the work of JSR 154...not JSR 053. JSR 154 is specific to the > Servlet API and is not working on JSP. So, it no longer makes sense to have > the two together fo

Re: Missed vote

On Wed, 17 Jul 2002, Jon Scott Stevens wrote: > > Until the JSP 2.0 spec is changed, it make less sense for us to > > have two separate repos. (It just make more sense to put > > javax.servlet.jsp.tagext.TagInfo with javax.servlet classes). > > They can be in separate repo's with the same packa

Re: $ in JSP names

On Mon, 15 Jul 2002, Kin-Man Chung wrote: > I think you and Craig are both right. So how about using a "_" instead of > a "$"? +1 ! Costin > > > > Date: Mon, 15 Jul 2002 12:48:18 -0700 > > From: Arvind Srinivasan <[EMAIL PROTECTED]> > > Subject: Re: $ in JSP names > > To: Tomcat Developers

$ in JSP names

I just upgraded to jikes1.16, and I get one warning for each JSP file I compile: "Lexical: The use of "$" in an identifier, while legal, is strongly discouraged, since it can conflict with compiler-generated names. If you are trying to access a nested type, use "." instead of "$"." In addition

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/confConfig.java package.html

On Fri, 12 Jul 2002, Bill Barker wrote: > I know you hate interfaces :-), but this really does look like it should be > an interface at the moment. What about abstract class :-) ? The major reason I don't like interfaces is backward compatibility issues ( like the ones we see in JDK1.4 Connect

Re: [4.1][5.0] Jasper branch

Larry, Could you create a branch in jakarta-tomcat as well ? Not very urgent - getting coyote and the other parts working is more important for now, but eventually I want to make interceptors work with 5.0, and that should be in the main branch. Costin -- To unsubscribe, e-mail:

  1   2   3   4   5   6   7   8   >