Re: [Tomcat 4] Session Handling Enhancements
Craig R. McClanahan typed the following on 04:40 PM 2/5/2001 -0800 (1) Session Save/Restore Across App Restarts Currently, StandardManager saves and restores sessions across app restarts (i.e. autoreload if turned on, or normal shutdown and startup). It should be modified to use the new passivate() and activate() methods of the session implementation to warn interested session attributes that this activity is taking place. -0 How about stripping this entirely out of StandardManager? People who want to keep sessions over restarts can use PersistentManager, leaving StandardManager as a slimmer, simpler default. (2) Modify StandardSession.readObject() and writeObject() Currently, when the session is being serialized, the attributes are removed via removeAttribute() -- which triggers calls to valueUnbound() of attributes that implement HttpSessionBindingListener, among other things. Likewise, when the session is reloaded in readObject, setAttribute() is called and triggers calls to valueBound(). These calls were initially made to give session attributes some knowledge that a restart was being done. Now that the activate and passivate mechanisms are in place, I propose that these mechanisms be changed to *not* unbind and bind the attributes during these processes. Any interested attribute can implement HttpSessionAttributeListener instead. You mean HttpSessionActivationListener? If so I'm +1 on this - I can make this change. (3) Change "final" classes One of the challenges Kief ran into is that StandardManager and StandardSession are both marked final, and therefore cannot be subclassed. I propose to remove the "final" modifier so that this restriction is no longer in place. Additional refactoring can be performed separately, but you should at least be able to subclass these classes. +1 - I can do this also. What do you think about pushing more functionality up into ManagerBase, and creating a SessionBase class? Most of what I want to do shouldn't need subclassing of StandardManager/Session. Kief - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4] Session Handling Enhancements
Craig R. McClanahan [EMAIL PROTECTED] wrote: The session handling enhancements proposed by Kief Morris [EMAIL PROTECTED] have been committed on the Tomcat 4.0 CVS repository. Way cool... Thanks Kief... -- Pier Fumagalli mailto:[EMAIL PROTECTED] - 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
"Craig R. McClanahan" wrote: Glenn Nielsen wrote: "Craig R. McClanahan" wrote: [EMAIL PROTECTED] wrote: When Jasper is run in a servlet container it no longer puts the class files in a package, they are now in the default package. As was discussed earlier on TOMCAT-DEV, this is going to cause portability problems for people who use beans that are not in packages. With this change, such beans will work in Tomcat but not when the app is moved to a different container that *does* put JSP-generated servlets into a package. The previous behavior (Jasper-generated servlets go into a package) avoided this, because it essentially disallowed non-packaged beans. Therefore, I prefer it. (Also, I seem to remember a discussion on the expert group for JSP 1.2 that non-packaged beans and generarted classes should be disallowed, but I have not yet located any reference to this in the 1.2 spec.) If you check the code for JasperLoader you will find that it requires all classes to be in a package, the only class that does not have to be in a package is the JSP page itself. That's true, but Steve Downey also found the spec reference I couldn't find (in Section 8.2 of the JSP 1.2 Proposed Final Draft). The JSP page class is required to be in a package for 1.2. Ok, I'm convinced thanks to Steve and Craig. I'll put compiled jsp pages in the package "org.apache.jsp" (JspC can still specify a package). I will have to make some changes to the Jasper class loader to support this. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - 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 package naming solution I've opt'ed for in my own enhancement to Jasper (which I'll gladly share) is to derive package names that are related to the location of the jsp relative to the server context. This is simple, flexible and should avoid collisions. Some implementation details are: Configurable properties (loaded at startup and available through an extention of the Constants class): - default JSP_PACKAGE root (i.e. 'jsp_servlet') - PACKAGE_PREFIX string (i.e. '_') I've then created an extention of JspCompilerContext that adds method for deriving fully-qualified class names for the generated classes. Among these are assertion methods that force conformance with java naming conventions (allowed letters, disallowed keywords, etc) as described in the Java Language Specification. These two methods are: public static String manglePackageName(String s) and public static String mangleNameLetters(String s) Using these utilities and the above configurable properties I then have methods that actually derive the package and file names I need given a Jsp File. public static String buildPackageName(File file) let ifile/i correspond to the path "foo/somedir/myfile.jsp", JSP_PACKAGE="jsproot" and PACKAGE_PREFIX="x". In that case the return value would be "jsproot.xfoo.xsomedir". public static String buildClassName(File file) let ifile/i correspond to the path "foo/somedir/myfile.jsp", JSP_PACKAGE="jsproot" and PACKAGE_PREFIX="x". In that case the return value would be "xmyfile". public static String buildJavaFileName( String srcDir, String clsName) calculates the absolute filename for the .java file corresponding to the class clsName residing under the directory srcDir. For example if srcDir = "/opt/myapp/work" and clsName="jsproot.xfoo.xsomedir.myfile" then this returns the string "/opt/myapp/work/jsproot/xfoo/xsomedir/myfile.java" public static String buildClassFileName( String clsDir, String clsName) like buildJavaFileName() except result would be: "/opt/myapp/work/jsproot/xfoo/xsomedir/myfile.class" These static methods are used by the JspContext (which extends JspEngineContext) to derive the instance methods: public String getServletClassName() public String getServletPackageName() public String getFullJavaClassName() public String getServletJavaFileName() public String getServletClassFileName() The result is that you have a lot of control over the naming used by the generated classes. Further, the resulting .java files are much easier to find and look at when debugging. This mangling scheme does not do any incrementing because a new JspLoader is used each time a JSP gets reloaded dynamically. This package also provides a mechanism for recursively detecting changes to statically included JSP files. I would like to make this code available for integration into the jasper scheme but I will need to rename the packaging to something acceptable. As I mentioned before, the whole thing is implemented as an extension to Jasper, not a rewrite. Implementation should be as simple as re-registering the server to send *.jsp files to the JspServlet class in my extended package. A simplest option would to simply put the seven classes involved into a separate package like "org.apache.jasper.jspx". I've tested this thoroughly using the WebLogicServer as the servlet engine (bypassing their JSP compiler) and also New Atlanta's ServletExecDebugger. I am still setting up using the Tomcat Servlet Engine to try and test it there. I am having some unrelated difficulties there and will make a separate post on that. I've been working so far by extending the Jasper API as it exists in the tc 3.2.1 release. How mature is the 4.0 build? Should I I welcome queries on this code (I will share snippets in lew of the whole thing for now, if necessary) and suggestions on how to become more involved with the Jasper effort. Like all of you, my time is very tight, but this subject area is very important to my projects so I'd like to be involved as much as possible. Cheers, Dr. Mel Martinez Senior Software Architect G1440, Inc. [EMAIL PROTECTED] --- Glenn Nielsen [EMAIL PROTECTED] wrote: "Craig R. McClanahan" wrote: Glenn Nielsen wrote: "Craig R. McClanahan" wrote: [EMAIL PROTECTED] wrote: When Jasper is run in a servlet container it no longer puts the class files in a package, they are now in the default package. As was discussed earlier on TOMCAT-DEV, this is going to cause portability problems for people who use beans that are not in packages. That's true, but Steve Downey also found the spec reference I couldn't find (in Section 8.2 of the JSP 1.2 Proposed Final Draft). The JSP page class is required to be in a package for 1.2. snip Ok, I'm convinced thanks to Steve and
cvs commit: jakarta-tomcat/src/shell startup2.bat tomcat2.bat
nacho 01/02/06 08:51:52 Modified:src/etc server.xml Removed: src/shell startup2.bat tomcat2.bat Log: Change the server.xml to use the new parentClassloader, by default Revision ChangesPath 1.68 +4 -2 jakarta-tomcat/src/etc/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat/src/etc/server.xml,v retrieving revision 1.67 retrieving revision 1.68 diff -u -r1.67 -r1.68 --- server.xml2001/02/02 04:56:45 1.67 +++ server.xml2001/02/06 16:51:51 1.68 @@ -36,7 +36,7 @@ className="org.apache.tomcat.modules.loggers.LogEvents" -- -ContextInterceptor +ContextInterceptor className="org.apache.tomcat.modules.config.ContextXmlReader" / ContextInterceptor @@ -57,8 +57,10 @@ ContextInterceptor className="org.apache.tomcat.modules.config.PolicyLoader" / +!-- Classloader interceptor -- ContextInterceptor -className="org.apache.tomcat.modules.config.LoaderInterceptor11" / +className="org.apache.tomcat.modules.config.LoaderInterceptor11" +useApplicationLoader="true" / ContextInterceptor className="org.apache.tomcat.modules.generators.ErrorHandler" / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Tomcat 4] Session Handling Enhancements
Kief Morris wrote: Craig R. McClanahan typed the following on 04:40 PM 2/5/2001 -0800 (1) Session Save/Restore Across App Restarts Currently, StandardManager saves and restores sessions across app restarts (i.e. autoreload if turned on, or normal shutdown and startup). It should be modified to use the new passivate() and activate() methods of the session implementation to warn interested session attributes that this activity is taking place. -0 How about stripping this entirely out of StandardManager? People who want to keep sessions over restarts can use PersistentManager, leaving StandardManager as a slimmer, simpler default. Well, StandardManager already supports saving and restoring sessions across restarts -- it just doesn't do the event notifications right. (2) Modify StandardSession.readObject() and writeObject() Currently, when the session is being serialized, the attributes are removed via removeAttribute() -- which triggers calls to valueUnbound() of attributes that implement HttpSessionBindingListener, among other things. Likewise, when the session is reloaded in readObject, setAttribute() is called and triggers calls to valueBound(). These calls were initially made to give session attributes some knowledge that a restart was being done. Now that the activate and passivate mechanisms are in place, I propose that these mechanisms be changed to *not* unbind and bind the attributes during these processes. Any interested attribute can implement HttpSessionAttributeListener instead. You mean HttpSessionActivationListener? If so I'm +1 on this - I can make this change. (3) Change "final" classes One of the challenges Kief ran into is that StandardManager and StandardSession are both marked final, and therefore cannot be subclassed. I propose to remove the "final" modifier so that this restriction is no longer in place. Additional refactoring can be performed separately, but you should at least be able to subclass these classes. +1 - I can do this also. I've actually got a commit ready to go on all of these, plus an extended unit test to prove that it fires all the right events at the right time. I'll go ahead and check it in. What do you think about pushing more functionality up into ManagerBase, Either that, or subclass StandardManager instead if it makes life easier. and creating a SessionBase class? Sounds good as well. Most of what I want to do shouldn't need subclassing of StandardManager/Session. Some of the places where we're casting to StandardSession seem to imply that these methods should really be in the Session interface itself. I was particularly thinking about the new activate() and passivate() methods, which every session implementation should be ready to implement. There are probably others as well. Kief Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
java.lang.NoClassDefFoundError in UNIX
Hi, I am running Tomcat 3.2.1 on jdk 1.3.0 on RedHat 7.0. When i try to run Tomcat by doing ./tomcat.sh start, i would get a "Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tomcat/shell/Startup. I have Ant, ServletApi, Java Api, JSSE installed already. Could anyone help me on this. Thks in advance. Calvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[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? Craig McClanahan - 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. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml
craigmcc01/02/06 09:16:28
Modified:tester/src/bin tester.xml
tester/src/tester/org/apache/tester Session03.java
SessionBean.java
tester/web/WEB-INF web.xml
Added: tester/src/tester/org/apache/tester Include02.java
Include02a.java
Log:
Enhance the session management test to validate that the appropriate
lifecycle events have been called at the correct times across an application
shutdown and restart.
Add a unit test for the corrected handling of exceptions thrown by
an included or forwarded-to servlet.
Revision ChangesPath
1.14 +26 -0 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- tester.xml2001/02/04 05:34:18 1.13
+++ tester.xml2001/02/06 17:16:21 1.14
@@ -115,6 +115,32 @@
request="${context.path}/WrappedInclude01"
outContent="Include01 PASSED"/
+!-- == Included Servlet Throwing Exceptions == --
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/Include02?exception=IOException"
+ outContent="Include02 PASSED"/
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/Include02?exception=ServletException"
+ outContent="Include02 PASSED"/
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/Include02?exception=NullPointerException"
+ outContent="Include02 PASSED"/
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/WrappedInclude02?exception=IOException"
+ outContent="Include02 PASSED"/
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/WrappedInclude02?exception=ServletException"
+ outContent="Include02 PASSED"/
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/WrappedInclude02?exception=NullPointerException"
+ outContent="Include02 PASSED"/
+
/target
1.2 +18 -6
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Session03.java
Index: Session03.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Session03.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Session03.java2001/02/04 04:49:38 1.1
+++ Session03.java2001/02/06 17:16:24 1.2
@@ -68,7 +68,7 @@
* Then, it removes that attribute and verifies successful removal.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.1 $ $Date: 2001/02/04 04:49:38 $
+ * @version $Revision: 1.2 $ $Date: 2001/02/06 17:16:24 $
*/
public class Session03 extends HttpServlet {
@@ -89,17 +89,19 @@
}
// Ensure that we can retrieve the attribute successfully
+ SessionBean bean = null;
if (ok) {
-Object bean = session.getAttribute("sessionBean");
-if (bean == null) {
+Object object = session.getAttribute("sessionBean");
+if (object == null) {
writer.println("Session03 FAILED - Cannot retrieve attribute");
ok = false;
-} else if (!(bean instanceof SessionBean)) {
+} else if (!(object instanceof SessionBean)) {
writer.println("Session03 FAILED - Attribute instance of " +
- bean.getClass().getName());
+ object.getClass().getName());
ok = false;
} else {
-String value = ((SessionBean) bean).getStringProperty();
+bean = (SessionBean) object;
+String value = bean.getStringProperty();
if (!"Session01".equals(value)) {
writer.println("Session03 FAILED - Property = " + value);
ok = false;
@@ -115,6 +117,16 @@
ok = false;
}
}
+
+ // Validate the bean lifecycle of this bean
+ if (ok) {
+ String lifecycle = bean.getLifecycle();
+ if (!"/vb/swp/sda/vu".equals(lifecycle)) {
+ writer.println("Session03 FAILED - Invalid bean lifecycle '" +
+lifecycle + "'");
+ ok = false;
+ }
+ }
// Report success if everything is still ok
if (ok)
1.2 +75 -2
RE: [VOTE] New Committer: Kief Morris
+1 La prise de conscience de votre propre ignorance est un grand pas vers la connaissance. -- Benjamin Disraeli -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 6:16 PM To: [EMAIL PROTECTED] Subject: [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? 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: [VOTE] New Committer: Kief Morris
+1 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 11:16 AM To: [EMAIL PROTECTED] Subject: [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? 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]
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]
Tomcat Setup and configuration
I realize that this is probably a 'tomcat-user' question, but since my intention is towards dev efforts, I hope no one minds my posting it here. If necessary I'll post it to the users list. I've run into 3 issues described below. Of them, #3 is the most important to me and I really need to get it resolved rapidly. Hopefully in all cases I'm just being an idiot and someone here can nudge me with the obvious answers. :-) I'm having trouble figuring out how to setup Tomcat in the following particular manner: I've installed Tomcat 3.2.1 into /opt/local/tomcat and have set TOMCAT_HOME=/opt/local/tomcat. However I have a need to keep my actual application completely separate from the above installation. (This is not an unusual idea: keep all application-specific data, scripts and configuration independent of the COTS installation). My application is thus, for example, installed in APP_HOME=/opt/demo. I've created a server.xml file for the application and I start tomcat using the option "-f /opt/demo/conf/server.xml". So far so good. Issue#1: The comments in the server.xml file say that by setting the "home" attribute to the ContextManager element, that "...webapps/, work/ and log/tomcat_logs/ will be relative to this...". So I set this attribute to home="/opt/demo". However, because the tc_log, servlet_log and JASPER_log are all defined outside the scope of the ContextManager, I soon find that by default, tomcat still writes it's logs back to TOMCAT_HOME/logs/*. There does not seem to be a single attribute in server.xml that can tell tomcat to route all Logger output to have a different root directory (i.e., I'd prefer to write to APP_HOME/logs/*). So I am forced to edit the 'path' attribute of every Logger element to have an absolute path like so : path="/opt/demo/logs/tomcat.log". Q: Wouldn't it be easier to have a 'home' attribute on the Server element that would be used as the base for all relative paths in nested elements (i.e. Logger, ContextManager, Context, etc.) And even better, wouldn't it be nice to be able to set that at the command-line with a an option? That would make it much easier to reuse server.xml settings across multiple deployments. Basically, I think tomcat needs to have the ability to clearly separate the TOMCAT_HOME installation from the configuration and data for a particular application. Not doing so is kind of like assuming that every user wants to store all his MS Word documents into C:/Program Files/Microsoft/Word/documents/ (or wherever the MS Word application is installed). Issue#2 Having set the ContextManager home="/opt/demo" ... attribute, Tomcat does seem to be finding the work and webapps directories correctly. And it also seems to create certain output, such as the "tomcat-apache.conf" file correctly inside the "/opt/demo/conf/" directory. Q: While there are attributes (workDir, path) for changing the names used for the scratch directory and the location of a webapp context, there seems no way to change the name or location used for the conf/ directory. It is 'fixed' as relative to the home path. Since configuration data is often deployment specific, I would greatly appreciate the ability to direct tomcat to use a particular directory for conf (for example if I need to deploy to both linux and nt I might want to specify APP_HOME/conf/linux/ for one and APP_HOME/conf/nt/ for the other.). If this capability already exists, could someone please explain to me how to invoke it? At any rate, given the above, I am now able to run tomcat and launch, compile and run JSPs using the default jasper JspServlet. I am also able to invoke classes I've included in the CLASSPATH just fine. I still have some issue with referencing classes with the default JasperLoader but I think this is because the ClassPath pulled from the init-params is not set. I'm not to worried about that one. Issue#3: The documentation in the "Tomcat - A Minimalistic User's Guide" says: "Tomcat lets the user define default web.xml values for all context by putting a default web.xml file in the conf directory.". This sounds reasonable, as there needs to be some global registration of such servlets as, for example, the JspServlet. So, I promptly placed a copy of web.xml in my APP_HOME/conf directory and edited it to change the servlet class used for JSPs. I first tried doing this by simply replacing: servlet servlet-name jsp /servlet-name servlet-class org.apache.jasper.runtime.JspServlet /servlet-class /servlet with: servlet servlet-name jsp /servlet-name servlet-class com.my.package.JspServlet /servlet-class /servlet At this point, I would expect that tomcat would send all *.jsp requests to the 'jsp' servlet which should use my class as indicated above for servlet. However, it does not. At this point, I try making a
cvs commit: jakarta-tomcat/src/shell tomcat.bat
nacho 01/02/06 09:58:22 Modified:src/shell tomcat.bat Log: Default startup shell for windows, starts tomcat with new bootstrap Revision ChangesPath 1.34 +11 -61jakarta-tomcat/src/shell/tomcat.bat Index: tomcat.bat === RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.bat,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- tomcat.bat2001/01/11 19:13:18 1.33 +++ tomcat.bat2001/02/06 17:58:21 1.34 @@ -22,7 +22,7 @@ rem rem JAVA_HOMEMust point at your Java Development Kit installation. rem -rem $Id: tomcat.bat,v 1.33 2001/01/11 19:13:18 larryi Exp $ +rem $Id: tomcat.bat,v 1.34 2001/02/06 17:58:21 nacho Exp $ rem - @@ -34,7 +34,7 @@ rem - Internal Environment Vars used somewhere -- -set TEST_JAR=tomcat.jar +set TEST_JAR=lib\tomcat.jar rem - Verify and Set Required Environment Variables - @@ -46,7 +46,7 @@ if not "%TOMCAT_HOME%" == "" goto gotTomcatHome set TOMCAT_HOME=. :gotTomcatHome -if exist "%TOMCAT_HOME%\lib\%TEST_JAR%" goto okTomcatHome +if exist "%TOMCAT_HOME%\%TEST_JAR%" goto okTomcatHome echo Unable to locate %TEST_JAR%, check the value of TOMCAT_HOME. goto cleanup :okTomcatHome @@ -65,64 +65,14 @@ set _STARTJAVA=start "%JAVA_HOME%\bin\java" set _RUNJAVA="%JAVA_HOME%\bin\java" - -rem - Set Up The Runtime Classpath -- - :setClasspath -set CP=%TOMCAT_HOME%\classes -rem Try to determine if TOMCAT_HOME contains spaces -if exist %TOMCAT_HOME%\lib\%TEST_JAR% goto dynClasspath -echo Your TOMCAT_HOME appears to contain spaces. -echo Unable to set CLASSPATH dynamically. -goto staticClasspath - -:dynClasspath -set _LIBJARS= -for %%i in (%TOMCAT_HOME%\lib\*.jar) do call %TOMCAT_HOME%\bin\cpappend.bat %%i -if not "%_LIBJARS%" == "" goto gotLibJars -echo Unable to set CLASSPATH dynamically. -if "%OS%" == "Windows_NT" goto staticClasspath -echo Note: To set the CLASSPATH dynamically on Win9x systems -echo only DOS 8.3 names may be used in TOMCAT_HOME! -goto staticClasspath - -:gotLibJars -echo Including all jars in %TOMCAT_HOME%\lib in your CLASSPATH. -rem Note: _LIBJARS already contains a leading semicolon -set CP=%CP%%_LIBJARS% -goto chkClasspath - -:staticClasspath -echo Setting your CLASSPATH statically. -set CP=%CP%;%TOMCAT_HOME%\lib\ant.jar -set CP=%CP%;%TOMCAT_HOME%\lib\jasper.jar -set CP=%CP%;%TOMCAT_HOME%\lib\jaxp.jar -set CP=%CP%;%TOMCAT_HOME%\lib\parser.jar -set CP=%CP%;%TOMCAT_HOME%\lib\servlet.jar -set CP=%CP%;%TOMCAT_HOME%\lib\tomcat.jar -set CP=%CP%;%TOMCAT_HOME%\lib\tomcat_core.jar -set CP=%CP%;%TOMCAT_HOME%\lib\tomcat_modules.jar -set CP=%CP%;%TOMCAT_HOME%\lib\tomcat_util.jar -set CP=%CP%;%TOMCAT_HOME%\lib\tomcat-startup.jar -set CP=%CP%;%TOMCAT_HOME%\lib\stop-tomcat.jar -set CP=%CP%;%TOMCAT_HOME%\lib\facade22.jar - -:chkClasspath -if "%CLASSPATH%" == "" goto noClasspath -set CP=%CP%;%CLASSPATH% -:noClasspath -if not exist "%JAVA_HOME%\lib\tools.jar" goto installClasspath -set CP=%CP%;%JAVA_HOME%\lib\tools.jar -:installClasspath -echo. -echo Using CLASSPATH: %CP% -echo. -set CLASSPATH=%CP% +set CLASSPATH=%TOMCAT_HOME%\lib\tomcat.jar - rem - Execute The Requested Command - +:execute + if "%1" == "start" goto startServer if "%1" == "stop" goto stopServer if "%1" == "run" goto runServer @@ -147,28 +97,28 @@ :startServer echo Starting Tomcat in new window if "%2" == "-security" goto startSecure -%_STARTJAVA% %TOMCAT_OPTS% -Dtomcat.home="%TOMCAT_HOME%" org.apache.tomcat.startup.Tomcat %2 %3 %4 %5 %6 %7 %8 %9 +%_STARTJAVA% %TOMCAT_OPTS% -Dtomcat.home="%TOMCAT_HOME%" org.apache.tomcat.startup.Main %2 %3 %4 %5 %6 %7 %8 %9 goto cleanup :startSecure echo Starting Tomcat with a SecurityManager -%_SECSTARTJAVA% %TOMCAT_OPTS% -Djava.security.manager -Djava.security.policy=="%TOMCAT_HOME%/conf/tomcat.policy" -Dtomcat.home="%TOMCAT_HOME%" org.apache.tomcat.startup.Tomcat %3 %4 %5 %6 %7 %8 %9 +%_SECSTARTJAVA% %TOMCAT_OPTS% -Djava.security.manager -Djava.security.policy=="%TOMCAT_HOME%/conf/tomcat.policy" -Dtomcat.home="%TOMCAT_HOME%" org.apache.tomcat.startup.Main %3 %4 %5 %6 %7 %8 %9 goto cleanup :runServer rem Running Tomcat in this window if "%2" == "-security" goto runSecure -%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home="%TOMCAT_HOME%" org.apache.tomcat.startup.Tomcat %2 %3 %4 %5 %6 %7 %8 %9 +%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home="%TOMCAT_HOME%" org.apache.tomcat.startup.Main %2 %3 %4 %5 %6 %7 %8 %9 goto cleanup :runSecure rem Running
cvs commit: jakarta-tomcat build.xml
nacho 01/02/06 10:16:00 Modified:.build.xml Log: Build now builds with the new directory structure under lib Revision ChangesPath 1.108 +2 -2 jakarta-tomcat/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat/build.xml,v retrieving revision 1.107 retrieving revision 1.108 diff -u -r1.107 -r1.108 --- build.xml 2001/02/06 02:46:24 1.107 +++ build.xml 2001/02/06 18:15:59 1.108 @@ -448,7 +448,7 @@ /target - target name="all" depends="clean,dist"/ - target name="main" depends="tomcat,webapps,sanity-test"/ + target name="all" depends="clean,dist,dist-new"/ + target name="main" depends="tomcat,webapps,sanity-test,new"/ /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat build.xml
nacho 01/02/06 10:17:55
Modified:.build.xml
Log:
Oops, a circular dependency ..
Revision ChangesPath
1.109 +2 -2 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.108
retrieving revision 1.109
diff -u -r1.108 -r1.109
--- build.xml 2001/02/06 18:15:59 1.108
+++ build.xml 2001/02/06 18:17:55 1.109
@@ -403,7 +403,7 @@
zip zipfile="${Name}-${version}.zip" basedir="${tomcat.dist}" includes="**"/
/target
- target name="dist-new" depends="dist"
+ target name="dist-new"
mkdir dir="${tomcat.dist}/lib/shared"/
mkdir dir="${tomcat.dist}/lib/common"/
copy file ="${tomcat.dist}/lib/servlet.jar"
@@ -414,7 +414,7 @@
todir="${tomcat.dist}/lib/shared" /
/target
- target name="new" depends="main"
+ target name="new"
mkdir dir="${tomcat.build}/lib/shared"/
mkdir dir="${tomcat.build}/lib/common"/
copy file ="${tomcat.build}/lib/servlet.jar"
-
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: [VOTE] New Committer: Kief Morris
Craig R. McClanahan [EMAIL PROTECTED] wrote: 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 -- Pier Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] New Committer: Kief Morris
+1 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 12:16 PM To: [EMAIL PROTECTED] Subject: [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? 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: Tomcat Setup and configuration
Costin - Thanks a ton for your reply. Very helpful.
--- [EMAIL PROTECTED] wrote:
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".
This sound great. I am a big proponent of explicit
configuration (with implicit defaults, of course).
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.
Shouldn't they be by default set relative to the
application home? I.E. if we have one install of
tomcat on the system, (TOMCAT_HOME =
/opt/local/tomcat) and we have two different
applications on the box (using, perhaps different
ports) with different server.xml files and
ContextManager 'home' attributes), the log output
should be consider 'of the application' in each case
and should be implicitely written to paths relative to
the application 'home', not into TOMCAT_HOME. This
is simple OO partitioning of responsibilities.
If nobody objects to the config changes I'll also
add the ant-style syntax
for ${properties}, so you'll have more flexibility.
No objection. Sounds like a good idea. The
${property} syntax is consistent with the Security
Manager policy file format as well. I've implemented
it in my own application's configuration file scheme.
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
into the DOM). Having built this sort of thing
before, I realize this not trivial (recursion,
protocol for conflict resolution, etc.) but the value
is high.
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 )
Is this available in the current 3.3 milestone or
nightly builds?
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.
That sounds great. At least I now know what is (not)
going on! :-)
Q1: Why does it say in the documentation that
conf/web.xml is used as a default? Needs to be
corrected.
Q2: More importantly, I'm still left with: How do I
configure the use of a different servlet to handle
*.jsp requests?
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.
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?
Thanks again for your help.
Mel
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
signals with JNI
Hi,
I have a problem under Linux loading the JVM since before I set a Handler to
catch SIGSEGV signals. It seems that this causes some troubles when the JVM
is loaded. This seems due to threads in Java. I saw several post from
yourself about this topic.
I include my C test file (called x.c) and the command-line
to compile it is:
gcc -o x /usr/java/jdk1.3/jre/lib/i386/client/libjvm.so x.c
-I/usr/java/jdk1.3/include -I/usr/java/jdk1.3/include/linux -g -Wall
(assuming the JDK is installed in /usr/java/jdk1.3)
Here is the C file
#include stdio.h
#include stdlib.h
#include signal.h
#include jni.h
JNIEnv *env;
JavaVM *vm;
jclass cls;
void
Load_JVM(void)
{
JavaVMOption options[2];
JavaVMInitArgs vm_args;
options[0].optionString = "-Djava.class.path=."; /* user classes */
vm_args.version = JNI_VERSION_1_2;
vm_args.options = options;
vm_args.nOptions = 1;
vm_args.ignoreUnrecognized = 1;
printf("READY TO LOAD THE JVM\n");
if (JNI_CreateJavaVM(vm, (void **)env, (void *)vm_args) 0)
{
fprintf(stderr, "cannot load the JVM\n");
exit(1);
}
printf("JVM LOADED\n");
}
void
SIGSEGV_Handler(void)
{
fprintf(stderr, "Received SIGSEGV\n");
exit(2);
}
int
main(int argc, char *argv[])
{
signal(SIGSEGV, (void (*)()) SIGSEGV_Handler);
Load_JVM();
return 0;
}
It simply installs a handler for SIGSEGV and then loads the JVM. If you
comment the line signal(SIGSEGV, (void (*)()) SIGSEGV_Handler) in the main(),
this works properly but with the handler this crashes with:
READY TO LOAD THE JVM
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 4F533F4C494E55580E4350500570
#
# Problematic Thread: Received SIGSEGV
Another strange problem occurs if you replace this line by
system("uname -a");
after executing system() the JVM loading is blocked (in a sigsuspend I think).
Could you help me on this please ?
--
===
Daniel Diaz
University of Paris 1 INRIA Rocquencourt
75013 Paris FRANCE 78153 Le Chesnay FRANCE
web: http://pauillac.inria.fr/~diaz
email: [EMAIL PROTECTED]
===
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] New Committer: Kief Morris
+1 -- Pierre -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 12:16 PM To: [EMAIL PROTECTED] Subject: [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? 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] New Committer: Kief Morris
Craig R. McClanahan typed the following on 09:16 AM 2/6/2001 -0800 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? Thanks for the support everyone, I'm glad to be involved with this project. Kief - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] New Committer: Kief Morris
+1 Saludos , Ignacio J. Ortega -Mensaje original- De: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Enviado el: martes 6 de febrero de 2001 18:16 Para: [EMAIL PROTECTED] Asunto: [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? 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]
Common Session code 3.3/4.0 (was: [VOTE] New Committer: Kief Morris)
[EMAIL PROTECTED] typed the following on 09:44 AM 2/6/2001 -0800 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 :-) Sure, the 3.3 code could be modified to use the Store interfaces to serialize its sessions, although that would require sharing the Session interface. Maybe a bit too much work for the current release cycle. Kief - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Updating the Jakarta Website
I just checked out a copy of the website and updated one of the pages (added my info to "Who We Are"), but, when I tried to check it back in, I got the following: Access denied: Insufficient Karma (danmil|jakarta-site2/docs/site) cvs server: Pre-commit check failed Access denied: Insufficient Karma (danmil|jakarta-site2/xdocs/site) cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! What gives? -Dan p.s. In case you're wondering, I *did* follow the instructions in the various docs (edited whoweare.xml, built whoweare.html). -- Dan Milstein // [EMAIL PROTECTED] - 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]
Re: signals with JNI
Hi, I have a problem under Linux loading the JVM since before I set a Handler to catch SIGSEGV signals. It seems that this causes some troubles when the JVM is loaded. This seems due to threads in Java. I saw several post from yourself about this topic. Long ago... Did you tried with a different VM ? It simply installs a handler for SIGSEGV and then loads the JVM. If you comment the line signal(SIGSEGV, (void (*)()) SIGSEGV_Handler) in the main(), this works properly but with the handler this crashes with: READY TO LOAD THE JVM # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Error ID: 4F533F4C494E55580E4350500570 # # Problematic Thread: Received SIGSEGV I guess you should do exactly that ( after you try with a different VM and works as you expect :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common Session code 3.3/4.0 (was: [VOTE] New Committer: Kief Morris)
( +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 :-) Sure, the 3.3 code could be modified to use the Store interfaces to serialize its sessions, although that would require sharing the Session interface. Maybe a bit too much work for the current release cycle. This doesn't have to be part of tomcat3.3 release - it can be a standalone module. The only issue is that the code you write ( Store, impls, etc ) need to be "standalone" - i.e. be usable in any container. ( the session manager for tomcat3.2 is based on early catalina session managers, but it was a huge pain to extract the session management and use it, since it depended on a lot of internals - Request, Lifecycle, etc). With the same functionality, you can organize the code in many ways. If you look at tomcat.util you'll find that none of the tools there depends in any way on any tomcat internal object. If the store can be written as a general-purpose utility, and you keep container-dependent code in a small adapter then more people will be able to use it or contribute to it. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat Setup and configuration
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 :-) Erggg, hummm, i did from code of Alex Chafee, it was inadvertly slipped in a commit many time ago ( about August or Sept ) , but it's truly useful :) so it's there .. and it's very tested a least for me :).. Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
--- [EMAIL PROTECTED] wrote: 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. Where is this stuff documented? There doesn't seem to be a DTD for server.xml. 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 ). so you seem to be saying that one would set InstallDir - TOMCAT_HOME and home - APP_HOME. I'll test that out. By using explicit paths we can accomodate more use cases and be very clear about what goes where. yup. Down the road an include mechanism would be a good No need, it's already done ( and in 3.2 too ). Luv it. Thanks for pointing that out. One of the goals for 3.3 release is to have all those small things that makes configuration easy ( as usability enhancements ). These issues directly affect configuration management and are critical for managing complex deployments. I don't think enough people take this area seriously enough (code features now, worry about deployment later!). 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. Why exactly would it be 'much' slower? Does that presume that a custom JspServlet would be inherently slower or that the default org.apache.jasper.runtime.JspServlet is somehow accellerated by something JspInterceptor does? Hypothetical: If I were to modify org.apache.jasper.runtime.JspServlet (or make a replacement and pre-load it in the CLASSPATH) would that be 'much slower' (even though it should not require setting the 'useJspServlet' tag since it would appear to be the regular default class)? Just curious about your statement. 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. This may be suitable for some situations, but I have other situations where I need to have complete control over what JSP compiler is used by the servlet engine. This sort of configuration (specifying what servlet to route a request to) is easy with JServ, WebLogic Server and other servlet engines. I'm not sure why it shouldn't be just as simple on Tomcat. Especially since fundamentally Jasper is a standalone servlet package that runs fine on other servlet engines than Tomcat. One should be able to plug-in a different JSP processing servlet (or any default servlet) with no more work than changing a line in a configuration file. It sounds like 3.3 brings this ease in the JspInterceptor. I'm pretty intimate with the Jasper API, but still learning the Tomcat API. I'm still working on understanding how the Connector and Interceptor patterns are implemented. Thanks again for the help. Cheers, mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common Session code 3.3/4.0 (was: [VOTE] New Committer: Kief Morris)
you look at tomcat.util you'll find that none of the tools there depends in any way on any tomcat internal object. If the store can be written as a general-purpose utility, and you keep container-dependent code in a small adapter then more people will be able to use it or contribute to it. Is 3.3 ready to give up on JDK 1.1 compatibility? If not, the extra effort to maintain it is not particularly "productive" from a Tomcat 4 point of view. That's a very common misconceptions about JDK1.1 compatibility - it doesn't imply in any way that tomcat3.3 can't use JDK1.2 features. Tomcat 3.3 is using a number of 1.2 features ( context class loader, doPriviledged, URLClassLoader, etc ) - the _core_ and the _required_ modules are strictly JDK1.1. In other words: - tomcat3.3 compiles with JDK1.1 ( since all modules depending on 1.2 are compiled only if 1.2 is detected. Same for JSSE ). - tomcat3.3 should run fine with JDK1.1 and work as a normal servlet container - it doesn't have to provide all the functionality that would be available in JDK1.2 - for example it'll not be capable of sandboxing or set the context class loader or URLClassLoader. Advanced session management is just a module ( and BTW, I wouldn't vote for including it in tomcat3.3 in any way) that can be used as an add-on. It doesn't affect the default session manager ( which is JDK1.1 compatible). Also, a small note regarding the code organization and reusability. Of course, the session manager needs to send the right events and read data from the server. But that can be easily abstracted and most functionality made re-usable. Many people talk about OO and reusing - but the reality is that very little happens, and the main reason ( IMHO ) is that in many cases a lot of dependencies exists. The end result of this can be tomcat3.0. ( for example the session manager can use a Bean-style API, with Listerners for all generated events and setters for all the properties it needs. Instead of pulling data from the container, an adapter can push the needed data and generate the right servlet events using the session manager listeners. IMHO it would be a mistake to write a session manager using the same abstractions as in a servlet container - after all the task is to store data and the requirements are pretty specific ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
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. Where is this stuff documented? There doesn't seem to be a DTD for server.xml. It's still on the TODO list, but it'll happen only after we add the ant style config directives ( since that will allow us to define all the attributes for JspInterceptor, and different attributes for StaticInterceptor - each module has it's own properties ). ( same problems as in ant - user modules can't be coded in the dtd ). BTW, there is already code checked in that will read all the .java code, and for all classes that extends BaseInterceptor it'll extract the comments for the setters and generate a xml file. The .dtd generation can be easily automated ( the goal is mostly to generate user documentation for modules that is in sync with the real code ) so you seem to be saying that one would set InstallDir - TOMCAT_HOME and home - APP_HOME. I'll test that out. Confusing, isn't it :-) ? ( it's easy for me to criticize that - I wrote a lot of this code, so I'm not at risk to offend anyone else :-) These issues directly affect configuration management and are critical for managing complex deployments. I don't think enough people take this area seriously enough (code features now, worry about deployment later!). IMHO the biggest problem is that people deploying tomcat are not providing enough feedback and are not contributing back code or documentation. Yes, we had requests for this kind of configuration ( with separate install and user dir ), and the intial code has been written way ago. I tried to do it as good as I could - but I can't guess what's easy and what isn't from a deployment perspective. Why exactly would it be 'much' slower? Does that presume that a custom JspServlet would be inherently slower or that the default org.apache.jasper.runtime.JspServlet is somehow accellerated by something JspInterceptor does? No, the overhead of using a servlet to invoke the jsp page is significant ( at least in my tests is shows a big difference ). JspInterceptor does a simple thing - after the jsp page is compiled to a servlet, the servlet will be "registered" to tomcat ( as if it was declared in web.xml ) and after that all invocations to the jsp page are identical with invocations for servlets ( with one exception - jsp_precompile param must be read on each request and if present, the request shouldn't be executed - that's the spec ). ( reloading is also done in the same way, using DependManager ). replacement and pre-load it in the CLASSPATH) would that be 'much slower' (even though it should not require setting the 'useJspServlet' tag since it would appear to be the regular default class)? Just curious about your statement. Try it yourself, send back the results :-) ( ab -n 1 -c 80 http://localhost:8080/foo.jsp with JspInterceptor in both modes ). ( useJspServlet means JspInterceptor will do nothing, just return ). ( of course, you can compare 3.3 with JspInterceptor with 3.2.1 without it - but there are other factors in that) ( as developer I do this kind of tests quite often to track if the changes are affecting the performance, and everyone should do it once in a while ) processing servlet (or any default servlet) with no more work than changing a line in a configuration file. It sounds like 3.3 brings this ease in the JspInterceptor. Well, it is possible in 3.2 also, but you need a special module that will set the jsp implementation. It's not hard to do, but it's not there by default. ( I sent to the list one that changed jasper settings, you just need to add few lines to change jasper with a different one). The module will do nothing else, just alter some settings - you add it to server.xml. I'm pretty intimate with the Jasper API, but still learning the Tomcat API. I'm still working on understanding how the Connector and Interceptor patterns are implemented. A good news - in 3.3 there is no Connector API :-) ( the Connector is just a regular module ) ( well, we are still far away from the rafinaments in Apache 2.0 where even the threads are managed by a plugable module - but the model for modularization is close ) -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common Session code 3.3/4.0 (was: [VOTE] New Committer: Kief Morris)
--- [EMAIL PROTECTED] wrote: IMHO it would be a mistake to write a session manager using the same abstractions as in a servlet container - after all the task is to store data and the requirements are pretty specific ) I'd like to poke my $.02 in and say I totally agree with Costin. The only 'connection' required between the servlet container apis and persistent session management is state maintenance, which can be encapsulated in some sort of session identifier (i.e. cookie typically) which can be built independent of the actual container by using the standard servlet APIs (v 2.2 is sufficient). Other than that, the actual implementation of a persistant session managment API does not have to have anything to do with the servlet container or even the servlet API. I have built such a beast and it is, as Costin advocates, independent of servlet container. It is proprietary, so I can't give it to the project, but the basic principal is simple: 1 - Use the standard servlet API's to establish a 'session identifier' (cookies work fine for 90% of the browser world out there). 2 - use this as a key into your persistant session store. Naturally, there are some other details involving assertaining the 'active' or inactive state of the session, time out of session ids,authentication controls, etc., but even all that does not have to depend on the servlet container. You should come up with a scheme that is pluggable as to where the actual data is stored (i.e. disk files vs (shared) RDBMS vs whatever). Just my $.02. Mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
--- [EMAIL PROTECTED] wrote: No, the overhead of using a servlet to invoke the jsp page is significant ( at least in my tests is shows a big difference ). JspInterceptor does a simple thing - after the jsp page is compiled to a servlet, the servlet will be "registered" to tomcat ( as if it was declared in web.xml ) and after that all invocations to the jsp page are identical with invocations for servlets ( with one exception - jsp_precompile param must be read on each request and if present, the request shouldn't be executed - that's the spec ). This almost implies some special behavior on the part of the base HttpJspPage class (i.e. 'JspBase') used to build the jsp servlet. Is that so? Is there any problem for jsp pages that use the %@page extends=... tag that don't extend org.apache.jasper.runtime.JspBase but rather instead (as per spec) simply implement javax.servlet.jsp.HttpJspPage? One of the things that really gripes me about the WebLogic JSP servlet engine and JSP compiler is that it has dependencies on the proprietary base class used to generate JSP servlets. There are a lot of problems with this so I hope that we don't send tomcat/jasper down that road. Try it yourself, send back the results :-) ( ab -n 1 -c 80 http://localhost:8080/foo.jsp with JspInterceptor in both modes ). ( useJspServlet means JspInterceptor will do nothing, just return ). ( of course, you can compare 3.3 with JspInterceptor with 3.2.1 without it - but there are other factors in that) It looks like I'll need to get the 3.3 version to try this out! :-) Thanks again, Costin. mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 233] New - When using XML with IE retreiving XSL using GET appends the POST params BugRat Report#370
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=233 *** shadow/233 Tue Feb 6 16:54:22 2001 --- shadow/233.tmp.24101Tue Feb 6 16:54:22 2001 *** *** 0 --- 1,22 + ++ + | When using XML with IE retreiving XSL using GET appends the POST params Bu | + ++ + |Bug #: 233 Product: Tomcat 4| + | Status: UNCONFIRMED Version: Nightly Build | + | Resolution:Platform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Catalina| + ++ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + Using IE to render XML with a xsl stylesheet, the trip to retrieve the stylesshet +using the GET method results in the query from the post to be appnded. Sample code +is included. Following is from the log file: + Notice in the log below, the post param from the initial request are included in the +GET + + localhost - - [10/Nov/2000:15:51:48 -0800] "GET /local/input.html HTTP/1.1" 200 350 + localhost - - [10/Nov/2000:15:51:51 -0800] "POST /local/demoservlet HTTP/1.1" 200 357 + localhost - - [10/Nov/2000:15:51:51 -0800] "data=cvsfffGET /local/demo.xsl HTTP/1.1" +501 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 391] New - stalled processors BugRat Report#685
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=391 *** shadow/391 Tue Feb 6 16:52:59 2001 --- shadow/391.tmp.24090Tue Feb 6 16:52:59 2001 *** *** 0 --- 1,31 + ++ + | stalled processors BugRat Report#685 | + ++ + |Bug #: 391 Product: Tomcat 4| + | Status: UNCONFIRMED Version: 4.0 Beta 1 | + | Resolution:Platform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Catalina| + ++ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + After running for some time tomcat can't process any more request because all +processors are used. + + I think the problem occurs when in every thread occured a SocketException in +HttpProcessor.parse. + + 2001-01-02 12:36:01 HttpProcessor[80][13] process.parse + java.net.SocketException: Connection reset by peer: Connection reset by peer + at java.net.SocketInputStream.socketRead(Native Method) + at java.net.SocketInputStream.read(SocketInputStream.java:86) + at java.io.BufferedInputStream.fill(BufferedInputStream.java:186) + at java.io.BufferedInputStream.read(BufferedInputStream.java:204) + at +org.apache.catalina.connector.http.SocketInputStream.readRequestLine(SocketInputStream.java:168) + at +org.apache.catalina.connector.http.HttpProcessor.parseRequest(HttpProcessor.java:635) + at +org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:779) + at +org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:890) + at java.lang.Thread.run(Thread.java:484) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
TDK and 4.0 or 4.1
Hi, I'm putting together the next version of the Turbine Development Kit and I was wondering what repository I should be using: the 4.0 or 4.1 repository. I don't want to debug something I don't have to :-) jvz. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TDK and 4.0 or 4.1
Hi, I'm putting together the next version of the Turbine Development Kit and I was wondering what repository I should be using: the 4.0 or 4.1 repository. I don't want to debug something I don't have to :-) 4.0. 4.1 is a development branch which is temporarily abandoned. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java
craigmcc01/02/06 17:08:59
Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
Log:
Correct the loop control for the reversed test variation.
Submitted by: John Li [EMAIL PROTECTED]
PR: 401
Revision ChangesPath
1.3 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java
Index: StandardServer.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- StandardServer.java 2000/09/30 19:15:45 1.2
+++ StandardServer.java 2001/02/07 01:08:58 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
1.2 2000/09/30 19:15:45 craigmcc Exp $
- * $Revision: 1.2 $
- * $Date: 2000/09/30 19:15:45 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
1.3 2001/02/07 01:08:58 craigmcc Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/02/07 01:08:58 $
*
*
*
@@ -86,7 +86,7 @@
* (but not required) when deploying and starting Catalina.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.2 $ $Date: 2000/09/30 19:15:45 $
+ * @version $Revision: 1.3 $ $Date: 2001/02/07 01:08:58 $
*/
public final class StandardServer
@@ -390,7 +390,7 @@
return (true);
// Compare the reversed form of the two addresses
- for (int i = 0; serverAddr.length 4; i++) {
+ for (int i = 0; i serverAddr.length; i++) {
if (serverAddr[i] != clientAddr[(serverAddr.length-1)-i])
return (false);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: TDK and 4.0 or 4.1
On Tue, 6 Feb 2001, Remy Maucherat wrote: Hi, I'm putting together the next version of the Turbine Development Kit and I was wondering what repository I should be using: the 4.0 or 4.1 repository. I don't want to debug something I don't have to :-) 4.0. 4.1 is a development branch which is temporarily abandoned. Thanks, much appreciated. jvz. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 428] New - JSP tags names must be valid variable names BugRat Report#738
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=428 *** shadow/428 Tue Feb 6 17:17:49 2001 --- shadow/428.tmp.24145Tue Feb 6 17:17:49 2001 *** *** 0 --- 1,26 + ++ + | JSP tags names must be valid variable names BugRat Report#738 | + ++ + |Bug #: 428 Product: Tomcat 4| + | Status: UNCONFIRMED Version: 4.0 Beta 1 | + | Resolution:Platform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Jasper | + ++ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + On Tomcat 4.0b1 it appears that tag names must be valid Java variable names. + So a tag cannot be named like: + mytags:set-counter1/mytags:set-counter + + Exception reported: + org.apache.jasper.JasperException: Unable to compile class for +JSP..\work\localhost\lh-app\_0002fToc_0002ejspToc_jsp_0.java:126: + Invalid expression statement. + _jspx_th_get-folder-attribute_0.setPageContext(pageContext); + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet JspServlet.java
remm01/02/06 17:38:28
Modified:jasper/src/share/org/apache/jasper/servlet JspServlet.java
Log:
- Fix for bug 531 : normalize the path (and use File.toURL() to make sure
the URL is valid).
Revision ChangesPath
1.11 +64 -3
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet/JspServlet.java
Index: JspServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet/JspServlet.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JspServlet.java 2001/02/04 01:07:51 1.10
+++ JspServlet.java 2001/02/07 01:38:27 1.11
@@ -517,8 +517,9 @@
if((jsw.servletClass == null) || outDated) {
try {
URL [] urls = new URL[1];
- urls[0] = new URL("file:" + ctxt.getOutputDir());
- jsw.loader = new JasperLoader(urls,ctxt.getServletClassName(),
+File outputDir = new File(normalize(ctxt.getOutputDir()));
+urls[0] = outputDir.toURL();
+jsw.loader = new JasperLoader(urls,ctxt.getServletClassName(),
parentClassLoader,permissionCollection);
jsw.servletClass = jsw.loader.loadClass(ctxt.getServletClassName());
} catch (ClassNotFoundException cex) {
@@ -534,7 +535,8 @@
return outDated;
}
-/**
+
+/**
* Determines whether the current JSP class is older than the JSP file
* from whence it came
*/
@@ -554,5 +556,64 @@
return outDated;
}
+
+
+/**
+ * Return a context-relative path, beginning with a "/", that represents
+ * the canonical version of the specified path after ".." and "." elements
+ * are resolved out. If the specified path attempts to go outside the
+ * boundaries of the current context (i.e. too many ".." path elements
+ * are present), return codenull/code instead.
+ *
+ * @param path Path to be normalized
+ */
+protected String normalize(String path) {
+
+if (path == null)
+return null;
+
+String normalized = path;
+
+ // Normalize the slashes and add leading slash if necessary
+ if (normalized.indexOf('\\') = 0)
+ normalized = normalized.replace('\\', '/');
+ if (!normalized.startsWith("/"))
+ normalized = "/" + normalized;
+
+ // Resolve occurrences of "//" in the normalized path
+ while (true) {
+ int index = normalized.indexOf("//");
+ if (index 0)
+ break;
+ normalized = normalized.substring(0, index) +
+ normalized.substring(index + 1);
+ }
+
+ // Resolve occurrences of "/./" in the normalized path
+ while (true) {
+ int index = normalized.indexOf("/./");
+ if (index 0)
+ break;
+ normalized = normalized.substring(0, index) +
+ normalized.substring(index + 2);
+ }
+
+ // Resolve occurrences of "/../" in the normalized path
+ while (true) {
+ int index = normalized.indexOf("/../");
+ if (index 0)
+ break;
+ if (index == 0)
+ return (null); // Trying to go outside our context
+ int index2 = normalized.lastIndexOf('/', index - 1);
+ normalized = normalized.substring(0, index2) +
+ normalized.substring(index + 3);
+ }
+
+ // Return the normalized path that we have completed
+ return (normalized);
+
+}
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
[Bug 453] New - Errors in jsp:include jsp file with flush=true are not displayed in Internet Explorer BugRat Report#775
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=453 *** shadow/453 Tue Feb 6 18:26:14 2001 --- shadow/453.tmp.25070Tue Feb 6 18:26:14 2001 *** *** 0 --- 1,116 + ++ + | Errors in jsp:include jsp file with flush="true" are not displayed in Inte | + ++ + |Bug #: 453 Product: Tomcat 4| + | Status: UNCONFIRMED Version: Unknown | + | Resolution:Platform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Jasper | + ++ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + If there is an error in a jsp file that was included with the jsp:include tag and +flush is set to true, Internet Explorer (5.5) does not display the error and +sometimes gets stuck in a loop loading the page over and over again until the +operation is manually stopped. The follow example causes this to happen: + + test1.jsp: + html + body bgcolor="#FF" + jsp:include page="test2.jsp" flush="true" / + /body + /html + + test2.jsp: + % + bad syntax + % + + + The Tomcat Exception Report generated by this error displays correctly in IE if +flush is set to false and displays correctly in Netscape regardless of the value of +flush. + + I have used the RequestDumperValve to show the requests going back and forth between +IE and Tomcat. While I am not certain this is related, the content length of Tomcat's +response is -1, even though some data should have been returned (the error message). +The RequestDumperValve excerpt is here: + + 2001-01-15 21:46:53 RequestDumperValve[Standalone]: +=== + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: REQUEST URI =/test.jsp + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: authType=null + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: characterEncoding=ISO-8859-1 + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: contentLength=-1 + 2001-01-15 21:46:58 RequestDumperValve[Standalone]:contentType=null + 2001-01-15 21:46:58 RequestDumperValve[Standalone]:contextPath= + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: +cookie=JSESSIONID=27F243C53725B2F3E25410108860A1E4 + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: +header=accept=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, +application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, +application/pdf, */* + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: +header=accept-language=en-us + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: +header=accept-encoding=gzip, deflate + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: +header=user-agent=Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: +header=host=copernicus:8080 + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: +header=connection=Keep-Alive + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: +header=cookie=JSESSIONID=27F243C53725B2F3E25410108860A1E4 + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: locale=en_US + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: method=GET + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: pathInfo=null + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: protocol=HTTP/1.1 + 2001-01-15 21:46:58 RequestDumperValve[Standalone]:queryString=null + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: remoteAddr=10.134.3.250 + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: remoteHost=copernicus + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: remoteUser=null + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: +requestedSessionId=27F243C53725B2F3E25410108860A1E4 + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: scheme=http + 2001-01-15 21:46:58 RequestDumperValve[Standalone]: serverName=copernicus + 2001-01-15 21:46:58
[Bug 452] New - Using jsp:include with an html and flush=true generates exception BugRat Report#773
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=452 *** shadow/452 Tue Feb 6 18:25:34 2001 --- shadow/452.tmp.25065Tue Feb 6 18:25:34 2001 *** *** 0 --- 1,90 + ++ + | Using jsp:include with an html and flush="true" generates exception BugRat | + ++ + |Bug #: 452 Product: Tomcat 4| + | Status: UNCONFIRMED Version: Unknown | + | Resolution:Platform: All | + | Severity: Normal OS/Version: All | + | Priority: High Component: Jasper | + ++ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + When using the jsp:include tag to include an html file and setting the flush option +to true, Tomcat generates the following exception: + + A Servlet Exception Has Occurred + + Exception Report: + + javax.servlet.ServletException: Servlet.service() for servlet default threw exception + at +org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:593) + at +org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:483) + at +org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:388) + at +org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:430) + at +_0002ftest_0002ejsptest_jsp_6._jspService(_0002ftest_0002ejsptest_jsp_6.java:56) + at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) + at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) + at +org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:184) + at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:328) + at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:407) + at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) + at +org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) + at +org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:251) + at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) + at +org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196) + at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) + at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041) + at +org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) + at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) + at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414) + at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) + at +org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159) + at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) + at +org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:215) + at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) + at +org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818) + at +org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:897) + at java.lang.Thread.run(Thread.java:484) + + Root Cause: + + java.lang.IllegalStateException: Buffer size cannot be changed after data has been +written + at +org.apache.catalina.connector.ResponseBase.setBufferSize(ResponseBase.java:746) + at +javax.servlet.ServletResponseWrapper.setBufferSize(ServletResponseWrapper.java:172) + at +javax.servlet.ServletResponseWrapper.setBufferSize(ServletResponseWrapper.java:172) + at +org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1459) + at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:433) + at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) + at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) +
[Bug 487] Changed - JSPC Empty stack exeption BugRat Report#818
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=487 *** shadow/487 Tue Jan 30 08:00:28 2001 --- shadow/487.tmp.25081Tue Feb 6 18:28:52 2001 *** *** 2,13 | JSPC Empty stack exeption BugRat Report#818| ++ |Bug #: 487 Product: Tomcat 4| ! | Status: NEW Version: 4.0 Beta 1 | | Resolution:Platform: All | | Severity: Normal OS/Version: All | | Priority: High Component: Jasper | ++ ! | Assigned To: BugRatImport | | Reported By: [EMAIL PROTECTED] | | CC list: Cc: | ++ --- 2,13 | JSPC Empty stack exeption BugRat Report#818| ++ |Bug #: 487 Product: Tomcat 4| ! | Status: UNCONFIRMED Version: 4.0 Beta 1 | | Resolution:Platform: All | | Severity: Normal OS/Version: All | | Priority: High Component: Jasper | ++ ! | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED] | | CC list: Cc: | ++ - 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
Mel Martinez wrote: The package naming solution I've opt'ed for in my own enhancement to Jasper (which I'll gladly share) is to derive package names that are related to the location of the jsp relative to the server context. This is simple, flexible and should avoid collisions. There is no need for all this complexity to generate a package name in the new Jasper. The way jasper now loads jsp pages, each page is completely isolated from all other pages. Every jsp page compiled could be a class named "org.apache.jsp.MyJSP" without any concern whatsoever about conflicts because each individual page has its own class loader. I will modify the current jasper class loader to support putting the jsp pages in a package, but this is just to comply with the JSP 1.2 spec. All of the previous code in jasper to do all the package and class name mangling was to overcome the limitations of how the Jasper class loader for jsp pages was designed. 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. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - 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
--- Glenn Nielsen [EMAIL PROTECTED] wrote: There is no need for all this complexity to generate a package name in the new Jasper. Hmmm... compared to the gobbledy-gook that was being done before, I'd hardly call what I did complex. Aside from options, all it does is very simply asign the JSP page a package name based on it's directory hierarchy and place the .java and .class files in same - this is consistant with strict java naming convention. The way jasper now loads jsp pages, each page is completely isolated from all other pages. Every jsp page compiled could be a class named "org.apache.jsp.MyJSP" without any concern whatsoever about conflicts because each individual page has its own class loader. Ah, I see, you avoid file-level conflicts by placing the generated code into separate directory paths, even though the package names (currently) do not reflect the directory locations. Yup, that should work, although i wouldn't say it is any less complex and I don't think it is consistent with standard java package/directory naming conventions. 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? Mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/etc server.xml
larryi 01/02/06 20:23:58
Modified:src/etc server.xml
Log:
Remove extra "/".
Make it a little easier to copy the "path" setting for the servlet_log to the
tc_log .
Revision ChangesPath
1.69 +3 -3 jakarta-tomcat/src/etc/server.xml
Index: server.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/etc/server.xml,v
retrieving revision 1.68
retrieving revision 1.69
diff -u -r1.68 -r1.69
--- server.xml2001/02/06 16:51:51 1.68
+++ server.xml2001/02/07 04:23:57 1.69
@@ -23,12 +23,12 @@
ContextInterceptor name="servlet_log"
className="org.apache.tomcat.modules.config.LogSetter"
-verbosityLevel = "INFORMATION"
-path="logs/servlet-${MMdd}.log" /
+path="logs/servlet-${MMdd}.log"
+verbosityLevel = "INFORMATION" /
ContextInterceptor name="JASPER_LOG"
className="org.apache.tomcat.modules.config.LogSetter"
-path="logs/jasper-${MMdd}.log" /
+path="logs/jasper-${MMdd}.log"
verbosityLevel = "INFORMATION" /
!--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
IIS/ISAPI connection to tomcat
I have a little problem with the isapi_redirect.dll connector to Tomcat. There seems to be a buffering problem with sending the response back to the browser. My symptoms are as follows: I access a JSP file running in Tomcat via the IIS and isapi_redirect.dll and I receive a page back that has random fragments of HTML repeated several times. I am happy with tracking down the problem and fixing it myself, if necessary, but before I do that I would like to ensure that I am not wasting my time. I am using tomcat 3.1-FINAL and a version of isapi_redirect.dll of about the same vintage. I cannot upgrade this server to Tomcat 3.2, as the case sensitivity breaks existing code (not written by me - bloody IIS). Has anyone seen/fixed this problem before? I see that there have been some changes to the source files since then. Should I be using a later version of the redirector, or is the new code specific to a later tomcat version? (I don't want to be fixing old code.) Thanks in advance for any help/advice that you can offer. --- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com
Re: signals with JNI
Daniel Diaz [EMAIL PROTECTED] wrote:
Another strange problem occurs if you replace this line by
system("uname -a");
after executing system() the JVM loading is blocked (in a sigsuspend I think).
Could you help me on this please ?
Hehehe :) You're going down hard-core on the VM :)
Well, I don't think you'll be actually able to TRAP a SEGV signal, I mean,
that signal means "segment violation" and it's the worst thing you can
possibly try to debug...
What I think is happening is that the VM itself (for debugging purposes, I
believe with the Debugging Native Interface), tries to set a handler to
SIGSEGV itself, and if it has already been set, it will just panic...
Aka, all it means is "don't mess around too much with that" :)
I don't know, though! I should have to go and look into the Hotspot
sources...
So far the same code you wrote works with SIGHUP, SIGKILL and SIGUSR?...
Pier
--
Pier Fumagalli mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: TDK and 4.0 or 4.1
Remy Maucherat [EMAIL PROTECTED] wrote: 4.1 is a development branch which is temporarily abandoned. Since it's abandoned, can't we just get rid of it? Pier -- Pier Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: signals with JNI
Pier Fumagalli [EMAIL PROTECTED] wrote: So far the same code you wrote works with SIGHUP, SIGKILL and SIGUSR?... Uh uh uh... So damn stupid Pier :) Now I get it, it's not because of SIGSEGV, but it's because a SIGSEGV is raised when the VM is created... :) Now I remember when I saw that message in the first place... Basically, what happens is that the "main" thread, to be able to receive signals, must be "detached" from the VM... By "detached" I don't mean calling the JNI_Detach_Thread() function, but it _MUST_ return before any signal can be caught (and this is a bug in the invocation stuff)... What you can do is: 1) create the VM 2) set the SIGSEGV handler 3) create a new Thread() that is the one which will call your main() method In this order it "should" work... (In theory, as always!) Pier -- Pier Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Is it legal to have multiple taglib setter methods for the same property
Hi folks. (My apologies for crossposting, I wasn't sure if this is a
taglib question or a tomcat question/problem)
I'm writing a taglib using the JSP 1.1 spec (currently Tomcat 3.x). I'm
having a problem with a property "set" method.
I have a taglib tag which takes one parameter: "index". This index can
be either the string "all" or a number representing which CLE object to
show.
I have the following defined in my tld file:
tag
namedisplayCLE/name
tagclasscom.funkware.DisplayCLETag/tagclass
teiclasscom.funkware.DisplayCLEExtraInfo/teiclass
infoDisplay a CLE/info
attribute
nameindex/name
requiredtrue/required
rtexprvaluetrue/rtexprvalue
/attribute
/tag
In my "DisplayCLETag.java" file, I have the following:
/**
* !-- setIndex--
*
*Called when the taglib encounters an int for the index field...
*This form takes an int which happens when a jsp expression is
*evaluated on the right side of the "index=".
*
* @param nIndex
*The index
*/
public void setIndex ( int nIndex ) {
m_nIndex = nIndex;
}
/**
* !-- setIndex--
*
*Called when the taglib encounters the "index" parameter. This
*form takes an object. We try to convert and Integer and a
*String. Anything else we barf on.
*
* @param o
*An object which we'll try to convert.
*/
public void setIndex ( String s ) {
if ( SHOWELEMENT_ALL_STRING.equalsIgnoreCase ( s ) ) {
m_nIndex = SHOWELEMENT_ALL;
return;
}
try {
m_nIndex = Integer.parseInt ( s );
} catch ( NumberFormatException e ) {
Dispatcher.log ( Log.NOTICE, "DisplayListElementTag.setElement",
"The element: '" + s +
"' is invalid, it should be a number" );
m_nIndex = SHOWELEMENT_UNDEF;
}
}
The reason I have two setter methods for Index is that doing:
af:displayCLE index="1"/
is different than
af:displayCLE index="%= i %"/ !-- where i is an int and == 1 --
Is this a legal way of doing this?
I ask because when I run tomcat using the SunJDK1.3, it works fine,
however when I run tomcat with the SunJDK1.3 with Hotspot, it fails with
java.lang.NumberFormatException: all
at java.lang.Integer.parseInt(Integer.java:405)
at java.lang.Integer.(Integer.java:540)
at org.apache.jasper.runtime.JspRuntimeLibrary.convert \
(JspRuntimeLibrary.java:125)
at org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper \
(JspRuntimeLibrary.java:201)
at ui.html._0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3._jspService \
(_0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3.java:274)
...
I don't actually think that is hotspot related. I think i'm doing
something wrong. I've looked through the tomcat code, however not too
particularly closely. I was hoping someone would know what's wrong.
In a somewhat unrelated question, I tried having my setIndex() method
defined as:
public void setIndex ( Object o )
and then doing internal "instanceof" calls and casting to proper
objects. This works in Tomcat 3.1, however it fails in Tomcat 4.0.
Did something change in JSP/Taglib 1.2 that makes that type of
declaration invalid?
Thanks very much.
...alex...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Is it legal to have multiple taglib setter methods for the same property
IIRC, having two setters with different argument types violates the JavaBeans
specification. In addition, it seems to cause the Java reflection APIs to think that
there
is no setter method at all, so you will get complaints about a read-only property from
any
JSP implementation that uses this technique.
Craig McClanahan
Alex Tang wrote:
Hi folks. (My apologies for crossposting, I wasn't sure if this is a
taglib question or a tomcat question/problem)
I'm writing a taglib using the JSP 1.1 spec (currently Tomcat 3.x). I'm
having a problem with a property "set" method.
I have a taglib tag which takes one parameter: "index". This index can
be either the string "all" or a number representing which CLE object to
show.
I have the following defined in my tld file:
tag
namedisplayCLE/name
tagclasscom.funkware.DisplayCLETag/tagclass
teiclasscom.funkware.DisplayCLEExtraInfo/teiclass
infoDisplay a CLE/info
attribute
nameindex/name
requiredtrue/required
rtexprvaluetrue/rtexprvalue
/attribute
/tag
In my "DisplayCLETag.java" file, I have the following:
/**
* !-- setIndex--
*
*Called when the taglib encounters an int for the index field...
*This form takes an int which happens when a jsp expression is
*evaluated on the right side of the "index=".
*
* @param nIndex
*The index
*/
public void setIndex ( int nIndex ) {
m_nIndex = nIndex;
}
/**
* !-- setIndex--
*
*Called when the taglib encounters the "index" parameter. This
*form takes an object. We try to convert and Integer and a
*String. Anything else we barf on.
*
* @param o
*An object which we'll try to convert.
*/
public void setIndex ( String s ) {
if ( SHOWELEMENT_ALL_STRING.equalsIgnoreCase ( s ) ) {
m_nIndex = SHOWELEMENT_ALL;
return;
}
try {
m_nIndex = Integer.parseInt ( s );
} catch ( NumberFormatException e ) {
Dispatcher.log ( Log.NOTICE, "DisplayListElementTag.setElement",
"The element: '" + s +
"' is invalid, it should be a number" );
m_nIndex = SHOWELEMENT_UNDEF;
}
}
The reason I have two setter methods for Index is that doing:
af:displayCLE index="1"/
is different than
af:displayCLE index="%= i %"/ !-- where i is an int and == 1 --
Is this a legal way of doing this?
I ask because when I run tomcat using the SunJDK1.3, it works fine,
however when I run tomcat with the SunJDK1.3 with Hotspot, it fails with
java.lang.NumberFormatException: all
at java.lang.Integer.parseInt(Integer.java:405)
at java.lang.Integer.(Integer.java:540)
at org.apache.jasper.runtime.JspRuntimeLibrary.convert \
(JspRuntimeLibrary.java:125)
at org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper \
(JspRuntimeLibrary.java:201)
at
ui.html._0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3._jspService \
(_0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3.java:274)
...
I don't actually think that is hotspot related. I think i'm doing
something wrong. I've looked through the tomcat code, however not too
particularly closely. I was hoping someone would know what's wrong.
In a somewhat unrelated question, I tried having my setIndex() method
defined as:
public void setIndex ( Object o )
and then doing internal "instanceof" calls and casting to proper
objects. This works in Tomcat 3.1, however it fails in Tomcat 4.0.
Did something change in JSP/Taglib 1.2 that makes that type of
declaration invalid?
Thanks very much.
...alex...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Is it legal to have multiple taglib setter methods for the same property
Thanks for the quick reply Craig.
A followup question. In tomcat 3.1, I was able to do
public setIndex ( Object o )
If this is legal, I can do my own internal checking to see if the object "o" is a
String or an
int. However in Tomcat 4.0, I get an error when I try to do this. I saw some talk
about this
on the tomcat archives, however it wasn't clear whether this is an error on my side or
an error
in tomcat.
Thanks again.
...alex...
"Craig R. McClanahan" wrote:
IIRC, having two setters with different argument types violates the JavaBeans
specification. In addition, it seems to cause the Java reflection APIs to think
that there
is no setter method at all, so you will get complaints about a read-only property
from any
JSP implementation that uses this technique.
Craig McClanahan
Alex Tang wrote:
Hi folks. (My apologies for crossposting, I wasn't sure if this is a
taglib question or a tomcat question/problem)
I'm writing a taglib using the JSP 1.1 spec (currently Tomcat 3.x). I'm
having a problem with a property "set" method.
I have a taglib tag which takes one parameter: "index". This index can
be either the string "all" or a number representing which CLE object to
show.
I have the following defined in my tld file:
tag
namedisplayCLE/name
tagclasscom.funkware.DisplayCLETag/tagclass
teiclasscom.funkware.DisplayCLEExtraInfo/teiclass
infoDisplay a CLE/info
attribute
nameindex/name
requiredtrue/required
rtexprvaluetrue/rtexprvalue
/attribute
/tag
In my "DisplayCLETag.java" file, I have the following:
/**
* !-- setIndex--
*
*Called when the taglib encounters an int for the index field...
*This form takes an int which happens when a jsp expression is
*evaluated on the right side of the "index=".
*
* @param nIndex
*The index
*/
public void setIndex ( int nIndex ) {
m_nIndex = nIndex;
}
/**
* !-- setIndex--
*
*Called when the taglib encounters the "index" parameter. This
*form takes an object. We try to convert and Integer and a
*String. Anything else we barf on.
*
* @param o
*An object which we'll try to convert.
*/
public void setIndex ( String s ) {
if ( SHOWELEMENT_ALL_STRING.equalsIgnoreCase ( s ) ) {
m_nIndex = SHOWELEMENT_ALL;
return;
}
try {
m_nIndex = Integer.parseInt ( s );
} catch ( NumberFormatException e ) {
Dispatcher.log ( Log.NOTICE, "DisplayListElementTag.setElement",
"The element: '" + s +
"' is invalid, it should be a number" );
m_nIndex = SHOWELEMENT_UNDEF;
}
}
The reason I have two setter methods for Index is that doing:
af:displayCLE index="1"/
is different than
af:displayCLE index="%= i %"/ !-- where i is an int and == 1 --
Is this a legal way of doing this?
I ask because when I run tomcat using the SunJDK1.3, it works fine,
however when I run tomcat with the SunJDK1.3 with Hotspot, it fails with
java.lang.NumberFormatException: all
at java.lang.Integer.parseInt(Integer.java:405)
at java.lang.Integer.(Integer.java:540)
at org.apache.jasper.runtime.JspRuntimeLibrary.convert \
(JspRuntimeLibrary.java:125)
at org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper \
(JspRuntimeLibrary.java:201)
at
ui.html._0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3._jspService \
(_0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3.java:274)
...
I don't actually think that is hotspot related. I think i'm doing
something wrong. I've looked through the tomcat code, however not too
particularly closely. I was hoping someone would know what's wrong.
In a somewhat unrelated question, I tried having my setIndex() method
defined as:
public void setIndex ( Object o )
and then doing internal "instanceof" calls and casting to proper
objects. This works in Tomcat 3.1, however it fails in Tomcat 4.0.
Did something change in JSP/Taglib 1.2 that makes that type of
declaration invalid?
Thanks very much.
...alex...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/test GTest.java HttpClient.java
costin 01/02/06 22:41:33
Modified:src/share/org/apache/tomcat/util/test GTest.java
HttpClient.java
Log:
Allow multiple tests (matchers ) per request.
Revision ChangesPath
1.9 +58 -23jakarta-tomcat/src/share/org/apache/tomcat/util/test/GTest.java
Index: GTest.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/test/GTest.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- GTest.java2001/01/31 02:02:39 1.8
+++ GTest.java2001/02/07 06:41:33 1.9
@@ -86,8 +86,10 @@
// Instance variables
HttpClient httpClient=new HttpClient();
-DefaultMatcher matcher=new DefaultMatcher();
+Vector matchers=new Vector();
+//DefaultMatcher matcher=new DefaultMatcher();
Body comment=null;
+String failMessage="";
String description="No description";
@@ -98,7 +100,7 @@
boolean result=false;
public GTest() {
- matcher.setDebug( debug );
+ //matcher.setDebug( debug );
httpClient.setDebug( debug );
}
@@ -183,7 +185,8 @@
}
public void addDefaultMatcher( DefaultMatcher m ) {
- matcher=m;
+ matchers.addElement( m );
+ // matcher=m;
}
public Body createComment() {
@@ -196,9 +199,9 @@
return httpClient;
}
-public DefaultMatcher getMatcher() {
- return matcher;
-}
+// public DefaultMatcher getMatcher() {
+// return matcher;
+// }
public String getComment() {
if(comment==null) return "";
@@ -209,18 +212,33 @@
/** Description should be in test description=""/
*/
public String getDescription() {
+ if( comment!=null) return comment.getText();
return description;
}
public void setDescription(String description) {
this.description=description;
}
+
+public String getMatchDescription() {
+ StringBuffer sb=new StringBuffer();
+ for( int i=0; imatchers.size(); i++ ) {
+ DefaultMatcher m=(DefaultMatcher)matchers.elementAt( i );
+ if( i!=0 ) sb.append( " " );
+ sb.append( m.getTestDescription());
+ }
+ return sb.toString();
+}
+
+public String getFailureMessage() {
+ return failMessage;
+}
/** Display debug info
*/
public void setDebug( String debugS ) {
debug=Integer.valueOf( debugS).intValue();
- matcher.setDebug( debug );
+ //matcher.setDebug( debug );
httpClient.setDebug( debug );
}
@@ -259,46 +277,56 @@
}
// Matcher properties
+
+// @deprecated Use defaultMatcher childs, this allow only one test !!!
+
public void setExactMatch(String exact) {
- matcher.setExactMatch(exact);
+ if( matchers.size() 0 )
+ ((DefaultMatcher)matchers.elementAt(0)).setExactMatch(exact);
}
/** True if this is a positive test, false for negative
*/
public void setMagnitude( String magnitudeS ) {
-matcher.setMagnitude( magnitudeS );
+ if( matchers.size() 0 )
+ ((DefaultMatcher)matchers.elementAt(0)).setMagnitude( magnitudeS );
}
/** Compare with the golden file
*/
public void setGoldenFile( String s ) {
- matcher.setGoldenFile(s);
+ if( matchers.size() 0 )
+ ((DefaultMatcher)matchers.elementAt(0)).setGoldenFile(s);
}
/** Verify that response includes the expected headers
* The value is a "|" separated list of headers to expect.
*/
public void setExpectHeaders( String s ) {
- matcher.setExpectHeaders( s );
+ if( matchers.size() 0 )
+ ((DefaultMatcher)matchers.elementAt(0)).setExpectHeaders( s );
}
/** Verify that response match the string
*/
public void setResponseMatch( String s ) {
- matcher.setResponseMatch( s );
+ if( matchers.size() 0 )
+ ((DefaultMatcher)matchers.elementAt(0)).setResponseMatch( s );
}
/** Verify that response matches a list of strings in a file
*/
public void setResponseMatchFile( String s ) {
- matcher.setResponseMatchFile( s );
+ if( matchers.size() 0 )
+ ((DefaultMatcher)matchers.elementAt(0)).setResponseMatchFile( s );
}
/** Verify the response code
*/
public void setReturnCode( String s ) {
- matcher.setReturnCode( s );
+ if( matchers.size() 0 )
+ ((DefaultMatcher)matchers.elementAt(0)).setReturnCode( s );
}
// Execute the request
@@
cvs commit: jakarta-tomcat/src/admin/test sanity-form.jsp test.jsp
costin 01/02/06 22:42:48
Modified:src/admin/WEB-INF/classes/tadm TomcatAdmin.java
src/admin/test sanity-form.jsp test.jsp
Log:
Fix the test.jsp to allow multiple checks per request.
Revision ChangesPath
1.9 +8 -5 jakarta-tomcat/src/admin/WEB-INF/classes/tadm/TomcatAdmin.java
Index: TomcatAdmin.java
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/WEB-INF/classes/tadm/TomcatAdmin.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TomcatAdmin.java 2001/02/03 07:48:28 1.8
+++ TomcatAdmin.java 2001/02/07 06:42:48 1.9
@@ -24,7 +24,7 @@
String action;
String host;
String value;
-PageContext pageContext;
+//PageContext pageContext;
public TomcatAdmin() {}
@@ -70,9 +70,9 @@
return EVAL_PAGE;
}
-public void setPageContext(PageContext pctx ) {
- this.pageContext=pctx;
-}
+// public void setPageContext(PageContext pctx ) {
+// this.pageContext=pctx;
+// }
public void setParent( Tag parent ) {
super.setParent( parent);
@@ -84,7 +84,10 @@
private void init(HttpServletRequest request) {
Request realRequest = (Request)
request.getAttribute( Request.ATTRIB_REAL_REQUEST);
- cm = realRequest.getContext().getContextManager();
+ if( cm==null )
+ pageContext.getServletContext().log("Untrusted Application");
+ else
+ cm = realRequest.getContext().getContextManager();
}
public ContextManager getContextManager(HttpServletRequest request ) {
1.2 +1 -0 jakarta-tomcat/src/admin/test/sanity-form.jsp
Index: sanity-form.jsp
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/test/sanity-form.jsp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- sanity-form.jsp 2001/01/29 06:46:19 1.1
+++ sanity-form.jsp 2001/02/07 06:42:48 1.2
@@ -2,6 +2,7 @@
Target:
select name="target"
optionfile/option
+ optionparams/option
optiondispatch/option
optionget/option
optionrequestMap/option
1.11 +3 -3 jakarta-tomcat/src/admin/test/test.jsp
Index: test.jsp
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/test/test.jsp,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- test.jsp 2001/02/01 04:43:48 1.10
+++ test.jsp 2001/02/07 06:42:48 1.11
@@ -63,7 +63,7 @@
font color='red' FAIL /font/a ( %= failures.getDescription() % )
%= failures.getHttpClient().getRequestLine() %
br
-TEST: %= failures.getMatcher().getTestDescription() %
+TEST: %= failures.getMatchDescription() %
br
bRequest: /b
pre
@@ -74,7 +74,7 @@
br
bMessage: /b
pre
- %= failures.getMatcher().getMessage() %
+ %= failures.getFailureMessage() %
/pre
% // use a tag %
@@ -106,7 +106,7 @@
OK/a ( %= success.getDescription() % )
%= success.getHttpClient().getRequestLine() %
br
-TEST: %= success.getMatcher().getTestDescription() %
+TEST: %= success.getMatchDescription() %
br
/adm:iterate
/body
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF/classes/params RDInclude.java ServletUtil.java InputStreamParams.java Params.java ParamsInputStream.java
costin 01/02/06 22:49:38
Modified:src/tests/webpages/WEB-INF test-tomcat.xml
src/tests/webpages/WEB-INF/classes/params
InputStreamParams.java Params.java
ParamsInputStream.java
Added: src/tests/webpages/WEB-INF/classes/params RDInclude.java
ServletUtil.java
Log:
More work on testing the parameter handling.
The final tests will cover:
- POST + GET and the way the params are merged
- The Body is read on getParameter ( and not before )
- RequestDispatchers and the way params are merged and restored.
- RequestDispatchers and the rule that the Body is read on the first
getParameter ( this will probably fail with Tomcat3.2 )
- Same tests for JSPs ( the tests for reading the Body will probably
fail on 3.2 and if 3.3 is using JspServlet - since JspServlet does a
getParameter that will automatically read the body )
- the special case of jsp_compile ( the spec mentions that ?jsp_compile
can be used - which is a special form of parameter, since it has no =)
- also make sure that jsp_compile doesn't execute the jsp
So far the tests found few bugs in reading input, I'll commit the fix
tommorow.
Revision ChangesPath
1.14 +78 -17jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml
Index: test-tomcat.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- test-tomcat.xml 2001/01/31 02:05:54 1.13
+++ test-tomcat.xml 2001/02/07 06:49:29 1.14
@@ -16,7 +16,7 @@
early tests.
--
- property name="revision" value="$Revision: 1.13 $" /
+ property name="revision" value="$Revision: 1.14 $" /
property name="host" value="127.0.0.1" /
property name="port" value="8080" /
property name="outputType" value="text" /
@@ -90,6 +90,82 @@
/target
+ !-- Parameters tests --
+
+ target name="params" depends="init"
+ gtest
+ commentSimple GET with parmeters/comment
+ httpClient path="/test/servlet/params.Params?a=kamp;c=lamp;a=m" /
+ defaultMatcher returnCode="200" /
+ defaultMatcher responseMatch="a = [ k , m ]" /
+ defaultMatcher responseMatch="c = [ l ]"/
+ /gtest
+
+ gtest
+ commentSimple POST parmeters/comment
+ httpClient path="/test/servlet/params.Params"
+ method="POST"
+ header name="Content-Type"
+ value="application/x-www-form-urlencoded" /
+ bodya=bamp;c=d/body
+ /httpClient
+ defaultMatcher returnCode="200" /
+ defaultMatcher responseMatch="a = [ b ]"/
+ defaultMatcher responseMatch="c = [ d ]"/
+ /gtest
+
+ gtest
+ commentPOST and GET parameters/comment
+ httpClient path="/test/servlet/params.Params?a=xamp;m=n"
+ method="POST"
+ header name="Content-Type"
+ value="application/x-www-form-urlencoded" /
+ bodya=bamp;c=d/body
+ /httpClient
+ defaultMatcher returnCode="200" /
+ defaultMatcher responseMatch="a = [ x , b ]"/
+ defaultMatcher responseMatch="m = [ n ]"/
+ defaultMatcher responseMatch="c = [ d ]"/
+ /gtest
+
+ gtest
+ commentThe POST data can't be read before getParameter/comment
+ httpClient
+ path="/test/servlet/params.InputStreamParams?a=xamp;m=n"
+ method="POST"
+ header name="Content-Type"
+ value="application/x-www-form-urlencoded" /
+ bodya=bamp;c=d/body
+ /httpClient
+ defaultMatcher returnCode="200" /
+ defaultMatcher responseMatch="a = [ x ]" /
+ defaultMatcher responseMatch="m = [ n ]"/
+ defaultMatcher responseMatch="c = [ d ]"/
+ /gtest
+
+
+ /target
+
+ !-- Init params tests --
+
+ target name="init-params" depends="init"
+gtest request="GET /test/servlet/servletParam1 HTTP/1.0"
+ returnCode="${http.protocol} 200"
+ goldenFile="${gdir}/servletParam1.txt"
+/
+
+gtest request="GET /test/servlet/servletParam2 HTTP/1.0"
+ returnCode="${http.protocol} 200"
+ goldenFile="${gdir}/servletParam2.txt"
+/
+
+gtest request="GET /test/servlet/ServletParam HTTP/1.0"
+ returnCode="${http.protocol} 200"
+ goldenFile="${gdir}/ServletParam.txt"
+/
+ /target
+
+
!--
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/http Parameters.java
costin 01/02/06 23:01:31
Modified:src/share/org/apache/tomcat/core ContextManager.java
Request.java
src/share/org/apache/tomcat/modules/server
Ajp12Interceptor.java Ajp13Interceptor.java
Http10Interceptor.java JNIConnectionHandler.java
src/share/org/apache/tomcat/startup StopTomcat.java
src/share/org/apache/tomcat/util/http Parameters.java
Log:
Fixed a number of probles with reading the request body.
- moved the check for "available" in Request, and make sure all the
adapters are checking if more data is to be expected.
( it used to be in the facade, but this is not the only place where the
check must be made - it's much better to test it at the lower level )
- few changes in how the POST data is pushed in Parameters.
Note: reading the request body will be changed a bit to deal with the
encoding problems, right now the parameters have hardcoded charset
( that was the original code ), and needs to be fixed.
Revision ChangesPath
1.167 +3 -0
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.166
retrieving revision 1.167
diff -u -r1.166 -r1.167
--- ContextManager.java 2001/02/06 06:41:07 1.166
+++ ContextManager.java 2001/02/07 07:01:23 1.167
@@ -871,7 +871,10 @@
}
Request lr = new Request();
+ Response res = new Response();
lr.setContextManager( this );
+ lr.setResponse( res );
+ res.setRequest( lr );
lr.requestURI().setString( urlPath );
lr.queryString().setString(queryString );
1.89 +69 -27jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java
Index: Request.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v
retrieving revision 1.88
retrieving revision 1.89
diff -u -r1.88 -r1.89
--- Request.java 2001/02/06 06:29:19 1.88
+++ Request.java 2001/02/07 07:01:23 1.89
@@ -137,9 +137,12 @@
// Processed information ( redundant ! )
protected Parameters params=new Parameters();
//protected Hashtable parametersH = new Hashtable();
-protected boolean didReadFormData;
+protected boolean didReadFormData=false;
protected int contentLength = -1;
+// how much body we still have to read.
+protected int available = -1;
+
protected String contentType = null;
protected String charEncoding = null;
protected MessageBytes serverNameMB=new MessageBytes();
@@ -327,12 +330,26 @@
* are available.
*/
public void handlePostParameters() {
- int needData=params.needContent();
+ if( didReadFormData )
+ return;
+ didReadFormData=true;
+
+ if( ! methodMB.equalsIgnoreCase("POST") )
+ return;
+ String contentType= getContentType();
+ if (contentType == null
+contentType.startsWith("application/x-www-form-urlencoded")) {
+ return;
+ }
- if( needData 0 ) {
+ int len=getContentLength();
+ int available=getAvailable();
+
+ // read only available ( someone else may have read the content )
+ if( available 0 ) {
try {
- byte[] formData = new byte[needData];
- readBody( formData, needData );
+ byte[] formData = new byte[available];
+ readBody( formData, available );
params.processData( formData );
} catch(IOException ex ) {
// XXX should we throw exception or log ?
@@ -345,8 +362,6 @@
return params;
}
-
-
// encoding/type
public String getCharacterEncoding() {
@@ -361,6 +376,7 @@
public void setContentLength( int len ) {
this.contentLength=len;
+ available=len;
}
public int getContentLength() {
@@ -368,6 +384,7 @@
MessageBytes clB=headers.getValue("content-length");
contentLength = (clB==null || clB.isNull() ) ? -1 : clB.getInt();
+ available=contentLength;
return contentLength;
}
@@ -690,38 +707,43 @@
return headers.names();
}
-// Utils - facade for RequestUtil
+// Computed fields
+
-/** Read request data, filling a byte[]
+// For adapters
+// This should move to an IntputBuffer - the reading
AccessInterceptor bug
Hi
...I've tried to modify AccessInterceptor in order to use FORM
authentication WITHOUT enabling cookies.
The appended code stays between //HERE IS THE DIFFERENCE // SOFTWIN: THE
DIFFERENCE ENDS HERE. Unfortunately, I didn't succeed in copiling it. Could
you take a look and eventually send me back a "fixed" Tomcat?
...
// SOFTWIN: HERE IS THE DIFFERENCE
boolean noCookies=false;
public void setNoCookies(boolean noCookies) {
this.noCookies = noCookies;
}
// SOFTWIN: THE DIFFERENCE ENDS HERE
...
class FormAuthHandler extends ServletWrapper {
FormAuthHandler() {
initialized=true;
internal=true;
name="tomcat.formAuthHandler";
}
public void doService(Request req, Response res)
throws Exception
{
Context ctx=req.getContext();
HttpSession session=req.getSession( false );
if( session == null ) {
}
String page=ctx.getFormLoginPage();
String errorPage=ctx.getFormErrorPage();
// assert errorPage!=null ( AccessInterceptor will check
// that and enable form login only if everything is ok
session=req.getSession( true );
String username=(String)session.getAttribute( "j_username" );
if( debug0) log( "Username = " + username);
if( username != null ) {
// 401 with existing j_username - that means wrong credentials.
// Next time we'll have a fresh start
session.removeAttribute( "j_username");
session.removeAttribute( "j_password");
req.setAttribute("javax.servlet.error.message",
errorPage );
contextM.handleStatus( req, res, 302 ); // redirect
return;
}
String originalLocation = req.getRequestURI();
// SOFTWIN: HERE IS THE DIFFERENCE
if (noCookies)
{
originalLocation+="jsessionid="+session.getId();
}
// SOFTWIN: THE DIFFERENCE ENDS HERE
if (req.getQueryString() != null)
originalLocation += "?" + req.getQueryString();
session.setAttribute( "tomcat.auth.originalLocation",
originalLocation);
if( debug 0 )
log("Redirect1: " + page + " originalUri=" +
req.getRequestURI());
req.setAttribute("javax.servlet.error.message",
page );
contextM.handleStatus( req, res, 302 ); // redirect
return;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
