Re: [VOTE] Tomcat 4.0.2 b2 release
On Wed, 16 Jan 2002, Remy Maucherat wrote: [...] ballot [ ] +1 Make the release [X] +0 Good idea, but I can't help [ ] -0 Bad idea [ ] -1 No, because: /ballot -bip -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files
-Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED]] Actually, while I'm on that subject, the diffs are extensive since I've pretty much touched every SSI related file in a very significant way... in addition to removing a few of them. What is the preferred way to submit such a large patch? Send them along as .zip or .tar.gz if they're *really* big maybe you could put them somewhere and send along the link. Bip
RE: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files
-Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED]] [...] I now have this working on my system here. It currently passes all of the tester tests in addition to about 7 more tests that I added myself here locally. I also added the initial support for the set directive and variable substitution. I have one more command to get working and then some clean-up and I'll see about posting the diffs. Actually, while I'm on that subject, the diffs are extensive since I've pretty much touched every SSI related file in a very significant way... in addition to removing a few of them. What is the preferred way to submit such a large patch? I don't know how much you have left but I'm going to be unavailable for the coming weeks starting from tomorrow. I'm relocating back to Sweden from San Francisco. So if you want/can you could send me the files today and I could try and integrate the changes before I take off. Bip Thelin
RE: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files
-Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED]] [...] Actually, includes should share the environment of the parent... in fact, if they set server variables the parent will see them. Ok, that might be true(just looked at Apache's behavior and they seem to do just that), when we implemented SSI we strictly followed the NCSA standard which don't have set, and doesn't talk about if the included page should see commands set by the parent. God catch! Cool. I'm almost done refactoring. I'm basically replacing the SsiMediator with an SsiEnvironment that is then stuck into a request attribute. In the process, I'm moving some things around a little since all of the commands were relying on the fact that they were SsiMediator subclasses... and therefore directly accessing the static fields of SsiMediator. Ok, sounds good, send along some code and I can take a look at it and commit it. Bip
RE: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files
-Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED]] For the curious reader, after looking into this code at some length it seems clear why the set command was not added. All SSI requests share the same environment, which not only makes a set command impossible but also means that multiple SSI requests (or even nested SSI requests) trample all over each other. A simple shtml file that includes two other shtml files illustrates this quite nicely. Do you have a smal testcase? We have unittests with Tomcat that have nested includes and several includes in one page. All Ssi directives share the same enviroment per page through a mediator, this is due to the fact that you can have a config directive that changes the error message that you would get for a failed include further down on the same page, for instance. However if pageA includes pageB, if pageB is also an shtml/ssi file it would have a new fresh enviroment and could not tamper with pageA's enviroment. So you could easily do a set command simmilar to the config command. Since I'm between assignments at the moment, I'm working on a patch here locally. It's pretty significant, though, so it may take me a few days. It will include the set command though since that's what I'm going to use to test it. :) Patches and additions are gladly appreciated. Bip Thelin
RE: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi SsiMediator.java
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Could you also commit these fixes to the 4.0 branch if you can ? done, I have a bunch of enhancements on my table that I'm gonna take care of as soon as possible, I'm in the process if relocating back to sweden so I haven't been that active commiting code lately. Regards, Bip
RE: cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml
Oups, seems my XML editor reformatted/reindented everything if anyone experiences problem or disslike it feel free to change it or let me know and I can roll back and reapply my changes. Bip
RE: DO NOT REPLY [Bug 4259] New: - SSI prosessing loses content-type information
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] [...] SSI prosessing loses content-type information Summary: SSI prosessing loses content-type information Product: Tomcat 4 Version: 4.0 Final Platform: Sun OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This should be fixed in the coming nightly build, 20011019 Bip Thelin
RE: [VOTE] New Committer
-Original Message- From: Christopher Cain [mailto:[EMAIL PROTECTED]] I would like to nominate Patrick Luby [EMAIL PROTECTED] for committer status. His recent contributions include several security-manager-related patches and documentation help, and appears keen to tackle the Admin Apps functionality as well. I think he would make an excellent addition to the team. Votes please? +1 bienvenue à l'équipe! /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
RE: [VOTE] Release Plan for Apache Tomcat 4.0 (final release)
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Please review this proposal, and the associated Bugzilla bug reports, and cast your vote: -- Release Plan for Apache Tomcat 4.0 (final release) -- [X] +1I am in favor of this plan, and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I not in favor of this plan [ ] -1I am opposed to this plan, and my reason(s) are: +1 -Bip
RE: bugs to fix for tc4.0 final
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] I have reopened the bug, as jsp pages are not compiled under windows 2000 using jdk 1.4b2 and tc 4.0b7. Under jdk 1.3.1, everything works well. i suspect this is due to a change in the error reporting of the new javac compiler. Per the release plan, this is definitely on the must be addressed list. I can not reproduce this bug. Here's my java -version java version 1.4.0-beta2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta2-b77) Java HotSpot(TM) Client VM (build 1.4.0-beta2-b77, mixed mode) I'm running Windows 2000, build 5.00.2195 Service Pack 2 -Bip
RE: Addition of 'dirty' field to Session interface
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] [...] * Load-balanced distributed container that can move sessions around as various servers get overloaded. * Fail-safe distributed container that automatically recovers from server failures and reconnects you to a different one with your session intact. without the application developer having to worry about this for his/her session beans. The first case isn't so hard -- the only time you have to persist is when you are going to migrate, so you would just do it unconditinally. The second case is harder, unless you can afford the performance hit of persisting after *every* request. This is just an idea from the top of my head, would it be possible having a second vector that contains a footprint(not a full clone) of the object for a session and have a reaper thread checking the footprints against the real objects and determine if they changed or not and based on that replicate of whatever we want to do. Similar to how PersistentManager check sessions to determine if they should be swapped to disk or backed up. Or is this just plain dumb? -bip thelin
RE: [VOTE] New Tomcat Committer
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] As Jon informally did last week or so, I'd like to formally propose Christopher Cain [EMAIL PROTECTED] as a committer on Tomcat. He's contributed lots of useful discussion, patches, and documentation (particularly in the area of SSL-based things) and wants to do more. +1 -bip
RE: [PATCH] TC4 shell Scripts
-Original Message- From: Stephane Bailliez [mailto:[EMAIL PROTECTED]] Fixed some bugs that prevented its use under cygwin. Can someone with cygwin try out the catalina.sh diff, I commited the digest.sh diff. Thanks, Bip Thelin
RE: [VOTE] Sources in Binary Distributions
-Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] [...] [X] - +1 Remove the sources [I will help in the process, meaning do the job] [ ] - +0 Remove the sources [I can't help, won't help] [ ] - -0 Leave the sources [But since I don't volunteer this is not binding] [ ] - -1 Are you nuts? Sources are there and there have to remain. -bip
RE: [DOC] Resend of ROOT/index.html
-Original Message- From: Rob S. [mailto:[EMAIL PROTECTED]] [...] Here's my take on a new default index.html along with the jakarta banner since I've incorporated that in as well. I'd like it if all of the sample apps retained a somewhat similar look and feel (volunteering if people agree that it should be done). I tried this page under Opera and IE and it works fine. I'm scared to try NS! =) I've tried it in NS and it works fine. I'd really like the default apps to showcase Tomcat, and they've always been kind of clunky. IIRC, some of the JSP/Servlet example links don't work correctly. I'd also like the default homepage to brag about the features of Tomcat to some degree, e.g. session persistence and whatnot, but I don't know enough about these things yet... Of course, by mentioning this I'm implicitly volunteering to do it ;) Sounds great, If you feel like giving the default apps a more appealing look that goes well with what you just submitted I don't think anyone would disagree with updating them. Bip Thelin
RE: Sources in Binary Distributions
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] [...] For Tomcat 4, what do folks think of omitting the sources from the binary distribution? This would knock the size of the binary distributions down by around 2 megabytes (which I'm sure people would also appreciate). +1 And also update the build.xml to omitt the sources when compiling with target dist. ..bip
RE: Sources in Binary Distributions
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] [...] Well, ant dist ***is*** how binary distributions (for both the nightly builds and releases) are created, so this should not be too much of a surprise :-). Oups, ignore my last post. ..bip
Re: JDBC session store, release date projections, etc
Dunlop, Aaron wrote: [...] First: We will need to cluster application servers in front of a central database. We want the ability to add and remove servers from that farm in real-time, without disturbing ongoing sessions. That either means storing sessions remotely in the central DB, or migrating sessions from one machine to another. We'd like to avoid being forced into using session-affinity for load balancing, since in our environment, that would likely result in significantly unbalanced loads. There is some effort going on to provide Clustering ability for TC4, currently you can use it for in memory replication of sessions, however this feature is considered highly experimental. So that probably means we need JDBC session store. Correct? And if so, what (in your opinions) is the current state of JDBC Session Store? (Also - am I correct that it's only available under Tomcat 4.0? Will it eventually also be available under the 3.x series?) When it comes to storing sessions you can use either FileStore or JDBCStore, I would say that both are considered medium rare. ..bip
Re: the ssi mediator
Martin van den Bemt wrote: Hi, I've been browsing through the util package (catalaina/src/share/org/apache/catalina/util/* ) for my preperation of writing tests. I came acros the SsiMediator. All the ssi commands created there override SsiMediator and SsiMediator adds all the commands to a hashtable of the commands. Isn't it wiser to set up a ssicommands.properties with eg : config=org.apache.blah.blah Yes, I guess that would be a cleaner solution, however you could dispute what you would actually gain from it. The mediator was created because the SsiCommands needed to talk to each other at any given time. i.e. the config command could set a errmsg which would then be used for every SsiCommand on that page. And make a instance from that class depending on that properties file. This will make it more flexible and the compile dependencies on each ssi command are gone.. There would still be dependencies, the config command could change how the output would be for different tags and server variables. Don't if this stuff is actualy used in tomcat 4 (and how to use it), but just an idea.. It's used in Tomcat4, look in web.xml howto map it to a URL pattern. We could also do this for the server variables (don't know if this is subject to change though... I'm happy to do the rewrite if I can test this ;-). Remember that there are server variables that could be changed from the config commands. If you have any thoughts, ideas, patches on how to clean up the Ssi code and make it modular I'd be happy to review and commit it. ..bip
Re: public static String Digest() in JDBCRealm
Craig R. McClanahan wrote: It went away by accident during my refactoring. It'll get put back in (by me) sometime, unless someone wants to beat me to it (hint, hint :-). I put the static method back in along with the main() method. I'd actually prefer to see a little stand-alone tool for doing this (available in the bin directory with appropriate scripts), as well as having the static method restored. I can write up a little tool or script that does this. Maybe just a script that triggers the main method of JDBCRealm? ..bip
public static String Digest() in JDBCRealm
Have the public static Digest method in JDBCRealm gone away? I couldn't find it when browsing through RealmBase/JDBCRealm. ..bip
Re: public static String Digest() in JDBCRealm
Ignacio J. Ortega wrote: It 's on RealmBase at least on my CVS working copy.. Sorry, forgot to specify the version, do you have a public Digest method that is static for Tomcat 4 in RealmBase? ..bip
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreLocalStrings.propertiesStandardContextMapper.java
[EMAIL PROTECTED] wrote: craigmcc01/05/11 16:20:12 Modified:catalina/src/share/org/apache/catalina/core LocalStrings.properties StandardContextMapper.java Log: Return error 400 if the user uses invalid characters (including %00 and %7f) in a URI. This fixes a security vulnerability, present in 4.0-b4, that exposes JSP source code when you request: http://localhost:8080/examples/jsp/num/numguess.jsp%00 [...] Shouldn't we post a security hotfix or cut a new beta release? This seems like a pretty major security flaw. ..bip
Re: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
Craig R. McClanahan wrote: Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP 1.2 specs have been published (with Tomcat 4.0 updated to support the latest changes), and a ton of bug fixes have been made, I would like to propose that we create a Tomcat 4.0 Beta 4 release as follows: Release Manager: Craig McClanahan Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time See the file RELEASE-NOTES-4.0-B4.txt for a reasonably up-to-date list of the changes to date. This document will be updated with any additional changes that are made, plus a list of known outstanding issues. Between now and the code freeze, I'd like us to focus on fixing outstanding bugs and catching the configuration documentation up to date. I'm OK with continuing work on the new distributed session stuff in the mean time (as long as it is not enabled in the default configuration), but please hold off on making substantive changes in the core container until after the Beta 4 release. Comments? Votes? The usual rules apply: [ ] +1 = I agree with this proposal and will support it [ ] +0 = I agree with this proposal, but do not have time to support it [ ] -0 = I do not agree with this proposal, but don't want to try to block it [ ] -1 = I do not agree with this proposal (requires reasons) Craig +1 ..bip
Re: Class Loader Problem?
Wildeboer, Tonnis wrote: [...] I have gone so far as completely removing VCALookup.class from my classes directory and I still get the same Exception. I also tried instantiating the class from a different file (first line of my doGet()) and still get the same Exception. I copied a known good class (my servlet class), renamed it to VCALookup.class, same Exception. Ok, this is what the Javadocs say about java.lang.ClassFormatError. snip Thrown when the Java Virtual Machine attempts to read a class file and determines that the file is malformed or otherwise cannot be interpreted as a class file. /snip I interpret this as that the classloader are _finding_ the class but has problems loading it. What is this file/class? Something you copied from somewhere? Could it be that you are missing an inline class for VCALookup? i.e. VCALookup$inlineclass.class I would think that there's something wrong with the VCALookup class, if it couldn't find the file you wou'd have gotten a ClassNotFoundException. Is VCALookup refering to any other classed that you've missed to bring to your Tomcat env? 2001-05-01 04:19:15 - Ctx( ): Exception in: R( + /csp + /+cfi/login) - java.lang.ClassFormatError: VCALookup (Truncated class file) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass0(Compiled Code) at java.lang.ClassLoader.defineClass(Compiled Code) at java.security.SecureClassLoader.defineClass(Compiled Code) at java.net.URLClassLoader.defineClass(Compiled Code) at java.net.URLClassLoader.access$1(Compiled Code) at java.net.URLClassLoader$1.run(Compiled Code) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivileged(Compiled Code) at java.net.URLClassLoader.findClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at sun.misc.Launcher$AppClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at org.apache.tomcat.loader.AdaptiveClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClassInternal(Compiled Code) at MediatorAgent.printTemplateResponse(Compiled Code) at MediatorAgent.printResponse(MediatorAgent.java:606) at MainVCAServlet.doGeneral(Compiled Code) at MainVCAServlet.doGet(MainVCAServlet.java:196) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) Sorry I can't help you more. ..bip
Re: [PROPOSAL Tomcat 4.x] Cluster
Kief Morris wrote: [...] My point is that the Manager/Cluster needs to know when the session is in use by another instance of Catalina. A locking mechanism must be implemented by the Cluster (or whatever) to prevent a session from being used by multiple instances at once. This mechanism will require the Manager/Cluster system to know when a request begins using a session, and when it has finished. If we say that only one JVM at a time can manipulate a sessions since a sessions only belongs to one machine at a time the only time a session needs to be replicated is when it's created/changed/destroyed. Yes. But putting the session into the Cluster at creation time is unnecessary. It should be put in at the end of the request when it is created (other Catalina instances can't use it before then anyway), and updated at the end of each subsequent request. So we need to have the end of a request call into the Manager to indicate that the session can be sent to the Cluster and unlocked for use. Do we really need to lock a session for each request and then replicate it? Sorry I might be confused, you mean a request for a session or a request as in generating a new request object(http request). If we assume that a session is only in use in one JVM at a time(which I think we can assume) then that session doesn't need to be locked it just needs replication when it's changed. I'd rather see the replication be implemented in a Manager(i.e. DistributedManager or maybe change name to MulticastDistributedManager) thus making it possible to run any Store with the DistributedManager(i.e. FileStore). OK, I take your point that extending Store isn't the way to go. But I don't think we should have a different Manager implementation for each available distribution mechanism - MulticastDistributedManager, JMSDistributedManager, JavaSpacesDistributedManager, JCacheDistributedManager, etc. We should use the same pattern that Manager/Store uses: a single DistributedManager should be implemented which is independent of the actual session sharing mechanism. It should be able to use any implementation of the Cluster interface. Yes, sorry I was clear as mudd in my last email, so if you look at the DistributedManager.java I checked in 14h ago(as of writing) it now uses the new API's I created which is common for any distribuition protocol you might implement. I'd like to keep the possibility open to implement different distribution strategies. The strategy we're looking at now is for each instance of the application to hold copies of every session. An alternative Cluster strategy would keep the sessions in a central location such as a database: when a request comes in for a session not found in the current instance, the Cluster checks the database to see if it's there. This isn't too different from simply using JDBCStore. A third way is to have just two instances of the application holding a given session: when instance A creates the session, the Cluster chooses instance B to hold a backup copy in case A goes down: if a request comes in to C, B still has it available. One way that you could simply go with the cluster is to group them. So there is an option now to specify the name/port/address of the cluster. What I was thinking is that you could specify a cluster that this.jvm belongs too and then specify a cluster it should replicate too. Not that we need to implement all of these, but the architecture we build now should allow these possibilities and others. Other people can try out different ideas, and users can choose the system best suited to their needs. yes, agree. I'm also not sure about the issues with using persistence and distribution simultaneously. If we simply use PersistentManager with this distribution code, each instance will save its own copy of every session to persistent storage. This might be desirable in some cases - I can see using FileStore, for instance. But if you use JDBCStore and the Multicast distribution, it's wasteful - with a 4 server farm, we have 4 copies of each session in the database. So how should this be addressed? Cluster ought to have some mechanism which (optionally) ensures that each session is only persisted once. This may mean having Cluster override Store functionality, which is why I was thinking of combining the two. Yes, that's a good point, at first I was thinking that each machine in a Cluster is having it's own unique key, so when you generate an session id machine 1 would get something like: A1KDSFNRKIFLKMFDSFDSA where: || -- Are the two letters that identifies the machine, so when you know which machine that owns the session all machines that have the session replicated know that it doesn't belong to them so they shouldn't save in a Store. It's also useful for an eventuall tomcat dispatcher frontend to know which machine the session origins from. However some complications occur when you
Re: [VOTE] New Committer: Kevin Seguin
GOMEZ Henri wrote: I would like to propose Kevin Seguin as a new committer. He make a great job in developping the ajp13 protocol for Tomcat 4.0 and this code will be a great help for sites wanting to upgrade from 3.2.x to 4.0 while still using mod_jk +1 Welcome! ..bip
Re: JDBCStore package for Tomcat 4.x
Kief Morris wrote:
[...]
I think this is a good way to go about it: it looks like the table name can be
configured
in the server.xml file. Probably the column names should also maintained as JDBCStore
properties for configurability.
Yes, that's why I wrote the last email to get some feedback on fields needed for the
table.
I'll implement it so it'll be configurable.
The table will need a column for the lastAccessedTime. And the ID column will need to
be something like CHAR, VARCHAR, or BYTE rather than an int.
Yes, a typo from me. I looked at your latest patches for Persistentmanager and the
Managerbase
and it looks good. However we should come up with some smart solution when working
with JDBCStore,
the processexpires() in PersistentManagerBase is looking for current sessions then
swaping them
in and checking if they're valid, if so continue else invalidate. This is fine for
FileStore but
with JDBCStore this causes each session to be retrieved over the network(or where the
RDBMS is located)
just to check if the session is valid. Maybe we could add a method to the Store
interface, i.e.
public boolean isSessionValid(String sessionId) {}.
What you would gain from this is that each Store is responsible for checking if
expired in
the way that's best for that particular Store, with JDBC you could do that in a single
select
statement without having to retrieve the data from the session(Assuming you save the
lastaccesstime in
the database, I'm currently working on that).
..bip
Re: JDBCStore package for Tomcat 4.x
"Craig R. McClanahan" wrote: [...] One of my original thoughts was along this line ... a Store should be responsible for expiring its own swapped-out sessions. In practice, you would have a background thread inside JDBCStore doing this for you. The Store would also double check the current status while processing a load(). That's how I've implemented it right now, but that won't do it now when Kief has migrated it to the PersistentManagerBase. I think that it's good to abstract the thread/Lifecycle methods up to the Manager but maybe we should keep the proccessexpires method in the Store so each Store is responsible for checking expired sessions in it's own best way upon triggered from the reaper thread in the Manager. ..bip
Re: JDBCStore package for Tomcat 4.x
a.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import org.apache.catalina.Container;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Loader;
import org.apache.catalina.Logger;
import org.apache.catalina.Manager;
import org.apache.catalina.Session;
import org.apache.catalina.Store;
import org.apache.catalina.util.CustomObjectInputStream;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;
/**
* Implementation of the codeStore/code interface that stores
* serialized session objects in a database. Sessions that are
* saved are still subject to being expired based on inactivity.
*
* @author Bip Thelin
* @version $Revision$, $Date$
*/
public class JDBCStore
implements Lifecycle, Runnable, Store {
// - Instance Variables
/**
* The interval (in seconds) between checks for expired sessions.
*/
protected int checkInterval = 60;
/**
* The descriptive information about this implementation.
*/
protected static String info = "JDBCStore/1.0";
/**
* The lifecycle event support for this component.
*/
protected LifecycleSupport lifecycle = new LifecycleSupport(this);
/**
* Has this component been started yet?
*/
protected boolean started = false;
/**
* The property change support for this component.
*/
protected PropertyChangeSupport support = new PropertyChangeSupport(this);
/**
* The string manager for this package.
*/
protected StringManager sm = StringManager.getManager(Constants.Package);
/**
* The background thread.
*/
protected Thread thread = null;
/**
* The background thread completion semaphore.
*/
protected boolean threadDone = false;
/**
* The Manager with which this JDBCStore is associated.
*/
protected Manager manager;
/**
* The debugging detail level for this component.
*/
protected int debug = 0;
/**
* Name to register for the background thread.
*/
protected String threadName = "JDBCStore";
/**
* Connection string to use when connecting to the DB.
*/
protected String connString = null;
/**
* Table to use.
*/
protected String sessionTable = null;
/**
* The database connection.
*/
private Connection conn = null;
/**
* Driver to use.
*/
protected String driverName = null;
// - SQL Variables
/**
* Variable to hold the codegetSize()/code prepared statement.
*/
protected PreparedStatement preparedSizeSql = null;
/**
* Variable to hold the codekeys()/code prepared statement.
*/
protected PreparedStatement preparedKeysSql = null;
/**
* Variable to hold the codesave()/code prepared statement.
*/
protected PreparedStatement preparedSaveSql = null;
/**
* Variable to hold the codeclear()/code prepared statement.
*/
protected PreparedStatement preparedClearSql = null;
/**
* Variable to hold the coderemove()/code prepared statement.
*/
protected PreparedStatement preparedRemoveSql = null;
/**
* Variable to hold the codeload()/code prepared statement.
*/
protected PreparedStatement preparedLoadSql = null;
// - Properties
/**
* Return the info for this Store.
*/
public String getInfo() {
return(info);
}
/**
* Set the debugging detail level for this Store.
*
* @param debug The new debugging detail level
*/
public void setDebug(int debug) {
this.debug = debug;
}
/**
* Return the debugging detail level for this Store.
*/
public int getDebug() {
return(this.debug);
}
/**
* Set the driver for this Store.
*
* @param driverName The new driver
*/
public void setDriverName(String driverName) {
String oldDriverName = this.driverName;
this.driverName = driverName;
support.firePropertyChange("driverName",
oldDriverName,
this.driverName);
this.driverName = driverName;
}
/**
* Return the driver for this Store.
*/
public String getDriverName() {
return(this.driverName);
}
/**
* Set the Connection URL for this Store.
*
* @param connectionURL The new Connection URL
*/
public void setConnectionURL(String connectionURL) {
String oldConnStr
Re: JDBCStore package for Tomcat 4.x
"Craig R. McClanahan" wrote: [...] A couple of quick notes: - Would it be possible to flesh out the rest of the JavaDoc comments? I would like us to maintain the high quality level of JavaDocs that Tomcat 4 is known for :-) Flesh out? As in enhance the comments? Yes that's possible, when I'm done I could write up a little Howto on how to use it and how it works, a'la JDBCRealm. - Would it be possible to parameterize the SQL statements used to access the database? The idea would be that we can adapt to different table and column names (like JDBCRealm does on the authentication side). Yes, and I acctually have some refactoring I would like to try out. Thanks for the comments and suggestions. ..bip
[PATCH StandardSession] patch and additions to the Storeimplementations.
I took out the inline class CustomObjectInputStream from FileStore and put it in
org.apache.catalina.util since I need it for the JDBCStore too. There's also a
patch for StandardSession.java to return if the stream is null instead of giving
a NullPointerException, maybe it should throw an Exception instead of returning?
At least it won't corrupt the current Context if a session load is corrupt.
..bip
Index: CustomObjectInputStream.java
===
/*
* CustomObjectInputStream.java
* $Header$
* $Revision$
* $Date$
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.catalina.util;
import java.io.InputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectStreamClass;
/**
* Custom subclass of codeObjectInputStream/code that loads from the
* class loader for this web application. This allows classes defined only
* with the web application to be found correctly.
*
* @author Craig R. McClanahan
* @author Bip Thelin
* @version $Revision$, $Date$
*/
public final class CustomObjectInputStream
extends ObjectInputStream {
/**
* The class loader we will use to resolve classes.
*/
private ClassLoader classLoader = null;
/**
* Construct a new instance of CustomObjectInputStream
*
* @param stream The input stream we will read from
* @param classLoader The class loader used to instantiate objects
*
* @exception IOException if an input/output error occurs
*/
public CustomObjectInputStream(InputStream stream,
ClassLoader classLoader)
throws IOException {
super(stream);
this.classLoader = classLoader;
}
/**
* Load the local class equivalent of the specified stream class
* description, by using the class loader assigned to this Context.
*
* @param classDesc Class description from the input stream
*
* @exception ClassNotFoundException if this class cannot be found
* @exception IOException if an input/output error occurs
*/
protected Class resolveClass(ObjectStreamClass classDesc)
throws ClassNotFoundException, IOExceptio
JDBCStore package for Tomcat 4.x
NTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.catalina.session;
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.ObjectStreamClass;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import org.apache.catalina.Container;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Loader;
import org.apache.catalina.Logger;
import org.apache.catalina.Manager;
import org.apache.catalina.Session;
import org.apache.catalina.Store;
import org.apache.catalina.util.CustomObjectInputStream;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;
/**
* Concrete implementation of the codeStore/code interface that stores
* serialized session objects in a database. Sessions that are
* saved are still subject to being expired based on inactivity.
*
* @author Bip Thelin
* @version $Revision$, $Date$
*/
public final class JDBCStore
implements Lifecycle, Runnable, Store {
// - Instance Variables
/**
* The interval (in seconds) between checks for expired sessions.
*/
private int checkInterval = 60;
/**
* The descriptive information about this implementation.
*/
private static final String info = "JDBCStore/1.0";
/**
* The lifecycle event support for this component.
*/
protected LifecycleSupport lifecycle = new LifecycleSupport(this);
/**
* Has this component been started yet?
*/
private boolean started = false;
/**
* The property change support for this component.
*/
private PropertyChangeSupport support = new PropertyChangeSupport(this);
/**
* The string manager for this package.
*/
private StringManager sm = StringManager.getManager(Constants.Package);
/**
* The background thread.
*/
private Thread thread = null;
/**
* The background thread completion semaphore.
*/
private boolean threadDone = false;
/**
* The Manager with which this FileStore is associated.
*/
protected Manager manager;
/**
* The debugging detail level for this component.
*/
protected int debug = 0;
/**
* Name to register for the background thread.
*/
private String threadName = "JDBCStore";
/**
* Connection string to use when connecting to the DB.
*/
private String connString = null;
/**
* Table to use.
*/
private String sessionTable = null;
/**
* The database connection.
*/
private Connection conn = null;
/**
* Driver to use.
*/
private String driverName = null;
// - SQL Variables
private PreparedStatement preparedSizeSql = null;
private PreparedStatement preparedKeysSql = null;
private PreparedStatement preparedSaveSql = null;
private PreparedStatement preparedClearSql = null;
private PreparedStatement preparedRemoveSql = null;
private PreparedStatement preparedLoadSql = null;
// - Properties
/**
* Return the info for this Store.
*/
public String getInfo() {
return(info);
}
/**
* Set the debugging detail level for this Store.
*
* @param debug The new debugging detail level
*/
public void setDebug(int debug) {
this.debug = debug;
}
/**
* Return the debugging detail level for this Store.
*/
public int getDebug() {
return(this.debug);
}
/**
* Set the driver for this Store.
*
* @param driverName The new driver
*/
public void setDriverName(String driverName) {
String oldDriverName = this.driverName;
this.driverName =
[PATCH] patch to make PersistentManager work with different Storeimplementations.
This is a minor change so you can specify the store to use within server.xml.
Here's how you can change the Store use from server.xml:
Manager className="org.apache.catalina.session.PersistentManager"
debug="0"
saveOnRestart="true"
maxActiveSessions="1"
minIdleSwap="-1"
maxIdleSwap="1"
maxIdleBackup="-1"
Store className="org.apache.catalina.session.FileStore"/
/Manager
I'll hope to have a first cut of the JDBCStore soon.
..bip
[ PersistentManager.java ]
diff -r1.2 PersistentManager.java
267c266
---
store.setManager(this);
598,601d596
// Create the FileStore object.
// FIXME: Do this properly (configurable)
store = new FileStore();
store.setManager (this);
[ Catalina.java ]
diff -r1.17 Catalina.java
351a352,358
mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
mapper.objectCreate(null, "className"));
mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
mapper.setProperties());
mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
mapper.addChild("setStore", "org.apache.catalina.Store"));
[PATCH] patch to make PersistentManager work with different Storeimplementations.
If you get this email twice please ignore. Our emailserver experienced problems
yesterday
so I never think my email was delivered.
..bip
-
This is a minor change so you can specify the store to use within server.xml.
Here's how you can change the Store use from server.xml:
Manager className="org.apache.catalina.session.PersistentManager"
debug="0"
saveOnRestart="true"
maxActiveSessions="1"
minIdleSwap="-1"
maxIdleSwap="1"
maxIdleBackup="-1"
Store className="org.apache.catalina.session.FileStore"/
/Manager
I'll hope to have a first cut of the JDBCStore soon.
..bip
[ PersistentManager.java ]
diff -r1.2 PersistentManager.java
267c266
---
store.setManager(this);
598,601d596
// Create the FileStore object.
// FIXME: Do this properly (configurable)
store = new FileStore();
store.setManager (this);
[ Catalina.java ]
diff -r1.17 Catalina.java
351a352,358
mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
mapper.objectCreate(null, "className"));
mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
mapper.setProperties());
mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
mapper.addChild("setStore", "org.apache.catalina.Store"));
Re: ? on SSI virtual file
Amy Roh wrote: (1) According to NCSA "virtual gives a virtual path to a document on the server." So no matter which context you're in, !--#include virtual="/test.txt" -- should try to access "test.txt" on your server's root, right? Does virtual have to start with "/" always? I would think so. If not, what should be the behavior if it doesn't start with "/", context based? snip virtual gives a virtual path to a document on the server. You must access a normal file this way, you cannot access a CGI script in this fashion. You can, however, access another parsed document. /snip I would say that !--#include virtual="/test.txt" -- tries to access test.txt in the server's root. However if you read the rfc on virtual paths you can also use ., .., dir instead of starting with a / so then the following examples would/should work: !--#include file="file.txt" -- Which is a file in the current directory. !--#include file="./file.txt" -- Which is a file in the current directory. !--#include file="dir/file.txt" -- Which is a file in the "dir" directory _above_ the current directory. !--#include file="/file.txt" -- Which is a file on the servers root. !--#include file="../file.txt" -- Which is a file in the dir _below_ the current directory. (2) Also, NCSA states "file gives a pathname relative to the current directory." So obviously !--#include file="test.txt" -- should try to access "test.txt" in your current directory. What about "!--#include file="/test.txt" --"? Should that look for "test.txt" on your server root or on webapp? snip file gives a pathname relative to the current directory. ../ cannot be used in this pathname, nor can absolute paths be used. As above, you can send other parsed documents, but you cannot send CGI scripts. /snip As i enterpret this you can _only_ access a file using the file command in the following ways: !--#include file="file.txt" -- Which is a file in the current directory. !--#include file="dir/file.txt" -- Which is a file in the "dir" directory _above_ the current directory. !--#include file="/file.txt" -- Would fail. !--#include file="../file.txt" -- Would fail. And this is how it should be implemented right now. ..bip
Re: Behavior of new Server Side Include Functionality
"Craig R. McClanahan" wrote: We can provide this option since this kind of makes sense in a web-app environment. However, I think the default way should be relative to the server's root following NCSA. What do you think? +1 on defaulting to NCSA rules, but I'd really like to see a configurable option that virtual paths can be webapp-relative. Yes a webapp-relative option would seem good, but the option/standard way to run SSI should be NCSA compatible of course. You want to take this bug Amy? Let me know if you have any problems or need any help, I know I could of documented the code a bit better ;) ..bip
Re: CGI support servlet (TC 4) -- feedback wanted
"Craig R. McClanahan" wrote: 2) Addition to default context Would this CGI servlet be added to the default context similar to SsiInvokerServlet? Yes. I would suggest that we do this, but leave it commented out. The reason is that the potential for mischief is *much* larger when we are talking about executing outside programs instead of just displaying content back to a web browser. I vote for making the Tomcat sysadmin have to enable this feature explicitly if they want it. Once we implement the #exec functionality in SSI, the same argument would apply here -- unless we added a config option to disable the #exec by default but left everything else alone. +1 on having CGI in web.xml but commented out, regarding SSI I suggest we add a configure property(like Apaches NoExec) that set's whether #exec is allowed or not. And if that property is not set it defaults to NoExec. So for a standard setup SSI would be allowed but you'd have to bug your Tomcat sysadmin to have the #exec option enabled. Sort of like a standard Apache setup. ..bip
Re: JDBC-Session store
Kief Morris wrote: Excellent! Let us know if you need any help. I will, BTW how is the work on distributed sessions coming along? Is it possible to distribute sessions over x number of machines and that if one goes down you could go to the other and happily continue your session? ..bip
Re: JDBC-Session store
"Craig R. McClanahan" wrote: [...] Kief, a while back (when the work on PersistentManager was going on), the need for a little refactoring work on Manager vs. StandardManager would be useful. Have you thought any more about what we should do here? I couldn't find anything about how to add the PersistenManager in server.xml or in the manuals, however, after backtracking the maillist I found a "patch" by Kief that seems to have been forgotten, I'll cat it to the end of this mail. Maybe it can find it's way into the server.xml after all. Cheers, Bip --[ server.xml patch from Kief Morris ] --- server.xml.orig Sat Dec 16 20:03:29 2000 +++ server.xml Fri Jan 12 22:01:04 2001 @@ -179,6 +179,53 @@ Ejb name="ejb/EmplRecord" type="Entity" home="com.wombat.empl.EmployeeRecordHome" remote="com.wombat.empl.EmployeeRecord"/ +!-- + PersistentManager + Uncomment the section below to test Persistent Sessions. + + saveOnRestart: If true, all active sessions will be saved + to the Store when Catalina is shutdown, regardless of + other settings. All Sessions found in the Store will +be + loaded on startup. Sessions past their expiration are + ignored in both cases. + maxActiveSessions: If 0 or greater, having too many active + sessions will result in some being swapped out. +minIdleSwap + limits this. -1 means unlimited sessions are allowed. + 0 means sessions will almost always be swapped out +after + use - this will be noticeably slow for your users. + minIdleSwap: Sessions must be idle for at least this long + (in seconds) before they will be swapped out due to + maxActiveSessions. This avoids thrashing when the site +is + highly active. -1 or 0 means there is no minimum - +sessions + can be swapped out at any time. + maxIdleSwap: Sessions will be swapped out if idle for this + long (in seconds). If minIdleSwap is higher, then it +will + override this. This isn't exact: it is checked +periodically. + -1 means sessions won't be swapped out for this reason, + although they may be swapped out for maxActiveSessions. + If set to = 0, guarantees that all sessions found in +the + Store will be loaded on startup. + maxIdleBackup: Sessions will be backed up (saved to the Store, + but left in active memory) if idle for this long (in +seconds), + and all sessions found in the Store will be loaded on +startup. + If set to -1 sessions will not be backed up, 0 means +they + should be backed up shortly after being used. + + To clear sessions from the Store, set maxActiveSessions, +maxIdleSwap, + and minIdleBackup all to -1, saveOnRestart to false, then +restart + Catalina. + -- + !-- + Manager className="org.apache.catalina.session.PersistentManager" + debug="0" + saveOnRestart="true" + maxActiveSessions="-1" + minIdleSwap="-1" + maxIdleSwap="-1" + maxIdleBackup="-1" + Store className="org.apache.catalina.session.FileStore"/ + /Manager + -- Environment name="maxExemptions" type="java.lang.Integer" value="15"/ Parameter name="context.param.name" value="context.param.value"
Re: JDBC-Session store
Grr, seems my message got stuck somewhere so I'll resend it. "Craig R. McClanahan" wrote: [...] Kief, a while back (when the work on PersistentManager was going on), the need for a little refactoring work on Manager vs. StandardManager would be useful. Have you thought any more about what we should do here? I couldn't find anything about how to add the PersistenManager in server.xml or in the manuals, however, after backtracking the maillist I found a "patch" by Kief that seems to have been forgotten, I'll cat it to the end of this mail. Maybe it can find it's way into the server.xml after all. Cheers, Bip --[ server.xml patch from Kief Morris ] --- server.xml.orig Sat Dec 16 20:03:29 2000 +++ server.xml Fri Jan 12 22:01:04 2001 @@ -179,6 +179,53 @@ Ejb name="ejb/EmplRecord" type="Entity" home="com.wombat.empl.EmployeeRecordHome" remote="com.wombat.empl.EmployeeRecord"/ +!-- + PersistentManager + Uncomment the section below to test Persistent Sessions. + + saveOnRestart: If true, all active sessions will be saved + to the Store when Catalina is shutdown, regardless of + other settings. All Sessions found in the Store will +be + loaded on startup. Sessions past their expiration are + ignored in both cases. + maxActiveSessions: If 0 or greater, having too many active + sessions will result in some being swapped out. +minIdleSwap + limits this. -1 means unlimited sessions are allowed. + 0 means sessions will almost always be swapped out +after + use - this will be noticeably slow for your users. + minIdleSwap: Sessions must be idle for at least this long + (in seconds) before they will be swapped out due to + maxActiveSessions. This avoids thrashing when the site +is + highly active. -1 or 0 means there is no minimum - +sessions + can be swapped out at any time. + maxIdleSwap: Sessions will be swapped out if idle for this + long (in seconds). If minIdleSwap is higher, then it +will + override this. This isn't exact: it is checked +periodically. + -1 means sessions won't be swapped out for this reason, + although they may be swapped out for maxActiveSessions. + If set to = 0, guarantees that all sessions found in +the + Store will be loaded on startup. + maxIdleBackup: Sessions will be backed up (saved to the Store, + but left in active memory) if idle for this long (in +seconds), + and all sessions found in the Store will be loaded on +startup. + If set to -1 sessions will not be backed up, 0 means +they + should be backed up shortly after being used. + + To clear sessions from the Store, set maxActiveSessions, +maxIdleSwap, + and minIdleBackup all to -1, saveOnRestart to false, then +restart + Catalina. + -- + !-- + Manager className="org.apache.catalina.session.PersistentManager" + debug="0" + saveOnRestart="true" + maxActiveSessions="-1" + minIdleSwap="-1" + maxIdleSwap="-1" + maxIdleBackup="-1" + Store className="org.apache.catalina.session.FileStore"/ + /Manager + -- Environment name="maxExemptions" type="java.lang.Integer" value="15"/ Parameter name="context.param.name" value="context.param.value"
JDBC-Session store
According to the STATUS.html(which doesn't seem to be up to date) no one seems to have volunteered for the JDBC-Session store. If that is truly the case I would like to volunteer for that part. Thanks, Bip
SSI Update
Here's the latest version of the SSI package which now *fully* implements: Echo Config errmsg sizefmt timefmt Fsize flastmod include exec is the only command from the NCSA SSI standard that is not supported. Enjoy, Bip tomcat-4.x.SSI.zip
Re: TOMCAT 4.x SSI Status
Attached is the latest SSI package, it's not heavily tested. It supports expiration on the SSI page and buffering. Check below how to use it also ook below on what's implemented and what's not. Amy, check the files and mail me and we can decide how to work on the package towards a "stable" release. BTW; Anyone know where to buy those old pimp-ass Kung Fu movies in San Francisco? I'm talking about stuff like: 36chambers, Chess Boxing, 5 deadly Venoms, Wu-tang. Cheers, Bip --- ::: Implemented / Not implemented #+Echo #Config *errmsg *sizefmt timefmt #@Fsize flastmod exec #@include * == fully supported. # == partly supported. @ == virtual directive not supported. + == Missing enviromental variables: DOCUMENT_NAME: The current filename. DOCUMENT_URI: The virtual path to this document (such as /docs/tutorials/foo.shtml). QUERY_STRING_UNESCAPED: The unescaped version of any search query the client sent, with all shell-special characters escaped with \. DATE_LOCAL: The current date, local time zone. Subject to the timefmt parameter to the config command. DATE_GMT: Same as DATE_LOCAL but in Greenwich mean time. LAST_MODIFIED: The last modification date of the current document. Subject to timefmt like the others. ::: To use add the following to your web.xml: 8-- servlet servlet-namessi/servlet-name servlet-classorg.apache.catalina.servlets.SsiInvokerServlet/servlet-class init-param !-- debug 0 == debug enabled -- param-namedebug/param-name param-value1/param-value /init-param init-param !-- time in seconds before the SSI page expires -- param-nameexpires/param-name param-value666/param-value /init-param init-param !-- 0 == false; 1 == true -- param-namebuffered/param-name param-value1/param-value /init-param load-on-startup5/load-on-startup /servlet servlet-mapping servlet-namessi/servlet-name url-pattern*.shtml/url-pattern /servlet-mapping 8--
[Fwd: Re: TOMCAT 4.x SSI Status]
And here's the file I proMISSED. ..bip Original Message Subject: Re: TOMCAT 4.x SSI Status Date: Tue, 20 Mar 2001 17:20:30 -0800 From: Bip Thelin [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Organization: Razorfish To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Attached is the latest SSI package, it's not heavily tested. It supports expiration on the SSI page and buffering. Check below how to use it also ook below on what's implemented and what's not. Amy, check the files and mail me and we can decide how to work on the package towards a "stable" release. BTW; Anyone know where to buy those old pimp-ass Kung Fu movies in San Francisco? I'm talking about stuff like: 36chambers, Chess Boxing, 5 deadly Venoms, Wu-tang. Cheers, Bip --- ::: Implemented / Not implemented #+Echo #Config *errmsg *sizefmt timefmt #@Fsize flastmod exec #@include * == fully supported. # == partly supported. @ == virtual directive not supported. + == Missing enviromental variables: DOCUMENT_NAME: The current filename. DOCUMENT_URI: The virtual path to this document (such as /docs/tutorials/foo.shtml). QUERY_STRING_UNESCAPED: The unescaped version of any search query the client sent, with all shell-special characters escaped with \. DATE_LOCAL: The current date, local time zone. Subject to the timefmt parameter to the config command. DATE_GMT: Same as DATE_LOCAL but in Greenwich mean time. LAST_MODIFIED: The last modification date of the current document. Subject to timefmt like the others. ::: To use add the following to your web.xml: 8-- servlet servlet-namessi/servlet-name servlet-classorg.apache.catalina.servlets.SsiInvokerServlet/servlet-class init-param !-- debug 0 == debug enabled -- param-namedebug/param-name param-value1/param-value /init-param init-param !-- time in seconds before the SSI page expires -- param-nameexpires/param-name param-value666/param-value /init-param init-param !-- 0 == false; 1 == true -- param-namebuffered/param-name param-value1/param-value /init-param load-on-startup5/load-on-startup /servlet servlet-mapping servlet-namessi/servlet-name url-pattern*.shtml/url-pattern /servlet-mapping 8-- tomcat-4.x.SSI.zip
Re: TOMCAT 4.x SSI Status
Amy Roh wrote: Bip, What's the status on the SSI feature that you were working on. I would like to help you finish all the features and commit the code if you'd like. Status? Hi, I'll mail the latest source later on today(Pacific time). I've had my ass full of good 'ol work-work lately. That's why I haven't already mailed something out. I'll give you a quick update on status and my thoughts around it when I mail out the source. Aiight! ..bip
Re: [TOMCAT 4.x SSI] Update
Hans Bergsten wrote: JSSI supports most of the NCSA SSI commands as well as the servlet tag for invoking servlets. In addition, it implements a number of configurable settings, such as expiration time, buffering, (and server-side caching, I believe) etc. When I started writing the SSI-servlet I did not have in mind to add support for ".jhtml", I was envisioning a servlet that _only_ supported NCSA SSI. I believe that SSI support and ".jhtml" support are two different packages so therefore when I looked at JSSI I did it from a view of how easy it was to modify this to work with Tomcat, for me and write up the missing SSI commands and also "strip out" the ".jhtml" support since I believe that that's another package/servlet/"whatever" to be implemented. Both so that it leaves the user with most flexibility as well as making it easier for us to maintain/update/modify without breaking the other functionality. I came to the conclusion that it was probably easier for me to try to use what JSSI has done in terms of SSI commands and implement that in "my" framework than it was for me to port the whole application. By the way, I just implemented Expiration and buffering. Most importantly, people who come to Tomcat from JServ are primarily interested in getting the same SSI support as they had in JServ. So in addition to saving on the initial implementation time by porting JSSI instead of starting from scratch, you will also end up with the SSI functionality the majority of the users expect. My goal is to stick to the NCSA SSI standard and maybe later on add support for xSSI so I don't think that _anyone_ will have problem with the SSI implementation from a user perspective. So I strongly suggest that you port JSSI. Most of it can be used as is. The only things that need to be tweaked are probably using resources instead of File, and using a different interface to ask Tomcat to load servlets. You may even drop support for the class and init parameters in the servlet tag, and then get away with just using the standard features in Servlet 2.3: getNamedDispatcher() plus a request wrapper that merges the original parameters with the ones specified in the servlet tag. I'm not trying the reinvent the wheel, I just want to accomplish a robust SSI-package that does only that and does it good. I haven't looked at ".jhtml" and hadn't even planned to write up that support for tomcat. But if my spare time allows me maybe I should :) Anyone can feel free to comment since I'm more than willing to discuss and eventually change my mind in this matter for the best of the outcome. ..bip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[TOMCAT 4.x SSI] Update
Here's an update of the SSI package I submitted a week ago. The "only" SSI command that has been added is 'echo', example. !--# echo var="SERVER_NAME"--. The main part of the update is a major rewrite of code/[structure|pattern]. Please let me know if you find bugs/flaws. I appologize for the paths in the Zipfile, for some reason Winzip screwed up my path. Anyway this is how the file layout should look like once deployed. catalina \ - servlets / SsiInvokerServlet.java | \ - util / ssi / SsiMediator.java SsiCommand.java SsiConfig.java SsiEcho.java SsiExec.java SsiFlastmod.java SsiFsize.java SsiInclude.java ..bip tomcat-4.x.SSI.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Tomcat 4.x] SSI package
Attatched is a _very_ early release of the SSI package. It's just the initial framework and one working SSI command 'fsize' which returns a file's size. Looks like this: '!--#fsize virtual="/tomcat.gif"--' I appologize for the path in the Zipfile, for some reason Winzip screwed up my path. Anyway this is how the file layout should look like once deployed. catalina \ - servlets / SsiInvokerServlet.java | \ - util / ssi / SsiCommand.java SsiConfig.java SsiEcho.java SsiExec.java SsiFlastmod.java SsiFsize.java SsiInclude.java To try it out map e.g "*.shtml" to the SsiInvoker in web.xml. ---8- !-- The SSI invoker servlet -- servlet servlet-namessi/servlet-name servlet-classorg.apache.catalina.servlets.SsiInvokerServlet/servlet-class init-param param-namedebug/param-name param-value1/param-value /init-param load-on-startup5/load-on-startup /servlet !-- The mapping for the SSI servlet -- !-- Comment this out if you do not want "jsp" service -- servlet-mapping servlet-namessi/servlet-name url-pattern*.shtml/url-pattern /servlet-mapping ---8- I'd love constructive critic on design issues as well as eventual performance issues or bugs. I'll try and finish the other ones soon and have the whole package up to a "final/production" status. ..bip tomcat-4.x.SSI.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[TOMCAT 4.x] SSI - Servlet Provided Functionality
I've started working on the SSI implementation for Tomcat 4.x. I don't know if anyone else is working on that since I didn't see anyone volunteered. However I've come a bit on the way and should have a beta due next week. Let you know further when I have code to present. Regards, Bip /* This message is encrypted in a way that makes it look like an ordinary message */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
