Re: Fwd: Re: Tomcat and LDAP Issues
Jeff, I see nine bugs out there for JNDIRealm for tomat 4 and 5, included is the one mentioned below in the previous email. http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Tomcat+4product=Tomcat+5short_desc=jndirealmshort_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Reuse+same+sort+as+last+time I have used JNDIRealm in the past but stopped using it in favor of other solutions for unrelated reasons. Can you do me a favor? If you are able, can you update the bugs above and send me a patch for the stuff below (and any applicable bugs above) and I'll try to get 'em in next week. -Tim Jeff Tulley wrote: Something from the user list of note for development. The current method does something like this when handling a communication exception at authenticate time: / If not a Socket closed. error then rethrow. if (e.getMessage().indexOf(Socket closed) 0) throw(e); This seems to have two problems 1) e.getMessage() is sometimes null with some LDAP providers. 2) some LDAP providers set the exception to actually be connection closed (retrieved by e.toString()) Just forwarding this on for the user, since this code currently has some problems that ought to be fixed. (I have a vested interest being a heavy user of JNDIRealm). For a stopgap measure, one could do the following I guess: if (e.toString().indexOf(closed) 0) throw(e); Though as the bug report points out there may be yet other error messages given by other LDAP providers, and I don't know if closed is too general to check on or not. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/1/03 2:00:46 PM Well, I understand this is now a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19864 Was this fixed in the 4.1.27 version? Can't seem to determine if it was based on the README in the download. Jon On Friday, August 1, 2003, at 12:07 PM, Jon Wynacht wrote: Hi, I have Tomcat 4.1.24 installed on a server that hosts a web application. I have set up the container to do authentication via LDAP and it works for a bit then just stops working. The only way to get things working again is to restart Tomcat. I've included the error message below and am wondering if anybody on this list has had a similar experience? If so, how did you solve it? Thanks in advance, Jon 2003-08-01 10:37:29 JNDIRealm[Standalone]: lookupUser(jwynacht) 2003-08-01 10:37:29 JNDIRealm[Standalone]: dn=uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com 2003-08-01 10:37:29 JNDIRealm[Standalone]: validating credentials by binding as the user 2003-08-01 10:37:29 JNDIRealm[Standalone]: binding as uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com 2003-08-01 10:37:29 CoyoteAdapter An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:793) at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(Basic Authenticator.java:161) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticato rBase.java:526) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:24 15) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav a:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV alve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav a:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve .java:174) at
Re: [VOTE] Release mod_jk 1.2.5
From: Henri Gomez [EMAIL PROTECTED] The future will be mod_jk2, and I think we should focus on it after the 1.2.5 release. Ok. I jumped in on this thread because I thought that a new problem was introduced, but that is how it was in prior releases. I can report 1.2.5 works fine on OpenBSD-current/i386. I will keep working on OpenBSD/sparc64 and post patches here when it is working. If there's a 1.2.6 release maybe they can be incorporated then. Surely, jk 1.2.6 could be the release with OpenBSD/sparc64 support, we should fix this hack around the in_addr_t and of course add the Ipv6 support since an IP adress won't fix into a 32 bits integer for too long. Work on patch and we'll see how to make them useable for other OS, I think the rigth way is via in_addr_t I done more testing this morning and have determined that the u_long is the only bug preventing mod_jk from working on OpenBSD/sparc64. The other issues on OpenBSD/sparc64 that I was referring to seem to be related to my install of tomcat 4.0.6. I setup a new tomcat 4.1.27 install on a different box and mod_jk on OpenBSD/sparc64 works fine with it (with the datatype change). Is it too late to incorporate a change for the 1.2.5 release? You and David Rees have pointed out the in_addr_t is the correct type to use for inet_addr. Would it not make sense to change it to that and have a define for the iSeries? I would supply a patch, but I don't have an iSeries available. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation of the server.xml
On Sat, 2 Aug 2003, Yoko Kamei Harada wrote: Date: Sat, 02 Aug 2003 11:23:23 +0900 (JST) From: Yoko Kamei Harada [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Validation of the server.xml From: Craig R. McClanahan [EMAIL PROTECTED] Subject: Re: Validation of the server.xml Date: Fri, 1 Aug 2003 09:15:22 -0700 (PDT) On Fri, 1 Aug 2003, Sabine Winkler wrote: may be, this isn't really important but why is there no DTD or scheme to validate the server.xml ? in combination with the defined DTD for validating the mbeans descriptor file this should be a 'nice' feature. so if You are interested in developing / using such a scheme I would start to define one. Interest ??? A complete DTD (and I'm pretty sure even a schema) for server.xml, which would support the current level of functionality, is not technically feasible. How about RELAX NG (http://relaxng.org/) ? RELAX NG is a schema language for XML. RELAX NG has a include feature, so RELAX NG allows merging plural schemas. How would you specify the rules (even in English) for Valve? The set of attributes recognized by every Valve implementation class in the world is different. And the same thing applies to all the other elements -- the valid set of attributes depends on the implementation class pointed at with the className attribute, or the default one that is built in as described in the docs. Validation rules would have to include the ability to introspect the corresponding Java classes in order to identify the legal attribute names. And the schema compiler for RELAX NG such as JAXB and Relaxer(http://www.relaxer.org/) maps the schema to Java classes. If tomcat provides some rules for schemas to include, it is easy to get Java objects from XML documents. The server.xml will be a plugable and valid document. I'm going to remain a skeptic until someone shows me it is possible, by actually doing it for at least a couple of server.xml elements :-). Don't get me wrong -- I agree that such a thing would be useful -- I just don't think it can be done. --- HARADA, Yoko Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
remm2003/08/02 10:15:54
Modified:.build.xml
Log:
- Initialize filter so that the release notes of the docs look right.
Revision ChangesPath
1.147 +2 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.146
retrieving revision 1.147
diff -u -r1.146 -r1.147
--- build.xml 29 Jul 2003 15:14:39 - 1.146
+++ build.xml 2 Aug 2003 17:15:54 - 1.147
@@ -558,6 +558,8 @@
target name=fix-webapps depends=init
!-- Extra build steps for webapps --
+filter token=VERSION value=${version}/
+
!-- Add release notes to the root webapp --
copy file=./RELEASE-NOTES
tofile=${tomcat.build}/webapps/ROOT/RELEASE-NOTES.txt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5/resources welcome.main.html
remm2003/08/02 10:16:27 Modified:resources welcome.main.html Log: - Add additional information. Revision ChangesPath 1.2 +8 -2 jakarta-tomcat-5/resources/welcome.main.html Index: welcome.main.html === RCS file: /home/cvs/jakarta-tomcat-5/resources/welcome.main.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- welcome.main.html 9 Oct 2002 10:06:07 - 1.1 +++ welcome.main.html 2 Aug 2003 17:16:27 - 1.2 @@ -6,8 +6,14 @@ P H3Apache Tomcat @VERSION@/H3 P/P -PPlease see the a href=RELEASE-NOTESRELEASE-NOTES/a for important -information about recent bug fixes and known issues. /P +pUseful references: +ul +lia href=RELEASE-NOTESRelease notes/a, with important information +about known issues/li +lia href=http://jakarta.apache.org/tomcat/tomcat-5.0-doc/changelog.html;Changelog/a/li +lia href=http://jakarta.apache.org/tomcat/tomcat-5.0-doc/status.html;Status/a/li +/ul +/p pbNOTE: The tar files in this distribution use GNU tar extensions, and must be untarred with a GNU compatible version of tar. The version of CODEtar/CODE on Solaris and Mac OS X will not work with - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java RequestDumperValve.java
remm2003/08/02 10:31:04 Modified:catalina/src/share/org/apache/catalina/valves ErrorReportValve.java RequestDumperValve.java Log: - Remove bad import. Revision ChangesPath 1.8 +4 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java Index: ErrorReportValve.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- ErrorReportValve.java 29 Jul 2003 12:19:06 - 1.7 +++ ErrorReportValve.java 2 Aug 2003 17:31:04 - 1.8 @@ -91,7 +91,6 @@ import org.apache.catalina.Response; import org.apache.catalina.Valve; import org.apache.catalina.ValveContext; -import org.apache.catalina.connector.HttpResponseWrapper; import org.apache.catalina.util.RequestUtil; import org.apache.catalina.util.ServerInfo; import org.apache.catalina.util.StringManager; 1.2 +4 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java Index: RequestDumperValve.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- RequestDumperValve.java 18 Jul 2002 16:47:42 - 1.1 +++ RequestDumperValve.java 2 Aug 2003 17:31:04 - 1.2 @@ -83,7 +83,6 @@ import org.apache.catalina.Response; import org.apache.catalina.Valve; import org.apache.catalina.ValveContext; -import org.apache.catalina.connector.HttpResponseWrapper; import org.apache.catalina.util.StringManager; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util ExtensionValidator.java
remm2003/08/02 10:40:31
Modified:catalina/src/share/org/apache/catalina/util
ExtensionValidator.java
Log:
- Tomcat will now ignore a non existent classpath JAR.
Revision ChangesPath
1.7 +17 -8
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/ExtensionValidator.java
Index: ExtensionValidator.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/ExtensionValidator.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ExtensionValidator.java 31 Jul 2003 20:56:25 - 1.6
+++ ExtensionValidator.java 2 Aug 2003 17:40:30 - 1.7
@@ -119,8 +119,12 @@
private static HashMap containerAvailableExtensions = null;
private static ArrayList containerManifestResources = null;
private static ResourceBundle messages = null;
-
-/*
+
+
+// --- Constructors
+
+
+/**
* Access to this class can only be made through the factory method
* getInstance()
*
@@ -144,7 +148,10 @@
while (strTok.hasMoreTokens()) {
String classpathItem = strTok.nextToken();
if (classpathItem.toLowerCase().endsWith(.jar)) {
-addSystemResource(new File(classpathItem));
+File item = new File(classpathItem);
+if (item.exists()) {
+addSystemResource(item);
+}
}
}
@@ -168,8 +175,10 @@
}
}
+
// - Public Methods
-
+
+
/**
* Runtime validation of a Web Applicaiton.
*
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
remm2003/08/02 10:42:59
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- Some steps of startup shouldn't be executed if the context startup has
previously encountered errors.
Revision ChangesPath
1.79 +9 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.78
retrieving revision 1.79
diff -u -r1.78 -r1.79
--- StandardContext.java 1 Aug 2003 06:14:40 - 1.78
+++ StandardContext.java 2 Aug 2003 17:42:59 - 1.79
@@ -3823,12 +3823,12 @@
dependencyCheck = validator.validateApplication(getResources(),
this);
} catch (IOException ioe) {
+log.error(Error in dependencyCheck, ioe);
dependencyCheck = false;
}
if (!dependencyCheck) {
// do not make application available if depency check fails
-log.error( Error in dependencyCheck);
ok = false;
}
@@ -3981,15 +3981,17 @@
}
// JMX registration
-registerJMX();
+if (ok) {
+registerJMX();
-// Notify our interested LifecycleListeners
-lifecycle.fireLifecycleEvent(AFTER_START_EVENT, null);
-startTime=System.currentTimeMillis();
+// Notify our interested LifecycleListeners
+lifecycle.fireLifecycleEvent(AFTER_START_EVENT, null);
+}
+startTime=System.currentTimeMillis();
// Send j2ee.state.running notification
-if (this.getObjectName() != null) {
+if (ok (this.getObjectName() != null)) {
Notification notification =
new Notification(j2ee.state.running, this.getObjectName(),
sequenceNumber++);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Function of o.a.catalina.connector.(Http)Request/ResponseWrapper
Are these four classes useful ? They are not used anywhere (and I believe using them will break the pipeline, as some parts now depend on the CoyoteRequest/Response). I'll remove them. Please complain if you want them back for some reason :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-5.0.5 cannot access jar resources in WEB-INF/lib but o nly unzipped in WEB-INF/classes
Harmsen, Jan wrote: Please provide a test case along with infomation on your environment. okay, tomorrow I'll provide a test case + description, Any update on this ? This is obviously a big problem if the issue is valid, so I'd really appreciate your help. Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22040] - NullPointerException when invoking getSession in Filter
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=22040. 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=22040 NullPointerException when invoking getSession in Filter --- Additional Comments From [EMAIL PROTECTED] 2003-08-02 17:52 --- I have never been able to reproduce this issue. Can you provide a simple test case to reproduce it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs html-manager-howto.xml
remm2003/08/02 10:51:15 Modified:webapps/docs html-manager-howto.xml Log: - HTML manager docs update. Revision ChangesPath 1.3 +40 -38jakarta-tomcat-catalina/webapps/docs/html-manager-howto.xml Index: html-manager-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/html-manager-howto.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- html-manager-howto.xml30 Jul 2003 18:37:06 - 1.2 +++ html-manager-howto.xml2 Aug 2003 17:51:15 - 1.3 @@ -27,7 +27,7 @@ help./li listrongApplications/strong - List of web applications and commands./li - listrongInstall/strong - Installing web applications./li + listrongDeploy/strong - Deploying web applications./li listrongServer Information/strong - Information about the Tomcat server./li /ul @@ -91,7 +91,7 @@ listrongReload/strong - Reload the web application so that new .jar files in code/WEB-INF/lib//code or new classes in code/WEB-INF/classes//code can be used./li -listrongRemove/strong - Stop and then remove this web +listrongUndeploy/strong - Stop and then remove this web application from the server./li /ul /li @@ -127,7 +127,7 @@ /blockquote/li liemNo context exists for path /foo/em blockquote -pThere is no deployed or installed application on the context path +pThere is no deployed application on the context path that you specified./p /blockquote/li liemNo context path was specified/em @@ -142,7 +142,7 @@ subsection name=Stop pSignal an existing application to make itself unavailable, but leave it -deployed or installed. Any request that comes in while an application is +deployed. Any request that comes in while an application is stopped will see an HTTP error 404, and this application will show as stopped on a list applications command./p @@ -167,7 +167,7 @@ /blockquote/li liemNo context exists for path /foo/em blockquote -pThere is no deployed or installed application on the context path +pThere is no deployed application on the context path that you specified./p /blockquote/li liemNo context path was specified/em @@ -215,7 +215,7 @@ /blockquote/li liemNo context exists for path /foo/em blockquote -pThere is no deployed or installed application on the context path +pThere is no deployed application on the context path that you specified./p /blockquote/li liemNo context path was specified/em @@ -226,17 +226,18 @@ blockquote Currently, application reloading (to pick up changes to the classes or codeweb.xml/code file) is not supported when a web application is -installed directly from a WAR file. It only works when the web application -is installed from an unpacked directory. If you are using a WAR file, -you should coderemove/code and then codeinstall/code the -application again to pick up your changes. +installed directly from a WAR file, which happens when the host is +configured to not unpack WAR files. As it only works when the web +application is installed from an unpacked directory, if you are using +a WAR file, you should codeundeploy/code and then codedeploy/code +the application again to pick up your changes. /blockquote/li /ul /p /subsection -subsection name=Remove +subsection name=Undeploy pstrongfont color=redWARNING/font - This command will delete the contents of the web application directory and/or .war file if it exists within @@ -248,11 +249,12 @@ pSignal an existing application to gracefully shut itself down, and then remove it from Tomcat (which also makes this context path available for reuse later). This command is the logical opposite of the -code/install/code command./p +code/deploy/code Ant command, and the related deploy features available +in the HTML manager./p pIf this command succeeds, you will see a Message like this:/p source -OK - Removed application at context path /examples +OK - Undeployed application at context path /examples /source pOtherwise, the Message will start with codeFAIL/code and include an @@ -260,8 +262,8 @@ ul liemEncountered exception/em blockquote -pAn exception was encountered trying to remove the web application. -Check the Tomcat 4 logs for the details./p +
DO NOT REPLY [Bug 22082] New: - Variable substiturion not working for server.xml
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=22082.
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=22082
Variable substiturion not working for server.xml
Summary: Variable substiturion not working for server.xml
Product: Tomcat 4
Version: 4.1.24
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Major
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
First off, is this feature deprecated? I can find NO REFERENCE for the life of
me in the 4.1 docs for variable substitution, so there is a chance this was
changed and not documented anywhere.
According to the 3.3 manual, variable substitution SHOULD work:
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html
There is no correspnding page in the 4.1 manual (oversight?) so I can not tell
if that data is accurate. In order to pass in an environment variable (in my
case the bind IP for a developer instance), it would appear one should do:
tomcat.sh start -bind.ip=1.2.3.4
However, since 3.3:
tomcat.sh is now catalina.sh?
there is no support for options past the start argument
it appears JAVA_OPTS is now preferred.
So I set JAVA_OPTS=-Dbind.ip=1.2.3.4, and verified that declaration was
passed to the JVM. No problem there. However, catalina does not respect my
server.xml reference to the property:
!-- HTTP 1.1 Listener on port 8080 --
Connector className=org.apache.coyote.tomcat4.CoyoteConnector
address=${bind.ip}
port=8080
And reports the following in the error log:
VM Started:
IntrospectionUtils: Unable to resolve host name:${bind.ip}
Aug 7, 2003 8:35:26 AM org.apache.coyote.http11.Http11Protocol init
This is at the very least a break in documentation since there is no general
server.xml reference documnent, and appears to be a bug in the app as well.
This is a major pain since now I need to customize each server.xml for each
developer and then all are out of sync with CVS. Please Fix!!!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22084] New: - JSP compiler incorrectly indents code
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=22084. 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=22084 JSP compiler incorrectly indents code Summary: JSP compiler incorrectly indents code Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If the text in a TemplateText node ends in \n, then if the mappedfile init parameter is set to true, or the line length exceeds CHUNKSIZE, the first line of Java code generated from the succeeding node will be indented too far. The problem is that when visit(Node.TemplateText n) in Generator.java sees the \n, it finishes the current line, and then calls out.printin() in order to properly indent the text that follows. This works fine if there is text that follows, but if there isn't, the effect is to overindent the first line in whatever code is generated by the next node to be visited. I will attach a patch that fixes this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22084] - JSP compiler incorrectly indents code
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=22084. 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=22084 JSP compiler incorrectly indents code --- Additional Comments From [EMAIL PROTECTED] 2003-08-02 19:59 --- Created an attachment (id=7627) Proposed patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22084] - JSP compiler incorrectly indents code
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=22084. 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=22084 JSP compiler incorrectly indents code [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java
billbarker2003/08/02 20:19:08
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java
Log:
Temporary fix for running SSL without a SocketFactory.
This patch doesn't play well with JMX, but I'm intending to do a general JMX cleanup
of the Connector next week, and will remove the method then. This is only so that I
can commit server.xml and have it run.
Revision ChangesPath
1.19 +25 -8
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- CoyoteConnector.java 31 Jul 2003 00:19:42 - 1.18
+++ CoyoteConnector.java 3 Aug 2003 03:19:08 - 1.19
@@ -690,11 +690,6 @@
*/
public ServerSocketFactory getFactory() {
-if (this.factory == null) {
-synchronized (this) {
-this.factory = new DefaultServerSocketFactory();
-}
-}
return (this.factory);
}
@@ -1314,7 +1309,7 @@
ssf.getCiphers());
} else {
IntrospectionUtils.setProperty(protocolHandler, secure,
-+ false);
++ secure);
}
/* Set the configured properties. This only sets the ones that were
@@ -1325,7 +1320,8 @@
while( keys.hasNext() ) {
String name = (String)keys.next();
String value = properties.get(name).toString();
-IntrospectionUtils.setProperty(protocolHandler, name, value);
+ String trnName = translateAttributeName(name);
+IntrospectionUtils.setProperty(protocolHandler, trnName, value);
}
@@ -1336,6 +1332,27 @@
(sm.getString
(coyoteConnector.protocolHandlerInitializationFailed, e));
}
+}
+
+/**
+ * Translate the attribute name from the legacy Factory names to their
+ * internal protocol names.
+ */
+private String translateAttributeName(String name) {
+ if(clientAuth.equals(name)) {
+ return clientauth;
+ } else if(keystoreFile.equals(name)) {
+ return keystore;
+ } else if(randomFile.equals(name)) {
+ return randomfile;
+ } else if(rootFile.equals(name)) {
+ return rootfile;
+ } else if(keystorePass.equals(name)) {
+ return keypass;
+ } else if(keystoreType.equals(name)) {
+ return keytype;
+ }
+ return name;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf server.xml
billbarker2003/08/02 20:21:58 Modified:catalina/src/conf server.xml Log: Removing the Factory element in the default SSL configuration. Revision ChangesPath 1.21 +2 -3 jakarta-tomcat-catalina/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- server.xml29 Jul 2003 15:26:43 - 1.20 +++ server.xml3 Aug 2003 03:21:58 - 1.21 @@ -100,9 +100,8 @@ Connector port=8443 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true - acceptCount=100 debug=0 scheme=https secure=true - Factory clientAuth=false protocol=TLS / -/Connector + acceptCount=100 debug=0 scheme=https secure=true + clientAuth=false sSLprotocol=TLS / -- !-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Function of o.a.catalina.connector.(Http)Request/ResponseWrapper
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, August 02, 2003 10:44 AM Subject: [5.0] Function of o.a.catalina.connector.(Http)Request/ResponseWrapper Are these four classes useful ? They are not used anywhere (and I believe using them will break the pipeline, as some parts now depend on the CoyoteRequest/Response). I'll remove them. Please complain if you want them back for some reason :) I had thought that we had already voted to remove the o.a.c.connector.** package entirely from TC 5. I'll repeat my +1 for removing o.a.c.connector.**. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
