DO NOT REPLY [Bug 15052] New: - ODBC bridge corrupt under NT service
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15052. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15052 ODBC bridge corrupt under NT service Summary: ODBC bridge corrupt under NT service Product: Tomcat 4 Version: Unknown Platform: PC OS/Version: Windows XP Status: UNCONFIRMED Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] discovered that a JSP page using a package that links to a JDBC-ODBC bridge crashed if and only if (iff) it was set to be an NT service. it seemed as if it was trying to run the bridge before the ODBC service had been initialized. perhaps this would be more stable if done at JSP run-time as opposed to catalina runtime. don't know if that would work however with the JDBC-ODBC bridge being run in the package. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15053] New: - Examples must be installed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15053. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15053 Examples must be installed Summary: Examples must be installed Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows XP Status: UNCONFIRMED Severity: Blocker Priority: Other Component: Webapps:Examples AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] under the installation options, you have to accept the examples installer, or the default (server.xml) cannot run catalina. it crashes complaining that there is no example folder. hmmm, well, i chose not to install it for a reason. anyway, good luck with that. works on my previous version of tomcat (4.0.40). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15053] - Examples must be installed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15053. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15053 Examples must be installed [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 09:51 --- It has been fixed in 4.1.16. Please do not file duplicates. You can also easily work around this by removing the section in server.xml about the examples webapp. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15054] New: - un able to update CONTEXT in webapps/admin
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15054. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15054 un able to update CONTEXT in webapps/admin Summary: un able to update CONTEXT in webapps/admin Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] when i log into my admin page, i cannot change some of the default CONTEXT settings because they are blank, and the XML/XSL transformer doesn't seem to create a text field if there is no NODE for it in the XML. as well, once i go into the ADMIN page, i can no longer modify my XML setting files. meaning i cannot manually correct for this problem. as well, i cannot seem to add/remove contexts. it had some contexts that it ported from my old Tomcat/WebApps (4.0.40), but i could not delete unwanted ones and coule not create new ones (mostly because i could not modify XML anymore). good luck with that. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 bldjk.qclsrc
hgomez 2002/12/04 02:12:04
Modified:jk/native/apache-2.0 bldjk.qclsrc
Log:
Link phase should also use the TERASPACE model
Revision ChangesPath
1.4 +1 -0 jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc
Index: bldjk.qclsrc
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- bldjk.qclsrc 3 Dec 2002 17:50:29 - 1.3
+++ bldjk.qclsrc 4 Dec 2002 10:12:04 - 1.4
@@ -280,6 +280,7 @@
SRCFILE(MOD_JK/QSRVSRC)+
SRCMBR(MOD_JK) +
DETAIL(*BASIC) +
+ STGMDL(*TERASPACE) +
BNDSRVPGM(QHTTPSVR/QZSRAPR QHTTPSVR/QZSRCORE +
QHTTPSVR/QZSRXMLP QHTTPSVR/QZSRSDBM) +
TEXT('Apache mod_jk tomcat connector module')
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15054] - un able to update CONTEXT in webapps/admin
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15054. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15054 un able to update CONTEXT in webapps/admin [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 10:22 --- Editing contexts works fine for me with more recent builds. I don't know for sure about 4.1.12. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
pushBody()/popBody() error
How it should work: I am using bodytag that calls a pushBody(), then the current body writer sould be kept and it should be createa a new one, later when I call the popBody() the system should get the previous body (that is, the body that has been kept on the call to pushBody()) What it does now: All works as expected, but after I call popBody() the new body writer that has been created on the call to pushBody() writes its contents to the previous body writer (that is, the body that has been kept on the call to pushBody()). I think that the content should not been copied on the other body writer. It fails on Tomcat 4.1.12 and it works fine on Tomcat 4.0.X. Cheers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13040] - can't retrieve external context who's uri is a sub-dir of current context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13040. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13040 can't retrieve external context who's uri is a sub-dir of current context --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 12:29 --- This is a serious bug that needs to be fixed. I agree that the last patch submited by Martin Algesten lookes nice. Please add it yo the CVS tree. Thanks! Christer Grimsæth -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
patches to remove calls to setenv
Unless I'm mistaken, setenv.bat and setenv.sh were retired long ago. There are still calls to them in the following .bat and shell files: catalina.bat catalina.sh jasper.bat jasper.sh jspc-using-launcher.bat jspc-using-launcher.sh shutdown-using-launcher.bat shutdown-using-launcher.sh startup-using-launcher.bat startup-using-launcher.sh tool-wrapper-using-launcher.bat tool-wrapper-using-launcher.sh tool-wrapper.bat tool-wrapper.sh The attached zip files contain diff -u patches for all these files. catalina-setenv-diffs.zip Description: catalina-setenv-diffs.zip jasper-setenv-diffs.zip Description: jasper-setenv-diffs.zip -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15065] New: - reuse of variables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15065. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15065 reuse of variables Summary: reuse of variables Product: Tomcat 4 Version: 4.1.16 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Using a code like this in jsp results in compile-errors: ... % -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15066] New: - reuse of variables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15066.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15066
reuse of variables
Summary: reuse of variables
Product: Tomcat 4
Version: 4.1.16
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Servlet JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Using a code like this in jsp results in compile-errors:
---cut---
%
if (bAnyVar == true)
{
%anytag id=sHrefString param=A /%
%a href=%=sHrefString%TEST TRUE/a%
}
else
{
%anytag id=sHrefString param=B /%
%a href=%=sHrefString%TEST FALSE/a%
}
%
---cut---
For the first condition a String sHrefString declaration is generated in the
Servlet.
For the second condition this declaration is missing (wrong reuse??)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15065] - reuse of variables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15065. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15065 reuse of variables [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 13:49 --- pressed tab-enter to fast -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15032. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 14:27 --- Thanks to check with latest releases : jk 1.2.1 or jk 2.0.2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange Tomcat 4.1.x release versions
I also had some questions about how releases are made a few weeks ago. Since we voted to pattern the releases after httpd, then I guess we are using this document as a guideline on how to release: http://httpd.apache.org/dev/release.html Glenn Jon Scott Stevens wrote: on 2002/12/3 11:51 AM, Craig R. McClanahan [EMAIL PROTECTED] wrote: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]. orgmsgNo=52475 Someone obviously hasn't been keeping up on TOMCAT-DEV mail :-). See the discussions and vote that took place in April 2003, where the Tomcat developers agreed to adopt the version numbering approach that Apache 2.0 (and several other projects) use. A good starting point: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]. orgmsgNo=39859 Ok, I understand the version number part now. I actually read those discussions but forgot about them. Full brain. But are you also saying that the HTTPd project doesn't announce on the list in advance when a new release is going to happen? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Sorry to be late commenting on this. I have been busy with non Tomcat stuff. I have read most of the thread and just picked the original proposal to reply to. I agree that authentication and authorization should be split out into separate interfaces. I also think it would be nice if the web server (especially Apache) could work seemlessly with Tomcat realm based authentication for when you use Apache to serve static content. I think Costin raised this point. I have some other issues with realm based authentication as currently implemented. There are a number of different types of realm implementations in org.apache.catalina.realm. These are all solely used for web application realm based authentication except for those which implement the UserDatabase which understands users, groups, and roles and has methods for managing these. Also a UserDatabase can be instantiated as a JNDI resource. It would be nice if all realm implementations could support not only authentication and authorization but also management of users, groups, and roles. And be instantiated as a JNDI resource so it can be provided by the container as a resource to a virtual host. This would allow adding support to the web application manager for user management so that a virtual host could manage their own universe of users. Or even integrate this into their own web application. This would require extending the JndiPermission custom SecurityManager permission to support read/write of a realm JNDI resource. And putting the interfaces for using the realms in a package such as org.apache.realm so that web applications can use the interface for managing users without having to grant a RuntimePermission accessClassInPackage for org.apache.catalina.realm. Regards, Glenn Jeanfrancois Arcand wrote: Hi, I would like to propose the following re-factorisation of the current Realm interface. Righ now, Realm contains 3 methods related to authorization: hasRole hasUserDataPermission hasResourcePermission I would like to create a new interface called Authorizator(and a default AuthorizatorBase) that will take care of those methods. I just think those methods should be grouped together, and I think they are not directly related to the Realm concepts (better separation of concepts). It will allows peoples to change the current resource authorization mechanism without having to modify the Realm interface. Precisely, the method will have the following signature: public boolean hasResourcePermission(HttpRequest request, HttpResponse response, SecurityConstraint constraint, Context context) public boolean hasRolePermission(HttpRequest request, HttpResponse response, String role); public boolean hasUserDataPermission(HttpRequest request, HttpResponse response, SecurityConstraint constraint, Context context) In the current implementation, those methods will get invoked by the AuthenticatorBase and when the user call isUserInRole(). This factorisation will provide the ability to replace/extend the default AuthorizatorBase (that implement the Servlet security-constraint stuffs...section SRV 12.7) by another mechanism: LDAP, NFS, Database, File base, JSR 115, etc. This way peoples will be able to grant/denied permissions not only based on the web.xml content, but also using other technologies. Althrough it is possible to do that with the current Tomcat 5 codebase, I recommend we create this extra interface. For J2EE 1.4, I was able to implement JSR 115 without having to much problems, but I'm sure having a specialized interface will make implementation easier. The Realm.hasRole will be deprecated in order to achieve that re-factorisation. What do you think? Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
pushBody()/popBody() error on tomcat 4.1.12
How it should work: I am using bodytag that calls a pushBody(), then the current body writer sould be kept and it should be createa a new one, later when I call the popBody() the system should get the previous body (that is, the body that has been kept on the call to pushBody()) What it does now: All works as expected, but after I call popBody() the new body writer that has been created on the call to pushBody() writes its contents to the previous body writer (that is, the body that has been kept on the call to pushBody()). I think that the content should not been copied on the other body writer. It fails on Tomcat 4.1.12 and it works fine on Tomcat 4.0.X. Cheers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jasper 2 Synchronized JSP compiles
I have some ideas on how invoking the javac compiler for compiling JSP pages can be improved. Currently Jasper 2 uses ant to do compiles from within Tomcat which are synchronized. There are currently several problems. 1. The known javac memory leak. 2. JSP page compiles are synchronized. 3. Jikes currently can't be configured for windows because the windows build of jikes doesn't support -encoding. 4. We may be getting some bug reports related to this problem noted in the Ant documentation for the javac task: Windows Note:When the modern compiler is used in unforked mode on Windows, it locks up the files present in the classpath of the javac task, and does not release them. The side effect of this is that you will not be able to delete or move those files later on in the build. The workaround is to fork when invoking the compiler. Recommendation: Change Jasper 2 so that it tells ant to fork the javac compile. This should remove the need to synchronize the compiles. It will also move java compilation outside of the JVM process Tomcat is running in saving JVM heap memory and reducing GC overhead from objects created for JSP compiles. This could be done by just adding another parameter called fork to the JspServlet paramters. If fork=true ant forks the javac compile and no synchronization is done. The default for fork would be false. Comments? Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Making JMX required in tomcat5
+1 Costin Manolache wrote: The subject should be clear. The benefit is that we'll be able to build more JMX awareness in the code without doing tricks - each component will know about its ObjectName and will be able to return ObjectName[]. I'm not proposing MBeans all over tomcat - modeler works very well in transforming our components into model mbeans. We already have 3 +1 votes ( costin, Remy and Jean Francois ). The only possible problem is the classical licensing issue ( we must use mx4j - but I don't know if they passed the TCK or if they will or if the TCK is available yet, etc ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5
With Tomcat 4.1 released many tomcat developers have been reticent to add new features to its codebase for a number of reasons. All the development going on in Tomcat 5 and wanting to keep the number of codebase's where bug fix patches have to be applied to a minimum. There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2 release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized so that Tomcat 5 can be released. There isn't that much difference in the core of catalina between the Servlet 2.3 and Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase to make it neutral to what Servlet spec is implemented. Then this codebase could be used for future Tomcat 4 and Tomcat 5 development. And we then have a common codebase for applying bug fix patches. This seems to fit in with the direction we have been going where different components are kept in different code bases. naming, connectors, jasper, etc. Comments? Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Costin Manolache wrote: Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I think it is time to stop bloating the base tomcat source and binaries. BTW, it may be a good time to move some of the current features in separate modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide bundled with tomcat and the current code deprecated. I'm not talking ( for now ) about a real module with descriptors or anything, just separate dirs in the CVS and a .jar target that can be included or not. It may be worth reopening the minimal tomcat discussion :-) Costin +1 to Costin's comments -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5
Glenn Nielsen wrote: With Tomcat 4.1 released many tomcat developers have been reticent to add new features to its codebase for a number of reasons. All the development going on in Tomcat 5 and wanting to keep the number of codebase's where bug fix patches have to be applied to a minimum. There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2 release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized so that Tomcat 5 can be released. There isn't that much difference in the core of catalina between the Servlet 2.3 and Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase to make it neutral to what Servlet spec is implemented. Then this codebase could be used for future Tomcat 4 and Tomcat 5 development. And we then have a common codebase for applying bug fix patches. This seems to fit in with the direction we have been going where different components are kept in different code bases. naming, connectors, jasper, etc. Comments? This is hard to do (Catalina has never been written to allow facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade. I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2 from TC 4.1 very very quickly. Do you want a common codebase and some facades for that too ? ;-) Connectors is in common, because of the set of facades used in Coyote. I have no interest in that project, and see no point in trying to extend the life of the old API (given that the new one is quite similar). -0 from me (ie, go ahead if there's some developer interest; of course, implementation details will need to be discussed further). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5
Remy Maucherat wrote: Glenn Nielsen wrote: With Tomcat 4.1 released many tomcat developers have been reticent to add new features to its codebase for a number of reasons. All the development going on in Tomcat 5 and wanting to keep the number of codebase's where bug fix patches have to be applied to a minimum. There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2 release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized so that Tomcat 5 can be released. There isn't that much difference in the core of catalina between the Servlet 2.3 and Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase to make it neutral to what Servlet spec is implemented. Then this codebase could be used for future Tomcat 4 and Tomcat 5 development. And we then have a common codebase for applying bug fix patches. This seems to fit in with the direction we have been going where different components are kept in different code bases. naming, connectors, jasper, etc. Comments? This is hard to do (Catalina has never been written to allow facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade. I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2 from TC 4.1 very very quickly. Do you want a common codebase and some facades for that too ? ;-) Connectors is in common, because of the set of facades used in Coyote. I have no interest in that project, and see no point in trying to extend the life of the old API (given that the new one is quite similar). -0 from me (ie, go ahead if there's some developer interest; of course, implementation details will need to be discussed further). I'd like to add that these comments only apply to a portion of the code in j-t-catalina. A significant amount of code is independent (the stores, the auth, the realms, etc, etc), and could be put in that legendary j-t-modules repository ;-) I don't see how j-t-jasper could be independent of the API (nor the rest of j-t-catalina); at least not without a prohibitive amount of work. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5
Remy Maucherat wrote: Glenn Nielsen wrote: With Tomcat 4.1 released many tomcat developers have been reticent to add new features to its codebase for a number of reasons. All the development going on in Tomcat 5 and wanting to keep the number of codebase's where bug fix patches have to be applied to a minimum. There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2 release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized so that Tomcat 5 can be released. There isn't that much difference in the core of catalina between the Servlet 2.3 and Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase to make it neutral to what Servlet spec is implemented. Then this codebase could be used for future Tomcat 4 and Tomcat 5 development. And we then have a common codebase for applying bug fix patches. This seems to fit in with the direction we have been going where different components are kept in different code bases. naming, connectors, jasper, etc. Comments? This is hard to do (Catalina has never been written to allow facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade. Right, I am aware of that. There isn't that much difference between Servlet 2.3 and Servlet 2.4. Having a common codebase for both would make addition of new non spec related features easier and bug fix patching easier. I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2 from TC 4.1 very very quickly. Do you want a common codebase and some facades for that too ? ;-) No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make sense to do so, also jasper is primarily implementing the JSP spec. Whereas the core of catalina is where all the non spec related features get added. Connectors is in common, because of the set of facades used in Coyote. I have no interest in that project, and see no point in trying to extend the life of the old API (given that the new one is quite similar). -0 from me (ie, go ahead if there's some developer interest; of course, implementation details will need to be discussed further). Remy There needs to be someplace where new features can be added to the Tocmat 4 branch. You have been against adding new features to Tomcat 4 head, creating a Tocmat 4.2 branch for developement, and now against making j-t-catalina common to both Tomcat 4 5. If this is what you want then perhaps you should propose a VOTE to freeze all work on Tomcat 4 except for bug fixes. And I mean all work. If the community votes to do that then I will stop asking and perhaps go review the rules for revolutionaries. Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15077] New: - NPE when reloading servlets in org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:686)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15077.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15077
NPE when reloading servlets in
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:686)
Summary: NPE when reloading servlets in
org.apache.catalina.core.StandardWrapper.allocate(Standa
rdWrapper.java:686)
Product: Tomcat 4
Version: 4.1.16
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi
Dynamic reloading of a servlet (with or without SingleThreadModel interface)
leads to a NullPointerException in
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:686). It
seems that the instancePool stack is not properly constructed when the
allocated method is call during a reload. The servlet has nothing really
special except that it is a second level derivation of HttpServlet and is
activated thru RequestDispatcher.forward().
2002-12-04 17:42:38 StandardContext[/primer]: Le rechargement de ce contexte a
démarré
2002-12-04 17:42:38 MYSERVLET01 : MYSERVLET00: DESTROYED
2002-12-04 17:42:38 MYSERVLET01 : MYSERVLET00: DESTROYED
2002-12-04 17:42:38 MYSERVLET00 : MYSERVLET00: DESTROYED
2002-12-04 17:42:38 MYSERVLET00 : MYSERVLET00: DESTROYED
2002-12-04 17:42:38 StandardContext[/primer]: Sending application stop events
2002-12-04 17:42:38 StandardContext[/primer]: Stopping filters
2002-12-04 17:42:38 WebappLoader[/primer]: Deploying class repositories to work
directory C:\Program Files\Apache Group\Tomcat 4.1.16
\work\Standalone\localhost\primer
2002-12-04 17:42:38 WebappLoader[/primer]: Deploy class files /WEB-INF/classes
to C:\IWK\MyApp\Primer\WEB-INF\classes
2002-12-04 17:42:38 WebappLoader[/primer]: Deploy JAR /WEB-INF/lib/myapp.jar to
C:\IWK\MyApp\Primer\WEB-INF\lib\myapp.jar
2002-12-04 17:42:38 WebappLoader[/primer]: Deploy JAR /WEB-INF/lib/percobol.jar
to C:\IWK\MyApp\Primer\WEB-INF\lib\percobol.jar
2002-12-04 17:42:38 WebappLoader[/primer]: Reloading checks are enabled for
this Context
2002-12-04 17:42:38 NamingContextListener[/Standalone/localhost/primer]:
Creating JNDI naming context
2002-12-04 17:42:38 NamingContextListener[/Standalone/localhost/primer]:
Resource parameters for UserTransaction = null
2002-12-04 17:42:38 StandardContext[/primer]: Configuring application event
listeners
2002-12-04 17:42:38 StandardContext[/primer]: Sending application start events
2002-12-04 17:42:38 StandardContext[/primer]: Starting filters
2002-12-04 17:42:38 StandardWrapper[/primer:default]: Chargement du conteneur
(container) de servlet default
2002-12-04 17:42:38 StandardWrapper[/primer:invoker]: Chargement du conteneur
(container) de servlet invoker
2002-12-04 17:42:38 StandardManager[/primer]: Alimentation de la classe du
générateur de nombre aléatoire java.security.SecureRandom
2002-12-04 17:42:38 StandardManager[/primer]: L'alimentation du générateur de
nombre aléatoire est terminé
2002-12-04 17:42:38 StandardContext[/primer]: Le rechargement de ce contexte
est terminé
2002-12-04 17:42:39 StandardContext[/primer]: Mapping contextPath='/primer'
with requestURI='/primer/kix' and relativeURI='/kix'
2002-12-04 17:42:39 StandardContext[/primer]: Trying exact match
2002-12-04 17:42:39 StandardContext[/primer]: Mapped to servlet 'MyApp
Executive' with servlet path '/kix' and path info 'null' and update=true
2002-12-04 17:42:39 StandardWrapperValve[MyApp Executive]: Exception lors de
lallocation pour la servlet {0}
java.lang.NullPointerException
at org.apache.catalina.core.StandardWrapper.allocate
(StandardWrapper.java:686)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2407)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at
DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15032. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 17:50 --- tested with mod_jk2.so version 2.0.2 has the same issue... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Repost: SSI invoking CGI fix PATCH
Errr, Anyone care about this? How do I get a patch in the repository? Hello Tom Cats, Currently under Tomcat 4.1.12 SSI normal configuration which invokes a CGI script does not work. The reason for this is pretty obvious: The SSI servelet uses the pathInfo (PATH_INFO) value and calls the request dispatcher for any resources needed. The request dispatcher eats the pathInfo value and the CGI servlet can't find the CGI program, because it relies on pathInfo to tell it where the script is. Or something like that, whatever, you cats probably know better. Anyway, I made minor changes to three files in the current 4.1.12 distro to solve this problem. The strategy is thus: SSI-invoked resources flag the request with an attibute. When CGI servlet finally gets the request dispached, he checks whether SSI servlet invoked the resource via said attribute. If this is the case, he ignores the request.getPathInfo() method in favor of an already-present attribute on the request which already has the PATH_INFO environment value in it. Voila, everything works now. Diff attached. Nick Bauman Software Engineer Cortexity Development 3600 N. Dupont Minneapolis, MN 55412 M: 612-232-7120 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Making JMX required in tomcat5
On Tue, 3 Dec 2002, Costin Manolache wrote: Date: Tue, 03 Dec 2002 12:22:18 -0800 From: Costin Manolache [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [VOTE] Making JMX required in tomcat5 The subject should be clear. The benefit is that we'll be able to build more JMX awareness in the code without doing tricks - each component will know about its ObjectName and will be able to return ObjectName[]. I'm not proposing MBeans all over tomcat - modeler works very well in transforming our components into model mbeans. We already have 3 +1 votes ( costin, Remy and Jean Francois ). Add a +1 from me as well. The only possible problem is the classical licensing issue ( we must use mx4j - but I don't know if they passed the TCK or if they will or if the TCK is available yet, etc ). Has anyone asked the MX4J developers about this? That would seem to be the next course of action. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5
Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: With Tomcat 4.1 released many tomcat developers have been reticent to add new features to its codebase for a number of reasons. All the development going on in Tomcat 5 and wanting to keep the number of codebase's where bug fix patches have to be applied to a minimum. There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2 release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized so that Tomcat 5 can be released. There isn't that much difference in the core of catalina between the Servlet 2.3 and Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase to make it neutral to what Servlet spec is implemented. Then this codebase could be used for future Tomcat 4 and Tomcat 5 development. And we then have a common codebase for applying bug fix patches. This seems to fit in with the direction we have been going where different components are kept in different code bases. naming, connectors, jasper, etc. Comments? This is hard to do (Catalina has never been written to allow facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade. Right, I am aware of that. There isn't that much difference between Servlet 2.3 and Servlet 2.4. Having a common codebase for both would make addition of new non spec related features easier and bug fix patching easier. I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2 from TC 4.1 very very quickly. Do you want a common codebase and some facades for that too ? ;-) No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make sense to do so, also jasper is primarily implementing the JSP spec. Whereas the core of catalina is where all the non spec related features get added. I mentioned Jasper since it was in your list of components in common. Connectors is in common, because of the set of facades used in Coyote. I have no interest in that project, and see no point in trying to extend the life of the old API (given that the new one is quite similar). -0 from me (ie, go ahead if there's some developer interest; of course, implementation details will need to be discussed further). Remy There needs to be someplace where new features can be added to the Tocmat 4 branch. You have been against adding new features to Tomcat 4 head, creating a Tocmat 4.2 branch for developement, and now against making j-t-catalina common to both Tomcat 4 5. I am not against it (I would have been -1). I just think it is not such a great idea, so as it stands, I do not support it and don't plan to help. BTW, I have been regularly adding features to 4.1.x, excluding the features which change existing behavior or lead to API changes (of course, given your recent posts, I guess you don't really know what occurred in tomcat-dev in the last 2 months). Please read the commits and the changelog. If this is what you want then perhaps you should propose a VOTE to freeze all work on Tomcat 4 except for bug fixes. And I mean all work. If the community votes to do that then I will stop asking and perhaps go review the rules for revolutionaries. Glenn, I do not understand what is it that is not in 4.1 that you would want to add. Costin posted a comment the last time you mentioned 4.2 (I think it was one month ago), and I fully agree with it. If you want to make a proposal, including a revolution, please do so. As is, my personal opinion is that having a common j-t-catalina between 4.x and 5.x is not doable from a technical standpoint (given that we have limited development resources), and even not desirable, as some API changes will be needed to make Catalina faster (right now, mapping and auth are really slow, and will need access to j-t-c/util objects to have acceptable speed and GC behavior). Another possibility, given that the API 2.4 is close from 2.3, is that we release j-t-catalina as part of a 4.2 release, and advertise it as supporting servlets 2.3. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java
jfarcand2002/12/04 09:42:32
Modified:coyote/src/java/org/apache/coyote/tomcat5
CoyoteResponse.java
Log:
Fix for bugtraq 4772112 encodeURL does not encode session with empty URL (rfc2396)
Revision ChangesPath
1.15 +12 -6
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java
Index: CoyoteResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- CoyoteResponse.java 3 Dec 2002 16:37:59 - 1.14
+++ CoyoteResponse.java 4 Dec 2002 17:42:31 - 1.15
@@ -1033,10 +1033,16 @@
* @param url URL to be encoded
*/
public String encodeURL(String url) {
-
-if (isEncodeable(toAbsolute(url))) {
+
+String absolute = toAbsolute(url);
+if (isEncodeable(absolute)) {
HttpServletRequest hreq =
(HttpServletRequest) request.getRequest();
+
+// W3c spec clearly said
+if (url.equalsIgnoreCase()){
+url = absolute;
+}
return (toEncoded(url, hreq.getSession().getId()));
} else {
return (url);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteResponse.java
jfarcand2002/12/04 09:43:05
Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteResponse.java
Log:
Fix for bugtraq 4772112 encodeURL does not encode session with empty URL (rfc2396)
Revision ChangesPath
1.30 +12 -6
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java
Index: CoyoteResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- CoyoteResponse.java 11 Nov 2002 11:01:04 - 1.29
+++ CoyoteResponse.java 4 Dec 2002 17:43:05 - 1.30
@@ -981,10 +981,16 @@
* @param url URL to be encoded
*/
public String encodeURL(String url) {
-
-if (isEncodeable(toAbsolute(url))) {
+
+String absolute = toAbsolute(url);
+if (isEncodeable(absolute)) {
HttpServletRequest hreq =
(HttpServletRequest) request.getRequest();
+
+// W3c spec clearly said
+if (url.equalsIgnoreCase()){
+url = absolute;
+}
return (toEncoded(url, hreq.getSession().getId()));
} else {
return (url);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15081] New: - WAR loses date information for enclosed contents
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15081. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15081 WAR loses date information for enclosed contents Summary: WAR loses date information for enclosed contents Product: Tomcat 4 Version: 4.0 Beta 1 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When the .war is decompressed, the file contents are all given the file creation date for the time of extraction. The .war contains the correct dates. I.e. if you open the .war with pkzip or WinZIP, you'll see that the correct creation dates are present. Why do I need the actual creation dates? I am using an autodeploy process (Java Web Start) for distributing my rich client. Because the .war loses the dates, each new .war requires every file to download. If the .war was properly decompressed, only the updated files (i.e. those with new build dates) would be downloaded because Java Web Start would have access to the correct creation dates. thanks, anthony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5
Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: With Tomcat 4.1 released many tomcat developers have been reticent to add new features to its codebase for a number of reasons. All the development going on in Tomcat 5 and wanting to keep the number of codebase's where bug fix patches have to be applied to a minimum. There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2 release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized so that Tomcat 5 can be released. There isn't that much difference in the core of catalina between the Servlet 2.3 and Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase to make it neutral to what Servlet spec is implemented. Then this codebase could be used for future Tomcat 4 and Tomcat 5 development. And we then have a common codebase for applying bug fix patches. This seems to fit in with the direction we have been going where different components are kept in different code bases. naming, connectors, jasper, etc. Comments? This is hard to do (Catalina has never been written to allow facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade. Right, I am aware of that. There isn't that much difference between Servlet 2.3 and Servlet 2.4. Having a common codebase for both would make addition of new non spec related features easier and bug fix patching easier. I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2 from TC 4.1 very very quickly. Do you want a common codebase and some facades for that too ? ;-) No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make sense to do so, also jasper is primarily implementing the JSP spec. Whereas the core of catalina is where all the non spec related features get added. I mentioned Jasper since it was in your list of components in common. Connectors is in common, because of the set of facades used in Coyote. I have no interest in that project, and see no point in trying to extend the life of the old API (given that the new one is quite similar). -0 from me (ie, go ahead if there's some developer interest; of course, implementation details will need to be discussed further). Remy There needs to be someplace where new features can be added to the Tocmat 4 branch. You have been against adding new features to Tomcat 4 head, creating a Tocmat 4.2 branch for developement, and now against making j-t-catalina common to both Tomcat 4 5. I am not against it (I would have been -1). I just think it is not such a great idea, so as it stands, I do not support it and don't plan to help. BTW, I have been regularly adding features to 4.1.x, excluding the features which change existing behavior or lead to API changes (of course, given your recent posts, I guess you don't really know what occurred in tomcat-dev in the last 2 months). Please read the commits and the changelog. If this is what you want then perhaps you should propose a VOTE to freeze all work on Tomcat 4 except for bug fixes. And I mean all work. If the community votes to do that then I will stop asking and perhaps go review the rules for revolutionaries. Glenn, I do not understand what is it that is not in 4.1 that you would want to add. Costin posted a comment the last time you mentioned 4.2 (I think it was one month ago), and I fully agree with it. If you want to make a proposal, including a revolution, please do so. As is, my personal opinion is that having a common j-t-catalina between 4.x and 5.x is not doable from a technical standpoint (given that we have limited development resources), and even not desirable, as some API changes will be needed to make Catalina faster (right now, mapping and auth are really slow, and will need access to j-t-c/util objects to have acceptable speed and GC behavior). Another possibility, given that the API 2.4 is close from 2.3, is that we release j-t-catalina as part of a 4.2 release, and advertise it as supporting servlets 2.3. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper 2 Synchronized JSP compiles
+1, good idea ! Costin Glenn Nielsen wrote: I have some ideas on how invoking the javac compiler for compiling JSP pages can be improved. Currently Jasper 2 uses ant to do compiles from within Tomcat which are synchronized. There are currently several problems. 1. The known javac memory leak. 2. JSP page compiles are synchronized. 3. Jikes currently can't be configured for windows because the windows build of jikes doesn't support -encoding. 4. We may be getting some bug reports related to this problem noted in the Ant documentation for the javac task: Windows Note:When the modern compiler is used in unforked mode on Windows, it locks up the files present in the classpath of the javac task, and does not release them. The side effect of this is that you will not be able to delete or move those files later on in the build. The workaround is to fork when invoking the compiler. Recommendation: Change Jasper 2 so that it tells ant to fork the javac compile. This should remove the need to synchronize the compiles. It will also move java compilation outside of the JVM process Tomcat is running in saving JVM heap memory and reducing GC overhead from objects created for JSP compiles. This could be done by just adding another parameter called fork to the JspServlet paramters. If fork=true ant forks the javac compile and no synchronization is done. The default for fork would be false. Comments? Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Glenn Nielsen wrote: There are a number of different types of realm implementations in org.apache.catalina.realm. These are all solely used for web application realm based authentication except for those which implement the UserDatabase which understands users, groups, and roles and has methods for managing these. Also a UserDatabase can be instantiated as a JNDI resource. It would be nice if all realm implementations could support not only authentication and authorization but also management of users, groups, and roles. And be instantiated as a JNDI resource so it can be provided by the container as a resource to a virtual host. Requiring all realm implementations to support user management is not a good idea. Some realms can do that ( database, our own file, ldap) and some just can't ( passwd, kerberos/radius/tacacs, etc ). I think we have 3 distinct issues: - authorization: I think tomcat needs to expose a single hook and provide a default implementation ( using the mapper - it can also implement jsr115, but it needs to be efficient ) - authentication: again one hook that could be implemented by delegating to apache or use JAAS ( that should be the default - and all current Realms migrated to JAAS plugins ! ) - user management. That should be optional - and probably the best abstraction is JNDI. Besides user/pass/certificate it can store all other user attributes. I think we should be consistent on naming the attributes as in the inetUser LDAP schema ( it will work out-of-box with existing ldap servers and easy to translate to databases, etc ). All UserDatabase impl should be migrated to JNDI providers, and UserDatabase deprecated ( or implemented on top of jndi ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5
Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: With Tomcat 4.1 released many tomcat developers have been reticent to add new features to its codebase for a number of reasons. All the development going on in Tomcat 5 and wanting to keep the number of codebase's where bug fix patches have to be applied to a minimum. There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2 release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized so that Tomcat 5 can be released. There isn't that much difference in the core of catalina between the Servlet 2.3 and Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase to make it neutral to what Servlet spec is implemented. Then this codebase could be used for future Tomcat 4 and Tomcat 5 development. And we then have a common codebase for applying bug fix patches. This seems to fit in with the direction we have been going where different components are kept in different code bases. naming, connectors, jasper, etc. Comments? This is hard to do (Catalina has never been written to allow facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade. Right, I am aware of that. There isn't that much difference between Servlet 2.3 and Servlet 2.4. Having a common codebase for both would make addition of new non spec related features easier and bug fix patching easier. There are new methods in interfaces, etc. It won't be easy, I tried that ( for 2.2/2.3 ). I agree with your idea of having common code between tomcat4 and tomcat5 ( and tomcat3 ) - j-t-c is the best place to do that. If we agree on a hook mechanism at coyote level - i.e. move auth* and other hooks to implement Action or similar interface - then a lot of stuff can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, mapping, security - and we already have connectors and Request. That will also simplify the codebase in j-t-catalina - i.e. the code will be more focused on implementing the servlet spec. There needs to be someplace where new features can be added to the Tocmat 4 branch. You have been against adding new features to Tomcat 4 head, creating a Tocmat 4.2 branch for developement, and now against making j-t-catalina common to both Tomcat 4 5. I think adding features in j-t-c was allways open, and so will be for a potential j-t-module. The reason for the negative votes on 4.2 was simple - if you find 3 people to vote +1 on 4.2 ( i.e. who are interested in working on it ), then I don't see any reason not to do it. I can hardly find time to work on 5.0 ( and thanks to Bill I don't have to worry about 3.3 :-), and we have a lot of stuff on the todo list. That shouldn't stop a 4.2 effort - if it gets at least the minimum 3 committers. I voted -0, I think Remy will change the vote to -0 as well. My -0 means: I don't have time or interest in that, and I would preffer that the features are done in 5.0 - but if 3 committers have this itch I won't stop it. If this is what you want then perhaps you should propose a VOTE to freeze all work on Tomcat 4 except for bug fixes. And I mean all work. If the community votes to do that then I will stop asking and perhaps go review the rules for revolutionaries. I don't see the point of a vote to freeze ( and I think it would be a very bad idea ). Tomcat4 ( and tomcat33 - I think ) can get new features if enough interest exists. They do get new features all the time ( at connector level ). If any of the features in 5.0 gets 3 +1 for porting it back to 4.x - then it should be done. If we move auth* and other stuff to couyte level and use Action - more featurs will be common across versions. You can start a revolution and make any changes you want in proposal/, but you'll still need at least 3 +1 votes to release it (well, you need a majority - but again I don't see why anyone would vote -1 ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper 2 Synchronized JSP compiles
Performance-wise, wouldn't doing javac compilation in another process be much worse than synchronized javac, at least for systems with small number of processors? It would nice if we can have some numbers for comparision. I know javac used to have memory leak, but is it still true for modern compilers, such as the one in JDK 1.4.0? BTW, I am +1 on the proposal. Date: Wed, 04 Dec 2002 09:04:35 -0600 From: Glenn Nielsen [EMAIL PROTECTED] Subject: Jasper 2 Synchronized JSP compiles To: [EMAIL PROTECTED] I have some ideas on how invoking the javac compiler for compiling JSP pages can be improved. Currently Jasper 2 uses ant to do compiles from within Tomcat which are synchronized. There are currently several problems. 1. The known javac memory leak. 2. JSP page compiles are synchronized. 3. Jikes currently can't be configured for windows because the windows build of jikes doesn't support -encoding. 4. We may be getting some bug reports related to this problem noted in the Ant documentation for the javac task: Windows Note:When the modern compiler is used in unforked mode on Windows, it locks up the files present in the classpath of the javac task, and does not release them. The side effect of this is that you will not be able to delete or move those files later on in the build. The workaround is to fork when invoking the compiler. Recommendation: Change Jasper 2 so that it tells ant to fork the javac compile. This should remove the need to synchronize the compiles. It will also move java compilation outside of the JVM process Tomcat is running in saving JVM heap memory and reducing GC overhead from objects created for JSP compiles. This could be done by just adding another parameter called fork to the JspServlet paramters. If fork=true ant forks the javac compile and no synchronization is done. The default for fork would be false. Comments? Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Coyote Connector/Tomcat 4.1.12 flushBuffer()
I hesitate to send this message to this list, but I have had no nibbles on the tomcat-user list. As I noted below, I think there may be a bug in the tomcat4 Coyote Connector code that implements flushBuffer(). Can anyone in the Tomcat developer community comment here or point me to someone that owns the Coyote connectors? Thanks in advance, Randy Watler Finali Corporation We are using Tomcat to serve pages that can take a long time to generate, (in excess of 1 minute). To prevent the browser from retrying to resend the request, we are committing the request using flushBuffer() immediately after setting the response headers. However, it appears that the CoyoteConnector ServletResponse.flushBuffer() implementation does not execute unless the output stream or writer has been written to. We are currently working around this problem by using chunked encoding and pushing some white space out onto the stream. Of course, this does commit the request, but is ugly. The Servlet 2.3 standard seems to imply that flushBuffer() should commit the request and flush the response headers. Furthermore, the code in tomcat4/CoyoteResponse.java appears to attempt to commit the request and flush the stream. When CoyoteResponse.flushBuffer() invokes OutputBuffer.flush(), it attempts to call OutputBuffer.realWriteBytes(null, 0, 0). This almost calls the necessary doWrite() protocol on the underlying Response object, but the cnt 0 argument safety check in OutputBuffer.realWriteBytes():377 prevents it. Is there a bug here or are my eyes missing something subtle, (or obvious)?
DO NOT REPLY [Bug 15009] - Classloading behavior does not follow specification/documentation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15009. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15009 Classloading behavior does not follow specification/documentation [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 19:48 --- What's the opinion about restoring the delegate attribute's original purpose? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper 2 Synchronized JSP compiles
Glenn Nielsen wrote: I have some ideas on how invoking the javac compiler for compiling JSP pages can be improved. Currently Jasper 2 uses ant to do compiles from within Tomcat which are synchronized. There are currently several problems. 1. The known javac memory leak. 2. JSP page compiles are synchronized. 3. Jikes currently can't be configured for windows because the windows build of jikes doesn't support -encoding. 4. We may be getting some bug reports related to this problem noted in the Ant documentation for the javac task: Windows Note:When the modern compiler is used in unforked mode on Windows, it locks up the files present in the classpath of the javac task, and does not release them. The side effect of this is that you will not be able to delete or move those files later on in the build. The workaround is to fork when invoking the compiler. Recommendation: Change Jasper 2 so that it tells ant to fork the javac compile. This should remove the need to synchronize the compiles. It will also move java compilation outside of the JVM process Tomcat is running in saving JVM heap memory and reducing GC overhead from objects created for JSP compiles. This could be done by just adding another parameter called fork to the JspServlet paramters. If fork=true ant forks the javac compile and no synchronization is done. The default for fork would be false. +1. The compilation is not completely thread safe for concurrent requests on the same JSP, BTW (and it's quite complex to make it thread safe - I tried). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15009] - Classloading behavior does not follow specification/documentation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15009. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15009 Classloading behavior does not follow specification/documentation [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 20:04 --- No, it violates the spec wording (and wouldn't work right anyway). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5
Costin Manolache wrote: Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: With Tomcat 4.1 released many tomcat developers have been reticent to add new features to its codebase for a number of reasons. All the development going on in Tomcat 5 and wanting to keep the number of codebase's where bug fix patches have to be applied to a minimum. There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2 release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized so that Tomcat 5 can be released. There isn't that much difference in the core of catalina between the Servlet 2.3 and Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase to make it neutral to what Servlet spec is implemented. Then this codebase could be used for future Tomcat 4 and Tomcat 5 development. And we then have a common codebase for applying bug fix patches. This seems to fit in with the direction we have been going where different components are kept in different code bases. naming, connectors, jasper, etc. Comments? This is hard to do (Catalina has never been written to allow facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade. Right, I am aware of that. There isn't that much difference between Servlet 2.3 and Servlet 2.4. Having a common codebase for both would make addition of new non spec related features easier and bug fix patching easier. There are new methods in interfaces, etc. It won't be easy, I tried that ( for 2.2/2.3 ). I agree with your idea of having common code between tomcat4 and tomcat5 ( and tomcat3 ) - j-t-c is the best place to do that. If we agree on a hook mechanism at coyote level - i.e. move auth* and other hooks to implement Action or similar interface - then a lot of stuff can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, mapping, security - and we already have connectors and Request. That will also simplify the codebase in j-t-catalina - i.e. the code will be more focused on implementing the servlet spec. Yes, probably moving some code would be a nice solution. I'd prefer j-t-modules for that use, personally. There needs to be someplace where new features can be added to the Tocmat 4 branch. You have been against adding new features to Tomcat 4 head, creating a Tocmat 4.2 branch for developement, and now against making j-t-catalina common to both Tomcat 4 5. I think adding features in j-t-c was allways open, and so will be for a potential j-t-module. The reason for the negative votes on 4.2 was simple - if you find 3 people to vote +1 on 4.2 ( i.e. who are interested in working on it ), then I don't see any reason not to do it. I can hardly find time to work on 5.0 ( and thanks to Bill I don't have to worry about 3.3 :-), and we have a lot of stuff on the todo list. That shouldn't stop a 4.2 effort - if it gets at least the minimum 3 committers. I voted -0, I think Remy will change the vote to -0 as well. My -0 means: I don't have time or interest in that, and I would preffer that the features are done in 5.0 - but if 3 committers have this itch I won't stop it. This is a conspiracy ;-) I already voted -0 ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15083] New: - App Deployed by manager can't find properties file in the classpath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15083. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15083 App Deployed by manager can't find properties file in the classpath Summary: App Deployed by manager can't find properties file in the classpath Product: Tomcat 4 Version: 4.1.16 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a JAXB application that I deploy through the manager. The app has a file called jaxb.properties that is loaded by the jaxb runtime. This file is in the war at web-inf/classes/long/class/path/jaxb.properties. When the runtime tries to load the file it fails. If I deploy the same war to tomcat/webapps or if I explode the war into tomcat/webapps/appname then everything works fine -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5
Remy Maucherat wrote: Costin Manolache wrote: Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: With Tomcat 4.1 released many tomcat developers have been reticent to add new features to its codebase for a number of reasons. All the development going on in Tomcat 5 and wanting to keep the number of codebase's where bug fix patches have to be applied to a minimum. There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2 release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized so that Tomcat 5 can be released. There isn't that much difference in the core of catalina between the Servlet 2.3 and Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase to make it neutral to what Servlet spec is implemented. Then this codebase could be used for future Tomcat 4 and Tomcat 5 development. And we then have a common codebase for applying bug fix patches. This seems to fit in with the direction we have been going where different components are kept in different code bases. naming, connectors, jasper, etc. Comments? This is hard to do (Catalina has never been written to allow facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade. Right, I am aware of that. There isn't that much difference between Servlet 2.3 and Servlet 2.4. Having a common codebase for both would make addition of new non spec related features easier and bug fix patching easier. There are new methods in interfaces, etc. It won't be easy, I tried that ( for 2.2/2.3 ). I agree with your idea of having common code between tomcat4 and tomcat5 ( and tomcat3 ) - j-t-c is the best place to do that. If we agree on a hook mechanism at coyote level - i.e. move auth* and other hooks to implement Action or similar interface - then a lot of stuff can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, mapping, security - and we already have connectors and Request. I'm coming, I'm coming with a proposal :-) That will also simplify the codebase in j-t-catalina - i.e. the code will be more focused on implementing the servlet spec. Yes, probably moving some code would be a nice solution. I'd prefer j-t-modules for that use, personally. Euh...I also like the module idea, but I share Remy's view and I doubt about having a single o.a.c workspace for all Servlet specs (starting 2.3 2.4). Without facade, I don't see how we can achieve that. I would prefer having a shared workspace for everything except stuffs related to Servlet. Something like: o.a.catalina (basic web server stuff) o.a.catalina.servletEngine (where the Servlet spec is implemented) or something like that. That probably what Facade meansMaybe I'm dreaming ;-). We should really think of having an extension mechanism where module can be added easily. The solution resides probably by having a consistent hook mechanism... There needs to be someplace where new features can be added to the Tocmat 4 branch. You have been against adding new features to Tomcat 4 head, creating a Tocmat 4.2 branch for developement, and now against making j-t-catalina common to both Tomcat 4 5. I think adding features in j-t-c was allways open, and so will be for a potential j-t-module. The reason for the negative votes on 4.2 was simple - if you find 3 people to vote +1 on 4.2 ( i.e. who are interested in working on it ), then I don't see any reason not to do it. I can hardly find time to work on 5.0 ( and thanks to Bill I don't have to worry about 3.3 :-), and we have a lot of stuff on the todo list. That shouldn't stop a 4.2 effort - if it gets at least the minimum 3 committers. I voted -0, I think Remy will change the vote to -0 as well. My -0 means: I don't have time or interest in that, and I would preffer that the features are done in 5.0 - but if 3 committers have this itch I won't stop it. This is a conspiracy ;-) I already voted -0 ;-) -0. I would prefer concentrating my works on 5.0 since I don't see a major difference between 4.2/5.0. -- Jeanfrancois Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15084] New: - preloaded jsp's have their init method called again on first hit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15084. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15084 preloaded jsp's have their init method called again on first hit Summary: preloaded jsp's have their init method called again on first hit Product: Tomcat 4 Version: 4.1.16 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you have a jsp with a jspInit method, and you preload this jsp, the jspInit method gets called, as it should, upon server startup. But now if you hit that jsp with your web browser, Tomcat calls the jspInit method again. (If you hit the jsp a second time, it's ok, doesn't call jspInit a third time.) I will attach a war file that demonstrates this problem. Simply load this application (test_app.war) and two pages (preload1.jsp, preload2.jsp) each print out that their jspInit methods are called. Then hit the pages (http://host:port/test_app/preload1.jsp, etc.) and see that they print out (to System.out) that their jspInit methods are called once more. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15084] - preloaded jsp's have their init method called again on first hit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15084. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15084 preloaded jsp's have their init method called again on first hit --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 20:51 --- Created an attachment (id=4052) War file for test application -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15032. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 21:03 --- *** This bug has been marked as a duplicate of 14797 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14797] - Request headers are broken after invoking pageContext.include()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14797. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14797 Request headers are broken after invoking pageContext.include() [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 21:03 --- *** Bug 15032 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15086] - System.out from destroy goes to different place than init message
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15086. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15086 System.out from destroy goes to different place than init message [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Other |Windows XP Platform|Other |PC -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi SSIServlet.java
amyroh 2002/12/04 13:09:08
Modified:catalina/src/share/org/apache/catalina Globals.java
catalina/src/share/org/apache/catalina/servlets
CGIServlet.java
catalina/src/share/org/apache/catalina/ssi SSIServlet.java
Log:
Fix for SSI normal configuration which invokes a CGI script.
Patch submitted by Nick Bauman [EMAIL PROTECTED].
Revision ChangesPath
1.45 +15 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java
Index: Globals.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- Globals.java 23 Sep 2002 00:16:35 - 1.44
+++ Globals.java 4 Dec 2002 21:09:07 - 1.45
@@ -266,6 +266,17 @@
public static final String SESSION_PARAMETER_NAME = jsessionid;
+ /**
+* The servlet context attribute under which we store a flag used
+* to mark this request as having been processed by the SSIServlet.
+* We do this because of the pathInfo mangling happening when using
+* the CGIServlet in conjunction with the SSI servlet. (value stored
+* as an object of type String)
+*/
+public static final String SSI_FLAG_ATTR =
+org.apache.catalina.ssi.SSIServlet;
+
+
/**
* The request attribute under which we forward an HTTP status code
* (as an object of type Integer) to an error page.
1.11 +13 -8
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
Index: CGIServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- CGIServlet.java 22 Nov 2002 21:51:14 - 1.10
+++ CGIServlet.java 4 Dec 2002 21:09:07 - 1.11
@@ -967,7 +967,12 @@
String[] sCGINames;
-sPathInfoOrig = this.pathInfo;
+if (null != req.getAttribute(Globals.SSI_FLAG_ATTR)) {
+// invoked by SSIServlet, which eats our req.getPathInfo() data
+sPathInfoOrig = (String) req.getAttribute(Globals.PATH_INFO_ATTR);
+} else {
+sPathInfoOrig = this.pathInfo;
+}
sPathInfoOrig = sPathInfoOrig == null ? : sPathInfoOrig;
sPathTranslatedOrig = req.getPathTranslated();
1.2 +35 -28
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
Index: SSIServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SSIServlet.java 26 May 2002 00:00:55 - 1.1
+++ SSIServlet.java 4 Dec 2002 21:09:08 - 1.2
@@ -95,6 +95,7 @@
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.apache.catalina.Globals;
/**
* Servlet to process SSI requests within a webpage.
@@ -106,6 +107,7 @@
* @version $Revision$, $Date$
*/
public class SSIServlet extends HttpServlet {
+
/** Debug level for this servlet. */
protected int debug = 0;
@@ -217,14 +219,14 @@
path.toUpperCase().startsWith(/META-INF) ) {
res.sendError(res.SC_NOT_FOUND, path);
- log( Can't serve file: + path );
+log( Can't serve file: + path );
return;
}
-
- URL resource = servletContext.getResource(path);
+
+URL resource = servletContext.getResource(path);
if (resource==null) {
res.sendError(res.SC_NOT_FOUND, path);
- log( Can't find file: + path );
+log( Can't find file: + path );
return;
}
@@ -234,37 +236,42 @@
res.setDateHeader(Expires, (
new java.util.Date()).getTime() + expires.longValue() * 1000);
}
-
- processSSI( req, res, resource );
+
+req.setAttribute(Globals.SSI_FLAG_ATTR,true);
+processSSI( req, res, resource );
}
protected void processSSI( HttpServletRequest req,
-HttpServletResponse res,
-URL resource ) throws IOException {
- SSIExternalResolver ssiExternalResolver = new SSIServletExternalResolver(
this, req, res,
-
Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5
Jeanfrancois Arcand wrote: This is hard to do (Catalina has never been written to allow facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade. Euh...I also like the module idea, but I share Remy's view and I doubt about having a single o.a.c workspace for all Servlet specs (starting 2.3 2.4). Without facade, I don't see how we can achieve that. I would prefer having a shared workspace for everything except stuffs related to Servlet. Something like: o.a.catalina (basic web server stuff) o.a.catalina.servletEngine (where the Servlet spec is implemented) Well, if you move auth* and session to modules and use Action ( or something like that ) for hooks - catalina will be the facade and have all the Servlet spec implementation. And all modules should work with any version of tomcat that uses coyote ( i.e. 3.3, 4.0, 4.1, 5.0, etc ). If we also move ( or replace ) some of the 3.3 modules ( for example the mapper, or auth* ) - then 3.3 core will also act as a facade. There is no need for a servletEngine package, it's much better to go the other way around and move ahead with moving modules out. We'll need to keep the existing modules in - probably as small wrappers around the new modules - for backward compatibility. So only new modules or existing module implementation will need to move ( and not all at once ). Probably a backward-compat module could be used for all the code that is deprecated but needs to be around for backward compat. or something like that. That probably what Facade meansMaybe I'm dreaming ;-). We should really think of having an extension mechanism where module can be added easily. The solution resides probably by having a consistent hook mechanism... Part of the solution, yes. The other part is ( IMO ) JNDI/JMX. JNDI+JMX will take care of configuring ( you can't do it with JMX alone - you also need JNDI to locate the objects ). A module will be an mbean that also implements the hook interface. We can theoretically use JMX alone - without a hook interface and using invoke() - but that would hurt performance. To add a module - you can use any JMX mechanism ( including mlet ) _and_ register the module in a catalina:/jmx/OBJECT_NAME jndi. Tomcat will listen for object notifications - and pick up all modules and configure them based on the name. The JNDI/JMX name of each module is very important - as it contains the position where it must be inserted. It is quite simple. And it can be implemented without affecting too much the existing code - it'll be just another module. We'll need to add some JMX awareness into the code, but it seems the proposal to require jmx will pass. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
How to print to logs?
Hi, i'm creating JSP's in Tomcat, and i want to print stuff out to the log. I tried system.out.println (...), but it doesn't work. Do any of you know how I can do this? Thanks in advance, -Mike -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15088] New: - org.apache.jasper.servlet.JspServlet doesn't close a FileInputStream.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15088. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15088 org.apache.jasper.servlet.JspServlet doesn't close a FileInputStream. Summary: org.apache.jasper.servlet.JspServlet doesn't close a FileInputStream. Product: Tomcat 4 Version: 4.0.6 Final Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] As I know, JspServlet is responsible for checking if jsp should be reloaded or not, etc. I found that JspServlet is checking it by opening the jsp file input stream. In the loadJSP() method of JspServlet, // First check if the requested JSP page exists, to avoid creating // unnecessary directories and files. if (context.getResourceAsStream(jspUri) == null) throw new FileNotFoundException(jspUri); context.getResourceAsStream() returns a InputStream object for the jsp file. I think this routine would call `org.apache.catalina.core.ApplicationContext''s getResourceAsStream() method, and then call `org.apache.naming.resources.FileDirContext''s `streamContent()' method, which would return a FileInputStream object. If my inference is true, then `if (context.getResourceAsStream(jspUri) == null)' code has a problem. Because this code doesn't close the FileInputStream object explicitly, the file handle might be monitored only by garbage collector. This can be a problem in case that the limit count of open files is set on a system. Every request can open a jsp stream, so the open file count increases. I don't think it's efficient to open the stream to check whether the jsp should be reloaded or not. Thanks. (My opinion could be based on misunderstandings.) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] SSI-CGI fix in Tomcat 4.1.12
Currently under Tomcat 4.1.12 SSI normal configuration which invokes a
CGI script does not work. The reason for this is pretty obvious: The SSI
servelet uses the pathInfo (PATH_INFO) value and calls the request
dispatcher for any resources needed. The request dispatcher eats the
pathInfo value and the CGI servlet can't find the CGI program, because
it relies on pathInfo to tell it where the script is.
I made minor changes to three files in the current 4.1.12 distro
to solve this problem. The strategy is thus: SSI-invoked resources flag
the request with an attibute. When CGI servlet finally gets the request
dispached, he checks whether SSI servlet invoked the resource via said
attribute. If this is the case, he ignores the request.getPathInfo()
method in favor of an already-present attribute on the request which
already has the PATH_INFO environment value in it.
Voila, everything works now. Diffs attached.
Nick Bauman
Software Engineer
Cortexity Development
3600 N. Dupont
Minneapolis, MN
55412
M: 612-232-7120
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/Globals.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/Globals.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/Globals.java
2002-09-23
03:24:20.0 -0600
+++
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/Globals.java
2002-12-03
20:48:00.0 -0600
@@ -290,5 +290,13 @@
public static final String WORK_DIR_ATTR =
javax.servlet.context.tempdir;
-
+/**
+ * The servlet context attribute under which we store a flag used
+ * to mark this request as having been processed by the SSIServlet.
+ * We do this because of the pathInfo mangling happening when using
+ * the CGIServlet in conjunction with the SSI servlet. (value stored
+ * as an object of type String)
+ */
+public static final String SSI_FLAG_ATTR =
+org.apache.catalina.ssi.SSIServlet;
}
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
2002-09-23
03:24:18.0 -0600
+++
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
2002-12-03
20:54:32.0 -0600
@@ -966,8 +966,12 @@
String sCGIName = null;
String[] sCGINames;
-
-sPathInfoOrig = this.pathInfo;
+if(null != req.getAttribute(Globals.SSI_FLAG_ATTR)) {
+// invoked by SSIServlet, which eats our req.getPathInfo() data
+sPathInfoOrig = (String) req.getAttribute(Globals.PATH_INFO_ATTR);
+} else {
+sPathInfoOrig = this.pathInfo;
+}
sPathInfoOrig = sPathInfoOrig == null ? : sPathInfoOrig;
sPathTranslatedOrig = req.getPathTranslated();
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
2002-09-23
03:24:18.0 -0600
+++
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
2002-12-03
19:44:06.0 -0600
@@ -64,38 +64,24 @@
package org.apache.catalina.ssi;
+import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
-import java.io.OutputStream;
-import java.io.OutputStreamWriter;
-import java.io.BufferedInputStream;
-import java.io.BufferedReader;
-import java.io.ByteArrayOutputStream;
import java.io.PrintWriter;
-import java.io.Reader;
import java.io.StringWriter;
-import java.io.Writer;
import java.net.URL;
import java.net.URLConnection;
-import java.net.URLDecoder;
-import java.util.ArrayList;
-import java.util.Collection;
import java.util.Date;
-import java.util.Enumeration;
-import java.util.HashMap;
-import java.util.Locale;
-import java.text.SimpleDateFormat;
-import java.util.StringTokenizer;
-import java.util.TimeZone;
-import javax.servlet.RequestDispatcher;
-import javax.servlet.ServletException;
+
import javax.servlet.ServletContext;
-import javax.servlet.ServletOutputStream;
+import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.apache.catalina.Globals;
+
/**
* Servlet to process SSI requests within a webpage.
* Mapped to a path from within web.xml.
@@ -234,7 +220,7 @@
res.setDateHeader(Expires, (
new java.util.Date()).getTime() + expires.longValue() * 1000);
}
-
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote ActionCode.java
costin 2002/12/04 15:33:28
Modified:coyote/src/java/org/apache/coyote ActionCode.java
Log:
A small change to ActionCode - add an int id to each action. It can
be used in switch().
Revision ChangesPath
1.11 +34 -25
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java
Index: ActionCode.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ActionCode.java 24 Nov 2002 11:56:14 - 1.10
+++ ActionCode.java 4 Dec 2002 23:33:27 - 1.11
@@ -70,78 +70,87 @@
// -- Constants
-public static final ActionCode ACTION_ACK = new ActionCode();
+public static final ActionCode ACTION_ACK = new ActionCode(1);
-public static final ActionCode ACTION_CLOSE = new ActionCode();
+public static final ActionCode ACTION_CLOSE = new ActionCode(2);
-public static final ActionCode ACTION_COMMIT = new ActionCode();
+public static final ActionCode ACTION_COMMIT = new ActionCode(3);
/**
* A flush() operation originated by the client ( i.e. a flush() on
* the servlet output stream or writer, called by a servlet ).
*/
-public static final ActionCode ACTION_CLIENT_FLUSH = new ActionCode();
+public static final ActionCode ACTION_CLIENT_FLUSH = new ActionCode(4);
-public static final ActionCode ACTION_CUSTOM = new ActionCode();
+public static final ActionCode ACTION_CUSTOM = new ActionCode(5);
-public static final ActionCode ACTION_RESET = new ActionCode();
+public static final ActionCode ACTION_RESET = new ActionCode(6);
-public static final ActionCode ACTION_START = new ActionCode();
+public static final ActionCode ACTION_START = new ActionCode(7);
-public static final ActionCode ACTION_STOP = new ActionCode();
+public static final ActionCode ACTION_STOP = new ActionCode(8);
-public static final ActionCode ACTION_WEBAPP = new ActionCode();
+public static final ActionCode ACTION_WEBAPP = new ActionCode(9);
-
-/**
- * Hook called after request, but before recycling. Can be used
- * for logging, to update counters, custom cleanup - the request
- * is still visible
- */
-public static final ActionCode ACTION_POST_REQUEST = new ActionCode();
+/** Hook called after request, but before recycling. Can be used
+for logging, to update counters, custom cleanup - the request
+is still visible
+*/
+public static final ActionCode ACTION_POST_REQUEST = new ActionCode(10);
/**
* Callback for lazy evaluation - extract the remote host name.
*/
public static final ActionCode ACTION_REQ_HOST_ATTRIBUTE =
-new ActionCode();
+new ActionCode(11);
/**
- * Callback for lazy evaluation - extract the remote host address.
+ * Callback for lazy evaluation - extract the SSL-related attributes.
*/
-public static final ActionCode ACTION_REQ_HOST_ADDR_ATTRIBUTE =
-new ActionCode();
-
+public static final ActionCode ACTION_REQ_HOST_ADDR_ATTRIBUTE = new
ActionCode(12);
/**
* Callback for lazy evaluation - extract the SSL-related attributes.
*/
-public static final ActionCode ACTION_REQ_SSL_ATTRIBUTE = new ActionCode();
+public static final ActionCode ACTION_REQ_SSL_ATTRIBUTE = new ActionCode(13);
+
+
+/** Chain for request creation. Called each time a new request is created
+( requests are recycled ).
+ */
+public static final ActionCode ACTION_NEW_REQUEST = new ActionCode(14);
/**
* Callback for lazy evaluation - extract the SSL-certificate
* (including forcing a re-handshake if necessary)
*/
-public static final ActionCode ACTION_REQ_SSL_CERTIFICATE = new ActionCode();
+public static final ActionCode ACTION_REQ_SSL_CERTIFICATE = new ActionCode(14);
// --- Constructors
-
+int code;
/**
* Private constructor.
*/
-private ActionCode() {
+private ActionCode(int code) {
+this.code=code;
+}
+
+/** Action id, useable in switches and table indexes
+ */
+public int getCode() {
+return code;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15002] - Tag files in different directories not belonging to different tag libraries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15002 Tag files in different directories not belonging to different tag libraries --- Additional Comments From [EMAIL PROTECTED] 2002-12-05 00:00 --- Looking into this. Problem must be related to file path separators on Windows. Examples work fine on Solaris. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [newbie] where do I get TagFileInfo, etc.?
It's in jakarta-servletapi-4, which IS mentioned in BUILDING_txt. Make sure that you have servlet.home defined correctly in build.properties. Date: Wed, 04 Dec 2002 17:39:25 -0800 From: Michael [EMAIL PROTECTED] Subject: [newbie] where do I get TagFileInfo, etc.? To: [EMAIL PROTECTED] I'm trying to build jakarta-tomcat-4.0, but it wanted jakarta-tomcat-jasper (not mentioned in BUILDING.txt). I checked that out, but it's build fails with undefined symbols. Where can I find these? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java
luehe 2002/12/04 18:27:35
Modified:jasper2/src/share/org/apache/jasper
JspCompilationContext.java
jasper2/src/share/org/apache/jasper/servlet
JspServletWrapper.java
Log:
Fix for 15002 (Tag files in different directories not belonging to
different tag libraries) on Windows.
Revision ChangesPath
1.26 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java
Index: JspCompilationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- JspCompilationContext.java28 Nov 2002 04:18:07 - 1.25
+++ JspCompilationContext.java5 Dec 2002 02:27:35 - 1.26
@@ -447,7 +447,7 @@
if (isTagFile) {
jspPath = tags/
- + tagInfo.getTagClassName().replace('.', File.separatorChar)
+ + tagInfo.getTagClassName().replace('.', '/')
+ .java;
} else {
String dirName = getJspFile();
1.22 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java
Index: JspServletWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- JspServletWrapper.java28 Nov 2002 04:18:08 - 1.21
+++ JspServletWrapper.java5 Dec 2002 02:27:35 - 1.22
@@ -155,7 +155,7 @@
servletContext, this, rctxt,
tagFileJars);
ctxt.createOutdir(/tags/
- + tagInfo.getTagClassName().replace('.',
File.separatorChar));
+ + tagInfo.getTagClassName().replace('.', '/'));
}
public JspCompilationContext getJspEngineContext() {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/tagplugin TagPluginContext.java
kinman 2002/12/04 18:39:03
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Node.java TagPluginManager.java
jasper2/src/share/org/apache/jasper/compiler/tagplugin
TagPluginContext.java
Log:
- More updates on tag plugin work.
Revision ChangesPath
1.136 +118 -74
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- Generator.java3 Dec 2002 23:49:46 - 1.135
+++ Generator.java5 Dec 2002 02:39:03 - 1.136
@@ -1483,21 +1483,14 @@
public void visit(Node.CustomTag n) throws JasperException {
- Hashtable handlerInfosByShortName = (Hashtable)
- handlerInfos.get(n.getPrefix());
- if (handlerInfosByShortName == null) {
- handlerInfosByShortName = new Hashtable();
- handlerInfos.put(n.getPrefix(), handlerInfosByShortName);
- }
- TagHandlerInfo handlerInfo = (TagHandlerInfo)
- handlerInfosByShortName.get(n.getShortName());
- if (handlerInfo == null) {
- handlerInfo = new TagHandlerInfo(n,
- n.getTagHandlerClass(),
- err);
- handlerInfosByShortName.put(n.getShortName(), handlerInfo);
+ // Use plugin to generate more efficient code if there is one.
+ if (n.useTagPlugin()) {
+ generateTagPlugin(n);
+ return;
}
+ TagHandlerInfo handlerInfo = getTagHandlerInfo(n);
+
// Create variable names
String baseVar = createTagVarName(n.getName(), n.getPrefix(),
n.getShortName());
@@ -1879,6 +1872,48 @@
}
}
+ public void visit(Node.GenAttribute n) throws JasperException {
+ Node.CustomTag tag = n.getTag();
+Node.JspAttribute[] attrs = tag.getJspAttributes();
+for (int i=0; iattrs.length; i++) {
+ if (attrs[i].getName() == n.getName()) {
+ out.print(evaluateAttribute(getTagHandlerInfo(tag),
+ attrs[i], tag, null));
+ break;
+ }
+ }
+ }
+
+ private TagHandlerInfo getTagHandlerInfo(Node.CustomTag n)
+ throws JasperException {
+Hashtable handlerInfosByShortName = (Hashtable)
+handlerInfos.get(n.getPrefix());
+if (handlerInfosByShortName == null) {
+handlerInfosByShortName = new Hashtable();
+handlerInfos.put(n.getPrefix(), handlerInfosByShortName);
+}
+TagHandlerInfo handlerInfo = (TagHandlerInfo)
+handlerInfosByShortName.get(n.getShortName());
+if (handlerInfo == null) {
+handlerInfo = new TagHandlerInfo(n,
+ n.getTagHandlerClass(),
+ err);
+handlerInfosByShortName.put(n.getShortName(), handlerInfo);
+}
+ return handlerInfo;
+ }
+
+ private void generateTagPlugin(Node.CustomTag n)
+ throws JasperException {
+ if (n.getAtSTag() != null) {
+ n.getAtSTag().visit(this);
+ }
+ visitBody(n);
+ if (n.getAtETag() != null) {
+ n.getAtETag().visit(this);
+ }
+ }
+
private void generateCustomStart(Node.CustomTag n,
TagHandlerInfo handlerInfo,
String tagHandlerVar,
@@ -2336,6 +2371,70 @@
}
}
+ private String evaluateAttribute(TagHandlerInfo handlerInfo,
+ Node.JspAttribute attr,
+ Node.CustomTag n,
+ String tagHandlerVar)
+ throws JasperException {
+
+ String attrValue = attr.getValue();
+ if (attrValue == null) {
+if(attr.isNamedAttribute()) {
+if(n.checkIfAttributeIsJspFragment(attr.getName())) {
+// XXX - no need to generate temporary variable here
+attrValue = generateNamedAttributeJspFragment(
+attr.getNamedAttributeNode(),
+
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JspUtil.java
luehe 2002/12/04 18:41:53 Modified:jasper2/src/share/org/apache/jasper/compiler JspUtil.java Log: Added javadocs Revision ChangesPath 1.26 +9 -3 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java Index: JspUtil.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- JspUtil.java 2 Dec 2002 20:09:28 - 1.25 +++ JspUtil.java 5 Dec 2002 02:41:53 - 1.26 @@ -756,6 +756,12 @@ /** * Gets the fully-qualified class name of the tag handler corresponding to * the given tag file path. + * + * @param path Tag file path + * @param err Error dispatcher + * + * @return Fully-qualified class name of the tag handler corresponding to + * the given tag file path */ public static String getTagHandlerClassName(String path, ErrorDispatcher err) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpServletResponseFacade.java
billbarker2002/12/04 22:42:35
Modified:src/facade22/org/apache/tomcat/facade
HttpServletResponseFacade.java
Log:
Port patch for encoding an empty string from TC4 branch.
Revision ChangesPath
1.30 +17 -7
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java
Index: HttpServletResponseFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- HttpServletResponseFacade.java4 Jul 2002 04:09:30 - 1.29
+++ HttpServletResponseFacade.java5 Dec 2002 06:42:35 - 1.30
@@ -142,10 +142,15 @@
* part of response, but session code.
*/
public String encodeRedirectURL(String location) {
- if (isEncodeable(toAbsolute(location)))
+ String absolute = toAbsolute(location);
+ if (isEncodeable(absolute)) {
+ if( .equals(location) ) {
+ location = absolute;
+ }
return (toEncoded(location, response.getRequest().getSession(false)));
- else
+ } else {
return (location);
+ }
}
/**
@@ -156,10 +161,15 @@
}
public String encodeURL(String url) {
- if (isEncodeable(toAbsolute(url)))
+ String absolute = toAbsolute(url);
+ if (isEncodeable(absolute)) {
+ if( .equals(url) ) {
+ url = absolute;
+ }
return (toEncoded(url, response.getRequest().getSession(false)));
- else
+ } else {
return (url);
+ }
}
/**
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt
billbarker2002/12/04 22:51:04 Modified:.RELEASE-NOTES-3.3.2.txt Log: Document change to encodeURL. Revision ChangesPath 1.15 +3 -1 jakarta-tomcat/RELEASE-NOTES-3.3.2.txt Index: RELEASE-NOTES-3.3.2.txt === RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.2.txt,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- RELEASE-NOTES-3.3.2.txt 31 Oct 2002 06:41:37 - 1.14 +++ RELEASE-NOTES-3.3.2.txt 5 Dec 2002 06:51:04 - 1.15 @@ -63,6 +63,8 @@ be restored by setting the secureCookie=false attribute on the SessionId element in server.xml. + Fix the handling of response.encodeURL() to conform to the w3 spec. + Jasper: Bug No. Description -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
