cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators StaticInterceptor.java
nacho 01/03/24 11:56:06
Modified:src/share/org/apache/tomcat/modules/generators
StaticInterceptor.java
Log:
Oops.
Revision ChangesPath
1.9 +0 -3
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/StaticInterceptor.java
Index: StaticInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/StaticInterceptor.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- StaticInterceptor.java2001/03/24 19:48:32 1.8
+++ StaticInterceptor.java2001/03/24 19:56:06 1.9
@@ -292,8 +292,6 @@
File file = new File( absPath );
String headerValue=req.getHeader("If-Modified-Since");
-/**/
-headerValue = req.getHeader("If-Modified-Since");
if (headerValue != null) {
Date date = null;
@@ -317,7 +315,6 @@
}
-/**/
if( debug0) log( "After paranoic checks = " + absPath);
String mimeType=ctx.getMimeMap().getContentTypeFor(absPath);
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory MailSessionFactory.java ResourceFactory.java
On Sat, 24 Mar 2001, Remy Maucherat wrote: Where? This didn't work until I modified ResourceFactory to take care of it, copying the way that the default resource factory for a DataSource is set up. You can set parameters for a resource (ejb-ref, resource-ref, and the others) with : If the resource is jdbc/TestDB, the parameters are defined with : ResourceParams name="jdbc/TestDB" parameternamefactory/namevaluefactory_class_name/value/parameter parameternameuser/namevaluesa/value/parameter parameternamepassword/namevalue/value/parameter parameternamedriverClassName/name valueorg.hsql.jdbcDriver/value/parameter parameternamedriverName/name valuejdbc:HypersonicSQL:database/value/parameter /ResourceParams Oh, OK. We should probably write up some simple docs on this. Because javax.mail.Session is a standard J2EE resource type, I'm going to go ahead and leave it defaulting to the factory I just created, so users don't have to remember that. Sure, that's what we should do with the default types. I presume that a user-supplied factory would need to be visible to the Catalina class loader, right? Yes. It can be put where the namingfactory.jar is. I don't know if it works if it's in the webapp. Note the factory parameter. Also, I noticed one other thing that I'm about to fix. The entries for resources, EJB references, and so on are getting created in the "java:com" context. According to the J2EE spec, they are supposed to be in the "java:comp/env" context (along with environment entries). It's a real simple patch, to be submitted shortly after I double check that it works correctly. Yes, I made a mistake. I can fix it. See next CVS commit. Cool. Remy
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators StaticInterceptor.java
nacho 01/03/24 13:33:53
Modified:src/share/org/apache/tomcat/modules/generators
StaticInterceptor.java
Log:
tuneup If-Modified-Since honoring 3.3 style..
MessageBytes has inside all the needed RFC dates parsing things..
Revision ChangesPath
1.10 +5 -21
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/StaticInterceptor.java
Index: StaticInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/StaticInterceptor.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- StaticInterceptor.java2001/03/24 19:56:06 1.9
+++ StaticInterceptor.java2001/03/24 21:33:53 1.10
@@ -62,6 +62,7 @@
import org.apache.tomcat.util.res.StringManager;
import org.apache.tomcat.util.io.FileUtil;
import org.apache.tomcat.util.http.*;
+import org.apache.tomcat.util.buf.*;
import java.io.*;
import java.net.*;
import java.text.*;
@@ -240,14 +241,6 @@
final class FileHandler extends Handler {
int realFileNote;
Context context;
-/**
- * The set of SimpleDateFormat formats to use in getDateHeader().
- */
-protected static final SimpleDateFormat formats[] = {
- new SimpleDateFormat("EEE, dd MMM HH:mm:ss zzz", Locale.US),
- new SimpleDateFormat("EE, dd-MMM-yy HH:mm:ss zzz", Locale.US),
- new SimpleDateFormat("EEE d HH:mm:ss ", Locale.US)
-};
FileHandler() {
// setOrigin( Handler.ORIGIN_INTERNAL );
@@ -291,22 +284,13 @@
}
File file = new File( absPath );
-String headerValue=req.getHeader("If-Modified-Since");
-if (headerValue != null) {
+MessageBytes imsMB=req.getMimeHeaders().getValue("If-Modified-Since");
-Date date = null;
+if (imsMB != null) {
-// Parsing the HTTP Date
-for (int i = 0; (date == null) (i formats.length); i++) {
-try {
-date = formats[i].parse(headerValue);
-} catch (ParseException e) {
-;
-}
-}
+long date = imsMB.getTime();
-if ((date != null)
- (file.lastModified() = (date.getTime() + 1000)) ) {
+if ((file.lastModified() = (date + 1000)) ) {
// The entity has not been modified since the date
// specified by the client. This is not an error case.
context.getContextManager().handleStatus( req, res, 304);
RE: Still have XML loading problems
I'm interested in seeing if we can gather enough folks to start a "Jasper 2.0" effort, on a completely fresh slate. The design of this would take into account the two input syntaxes and everything we've learned, and the implementation could implement many obvious optimizations that would speed up the runtime code as well. What do you think? I think this is a great idea - I'd certainly be interested, Kevin Jones DevelopMentor www.develop.com
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: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory MailSessionFactory.java ResourceFactory.java
Craig,
I have another version of a MailSessionFactory (I thought I had mentioned
I would take care of it). It is identical to what you just commited,
with one exception.
It uses getInstance() instead of getDefaultInstance(). getDefaultInstance()
creates just one instance of a Session for the entire JVM which would be global
to all web applications. With getInstance() you can configure different SMTP settings
per web application.
I also have an updated version of the Factory which creates a MimePartDataSource
which allows more generic configuration of SMTP settings like you did below.
Regards,
Glenn
[EMAIL PROTECTED] wrote:
/**
* pFactory class that creates a JNDI named JavaMail Session factory,
* which can be used for managing inbound and outbound electronic mail
* messages via JavaMail APIs. All messaging environment properties
* described in the JavaMail Specification may be passed to the Session
* factory; however the following properties are the most commonly used:/p
* ul
* li
* listrongmail.smtp.host/strong - Hostname for outbound transport
* connections. Defaults to codelocalhost/code if not specified./li
* /ul
*
* pThis factory can be configured in a codelt;DefaultContextgt;/code
* or codelt;Contextgt;/code element in your codeconf/server.xml/code
* configuration file. An example of factory configuration is:/p
* pre
* lt;Resource name="mail/smtp" auth="CONTAINER"
* type="javax.mail.Session"/gt;
* lt;ResourceParams name="mail/smtp"gt;
* lt;parametergt;
* lt;namegt;factorylt;/namegt;
* lt;valuegt;org.apache.naming.factory.MailSessionFactorylt;/valuegt;
* lt;/parametergt;
* lt;parametergt;
* lt;namegt;mail.smtp.hostlt;/namegt;
* lt;valuegt;mail.mycompany.comlt;/valuegt;
* lt;/parametergt;
* lt;/ResourceParamsgt;
* /pre
*
* @author Craig R. McClanahan
* @version $Revision: 1.1 $ $Date: 2001/03/24 20:52:07 $
*/
public class MailSessionFactory implements ObjectFactory {
/**
* The Java type for which this factory knows how to create objects.
*/
protected static final String factoryType = "javax.mail.Session";
/**
* Create and return an object instance based on the specified
* characteristics.
*
* @param refObj Reference information containing our parameters, or null
* if there are no parameters
* @param name The name of this object, relative to context, or null
* if there is no name
* @param context The context to which name is relative, or null if name
* is relative to the default initial context
* @param env Environment variables, or null if there are none
*
* @exception Exception if an error occurs during object creation
*/
public Object getObjectInstance(Object refObj, Name name, Context context,
Hashtable env) throws Exception
{
// Return null if we cannot create an object of the requested type
final Reference ref = (Reference) refObj;
if (!ref.getClassName().equals(factoryType))
return (null);
// Create a new Session inside a doPrivileged block, so that JavaMail
// can read its default properties without throwing Security
// exceptions
return AccessController.doPrivileged( new PrivilegedAction() {
public Object run() {
// Create the JavaMail properties we will use
Properties props = new Properties();
props.put("mail.transport.protocol", "smtp");
props.put("mail.smtp.host", "localhost");
Enumeration attrs = ref.getAll();
while (attrs.hasMoreElements()) {
RefAddr attr = (RefAddr) attrs.nextElement();
if ("factory".equals(attr.getType()))
continue;
props.put(attr.getType(), (String) attr.getContent());
}
// Create and return the new Session object
Session session = Session.getDefaultInstance(props, null);
return (session);
}
} );
}
}
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
RE: Thread pools
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. I'm +1 for checking it in. I think there are still enough bugs to fix to justify the next Tomcat 3.3 release being Milestone 3 instead of Beta 1. I think there will be time to give it a good test. Larry
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory MailSessionFactory.java ResourceFactory.java
On Sat, 24 Mar 2001, Glenn Nielsen wrote: Craig, I have another version of a MailSessionFactory (I thought I had mentioned I would take care of it). It is identical to what you just commited, with one exception. Well, I must have missed your message about taking care of it (but it was a good learning experience for me anyway). Once we get the Commons project up and running, the in-memory naming context stuff might be a good candidate for a shareable component, and I wanted to understand a bit more about how it worked first. It uses getInstance() instead of getDefaultInstance(). getDefaultInstance() creates just one instance of a Session for the entire JVM which would be global to all web applications. With getInstance() you can configure different SMTP settings per web application. That sounds like a *much* better idea. Go ahead and switch this this to getInstance() if you want. I also have an updated version of the Factory which creates a MimePartDataSource which allows more generic configuration of SMTP settings like you did below. It seems like a pretty good design pattern when the underlying factory accepts an arbitrary set of properties. Regards, Glenn Craig
