RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
On Thu, 29 Mar 2001, Mel Martinez wrote: activities that should be orthogonal. The only dependency should be that the Compiler is a consumer of the products of the Mangler. +1 I think the problem starts with the idea to make a JspLoader that 'loads JSP files just as if they were JspLoader is a special thing - it's a great idea ( well, the new model used by JspInterceptor does the same thing in a much cleaner way ). But in any case, should be independent of everything else - just a component that may be used by the "container adapter" classes. Costin classes'. That then broke down into creating a Jsp Compiler that turned JSP files into classes. That finally breaks down when you realize that you have to have an actual javac compiler to turn the .java files into classes. The JspCompilationContext (originally the JspEngineContext) was an attempt to tie all these together with one big payload to carry information around with. But all that information isn't needed in every place and further, some of that information would be better and more efficiently retrieved elsewhere than from the JspCompilationContext. By this I mean that currently the JspCompilationContext provides information relevant to the page life cycle such as the JspFile, the OutputDir, Servlet Class and Package names, etc. etc. - yet JspCompilationContext is a _request_ level object! It is created once for every request! This has got to be refactored. Basically, there are some distinctly separate services used during the jsp page life cycle and the request life cycle that should be factored out and made distinct from each other. More later. I've got to go interview someone. Cheers, Mel The classes that implement JspCompilationContext look to me like they don't all belong in the same package, unless everything here is in the same package. They are interface classes between the Jasper compiler and the outside invoker of the compiler. Here are the classes I'm talking about http://www.panix.com/~sdowney/compilers.gif and the entire compiler package http://www.panix.com/~sdowney/org.apache.jasper.compiler.gif (courtesy Together J) This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
On Wed, 28 Mar 2001, Steve Downey wrote: The second most common cause of bugs in Jasper is confusion over when to use File.separator and when to use '/'. It's hard to keep track of, since Jasper does deal with both files and URIs. And the File methods are used to regularize some URIs. Another reason to refactor. I would say this is also part of interfacing the jasper with the container, and not core to the jsp parser and jsp-java convertor ( which in my opinion represents the "core" of jasper ). There is the problem of importing jsps ( and few other cases where files are needed), but again that's related with the API that is needed to plug jasper into a ( cooperating ) container. Costin ( BTW, my interest is more in the jsp-java convertor area, I would be interested to try a more customizable generator that would use XSL templates, but that depends on a modularization and refactoring that would make the generator a clear and replaceable component. This is a long-term plan, of course - some people will kill me if I don't start working on charsets and encodings )
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
Mel, Regarding the names and the scope of the changes. If we are going to do some refactoring ( and that's going to require work and testing anyway), then we should do it on a slightly broader scope, not only local to the servlet interface. Instead of org.apache.jasper.servlet33, I would suggest something like org.apache.jasperX.*, and have separate packages for the different components that we identify ( see my proposal for 5 components - some of them like the java-class compiler or even the mangler are general-purpose for any scripting system and could even be part of the an util package ). What would be really great is to coordinate this with someone on jasper4.0 side - we should be able to share most components, except probably few classes in the JSP generator ( and of course the runtime - which implements security and is heavily dependent on jsp1.2 ). Most of the parser and generator is identical, and I think we would all benefit by sharing as much as is possible. In other words - it would be great to try to make this proposal not limited to jasper33 servlet, but a jasper7.3 ( 4.0 + 3.3 ) proposal, refactoring and combining the 2 ( now divergent ) versions ( while keeping and increasing the ability to have alternative implementations for all components - like the runtime and some of the generator ). Of course, it's your choice - I will support a limited refactoring if that's what you want, but I think we should at least try to combine our efforts and re-unite ( at least ) jasper. Then all the optimizations ( like tag pooling ) and fixes and the sandboxing will be common for most part, with clear container-specific modules ( that would also prove and show how other containers can use jasper ), Costin On Wed, 28 Mar 2001, Mel Martinez wrote: Wow! I go away for a day and there is some great discussion on this thread! I've saved everybody's comments and will incorporate them into the proposal, which I will be working on tonight to formalize. When I've got it ready for review, I will put a proposal doc and any related files in html form into .../jakarta-tomcat/proposals/tomcat33/ From the discussion I think it is safe to say that the goals of this refactoring are: 1) focused primarily with cleaning up the object model of the org.apache.jasper.servlet package (i.e. JspServlet) so that we can reduce coupling between JspServlet and the core of Jasper. 2) we will try to increase separation between the JspServlet entry point into jasper from the various life-cycle services (class loading, mangling, compiling, etc) to make those services both replaceable for JspServlet and also reusable for alternate entry points, such as JspC or JspInterceptor. 3) we will try to clarify classpath and init-params configuration issues. 4) despite all this, we will strive to improve performance by reducing the call stack and by utilizing caching where possible. 5) fix more bugs than we introduce. I should have a first-draft class diagram and probably initial java code ready for the proposal tonight or early tomorrow. I tentatively propose to introduce the changes through the package name 'org.apache.jasper.servlet33', unless anyone objects AND has a better package name. :-) Cheers, Dr. Mel Martinez G1440, Inc. --- Steve Downey [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 3:46 PM To: [EMAIL PROTECTED] Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet On Wed, 28 Mar 2001, Steve Downey wrote: The second most common cause of bugs in Jasper is confusion over when to use File.separator and when to use '/'. It's hard to keep track of, since Jasper does deal with both files and URIs. And the File methods are used to regularize some URIs. Another reason to refactor. I would say this is also part of interfacing the jasper with the container, and not core to the jsp parser and jsp-java convertor ( which in my opinion represents the "core" of jasper ). There is the problem of importing jsps ( and few other cases where files are needed), but again that's related with the API that is needed to plug jasper into a ( cooperating ) container. SNIP ... importing jsp text, determining the file to write java to, finding tag library descriptors, finding the directory to direct the java compiler to write class files to... Files are inherent, at least as long as javac insists on having files. I would love to be able to compile a stream, or array of streams, but that's not happening near term. Almost everything else uses URI's to refer to things. So, for the most part, jasper should not be looking at, or using, files. Streams, yes, as in getResourceAsStream, but mostly not Files. Most
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
On Wed, 28 Mar 2001, Matthew L Daniel wrote: ( BTW, my interest is more in the jsp-java convertor area, I would be interested to try a more customizable generator that would use XSL templates, but that depends on a modularization and refactoring that would I remember back in the "old days" when the JSP spec actually contained a representation of JSP syntax as XML tags (jsp:expression and whatnot), but Tomcat didn't support it because (as I recall) Sun deprecated it. I'm with Costin, I think that would be/was just super-cool. The XML syntax is part of JSP1.2, but the JSP parser can easily generate SAX events from a "normal" JSP that match the 1.2 XML representation. Just to make clear - this is more of an experimental/cool/maybe project, and a refactoring that would allow other generator modules to be plugged in would make possible to do this kind of experiments while sharing the same infrastructure and without hurting jasper's stability ( i.e. I'm not proposing to replace the current stable code with some cool stuff - just to make things more modular so experiments in code generation can happen). I think Mel's original proposal had this right - developing the new JspServlet interface along with the old one, and allowing the user to use either ( until the new one is clearly ready and we can deprecate the old one ). Same should happen in the generator, compiler and for all other components of jasper. And the good news is that the refactoring shouldn't be very difficult - the most important thing is to agree on the components, move the code in new packages and then try to simplify the interfaces. After that we can test and make sure we still have the good jasper, and start playing with new JspServlet, parsers, generators, manglers, etc. Costin
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
1) I don't off-hand know of any other generalized way to make a portable JSP compiler that can be plugged into any servlet 2.2 engine other than as a servlet. I'm not sure how that limits us feature-wise, other than the fact that it adds a layer of indirection between the request on the container and the actual ultimate jsp servlet. A small performance price to pay for portability. The only problem is that the price is much higher that that: - JspServlet must manage the servlet lifecycle - the container can no longer treat jsp-generate-servlets the same as regular servlets - initialization - how can you pass init parameters to the jsp ? This is one of the worst hacks and source of counteless problems ( AFAIK - I couldn't find any clean way to do that ) - class loader problems - again, the JspServlet must duplicate and override the class loading decisions of the container - other problems and issues My point is that the servlet abstraction may not provide enough API support for what jasper need - in order to make it work you have to duplicate services that should be ofered by containers ( class loading, init, reloading, admin, etc ). I don't want to discourage you from doing that - any refactoring will help and we badly need that. I just want to give you an alternate view, based on my experience - before you repeat mistakes we've already done :-) 2) One major point of the refactoring is to minimize the role that the JspServlet plays. In the model I'm advocating it only does a couple of things: initializes jasper (i.e., creates the JspFactory) and maintain a cache of JspPageHandlers to which it passes the requests. Given this, the same role could be played by other entry mechanisms. +1 Costin
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
- JspServlet must manage the servlet lifecycle - the container can no longer treat jsp-generate-servlets the same as regular servlets This is a limitation of the servlet api and thus the lack of access to a consistent set of servlet engine features necessary for full servlet life-cycle management that can be relied upon. Besides, who said that the container was guaranteed full-lifecycle management of ANY servlet? Any servlet could be created/loaded dynamically and managed by some other servlet without the container ever knowing about it (assuming the SecurityManager allowed it, of course :-). True, but a container can be smart ( and unload unused servlets, provide nice monitoring, etc ). - initialization - how can you pass init parameters to the jsp ? This is one of the worst hacks and source of counteless problems ( AFAIK - I couldn't find any clean way to do that ) How exactly do you solve this with JspInterceptor? A JSP is treated the same way as a servlet - it gets a ServletConfig with the right info from web.xml, etc. There is no distinction between the way a regular servlet is treated and a jasper-generated servlet. The specification doesn't really seem to cover init-params for individual JSP pages. The JSP ??? servletjsp-file/foo.jsp/jsp-file init-paramnamefoo/name.. AFAIK you should be able to define init params for jsps the same as you do for servlets ( unless I'm missing something here). container has no responsibility to provide individualized init-params for JSP servlets, only to invoke jspInit() prior to service(). In the absence I thought it does... Even tought that never worked very well :-) The glass is half-full as well - because at least with the servlet api it is _possible_ to implement those services portably and thus provide a portable JSP compiler. Almost everything is possible ( in a turing machine :-). The problem is at what cost, and if that's the best solution. And again - what is the alternative? I can't write a JspInterceptor solution for WebLogic or JRun. Unfortunately that's true - and it's a good reason to have JspServlet. But if you have control over the servlet container ( for example using an internal extension mechanism - like the interceptor in tc3 or valve in tc4 ) it would be much better to use a rich API that allows full control over jasper, and lets the container do what it is supposed to do - manage servlets. The mistakes aren't in using a servlet-based approach. This sort of feature (a plug-in to provid jsp compilation and loading services to a web server) is exactly what servlets are for. This in itself in no way limits what you can do with JSPs because all features of the JSP spec should be attainable through a servlet implementation. I'm still looking for a solution to deal with the init-param ( except for re-parsing web.xml ) I'm not saying it's a mistake to have a servlet-based approach, but that having a full API and letting the container manager servlets and jasper do the compilation could be a better solution. The way to look at it is that a JspInterceptor-style solution is a value-added feature of the tomcat servlet engine. That is a positive. The portability of JspServlet is also a positive. +1 ( and to my defense - I did the fixes to allow JspServlet to be still be used in tomcat 3.3, for people who want a slower jsp :-) Mel, what I'm trying to explain is not that JspServlet is bad, but that we need a refactoring to expose more if Jasper API and cleanly separate the components - so we can use JspServlet and interceptors ( or valves ). A lot of the code in jasper is written with the assumption that JspServlet is the entry point ( i.e. with workarounds and hacks for this case ) - and then we have JspC and JspInterceptor that adds another round of hacks and workarounds. And it would help a lot to keep this in mind while doing the refactoring - i.e. to distinguish between what's jasper's core functionality ( convert a .jsp file to a java file ) and what's a hack and duplication of container's functionality for JspServlet's use. For example JspLoader, some of the manglers, some of the JspEngine and context. If we are going for a refactoring, it would be a good idea to clean up and fix more than just JspServlet. Costin
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
On Tue, 27 Mar 2001, Craig R. McClanahan wrote: The glass is half-full as well - because at least with the servlet api it is _possible_ to implement those services portably and thus provide a portable JSP compiler. When Tomcat 4.0 was created, one of the goals was to eliminate all the Jasper dependencies on servlet container code (with the goal of a portable JSP environment). We were completely successful except for two (initially) and now only one issue: specifying a classpath for the Java compiler. ... The portability goal is definitely achievable in a Java2 world. The only problem is that maybe trying to make jasper independent of the container is the wrong goal... The price is ugly ( or at least complex ) and inefficient code ( not only because of the overhead, but also because of the missed oportunities for optimizations ). A quick test is very simple - in 3.3 compare the speed of running jsps via JspServlet and JspInterceptor. ( or with the JspServlet in 4.0 if you think the 3.x JspServlet is bad ). I'm not saying that having a JSP implementation packaged as a servlet and reimplementing functions of the servlet container is bad or impossible - just that a solution where the container does servlet management and jasper deals with converting jsps to servlets may result in cleaner code and better performance. I don't remember reading anywhere in the JSP spec that jasper must be implemented as a servlet, or that it must be independent of the servlet container. And I don't think having a good design for jasper's API that allows it to take advantage of the container would make it less portable - and JspServlet can still be used to plug jasper in un-cooperating containers. So far jasper has been one of the most stable pieces on tomcat ( most bugs I know about are related with the interfacing between jasper and the container ). And it has a huge potential for performance improvement - if we do the right refactoring and provide the right internal APIs. Costin
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
Hi Mel, In my view, jasper is composed from at least 5 big components: 1. The jsp-java translator. 2. The java-class compiler 3. The Mangler ( managing name mappings ) 4. Runtime - that should be completely independent of all other pieces, since jasper-generated servlets should run without jasper ( as simple servlets ) 5. Interface with the serlvet container ( JspServlet, JspInterceptor and the associated classes). ( putting all other components togheter ) My understanding is that your proposal is related with (5), and it seems it has the great property that it can be done as a proper refactoring - without chaning any functionality, just by providing better communication and code organization ( as the first stage ), and then by creating one module ( that will eventually replace JspServlet ). Since this is my favorite "modus operandis" I can't say anything than a big +1... There are few issues: - Impact on 3.3 release cycle. I hate delaying it - it's clear we need another milestone, but I believe in the "release early and often" ( and on schedule :-). I tried very hard to decouple the components as much as possible, so development on any component shouldn't affect the overall release ( and the rest of the code ). That would be resolved by your proposal to use a separate package name - the new ( "in development mode" ) code can be developed in a proposal space and released separately and be included in a 3.3.1 for example. I think keeping "old, stable" code in paralel with "new, better" implementations and doing a gradual replacement is a very good strategy ( AJP1.1 - AJP1.2 - Ajp1.3 - Ajp1.4, mod_jserv - mod_jk - mod_jk+webapp, facade22 - facade23, etc ). - The other 4 components of jasper are also in a big need for a refactoring. I think we'll see a lot of improvements in jsp-java generation, and it would help a lot to be able to modularize it even more. We clearly need a refactoring to allow you to plug the new JspServlet, and we should extend it to at least the point where we cleanly separate the components. - Jasper 4. This will increase the divergence between jasper3 and jasper4. I spent some time trying to find a way to merge the 2, and I gave up because of the current complexity. If a similar refactoring is done in both sides ( since at least 90% of the code is still common ), and as result of refactoring we can merge the common code in a set of common components - then we might get more people involved and avoid a lot of time waste. - Class loading and other interfacing problems. As I said many times, I don't think JspServlet is the right way to plug jasper in a container, but a richer interface exposing more of jasper. Having a working JspServlet for quick-plugin is great, but I think we should rather focus on keeping it just a small facade to a better designed and more powerfull internal API. In any case, a refactoring can only help, and you have my +1 ( i.e. I think it's a good idea and I'll help !). ( BTW, I'm looking into an alternative/experimental implementation for the jsp-java component, probably after 3.3 - as a standalone add-on module. I have few ideas - but I want to first do a prototype ) Costin On Mon, 26 Mar 2001, Mel Martinez wrote: As hinted at last week, I'd like to propose refactoring some of the classes in Jasper to improve the OO model a bit, make maintenance/extendability a bit easier and hopefully help the performance a bit as well for those of us using jasper as the JSP engine in other servlet engines (other than tomcat, that is). There are problems with using the current Jasper in other ServletEngines that do not show up with the tomcat JspIntercepter that need to be addressed. I'd like to refactor JspServlet, JspServletWrapper, JasperLoader, JasperEngineContext and JasperCompiler to better divide responsibilities along the following lines: JspServlet - entry point for JSP page (*.jsp), initialize Jasper and maintain cache of jsp servlet wrapper/handlers, otherwise do very little but pass on the request to the handler. I.E. represents the scope of the jasper engine. Possibly rename this to JasperServlet or just 'Jasper'. JspServletWrapper - rename as 'JspServlet/PageHandler' (or similar) and make this a full class (i.e. take it out of JspServlet). This class manages the life cycle of a single Jsp file, including methods to resolve relevant file paths (i.e. to .jsp file, .java file, .class file), package/class name mangling and modification checking. This class would be responsible for managing dynamic reloading of an out-of-date page. Only one instance of this class is created per page for the life JVM (or more accurately, for the life of the JspServlet). JspRequestWrapper/Handler/Context - encapsulate information relevant to one request - this would implement JspCompilationContext, since a compilation would be one possible event during the request. However, we'd remove some of the
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/sessionSimpleSessionStore.java
Temporary(?) fix to stop crashes when creating a new Session in embedded use of Jasper (i.e. as standalone JspServlet ). Problem may occur in other situations as well, I'm not sure. Problem: When SimpleSessionStore.SimpleSessionManager.getNewSession() is called (as a result of a call to request.getSession(), the session ID of the new session has not been set. Since it is implemented as a MessageBytes Hi Mel, I looked at that and I couldn't reproduce it - are you sure you have the right configuration ( i.e. SessionIdGenerator included in server.xml ) ? getNewSession is calling setState( STATE_NEW ), that calls the sessionState callback that allows modules to initialize the new session object - and SessionIdGenerator is setting the id ( using whatever random). I can't understand what's wrong - my only guess is that SessionIdGenerator is not included. I didn't had too much time this weekend ( to restart the nightly tests ), but I hope to resolve those issues soon. Costin object, the .toString() method to get a string representation of the session id returns null. When getNewSession() tries to use this value as a key into the sessions hashtable, a NullPointerException is thrown.
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
1. In general the Java SecurityManager implemenation in Tomcat 4 and Jasper has significant improvements and is much cleaner. True. The SecurityManager in 3.3 is working fine for now ( Glenn is also the main author for the 3.x sandboxing ), with all watchdog passing - but a refactoring will help cleaning up the code. 2. Jasper class loading is much simpler in the Tomcat 4 version. It uses a single URLClassLoader for each JSP page, this allowed me to simplify a great deal how Jasper handles generation of class and package names (no more need to do incremental .java and .class files). And it removed alot of overhead at both JSP translation and runtime when Jasper tries to figure out which incremental class file to use/check. This sped up JSP compiles by 33% and runtime execution by 25%. Well, I have to disagree here :-) It is indeed much simpler than the 3.2 jsp class loading, and using URLClassLoader is a step in the right direction. Tomcat 3.3 is also using URLClassLoader ( for everything - except the JDK1.1 replacement that has the same interface and replicates URLClassLoader ). I would say the incremental .java is not a bad idea, and the code to support that is reasonably simple ( and provide some unique benefits related with reloading and avoiding some special cases ) - it should be trivial to make it optional ( if anyone feel the need ). We don't use a class loader per jsp page ( since it isn't needed - given the versioning ), but again it would be easy to add it. In any case - at least the class loading is just fine in 3.3, no need to fix it ( but I think everyone would be happy to have more options - like what you mention about one class loader per jsp and no versioning - as long as this is not mandatory and doesn't replace the other scheme ). And before you ask, I just don't have the time to back port these changes in TC3.3. Well, it would help a lot if you could at least take a look and review the sandboxing for 3.3 :-) Security and sandboxing are very difficult, and you probably have the most experience with that. On a related issue, I would be very interested in re-commiting some of the original patches ( defining the permissions in server.xml in addition to the policy file ), this would help a lot in the future admin interface. Again, we might need your help ( if you still have them around ) :-) Costin Regards, Glenn Mel Martinez wrote: As hinted at last week, I'd like to propose refactoring some of the classes in Jasper to improve the OO model a bit, make maintenance/extendability a bit easier and hopefully help the performance a bit as well for those of us using jasper as the JSP engine in other servlet engines (other than tomcat, that is). There are problems with using the current Jasper in other ServletEngines that do not show up with the tomcat JspIntercepter that need to be addressed. I'd like to refactor JspServlet, JspServletWrapper, JasperLoader, JasperEngineContext and JasperCompiler to better divide responsibilities along the following lines: JspServlet - entry point for JSP page (*.jsp), initialize Jasper and maintain cache of jsp servlet wrapper/handlers, otherwise do very little but pass on the request to the handler. I.E. represents the scope of the jasper engine. Possibly rename this to JasperServlet or just 'Jasper'. JspServletWrapper - rename as 'JspServlet/PageHandler' (or similar) and make this a full class (i.e. take it out of JspServlet). This class manages the life cycle of a single Jsp file, including methods to resolve relevant file paths (i.e. to .jsp file, .java file, .class file), package/class name mangling and modification checking. This class would be responsible for managing dynamic reloading of an out-of-date page. Only one instance of this class is created per page for the life JVM (or more accurately, for the life of the JspServlet). JspRequestWrapper/Handler/Context - encapsulate information relevant to one request - this would implement JspCompilationContext, since a compilation would be one possible event during the request. However, we'd remove some of the current behavior in JasperEngineContext that is really page-lifecycle behavior that belongs in the JspServlet/PageHandler. This class should be a lightweight information payload used by the page handler, loader and compiler for fullfillment of the request. By reducing the number of fields to only those that are request-specific and possibly by object pooling, the impact of instance creation (necessary for each request) can be greatly reduced. JasperLoader, Compiler, and a few other classes would be refactored (actually simply extended slightly through subclassing) to support these mods. Some of the current behavior would be refactored out to the page life-cycle handler. Compilers can probably be pooled for reuse. Along with the
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/sessionSimpleSessionStore.java
However, this does point to the need for default behavior of tomcat session generation code (or any interceptor or module code) in the absence of expected configuration info in server.xml. That's a good point, but I'm wondering how could it be implemented. The whole idea of modules is that each can be replaced with a better version ( for example a more secure or more efficient scheme to generate the ids ), so we can't just check for specific modules. Well, there is a solution ( I'm not sure how can we code it ) - have an automated way to run watchdog and sanity to validate the config files. If watchdog/sanity are passing - then probably the config is valid :-) Costin Mel getNewSession is calling setState( STATE_NEW ), that calls the sessionState callback that allows modules to initialize the new session object - and SessionIdGenerator is setting the id ( using whatever random). I can't understand what's wrong - my only guess is that SessionIdGenerator is not included. I didn't had too much time this weekend ( to restart the nightly tests ), but I hope to resolve those issues soon. Costin object, the .toString() method to get a string representation of the session id returns null. When getNewSession() tries to use this value as a key into the sessions hashtable, a NullPointerException is thrown. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
On Mon, 26 Mar 2001, Steve Downey wrote: 1. The jsp-java translator. 2. The java-class compiler 3. The Mangler ( managing name mappings ) 4. Runtime - that should be completely independent of all other pieces, since jasper-generated servlets should run without jasper ( as simple servlets ) 5. Interface with the serlvet container ( JspServlet, JspInterceptor and the associated classes). ( putting all other components togheter ) Layer 5 has to include the JspC/CommandLineXXX components, also. They have to provide an environment that looks to the rest of the JSP compiler like a web context, while actually interacting more closely with the filesystem. Yes. In fact a lot from JspInterceptor is inspired/derived from JspC. But the JspC is very special because it can be use to pre-compile applications - that would be great for special configurations or only the jsp runtime is included ( say an embeded tomcat, or a minimal environment). It should be possible ( after a bit of refactoring ) to create a mini distribution using only the core, a sub-set of the modules, jasper-runtime ( no xml parser or jasper converter or javac ), plus JspC-processed webapplications ( what's missing is a piece to serialize web.xml - for server.xml there is EmbededTomcat, and it shouldn't be difficult to automatically generate a java class that will have the same effect with reading web.xml - maybe using serialization ). I would bet on a result below 500K :-) ( most of the code is easy to port to J2ME, BTW - we just need volunteers :-). Mangler needs some work, too. JspC and JspServlet have drifted in their implementations. The bane of code sharing by cut and paste. Refactoring is the keyword :-) Merge what's duplicated, use the mistakes to define better interfaces between components. The mangler in 3.3 is slightly better ( forgive my lack of modesty here ), and I would also say the JspInterceptor is at least a simpler way to plug jasper ( compared with JspServlet ). Costin
Thread pools
Hi, The thread pool changes are almost done, with better interfaces and monitoring and even less coupling ( it no longer uses the Log, but generates Events - the only dependency is now JDK1.1 ). The code is almost the same as functionality ( except for additional sugar ), and should replace the old one without problems. The main benefits are the fact that the same pool can be used for all tasks ( http, ajp, session expiry, etc ), and we can better monitor what's happening inside ( by adding a Listener that will receive notifications for all relevant steps ). An admin page will be added later. Larry - let me know if you are ok with checking it in. I'm confident the code is as good ( or better ) than before, but this is a very important component. We can keep it as an experimental module - in /proposals - and keep the old code as default. Having fewer threads is not that important. Another option is to check this in the commons-sandbox workspace. There are other projects using thread pools, and we may have a chance to share it and merge it with other ideas. This can be done in paralel - and if/when the sandbox code is stable we can start using it ( replacing or as an alternative to the old thread pool ). What do you think ? I'll probably go ahead and check it in sandbox first, and after a bit more testing I'll ask for a vote. Costin
Re: bug in SimpleSessionStore/ServerSession id
Hi Mel, I'm working on the SimpleSessionStore, it had problems with recycling the ServerSession objects and I tried to fix them while removing some complexity and spaghetti code. I'll check that - probably after this weekend I'll be done with the session and threading changes. Regarding MessageBytes - it must be able to store null ( it's a holder for a String - which can be null ). The session Id can also be null, before it is set by the session id generator, and is also null after the session expires. So the fix is not in not returning null, but in making sure the code that uses the session id will access it when the session is in the right state. Defining the state of a ServerSession object is not yet completed, and it would certainly help to get some review - as well as for the other core objects. Costin On Fri, 23 Mar 2001, Mel Martinez wrote: I posted on this earlier (last night), but the tomcat-dev list is now so slow that I don't know if it ever really made it to the list. I'm encountering a bug now in SimpleSessionStore. In the inner class (gawd I hate inner classes :-)) SimpleSessionManager's getNewSession() method, a NullPointerException is thrown when the method tries to add the new session to the 'sessions' hashtable because the newly created session ID is null. This happens because, as near as I can tell, it is never set. I'm not sure who is working on this code or why it is not getting set, but it is very reproduceable - every time I try to access any servlet it crashes! :-) My app does not depend on sessions (we use a portable, non-servlet API dependent session management system) so it would be nice if this bit of code wasn't crashing on me. In my early post, if it ever made it, I proposed altering the MessageBytes.toString() function to never return a null (I think it is very bad form for a non-null object to return a null value from it's toString()) and instead simply return "null". However, I realize now that MessageBytes is a bit special in that it has a type T_NULL and that this could have larger impact if other code relies on this. Thus, I'd leave this for someone more knowledgeable with how MessageBytes is used to make that change if at all. The only thing I can think of to do right now is to modify the getNewSession() method to check the returned String representation of the session's id to see if it is null. If so, use "null". This fixes the crash and shouldn't, I believe, cause any new problems since the dang thing is null at this point anyway. I'm going to go ahead and commit this change, if this is bad, let me know or go ahead and change it back - but if so, please fix the underlying problem. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: mod_webapp status?
The original intention for mod_jk was to use APR whenever it's ready. Gal wrote most of the "general" code trying to stay as close as possible to APR semantics. Since mod_jk is using just a few APR-like functions, the transition woulnd't be difficult - but it's important to do it at the right time. And IMHO that should come as a decision from tomcat-dev - I would feel very bad if Henri or Dan would decide to switch to APR without a serious discussion on tomcat-dev. And at this moment I would be strongly -1: APR is still beta, while tomcat is used in production, the code we use works and has been ported on most platforms we care, the extra overhead will hurt users, and I don't know any real-world use of APR as a portable runtime with NES or IIS or AOLServer - it should work, but I need to see at least one proof before we start depending on that. Of course, I can't -1 something in mod_webapp - since nobody asked or proposed or discussed any of the mod_webapp developments ( or even requirements, or anything else for that matter - except announcements about the progress ). Costin On Thu, 22 Mar 2001, jean-frederic clere wrote: GOMEZ Henri wrote: No, that is not exactly the goal of APR, it is USED by APACHE2.0 but should/could be standalone. But it means probabably 2 portables run time for the non-Apache servers. I prefer to use apr_socket_create() than to see several #ifdef #else #endif in mod_webapp, the portability problems should not be solved in mod_webapp but in another layer. I agree and that's the main advantage of APR. But you'll see on a Tomcat list question like 'How to build APR ?', 'Where to find a APR.DLL ?'. This could be the answer: That means apr.so could/should be downloaded independantly from Apache. (And will be in Apache2.0).
Re: mod_webapp status?
On Thu, 22 Mar 2001 [EMAIL PROTECTED] wrote: You are 100% correct. Let me give a bit more detail. Covalent is currently using APR in many of our modules that work with Apache 1.3. This is actually harder than a module that works with a different web server, because there are some overlapping concepts that don't match exactly between APR and Apache 1.3. Ryan, Using APR ( or beeing able to use APR when ready ) was one of the design decisions in mod_jk, and most of the "generic" code was done using similar "interfaces" ( with what was at that time in APR ). We all agree APR is a great piece of code - the only problem is finding the right time to switch to it. And having APR released and tested with other servers ( IIS, NES, AOLServer ) is important. One question - is it possible to build only a subset of APR ( i.e. the set of functions that are actually used ) ? Costin APR is a great piece of code, that really makes ANY C code portable, regardless of whether it is integrated with Apache 2.0. There are functions to convert from OS specific types to APR types so that we can work with other programs. Please, keep me on this discussion, I want to be sure that if there are any questions, I can help where possible. Ryan ___ Ryan Bloom[EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: Deployment Descriptor Editor
On Wed, 21 Mar 2001, Aaron Mulder wrote: I'm wondering if Tomcat won't eventually have a separate custom DD for WARs (like WEB-INF/tomcat-web.xml or whatever), in which case we'd want to create a Tomcat plugin in addition to the standard servlet spec. That would be great, a deployment tool is one of the biggest missing things in tomcat. At least in 3.3 we do use a conf/app-xxx.xml ( which is not included in the original WAR - since it can contain security-related settings ). The WAR and web.xml should contain all the informations, the extra config is used only to tune server-specific configurations ( like log, auth, etc - very specific to the server installation ) I'll download it right now. Costin
Re: Linux IBM JDK + Tomcat + SMP hangs
I don't think we can or should do anything about that. Even if it would be possible to find a workaround ( and that may take a huge amount of work ), fact is that the JVM will still have a bug and some user code ( servlet, etc ) may make it hung in production environment. So you should consider luck that tomcat hungs early :-) I suspect it's a glibc problem, so maybe using the latest glibc would help. Costin On Thu, 22 Mar 2001, Scott Sanders wrote: The box's environ is 3 * p-pro/200 + 256Mb Redhat Linux 6.2, kernel 2.2.14smp Apache 1.2.19 Tomcat 3.2.1 using mod_jk (also happens with 3.1 using mod_jserv) glibc 2.2.2 thanks mac I am running a RH 7 box with 4 Xeon 450's with 2GB RAM, running both Tomcat 3.2 and Resin 1.2.1 behind Apache 1.3.17 with IBM JDK 1.3, and it has been running for months ;-)
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java PageContextImpl.java
On Fri, 23 Mar 2001, Casey Lucas wrote: I noticed that for PageContextImpl you made a comment about removing the log dependency. Was this just because it was used on a case that "shouldn't happen" or is there another reason why jasper components shouldn't rely on tomcat logging code? The log was used only to report when the JspWriterImpl constructor was throwing a RuntimeException ( I used that for debugging the sandbox). There is nothing wrong with using the tomcat logging code - especialy now that it has been refactored and is more "pluggable" ( i.e. you could write an adapter for log4j or the jsr?? logging ). I think jasper should not depend on tomcat - as it can be used in other containers - but using "common" utils is not bad. Costin
Re: [PATCH] [Bug 1001] - available() method on ServletInputStreamalways returns 0
Mike, I'm not sure I understand ( not your mail - the "available" definition ). Isn't availabe supposed to return how many bytes can be returned without a read() on the "primary" source ( that would block ) ? What you describe is slightly different - and I'm not sure it's a good idea. In any case, I would prefer the second choice - have the protocol return what it has in it's buffers ( if any ). Of course, a big question is what is available :-) If the data has been read by Apache but not yet sent to tomcat - is it available ? Probably so ( AFAIK this shouldn't happen - actual read from network is driven by a tomcat request and no data is buffered on apache ). But that would be a bit too complex even for 3.3 ( but may be implemented in a future ajp14 ) I don't think this would have any significant impact on code stability - since you replace a method that returns 0 to something a bit more acurate, and I see no problem with adding a patch to 3.3 ( 3.2 is quite close to a release, it's up to Marc to decide ). But I'm a bit concerned about the corectness of the result. Costin On Wed, 21 Mar 2001, Mike Anderson wrote: I noticed that this bug was marked RESOLVED/LATER and was wondering if there was any way to get this into 3.2.2 since that is the version that is closest to being released. I've already found 2 ways to fix this issue but am willing to abide by the groups decision and concentrate on getting this into the 3.3 release instead. The 2 ways to fix this are: 1. In BufferedServletInputStream, implement an available() method that returns limit - bytesRead or 0 whichever is greater. The limit class variable is set to the value of the Content-Length header and bytesRead is the number of bytes read since limit was set (see the attached diff1.txt). This is the easy fix but doesn't address the feature of available that says it will return the number of bytes that can be read "without blocking". Obviously, if there is a large amount of data, a read will most likely block at some point depending on how much is asked for, however this prevents a condition where one of the adapters returns 0 because a read hasn't actually been requested from the webserver. 2. Update BufferedServletInputStream to call reqA.available and then update the following files to provide this interface: Request.java RequestImpl.java HttpRequestAdapter.java Ajp12ConnectionHandler.java Ajp13ConnectorRequest.java JNIConnectionHandler.java MsgConnector.java TcpConnector.java Each of these classes would need to provide an appropriate available() method. I've also done the work on these files as well (see the attached diff2.txt) but noticed that since some of the protocols (particularly AJP13) actually have to request a read to fill their internal buffer, the adapter (i.e. Ajp13ConnectorRequest.java) will return a 0 if doRead is called and it exactly empties the internal buffer. Also the JNIRequestAdapter (in JNIConnectionHandler.java) makes a native call back into the webserver to do the reads and so available is implemented similar to #1 above; it just returns the max of contentLength - bytesRead or 0. This was because I'm not sure of a way to imp After testing both of these, implementation 1 is actually faster and more reliable. Typically if someone is calling available and they get back a 0, they would block the thread anyways and so it makes some sense to let it block on the read plus it gets around the issue of an adapter requiring one of it's read methods to be called to actually have something available. Any response positive or negative would be appreciated so that I know where to focus my energy (i.e. 3.2.2 or 3.3).
Re: bug in Jasper - bad lookups to Constants.getString()
On Wed, 21 Mar 2001, Mel Martinez wrote:
Would the following be an acceptable solution?
We change the
Constants.message(key,args,verbosityLevel) method
behavior so that if getString(key,args) throws
a missing resource exception that it logs using the
key itself as the log message. Note that this would
also require changing the getString() method to throw
the MissingResourceException instead of the Error
object that it currently throws.
+1 ( please check the tomcat side is doing the
same - we never had the problem but you never know )
Would StringManager be a better place for the fix ?
Costin
Looking at this, I am not sure why an Error is being
thrown here (in Constants.getString()). If Jasper is
operating in JspServlet mode inside some other
container (i.e. WebLogic, JRun, whatever) then should
it necessarily throw an Error? According to the spec,
Errors are reserved for conditions that are so serious
that they should normally not be caught by the
application. I.E., they should bring the JVM down.
The fact that Jasper (a servlet) is unable to find a
String in it's resource file sounds more like enough
error to throw a RuntimeException or even a
ServletException, but not an Error. That would allow
the containing ServletEngine to handl the error to
Jasper without bringing down other servlets - without
having to catch 'Error'.
I think the right way to handle this is to change the
getString() to just throw the
MissingResourceException. This requires no change to
the interfaces.
Then in org.apache.jasper.Constants change message()
to:
public static final void message(
String key,
Object[] args,
int
verbosityLevel){
if (jasperLog == null)
jasperLog = Log.getLog("JASPER_LOG", null);
if (jasperLog != null){
try{
jasperLog.log(
getString(key,args),
verbosityLevel);
}catch(MissingResourceException e){
jasperLog.log(
key,verbosityLevel);
}
}
This should work 99% of the time the way you describe
with much less pain in implementation.
Feedback welcome. If no one sends a -1 on this, I can
put this patch in fairly rapidly in tc3.3.
Mel
--- "Julien, Timothy" [EMAIL PROTECTED] wrote:
I believe there is a bug in Jasper when resources
(such as web.xml's dtd)
can't be loaded.
The basic problem is that keys are getting passed
into Constants.getString()
which aren't keys in the message resources file.
This happens because of
some exception handling, which basically constructs
an invalid key - namely,
a *value* in the message resources file.
JspUtil.parseXMLDocJaxp(String, InputStream)
{
try
{
...
}
catch(IOException io)
{
throw new
JasperException(Constants.getString("jsp.error.parse.xml",
new Object[] {
uri, io.toString()
}));
}
}
and then lower down the call stack:
public TldLocationsCache(ServletContext ctxt)
{
mappings = new Hashtable();
try
{
processWebDotXml(ctxt);
processJars(ctxt);
}
catch(JasperException ex)
{
Constants.message(ex.getMessage(), 1);
}
}
The trouble is that ex.getMessage() here contains a
*value* from the message
resource file, (as looked up in the first caught
Exception) not a *key*.
One fix would be in JspUtil.parseXMLDocJaxp(String,
InputStream) to pass
only the key (jsp.error.parse.xml) as the
JasperException's message - and
delay the lookup. But then you lose some
information (i.e., io.String()).
Maybe a better solution is to set a flag on
JasperException which marks its
message as being either key or value - so that
Constants.getString can be
called only when necessary. I realize this would
effect alot of code.
anyway, I'm happy to help in any way with the fix.
Tim Julien
HP Middleware
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java
On Wed, 21 Mar 2001, Casey Lucas wrote: Casey Lucas wrote: Just curious... why did you take out the buffer size double? Is that too much memory to sacrifice? Someone ? recently sent this in as a performance improvement patch. Ops :-) No, there is no problem with doubling the size, the fix was to match the new buffer size with bufSize - and I guess I picked the first value and changed the second. I'll revert to double size ( in both places ). Costin
Re: http 1.0 timeout patch
What about 33 sec. ? It matches the version :-) ( seriously - does the HTTP spec have any number ? If not, can we use whatever apache is using ? ) In any case - 300s is better than no timeout - and if it's too much we can reduce it later ( and make it configurable anyway ). Costin On Wed, 21 Mar 2001, Casey Lucas wrote: I'm -1 on the 15 sec. You never know what type of network a client may be traversing. -Casey GOMEZ Henri wrote: Hi, I notice you corrected the patch which is a good thing but settings timeout to 5mn (300s) is a little too high for an http 1.0 connection. The timeout could be as low as 15s. The timeout is activated if you have more that 15s between 2 read() and since connector read stream byte by byte. 300s is valid for http 1.1 connection with keep-alive. I'll commit the patch for 3.3 but with a 15 seconds timeout ;-) Si la fortune vient en dormant, a n'empche pas les emmerdements de venir au rveil. -- Pierre Dac -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 4:14 PM To: [EMAIL PROTECTED] Subject: Re: mod_webapp status? "Pier P. Fumagalli" wrote: jean-frederic clere [EMAIL PROTECTED] wrote: "Eric L. Anderson" wrote: What is the current status of mod_webapp? I have tried building the connector from cvs but the build fails with webapplib. The errors seem to indicate there are some missing source files. wa.c:69: `wa_connections' undeclared (first use in this function) wa.c:69: (Each undeclared identifier is reported only once wa.c:69: for each function it appears in.) wa.c:72: `cb' undeclared (first use in this function) wa.c:73: `wa_callbacks' undeclared (first use in this function) I can not find any trace of an actual definition of "wa_connections" in any of the source files. ? It is in "webapplib/wa_connection.c" -- Eric L. Anderson [EMAIL PROTECTED] I have also problems with mod_webapp. Pier has changed a lot of things, you will have to little. I'm rewriting it using APR... As we speak... Pier (under the snow in Dublin) APR is for Apache 2.0, correct? What about Apache 1.3? What _is_ the status of mod_webapp/WARP, this is a critical componenet for Tocmat 4. Tomcat 4 is useless to me without an Apache connector. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: Bugzilla issues
On Thu, 22 Mar 2001, Ignacio J. Ortega wrote: better.., not only 4.0.. This are really great news, but i continue thinking it's better to spread resposabilities a s much a we can, and bugzilla components are a great way to spread such resposabilities.. A big +1 ! Henri and Dan are a perfect example of what happens when more than one person is working on a component. I don't think the goal is to fix all the bugs and improve a piece of code, but improve ourself and learn from other people - and for that we need more people to work with on each component. Right now tomcat(3.3) is in a decent state, at least for performance and stability - I think jasper needs a bit more attention and maybe a bit of refactoring. Costin Thanks all good responses to my cal, this are really great news too !!! many thanks .. i'm glad to learn and work with all of you..all Saludos , Ignacio J. Ortega
Re: bug in Jasper - bad lookups to Constants.getString()
On Wed, 21 Mar 2001, Mel Martinez wrote: StringManager's getString() currently deals with the MissingResourceException by simply returning a String consisting of a warning message about not being able to find the particular key. I don't think that is correct behavior. I think it should throw the MissingResourceException or return null and that calling code should deal with it. Otherwise the Ignoring exceptions is bad. Having to handle exceptions for trivial cases is bad too. My feeling is that this is not the biggest priority, but you are right - StringManager and the whole resource handling needs a refactoring. Go for it, if you want to do it - I'll do whatever I can to help. ( I think thread pools or jasper or the admin are in a much bigger need for fixes and cleanup ) I am hoping the "commons" will ease our work - this is one of the things that are used in all jakarta projects, and it would be a good thing to share it ( in which case refactoring it and merging with the best out of what other projects are doing is worth the effort ) Costin
Re: Bug 1006, what's next ?
Hi, I had a (long) weekend without computers. But I still found one and read the mail once - and your report is very serious and important ( and not easy to fix ). You have (at least ) my full attention. The read timeout will be checked in soon - but the general problem ( with a servlet hanging a thread ) is very hard to resolve (or I don't know any good solution ). We could stop setting an upper limit on the thread count ( we still have the OS upper limit ), and we could also use the (dangerous, deprecated) suspend/terminate on the thread that is taking too much time. Have you tried any fix ? The timeout will not resolve the "bursts" ( and high-loaded servers ) - unless it is very short. BTW, this is not a tomcat-specific problem ( I would guess Apache does have the same issue - and we need to find how they deal with that ). Costin On Tue, 20 Mar 2001, Tal Dayan wrote: Two days ago I filed a bug report regarding a sever hanging problem in PollTcpEndpoint of Tomcat 3.x. The bug is at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and also include a suggestion for a patch. Since then I did not notice any change in the status or resolution of the bug report nor any indication that it got anywhere. 1. Is this is the right place to file the bug ? 2. Is the bug filed correctly ? 3. Should I do anything else to make sure the bug gets the attention of the relevant maintainers ? Thanks, Tal
RE: problem with national language in html form input
Hi, I volunteered to resolve the charset issues, the problem is very complex and difficult ( and I had very little time for that ). (I'm also an 8859-2 user). In other words - I need help ( patches, ideas, code to reproduce etc ) ... This is too big and scary issue - and I don't feel confident enough on my knowledge to start anything major. I already added code in 3.3 that would allow a module to set the charset, I fixed the generation of UTF8, and I'm looking at the changes that set the platform encoding - I believe it's a very bad idea ( since you can't know that the browser is using the same encoding as the server - unless you are inside intranets ), but I have no other solution right now. Anyway - I do believe we can' ship 3.3 final without this problem resolved, and the current design ( with MessageBytes and lazy conversion from byte-String ) should be able to support a solution ( if we find one) Maybe using UTF8 as the default for input and output ? ( I saw few RFCs mentioning that as the best solution - given that most current browsers do support UTF8). Of course, this can't be enabled the default ( spec issues ), but it's better than the local server encoding... Costin On Mon, 19 Mar 2001, Szegedi, Attila wrote: I have also done this once in my private copy of Tomcat, but have abandoned it. The problem is standards compliance, and standards (both the HTML standard and the Servlet spec) are somewhat internationalization-ignorant on this point. Tomcat follows the HTML standard, which explicitly declares that MIME type "application/x-www-form-urlencoded" is suitable ONLY for transferring ASCII (but will of course work for ISO 8859-1 as well). See http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1 It says: citation "The content type "application/x-www-form-urlencoded" is inefficient for sending large quantities of binary data or text containing non-ASCII characters. The content type "multipart/form-data" should be used for submitting forms that contain files, non-ASCII data, and binary data." /citation So, if you want to comply with the HTML standard, you should force sending all of your forms containing non-ASCII characters as "multipart/form-data" using the "enctype" attribute of the form. Unfortunately, Tomcat will not present "multipart/form-data" to your servlet as request parameters. The HTML standard is further flawed in that it 1. defaults the encoding type of the form to "application/x-www-form-urlencoded" 2. requires browsers to send form data in the same encoding they received the HTML page in, (except if "accept-charset" attribute is set, which is usually not). So, a complying browser will by default use "application/x-www-form-urlencoded" and send data through it in the same encoding they received the HTML page in. The trouble is, that they wont send the *ENCODING* back to the server in the Content-Type header (at least all IE (up to 5.5) and NN (up to 4.75) won't). It will always be "application/x-www-form-urlencoded" and not "application/x-www-form-urlencoded; charset=whatever"), so Tomcat's parsePostData can't determine the charset, it will always sense ISO 8859-1, as this is the default. I have some back experience working with Microsoft's ASP technology. They solved the problem partially by introducing the "session encoding" -- all HTML response used this encoding, and all request parameters were parsed according to that encoding. This could be a solution, however it should go into servlet spec. (Are we heard, servlet spec people?) My own app uses ISO 8859-2 (as it's in Hungarian), and for now I just transcode 8859-1 into 8859-2. I'm lucky I use Model2 paradigm, so I have a single servlet handling all requests and a single central place to transcode request parameters. Cheers, Attila. -Original Message- From: Aleksandras Novikovas [mailto:[EMAIL PROTECTED]] Sent: Friday, March 16, 2001 10:32 AM To: '[EMAIL PROTECTED]' Subject: problem with national language in html form input Hello All, I'm posting for the first time, so please inform me if I do something wrong ... First of all - problem description : I have application in multilanguage (where user can dynamically change charset). Problem rises when user enters information in selected language. After parsePostData in HttpUtils I get lots of "" instead of text. I can not rely on default system encoding, because application has ability to add the languages dynamically without recompilation. So I never know what next encoding system will need. I have written some code to work around this problem and think it would be nice to have it standard package. Actually I've changed parsePostData - added encoding parameter. Now programmer could choose in what encoding InputStream is supplied. I have tested it with windows-1257 (Baltic) and windows-1251 (Cyrylic) - for me it worked. If
Re: [VOTE] New Committer: Amy Roh
On Fri, 16 Mar 2001, Pier P. Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I still think it would be a good idea to merge mod_jk and mod_webapp, even if Pier is not going to touch 3.x code. Some of the ideas are good, and getting them into mod_jk will be good for the users - and that's what matters. That's what I've been telling Gomez in a private thread, we're going to meet later in April somewhere in the French alps with a BIG whiteboard... Well, maybe a better place to meet would be tomcat-dev, isn't it ? I'm sure Dan Milstein would enjoy a French vacation ( I would ), but so far mod_jk was developed by a larger group on tomcat-dev. Dan and Henri are doing most of the work maintaining mod_jk, and Larry and Nacho ( and Marc on the 3.2 branch) are doing most of the work maintaining tomcat - but they are not the only people working on either mod_jk or the container. Costin
Re: [VOTE] New committer: Mike Braden
+1 Costin On Thu, 15 Mar 2001, Dan Milstein wrote: I would like to propose Mike Braden ([EMAIL PROTECTED]) as a new committer. He has contributed very useful patches to the user docs, has fixed bugs in the ApacheConfig class, and has been a helpful presence on this list, both in discussing new features, and in answering questions. -Dan
RE: [PROPOSAL] The Commons - web connector
Dan, Henri, Remember the goal - to have a high quality connector and servlet container. Whatever brings us closer to that is good. Right now there are 3-4 people fixing bugs and working on mod_jk - and you 2 have probably the most knowledge about it. I was hoping that by moving it in a separate place we might get to share and merge the connector with 4.0. And that would be good because it'll increase the quality and the community behind the connector. This can happen only if all of you agree ( and also Craig, Pier and Remy who are working on connectors too on the 4.0 side ). Everything else ( list, cvs, integration with tomcat, etc ) is detail :-) Costin On Thu, 15 Mar 2001, GOMEZ Henri wrote: I don't see the advantages to having a separate project for the connectors. Can someone explain that to me? The main disadvantage that I see is that the connectors and Tomcat are very tightly linked. Why did you want the connector and Tomcat so tightly linked ? Take for example, mod_perl, mod_rubys or mod_python. Did mod_perl is hardly linked to perl ? Did you mix developpement of perl and mod_perl ? I think having one developer list for TC and the connectors makes a lot of sense. Yes we must split user/dev connector list from tomcat (core) list. I think having one bug system for TC and the connectors makes a lot of sense (especially since it's not always clear if the bug is in TC or in the connector when it is reported). if a request works against the Tomcat native http connector and didn't works when passing via connector, it's clearly a connector bug. Ditto for the user list, where TC/connector configuration issues are ever popular. +1 Would this separate project include both C and Java code? It would have to, if it would have any meaning (just working on one side of the protocols would be a nightmare to sync up with a "separate" project). A connector is part of code in C (Apache, IIS, NES) and part in Java (the plug in Tomcats). No need to split here. But if there's Java code in there, there's going to have to be different code for each different engine which the connector talks to (e.g. TC 3, TC 4). Pulling that code out of the main projects makes no sense to me. It is totally dependent on the rest of the project code. Sure, TC 3 and TC 4 use differents 'Interception' mechanism but the core ajp12/ajp13 code is and must be the same. I'm not sure if I'd want to be a committer on a different project -- once 3.3 is released, I'm planning on working on the 4.x branch. If you remember when the tomcat 3.3 was finally decided it was asked to developpers to keep working on it after release. The first thing I'd like to do (which I threatened to do a long time ago!), would be to write an ajp13 connector and/or merge mod_webapp with mod_jk. That is "connector" work, but I, personally, am more interested in the servlet engine as a whole than on "just" the connectors. I'm more interesting in building a stable connector and I'll concentrate on that. There is allready many talentuous developper like Costin or Craig (I don't forget Nacho, Larry, Remy, Pier) to works on Tomcat core. Working on connector is important for production world (and just before management decision) since stable, fast and featured connectors will help impose Tomcat's in real world. It's my personal opinion and vision but what make me choose JServ was Apache mod_jserv connector with it's fault-tolerance and load-balancing. And only this feature make my company (and others later) choose the Apache solution for servlet/jsp developpment and production. Regards
[VOTE] New commiter - Casey Lucas
Hi, Please vote for Casey Lucas as commiter. Casey is working on various optimizations in Jasper, with some very promising results ( tag pooling ). He is working on supporting both branches of jasper, and create container-specific adapters. Costin
Re: Plugging realms and JAAS into Tomcat 3.2
Hi Antony, Normally 3.2 is frozen, and only bug fixes should go in. But the good news is that for what you want, only a simple add-on module is needed ( and if it's available before 3.2 is final, we can probably include it in package - if not it'll be a separate download ). It should be reasonably easy - all you need to do is implement a module, with setters for all properties that you need for configuration, using the Simple or JDBC authenticators as a template. In 3.2 you'll need to implement authorize() and authenticate() hooks. Tomcat 3.x doesn't care how the authentication is done - it just calls the authentication chain and if a module returns OK and sets the roles then everything is ok. ( same model as in Apache/IIS/NES ) In 3.3 the auth code has been cleaned and reorganized, but it works in the same way. Please let me know if you need any help ( Nacho is probably a better source :-), it would be a great contribution. Costin On Wed, 14 Mar 2001, Antony Bowesman wrote: Hi, I am trying to find out if it is possible to plug ones own proprietary user realm into Tomcat 3.2. I have JAAS login modules that authenticate against this user realm and populate the JAAS Subject with principals (user names, groups, roles). However, I need to get this JAAS created security context into the Web container's security context, so that, for example, IsUserInRole() can be used to determine Roles from the original user realm and any calls to EJB container will get the security context. Rgds Antony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] New Committer: Amy Roh
On Wed, 14 Mar 2001, Pier P. Fumagalli wrote: GOMEZ Henri [EMAIL PROTECTED] wrote: I'll be +1 if Amy contribute to ALL TOMCAT current projects : ie : Tomcat 3.1, 3.2, 3.3 and 4.0 Sweetie... I'm not going to touch ONE LINE of the 3.x code... Now, do you Bravo ! That's the spirit of "community" and open source, isn't it ... Ok, I'll follow your example and stay away from mod_webapp - after all Pier's attitude should be an example for us all, he's been around for a long time. :-) Costin P.S. Note the :-) at the end - i.e. joke sign. I still think it would be a good idea to merge mod_jk and mod_webapp, even if Pier is not going to touch 3.x code. Some of the ideas are good, and getting them into mod_jk will be good for the users - and that's what matters. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons - web connector
On Wed, 14 Mar 2001, Dan Milstein wrote:
I don't see the advantages to having a separate project for the connectors.
Can someone explain that to me?
I don't think the proposal meant a separate top level project, with
separate list, etc.
It meant to decouple mod_jk and the connector from tomcat 3.3
As you can see in previous mails, there are people who "will not touch any
line of tomcat 3.x".
I think mod_jk and the connector part of tomcat3.3 is a great piece of
work, with a lot of great ideas - and it doesn't depend in any way of
tomcat3.3 - the same as mod_webapp is not specific to tomcat4.0
I think it will help to have a "common" and "neutral" repository, with
the goal of creating a connector based on the best ideas from mod_jk and
mod_webapp - or ( as mod_jk is designed ) multiple protocols that are used
in by both tomcat3.3, tomcat4.0 and maybe other containers.
As I said, the connector is in charge with implementing a protocol of
communication between the server and container - it doesn't depend on
having "Interceptors" or "Valves", it doesn't depend on having 6 core
classes or 20 interfaces, it doesn't depend on having a Loader interface
or using the standard ClassLoader.
Of course, there are parts that are specific to a container - but the idea
is to share what's common.
In the same way, it would be great to develop a single set of
general-purpose utilities - like ThreadPools, MessageBytes, etc - that
will combine the best out of both codebases and may be used by others as
well. And it would be great to have common code for jasper, with
specialized classes implementing what's different - 90% of the code in
jasper3.3 and jasper4.0 is common ( but is diverging every day ).
Right now the biggest problem is the fact that some people refuse to
accept there are other ideas and solutions. This leads to duplications all
across jakarta, not only in tomcat3.3/4.0.
And the only solution I know out of this is to concentrate in what's
common, and respect the differences.
The main disadvantage that I see is that the connectors and Tomcat are very
tightly linked -- I think having one developer list for TC and the
The protocol and most of the connector is not linked in any way to the
underlying architecture of tomcat ( i.e. the Interceptor is just a
wrapper, a way to plug in the connector ).
The list, bug system, etc will stay the same, of course, it's just that
it'll be less "coupled" with tomcat3.3, and may have a more independent
evolution.
would be a nightmare to sync up with a "separate" project). But if there's
Java code in there, there's going to have to be different code for each
different engine which the connector talks to (e.g. TC 3, TC 4). Pulling
that code out of the main projects makes no sense to me. It is totally
dependent on the rest of the project code.
Tomcat 3.3 should work with mod_webapp, tomcat4.0 should work with mod_jk.
There are differences - but most of the code should be common. The C code
should be the same, and on the Java side the only thing that is different
is the interface on the upper side.
I'm not sure if I'd want to be a committer on a different project -- once
I don't think it should be a different project - but the hope is that more
commiters will contribute on a 3.3-4.0 common connector.
3.3 is released, I'm planning on working on the 4.x branch. The first thing
After 3.3 is released I guess most of us will be working on something else
- for me it'll the "next" generation of container, combining the best of
3.x and 4.x.
Having a connector that combines the best of mod_jk and mod_webapp will
be a great step in that direction.
I'd like to do (which I threatened to do a long time ago!), would be to
write an ajp13 connector and/or merge mod_webapp with mod_jk. That is
"connector" work, but I, personally, am more interested in the servlet
engine as a whole than on "just" the connectors.
Same for me. I would be happy to help in anything that is a "merge" that
combines the best of both.
Costin
( BTW, I already have a prototype and a name for the combined thing :-)
GOMEZ Henri wrote:
Still no response for this sub-project proposal.
The upcoming PMC could be an occasion to speak about it.
I saw at least 4 potentials commiters working on it :
- Dan Milstein, our resident hacker/expert of mod_jk.
- Keith Wannamaker, webdav specialist
- Pier P. Fumagalli, mod_jserv and mod_webapp father
- I, Henri Gomez, mod_jk and adaptation to Apache 2.0
We start speaking of an updated mod_jk with ajp13++ (ajp14)
which must fix current known problem like :
- lack of security between Apache / Tomcat
Tomcat accept connection from anybody to it's ajp12/ajp13
connector. We may add so trivial authentification scheme
at least at connect time.
Nothing too expensive but last days on Tomcat list there is
an interesting Thread on 'Encrypting password' ('challenge-response')
-
Re: [VOTE] New Committer: Amy Roh
On Mon, 12 Mar 2001, Dan Milstein wrote: I have to say that I am a bit uncomfortable with this. The guidelines on the website say (http://jakarta.apache.org/site/roles.html): "Developers who give frequent and valuable contributions to a subproject of the Project can have their status promoted to that of a "Committer" for that subproject." I happened to be in the same situation with Amy - my account was created without "frequent or valuable" contribution from my part. It is very hard to get involved in such a project, with all the flames, so many smart people around who will read your mails in all possible ways, all kind of conflicting requirements. Not to mention the peer review. I could say a lot about this - but the short answer is that I'll vote +1 and I would love to see more people working for other companies in jobs involving tomcat and willing to become commiters, and this vote will make it easier for them to do so. Costin It sounds like Amy has contributed good work which people at Sun have seen, but, as a developer who only communicates via the list, I haven't seen anything she's done (I haven't missed any things she's submitted, have I? I have this vague memory of ezmlm complaining about not being able reach me). I'm also not clear if her documentation and test cases are part of the TC 4.x code base or part of the JSP spec (since she's working on the "JSP/Servlet Team") I don't want this to turn into a Sun-bashing thread -- I think it is *fantastic* that Sun is giving excellent developers a chance to work full-time on an open source Tomcat. And I would love to have more people who can contribute to the project. But I think those guidelines are important -- in terms of our social organization, I think it is reasonable to require a new developer to submit patches and ideas to the list at large, so that, when they are proposed as a committer, everyone can feel that they're voting for a known quantity. Furthermore, since I've been involved, that process has actually occurred very quickly (which I think is great). Once someone has contributed a few solid patches, everyone is ready to give them commit access. If I'm missing part of the story, I'd be happy to change my mind, but I guess I'm -1 until I can better understand what Amy's "frequent and valuable contributions" have been. -Dan "Craig R. McClanahan" wrote: Amy has recently joined the JSP/Servlet team at Sun, and has contributed several documentation updates and new tests for the test harness. She would like to work on bug fixes, as well as participate in the development of better admin tools, primarily on the Tomcat 4.0 code base. Votes please? Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons - web connector
On Wed, 14 Mar 2001, GOMEZ Henri wrote: Still no response for this sub-project proposal. A big +1 This will also reduce the pressure on making changes in the "stable" code. If a bug is found in the connector - we can just make a new release of the connector ( both sides ), without a need to make a dot.dot release of tomcat. ( tomcat 3.3 should still include the current mod_jk, with some of the fixes that are "safe" and/or proven in the new potential module ) BTW, if the "commons" project is aproved, than this can be a part of the "sandbox"/"agora" - and it doesn't require any special aproval from PMC or other projects ( only a vote on tomcat-dev). I saw at least 4 potentials commiters working on it : - Dan Milstein, our resident hacker/expert of mod_jk. - Keith Wannamaker, webdav specialist - Pier P. Fumagalli, mod_jserv and mod_webapp father - I, Henri Gomez, mod_jk and adaptation to Apache 2.0 I can help with some performance and a bit in the C side. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: where to plug-in startup/shutdown knowledge for internal tomcatcomponents
Hi Casey, I agree, resolving class loader problems is not easy. But it does have a bit of logic :-) The solution you found ( put everything in common/ ) is ok - that's how tomcat worked in 3.2 and before, and still works. Resolving the problem with a separate class loader for container is a bit more difficult - the main benefit is that the container implementation ( modules and libs that are used - including jaxp ) are separated from the web application. attempt 1: For each contextInit, TagPoolManagerInterceptor called TagPoolManager.setDefaultManager with a newly created TagPoolManagerImpl, yet when the jsp called TagPoolManager.getDefaultManager, the static reference set in setDefaultManager came back null. Try to do a println( TagPoolManager.getClassLoader().toString() ) every time you use it. You'll see what happens ( 2 different class loaders ). You can also try to print the parent loader. Giving up on that, I tried 2: Use no statics, just call Context.setAttribute in the interceptor. In the jsp use Context.getAttribute. The object that comes back is the exact same TagPoolManagerImpl that was put there by the interceptor but if I try to cast it to a TagPoolManager (or TagPoolManagerImpl for that matter), I get a ClassCastException. Same problem - different class loaders - different classes :-) I was originally trying to follow the model of JspFactory. I modeled my interceptor after the JspInterceptor, but no luck for me. I noticed that sevlet.jar was both in TC_HOME/lib and TC_HOME/lib/common. Maybe that's That was fixed recently, servlet.jar should be only in common. why JspFactory works. I jared up the TagPool* classes and stuck them into TC_HOME/lib/common and everything worked. Even though it worked, it didn't seem right putting jasper.runtime.Tag* classes into the common directory. Any help / suggestions would be greatly appreciated. jasper.runtime is now in common ( we did a number of fixes since M1 ). Everything that should be visible to webapps ( and jasper runtime is one example - since jsps are using the classes from runtime ) should be in common ( i.e. visible in both apps and container ). Jasper itself ( the compiler ) is in a separate loader. Think of the container as another application, that happens to provide some services to other apps. The common dir is what all applications are seeing ( including the container ). Each app has it's own local jars, providing the local functionality. The container provides jsp compilation, configuration, and other services that are used by tomcat. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Tomcat 3.x
http://jakarta.apache.org/builds/gump/2001-03-11/jakarta-tomcat.html This appears to be a classpath problem on my end. Will investigate. Build changed - using jakarta-tomcat/build instead of ../build, plus more. The nightly is also broken, I'm working on it. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: where to plug-in startup/shutdown knowledge for internal tomcatcomponents
Hi Casey, This is a hard question :-) The main decision you must make is that: Do you want to use JspServlet or JspInterceptor ? The first solution ( using Jasper via JspServlet ) is what is used in tomcat 3.1, 3.2 and 4.0 - and it has the big advantage that the full Jasper in interfaced using a normal servlet. That means jasper can be used in any place where a servlet can be used, and integrating it into any servlet container should be trivial. The second solution is used in tomcat 3.3 ( JspServlet is still supported). JspInterceptor is an adapter between tomcat 3.3 internals ( i.e. the hooks provided to tomcat 3.3 modules ) and Jasper's APIs ( Mangler, JspCompiler, etc). It works in the same way as JSPC - where a command-line interface to jasper is provided, with a lot of options. This is extremely flexible and gives you full access to all jasper's features, it allows a number of optimizations ( like avoiding the double redirection - JspServet-generated servlet), allows treating jsp-generated servlets as normal servlets ( i.e. absolutely no extra overhead or difference between a jsp and servlet after the compilation), and is much cleaner. It is also possible to adapt jasper ( not as easy as with a servlet ) to other containers by writing an adapter between Jasper's APIs and the container's internal APIs. In any case, remember that Jasper-generated servlets can be used via JspC - i.e. pre-compiled into servlets, without any jsp-specific code ( JspInterceptor acts like a runtime JspC ). So putting your code into JspServlet will be a bad choice. One way is to use tomcat3.3 hooks ( contextInit, reload, requestMap, pre/postRequest, etc ), and eventually take advantage of the per/request ( and thread ) and per context storage ( in 3.3, each Thread has it's own set of Request/Response - so request notes are equivalent with per thread data ). The other way is to do tricks in the generated servlet. For example on init() you can check a context attribute, and if not set you can do the context initialization and set the attribute. As long as you use "global" objects, reloading shouldn't affect you. You can use jasper runtime object to put the common code, so the generated code will remain small. Both solutions have advantages - and it's even possible to do a mix. My recomandation - just use a SimplePool, implement the "real" code ( tag pooling ), without worry about how the pool will look like or will be hooked. After this works, we'll find a solution ( or 2 ) for this issue. Costin On Fri, 9 Mar 2001, Casey Lucas wrote: I'm doing some prototyping for tag pooling in tomcat (based on the 3.3 tree.) I'd like to implement tag handler pooling per web application. Can someone point me to where I can hook into in order to setup the internal pool stuff when each web application starts, stop, reloads, etc.? I need to do things like setup the pooling strategy when each web application starts and release all the tag handlers when the application shuts down. Sorry if this is a dumb question, but hopefully someone can save me a lot of time. thanks. -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
3.3 build
Hi, I'm doing some fixes in the nightly build, and I was wondering about changing the default to what most other jakarta projects are using. I hate creating build in jakarta-tomcat - but since most other projects adopted this we should do it in 3.3 too. Now it's the right moment ( since we are preparing to build M2 - so we'll deal with all the build details and scripts ). Let me know what you think - I would be very happy to hear you strongly disagree with mixing the source and build result, but if no commiter -1 it I guess we should do it. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Bugtraq categories
Hi, I would like to add few more categories to bugzilla: 1. install ( better name ? ) - problems in the distrib packages - zip,tar, missing files, comments/problems on the README and release notes, install issues 2. reloading 3. session This will help us clasify the issues much better. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Bugtraq categories
+1 ( you know you can doit by yourself? just looked at bugzilla and you have the permissions already ) Yes, but still need the +1 before I do it :-) ( well, lazy consensus should be ok - if nobody -1 in 24h I'll add them ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: where to plug-in startup/shutdown knowledge for internal tomcatcomponents
Hi Casey, Welcome to the wonderful world of ClassLoading. The default configuration for 3.3 is to use a separate class loader for container ( i.e. tomcat.core, jasper, jaxp ) and web applications. This resolves a number of problems - like having a different parser in the web application. It also resolves the problem of overriding and fine-control over what is seen in the web app, and does enhance the security ( most classes that are visible in container are "trusted" ). But what I love about this is that it forces us to make a clear distinction between what is runtime and what is internal to the container. To answer to your problem: I assume TagPoolManager will be available at runtime to jsps. So it should be included in the common runtime, shared by both webapps and container. TagPoolInterceptor is a container extension, so it'll be part of the container loader. You shouldn't use static fields in general, but if you do keep in mind that "static" refers to the ClassLoader+Class combination ( you have one instance of the static field for each class loader ). BTW, this operating mode ( with multiple loaders ) is the most flexible for tomcat. The old mechanism still works ( with the old limitations ), but requires some code to enable it ( it's mostly for embeded tomcat ). Costin On Sat, 10 Mar 2001, Casey Lucas wrote: Now, I'm testing the pooling stuff out. I've got a TagPoolManagerInterceptor that listens to contextInit, etc. But my problem is that the static TagPoolManager reference that I initialize in contextInit always ends up null when the jsp runs. I put a print statement in the static initializer of TagPoolManager and I can see that it is being called once when tomcat starts up (and the various contexts are loaded) and a second time when the jsp is run. I assume that there's some class loader stuff going on that I don't understand. I looked at JspFactory because I'm using the same set/getDefault idiom. It some how keeps its static reference that is initilized in contextInit. My code seems to be just like JspFactory, yet my static gets reinitialized to null. Any suggestions? -Casey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, March 09, 2001 2:29 PM To: [EMAIL PROTECTED] Subject: RE: where to plug-in startup/shutdown knowledge for internal tomcat components On Fri, 9 Mar 2001, Casey Lucas wrote: So, given all that, I need to control lifetime of TagHandlerPoolManager's default instance. By controlling it, I can have one TagHandlerPoolManager instance per web application and when the web application gets unloaded, all the Tag.release methods can be called. Aren't the JspServlet and JspInterceptor mechanisms specific to an individual jsp file? If so, I don't think that's what I need because pooling will be for the entire web application not a specific JSP. I was hoping that when the web application (not individual jsp) is loaded, unloaded, reloaded I could do the TagHandlerPoolManager initialization and cleanup tasks. Maybe I'm making things too complicated. Should managing the lifetime of a per-web-application object like TagHandlerPoolManager be simpler? And you have 2 solutions: 1. Use tomcat hooks. You can let a tomcat module manager the TagHandlerPool and you'll get all the notifications you need. Just implement and TagPoolManagerInterceptor module, implement the hooks you need ( addContext, contextInit, reload, etc). 2. Use some "hacks" in the generated init()/destroy(). For example, in init() you can use a context attribute ( TagPoolManager ), if not set you'll create it and init, if it's set you just use it. Am I off base, with my general strategy? No, it is ok. Also, regarding 3.x and 4.x, I'd like to keep it usable / adaptable to all. We're currently using 3, but will eventually migrate to 4. 4.x also have a mechanism to notify you about events - either a 2.3 filter or use the internal Listener interfaces, and most decent servlet containers will provide such a mechanism. As long as you keep a simple interface to your tag pool, it should be easy to write the container-specific adapter that will plug it in. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
3.3 - top level files
Hi, There are a number of doc files at the top level, some of them old release plans, etc. What about moving them in doc/release ( so they will be included in the distrib - right now we don't ) ? ( we need to clean up and update the docs - but this can be done after the freeze ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Logging Issues
Hi Thomas, It would be great if you can help adding log4j support in tomcat3.3. My only problem ( and I'm very strong about this ) is that I don't like the "only one way to implement something" aproach. Log4j has great features, I like the code - but it's not the solution for all cases. I already did a refactoring of the logging code in 3.3, and now the actual implementation ( the Queue logger ) is cleanly separated, and tomcat is using only the util.Log base class. ( the main purpose of refactoring was exactly this - allow support for log4j and java.log and any other logger). Remember, tomcat can be embeded in different applications - and it's important to be able to use the application native logger. And tomcat can be run in environments where code size is important - and it this case the current logger is a better solution. Saying "there is only one logger" is wrong. 2. I am sure that the issues of logging and log4j have been raised before. Clearly logging is a critical function of any servlet engine. So here it is folks: If the consensus was that log4j was the way to go, I'd be willing to volunteer to fight I don't think the "consensus" is that log4j is the "way to go", but "one way to go". If you want to plug log4j, one way would be to: 1. Create an adapter between tomcat.util.Log and log4j. Log is the only class that is used by tomcat, and should be used to plug any logger. 2. Create a Log4JInterceptor ( you can use LogSetter as model - it's the only place where implementation-specific code is present ). You can also use it to configure it ( or at least pass the log4j config file ). This will setup log4j and set the adapter into tomcat. 3. Create the admin page or anything else that will make the life easier for the user. Of course, this is not the only way to do it :-) I would be very much against making this the "default" for 3.3 - we don't have the time and resources to test it, and the current logger has been used for a long time, and it's much simpler to configure and debug ( since it doesn't have any fancy feature ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Design Review for ajp13's changes: WAS problem w/ ajp13 - ifTomc at is shutdown
Hi Shinta, It's sounds like a solution to a real problem, please send a patch, I'm sure someone will read it. Dan and Henri are the best people to ask about this, I can also help a bit ( I've been using RPMs lately, it's too easy to get them and not worry about compile :-) My only sugestion/concern is that the code should work on both Windows and unix - or at least compile :-) Costin I would like to propose some changes to eliminate the requirement to restart Apache, when you restart Tomcat. I'm willing to give the code to anyone who needs it, when I'm done testing. But I need some help/suggestions so that I can put in the right code. If any of the proposed changes below should not exists ever, I'm open to other suggestions. This is my first time looking at mod_jk's ajp13 code. So any clue to make these better would be appreciated. Right now, if you use ajp13 and you restart Tomcat, you have to also restart Apache. See details in previous postings. For us, having to restart Apache is not a feasible solution in our customers' environment. After looking at the code, I have two possible solutions: 1. From mod_jk, I can detect that the socket has been closed by Tomcat. This is normally indicated by the recv() returning ECONNRESET. The recv() is called after the request has been sent to the socket. The send() unfortunately, doesn't give you an error. The proposed fixed is to check for errno ECONNRESET, then set the is_recoverable_error flag to TRUE, in the service() function in jk_ajp13_worker.c. I also add a code in mod_jk.c, to check for this flag, and call the service() method again if the flag is set TRUE. The 2nd time the service() method is called, it will reconnect to Tomcat like normal. 2. Another solution would be to put in a select() on the socket prior to send(), looking for the socket being read ready. Under normal condition, this select() should return nothing. But if Tomcat shuts down the socket, this select() should return the socket being read ready. When this happen, I issue a read() of 1 bytes. If the read() comes back with return code 0, this should be an indication that the socket was closed on the remote end. Then I will proceed to close the socket. The remaining logic already handles the reconnect, etc. I have both of these solution prototyped and minimally tested. They both Anyone care to comment which solution fits better with the overall code? Anyone voluteer to review the code? thanks, shinta -Original Message- From: Shinta Tjio To: [EMAIL PROTECTED] Cc: 'Dan Milstein' Sent: 3/6/01 7:01 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I am using Tomcat 3.2.1, Apache 1.3.14, running on Solaris 2.8, Sun machines. After various attempts of debugging this, I have more information. 1. Even though I'm setting the worker's property cache_size to default (1), I'm finding there are up to 6 connections opened from Apache to Tomcat. I deduce this by looking at the mod_jk.conf and by doing netstat. I finally find out, this is so because my Apache is set to spawn minimum of 6 children and each of those children are making separate connections to Tomcat. This is very bad because, I ended up having to reload 6 times before Tomcat starts serving me the page again. Each time it uses a different Apache children that has defunct socket. So the more Apache children I have, the longer it takes me to recover from this problem. 2. It seems when Tomcat dies restarts, the send() called by ajp13's jk_tcp_socket_sendfull() does not get an error. But the recv() does get an error, with errno ECONNRESET. After which, the socket is properly closed. 3. When I shutdown Tomcat, those sockets that were opened between Apache/Tomcat showed up in state CLOSE_WAIT, and FIN_WAIT2. I think this is normally solved by calling the shutdown() API after closing the socket. However, this would have to be done from the Tomcat side in Ajp13ConnectionHandler.java. I can't find the corresponding method of Socket in Java. So.. based on all of these, the only fix I can think of putting is to make mod_jk retry the send() if recv() comes back with an error ECONNRESET. The retry should happen after the old socket is properly closed. Anyone wants to comment? shinta -Original Message- From: Dan Milstein [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Tuesday, March 06, 2001 12:00 PM To: [EMAIL PROTECTED] Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown What version of TC are you using? What version of Apache? I would look into the mod_jk docs -- I think this is the spec'd behavior (which, admittedly, is not great, but that makes it
Re: tag handler pooling ideas
Just a quick note - my experience so far with server-side performance is that it doesn't matter how many objects you create, as long as you do it only once ( and not for each request ). I don't think doing any reuse inside a page ( i.e. same tag instance beeing reused during a request ) is worth the effort at this stage - you'll get most of the benefit and improvements by just using a pool and reusing the tags from request to request - if possible. Later you can do more advanced things. Another note - it would be nice if the pool interface is not very hardcoded in the implementation. Most of the time there is a sync() that is hard to avoid in pools, and you get a good improvement by using thread data ( in a form or another ). This is a bit hard because the same page may be accessed in multiple threads - so you'll have to keep tag instances duplicated per thread - but there are solutions to control it without affecting the response time, and most of the times few pages get most of the hits - so it's not like all the tags from all the pages will be cached at all times. Costin On Wed, 7 Mar 2001, Casey Lucas wrote: I am planning on implementing tag handler pooling and would like to throw out a few ideas for feedback: assumptions: - Tag handlers can only be reused if the same set of attributes are used for the tag. - Tag.relese is called only once -- at some point before the handler is garbage collected. basic idea: My general idea was to have a collection of named pools. Jasper could then render code to use the named pool to obtain handler instances instead of newing them each time. more info: Each tag handler pool would have a name that would include the tag's short name and the set of attributes that were used on the tag. This would give us the correct reuse level. So for the following tags there would be two named pools (after taking into account attributes): x:tag1 attr1="a" attr2="b"/ x:tag1 attr1="xyz" attr2="123"/ x:tag1 attr1="a"/ To eliminate the need to lookup the pool by name each time a tag was needed, pool references could be rendered and initialized (looked up) when the jsp is initialized. Inside the main jsp method (_jspService), the pool references would be used directly. When the pools are removed (shutdown, reload, etc.) Tag.release will be called for each of the handlers. I assume that pools need to be per web application, but haven't given it a lot of thought. Any comments / suggestions? -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: tag handler pooling ideas
On Wed, 7 Mar 2001, Casey Lucas wrote: Well I can do a pool per thread, but my assumption is that there could possibly be a lot of tag handlers sitting around. Should this be a concern? Also, I don't know the exact thread pooling model that Tomcat uses, but if it creates and destroys worker thread, that will hurt the pool-per-thread model. It doesn't matter what tomcat uses - this should work on other containers and models as well ( most decent containers are reusing the threads, if they don't probably the performance is bad anyway, or they have special needs - like small footprint ). It's important to just keep in mind that maybe later it should be possible to "tune" this and use some other mechanisms ( in adition or instead of the pool ). You probaly don't have to do anything right now - pool is a good start. By doing a web application wide collection of pools, there will be a synchronized pop (or similar) per handler retrieval and a synchronized push (or similar) per handler return to the pool. The synchronization will occur for handlers that are in the same pool across pages. Do you think this might be a problem? One collection per webapplication sounds good. Synchronization is not a big problem right now ( after you 2x the performance it'll be a bit more visible ). Keep in mind that a GC is also synchronizing, and object allocation does a sync() too ( most of the time ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Tomcat 3.x
Thanks Conor, It was a double mistake - Sam set ant.home to a wrong value in gump and I guessed wrong what was changed ( assuming the distribution layout changed). Tomcat doesn't depend on how ant build process works, only on the final directory layout ( in the distrib ). Meanwhile I updated ant, did a build - and congrats for the cleaned-up build process ( I don't like building in the source dir, but I'll get used to it :-). Costin On Tue, 6 Mar 2001, Conor MacNeill wrote: Costin, Is there any reasonable explanation for changing the ant structure ( i.e. removing ant/bin ) ? Besides breaking backward compatibility and forcing people to change their scripts ? We like you to change your scripts on a regular basis to stop them getting stale :-) Seriously Ant's build process was reorganized recently to build ant within the ant directory rather than above it. At that time, the bootstrapped Ant was moved into its own directory (bootstrap) so that generated jars (ant.jar) were not placed into a CVS directory (lib) where they may be inadvertently added to CVS. It made sense to move bin at the same time. If you have previously been using the ant/bin and ant/lib directories, you have actually been using the bootstrapped ant rather than the fully built ant. That is generally not a problem, of course, but perhaps not desirable. Also I think it is probably best for other projects not to rely on the internal organizaton of the Ant CVS tree but on the distribution built in the dist directory. Is that a "reasonable explanation" - you'll have to be the judge. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HTTP Status Codes and Error Pages
Costin - were you going to make the changes (out.flush() - out.flushBuffers()) in JspParseEventListener.generateFooter() and PageContextImpl.include() that we had discussed? I had thought that you implied you were going to do it (that was before I was a committer) but I just noticed that the out.flush() calls are still the same as before. Well, 2 things happened - first I had to do the changes in jasper ( i.e. jasper-runtime ), and make it available in lib/common ( so I can cast JspWriter to JspWriterImpl - jasper.jar is not visible to serlvets/jsps ) Second, we are waiting ( Larry ? ) for a clarification, to decide which is the best solution. The fix is trivial now - I tried on my machine and seemed to work fine ( i.e. pass the test suite ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Assigning Servlets to different ports.
Hi William, Regarding "multiple ContextManagers" - IMHO it should be possible to do that, but it's not a very tested feature. If what you want to do is support virtual hosts - tomcat supports virtual hosts using a single ContextManager ( the contextManager is a representation for a "server" that may have multiple hosts). There is no special representation for Host ( as a top-level object ) - each Context belongs to a virtual host, and the mapper is routing the requests. You can add additional modules to filter or do other tricks. ( just use Context.getHost() or getHostAliases() ). If you want to isolate applications/hosts - using separate VMs may give you more benefits. There are cases when multiple ContextManagers may help - for example if the servers have very different configuration ( i.e. top-level modules for mapping, etc). In 3.3 ( with the experimental ProfileLoader ) you can push all the modules as per/context interceptors, i.e. separate sets of modules for each web application - what's shared is the config modules and the top-level mapper. That means even fewer reasons to have multiple ContextManagers. IMHO if what you want to do requires changes/fixes in tomcat, you should try tomcat 3.3, where it is still possible to do this kind of change ( assuming it's not too big ). For 3.2.2 I don't think this can be clasified as a critical bug, and I don't think Marc would enjoy it :-) Costin Could you point me more specifically at where Enhydra uses multiple ContextManagers? I just downloaded EE 4.0a4 and couldn't find any files that have examples of multiple ContextManagers on different ports serving groups of apps. Whenever I try to use multiple ContextManagers on different ports I get lots of messages about removing duplicate servlets (like the jsp servlet, status servlet, exception servlet), and tomcat is unresponsive to any of my requests and refuses to shutdown, until I 'kill' it. Any help on figuring this out would be great. From my code archeology I was just about to conclude that it wasn't possible in tomcat 3.2.1 until your comment made me think that I had missed something. -Bill -Original Message- From: Shawn McMurdo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 10:25 AM To: [EMAIL PROTECTED] Subject: Re: Assigning Servlets to different ports. Hi Mel, If you are interested in an approach to getting Tomcat to serve apps on multiple ports, you might want to check out the Enhydra Enterprise 4.0 source. We create multiple ContextManagers, where each ContextManager handles the group of apps running on a particular connection (port). This is currently using Tomcat 3.2.1. Shawn Mel Martinez wrote: --- Uijin Hong [EMAIL PROTECTED] wrote: Why don't you just run 2 servlet container(Tomcat)s for each port? That could get memory expensive if you have to do this for several ports. The best performance scenario might be to use Apache to listen to several ports and rewrite them to go to a single tomcat 'delegator' servlet which then dispatches them to servlets/JSPs appropriately. And actually, you should just use apache rewrites directly to dispatch to any static resources. Mel -Original Message- From: William Wishon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 9:27 AM To: [EMAIL PROTECTED] Subject: Assigning Servlets to different ports. Hi, snipped An example of what I'm trying to do is to have a GET on "/" of port 8080 return webapps/app1/index.html and a GET of "/" on port 8081 return webapps/app2/index.html. Thanks, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Shawn McMurdo mailto:[EMAIL PROTECTED] Lutris Technologieshttp://www.lutris.com Enhydra.Orghttp://www.enhydra.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Tomcat 3.x
I can fix by specifying ant.home. What tomcat depends on is the distribution layout, i.e., "../jakarta-ant/dist". Well, tomcat depends on having ant binaries ( in the normal format ) in ant.home. The convention used is that "foo.home" is the place where a foo distribution is installed, it has nothing to do with the source or build structure. BTW, Sam - you are right about the need to test the latest ( i.e. CVS top dir ) - it's an excelent way to find any interface or layout change that may affect other projects, and maintain backward compatibility. Whenever I find some time I'll start using gump with the full dependencies. ( I still believe we need a separate build using the "latest stable" - for a different purpose ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
Costin, I would strongly vote for turning the auto-config back on by default for the following reasons (other than the fact that I explicity turned it back on when Keith fixed the ApacheConfig class): You don't need a "strong" vote - I'll do the change :-) 2) Configuration of mod_jk is notoriously complicated. Giving people the auto generated file is a big, big win. Wouldn't be enough to add a simple command line option ? For example, we have now a -enableAdmin ( to turn "trusted" on the /admin app ). We could add a "-generateConfig" - and everyone can be happy. ( plus - you'll not have problems with overriting the files ) ( unless you change your mind and agree with -generateConfig I'll just re-add the default behavior ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Just another Benchmark
Well, there is a possible explanation :-) The static interceptor ( which serves static files ) was never tuned or optimized. It probably does multiple accesses to disk, while in Apache there are a number of low-level optimizations, caching, etc. I am not very interested in spending time tuning the StaticInterceptor - I would rather spend the same time making sure setting up Tomcat + Apache is as easy as possible, and just let Apache do what it's designed to ( serve static files ) and tomcat do it's job ( servlets + jsp ) :-) For "real" production servers I hope you'll use Apache, and for embeding tomcat in apps or development you don't need 500 requests per seconde. Feel welcome to contribute any code that would improve the performance, or use apache for static files :-) Costin Hi, we tried the apachebench on our solaris system, to check out differences between architectures and thereby we found a quite interesting behaviour. When serving a static page, apache uses the whole machine resources while tomcat isn't (CPU usage 100% to 20%) and for maybe this reason isn't serving at the same speed as apache. Is there a limit somewhere in the java net or in tomcat? We used apachebench with 'ab -c 10 -n 5 Config: apache with mod_jk, and ajp13 to tomcat. Solaris 8 regards, tom --- Apache 1.3.14 serving static page --- This is ApacheBench, Version 1.3c $Revision: 1.38 $ apache-1.3 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/ Server Software:Apache/1.3.14 Server Hostname:solaris.lgsoft.at Server Port:80 Document Path: /start.html Document Length:2669 bytes Concurrency Level: 10 Time taken for tests: 98.686 seconds Complete requests: 5 Failed requests:0 Total transferred: 146255850 bytes HTML transferred: 133455338 bytes Requests per second:506.66 Transfer rate: 1482.03 kb/s received Connnection Times (ms) min avg max Connect:0 043 Processing: 119 1289 Total: 119 1332 --- Tomcat 3.2.1 serving static page --- This is ApacheBench, Version 1.3c $Revision: 1.38 $ apache-1.3 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/ Server Software:Apache/1.3.14 Server Hostname:solaris.lgsoft.at Server Port:80 Document Path: /pltest/start.html Document Length:2669 bytes Concurrency Level: 10 Time taken for tests: 509.877 seconds Complete requests: 5 Failed requests:0 Total transferred: 14360 bytes HTML transferred: 13345 bytes Requests per second:98.06 Transfer rate: 281.64 kb/s received Connnection Times (ms) min avg max Connect:0 0 299 Processing:94 101 128 Total: 94 101 427 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed Server.xml Change (was RE: Bugzilla #512 is Bunk)
Right, but that is excruciating to configure and more excruciating to maintain... We need to fix that :-) Why not use two copies of Tomcat, each with their own mod_jk.conf-auto which can be included in the appropriate VirtualHost section? Use 2 copies of tomcat as a workaround for stupid config mechanism ( I can say that, I wrote a large part of it :-) ? What if you have 1000 virtual hosts ? Don't get me wrong, sometimes it is good to have multiple instances of tomcat ( preferably on a farm of servers, or even on the same computer :-), for many valid reasons - but I wouldn't do it as a workaround for config. Then we could map each ContextManager to one VirtualHost with one auto-generated config file, and Include them from httpd.conf for each VirtualHost accordingly? Except ContextManager represents a "Server" instance, not a virtual host. Mea culpa - a lot of people said that we need a VirtualHost object, but I (still) think it is not actually needed - Container can represent any "group" of URLs, including VirtualHost, Context, URLPattern, or any other mechansim. And Modules ( including config modules ) do have access to all this information and can generate anything they need. While this may be a bit confusing ( why don't we treat a virtual host in a special way ) it is also much more flexible and simpler to do, with simpler code. Just some ideas... Thanks Steve. Please don't give up - maybe we can find a way to improve the config generator, or you may help with mod_webapp ( or ajp14 ) - i.e. extend the protocol to send Apache all the information about the hosts/web applications. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Just another Benchmark
on 3/2/01 11:58 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: For "real" production servers I hope you'll use Apache, and for embeding tomcat in apps or development you don't need 500 requests per seconde. What if we need 500 requests per second for non-static files? :-) You got them already - tomcat overhead for serving servlets is comparable with apache overhead for serving static pages. Everything else is up to the servlet implementation. ( actually, tomcat overhead is smaller than Apache 1.3, but Apache 2.0 is faster ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some benchmarks
I need to choose for my company the "next generation" servlet-engine. For now we are using JRUN. I am doing benchmark to choose the next one. choices for me are : JRUN, RESIN... not Tomcat as it is considered not stable and slow compare to the two others... What version of tomcat did you test ? Tomcat 3.3 should be close to Jrun and resin as speed - probably in 20..30% range. Again - it can serve servlets and Jsps faster than Apache1.3 is serving static files - if Apache is fast enough for you, tomcat will not be the problem. ( assuming of course the right VM and configuration :-) In these tests JRUN and Resin perform equally. Tomcat is get out of memory, is slow compared to the other and sometimes even crashed the JVM. Crashing the VM is a VM problem :-) Regarding memory usage - tomcat 3.3 creates about 10 objects per request ( compared with few hundreds in 3.1 ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
However, after upgrading to the latest and greatest tomcat 3.3 version out of CVS (as of last night) I've suddenly noticed that tomcat is no longer generating the mod_jk.conf-auto or tomcat-apache.conf files automatically. As near as I can tell, ApacheConfig.execute() is not being called. Yes, you need to insert the ApacheConfig module in server.xml. We can include it by default for the next milestone - but I would rather not, many people use tomcat standalone. ( a better solution be part of the new admin interface, but probably after 3.3 ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Just another Benchmark
what platform/os? i believe your previous claims have been on NT, is this also for unix now as well? I've never tried on NT - and it would be pretty difficult anyway ( to get NT on my computer :-) I'm using Linux/JDK1.3. Again, I'm talking about overhead - i.e. the time spent in tomcat ( if the servlet is doing anything - well, that's servlet performance, not something related with the container). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: How can I become a developer
IMHO, the best way to become a tomcat developer is to resolve your own problems and itches related with tomcat. If it works fine for you and you don't need anything - then just use it :-) There are many areas where we need help - and you don't have to be an expert in tomcat to help. Try to install it - is it simple enough ? Do you find the documentation confusing ? - then try to make it better. Try to use it - can it integrate with your existing infrastructure ? If not, try to make a module ( for example to authenticate against whatever is used on your network ). Is it easy to configure ? If not, either send documentations or fixes to improve that. Is it fast enough ? In general - find something that bothers your, and fix it. Right now what bothers me is: - fixing the bugs from the database - configuration - I want it to be easier to set up and manage - scalability - what happens if you have 500 webapps ? - facade23 Costin I have been following the messages from this thread. I have also been thinking of trying to join this group. I have read all the documentation, the open-source articles, etc. It occurs to me that the only way to join is to find a problem by running it on your own system through various personallized test, and then informing the group of the problem, and then coming up with your own solution. Is this the only way, or have I missed a note as to were a log of existing problems is that I can choose from and start working on? Thanks Gareth Jon Stevens [EMAIL PROTECTED] on 27/02/2001 23:10:34 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: How can I become a developer on 2/26/01 8:37 PM, "jerry123" [EMAIL PROTECTED] wrote: Hi guys, I want to be a developer in your team. Could you tell me how to do it?. Thanks a lot. Michael http://jakarta.apache.org/site/getinvolved.html -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ http://java.apache.org/turbine/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: How can I become a developer
The best place to start, to get a feeling of the thing yourself, is the source code itself. There's about 40K lines right now in 3.3m1, so take it easy. Perhaps the class diagrams will help you to start: http://nagoya.apache.org/~costin/tomcat3 And since I don't have an index.html, the diagrams and docs are all contributed by Alex, I just saved them in my public_html. I think I read somewhere that the most important thing was to have fun, sorry I cannot remember the exact source. So you can pick from existing bug-reports, build a challenging and complicated system, write javadoc or user documentation, do some code-reviewing, build new test suites... Whatever you feel you're better at. +1 ! ( either have fun or get a paycheck :-) Costin ( having fun ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: make jsse support optional
Hi Guillaume, I could be wrong here, as i didn't try to hack the build script, but jsse is currently mandatory for building tomcat, even if ssl support is not used You are right for 3.2.x - you can consider this as a bug in the build script. It's not hard to fix it - but I don't think it's that important ( since there are workarounds - like downloading the binaries ) In 3.3 it is fixed ( and one of the nightly tests is done without JSSE ). thereafter. As long as jsse is not free, i think it should be rendered optional for building as well. This way, tomcat introduction would be a lot easier for strict licensing policy Linux distributions, such as Debian or Mandrake. Would this wish be acceptable for next Tomcat release ? For the next release - absolutely. For 3.2.2 - I think it is still possible, but I wouldn't be that interested. BTW, you need JSSE to build - but you don't need to include it in the binary. ( the same way as you use the GPL gcc to build software with other licence ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Disk crash
Hi, My disk crashed this afternoon, I just finished installing the OS. I do have some backups, but the mail is the most affected - the last time I saved the mail was Feb 1. If you wrote me in the last month ( and still need an answer ) please try again :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Few commits
Hi, I'll start doing a number of commits that implement part of what was proposed so far. Please review. ( the tree may be unstable - I'll try to send individual commits instead of a big one ). One of the changes that wasn't discussed so far - in Ajp13.java I reproduced some of the changes from the standalone module. That results in almost 50% increase in speed, and the changes are pretty minor ( just the use of MessageBytes and OutputStream instead of Strings - it's fascinating how a small change can have such an effect ! ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TC3.2.1 - response commit on included JSPs
" if that destination is another character or byte stream, flush it." In this case, the destination is the servlet output stream - and it has to be flushed. That is only because the particular servlet engine implementation implements the ServletOutputStream of the Response object passed to the included servlet by wrapping it around (or simply passing on) the current ServletOutputStream. Technically, that does not have to be so. Ok, the final destination is the user's browser ( where bits will eventually go ). The meaning of flush() seems to be - empty all intermediary buffers. This is true. My argument then is only that I think the spec is bad in this regard. However, as I stated, I can live with it. +1 on that :-) So, I'm trying to decide whether to use the latest milestone build, nightly build or to setup a cvs project and simply track the latest code with the eventual goal of helping to contribute. Having to build one of my deployment tools from source is not something I really wanted to do from a project management perspective, but oh well The release plan is to have a beta soon, and so far it seems to work fine ( or at least my optimistic look at the bugs doesn't show any stopper ). I presume I can hook up as a 'read only' user of the tc 3.3 cvs repositories with wincvs? Where can I find the necessary repository url and authentication info? Or can I actually checkout the whole project via cvsweb? Looks like I need to do some poking around... It's the main branch of jakarta-tomcat, with nightly snapshots and builds available :-). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PROPOSAL: new commiter ( Mel Martinez )
Hi, Please vote to add Mel Martinez [EMAIL PROTECTED] to the list of commiters. Mel already made important contributions in desciphering and fixing the buffering issues, and will be a great addition to the community. Thanks, Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some benchmarks
Hi all. Here are the results of some measurements made with ab on Tomcat versions 3.2.1, 3.3.m1 and 4.0.b1 with different JDKs. Hi, Could you try again to run the test with 3.3 ( the next nightly build ) and Ajp13 ? 3.3.m1 Ajp13 (952/488) I did few changes and at least on my machine is now 30..50% better, but it would be great if you could check. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/serverAjp13.java
Hi Dan, I do see something which seems like a major gotcha, though -- you remove a lot of String creation by creating MessageBytes objects which point directly into the underlying input buffer. *However*, if there is any data posted as part of the request, that will immediately overwrite the input buffer (l. 376), and any further data which is input will also overwrite the input buffer (refillReadBuffer()). That's why it's great to have the patches reviewed :-) Yes, you are right. I don't think it's a problem to add a 8K buffer per Ajp13 thread - as long as the memory is constant and doesn't result in garbage ( the getBytes() method is creating a buffer that is garbage-collected ) I'll make sure a different buffer is used for the body. course, then you're adding an 8K buffer per Ajp13 thread. I had thought at one point that you could use a single buffer for input and output, but that's not the case -- the servlet can be in the middle of reading its way through the input stream when it starts to send output back to the browser. True - using the same buffer for in/out was an idea ( to reduce memory usage - the fact that GC is taking a lot of time was clear for a long time), but it turned that the trick is to keep the memory constant and to not generate garbage. Is there a reason you don't want to use your new hBuf Ajp13Packet for general output as well as headers? It kind of looks like you could merge it with outBuf (since, even when it's built around an OutputBuffer, it still supports appendBytes(), which is all that doWrite() needs). If you did this, you could get rid of one of those 8K buffers per thread. I guess I do it the wrong way - instead of using 2 buffers for input, where I should have, I got 2 buffers for output - where it wasn't needed. Well, I knew I need 2 buffers :-) Thank you very much, Dan ! Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some benchmarks
At c=10: 3.3.m1 Ajp12 (956/338) 3.3.m1 Ajp13 (966/390) At c=100: 3.3.m1 Ajp12 (920/343) 3.3.m1 Ajp13 (929/393) Not good I guess we can focus on ajp13 and do few changes, fixing both doesn't make sense. Mea culpa, I did a lot of tests/optimizations on standalone but I didn't reproduced them on the ajp side. I've been a bit lazy lately, the profiles are not ready yet and there are few bugs I'm draging... The good news is that it shouldn't be difficult to at least double the performance for ajp13 in few days, I expect it to be due to GC and the changes are easy to do ( I already done them in the Http10 side ). I guess I need few vacation days :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some benchmarks
Nick, Why in the WORLD should anyone be serving static html from tomcat through the connector from Apache? Working to improve performance of this kind of behavior, in my mind, is a total sillyness. A waste of your time. They should instead configure Apache to serve html itself and only pass servlet and jsp requests to the Container. I was looking at the second number ( 953/338 - 953 is RPS for static content served by apache, 338 is servlet served by apache+tomcat ). I am very happy I'm not the only one believing ( strongly ) that static content should be handled by Apache - I totally agree. If you look at the standalone behavior, servlet execution is as fast as static content on apache ( even faster ). That means mod_jk overhead is significant - it reduces the speed to 1/3rd. BTW, some old data ( before tuning the GC in standalone ) showed ajp13 to be _faster_ than tomcat standalone ( i.e. servlets using apache+ajp13 were faster than servlets using the standalone connector ), at that time servlets were running at 1/4 of the speed of static files served by apache. Now the standalone runs servlets faster than apache static files ( since there is no disk access, and the overhead in tomcat has been reduced ), but the Ajp13 hasn't been tunned ( still uses Strings, inefficient byte-char conversions, etc). BTW, I looked a bit this morning - and I'm amazed. Dan, you did a great job with the comments. It would be great if you could do something like that in other areas of tomcat. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Servlet Unit Testing strategies
Hi Tomcat developers, I'd like to have your opinion on servlet unit testing. I have written a simple extension to JUnit called J2EEUnit to do that but I'd like to knwo if there is a general consensus on servlet unit testing, regarding it's usefulness : Do you think : 1) It is useless. Just need to put a good facade in front of your business code and for the remaining part related to Servlets, functional tests are fine (using a tool such as HttpUnit), +0.5 I think functional tests ( using HttpUnit or GTest ) are extremely important for servlets ( while unit tests are important for beans and components used inside servlets ). That doesn't mean unit tests for servlets are useless - but that servlets/JSPs shouldn't have a lot of functionality, but delegate to beans/ejbs/taglibs that can be unit tested. Also, I think that for tomcat testing ( i.e. the container ) functional tests are more apropriate and efficient, and easier to write ( but doesn't mean we shouldn't have unit tests for individual components ). 2) It is nice to be able to unit test the part of the code related to servlets (i.e. the controller in a MVC model).It is possible to come up with a tool to do that (ex: J2EEUnit) I'm not sure I understand this - but any test is nice as long as it's easy enough to write. 3) With the current servlet API it is not possible to come up with a framework that will let you properly do unit tests. It will have lots of shortcomings. The only solution is to extend the Servlet API by our own Servlet Test API. Then have Tomcat implement it. Once we have this, it will then be possible to create a tool/framework that make use of this Test API to unit test servlet. The next step will to promote this API so that it becomes a standard and other Servlet engine implement it. -1. Extending the servlet API or implementing any extension in tomcat is not an option, and a test framework that requires changes in the design or implementation of the tested application is _bad_. It doesn't matter how good the test framework is, if you have to change your code to use it it's not good enough. ( IMHO ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TC3.2.1 - response commit on included JSPs
I won't contest that, but I would suggest considering the idea that the final, or intended destination is not necessarily the browser. In the case of an included resource, it is the calling servlet that is acting as client to the included resource. In good OO design, it should be in the control of that client what to do with the data that has been 'committed' by the included resource. Except that this is explicitely specified - the flush() in JspWriter should be propagated to the next stream. " if that destination is another character or byte stream, flush it." In this case, the destination is the servlet output stream - and it has to be flushed. And it is also explicitely stated that the included servlet can commit the response ( in RequestDispatcher spec ) Looking at the Tomcat 3.2.1 code, I see that this situation is still further broken in this regard because inside inside the We had a lot of problems with buffering - and changing 3.2.1 may be very dangerous ( because of many inter-dependecies like session,etc). The main change in 3.3 is removing many of the dependencies and cleaning the code. M I realize also, from looking around in the CVS repositories that the 'facade' package is history so I am not familiar yet with how newer versions of tomcat implement the include() method. Have they removed this offending call? Yes, and the whole buffering has been reimplemented. BTW, both solution should work with the current code - you can make the OutputBuffer ( the main component in the new buffer implementation ) ignore the flush(), etc. ( in 3.3 the Buffer is the central element - instead of hiding it inside the Stream it is now a first-class internal object, that can be controled via API ) It becomes clearer and clearer to me that I'm going to have to swallow upgrading to a newer version of Tomcat than 3.2.1. Which version should I jump in on? Sigh... I would say 3.3 :-) We hope to have a beta in few weeks - the code is already usable and stable. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Servlet Unit Testing strategies
But if you have to make setPropertiesFileName public, or to make design choices for the component based on the testing framework requirements - no, I don't think that's good. If the component has a setPropertiesFileName it is because that's the intended behavior. How would you unit test it then ? Unit testing works great in some cases, but not for everything. When you need to change the interfaces and code so that it can be unit-tested - you have a problem. 1) Ok, let's take another sample : let's take almost any Apache code that deals with Servlet(Turbine, Struts, Jetspeed, ... ). You'll see that you have code logic that is mixed with Servlet objects. Now let's imagine that you want to unit test a method. You'll have to *modify* it to try to move as much of the logic away from the Servlet code to try to build a facade. So I don't think "you have to unit test a method" is a good enough argument. You have to modify your test procedure if unit testing doesn't work for the code - not to modify the code ( there are enough other reasons to modify the code anyway ). Of course, if the code is not flexible enough or the API it provide doesn't solve the problems, or it's too complex - it must be changed. Hope I convinced you a bit more, even a slight bit more would make me happy :-) You don't have to convince me - I am convinced on the importance of testing the code, and more options the better. I'm just scared on the idea to change the code because the unit-test framework can't deal with it. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Some benchmarks
Suggestions for improving the tests are welcome. Please test Resin and Orion too, next we will beat'em.. As I said, setting goals and stopping when you reach them is very important ( and hard ). Beeing faster than Resin or Orion was not my goal - running at a speed comparable with Apache standalone and mod_perl was, and I think we are there. Now the only performance issue on my list is mod_jk ( the java side still need work to improve a bit the performance ). But fixing the bugs and making tomcat easier to use is far more important - and the connector module can be released independently, as a standalone module ( i.e. after 3.3 is released - stability is also more important than performance, I would vote for an ajp14 for performance and other "dev" enhancements, and making ajp13 the "stable" protocol instead of 12 ). -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: TC3.3: Profiles
I have a need to have the Tomcat "home" (i.e. the directory
where "conf", "webapps", and "work" are found by default)
be different from Tomcat "install" (i.e. where the "lib"
directory and the jars are found). The new class loader
scheme is finding jars using "tomcat.home" so Tomcat "home"
and "install" have to be the same. If this is something you
can easily include in the changes, please do so. If not,
I can take a look after your changes.
+1.
I would enforce saying that it will be good to follow the Apache
way in distrib like Redhat / Mandrake :
+1.
I was a bit slow, I hope next week I'll contribute some more time and code
- I think I can fix this one. ( I was thinking to something similar with
ant - use some ${properties}, like ${log.dir}, ${apps.dir}, etc, with the
current defaults.
( that requires little change in the existing code - and should provide
maximum flexibility, plus it's already very familiar to anyone using ant )
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RPMs
Hi Henri, Could you make sure that the RPMs included in the M1 are self-contained ? I installed a new machine, tried to use the RPMs - but they require xerces.rpm. I know where to find it, but other may have troubles :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TC3.2.1 - response commit on included JSPs
On Wed, 21 Feb 2001, Mel Martinez wrote: IMHO out.flush() should not commit the response. Only response.flushBuffer() should commit the response. And response.flushBuffer() should not be called from an inside an 'include' request. Hi Mel, First, JspWriter needs to be flushed at the end of the page - it has a buffer, and if the buffer is not commited the data will be lost. There is a method ( flushBuffer ) in JspWriterImpl, and that method should be called instead of flush(). In 3.2 we had a lot of problems with the buffers - changing that may be a bit dangerous. For 3.3, the whole buffering has been re-designed and refactored, and most problems we knew about in the servlet container are fixed ( but so far this issue hasn't been fixed - to be honest I didn't knew about it, I've been focused more on the servlet side ). It shouldn't be difficult to fix it, and since it is a spec issue I think this is a must_fix bug. The best way to make sure it'll be indeed fixed is to send a patch or at least a test case ( a small war with some servlets/jsps and a gtest fragment that we can include in our nighlty tests ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TC3.2.1 - response commit on included JSPs
Two points come to mind here. First off, I totally agree that at the end of the page the buffer should be 'committed' to the underlying ServletOutputStream - but I also believe that the ServletResponse should not be committed from within a dynamically included servlet or JSP page - is that distinction not clear? It is clear - just that 3.2 has a bug ( and fixing it was not easy because the buffering had problems ). In 3.3 it'll be fixed, I wasn't aware there is a problem. Second, while there is a flushBuffer() method in JspWriterImpl, this method is NOT a part of the javax.servlet.jsp.JspWriter interface nor is it public (it is protected). We can make it public - and the generated servlets already depends on jasper runtime. The problem is that flush() must still be executed as expected, i.e. if an included JSP or servlet is actually calling flush(), it expects the response to be commited. It is possible to disable commit when a servlet/jsp is included, but then we disable a reasonable function (explicit flush() ). Or we can disable the commit just before the final/implicit out.flush() - but again we need an explicit API call. Where trouble is probably being caused is that when flush is being called it also calls response.flushBuffer() both directly as well as indirectly (through cascaded out.flush() calls). If we can prevent that from happening in the 'included' case, perhaps that would be enough to fix the problem? Then how do you distinguish explicit flush() calls ? And the spec for flush() is clear IMHO - it should propagate and commit the response. I believe the problem here is solely on the jasper side. This problem shows up whether running jasper inside tomcat or inside weblogic server's servlet engine. There is a lot of "workaround" in jasper for tomcat buffering problems. Right now the buffering is more flexible ( including the ability to probagate a buffer without commiting the response, better conversions, more control, etc) Are the above suggestions useful? I can test them out on my own because I have a framework for overriding and extending most all jasper behavior through subclassing, but I am not a tomcat cvs committer nor am I well setup yet to put the changes directly into jasper code. I want to get more directly involved, but I don't have the luxury of time just yet. Just researching this problem is costing a lot of money so far. :-( I'll try to commit some changes tonight. I'm going to try with the flushBuffer() - it seems to me this is the right way to do it ( and you can still do explicit flush() inside an included jsp and get the expected behavior ) As for test cases, the problem should show up if you try to include a .jsp file and then subsequently in the calling page or servlet do something that requires an uncommitted response (such as a redirect). Can you send at least 2-3 JSP pages and a test scenario ? We need to include this in the nightly tests to make sure it'll be fixed in the final release. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TC3.2.1 - response commit on included JSPs
The problem is that flush() must still be executed
as expected,
i.e. if an included JSP or servlet is actually
calling flush(),
it expects the response to be commited.
But does that necessarily mean to commit it to the
browser? Or should it instead just commit it to the
buffer of the calling page (which is the actual
'client' here)? I think it is the latter case that is
correct.
The spec is not very clear ( IMHO ), but the comment on
JspWriter.flush() says:
"flush() invocation will flush all the buffers in a chain of
Writers and OutputStreams."
The flush() on ServletOutputStream and flush() in the Writer
are not redefined - and the java.io.OutputStrem.flush()
says:
"Flushes this output stream and forces any buffered output bytes to be
written out. The general contract of flush is that calling it is an
indication that, if any bytes previously written have
been buffered by the implementation of the output stream,
such bytes should immediately be written to their intended
destination. "
My expectation ( as a java user ) would be that if I call
out.flush() the data will be written to the final destination.
This may be correct for streams in general, but if
adhered to in servlet-servlet communication, then we
have to re-think the way we use flush().
Aside from the question of what an explicit flush()
should do, one also has to worry about what should
happen when the buffer of the underlying stream simply
fills up, forcing an implicit flush.
The implicit flush() shouldn't be different ( unless
the special "throw exception" setting is in place ).
which effectively makes this equivalent to your
suggestion of replacing the use of out.flush() in the
finally{..} with out.flushBuffer(). I'll grant that
if we accept that flush() must always propagate then
the above solution is not 'elegant'. However, it does
work just as well. And it at least tries to adhere to
the principal that included servlets should not commit
the response.
I tried flushBuffer() and it seems to work as well.
So the only question is how to interpret flush() on
JspWriter.
( for the flush() on OutputStream and Writer it seems
pretty clear from the java.io. comments - and I haven't
found any mention in the servlet spec to alter the way
streams work )
Neither solution completely blocks an included servlet
from flushing the parent stream because as currently
written flushBuffer() can still end up flushing the
stream if it writes enough bytes to the underlying
stream to overfill it's buffer, causing an implicit
flush().
This could be prevented by rewriting flushBuffer(),
but I can't do that in my scheme because for some
reason it is declared 'final' in the current code.
That's easy to change. In any case - the
ServletResponse.flushBuffer should go all the way - that's
specified in RD.include().
"If the page output is buffered then the buffer is
flushed prior to the inclusion."
That's a flushBuffer() to me.
The current jasper code in tc3.2.1 implements
jsp:include using PageContextImpl.include() which
simply does:
String path =
getAbsPathRelativeToContext(relativeUrlPath);
out.flush();
context.getRequestDispatcher(path).include(
request, response);
That should be a flushBuffer - if that's what we want,
or a flush() if we find a place where flush() is
redefined for servlet streams
( i.e. the Writer that is defined in the
servlet spec is not using the same definition for
flush() as java.io.Writer/OutputStream )
The java.io comment seems clear to me - all bytes should
go to their intended destination.
In other words, the use of out.flush() (as currently
defined) just prior to the include means you can not
do something like so:
Agreed.
So the core problem remains that flush() should NOT
commit the response.
Or that flush() shouln't be used where the intentions
is to not commit the response.
The solution you seem to favor is to make
JspWriterImpl.flushBuffer() public and then changing
the generated servlet code to have:
If we don't have a clear specification pointer where
flush() is defined as "flush to the last OutputStream, but
don't flush the last stream" or "ServletOutputStream.flush()
shouldn't commit the answer, but be a noop " - I think
we have to do that.
As I understand the spec, JspWriter.flush() will go down,
to the last writer/stream, and ServletOutputStream.flush()
is not re-defined - so OutputStream definition applys ( and
that sounds clear ).
This still would allow an explicit flush() or a buffer
overflow to commit the response.
Based on the assumption that this is the correct behavior
of flush().
I guess I'd be okay with that solution, but I'm not
sure I'm convinced that even an explicit flush() from
an included resource should commit the response. It
just seems counter-intuitive for a 'child' page that
I'm including to be able to change the commit state of
my response
RE: TC3.3: Profiles
Hola a todos, Costin: lib/common - jars shared by container and all webapplications ( similar with the global CLASSPATH ). ( tomcat-core.jar ) Now ( i do saw today's CVS changes perhaps i'm out of date ) common only need to contain servlet.jar, what do oyu think will be on tomcat-core.jar?? i think in classloaders more in a tree ( as archives directories ) of dependant classloaders.., and common will contnue to be *root* classloader ? I haven't changed anything yet - I was waiting for your opinion ( and my DSL was broken ). I suppose common should remain the root classloader. I don't know if core should be in lib/common or lib/container - but we may benefit by having it in common ( only org.apache.tomcat.core and the 2-3 util packages that it uses - MessageBytes, etc ). That's the last problem to solve - most of the work on "profiles" is related with easy configuration. Right now I'm trying to identify all dependencies and remove some wrong deps I put in core. I am also proposing few changes in the jar structure: - tomcat.utils: move all the top level "org.apache.tomcat.utils" in specific packages ( require changes in import lines ). +1 1/2 done :-) - Split tomcat-utils in few components. - jasper.jar will be separated in jasper-runtime.jar and jasper.jar ( to follow the general structure of tomcat, jasper.jar will contain the translator, jasper-runtime will be similar with facade.jar ) +1, i will assume this work, if ti has no volunteers already.. Great. Are you talking about the last point or the whole proposal ? :-) -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some benchmarks
Costin: Is there any way to find out how many objects are created in the JVM? I remember seeing something similar on a pre-release version of MacOS X: it sampled the number of objects of the different core classes that were allocated at any moment. Otherwise, how do you find out how many objects are allocated by the container with each request? There are 3 ways: - verbosegc. Java will report how many objects it reclaims on each GC. All you have to do is send many requests (100.000 or more ), add all the numbers reported in GC and divide. It's an estimate, but works ( for big numbers ) - -hprof will generate a big log file with all allocations ( then a grep or something can give you exact informations ). You can also find who is creating the garbage. - OptimizeIt ( commercial - I think they have an eval version ) - it's great if you can get it. It does almost the same thing as -hprof, but it's a nice GUI and you save a lot of time. ( and it works on Linux :-) As a side note - almost all performance improvements between 3.1 and 3.2 was due to recycling and avoiding garbage. One of the biggest changes in 3.3 was replacing Strings with MessageBytes - that also saved on byte-char conversion, which is extremely expensive, and hopefully will allow us to resolve the charset problems, since the conversion to char can be delayed until we know the real charset ). Right now there are around 10-20 objects per request, all created by modules ( and almost all can be avoided - by fixing the modules ). The only problem is that I don't think it's worth it - the time can be used in better ways, and the improvement will not be very significant. There are few hotspots in 3.3 that will give more performance , and I expect we can add 20-30% more performance with only small changes in modules ( so that can be done after 3.3 is released ), but I'm not very motivated to do that - it is very important to set a goal and stop when you reach it. A speed comparable with Apache standalone is decent, and I see little reason to go further (even if it is possible and even easy ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat file locations on Unix
I prefer /opt/tomcat/conf /src /doc /log /bin /lib over That's also my preference. Or at least /usr/local/tomcat. We have a precedent - Apache. FHS allows /opt packages, and AFAIK that's the best way to allow multiple versions of a products at the same time. Putting everything in /usr/bin ( or /windows ) is very bad if you want to work with multiple versions ( so I would vote for /opt/tomcat-3.3 ). ( but of course, Henri is maintaining the RPMs and who does the work should decide the layout ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
TC3.3: Testing
As you may noticed, we had few changes in the testing area: - you can run the test from the web interface - no special configuration - you just install the test.war and admin.war, no more command line tweeking. - the test .wars are built independently - we can add more tests for the current milestone/release We also did some tests with existing webapps ( I tested jetspeed, slide, I know other had run other apps ). But - we want to make sure those tests are run on multiple platforms/configurations, and we can easily test for regressions. I'm proposing that for M2 we start including the .war for the apps we test, and add some "black-box" test cases. ( i.e. in test-tomcat.xml we add test cases for the existing applications - making sure they work fine under tomcat ) We should also encourage people reporting bugs to contribute small .war files that can reproduce the bug ( or additions to /test ). More applications we test, more confidence we can have in the product. Even if automating some tests is difficult, at least having a small "manual test scenario" and making easy to run it ( by providing a common place for all tested applications that people just have to deploy ) will greatly enhance tc3.3 testing. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
TC3.3: modules
I was reviewing the "crypted password" auth module ( ok, digested, not crypted ) and few other modules, and I think it would be a bad idea to commit it as part of the current tomcat. The module is in an early stage of development ( it provide a very usefull thing ), and is not required for normal functionality. I would like to propose puting them in a new directory ( /modules ) and building sepparate jar(s) for them. The modules will depend on the 3.3 internal APIs, but will not be part of the 3.3 release - but distributed as a separate add-on jar. Again, this will reduce the need for a 3.3.1 release ( every major release requires a lot of work, while a module release is much simpler ), will reduce the ammount of code that is part of the tomcat release to what is functionally needed to implement a servlet container, and reduce the "featurism" syndrome ( keep the product small and focused ). ( you can think of those modules as mini-"revolutions" - when the code is stable we can discuss including them in the standard distribution. ) We could place them under /proposals, but I feel it's better to just use a /modules directory. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Class loading impact on performance?
pulp Command line usage: Step1 - 280ms Step2 - 20ms Step3 - 3946ms Step4 - 531ms Servlet in Tomcat 3.2.1 Step1 - 2954ms Step2 - 421ms Step3 - 46266ms Step4 - 8442ms As you can see, the performance degraded by about 10 times. I got around this by going against everything I believed about where to place libs in tomcat and loaded all jars in the server startup script. The problem goes away. I believe this is a problem with class loading on Tomcat. /pulp It may be - that's why we have 3.3 :-) Xalan, xerces, are loading a lot of classes - but this is only startup time. Thanks to Nacho, most of the class loading problems are resolved ( well, I also had a small contribution, so did Henri and Larry :-) - and it seems the loading speed is pretty good now. Unfortunately it's very hard ( and dangerous ) to port the changes to 3.2.x. Tomcat 3.3 uses only URLClassLoader - if JDK1.2 is detected - and only "standard" parent delegation. I tested it with xerces, jaxp1.1, etc - it all seems to work. The only problem is that by default, no parser is provided to applications - I'm working on a solution that will allow the admin to specify that an application needs a parser ( and what parser to provide by default ). ( in other words - to define different "profiles" - the default will probably remain the most conservative - no library provided by the container ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Bug 486] Changed - ????? instead of content of @include pageswhen contentType present in root page BugRat Report#817
Thanks Marc, Ilyin, I can reproduce the bug, it's very strange ( most of the time I see normal cyrilic characters, but some times I do see ). I'll start working, I hope to have patch in few days. Costin On Fri, 16 Feb 2001, Marc Saegesser wrote: I exchanged email with Ilyin in late January about this bug. I was able to duplicate the problem using tomcat_322_final, but the bug had already been fixed on the tip of the tomcat_32 branch. I didn't dig any deeper into the issue to see which commit actually fixed the problem. Attached are the samples files that he sent me to use for testing. I can also generate files in Japanese if that would help. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 15, 2001 11:30 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Bug 486] Changed - ? instead of content of @include pages when contentType present in root page BugRat Report#817 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=486 *** shadow/486 Sat Feb 3 11:43:09 2001 --- shadow/486.tmp.7159 Thu Feb 15 21:29:52 2001 *** *** 2,13 | ? instead of content of @include pages when contentType present in roo | +- ---+ |Bug #: 486 Product: Tomcat 3 | ! | Status: NEW Version: 3.2.1 Final | | Resolution:Platform: All | | Severity: Normal OS/Version: All | | Priority: High Component: Encoding | +- ---+ ! | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED] | | CC list: Cc: | +- ---+ --- 2,13 | ? instead of content of @include pages when contentType present in roo | +- ---+ |Bug #: 486 Product: Tomcat 3 | ! | Status: UNCONFIRMED Version: 3.2.1 Final | | Resolution:Platform: All | | Severity: Normal OS/Version: All | | Priority: High Component: Encoding | +- ---+ ! | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED] | | CC list: Cc: | +- ---+ *** *** 19,21 --- 19,25 in root jsp page and use @include I see instead of russian characters - ? in included files. When I remove contentType='text/html; charset=Windows-1251' all include OK. Can you make default encoding property in web.xml (or somewhere) to change default encoding from ISO to my prefered one. + + + --- Additional Comments From [EMAIL PROTECTED] 2001-02-15 21:29 --- + Can't reproduce - please include 2 jsp files with russian characters. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: charset used for parameters decoding on HTTP request Tomcat3.x,4
The problem is that browsers do not send the charset used to encode the form's parameters; but they sent the request with the ContentType header application/x-www-form-urlencoded. The charset should follow the encoding type ex: "application/x-www-form-urlencoded; charset=UTF8" but in most of cases does not. I know. But that's the standard, and we have to follow it first. If that fails ( and will - in most browsers that ignore the standards ) - then we can try workarounds. From my point of view instead of implementing a routine in charge of analysing the request header to extract the data's encoding charset (few chances for it to really work), It would be better to adopt the following policy: There is no "instead" here - in addition of the ";charset=" we can do many things. * we suppose that the request's parameters encoding is the one used for the response to this request content encoding. If the servlet processing generates a result page encoded with Shift_JIS charset, it is reasonnable to suppose that the incoming form data used for the page generation is encoded with the Shift_JIS charset. ... (javax.servlet.http.HttpServletResponse.setCharacterEncoding(String)). ... That's a good idea - thanks Adalbert. There are other few tricks we can try ( in addition to this one ), and in time we can hope that browsers will follow the standards. BTW, another small improvement would be to specify an encoding per application ( instead of defaulting to the platform or UTF). And one may guess the charset from the Accept-Language ( in some cases ). A very common mechanism seems to be a "charset" parameter in the request ( it seems there it is possible to do a javascript trick in the page to add a hidden param with the current browser encoding ). I'll start working on that in 1-2 weeks, and any sugestion ( like this one ) will help. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Modules subproject ( was: Re: [PATCH] CatalinaBlock.java )
Actually, I was thinking starting a modules subprojects for things like that in 4.1. It would be really great to have a module subproject !!! ( as long as it will host 3.3 modules too :-) This will keep the release more focused on the core functionality, and simplify the testing and release. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: charset used for parameters decoding on HTTP request Tomcat3.x,4
You will still need to fix the actual parameter parsing routine to delay applying the encoding until the name and parameter are parsed out of the input stream... Yes, most of this is already done. It also has a very nice performance implication - since the String is converted and alocated only when and if it's needed. The only missing part is the "internationalization" module that detects the encoding ( charset and accept-language parsing doesn't look good either in the current code ), and putting the pieces togheter. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: adding webappsDir attribute to ContextManager?
Hi Scott, I wanted to know the interest in adding an additional attribute to ContextManager in server.xml to specify a webapps directory, in much the same way that the work directory can be specified. This would override the For 3.3 - it's already customizable ( you can even specify multiple directories ). It's not using the ContextManager attribute, but something similar ( the auto-deploy is part of a module, you can specify the directory as an attribute and you can include multiple instances ) For 3.2.2 - I don't think it's difficult to make it work, and I know the plan is to keep it focused on bug fixes. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.2.2 Release Plan
Tomcat 3.2.2 Release Plan Ballot: [X] +1 I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1 I am against this plan being executed, and my reason is: I'll help with the nightly builds, and I'll help review the changes that'll go in ( and went in ) ( we have to port some of them to 3.3 too ). Maybe more, but 3.3 is my main priority. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtimeJspWriterImpl.java
This adds another dependency between jasper and tomcat.util ( the first is tomcat.util.log, now tomcat.util.compat ). Since both packages are completely standalone and can be bundled with jasper, I don't think it'll be a problem. Comments: I don't personally see a problem with Jasper requiring Tomcat, but I do see a problem with the other way around. :-) Tomcat3.3 doesn't have any dependency on jasper in core or utils. JspInterceptor is the only piece that depends ( via a Liaison - which takes full advantage of all jasper APIs.). Jasper has no dependency on tomcat internals, except 2 general-purpose utils which are shared. HOWEVER, I'm not sure what other corporations will think about this. People who want to bundle Jasper without Tomcat (ie: IBM) may not like this at all...even if the Tomcat stuff is standalone. Jasper already had a dependency of a "shared" util ( util.log), this fix just adds a second one ( util.compat ). That means someone integrating Japser in a different container needs to add the 2 shared utils. Maybe a good idea would be to change the build scripts to package the jasper.jar file with *everything* it needs to run standalone...even if it means duplicating a couple .class files. The build scripts are already doing something like that - all "shared utils" are packaged in tomcat_util ( can be renamed "shared_utils" or soemthing like that ). The utils have no external dependencies, and the only thing they have in common with tomcat is the package name ( org.apache.tomcat.util ). Someone who needs only jasper can take the utils and jasper package. ( duplicating some of the classes in 2 package may have negative impact on class loading - it may throw "Sealing" exceptions ) -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: your mail
Hola Costin: I've got this Fail , it's something you are doing currently? or it's a Windows quirk of something that is working on ixes ? Sorry - it was a cutpaste from the previous test. ( the previous test is checking what happens when you getInputStream() and read the body, and then getParameters() with post, the last one what happens if you getParamters() and the getInputStream(). In the first case the body should be read - by spec, and getParameters() should return only the GET params ( that part is not defined in the spec - it hust says that the body shouldn't be read before getParams() ). The second case is also slightly undefined ( the spec doesn't mention what should happen after getParameters, if getInputStream is called). Tomcat behavior is : - if getInputStream is used, the POST params will be consumed, and getParameters() will still work and return only the GET params. - if after getParameters() the getInputStream is called, the body will be empty ( since we don't support multipart in the current connector ) I still have to add the other 2-3 test cases for parameters ( include, jsps), but I'm doing some cleanup for M1. BTW, I'll start using tomcat_32 branch of watchdog for the nightly tests, so we can use the same tests as with 3.2 ( watchdog changed in the 3.2 branch, didn't changed in the main - we can easily merge, but I think someone else should do it). One question - for better testing we should also use a subset of watchdog-4.0 ( i.e. without the Servlet2.3 tests ). Since the spec is backward compatible, we should be able to run the 2.2 tests ( and make sure the behavior is similar - there are places in 2.2 where the behavior is undefined, but is defined in 2.3 - I think our "undefined" behavior should match 2.3, to allow easy transition in future) Costin 8 FAIL ( No data after the params are read ) POST /test/servlet/params.ParamsInputStream?a=xm=n HTTP/1.0 TEST: ( responseBody matches 'a = [ x ]') Request: POST /test/servlet/params.ParamsInputStream?a=xm=n HTTP/1.0 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 7 a=bc=d Comments: No data after the params are read Message: ERROR: expecting match on a = [ x ] GOT: Params = [m , a , c ] m = [ n ] a = [ x , b ] c = [ d ] Query = a=xm=n START BODY: END BODY 8 Saludos , Ignacio J. Orteg -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 3.3 Milestone 1 Status
Hi Larry, What about doing that after weekend ? Let's say is superstition, but so far Monday has been a good day for milestones. Though not completely frozen, only simple (i.e. safe) bug fixes should be made at this point. If there is something bigger that you think should be in TC3.3m1, please contact me first before committing. All code changes for ant syntax in server.xml are done, but the old syntax is still used. I checked in server1.xml with the new one, I think we should have it enabled by default. There are minor changes needed to support "profiles", I'm very confident they'll have minimal impact. It will be implemented by a separate module - basically no change in the current code, but I would like the config file to be written using the new style. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH]: Bugrat report 723 ( unescaping/unencoding URLs ) was'Re: 3.2.2 Release?'
Just checking back on the status of this patch, I received some email from someone who isn't actively on the list but has the same problem as originally reported in Bugrat report 723. Anyone have any feedback on the patch or the control characters in URL question I had? I will work on it for 3.3 , there are few more encoding problems and I need a bit of time. I don't think we can do it for M1, but it is on the list and it has high priority. ( I don't know if they are checked into 3.2.x ) Costin David Weinrich - Original Message - From: "David Weinrich" [EMAIL PROTECTED] To: "Tomcat Dev List" [EMAIL PROTECTED] Sent: Friday, February 02, 2001 23:18 Subject: [PATCH]: Bugrat report 723 ( unescaping/unencoding URLs ) was 'Re: 3.2.2 Release?' Thanks to everyone, that cleared things up quite a bit. Here is the patch for bugrat report 723 ( tomcat 3.2.x not unescaping escaped urls ). The patch is extremely short, and implemented a tiny bit different from the one I sent in for 3.2.x a while ago, the unencoding is done before the path is checked for other issues/security concerns to prevent unencoded stuff from causing these after the fact. Note: I haven't yet mastered the art of Watchdog/internal tomcat tests so this will need to be tested a bit more thoroughly. So far the following urls work correctly: http://localhost:8080/index%20%23%24.jsp http://localhost:8080/index%20%23%24.html corresponding to the following filenames in the ROOT webapp dir: 'index #$.jsp' and 'index #$.html' If an error occurs in unencoding, null is returned which ends up sending a Not Found(404) message instead of a stack trace. This seemed to be the most sane way to handle the issue of improperly encoded urls. This is usually the result of having a value after a % that isn't two hex digits or having an unencoded % in the url like: http://localhost:8080/index%%20%23%24.jsp or http://localhost:8080/index%zz%23%24.jsp One last remaining concern I have: the current implementation of RequestUtil allows control characters to pass through without raising an exception, I am assuming this could possibly raise problems, and is fairly undesired. If I interpret http://www.ietf.org/rfc/rfc2396.txt correctly, control characters should not be included in URLs. If it is agreeable, I will make a patch to RequestUtil.URLDecode tomorrow to block characters in the ranges of 00-1f and 7f-9f to prevent this from being a potential problem. Thanks again! David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java
The new jasper makes it very easy to find and view the java source for a translated jsp page, it is located in work/somehost/someapp/some/context/path/MyJSP.java. Does it not seem logical to assign a package to the MyJSP class based on all or part of the above path? This may seem like esthetics, I suppose. Not something we should get stressed about. What you've done is a great improvement over what was there. Does it work with tc 3.3? It should work for tc 3.x, but I don't have the time to back port it. Well, it works in tomcat 3.x for some time ( too long ago to remember, it's part of the original JspInterceptor :-) The scheme is slightly different, but the ideea is the same ( using simpler and predictible names for the generated classes ). -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
TC33: Configuration
Hi, There are few changes to simplify the configuration of tomcat3.3, and I would like to do them as early as possible. The idea is to simplify a bit server.xml and make it easier to tune web applications. The current syntax will of course be supported, my proposal is to add a mechanism to also allow a simplified syntax. The additions are: 1. Allow ant-style syntax for modules: a module is now loaded with: RequestInterceptor class="org.apache.tomcat.modules.aaa.SimpleRealm" filename="conf/users/myusers.xml" / We can use: SimpleRealm filename="conf/users/myusers.xml" / ( modules.xml will contain the list of predefined modules, new modules can be added with a syntax similar with taskdef. ) 2. Add a ModuleInfo object in core that will keep the meta-information about a module ( hooks, ordering, description, etc). This will be used for the /admin-like tool and for configuration. 3. Separate the "global" configuration from context configuration. Now server.xml contains both options for the server and options for individual contexts. It would be easier if each context or group of contexts will be configured in a simpler file ( given that users will have less need to edit server.xml ). For example: config/apps/foo.xml will keep informations about the /foo application. This is already supported ( by using ContextXmlReader ), but it's not documented and used by default - my proposal is to start doing that. (BTW, this is very important as it make easier to develop the /admin tool - the part about saving context preferences ) 4. Add a new configuration section profile containing a group of modules that are specific to a set of contexts. Right now you can tune individual contexts by adding a per-context module, but if you have a lot of applications that becomes very difficult and time-consuming. (for example you may want a group of webapps to use JdbcAuthentication and log in a certain directory ). This will save a lot of typing and will add clarity. Again - those are backward compatible usability enhancements, and should have minimal code impact - but it's important to do the changes as early as possible. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] New Committer: Kief Morris
Kief has recently proposed improvements to the session management code in Tomcat 4, and wants to continue helping out. I hereby propose him as a committer on the Tomcat project. Votes, please? +1 ( +2 if he also ports them to tomcat 3.3 or makes them independent of the container architecture - i.e. general purpose utils for serialization/deserialization with a simple adapter for each server :-) -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
The intention ( in tc3.3 ) is to make all the configurations "explicit",
instead of using conventions like "webapps will be in home, libs in
install, etc".
Even in 3.2 we tried to allow a shared installation dir and multiple
work dirs ( i.e. you have one tomcat installed in /opt/tomcat, and each
user can run it with it's port and webapps ). This is not a "supported"
feature - i.e. it's not very well tested or documented.
For issue #1, it's a bug - logs are "special" in 3.2 and they were not
made relative to the home. The workaround is to use explicit paths.
In 3.3, the logs are corectly set relative to TOMCAT_HOME.
If nobody objects to the config changes I'll also add the ant-style syntax
for ${properties}, so you'll have more flexibility. Nacho started
a nice idea in the loggers ( adding a ${TIMESTMAP} ), and I plan to add
other pre-defined properties (like configdir, context home, context
workdir ).
Again - the current mechanism is indeed a bit confusing and complex, and
making it explicit will be a big step forward ( i.e. all paths will use
${tomcat.home}/logs/mylog.log )
better, wouldn't it be nice to be able to set that at
the command-line with a an option? That would make it
That's something I work on, but it's lower priority. ( better command line
support )
Issue #2 ( conf dir ) - again, in 3.3 most if this is configurable via
individual module options. For example the apache.conf is generated by a
module - and you'll be able to set the location to anything you want
( or any other properties that affect its behavior )
Henri proposed to make it simple to use Linux-style hierarchy ( with
all logs in /var/log, configs in /etc/tomcat, webapps in /var/tomcat,
etc). Apache also have a "layout" option.
Regarding Issue #3 - the web.xml is not used in tomcat3.2,
and will not be used in tomcat3.3. All the server config
is done using server.xml ( and the new context.xml ) files.
There shouldn't be any overlap between web.xml and sever.xml,
any setting that is part of web.xml should be part of
the web application's WEB-INF to make sure the app is
portable ( if you rely on any tomcat-specific default,
your app will work only on tomcat).
Server.xml sets server behavior. For example, the
conversion between .jsp and java is a server property.
The static interceptor is a server property. Everything
that is not defined in the web.dtd belongs in server.xml,
and it's specific to tomcat. What is defined in web.dtd
and the spec belongs to WEB-INF/web.xml.
At this point, I try making a variety of changes to
the web.xml file, including registering my servlet
Web.xml is not read - it's just a template you can
use for your applications.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
In 3.3, the logs are corectly set relative to TOMCAT_HOME. and should be implicitely written to paths relative to the application 'home', not into TOMCAT_HOME. This is simple OO partitioning of responsibilities. Ok, this is a clear example of what's wrong with the current status - there are 2 directories that can be set on ContextManager, one is "home" and the other one is "installDir". The env. variable is used to set home. If one is set and the other not - both share the same value. InstallDir is the one used for jar files ( and all "shared" files ). home is supposed to be used for the local instance. ( the model is again a shared installation - /usr/local or /opt/tomcat and each user having it's own config and set of applications ). That's just a particular use case, and even for that it's too complex. By using explicit paths we can accomodate more use cases and be very clear about what goes where. Down the road an include mechanism would be a good idea to add as well (i.e. add a server.xml element server-include which could take a path (or even a URL) to an external config file that could be imported No need, it's already done ( and in 3.2 too ). ( I have no idea who did it - it's not me, and I was quite surprised to find it there :-) Any file named server-foo.xml will be read and used as addition to server.xml. In 3.3 you can use serverXmlReader to read additional files in arbitrary locations. Part of the current proposal is to formalize that and use explicit directives for what gets read. module - and you'll be able to set the location to anything you want ( or any other properties that affect its behavior ) Is this available in the current 3.3 milestone or nightly builds? The first milestone will happen soon, it's only in the nightly builds and it's not yet completed ( i.e. some of the paths are now configurable, but not all and not in all modules ). One of the goals for 3.3 release is to have all those small things that makes configuration easy ( as usability enhancements ). Q1: Why does it say in the documentation that conf/web.xml is used as a default? Needs to be corrected. I agree. Q2: More importantly, I'm still left with: How do I configure the use of a different servlet to handle *.jsp requests? In 3.3 - in JspInterceptor you have "useJspServlet" and "jspServlet" that allows you to specify it on a global level ( or per context ! ). This is strongly discuraged - as it'll be much slower than using JspInterceptor's optimizations. If your jsp processor does something special, you can bundle it with your application and use the web.xml ( from WEB-INF ) to set it. Then your app will work on any container the way you expect. Okay, so it sounds like I need to reconfigure the StaticInterceptor module. And I would do this... how? Is this possible on 3.2.1 or do I need to go to 3.3 for this? Could someone point me in the right direction here? Again - you can do it in a portable way ( using web.xml in your application ) or tomcat-specific, by replacing StaticInterceptor. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
