cvs commit: jakarta-tomcat-5 tomcat.nsi
remm2002/11/12 00:02:24
Modified:.tomcat.nsi
Log:
- Update to NSIS nightly.
Revision ChangesPath
1.15 +8 -12 jakarta-tomcat-5/tomcat.nsi
Index: tomcat.nsi
===
RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- tomcat.nsi7 Nov 2002 16:26:57 - 1.14
+++ tomcat.nsi12 Nov 2002 08:02:24 - 1.15
-12,14 +12,14
;
;Configuration
- !define MUI_INSTALLOPTIONS
-
!define MUI_LICENSEPAGE
!define MUI_COMPONENTSPAGE
!define MUI_DIRECTORYPAGE
!define MUI_ABORTWARNING
+
!define MUI_UNINSTALLER
+ !define MUI_WINDOWTITLE
!define MUI_CUSTOMPAGECOMMANDS
!define TEMP1 $R0
-247,23 +247,19
!insertmacro MUI_INSTALLOPTIONS_WRITETITLE config.ini $(TEXT_CONF_PAGETITLE)
!insertmacro MUI_INSTALLOPTIONS_WRITETITLE jvm.ini $(TEXT_JVM_PAGETITLE)
- ;Abort warnings for Install Options dialogs
- !insertmacro MUI_INSTALLOPTIONS_WRITEABORTWARNING config.ini
- !insertmacro MUI_INSTALLOPTIONS_WRITEABORTWARNING jvm.ini
-
FunctionEnd
Function SetChooseJVM
- !insertmacro MUI_HEADER_TEXT $(TEXT_JVM_TITLE) $(TEXT_JVM_SUBTITLE)
+ !insertmacro MUI_HEADER_TEXT $(TEXT_JVM_TITLE) $(TEXT_JVM_SUBTITLE)
Call findJavaPath
Pop $3
!insertmacro MUI_INSTALLOPTIONS_WRITE jvm.ini Field 2 State $3
- !insertmacro MUI_INSTALLOPTIONS_SHOW jvm.ini
+ !insertmacro MUI_INSTALLOPTIONS_DISPLAY jvm.ini
FunctionEnd
Function SetConfiguration
- !insertmacro MUI_HEADER_TEXT $(TEXT_CONF_TITLE) $(TEXT_CONF_SUBTITLE)
- !insertmacro MUI_INSTALLOPTIONS_SHOW config.ini
+ !insertmacro MUI_HEADER_TEXT $(TEXT_CONF_TITLE) $(TEXT_CONF_SUBTITLE)
+ !insertmacro MUI_INSTALLOPTIONS_DISPLAY config.ini
FunctionEnd
Function .onInstSuccess
-275,7 +271,7
;
;Descriptions
-!insertmacro MUI_FUNCTIONS_DESCRIPTION_START
+!insertmacro MUI_FUNCTIONS_DESCRIPTION_BEGIN
!insertmacro MUI_DESCRIPTION_TEXT ${SecTomcat} $(DESC_SecTomcat)
!insertmacro MUI_DESCRIPTION_TEXT ${SecTomcatCore} $(DESC_SecTomcatCore)
!insertmacro MUI_DESCRIPTION_TEXT ${SecTomcatService} $(DESC_SecTomcatService)
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [4.1.15] Tag tomorrow
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, November 11, 2002 11:56 PM Subject: Re: [4.1.15] Tag tomorrow Glenn Nielsen wrote: Doesn't this require a vote? No. The vote is when the milestone is then publicly released. Otherwise, it's like a nightly, and allows getting some testing. Better would be to get the nightlies back on line (I don't have an account on nagoya, so I can't do it). Amy has already posted a show-stopper for 4.1.15, so at the moment, my vote is Beta. Rémy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [4.1.15] Tag tomorrow
Bill Barker wrote: Glenn Nielsen wrote: Doesn't this require a vote? No. The vote is when the milestone is then publicly released. Otherwise, it's like a nightly, and allows getting some testing. Better would be to get the nightlies back on line (I don't have an account on nagoya, so I can't do it). Amy has already posted a show-stopper for 4.1.15, so at the moment, my vote is Beta. The admin webapp works fine for me, if that's the showstopper you are talking about. Releasing 4.1.15 as beta might be a good idea anyway. There are lots of changes over 4.1.12. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-4.0 build.properties.sample
Bill Barker wrote: jfarcand2002/11/11 20:16:59 Modified:.build.properties.sample Log: Update to Xerces 2.2.1. Not working any different than 2.2.0 for me. :-( 2002-11-11 22:46:32 action: null org.xml.sax.SAXParseException: The string -- is not permitted within comments. Then it still has the same problem with Struts 1.0. I'll keep Xerces 2.1.0 for Tomcat 4.1.x. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 4663] - Broken Pipe under some load
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=4663. 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=4663 Broken Pipe under some load --- Additional Comments From [EMAIL PROTECTED] 2002-11-12 09:15 --- I am using tomcat with jboss and is experiencing the same error. I see it more often when the load increases. Our application is running on the intranet and there has not been reported any problems with the network so I don't believe that is the problem. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Servlet Spec interpretation FORM-based authentication
This seems another aspect of issue
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279 ... there are
some work in progress on that one. There's even a patch, check it out.
Martin
-Original Message-
From: Algirdas P. Veitas [mailto:aveitas;mail.allesta.com]
Sent: 12 November 2002 04:57
To: [EMAIL PROTECTED]
Subject: Servlet Spec interpretation FORM-based authentication
Folks,
I am running into an issue with FORM-based authentication
using 4.1.12 (and 4.0.4). It seems as if the implementation
is not in line with the 2.3 Servlet Specification. Specifically, the
Servlet Spec states:
SRV.12.5.3 Form Base Authentication
--snip--
J2EE.12.5.3.1 Login Form Notes
--snip--
If the form based login is invoked because of an HTTP request, the
original
request parameters must be preserved by the container for use if, on
successful authentication, it redirects the call to the requested
resource.
It seems as if the request parameters are not being preserved by the
container. After a successful login the container forwards me to the
target
URL (a JSP page). The JSP page executes the following code:
Enumeration params = request.getParameterNames();
while (params.hasMoreElements())
{
String paramKey = (String)params.nextElement();
String paramVal = request.getParameter(paramKey);
System.out.println(paramKey + = + paramKey); }
which I would expect to atleast see printed out:
j_username = some val
j_password = some val 2
but in fact these request parameters are not printed out and thus not
part of
the request.
A bit of digging in the source revealed that in the method
authenticate(HttpRequest,HttpResponse,LoginConfig)
of class org.apache.catalina.authenticator.FormAuthenticator, the code
is
executing HttpResponse.sendRedirect(String url) in order to forward the
user
to the appropriate page. A sendRedirect() will wipe out all of the
original
request parameters.
I think in order to preserve the parameters the sendRedirect() needs to
be
replaced by HttpRequest.getServletDispatcher().forward().
Has anyone else seen this behavior and is my claim valid?
Thanks,
Al
--
Open WebMail Project (http://openwebmail.org)
--
To unsubscribe, e-mail:
mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: ServletOutputStreamWrapper
Actually, a good example of a ServletInputStream subclass with a read() implementation would be helpful too. I am trying to find al lthese examples in the source, but am haviong limited success tracking down the appropriate classes On Tue, 2002-11-12 at 10:13, Paul Hunnisett wrote: The main reason I was looking at this class in the first place was to try to find a good way of overriding the write(int) method of OutputStream in a server context. Is there another class which extends ServletOutputStream and would give me a more real world example? On Tue, 2002-11-12 at 00:03, Dan Sandberg wrote: Hi Paul. That class is specific to the server-side include code, so the server doesn't need to know anything about the writeTo method. Basically, the ServletOutputStreamWrapper is used so that we can capture the result of Tomcat processing a page, so that we may include the contents of one page within another. o.a.c.servlets.SsiInvokerServlet calls the writeTo method. If you have any questions after looking at the source-code, let us know. Is anyone familiar with this class? Yup. -Dan Paul Hunnisett wrote: I have been examining the source code for org.apache.catalina.util.ssi.ServletOutputStreamWrapper and I discovered a writeTo() method that writes the current buffer to the OutputStream. What I can't quite see is how this method would be called. It is not part of the servlet spec, so the web application won't be calling it. So I assume that the server calls it, but how does the server know when to write the buffer out? Any information would be appreciated. Paul Hunnisett -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[Q] How to merge 2 web.xml files?
Hi, I would like to merge 2 web.xml files programmatically and generate a new web.xml. Do you know if there's some library or code that already does this? I know Tomcat has a global web.xml. Is there some code I could use from Tomcat? Does anyone has a DVSL/XSL/other stylesheet for making this transformation? Thanks a lot -Vincent -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
Remy Maucherat [EMAIL PROTECTED] wrote: I'd also like to point out that the servlet API changes are very limited, and it will be possible to use Tomcat 5.0 with the Jasper from Tomcat 4.1. So I think major new features should go in the 5.0 codebase. What is a realistic timeline for 5.0 being released? I'm now independent and unemployed, so I'm not aware of the Sun schedules for the spec anymore :-P Probably within 3-6 months given J2EE 1.4 is in beta. The rule is we cannot release a stable version of 5.0.x until the specs are final. Regarding servlets, the JSR-154 Spec Lead did not inform us yet of any deadline... I know that Sun wants to have it out soonish, but there are still quite few bits and bobs to sort out (like friggin' schema). If you have questions regarding JSR-154 (requirements/info/...) contact me as I'm still the official representative for the ASF on the JCP expert group. Have fun... Pier -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [4.1.15] Tag tomorrow
Remy Maucherat wrote: Glenn Nielsen wrote: Doesn't this require a vote? No. The vote is when the milestone is then publicly released. Otherwise, it's like a nightly, and allows getting some testing. A nightly does not get announced publicly with a revision number. The previous 4.1.13 and 4.1.14 milestone releases you did were done and announced to the public without a vote. IMO, bumping the revision number and announcing to the public a release (no matter what name is given to it) requires a vote. Perhaps it would be better to get the nightly builds working again so changes can be tested by those interested in them by downloading the nightly. Regards, Glenn -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
Remy Maucherat wrote: Glenn Nielsen wrote: Remy Maucherat wrote: Bill Barker wrote: I think we have too many dev branches already, and this is causing maintenance problems. I'd like to have those things go in either 4.1 or 5.0. Esp the jspc refactoring ;-) jspc is currently broken in 4.1 and not really usable to a normal Tomcat user, it needs to be fixed in 4.1.x. Please :) Doing development in the 4.1 branch would limit the ability to do bug fix releases on 4.1. Perhaps if an effort to resolve all know 4.1 bugs was made we would see the number of bug reports for 4.1 decrease. That would make a 4.2 development branch easier to do while still maintaining 4.1. We could try to keep the time 4.2 is in development to a minimum, perhaps a couple of months. Once 4.2 was released the 4.1 branch could be retired with all bug fixes going in 4.2 (HEAD). Why not wait and see if there are more signficant changes/new features proposed for a possible 4.2 release. And if there are committers willing to assist porting bug fixes between the branches while 4.2 is under development. So far, I'm not in favor of a 4.2 branch, as I would like to avoid fragmentation. If: - 4.1 is put in a security-fix only mode - all new features are ported to 5.0 - all relevant bugfixes are ported to 5.0 Then fragmentation cannot happen, and I would be in favor of it, and could maybe RM it (since I wouldn't be doing anything on 4.1), if 4.2 is proven to be useful. On the features list: - A SecurityManager XML Policy file that allows secure delegation to web applications for setting their own policies (within a sandbox): as far as I can remember, this recieved negative feedback. This is sort of something which IMHO should be part of a future JDK. I don't really see what it has to do with Tomcat (except if would be a useful JDK feature to use). It could be developped in the Commons sandbox if you're interested. - jspc: it should be done in 4.1 (it is not really usable at the moment unless you know the code). Even if it's a major refactoring, we have to do it there *or* we have to remove the feature for now. Given the different view everyone has on jspc (and me who doesn't really care about what it does ;-) ), I think someone should start a poll on which committers would vote. - Using JMX to instrument Tomcat for production runtime monitoring: I have no idea what you want to do. I think it might be better in 5.0. - Audit the SecurityManager web application sandbox: This has been done in 5.0, and the result could be ported to 4.1, esp if the sandbox is somewhat deficient. I'd also like to point out that the servlet API changes are very limited, and it will be possible to use Tomcat 5.0 with the Jasper from Tomcat 4.1. So I think major new features should go in the 5.0 codebase. Rémy What is a realistic timeline for 5.0 being released? I'm now independent and unemployed, so I'm not aware of the Sun schedules for the spec anymore :-P Probably within 3-6 months given J2EE 1.4 is in beta. The rule is we cannot release a stable version of 5.0.x until the specs are final. Rémy If I understand correctly, what you are saying above is that Tomcat 4 development should be frozen except for bug fixes and all changes and new features go in Tomcat 5? Is that a correct summary? If so I think it is premature to do so, especially since a production quality version of Tomcat 5 could take 6 months. If we are just maintaining Tomcat 4.1 (bug fixes), I would be willing to port any bug fixes to the Tocmat 4.1 branch into a Tocmat 4.2 development branch. And when a 4.2 branch is ready, willing to act as the release manager if you are not interested in doing so. Regards, Glenn -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [4.1.15] Tag tomorrow
Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: Doesn't this require a vote? No. The vote is when the milestone is then publicly released. Otherwise, it's like a nightly, and allows getting some testing. A nightly does not get announced publicly with a revision number. The previous 4.1.13 and 4.1.14 milestone releases you did were done and announced to the public without a vote. I announced that a new test milestone was up and available for testing (reread the announcements, which only got sent to tc-user and tc-dev). IMO, bumping the revision number and announcing to the public a release (no matter what name is given to it) requires a vote. This release process got voted and unanimously approved before the 4.1.x releases started. Perhaps it would be better to get the nightly builds working again so changes can be tested by those interested in them by downloading the nightly. If you are not happy with the current release process, then you can propose a change to it and get it voted. I have the feeling that nobody is happy with my contributions these days, for reasons that elude me. If people want me to stop RMing Tomcat, I can step down. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: I'm now independent and unemployed, so I'm not aware of the Sun schedules for the spec anymore :-P Probably within 3-6 months given J2EE 1.4 is in beta. The rule is we cannot release a stable version of 5.0.x until the specs are final. Rémy If I understand correctly, what you are saying above is that Tomcat 4 development should be frozen except for bug fixes and all changes and new features go in Tomcat 5? Is that a correct summary? If so I think it is premature to do so, especially since a production quality version of Tomcat 5 could take 6 months. If we are just maintaining Tomcat 4.1 (bug fixes), I would be willing to port any bug fixes to the Tocmat 4.1 branch into a Tocmat 4.2 development branch. And when a 4.2 branch is ready, willing to act as the release manager if you are not interested in doing so. I consider 4.1.x can recieve bug fixes and minor feature additions (example: the JNDI realm new feature which just got added, optimisations, etc ...), similar to HTTPd 2.0. This is consistent with the patches I and others have been applying, the release process we've been following, and so on. You may want to clarify your intentions, and since this release process has been going on for 6+ months, I fail to see how you could be surprised at how things are getting done ;-) Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-4.0 build.properties.sample
Wow. I'm confuse. I did some test yesterday and everythings seems to work fine for me. I will continue to ping the Xerces guys -- Jeanfrancois Remy Maucherat wrote: Bill Barker wrote: jfarcand2002/11/11 20:16:59 Modified:.build.properties.sample Log: Update to Xerces 2.2.1. Not working any different than 2.2.0 for me. :-( 2002-11-11 22:46:32 action: null org.xml.sax.SAXParseException: The string -- is not permitted within comments. Then it still has the same problem with Struts 1.0. I'll keep Xerces 2.1.0 for Tomcat 4.1.x. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [4.1.15] Tag tomorrow
Remy, I went back and reviewed the discussion about the new version numbering. And reviewed http://httpd.apache.org/dev/release.html which it is patterned after. You are correct, under the httpd release plan there is no vote to tag and build. I was confused between the old release rules and the new. My mistake. :-) And the release manager has a great deal of latitude in when they do a release and what is in it. I looked back at the email announcements when you have tagged and built a new release for testing and noticed that you are calling them a test milestone. Under the httpd release rules and what we voted on there is no such thing as a test milestone. When a release is done it is called Alpha until a vote has been done to upgrade it to Beta or General Availability (stable). Regards, Glenn Remy Maucherat wrote: Glenn Nielsen wrote: Remy Maucherat wrote: Glenn Nielsen wrote: Doesn't this require a vote? No. The vote is when the milestone is then publicly released. Otherwise, it's like a nightly, and allows getting some testing. A nightly does not get announced publicly with a revision number. The previous 4.1.13 and 4.1.14 milestone releases you did were done and announced to the public without a vote. I announced that a new test milestone was up and available for testing (reread the announcements, which only got sent to tc-user and tc-dev). IMO, bumping the revision number and announcing to the public a release (no matter what name is given to it) requires a vote. This release process got voted and unanimously approved before the 4.1.x releases started. Perhaps it would be better to get the nightly builds working again so changes can be tested by those interested in them by downloading the nightly. If you are not happy with the current release process, then you can propose a change to it and get it voted. I have the feeling that nobody is happy with my contributions these days, for reasons that elude me. If people want me to stop RMing Tomcat, I can step down. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [4.1.15] Tag tomorrow
Remy Maucherat wrote: If you are not happy with the current release process, then you can propose a change to it and get it voted. I have the feeling that nobody is happy with my contributions these days, for reasons that elude me. If people want me to stop RMing Tomcat, I can step down. I am happy with the current release process. And _very_ happy with your contributions. As you know, everyone has (strong) opinions and few have diplomacy - so it may just look otherwise :-) Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
Remy Maucherat wrote: I consider 4.1.x can recieve bug fixes and minor feature additions (example: the JNDI realm new feature which just got added, optimisations, etc ...), similar to HTTPd 2.0. This is consistent with the patches I and others have been applying, the release process we've been following, and so on. +1 If there is enough interest and committers that need that feature - I see no problem with that. As procedure, I think it would be nice to announce the new features before commiting them. IMO the best way to improve this in future is to separate the 'core' and modules, or at least have a separate directory for add-on features and modules. This way the 'core' release can be frozen, but new features can be easily added. Given the backward compatibility it is even possible to even share the modules for multiple tomcat versions ( probably some doc should mention if it was tested with 4.0, 4.1 or 5.0 ). This may also increase the release cycle and reduce the load for the RM ( or at least allow the load to be spread - since modules could be released separately ). Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
Glenn Nielsen wrote: If I understand correctly, what you are saying above is that Tomcat 4 development should be frozen except for bug fixes and all changes and new features go in Tomcat 5? Is that a correct summary? If so I think it is premature to do so, especially since a production quality version of Tomcat 5 could take 6 months. The real problem is the new servlet/jsp spec and implementation. All the extra code is reasonably stable. I don't know how hard it would be to separate the servlet-specific classes, and use the same codebase for a 4.x release. IMHO - if you get 3 +1 votes for 4.2 - I won't opose it ( meaning people willing to work on it ). I am spending all my free time on 5.0 and ant ( I only review the excelent commits that Bill makes in 3.3, sorry I can't help more). If we are just maintaining Tomcat 4.1 (bug fixes), I would be willing to port any bug fixes to the Tocmat 4.1 branch into a Tocmat 4.2 development branch. And when a 4.2 branch is ready, willing to act as the release manager if you are not interested in doing so. Propose a vote then. Again - if 3 committers are willing to work on 4.2, then probably there is a need for it. I would prefer the features to be done on 5.0 ( or 3.3 :-), but everyone should deal with his itches. Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-4.0 build.properties.sample
jfarcand2002/11/12 08:34:57
Modified:.build.properties.sample
Log:
Revert back to Xerces 2.1.0. The bug is still reproducable with Struts 1.0, and
seems to have disappears with Struts 1.1. I'm unable to reproduce the problem with
Tomcat 5, but Xerces is still broken.
Revision ChangesPath
1.54 +3 -3 jakarta-tomcat-4.0/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.properties.sample,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- build.properties.sample 12 Nov 2002 04:16:59 - 1.53
+++ build.properties.sample 12 Nov 2002 16:34:57 - 1.54
-117,9 +117,9
# - Xerces XML Parser, version 2.0.0 or later -
# Note: Optional with JDK 1.4+, or if Xerces 1.x is present
-xerces.home=${base.path}/xerces-2_2_1
+xerces.home=${base.path}/xerces-2_1_0
xerces.lib=${xerces.home}
-xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.1.tar.gz
+xerces.loc=http://xml.apache.org/dist/xerces-j/old_xerces2/Xerces-J-bin.2.1.0.tar.gz
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[PATCH] Fixing Interoperability problem in iis connector
I have noticed problems in the Jakarta tomcat IIS connector when it is used
in conjunction with Netegrity's SiteMinder web agent. The following patch
works-around the problem by giving the user the option of passing data
between the filter and the extension using shared memory instead of headers.
The changes include two new files and I could not include them in the CVS
diff since I could not add the files to the repository so I have in-lined
them and hopefully appropriately delimited them.
Index: isapi.dsp
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/isapi.dsp,v
retrieving revision 1.9
diff -u -r1.9 isapi.dsp
--- isapi.dsp 9 Apr 2002 23:06:52 - 1.9
+++ isapi.dsp 12 Nov 2002 16:58:07 -
@@ -170,6 +170,10 @@
SOURCE=..\common\jk_worker.c
# End Source File
+# Begin Source File
+
+SOURCE=.\req_info.c
+# End Source File
# End Group
# Begin Group Header Files
@@ -265,6 +269,10 @@
# Begin Source File
SOURCE=..\common\jk_worker.h
+# End Source File
+# Begin Source File
+
+SOURCE=.\req_info.h
# End Source File
# End Group
# Begin Group Resource Files
Index: jk_isapi_plugin.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
retrieving revision 1.18
diff -u -r1.18 jk_isapi_plugin.c
--- jk_isapi_plugin.c 25 Sep 2002 00:49:40 - 1.18
+++ jk_isapi_plugin.c 12 Nov 2002 16:58:07 -
@@ -78,6 +78,8 @@
#include jk_worker.h
#include jk_uri_worker_map.h
+#include req_info.h
+
#define VERSION_STRING Jakarta/ISAPI/ JK_VERSTRING
#define DEFAULT_WORKER_NAME (ajp13)
@@ -109,6 +111,8 @@
#define URI_SELECT_UNPARSED_VERB(unparsed)
#define URI_SELECT_ESCAPED_VERB (escaped)
+#define SHMEM_REQUEST_INFO_TAG (use_shared_mem)
+
#define BAD_REQUEST-1
#define BAD_PATH -2
#define MAX_SERVERNAME 128
@@ -142,6 +146,17 @@
} \
}\
+#define GET_REQ_INFO_VALUE(ri, name, var) { \
+char *temp; \
+if (temp = rinfo_get_##name (ri)) \
+{ \
+(var) = jk_pool_strdup(private_data-p, temp); \
+} else { \
+(var) = NULL; \
+} \
+} \
+
+
static char ini_file_name[MAX_PATH];
static int using_ini_file = JK_FALSE;
static int is_inited = JK_FALSE;
@@ -159,6 +174,7 @@
static int log_level = JK_LOG_EMERG_LEVEL;
static char worker_file[MAX_PATH * 2];
static char worker_mount_file[MAX_PATH * 2];
+static int shmem_enabled = JK_FALSE;
#define URI_SELECT_OPT_PARSED 0
#define URI_SELECT_OPT_UNPARSED 1
@@ -670,6 +686,7 @@
char Host[INTERNET_MAX_URL_LENGTH]=;
char Port[INTERNET_MAX_URL_LENGTH]=;
char Translate[INTERNET_MAX_URL_LENGTH];
+char target_uri_buff[INTERNET_MAX_URL_LENGTH]=;
BOOL (WINAPI * GetHeader)
(struct _HTTP_FILTER_CONTEXT * pfc, LPSTR lpszName,
LPVOID lpvBuffer, LPDWORD lpdwSize );
BOOL (WINAPI * SetHeader)
@@ -681,6 +698,8 @@
DWORD szHost = sizeof(Host);
DWORD szPort = sizeof(Port);
DWORD szTranslate = sizeof(Translate);
+ request_information_t *p_request_info = NULL;
+request_info_name_t info_name = 0;
if (iis5) {
GetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)-GetHeader;
@@ -700,11 +719,13 @@
/*
* Just in case somebody set these headers in the request!
*/
-SetHeader(pfc, URI_HEADER_NAME, NULL);
-SetHeader(pfc, QUERY_HEADER_NAME, NULL);
-SetHeader(pfc, WORKER_HEADER_NAME, NULL);
-SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
-
+if (!shmem_enabled) {
+SetHeader(pfc, URI_HEADER_NAME, NULL);
+SetHeader(pfc, QUERY_HEADER_NAME, NULL);
+SetHeader(pfc, WORKER_HEADER_NAME, NULL);
+SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
+}
+
if (!GetHeader(pfc, url, (LPVOID)uri, (LPDWORD)sz)) {
jk_log(logger, JK_LOG_ERROR,
HttpFilterProc error while getting the url\n);
@@ -802,14 +823,30 @@
forwardURI = uri;
}
-if(!AddHeader(pfc, URI_HEADER_NAME, forwardURI) ||
- ( (query != NULL strlen(query) 0)
- ? !AddHeader(pfc, QUERY_HEADER_NAME, query) :
FALSE ) ||
- !AddHeader(pfc, WORKER_HEADER_NAME, worker) ||
- !SetHeader(pfc, url, extension_uri)) {
-jk_log(logger, JK_LOG_ERROR,
- HttpFilterProc error while adding request
headers\n);
-return SF_STATUS_REQ_ERROR;
+if (!shmem_enabled) {
+if(!AddHeader(pfc, URI_HEADER_NAME, forwardURI) ||
+ ( (query != NULL strlen(query) 0)
+
RE: [PATCH] Fixing Interoperability problem in iis connector
:( My mail client warpped the code inappropriately.. I will remedy this and re-post. Thanks, Steven -Original Message- From: Steven Velez [mailto:svelez;alventive.com] Sent: Tuesday, November 12, 2002 12:12 PM To: 'Tomcat Developers List' Subject: [PATCH] Fixing Interoperability problem in iis connector I have noticed problems in the Jakarta tomcat IIS connector when it is used in conjunction with Netegrity's SiteMinder web agent. The following patch works-around the problem by giving the user the option of passing data between the filter and the extension using shared memory instead of headers. The changes include two new files and I could not include them in the CVS diff since I could not add the files to the repository so I have in-lined them and hopefully appropriately delimited them. ..Patch deleted...
RE: [PATCH] Fixing Interoperability problem in iis connector
This should, hopefully, be correctly formatted.
Index: isapi.dsp
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/isapi.dsp,v
retrieving revision 1.9
diff -u -r1.9 isapi.dsp
--- isapi.dsp 9 Apr 2002 23:06:52 - 1.9
+++ isapi.dsp 12 Nov 2002 16:58:07 -
@@ -170,6 +170,10 @@
SOURCE=..\common\jk_worker.c
# End Source File
+# Begin Source File
+
+SOURCE=.\req_info.c
+# End Source File
# End Group
# Begin Group Header Files
@@ -265,6 +269,10 @@
# Begin Source File
SOURCE=..\common\jk_worker.h
+# End Source File
+# Begin Source File
+
+SOURCE=.\req_info.h
# End Source File
# End Group
# Begin Group Resource Files
Index: jk_isapi_plugin.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
retrieving revision 1.18
diff -u -r1.18 jk_isapi_plugin.c
--- jk_isapi_plugin.c 25 Sep 2002 00:49:40 - 1.18
+++ jk_isapi_plugin.c 12 Nov 2002 16:58:07 -
@@ -78,6 +78,8 @@
#include jk_worker.h
#include jk_uri_worker_map.h
+#include req_info.h
+
#define VERSION_STRING Jakarta/ISAPI/ JK_VERSTRING
#define DEFAULT_WORKER_NAME (ajp13)
@@ -109,6 +111,8 @@
#define URI_SELECT_UNPARSED_VERB(unparsed)
#define URI_SELECT_ESCAPED_VERB (escaped)
+#define SHMEM_REQUEST_INFO_TAG (use_shared_mem)
+
#define BAD_REQUEST-1
#define BAD_PATH -2
#define MAX_SERVERNAME 128
@@ -142,6 +146,17 @@
} \
}\
+#define GET_REQ_INFO_VALUE(ri, name, var) { \
+char *temp; \
+if (temp = rinfo_get_##name (ri)) \
+{ \
+(var) = jk_pool_strdup(private_data-p, temp); \
+} else { \
+(var) = NULL; \
+} \
+} \
+
+
static char ini_file_name[MAX_PATH];
static int using_ini_file = JK_FALSE;
static int is_inited = JK_FALSE;
@@ -159,6 +174,7 @@
static int log_level = JK_LOG_EMERG_LEVEL;
static char worker_file[MAX_PATH * 2];
static char worker_mount_file[MAX_PATH * 2];
+static int shmem_enabled = JK_FALSE;
#define URI_SELECT_OPT_PARSED 0
#define URI_SELECT_OPT_UNPARSED 1
@@ -670,6 +686,7 @@
char Host[INTERNET_MAX_URL_LENGTH]=;
char Port[INTERNET_MAX_URL_LENGTH]=;
char Translate[INTERNET_MAX_URL_LENGTH];
+char target_uri_buff[INTERNET_MAX_URL_LENGTH]=;
BOOL (WINAPI * GetHeader)
(struct _HTTP_FILTER_CONTEXT * pfc, LPSTR lpszName,
LPVOID lpvBuffer, LPDWORD lpdwSize );
BOOL (WINAPI * SetHeader)
@@ -681,6 +698,8 @@
DWORD szHost = sizeof(Host);
DWORD szPort = sizeof(Port);
DWORD szTranslate = sizeof(Translate);
+ request_information_t *p_request_info = NULL;
+request_info_name_t info_name = 0;
if (iis5) {
GetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)-GetHeader;
@@ -700,11 +719,13 @@
/*
* Just in case somebody set these headers in the request!
*/
-SetHeader(pfc, URI_HEADER_NAME, NULL);
-SetHeader(pfc, QUERY_HEADER_NAME, NULL);
-SetHeader(pfc, WORKER_HEADER_NAME, NULL);
-SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
-
+if (!shmem_enabled) {
+SetHeader(pfc, URI_HEADER_NAME, NULL);
+SetHeader(pfc, QUERY_HEADER_NAME, NULL);
+SetHeader(pfc, WORKER_HEADER_NAME, NULL);
+SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
+}
+
if (!GetHeader(pfc, url, (LPVOID)uri, (LPDWORD)sz)) {
jk_log(logger, JK_LOG_ERROR,
HttpFilterProc error while getting the url\n);
@@ -802,14 +823,30 @@
forwardURI = uri;
}
-if(!AddHeader(pfc, URI_HEADER_NAME, forwardURI) ||
- ( (query != NULL strlen(query) 0)
- ? !AddHeader(pfc, QUERY_HEADER_NAME, query) :
FALSE ) ||
- !AddHeader(pfc, WORKER_HEADER_NAME, worker) ||
- !SetHeader(pfc, url, extension_uri)) {
-jk_log(logger, JK_LOG_ERROR,
- HttpFilterProc error while adding request
headers\n);
-return SF_STATUS_REQ_ERROR;
+if (!shmem_enabled) {
+if(!AddHeader(pfc, URI_HEADER_NAME, forwardURI) ||
+ ( (query != NULL strlen(query) 0)
+ ? !AddHeader(pfc, QUERY_HEADER_NAME, query)
: FALSE ) ||
+ !AddHeader(pfc, WORKER_HEADER_NAME, worker) ||
+ !SetHeader(pfc, url, extension_uri)) {
+jk_log(logger, JK_LOG_ERROR,
+ HttpFilterProc error while adding request
headers\n);
+return SF_STATUS_REQ_ERROR;
+}
+}
[5.0] Experiment with JMX console
I was experimenting with using MC4J (from SF.net) support using MX4J. Basically, this is a JMX client app with some nice features, and it looked easy to add. However, I ran into serious trouble (and I'm posting that to see if someone can help sort it out, or is willing to investigate further): - The client part may only work with MX4J 1.1. There may be a workaround, according to the docs. - The client (based on Netbeans) crashes (with a BSOD) my XP computer a lot on exit, and no longer works ever since the first crash (I get a NPE on startup from each of MC4J's modules). I have no idea what is going on, and tried reinstalling, etc, without any success. So the bottom line is I can no longer work on the feature :-( I can commit the code if people are interested in the feature, and would like to investigate (basically, it adds a new method in MBeanUtils which instantiates the adaptor MBean, and that's it). Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [PATCH] Fixing Interoperability problem in iis connector
OK.. this time I sent a test before posting... and the post still has
problems it seems the list server (or something) is wrapping long
lines. how do I deal with this?
.-.| Steven Velez
oo|| Software Engineer
/`'\| alventive
(\_;/) | 678-202-2226
-Original Message-
From: Steven Velez [mailto:svelez;alventive.com]
Sent: Tuesday, November 12, 2002 12:23 PM
To: 'Tomcat Developers List'
Subject: RE: [PATCH] Fixing Interoperability problem in iis connector
This should, hopefully, be correctly formatted.
Index: isapi.dsp
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/isapi.dsp,v
retrieving revision 1.9
diff -u -r1.9 isapi.dsp
--- isapi.dsp 9 Apr 2002 23:06:52 - 1.9
+++ isapi.dsp 12 Nov 2002 16:58:07 -
@@ -170,6 +170,10 @@
SOURCE=..\common\jk_worker.c
# End Source File
+# Begin Source File
+
+SOURCE=.\req_info.c
+# End Source File
# End Group
# Begin Group Header Files
@@ -265,6 +269,10 @@
# Begin Source File
SOURCE=..\common\jk_worker.h
+# End Source File
+# Begin Source File
+
+SOURCE=.\req_info.h
# End Source File
# End Group
# Begin Group Resource Files
Index: jk_isapi_plugin.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
retrieving revision 1.18
diff -u -r1.18 jk_isapi_plugin.c
--- jk_isapi_plugin.c 25 Sep 2002 00:49:40 - 1.18
+++ jk_isapi_plugin.c 12 Nov 2002 16:58:07 -
@@ -78,6 +78,8 @@
#include jk_worker.h
#include jk_uri_worker_map.h
+#include req_info.h
+
#define VERSION_STRING Jakarta/ISAPI/ JK_VERSTRING
#define DEFAULT_WORKER_NAME (ajp13)
@@ -109,6 +111,8 @@
#define URI_SELECT_UNPARSED_VERB(unparsed)
#define URI_SELECT_ESCAPED_VERB (escaped)
+#define SHMEM_REQUEST_INFO_TAG (use_shared_mem)
+
#define BAD_REQUEST-1
#define BAD_PATH -2
#define MAX_SERVERNAME 128
@@ -142,6 +146,17 @@
} \
}\
+#define GET_REQ_INFO_VALUE(ri, name, var) { \
+char *temp; \
+if (temp = rinfo_get_##name (ri)) \
+{ \
+(var) = jk_pool_strdup(private_data-p, temp); \
+} else { \
+(var) = NULL; \
+} \
+} \
+
+
static char ini_file_name[MAX_PATH];
static int using_ini_file = JK_FALSE;
static int is_inited = JK_FALSE;
@@ -159,6 +174,7 @@
static int log_level = JK_LOG_EMERG_LEVEL;
static char worker_file[MAX_PATH * 2];
static char worker_mount_file[MAX_PATH * 2];
+static int shmem_enabled = JK_FALSE;
#define URI_SELECT_OPT_PARSED 0
#define URI_SELECT_OPT_UNPARSED 1
@@ -670,6 +686,7 @@
char Host[INTERNET_MAX_URL_LENGTH]=;
char Port[INTERNET_MAX_URL_LENGTH]=;
char Translate[INTERNET_MAX_URL_LENGTH];
+char target_uri_buff[INTERNET_MAX_URL_LENGTH]=;
BOOL (WINAPI * GetHeader)
(struct _HTTP_FILTER_CONTEXT * pfc, LPSTR lpszName,
LPVOID lpvBuffer, LPDWORD lpdwSize );
BOOL (WINAPI * SetHeader)
@@ -681,6 +698,8 @@
DWORD szHost = sizeof(Host);
DWORD szPort = sizeof(Port);
DWORD szTranslate = sizeof(Translate);
+ request_information_t *p_request_info = NULL;
+request_info_name_t info_name = 0;
if (iis5) {
GetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)-GetHeader;
@@ -700,11 +719,13 @@
/*
* Just in case somebody set these headers in the request!
*/
-SetHeader(pfc, URI_HEADER_NAME, NULL);
-SetHeader(pfc, QUERY_HEADER_NAME, NULL);
-SetHeader(pfc, WORKER_HEADER_NAME, NULL);
-SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
-
+if (!shmem_enabled) {
+SetHeader(pfc, URI_HEADER_NAME, NULL);
+SetHeader(pfc, QUERY_HEADER_NAME, NULL);
+SetHeader(pfc, WORKER_HEADER_NAME, NULL);
+SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
+}
+
if (!GetHeader(pfc, url, (LPVOID)uri, (LPDWORD)sz)) {
jk_log(logger, JK_LOG_ERROR,
HttpFilterProc error while getting the url\n);
@@ -802,14 +823,30 @@
forwardURI = uri;
}
-if(!AddHeader(pfc, URI_HEADER_NAME, forwardURI) ||
- ( (query != NULL strlen(query) 0)
- ? !AddHeader(pfc, QUERY_HEADER_NAME, query) :
FALSE ) ||
- !AddHeader(pfc, WORKER_HEADER_NAME, worker) ||
- !SetHeader(pfc, url, extension_uri)) {
-jk_log(logger, JK_LOG_ERROR,
- HttpFilterProc error while adding request
headers\n);
-return SF_STATUS_REQ_ERROR;
+if (!shmem_enabled) {
+if(!AddHeader(pfc, URI_HEADER_NAME,
Re: [5.0] Experiment with JMX console
Remy Maucherat wrote: I was experimenting with using MC4J (from SF.net) support using MX4J. Basically, this is a JMX client app with some nice features, and it looked easy to add. However, I ran into serious trouble (and I'm posting that to see if someone can help sort it out, or is willing to investigate further): - The client part may only work with MX4J 1.1. There may be a workaround, according to the docs. - The client (based on Netbeans) crashes (with a BSOD) my XP computer a lot on exit, and no longer works ever since the first crash (I get a NPE on startup from each of MC4J's modules). I have no idea what is going on, and tried reinstalling, etc, without any success. So the bottom line is I can no longer work on the feature :-( I can commit the code if people are interested in the feature, and would like to investigate (basically, it adds a new method in MBeanUtils which instantiates the adaptor MBean, and that's it). +1 As a note - some of the changes on the startup broke my ant startup code. Instead of fixing it I decided to try a different approach - similar to what JBoss is using. I plan to add code to allow catalina to be wrapped as an MBean, and then add some ant tasks to instantiate (mlet style) and set jmx properties ( and invoke actions ). If anyone is interested to help - it would be great ( the code is not yet ready - but I can check in what I have ). Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: JSPC refactoring/documentation
Has there or will there be any type of requirement gathering on jspc refactoring. I would like to help refactor this but would like to know what options need to be supported / added and which ones to remove. John -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
Costin Manolache wrote: I consider 4.1.x can recieve bug fixes and minor feature additions (example: the JNDI realm new feature which just got added, optimisations, etc ...), similar to HTTPd 2.0. This is consistent with the patches I and others have been applying, the release process we've been following, and so on. +1 If there is enough interest and committers that need that feature - I see no problem with that. Do you actually mean that a new feature will only be added if there is enough committers that need the feature? Does this apply only to 4.1.x? Since I'm not aware of the TC 5.0 requirements regarding the JDK and such I might be wrong here but... My guess is that many users will not be able to switch to TC 5.0 when it is released since their applications might have to be modified and in many cases also be unable to switch since their application might not be tested with the required JDK. If so wouldn't it be better if new features could be implemented into TC 4.x? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
Costin Manolache wrote: Glenn Nielsen wrote: If I understand correctly, what you are saying above is that Tomcat 4 development should be frozen except for bug fixes and all changes and new features go in Tomcat 5? Is that a correct summary? If so I think it is premature to do so, especially since a production quality version of Tomcat 5 could take 6 months. The real problem is the new servlet/jsp spec and implementation. All the extra code is reasonably stable. I don't know how hard it would be to separate the servlet-specific classes, and use the same codebase for a 4.x release. There's also the problem that some modules with API dependencies are getting really big (Jasper 2), so there's less interest to have that capability. At least the really tricky code (the connectors) is now in common. So we can't get back to the Tomcat 4.0 situation. IMHO - if you get 3 +1 votes for 4.2 - I won't opose it ( meaning people willing to work on it ). I am spending all my free time on 5.0 and ant ( I only review the excelent commits that Bill makes in 3.3, sorry I can't help more). +1. This seems reasonable. If this gets some interest (and is indeed needed), I would like to have mentioned in the release plan that relevant patches have to be ported to 5.0, to avoid maintenance problems in the upcoming release cycle. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
John Trollinger wrote: Has there or will there be any type of requirement gathering on jspc refactoring. I would like to help refactor this but would like to know what options need to be supported / added and which ones to remove. Everyone has apparently different opinions on what features should be in jspc. I think a poll should be made to sort it out ;-) Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: ServletOutputStreamWrapper
Paul, it would be a lot easier to help if I knew what you were trying to
do specifically.
If you want to find a class that extends another, why not just search
the source-code textually?
On my unix system, I just do:
findj extends ServletOutputStream
where findj is an alias:
alias findj='find . -name *.java -not -path */autogenerated/* |
xargs grep'
which returns:
./util/ssi/ServletOutputStreamWrapper.java:extends ServletOutputStream {
./connector/ResponseStream.java:extends ServletOutputStream {
-Dan
Paul Hunnisett wrote:
Actually, a good example of a ServletInputStream subclass with a read()
implementation would be helpful too. I am trying to find al lthese
examples in the source, but am haviong limited success tracking down the
appropriate classes
On Tue, 2002-11-12 at 10:13, Paul Hunnisett wrote:
The main reason I was looking at this class in the first place was to
try to find a good way of overriding the write(int) method of
OutputStream in a server context. Is there another class which extends
ServletOutputStream and would give me a more real world example?
On Tue, 2002-11-12 at 00:03, Dan Sandberg wrote:
Hi Paul.
That class is specific to the server-side include code, so the server
doesn't need to know anything about the writeTo method.
Basically, the ServletOutputStreamWrapper is used so that we can capture
the result of Tomcat processing a page, so that we may include the
contents of one page within another.
o.a.c.servlets.SsiInvokerServlet calls the writeTo method. If you have
any questions after looking at the source-code, let us know.
Is anyone familiar with this class?
Yup.
-Dan
Paul Hunnisett wrote:
I have been examining the source code for
org.apache.catalina.util.ssi.ServletOutputStreamWrapper and I discovered
a writeTo() method that writes the current buffer to the OutputStream.
What I can't quite see is how this method would be called. It is not
part of the servlet spec, so the web application won't be calling it.
So I assume that the server calls it, but how does the server know when
to write the buffer out?
Any information would be appreciated.
Paul Hunnisett
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Servlet Spec interpretation FORM-based authentication
See below.
On Mon, 11 Nov 2002, Algirdas P. Veitas wrote:
Date: Mon, 11 Nov 2002 21:56:46 -0700
From: Algirdas P. Veitas [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Servlet Spec interpretation FORM-based authentication
Folks,
I am running into an issue with FORM-based authentication
using 4.1.12 (and 4.0.4). It seems as if the implementation
is not in line with the 2.3 Servlet Specification. Specifically,
the Servlet Spec states:
SRV.12.5.3 Form Base Authentication
--snip--
J2EE.12.5.3.1 Login Form Notes
--snip--
If the form based login is invoked because of an HTTP request, the original
request parameters must be preserved by the container for use if, on
successful authentication, it redirects the call to the requested resource.
It seems as if the request parameters are not being preserved by the
container. After a successful login the container forwards me to the target
URL (a JSP page). The JSP page executes the following code:
Enumeration params = request.getParameterNames();
while (params.hasMoreElements())
{
String paramKey = (String)params.nextElement();
String paramVal = request.getParameter(paramKey);
System.out.println(paramKey + = + paramKey);
}
which I would expect to atleast see printed out:
j_username = some val
j_password = some val 2
but in fact these request parameters are not printed out and thus not part of
the request.
You are making an incorrect assumption. It is the *original* request
(i.e. the one to a protected resource when the user wasn't logged in, and
therefore triggered the login) that is saved, and that original request is
replayed once the login has been completed successfully.
From the user viewpoint, and from your application's viewpoint, the flow
of events is *exactly* like BASIC authentication works -- in between
regular requests, the login page (form-based) or popup (BASIC) is
displayed, then the request that triggered the login is executed. After
login has been completed, you'll see that getRequestUser() starts
returning the logged-in username, but from the app you're not able to see
the password.
The actual saving and restoring occurs in
org.apache.catalina.authenticator.FormAuthenticator.
A bit of digging in the source revealed that in the method
authenticate(HttpRequest,HttpResponse,LoginConfig)
of class org.apache.catalina.authenticator.FormAuthenticator, the code is
executing HttpResponse.sendRedirect(String url) in order to forward the user
to the appropriate page. A sendRedirect() will wipe out all of the original
request parameters.
I think in order to preserve the parameters the sendRedirect() needs to be
replaced by HttpRequest.getServletDispatcher().forward().
Has anyone else seen this behavior and is my claim valid?
Whether a forward or redirect is used is a controversial issue, but
doesn't affect the flow of events that I describe above -- it's a separate
decision.
The reason that Tomcat currently uses a redirect here, and when displaying
welcome pages, is because so many app developers don't understand an
important issue related to RequestDispatcher.forward() -- it would break
any relative URL references in the login page (such as images), because
relative references are resolved, by the browser, against the URL that was
originally submitted to (i.e. the protected page). Using a redirect, the
URL from which relative references are resolved is that of the login page
itself.
Thanks,
Al
Craig McClanahan
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [4.1.15] Tag tomorrow
On Tue, 12 Nov 2002, Remy Maucherat wrote: Date: Tue, 12 Nov 2002 17:01:49 +0100 From: Remy Maucherat [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: [4.1.15] Tag tomorrow Glenn Nielsen wrote: Remy, I went back and reviewed the discussion about the new version numbering. And reviewed http://httpd.apache.org/dev/release.html which it is patterned after. You are correct, under the httpd release plan there is no vote to tag and build. I was confused between the old release rules and the new. My mistake. :-) And the release manager has a great deal of latitude in when they do a release and what is in it. I looked back at the email announcements when you have tagged and built a new release for testing and noticed that you are calling them a test milestone. Under the httpd release rules and what we voted on there is no such thing as a test milestone. When a release is done it is called Alpha until a vote has been done to upgrade it to Beta or General Availability (stable). I wasn't aware of all the fine print. The difference is a bit academical in terms of how-stable-is-the-release, but it makes more sense (rather than moving and renaming releases as I have been doing). I don't like General Availability too much, so I chose to qualify stable releases as Stable. Not moving/renaming them will also get Pier off your back about the impact this has on rsyncs to folks who mirror the Apache web sites :-). Remy Craig -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [PATCH] Fixing Interoperability problem in iis connector
Post the patch as an attachment.
- Original Message -
From: Steven Velez [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Sent: Tuesday, November 12, 2002 10:00 AM
Subject: RE: [PATCH] Fixing Interoperability problem in iis connector
OK.. this time I sent a test before posting... and the post still has
problems it seems the list server (or something) is wrapping long
lines. how do I deal with this?
.-.| Steven Velez
oo|| Software Engineer
/`'\| alventive
(\_;/) | 678-202-2226
-Original Message-
From: Steven Velez [mailto:svelez;alventive.com]
Sent: Tuesday, November 12, 2002 12:23 PM
To: 'Tomcat Developers List'
Subject: RE: [PATCH] Fixing Interoperability problem in iis connector
This should, hopefully, be correctly formatted.
Index: isapi.dsp
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/isapi.dsp,v
retrieving revision 1.9
diff -u -r1.9 isapi.dsp
--- isapi.dsp 9 Apr 2002 23:06:52 - 1.9
+++ isapi.dsp 12 Nov 2002 16:58:07 -
@@ -170,6 +170,10 @@
SOURCE=..\common\jk_worker.c
# End Source File
+# Begin Source File
+
+SOURCE=.\req_info.c
+# End Source File
# End Group
# Begin Group Header Files
@@ -265,6 +269,10 @@
# Begin Source File
SOURCE=..\common\jk_worker.h
+# End Source File
+# Begin Source File
+
+SOURCE=.\req_info.h
# End Source File
# End Group
# Begin Group Resource Files
Index: jk_isapi_plugin.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
retrieving revision 1.18
diff -u -r1.18 jk_isapi_plugin.c
--- jk_isapi_plugin.c 25 Sep 2002 00:49:40 - 1.18
+++ jk_isapi_plugin.c 12 Nov 2002 16:58:07 -
@@ -78,6 +78,8 @@
#include jk_worker.h
#include jk_uri_worker_map.h
+#include req_info.h
+
#define VERSION_STRING Jakarta/ISAPI/ JK_VERSTRING
#define DEFAULT_WORKER_NAME (ajp13)
@@ -109,6 +111,8 @@
#define URI_SELECT_UNPARSED_VERB(unparsed)
#define URI_SELECT_ESCAPED_VERB (escaped)
+#define SHMEM_REQUEST_INFO_TAG (use_shared_mem)
+
#define BAD_REQUEST -1
#define BAD_PATH -2
#define MAX_SERVERNAME 128
@@ -142,6 +146,17 @@
} \
}\
+#define GET_REQ_INFO_VALUE(ri, name, var) { \
+char *temp; \
+if (temp = rinfo_get_##name (ri)) \
+{ \
+(var) = jk_pool_strdup(private_data-p, temp); \
+} else { \
+(var) = NULL; \
+} \
+} \
+
+
static char ini_file_name[MAX_PATH];
static int using_ini_file = JK_FALSE;
static int is_inited = JK_FALSE;
@@ -159,6 +174,7 @@
static int log_level = JK_LOG_EMERG_LEVEL;
static char worker_file[MAX_PATH * 2];
static char worker_mount_file[MAX_PATH * 2];
+static int shmem_enabled = JK_FALSE;
#define URI_SELECT_OPT_PARSED 0
#define URI_SELECT_OPT_UNPARSED 1
@@ -670,6 +686,7 @@
char Host[INTERNET_MAX_URL_LENGTH]=;
char Port[INTERNET_MAX_URL_LENGTH]=;
char Translate[INTERNET_MAX_URL_LENGTH];
+char target_uri_buff[INTERNET_MAX_URL_LENGTH]=;
BOOL (WINAPI * GetHeader)
(struct _HTTP_FILTER_CONTEXT * pfc, LPSTR lpszName,
LPVOID lpvBuffer, LPDWORD lpdwSize );
BOOL (WINAPI * SetHeader)
@@ -681,6 +698,8 @@
DWORD szHost = sizeof(Host);
DWORD szPort = sizeof(Port);
DWORD szTranslate = sizeof(Translate);
+ request_information_t *p_request_info = NULL;
+request_info_name_t info_name = 0;
if (iis5) {
GetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)-GetHeader;
@@ -700,11 +719,13 @@
/*
* Just in case somebody set these headers in the request!
*/
-SetHeader(pfc, URI_HEADER_NAME, NULL);
-SetHeader(pfc, QUERY_HEADER_NAME, NULL);
-SetHeader(pfc, WORKER_HEADER_NAME, NULL);
-SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
-
+if (!shmem_enabled) {
+SetHeader(pfc, URI_HEADER_NAME, NULL);
+SetHeader(pfc, QUERY_HEADER_NAME, NULL);
+SetHeader(pfc, WORKER_HEADER_NAME, NULL);
+SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
+}
+
if (!GetHeader(pfc, url, (LPVOID)uri, (LPDWORD)sz)) {
jk_log(logger, JK_LOG_ERROR,
HttpFilterProc error while getting the url\n);
@@ -802,14 +823,30 @@
forwardURI = uri;
}
-if(!AddHeader(pfc, URI_HEADER_NAME, forwardURI) ||
- ( (query != NULL strlen(query) 0)
- ? !AddHeader(pfc, QUERY_HEADER_NAME, query) :
FALSE ) ||
- !AddHeader(pfc, WORKER_HEADER_NAME, worker) ||
- !SetHeader(pfc, url, extension_uri)) {
-jk_log(logger, JK_LOG_ERROR,
Tomcat I/O
I assume that somewhere in Tomcat are some classes that extend ServletOutputStream and ServletInputStream? I've been looking through the source trying to find them but I'm afraid I can't see what they are. Is anyone able to shed any light on this for me? Paul Hunnisett www.lombok.org.uk -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: ServletOutputStreamWrapper
Thanks Dan, I'll try that. Basically what I'm trying to do is to write
my own subclasses of ServletOutputStream and ServletInputStream and I
need a little bit of inspiration - especially with the write(int) and
read() methods that I have to override.
On Tue, 2002-11-12 at 19:06, Dan Sandberg wrote:
Paul, it would be a lot easier to help if I knew what you were trying to
do specifically.
If you want to find a class that extends another, why not just search
the source-code textually?
On my unix system, I just do:
findj extends ServletOutputStream
where findj is an alias:
alias findj='find . -name *.java -not -path */autogenerated/* |
xargs grep'
which returns:
./util/ssi/ServletOutputStreamWrapper.java:extends ServletOutputStream {
./connector/ResponseStream.java:extends ServletOutputStream {
-Dan
Paul Hunnisett wrote:
Actually, a good example of a ServletInputStream subclass with a read()
implementation would be helpful too. I am trying to find al lthese
examples in the source, but am haviong limited success tracking down the
appropriate classes
On Tue, 2002-11-12 at 10:13, Paul Hunnisett wrote:
The main reason I was looking at this class in the first place was to
try to find a good way of overriding the write(int) method of
OutputStream in a server context. Is there another class which extends
ServletOutputStream and would give me a more real world example?
On Tue, 2002-11-12 at 00:03, Dan Sandberg wrote:
Hi Paul.
That class is specific to the server-side include code, so the server
doesn't need to know anything about the writeTo method.
Basically, the ServletOutputStreamWrapper is used so that we can capture
the result of Tomcat processing a page, so that we may include the
contents of one page within another.
o.a.c.servlets.SsiInvokerServlet calls the writeTo method. If you have
any questions after looking at the source-code, let us know.
Is anyone familiar with this class?
Yup.
-Dan
Paul Hunnisett wrote:
I have been examining the source code for
org.apache.catalina.util.ssi.ServletOutputStreamWrapper and I discovered
a writeTo() method that writes the current buffer to the OutputStream.
What I can't quite see is how this method would be called. It is not
part of the servlet spec, so the web application won't be calling it.
So I assume that the server calls it, but how does the server know when
to write the buffer out?
Any information would be appreciated.
Paul Hunnisett
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: ServletOutputStreamWrapper
On 12 Nov 2002, Paul Hunnisett wrote: Date: 12 Nov 2002 19:38:18 + From: Paul Hunnisett [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: ServletOutputStreamWrapper Thanks Dan, I'll try that. Basically what I'm trying to do is to write my own subclasses of ServletOutputStream and ServletInputStream and I need a little bit of inspiration - especially with the write(int) and read() methods that I have to override. In the examples webapp shipped with Tomcat, there's a compression filter that (among other things) creates a ServletResponseWrapper subclass and uses a specialized response stream implementation (extends ServletOutputStream). The sources are in the /WEB-INF/classes/compressionFilters subdirectory of the example webapp. Craig -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm JNDIRealm.java
amyroh 2002/11/12 12:09:30
Modified:catalina/src/share/org/apache/catalina/realm JNDIRealm.java
Log:
Port SSL support for JNDIRealm.
Revision ChangesPath
1.2 +66 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
Index: JNDIRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JNDIRealm.java18 Jul 2002 16:47:55 - 1.1
+++ JNDIRealm.java12 Nov 2002 20:09:29 - 1.2
-190,6 +190,12
/**
+ * The type of authentication to use
+ */
+protected String authentication = null;
+
+
+/**
* The connection username for the server we will contact.
*/
protected String connectionName = null;
-235,6 +241,12
/**
+ * The protocol that will be used in the communication with the directory
server.
+ */
+protected String protocol = null;
+
+
+/**
* The base element for user searches.
*/
protected String userBase = ;
-325,6 +337,28
/**
+ * Return the type of authentication to use.
+ */
+public String getAuthentication() {
+
+return authentication;
+
+}
+
+
+/**
+ * Set the type of authentication to use.
+ *
+ * param authentication The authentication
+ */
+public void setAuthentication(String authentication) {
+
+this.authentication = authentication;
+
+}
+
+
+/**
* Return the connection username for this Realm.
*/
public String getConnectionName() {
-411,6 +445,29
}
+
+/**
+ * Return the protocol to be used.
+ */
+public String getProtocol() {
+
+return protocol;
+
+}
+
+
+/**
+ * Set the protocol for this Realm.
+ *
+ * param protocol The new protocol.
+ */
+public void setProtocol(String protocol) {
+
+this.protocol = protocol;
+
+}
+
+
/**
* Return the base element for user searches.
*/
-1294,6 +1351,11
env.put(Context.SECURITY_CREDENTIALS, connectionPassword);
if (connectionURL != null)
env.put(Context.PROVIDER_URL, connectionURL);
+if (authentication != null)
+env.put(Context.SECURITY_AUTHENTICATION, authentication);
+if (protocol != null)
+env.put(Context.SECURITY_PROTOCOL, protocol);
+
context = new InitialDirContext(env);
return (context);
-1378,4 +1440,3
}
}
-
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/webapps/docs/config realm.xml
amyroh 2002/11/12 12:22:07 Modified:webapps/docs/config realm.xml Log: Port document change for newly supported SSL in JNDIRealm. Revision ChangesPath 1.3 +10 -0 jakarta-tomcat-catalina/webapps/docs/config/realm.xml Index: realm.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/realm.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- realm.xml 30 Jul 2002 03:58:28 - 1.2 +++ realm.xml 12 Nov 2002 20:22:07 - 1.3 -193,6 +193,11 information from the directory:/p attributes + attribute name=authentication required=false + pA string specifying the type of authentication to use. + none, simple, strong or a provider specific definition + can be used. If no value is given the providers default is used./p + /attribute attribute name=connectionName required=false pThe directory username to use when establishing a -219,6 +224,11 pFully qualified Java class name of the factory class used to acquire our JNDI codeInitialContext/code. By default, assumes that the standard JNDI LDAP provider will be utilized./p + /attribute + + attribute name=protocol required=false + pA string specifying the security protocol to use. If not given + the providers default is used./p /attribute attribute name=roleBase required=false -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realmJNDIRealm.java
Fredrik Westermarck wrote: Amy Roh wrote: I don't use SSL with JNDIRealm so I didn't test this out. However, the patch seems ok and has been ignored long enough (with a few complaints). ;-) Let me know if there're any issues. Thank you! You're welcome. Sorry for the delay and thanks for the good patch. Keep'em coming. :-) Amy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
bug found and fixed in jasper in 4.x cvs
I recently had the occasion to try and make jasper's JspC work for my webapp. Unfortunately, it was did not work out of the box. Fortunately, I was able to patch it to make it work. The problem is that my directory structure looks something like this: /WEB-INF/jsp/foo.jsp /WEB-INF/jsp/foo/bar.jsp JspC complained that foo was both a package name and a class name and that that was not allowed (java.util.Map.Entry not withstanding, I guess). Note that when catalina invokes jasper via the JspServlet, the class names are mangled with a $jsp suffix, so this problem does not occur; no idea why the algorithm is different when operating in JspC mode. In any case, I patched JspC to tack on a $jsp suffix to the ctctxt class name (when one has not been manually specified on the command line, that is). I'd be happy to submit a patch if someone can tell me the preferred mechanism these days. I also have a patch for JDBCRealm that generalizes it to allow the user to specify arbitrary SQL queries for getting user and role data. I posted a note about it a month or so ago to deafening silence, perhaps I'll have better luck this time? - donald -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
Fredrik Westermarck wrote: Do you actually mean that a new feature will only be added if there is enough committers that need the feature? Does this apply only to 4.1.x? Well... In theory it should apply to all tomcat features, or at least to important ones - they must be first proposed on the list, discussed, and then voted. We use 'lazy consensus' ( i.e. commit first and wait for -1 ) a bit too much. I was refering to the proposed tomcat 4.2 release. It needs at least 3 +1 votes - i.e. committers who are willing to spend time on it. Since I'm not aware of the TC 5.0 requirements regarding the JDK and such I might be wrong here but... AFAIK - JDK1.3. ( it should work fine with JDK1.2, but I don't think it is tested that much ). My guess is that many users will not be able to switch to TC 5.0 when it is released since their applications might have to be modified and in many cases also be unable to switch since their application might not be tested with the required JDK. TC5.0 should be backward compatible. If so wouldn't it be better if new features could be implemented into TC 4.x? The real question is who is going to do that. As I said, if there are people who need it and are willing to do the work - then it'll happen. Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14492] New: - PageContext.include doesn't work if a part of path is a number
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=14492. 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=14492 PageContext.include doesn't work if a part of path is a number Summary: PageContext.include doesn't work if a part of path is a number Product: Tomcat 4 Version: 4.0.6 Final Platform: PC OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] PageContext.include doesn't work if a part of path is a number. Example : /Presse/hebdo/2000/hebdo00276.html this include runs fine with Tomcat 4.0.2, 4.0.3 and 4.1.12. To solve the problem, I needed to change the path to : /Presse/hebdo/A2000/hebdo00276.html I don't use Tomcat 4.1.12 because request.getScheme method doesn't work and I need it. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
Costin Manolache wrote: Do you actually mean that a new feature will only be added if there is enough committers that need the feature? Does this apply only to 4.1.x? Well... In theory it should apply to all tomcat features, or at least to important ones - they must be first proposed on the list, discussed, and then voted. We use 'lazy consensus' ( i.e. commit first and wait for -1 ) a bit too much. Well there is quite a difference between needs and accepts. The problem that I and others have experienced is that proposals and/or patches, by non-committers, don't get discussed or voted about. Since I'm not aware of the TC 5.0 requirements regarding the JDK and such I might be wrong here but... AFAIK - JDK1.3. ( it should work fine with JDK1.2, but I don't think it is tested that much ). Should... My guess is that many users will not be able to switch to TC 5.0 when it is released since their applications might have to be modified and in many cases also be unable to switch since their application might not be tested with the required JDK. TC5.0 should be backward compatible. Should... Yes I also tell my customers that it should work, even if you never can be 100% sure. :-) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: /admin 404
I don't understand why I can't get it to work with xerces 2.1.0. I have updated all of my workspace and made sure I have the correct xerces 2.1.0 but still TLD errors. Bill, Can you get admin to work with 2.1.0? Can someone else confirm that admin works with 2.1.0? confused Amy Jeanfrancois Arcand wrote: Yes, everythings works fine with the current build. -- Jeanfrancois Amy Roh wrote: I switched from 2.2.0 to 2.1.0. Still no admin. :-( I'm attaching the error logs for tomcat 4 and tomcat 5. The same following errors are displayed running Tomcat 5. Jeanfrancois, admin works for you with 2.1.0?? Thanks, Amy Nov 11, 2002 5:59:59 PM org.apache.catalina.startup.ContextConfig start SEVERE: Exception processing TLD at resource path /WEB-INF/struts-logic.tld javax.servlet.ServletException: Exception processing TLD at resource path /WEB-I NF/struts-logic.tld at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.ja va:1159) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java: 1011) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:78 3) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfi g.java:260) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3 718) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:822) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:80 8) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDe ployer.java:624) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.jav a:250) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:260) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1063) at org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXPar ser.java:585) at org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBind er.java:647) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement( XMLDocumentFragmentScannerImpl.java:1008) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent Dispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1469) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XM LDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav a:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav a:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.j ava:1175) at org.apache.commons.digester.Digester.parse(Digester.java:1561) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDep loyer.java:430) at org.apache.catalina.core.StandardHost.install(StandardHost.java:856) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.j ava:504) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:461 ) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:930) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java :420) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1203) at org.apache.catalina.core.StandardHost.start(StandardHost.java:791) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1195) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347 ) at org.apache.catalina.core.StandardService.start(StandardService.java:4 97) at org.apache.catalina.core.StandardServer.start(StandardServer.java:229 0) at org.apache.catalina.startup.Catalina.start(Catalina.java:587) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at
Re: Servlet Spec interpretation FORM-based authentication
Craig,
Thank you for clearing this up. Here is what we are ultimately
trying to do given our requirements.
We need to introduce the concept of a domain when authenticating users.
Meaning jdoe in Domain X is not the same user as jdoe in Domain Y.
Thus, we would like to add another input tag into the j_security_check
form so that the user can specify their respective domain.
Given the current implementation in the FormAuthenticator, is their any way
that we can gain access to the domain parameter after Catalina performs
authentication while maintaining conformity to the servlet specification?
Thanks again,
Al
See below.
On Mon, 11 Nov 2002, Algirdas P. Veitas wrote:
Date: Mon, 11 Nov 2002 21:56:46 -0700
From: Algirdas P. Veitas [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Servlet Spec interpretation FORM-based authentication
Folks,
I am running into an issue with FORM-based authentication
using 4.1.12 (and 4.0.4). It seems as if the implementation
is not in line with the 2.3 Servlet Specification. Specifically,
the Servlet Spec states:
SRV.12.5.3 Form Base Authentication
--snip--
J2EE.12.5.3.1 Login Form Notes
--snip--
If the form based login is invoked because of an HTTP request, the
original
request parameters must be preserved by the container for use if, on
successful authentication, it redirects the call to the requested
resource.
It seems as if the request parameters are not being preserved by the
container. After a successful login the container forwards me to the
target
URL (a JSP page). The JSP page executes the following code:
Enumeration params = request.getParameterNames();
while (params.hasMoreElements())
{
String paramKey = (String)params.nextElement();
String paramVal = request.getParameter(paramKey);
System.out.println(paramKey + = + paramKey);
}
which I would expect to atleast see printed out:
j_username = some val
j_password = some val 2
but in fact these request parameters are not printed out and thus not
part of
the request.
You are making an incorrect assumption. It is the *original* request
(i.e. the one to a protected resource when the user wasn't logged in,
and therefore triggered the login) that is saved, and that original
request is replayed once the login has been completed successfully.
From the user viewpoint, and from your application's viewpoint, the flow
of events is *exactly* like BASIC authentication works -- in between
regular requests, the login page (form-based) or popup (BASIC) is
displayed, then the request that triggered the login is executed. After
login has been completed, you'll see that getRequestUser() starts
returning the logged-in username, but from the app you're not able
to see the password.
The actual saving and restoring occurs in
org.apache.catalina.authenticator.FormAuthenticator.
A bit of digging in the source revealed that in the method
authenticate(HttpRequest,HttpResponse,LoginConfig)
of class org.apache.catalina.authenticator.FormAuthenticator, the code is
executing HttpResponse.sendRedirect(String url) in order to forward the
user
to the appropriate page. A sendRedirect() will wipe out all of the
original
request parameters.
I think in order to preserve the parameters the sendRedirect() needs to be
replaced by HttpRequest.getServletDispatcher().forward().
Has anyone else seen this behavior and is my claim valid?
Whether a forward or redirect is used is a controversial issue, but
doesn't affect the flow of events that I describe above -- it's a separate
decision.
The reason that Tomcat currently uses a redirect here, and when displaying
welcome pages, is because so many app developers don't understand an
important issue related to RequestDispatcher.forward() -- it would break
any relative URL references in the login page (such as images), because
relative references are resolved, by the browser, against the URL
that was originally submitted to (i.e. the protected page). Using a
redirect, the URL from which relative references are resolved is
that of the login page itself.
Thanks,
Al
Craig McClanahan
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
Open WebMail Project (http://openwebmail.org)
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Servlet Spec interpretation FORM-based authentication
On Tue, 12 Nov 2002, Algirdas P. Veitas wrote: Date: Tue, 12 Nov 2002 16:04:36 -0700 From: Algirdas P. Veitas [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Servlet Spec interpretation FORM-based authentication Craig, Thank you for clearing this up. Here is what we are ultimately trying to do given our requirements. We need to introduce the concept of a domain when authenticating users. Meaning jdoe in Domain X is not the same user as jdoe in Domain Y. Thus, we would like to add another input tag into the j_security_check form so that the user can specify their respective domain. Given the current implementation in the FormAuthenticator, is their any way that we can gain access to the domain parameter after Catalina performs authentication while maintaining conformity to the servlet specification? The set of fields on a form login page are defined in the servlet spec, so adding extra fields beyond j_username and j_password would break compatibility with every other servlet container. Obviously, you can make that kind of a change in your own copy of Tomcat, but it would be problematic to do things like that in the standard release. How most people deal with the issue you raise is to combine the username and the domain (in your scenario) into the j_username field of the login (perhaps with usernames like jdoe@domainx and jdoe@domainy or something like that), and disambiguate in the Realm implementation as needed. That way, you can use the standard container managed facilities and still be portable. Thanks again, Al Craig -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
Fredrik Westermarck wrote: The problem that I and others have experienced is that proposals and/or patches, by non-committers, don't get discussed or voted about. You have to keep pushing. If you send patches and proposals you can become a committer - and then you'll start ignoring patches and proposals :-) I'm sorry - but everyone is very short on time. If you have a real interest in tomcat the best solution is to send patches, insist on getting them accepted and become a committer. I think many people here will tell you it's not that hard. Since I'm not aware of the TC 5.0 requirements regarding the JDK and such I might be wrong here but... AFAIK - JDK1.3. ( it should work fine with JDK1.2, but I don't think it is tested that much ). Should... Are you on JDK1.2 ? Is there any concrete feature that you need in 4.1 but is not implemented ? TC5.0 should be backward compatible. Should... Yes I also tell my customers that it should work, even if you never can be 100% sure. :-) Download the milestones, test your application - and if it doesn't work submit bug reports or patches. It is quite possible to have a change between minor releases that would brake your app. You can never know if it is not tested. What's important ( IMO ) is that at the moment it seems more people are actively working on 5.0, so its easier to get things changed there. 4.1 is stable - and it's normal to be a high resistence to bigger changes. It's a case-by-case decision - if a feature is extremely important and you have good arguments to convince 2-3 committers and you have the patch - than it's very likely it'll be accepted ( including for 4.0 or 3.3). Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors gump.xml
costin 2002/11/12 16:12:49 Modified:.gump.xml Log: Added a small desctiptor for the native connector. It'll fail if a compiler is not found. Revision ChangesPath 1.9 +5 -0 jakarta-tomcat-connectors/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/gump.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- gump.xml 18 Sep 2002 16:44:35 - 1.8 +++ gump.xml 13 Nov 2002 00:12:49 - 1.9 @@ -93,5 +93,10 @@ from=Craig McClanahan lt;[EMAIL PROTECTED]gt;/ /project + project name=jakarta-tomcat-jk2-native +ant basedir=jk/native2 target=all +/ant +depend project=jakarta-ant / + /project /module -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/http11 build.xml
costin 2002/11/12 16:14:25
Modified:http11 build.xml
Log:
A small change to allow 'compile only' in a separate dir.
Revision ChangesPath
1.9 +13 -6 jakarta-tomcat-connectors/http11/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/http11/build.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- build.xml 16 Mar 2002 03:51:25 - 1.8
+++ build.xml 13 Nov 2002 00:14:25 - 1.9
-146,9 +146,9
/javadoc
/target
+ target name=compile-only
+ description=Compile shareable components
- target name=compile depends=static
- description=Compile shareable components
javac srcdir=${source.home}
destdir=${build.home}/classes
debug=${compile.debug}
-159,13 +159,20
copytodir=${build.home}/classes filtering=on
fileset dir=${source.home} excludes=**/*.java/
/copy
-jarjarfile=${build.home}/lib/tomcat-${component.name}.jar
+property name=tomcat-http11.jar
value=${build.home}/lib/tomcat-${component.name}.jar/
+jarjarfile=${tomcat-http11.jar}
basedir=${build.home}/classes
- manifest=${build.home}/conf/MANIFEST.MF/
+ manifest=${conf.home}/MANIFEST.MF
+ include name=org/apache/coyote/http11/**/
+/jar
+ /target
+
+ target name=compile depends=static,compile-only
+ description=Compile shareable components
jar jarfile=${build.home}/lib/tomcat33-resource.jar
basedir=${build.home}/classes
includes=**/*.properties /
-
+
copy file=${tomcat-util.jar}
tofile=${build.home}/lib/tomcat-util.jar /
copy file=${tomcat-coyote.jar}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/conf jk2.manifest
costin 2002/11/12 16:17:08 Modified:jk/conf jk2.manifest Log: Only single-line classpath is allowed. Revision ChangesPath 1.7 +1 -2 jakarta-tomcat-connectors/jk/conf/jk2.manifest Index: jk2.manifest === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/conf/jk2.manifest,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- jk2.manifest 20 Sep 2002 03:41:48 - 1.6 +++ jk2.manifest 13 Nov 2002 00:17:07 - 1.7 -1,3 +1,2 Main-Class: org.apache.jk.apr.TomcatStarter -Class-Path: ../lib/tomcat.jar log4j.jar log4j-core.jar ../lib/common/log4j.jar ../lib/common/log4j-core.jar ../lib/common/classes ../lib/common/commons-logging.jar -Class-Path: bootstrap.jar ../server/lib/commons-logging.jar +Class-Path: ../lib/tomcat.jar log4j.jar log4j-core.jar ../lib/common/log4j.jar ../lib/common/log4j-core.jar ../lib/common/classes ../lib/common/commons-logging.jar bootstrap.jar ../server/lib/commons-logging.jar -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
costin 2002/11/12 16:18:16
Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
Move set attribute to trace level.
Revision ChangesPath
1.30 +5 -2
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
Index: JkCoyoteHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JkCoyoteHandler.java 10 Nov 2002 07:25:21 - 1.29
+++ JkCoyoteHandler.java 13 Nov 2002 00:18:16 - 1.30
-101,8 +101,8
public final int JK_STATUS_CLOSED=2;
public void setProperty( String name, String value ) {
-if( log.isDebugEnabled())
-log.debug(setProperty + name + + value );
+if( log.isTraceEnabled())
+log.trace(setProperty + name + + value );
jkMain.setProperty( name, value );
properties.put( name, value );
}
-114,6 +114,8
/** Pass config info
*/
public void setAttribute( String name, Object value ) {
+if( log.isDebugEnabled())
+log.debug(setAttribute + name + + value );
if( value instanceof String )
this.setProperty( name, (String)value );
}
-297,6 +299,7
if( contentLanguage != null ) {
headers.setValue(Content-Language).setString(contentLanguage);
}
+
int contentLength = res.getContentLength();
if( contentLength = 0 ) {
headers.setValue(Content-Length).setInt(contentLength);
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/11/12 16:19:00
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
Eliminate the .save file - it is not used and confusing.
( can be re-enabled in jk2.properties )
Revision ChangesPath
1.32 +7 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- JkMain.java 31 Oct 2002 00:56:35 - 1.31
+++ JkMain.java 13 Nov 2002 00:19:00 - 1.32
-112,6 +112,7
Properties modules=new Properties();
boolean modified=false;
boolean started=false;
+boolean saveProperties=false;
public JkMain()
{
-168,6 +169,10
return propFile;
}
+public void setSaveProperties( boolean b ) {
+saveProperties=b;
+}
+
/** Set a name/value as a jk2 property
*/
public void setProperty( String n, String v ) {
-442,6 +447,8
// Private methods
public void saveProperties() {
+if( !saveProperties) return;
+
// Temp - to check if it works
String outFile=propFile + .save;
log.debug(Saving properties + outFile );
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriEnv.c
costin 2002/11/12 16:21:20
Modified:jk/native2/common jk_uriEnv.c
Log:
Remove the deprecated message for path.
It is used by the 'native' apache2 mapper.
Revision ChangesPath
1.41 +12 -15jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
Index: jk_uriEnv.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- jk_uriEnv.c 22 Oct 2002 10:11:44 - 1.40
+++ jk_uriEnv.c 13 Nov 2002 00:21:20 - 1.41
-226,22 +226,26
uriEnv-aliases-put(env, uriEnv-aliases, val, uriEnv, NULL);
}
}
+else if (strcmp(path, name) == 0) {
+/** This is called from Location in jk2, it has the same effect
+ *as using the constructor.
+ */
+if (val == NULL)
+uriEnv-uri = NULL;
+else
+uriEnv-uri = uriEnv-pool-pstrdup(env, uriEnv-pool, val);
+}
else if (strcmp(inheritGlobals, name) == 0) {
uriEnv-inherit_globals = atoi(val);
}
else {
/* OLD - DEPRECATED */
-int d = 1;
if (strcmp(worker, name) == 0) {
-d = 1;
uriEnv-workerName = val;
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+uriEnv.setAttribute() the %s directive is deprecated. Use
'group' instead.\n,
+name);
}
-else if (strcmp(path, name) == 0) {
-if (val == NULL)
-uriEnv-uri = NULL;
-else
-uriEnv-uri = uriEnv-pool-pstrdup(env, uriEnv-pool, val);
-}
else if (strcmp(uri, name) == 0) {
jk2_uriEnv_parseName(env, uriEnv, val);
}
-254,13 +258,6
else
uriEnv-virtual = uriEnv-pool-pstrdup(env, uriEnv-pool, val);
}
-else
-d = 0;
-if (d)
-env-l-jkLog(env, env-l, JK_LOG_INFO,
-uriEnv.setAttribute() the %s directive is depriciated\n,
-name);
-
}
return JK_OK;
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configwebcom.xml
costin 2002/11/12 16:22:12 Modified:jk/xdocs/jk2 configwebcom.xml Log: Few fixes. Revision ChangesPath 1.5 +12 -5 jakarta-tomcat-connectors/jk/xdocs/jk2/configwebcom.xml Index: configwebcom.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk2/configwebcom.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- configwebcom.xml 22 Oct 2002 12:45:40 - 1.4 +++ configwebcom.xml 13 Nov 2002 00:22:12 - 1.5 -153,19 +153,26 thDescription/th /tr tr -tdworker/td +tdgroup/td tdlb:0 (The default loadbalancer)/td -tdName of the worker that process the request corresponding to the uri/td +tdName of the tomcat group or worker that will process the request corresponding to the uri. This used +to be called 'worker'/td /tr tr tdcontext/td td/ -tdthe context that will be served by this uri component (webapp style)/td +tdthe context path for this uri component (webapp style)./td +/tr +tr +tdservlet/td +td/ +tdServlet path for this mapping/td /tr tr tdalias/td td/ -tdserver name alias/td +tdserver name alias. This setting should only be used for +host uris like [uri:myHost:myPort] ( i.e. no /) /td /tr /table /p -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/lib log4j.jar
costin 2002/11/12 16:24:16 Modified:lib log4j.jar Log: Update log4j.jar in CVS. Note: the build process uses the downloaded version. We should eliminate most of the files in this dir. This log4j is modified to display the 'cause' if used with jdk1.3 and earlier, quite useful for debug. Revision ChangesPath 1.2 +911 -864 jakarta-tomcat-connectors/lib/log4j.jar Binary file -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina build.xml
costin 2002/11/12 16:27:43
Modified:catalina build.xml
Log:
Few changes ( I really hope I didn't broke the build for other people )
to allow faster compilation and better integration with some IDEs.
The build can now be customized to take place in a separate directory,
and the jar will take only the files that are needed. In addition
it is possible to just compile.
Revision ChangesPath
1.30 +26 -23jakarta-tomcat-catalina/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- build.xml 24 Oct 2002 22:11:03 - 1.29
+++ build.xml 13 Nov 2002 00:27:43 - 1.30
-12,6 +12,7
!-- Build Defaults --
property name=catalina.home location=../
property name=catalina.buildvalue=${catalina.home}/catalina/build/
+ property name=classes.dir value=${catalina.build}/server/classes /
property name=catalina.deploy value=${catalina.home}/build/
property name=catalina.dist value=${catalina.home}/dist/
property name=test.failonerror value=true/
-69,7 +70,7
pathelement location=${tyrex.jar}/
pathelement location=${xercesImpl.jar}/
pathelement location=${xmlParserAPIs.jar}/
-pathelement location=${catalina.build}/server/classes/
+pathelement location=${classes.dir}/
/path
!-- Construct unit tests classpath --
-100,7 +101,7
pathelement location=${tyrex.jar}/
pathelement location=${xercesImpl.jar}/
pathelement location=${xmlParserAPIs.jar}/
-pathelement location=${catalina.build}/server/classes/
+pathelement location=${classes.dir}/
pathelement location=${catalina.build}/tests/
/path
-153,7 +154,7
classpath=${commons-logging.jar}/
available property=modeler.present
classname=org.apache.commons.modeler.Registry
- classpath=${commons-modeler.jar}/
+ classpath=${commons-modeler.jar}:${jmx.jar}/
available property=jaas.present
classname=javax.security.auth.Subject
classpath=${jaas.jar} /
-434,7 +435,7
echo message=launcher.present=${launcher.present} /
echo message=launcher.bootstrap.present=${launcher.bootstrap.present} /
echo message=ldap.present=${ldap.present} /
-echo message=modeler.present=${modeler.present} /
+echo message=modeler.present=${modeler.present} /
echo message=pool.present=${pool.present} /
echo message=tyrex.present=${tyrex.present} /
-489,7 +490,7
mkdir dir=${catalina.build}/common/endorsed/
mkdir dir=${catalina.build}/conf/
mkdir dir=${catalina.build}/logs/
-mkdir dir=${catalina.build}/server/classes/
+mkdir dir=${classes.dir}/
mkdir dir=${catalina.build}/server/lib/
mkdir dir=${catalina.build}/shared/classes/
mkdir dir=${catalina.build}/shared/lib/
-584,9 +585,8
!-- BUILD: Compile Catalina Components --
target name=build-catalina
-
!-- Compile internal server components --
-javac srcdir=src/share destdir=${catalina.build}/server/classes
+javac srcdir=src/share destdir=${classes.dir}
debug=${compile.debug} deprecation=${compile.deprecation}
optimize=${compile.optimize}
excludes=**/CVS/**
-625,7 +625,7
!-- Copy static resource files --
filter token=VERSION value=${version}/
-copy todir=${catalina.build}/server/classes filtering=true
+copy todir=${classes.dir} filtering=true
fileset dir=src/share
exclude name=**/*.java/
/fileset
-835,13 +835,13
!-- == DEPLOY: Create Catalina JARs --
- target name=catalina-jars depends=deploy-static,build-catalina
+ target name=catalina-jars
depends=deploy-prepare,flags,flags.display,build-catalina
description=Build catalina jars
!-- Catalina Bootstrap JAR File --
jar jarfile=${catalina.deploy}/bin/bootstrap.jar
manifest=etc/bootstrap.MF
- fileset dir=${catalina.build}/server/classes
+ fileset dir=${classes.dir}
include name=org/apache/catalina/startup/Bootstrap.class /
include name=org/apache/catalina/startup/catalina.properties /
include name=org/apache/catalina/startup/CatalinaProperties.class /
-858,7 +858,8
!-- Catalina Main JAR File --
jar jarfile=${catalina.deploy}/server/lib/catalina.jar
- fileset dir=${catalina.build}/server/classes
+ fileset dir=${classes.dir}
+include name=org/apache/catalina/** /
exclude name=org/apache/catalina/ant/** /
exclude name=org/apache/catalina/launcher/** /
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
costin 2002/11/12 16:36:25
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
Added commons logging to the list of delegated jars.
This prevent some nasty class cast errors. ( that doesn't mean
apps can't use their own logging impl ).
Switch to c-l in the messages - that allows easier debugging of
loading problems ( I know it is possible to add the Loader to
Context, but using the single config file is much simpler ).
Revision ChangesPath
1.13 +111 -113
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- WebappClassLoader.java7 Nov 2002 18:03:10 - 1.12
+++ WebappClassLoader.java13 Nov 2002 00:36:25 - 1.13
-1,8 +1,4
/*
- * $Header$
- * $Revision$
- * $Date$
- *
*
*
* The Apache Software License, Version 1.1
-149,7 +145,11
*/
public class WebappClassLoader
extends URLClassLoader
-implements Reloader, Lifecycle {
+implements Reloader, Lifecycle
+ {
+
+private static org.apache.commons.logging.Log log=
+org.apache.commons.logging.LogFactory.getLog( WebappClassLoader.class );
protected class PrivilegedFindResource
implements PrivilegedAction {
-194,6 +194,7
org.xml.sax, // SAX 1 2
org.w3c.dom, // DOM 1 2
org.apache.xerces, // Xerces 1 2
+org.apache.commons.logging,// Commons logging.
org.apache.xalan // Xalan
};
-226,14 +227,15
public WebappClassLoader(ClassLoader parent) {
super(new URL[0], parent);
+
this.parent = getParent();
+
system = getSystemClassLoader();
securityManager = System.getSecurityManager();
if (securityManager != null) {
refreshPolicy();
}
-
}
-563,8 +565,8
if (repository == null)
return;
-if (debug = 1)
-log(addRepository( + repository + ));
+if (log.isDebugEnabled())
+log.debug(addRepository( + repository + ));
int i;
-597,8 +599,8
if (file == null)
return;
-if (debug = 1)
-log(addJar( + jar + ));
+if (log.isDebugEnabled())
+log.debug(addJar( + jar + ));
int i;
-684,8 +686,8
*/
public boolean modified() {
-if (debug = 2)
-log(modified());
+if (log.isDebugEnabled())
+log.debug(modified());
// Checking for modified loaded resources
int length = paths.length;
-703,14 +705,15
((ResourceAttributes) resources.getAttributes(paths[i]))
.getLastModified();
if (lastModified != lastModifiedDates[i]) {
-log( Resource ' + paths[i]
-+ ' was modified; Date is now:
-+ new java.util.Date(lastModified) + Was:
-+ new java.util.Date(lastModifiedDates[i]));
+if( log.isDebugEnabled() )
+log.debug( Resource ' + paths[i]
+ + ' was modified; Date is now:
+ + new java.util.Date(lastModified) + Was:
+ + new java.util.Date(lastModifiedDates[i]));
return (true);
}
} catch (NamingException e) {
-log(Resource ' + paths[i] + ' is missing);
+log.error(Resource ' + paths[i] + ' is missing);
return (true);
}
}
-731,8 +734,8
continue;
if (!name.equals(jarNames[i])) {
// Missing JAR
-log(Additional JARs have been added : '
-+ name + ');
+log.info(Additional JARs have been added : '
+ + name + ');
return (true);
}
i++;
-745,22 +748,22
// Additional non-JAR files are allowed
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java
costin 2002/11/12 16:40:14
Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
Log:
Port the /dev/urandom support from 3.3.
This is faster ( and probably more secure ) on linux ( or other
OSes that support a source of random - the name can be configured ).
Also switch to c-l for easier debugging.
Revision ChangesPath
1.3 +77 -20
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
Index: ManagerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ManagerBase.java 20 Sep 2002 21:22:31 - 1.2
+++ ManagerBase.java 13 Nov 2002 00:40:14 - 1.3
-68,6 +68,9
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import java.io.IOException;
+import java.io.DataInputStream;
+import java.io.File;
+import java.io.FileInputStream;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.ArrayList;
-92,10 +95,13
*/
public abstract class ManagerBase implements Manager {
-
+private static org.apache.commons.logging.Log log=
+org.apache.commons.logging.LogFactory.getLog( ManagerBase.class );
// - Instance Variables
+protected DataInputStream randomIS=null;
+protected String devRandomSource=/dev/urandom;
/**
* The default message digest algorithm to use if we cannot use
-322,22 +328,26
public synchronized MessageDigest getDigest() {
if (this.digest == null) {
-if (debug = 1)
-log(sm.getString(managerBase.getting, algorithm));
+long t1=System.currentTimeMillis();
+if (log.isDebugEnabled())
+log.debug(sm.getString(managerBase.getting, algorithm));
try {
this.digest = MessageDigest.getInstance(algorithm);
} catch (NoSuchAlgorithmException e) {
-log(sm.getString(managerBase.digest, algorithm), e);
+log.error(sm.getString(managerBase.digest, algorithm), e);
try {
this.digest = MessageDigest.getInstance(DEFAULT_ALGORITHM);
} catch (NoSuchAlgorithmException f) {
-log(sm.getString(managerBase.digest,
+log.error(sm.getString(managerBase.digest,
DEFAULT_ALGORITHM), e);
this.digest = null;
}
}
-if (debug = 1)
-log(sm.getString(managerBase.gotten));
+if (log.isDebugEnabled())
+log.debug(sm.getString(managerBase.gotten));
+long t2=System.currentTimeMillis();
+if( log.isDebugEnabled() )
+log.debug(getDigest() + (t2-t1));
}
return (this.digest);
-452,6 +462,35
}
+/** Use /dev/random-type special device. This is new code, but may reduce
the
+ * big delay in generating the random.
+ *
+ * You must specify a path to a random generator file. Use /dev/urandom
+ * for linux ( or similar ) systems. Use /dev/random for maximum security
+ * ( it may block if not enough random exist ). You can also use
+ * a pipe that generates random.
+ *
+ * The code will check if the file exists, and default to java Random
+ * if not found. There is a significant performance difference, very
+ * visible on the first call to getSession ( like in the first JSP )
+ * - so use it if available.
+ */
+public void setRandomFile( String s ) {
+ // as a hack, you can use a static file - and genarate the same
+ // session ids ( good for strange debugging )
+ try {
+ devRandomSource=s;
+ File f=new File( devRandomSource );
+ if( ! f.exists() ) return;
+ randomIS= new DataInputStream( new FileInputStream(f));
+ randomIS.readLong();
+ if( log.isDebugEnabled() )
+log.debug( Opening + devRandomSource );
+ } catch( IOException ex ) {
+ randomIS=null;
+ }
+}
+
/**
* Return the random number generator instance we should use for
-459,13 +498,12
* currently defined, construct and seed a new one.
*/
public synchronized Random getRandom() {
-
if (this.random == null) {
synchronized (this) {
if (this.random == null) {
Re: /admin 404
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, November 12, 2002 2:47 PM Subject: Re: /admin 404 I don't understand why I can't get it to work with xerces 2.1.0. I have updated all of my workspace and made sure I have the correct xerces 2.1.0 but still TLD errors. Bill, Can you get admin to work with 2.1.0? It's true that I'm still getting the messages in the log, but the webapp seems to be working fine. I'll have to take another look at 2.2.1, since I had thought that the message was enough to tell me that it was dead. Can someone else confirm that admin works with 2.1.0? confused Amy Jeanfrancois Arcand wrote: Yes, everythings works fine with the current build. -- Jeanfrancois Amy Roh wrote: I switched from 2.2.0 to 2.1.0. Still no admin. :-( I'm attaching the error logs for tomcat 4 and tomcat 5. The same following errors are displayed running Tomcat 5. Jeanfrancois, admin works for you with 2.1.0?? Thanks, Amy Nov 11, 2002 5:59:59 PM org.apache.catalina.startup.ContextConfig start SEVERE: Exception processing TLD at resource path /WEB-INF/struts-logic.tld javax.servlet.ServletException: Exception processing TLD at resource path /WEB-I NF/struts-logic.tld at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.ja va:1159) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java: 1011) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:78 3) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfi g.java:260) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3 718) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:822) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:80 8) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDe ployer.java:624) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.jav a:250) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:260) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1063) at org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXPar ser.java:585) at org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBind er.java:647) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement( XMLDocumentFragmentScannerImpl.java:1008) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent Dispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1469) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XM LDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav a:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav a:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.j ava:1175) at org.apache.commons.digester.Digester.parse(Digester.java:1561) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDep loyer.java:430) at org.apache.catalina.core.StandardHost.install(StandardHost.java:856) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.j ava:504) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:461 ) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:930) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java :420) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1203) at org.apache.catalina.core.StandardHost.start(StandardHost.java:791) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1195) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347 ) at
Re: /admin 404
Bill Barker wrote: - Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, November 12, 2002 2:47 PM Subject: Re: /admin 404 I don't understand why I can't get it to work with xerces 2.1.0. I have updated all of my workspace and made sure I have the correct xerces 2.1.0 but still TLD errors. Bill, Can you get admin to work with 2.1.0? It's true that I'm still getting the messages in the log, but the webapp seems to be working fine. I'll have to take another look at 2.2.1, since I had thought that the message was enough to tell me that it was dead. The problem is limited to org.apache.struts.action.ActionServlet (this servlet is not properly initialized), but the Admin tool is still installed properly. Are you seeing the problem with 2.1.0 as well? 2.2.1 doesn't seems to break when used with Struts 1.1b2 (at least from the limited testing I've made) I'm still working with the Xerces folks to find a solution (2.2.1 was supposed to fix the problem). The problem is I cannot reproduce the problem with a simple test case. If you have one, let me know :-) -- Jeanfrancois Can someone else confirm that admin works with 2.1.0? confused Amy Jeanfrancois Arcand wrote: Yes, everythings works fine with the current build. -- Jeanfrancois Amy Roh wrote: I switched from 2.2.0 to 2.1.0. Still no admin. :-( I'm attaching the error logs for tomcat 4 and tomcat 5. The same following errors are displayed running Tomcat 5. Jeanfrancois, admin works for you with 2.1.0?? Thanks, Amy Nov 11, 2002 5:59:59 PM org.apache.catalina.startup.ContextConfig start SEVERE: Exception processing TLD at resource path /WEB-INF/struts-logic.tld javax.servlet.ServletException: Exception processing TLD at resource path /WEB-I NF/struts-logic.tld at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.ja va:1159) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java: 1011) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:78 3) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfi g.java:260) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3 718) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:822) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:80 8) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDe ployer.java:624) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.jav a:250) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:260) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1063) at org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXPar ser.java:585) at org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBind er.java:647) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement( XMLDocumentFragmentScannerImpl.java:1008) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent Dispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1469) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XM LDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav a:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav a:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.j ava:1175) at org.apache.commons.digester.Digester.parse(Digester.java:1561) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDep loyer.java:430) at org.apache.catalina.core.StandardHost.install(StandardHost.java:856) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.j ava:504) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:461 ) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:930) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java :420) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:166) at
Tomcat Xerces
are now back to work together. Xerces 2.2.1 (released today) work/fix the parsing problem that magically appear with 2.2.0. Let see how long it will take to Xerces to break Tomcat again ;-) Just kidding FYI: Here are the version that works: 2.1.0, 2.2.1 doesn't work: 2.0.1, 2.0.2, 2.2 -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming ContextBindings.java
glenn 2002/11/12 18:23:11
Modified:catalina/src/share/org/apache/catalina/core
NamingContextListener.java StandardContext.java
catalina/src/share/org/apache/naming ContextBindings.java
Log:
Bug fix for BUG #13364
A Web Application Context reload by the manager web application
was causing named JNDI resources to disappear.
A webapp reload needs to dump the webapp classloader, then
recreate. The CL is bound to the naming context so the
reload was issing a NamingContext STOP_EVENT and then a
START_EVENT. This removed all the JNDI named resources
but the code which runs at webapp startup which creates
the JNDI named resources is not run on a reload.
I fixed this by removing the START and STOP events and
adding BEFORE_STOP_EVENT and AFTER_START_EVENT
lifecycle events whose only purpose is to bind or unbind the
ClassLoader to the JNDI context.
Defined JNDI resources are now preserved on a web app reload.
Revision ChangesPath
1.20 +43 -18
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/NamingContextListener.java
Index: NamingContextListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/NamingContextListener.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- NamingContextListener.java25 Jun 2002 22:29:23 - 1.19
+++ NamingContextListener.java13 Nov 2002 02:23:10 - 1.20
-293,26 +293,13
log(sm.getString(naming.namingContextCreationFailed, e));
}
-// Binding the naming context to the class loader
-if (container instanceof Context) {
-// Setting the context in read only mode
-ContextAccessController.setReadOnly(getName());
-try {
-ContextBindings.bindClassLoader
-(container, container,
- ((Container) container).getLoader().getClassLoader());
-} catch (NamingException e) {
-log(sm.getString(naming.bindFailed, e));
-}
-}
-
if (container instanceof Server) {
namingResources.addPropertyChangeListener(this);
org.apache.naming.factory.ResourceLinkFactory.setGlobalContext
(namingContext);
try {
ContextBindings.bindClassLoader
-(container, container,
+(container, container,
this.getClass().getClassLoader());
} catch (NamingException e) {
log(sm.getString(naming.bindFailed, e));
-321,9 +308,47
((StandardServer) container).setGlobalNamingContext
(namingContext);
}
+} else if (container instanceof Context) {
+// Setting the context in read only mode
+ContextAccessController.setReadOnly(getName());
+try {
+ContextBindings.bindClassLoader
+(container, container,
+ ((Container) container).getLoader().getClassLoader());
+} catch (NamingException e) {
+log(sm.getString(naming.bindFailed, e));
+}
}
initialized = true;
+
+} else if (event.getType() == Lifecycle.AFTER_START_EVENT ) {
+// Used at end of a Web Application Context reload
+if (container instanceof Context) {
+// Setting the context in read only mode
+ContextAccessController.setReadOnly(getName());
+try {
+ContextBindings.bindClassLoader
+(container, container,
+ ((Container) container).getLoader().getClassLoader());
+} catch (NamingException e) {
+log(sm.getString(naming.bindFailed, e));
+}
+}
+
+} else if (event.getType() == Lifecycle.BEFORE_STOP_EVENT) {
+// Used when starting a Web Application Context reload
+if (!initialized)
+return;
+
+// Setting the context in read/write mode
+ContextAccessController.setWritable(getName(), container);
+
+if (container instanceof Context) {
+ContextBindings.unbindClassLoader
+(container, container,
+ ((Container) container).getLoader().getClassLoader());
+}
} else if
DO NOT REPLY [Bug 13364] - JNDI DataSource not available after manager reload
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=13364. 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=13364 JNDI DataSource not available after manager reload [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-13 02:25 --- Patch to preventJNDI named resources from disappearing during a webapp reload has been committed to CVS -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13364] - JNDI DataSource not available after manager reload
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=13364. 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=13364 JNDI DataSource not available after manager reload [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: /admin 404
- Original Message - From: Jeanfrancois Arcand [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, November 12, 2002 5:09 PM Subject: Re: /admin 404 Bill Barker wrote: - Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, November 12, 2002 2:47 PM Subject: Re: /admin 404 I don't understand why I can't get it to work with xerces 2.1.0. I have updated all of my workspace and made sure I have the correct xerces 2.1.0 but still TLD errors. Bill, Can you get admin to work with 2.1.0? It's true that I'm still getting the messages in the log, but the webapp seems to be working fine. I'll have to take another look at 2.2.1, since I had thought that the message was enough to tell me that it was dead. The problem is limited to org.apache.struts.action.ActionServlet (this servlet is not properly initialized), but the Admin tool is still installed properly. Are you seeing the problem with 2.1.0 as well? That's what I get for letting ant copy things for me. When I copy the jars myself, then 2.1.0 doesn't have an exception in the log. Trying with 2.2.1, I get the exception in the log, but the context loads and seems to run Ok. When I first put it up on this box with the default 2.2.0, I remember that the context wouldn't even load. Since I didn't really need admin, I just disabled it. 2.2.1 doesn't seems to break when used with Struts 1.1b2 (at least from the limited testing I've made) I'm still working with the Xerces folks to find a solution (2.2.1 was supposed to fix the problem). The problem is I cannot reproduce the problem with a simple test case. If you have one, let me know :-) For me, all I have to do is to run Tomcat 4.1 out of the box using JVM 1.3.1 on Solaris. -- Jeanfrancois Can someone else confirm that admin works with 2.1.0? confused Amy Jeanfrancois Arcand wrote: Yes, everythings works fine with the current build. -- Jeanfrancois Amy Roh wrote: I switched from 2.2.0 to 2.1.0. Still no admin. :-( I'm attaching the error logs for tomcat 4 and tomcat 5. The same following errors are displayed running Tomcat 5. Jeanfrancois, admin works for you with 2.1.0?? Thanks, Amy Nov 11, 2002 5:59:59 PM org.apache.catalina.startup.ContextConfig start SEVERE: Exception processing TLD at resource path /WEB-INF/struts-logic.tld javax.servlet.ServletException: Exception processing TLD at resource path /WEB-I NF/struts-logic.tld at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.ja va:1159) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java: 1011) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:78 3) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfi g.java:260) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3 718) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:822) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:80 8) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDe ployer.java:624) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.jav a:250) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:260) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1063) at org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXPar ser.java:585) at org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBind er.java:647) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement( XMLDocumentFragmentScannerImpl.java:1008) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent Dispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1469) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XM LDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav a:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav a:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
DO NOT REPLY [Bug 8817] - nested custom jsp tags not working?
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=8817. 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=8817 nested custom jsp tags not working? [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2002-11-13 03:46 --- Jan Luehe's suggestion was the right one. After the jsp pages were re- compiled, the problem was resolved. Thanks Jan! -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
billbarker2002/11/12 22:10:38
Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
Log:
Add a flag to disable adding headers to prevent proxies from caching the content of
protected pages.
I strongly want this in 4.1, but committing here first since the topic is a bit
controversial. The out-of-the-box behavior is the same as before. This just adds a
much-asked-for configuration setting for webmasters that don't want this behavior.
Revision ChangesPath
1.4 +28 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AuthenticatorBase.java9 Aug 2002 01:12:39 - 1.3
+++ AuthenticatorBase.java13 Nov 2002 06:10:38 - 1.4
-194,6 +194,11
protected static final String info =
org.apache.catalina.authenticator.AuthenticatorBase/1.0;
+/**
+ * Flag to determine if we disable proxy caching, or leave the issue
+ * up to the webapp developer.
+ */
+protected boolean noProxyCaching = true;
/**
* The lifecycle event support for this component.
-388,6 +393,23
}
+/**
+ * Return the flag that states if we add headers to disable caching by
+ * proxies.
+ */
+public boolean getNoProxyCaching() {
+return noProxyCaching;
+}
+
+/**
+ * Set the value of the flag that states if we add headers to disable
+ * caching by proxies.
+ * param nocache codetrue/code if we add headers to disable proxy
+ * caching, codefalse/code if we leave the headers alone.
+ */
+public void setNoProxyCaching(boolean nocache) {
+noProxyCaching = nocache;
+}
// - Public Methods
-479,7 +501,8
// Make sure that constrained resources are not cached by web proxies
// or browsers as caching can provide a security hole
-if (!(((HttpServletRequest) hrequest.getRequest()).isSecure())) {
+if (noProxyCaching
+!(((HttpServletRequest) hrequest.getRequest()).isSecure())) {
HttpServletResponse sresponse =
(HttpServletResponse) response.getResponse();
sresponse.setHeader(Pragma, No-cache);
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticatorAuthenticatorBase.java
[EMAIL PROTECTED] wrote: billbarker2002/11/12 22:10:38 Modified:catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java Log: Add a flag to disable adding headers to prevent proxies from caching the content of protected pages. I strongly want this in 4.1, but committing here first since the topic is a bit controversial. The out-of-the-box behavior is the same as before. This just adds a much-asked-for configuration setting for webmasters that don't want this behavior. +1 for porting (this should be clear that this is potentially unsafe). Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
