[GUMP@vmgump]: Project tomcat-taglibs-standard (in module tomcat-taglibs) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project tomcat-taglibs-standard has an issue affecting its community
integration.
This issue affects 2 projects,
and has been outstanding for 117 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-taglibs-standard : Standard Taglib
- tomcat-taglibs-standard-install : JSP Taglibs
Full details are available at:
http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-INFO- Optional dependency httpunit failed with reason build failed
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/tomcat-taglibs/standard/pom.xml
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/gump_work/build_tomcat-taglibs_tomcat-taglibs-standard.html
Work Name: build_tomcat-taglibs_tomcat-taglibs-standard (Type: Build)
Work ended in a state of : Failed
Elapsed: 25 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml
install
[Working Directory: /srv/gump/public/workspace/tomcat-taglibs/standard]
M2_HOME: /opt/maven2
-
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/tomcat-taglibs/standard/spec/src/test/resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing
/srv/gump/public/workspace/tomcat-taglibs/standard/spec/target/taglibs-standard-spec-1.2-SNAPSHOT.jar
to
/srv/gump/public/workspace/mvnlocalrepo/shared/org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/taglibs-standard-spec-1.2-SNAPSHOT.jar
[INFO] [bundle:install {execution: default-install}]
[INFO] Parsing
file:/srv/gump/public/workspace/mvnlocalrepo/shared/repository.xml
[INFO] Installing
org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/taglibs-standard-spec-1.2-SNAPSHOT.jar
[INFO] Writing OBR metadata
[INFO]
[INFO] Building JSTL Implementation
[INFO]task-segment: [install]
[INFO]
[INFO] [remote-resources:process {execution: default}]
[INFO] snapshot org.apache.taglibs:taglibs-standard-spec:1.2-SNAPSHOT: checking
for updates from apache.snapshots
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 14 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 96 source files to
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[INFO] 1 error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO] --
Re: svn commit: r1394452 - in /tomcat/native/branches/1.1.x: java/org/apache/tomcat/jni/SSL.java java/overview.html xdocs/miscellaneous/changelog.xml
2012/10/5 Christopher Schultz : > Konstantin, > > On 10/5/12 7:33 AM, kkoli...@apache.org wrote: >> Author: kkolinko >> Date: Fri Oct 5 11:33:22 2012 >> New Revision: 1394452 >> >> URL: http://svn.apache.org/viewvc?rev=1394452&view=rev >> Log: >> Followup to r1394343: Update javadoc for hasOp method. >> It seems that is the only place where this method is documented. >> >> Note that Java classes are present in native/branches/1.1.x but do not exist >> in native/trunk. >> >> Modified: >> tomcat/native/branches/1.1.x/java/org/apache/tomcat/jni/SSL.java >> tomcat/native/branches/1.1.x/java/overview.html >> tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml >> >> Modified: tomcat/native/branches/1.1.x/java/org/apache/tomcat/jni/SSL.java > > Shouldn't that code just be removed entirely? I didn't update the Java > code in the tcnative project because I don't believe it's been kept > up-to-date for a while, has it? > 1. I do not see a reason to remove it from the branch. 2. I just though that behaviour /requirements/expectations of hasOp() must be documented somewhere. The old Javadoc correctly documented that the only flag that it supported was that legacy renegotiation one. If we consider the java classes in tomcat/trunk as the main source of java classes for tcnative, then I think this javadoc update could be applied there as well. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1394104 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/connector/ webapps/docs/ webapps/docs/config/
2012/10/5 Christopher Schultz :
> Konstantin,
>
> On 10/5/12 8:45 AM, Konstantin Kolinko wrote:
>> 2012/10/4 :
>>> Author: markt
>>> Date: Thu Oct 4 14:55:59 2012
>>> New Revision: 1394104
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1394104&view=rev
>>> Log:
>>> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48692
>>> Provide option to parse application/x-www-form-urlencoded PUT requests
>>>
>>> Modified:
>>> tomcat/tc6.0.x/trunk/STATUS.txt
>>> tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java
>>>
>>> tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/LocalStrings.properties
>>> tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java
>>> tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
>>> tomcat/tc6.0.x/trunk/webapps/docs/config/ajp.xml
>>> tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml
>>>
>>
>>> (...)
>>> Modified:
>>> tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java
>>> URL:
>>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java?rev=1394104&r1=1394103&r2=1394104&view=diff
>>> ==
>>> --- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java
>>> (original)
>>> +++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java
>>> Thu Oct 4 14:55:59 2012
>>> @@ -2596,7 +2596,7 @@ public class Request
>>> if (usingInputStream || usingReader)
>>> return;
>>>
>>> -if (!getMethod().equalsIgnoreCase("POST"))
>>> +if( !getConnector().isParseBodyMethod(getMethod()) )
>>> return;
>>
>>
>> It seems a bug crawled in.
>> The old behaviour: case-insensitive. equalsIgnoreCase("POST")
>> The new behaviour: case-sensitive (parseBodyMethodsSet.contains(method))
>>
>> That is unless the method name is converted to uppercase somewhere.
>> I have not yet checked what HTTP spec says on method names.
>
> RFCs 2616, 2068, and 1945 all agree that method name is case-sensitive:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1
>
OK. Agreed.
Looking at Servlet spec 2.5, SRV.3.1.1 says "The HTTP method is POST".
I tested 6.0.35 using telnet as a client.
The result is that it sometimes allow lowercase methods (or maybe it
does not care about a method in that case) but generally it responds
with an error.
get /index.jsp HTTP/1.0
post /index.jsp HTTP/1.0
- result in the welcome page being rendered
get / HTTP/1.0
- results in
HTTP/1.1 501 Not Implemented
The getMethod() call returns the name as is, as can be seen by adding
%m to the AccessLogValve pattern.
So there is no need for case-insensivity there. If someone has odd
clients that use unusual methods, one can add their specific values to
the parseBodyMethods list.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 52055] ChunkedInputFilter is not recycled for servlet 3.0 asynchronous request
https://issues.apache.org/bugzilla/show_bug.cgi?id=52055 --- Comment #17 from Konstantin Kolinko --- (In reply to comment #14) The needCRLFParse fix was backported to 5.5 in r1359748 and will be in 5.5.36. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1395081 - /tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml
Author: kkolinko Date: Sat Oct 6 14:59:04 2012 New Revision: 1395081 URL: http://svn.apache.org/viewvc?rev=1395081&view=rev Log: Add changelog entry for r1359748 Modified: tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml Modified: tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml?rev=1395081&r1=1395080&r2=1395081&view=diff == --- tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml (original) +++ tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml Sat Oct 6 14:59:04 2012 @@ -101,6 +101,11 @@ chunk-extension suffix, not trying to parse digits contained in it. Reject chunks whose header is incorrect. (kkolinko) + +52055 (comment 14): Correctly reset +ChunkedInputFilter.needCRLFParse flag when the filter +is recycled. (kkolinko) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1395086 - /tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml
Author: kkolinko Date: Sat Oct 6 15:03:17 2012 New Revision: 1395086 URL: http://svn.apache.org/viewvc?rev=1395086&view=rev Log: Correction. The change for 1359748 was already mentioned, though it did not have the bug number. Modified: tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml Modified: tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml?rev=1395086&r1=1395085&r2=1395086&view=diff == --- tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml (original) +++ tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml Sat Oct 6 15:03:17 2012 @@ -88,10 +88,6 @@ - -Ensure that the chunked input filter is correctly recycled between -requests. (kkolinko/jim) - Implement the maxHeaderCount for the HTTP connectors. (kkolinko) @@ -102,9 +98,8 @@ Reject chunks whose header is incorrect. (kkolinko) -52055 (comment 14): Correctly reset -ChunkedInputFilter.needCRLFParse flag when the filter -is recycled. (kkolinko) +52055 (comment 14): Ensure that the chunked input filter +is correctly recycled between requests. (kkolinko/jim) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1395100 - /tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/collections/
Author: kkolinko
Date: Sat Oct 6 15:44:12 2012
New Revision: 1395100
URL: http://svn.apache.org/viewvc?rev=1395100&view=rev
Log:
Remove bugtraq: properties that were added in r1388712.
Those properties are managed not here, but at the root of the project.
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/collections/ (props
changed)
Propchange: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/collections/
('bugtraq:append' removed)
Propchange: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/collections/
('bugtraq:label' removed)
Propchange: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/collections/
('bugtraq:message' removed)
Propchange: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/collections/
('bugtraq:url' removed)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53960] Extensions to HttpClient test helper class
https://issues.apache.org/bugzilla/show_bug.cgi?id=53960 --- Comment #1 from Brian Burch --- I wondered whether my refactoring might have broken the logic associated with processing the response body. I have reviewed my change, renamed an argument to make it self-explanatory, and fixed a typo in a comment. I have attached a new patch file for the entire change, so please ignore the original and implement only the new patch. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53960] Extensions to HttpClient test helper class
https://issues.apache.org/bugzilla/show_bug.cgi?id=53960 Brian Burch changed: What|Removed |Added Attachment #29443|0 |1 is obsolete|| --- Comment #2 from Brian Burch --- Created attachment 29455 --> https://issues.apache.org/bugzilla/attachment.cgi?id=29455&action=edit Minor improvements to original patch. This is a complete replacement for the original patch file, even though the differences are minor. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: FormAuthenticatorTest for cases without cookies - implementation issues
On 30/09/12 23:46, Brian Burch wrote: On 30/09/12 21:56, Konstantin Kolinko wrote: 2012/9/26 Brian Burch : Thanks for all the help while I was developing the new test case for https://issues.apache.org/bugzilla/show_bug.cgi?id=53584. The thread on the users mailing list is called "AuthenticatorBase setChangeSessionIdOnAuthentication without cookies". I now have two new test cases working successfully against a recently-updated trunk. I hope to use them in future as boilerplates, to expand the set of tests, and also to examine SSO behaviour. Before I open a bugzilla enhancement request and submit my patch files, I would like to discuss my implementation decisions in general, to ensure that my effort, and other developer's time, isn't wasted. I found it necessary to modify both org.apache.catalina.authenticator.FormAuthenticatorTest, and its parent class org.apache.catalina.startup.SimpleHttpClient. To save you looking it up, here is the unchanged class comment to SimpleHttpClient: /** * Simple client for unit testing. It isn't robust, it isn't secure and * should not be used as the basis for production code. Its only purpose * is to do the bare minimum for the unit tests. */ FormAuthenticatorTest doesn't have a class-level comment at all, but I have written a new one based on the conclusions in my thread on the users list. I would have preferred to make fairly localised changes to both of these classes, but the existing logic seems to incorporate some fundamental assumptions that made my intention too difficult to implement. I am not at all proud of my code, but I believe it a) works, b) is fairly harmonious with the existing design, and c) is amenable to the extensions I intend to add in due course. Firstly, I've written several small blocks of parser logic for urls and http headers, which are specific to the test environment and not very pretty. I looked for suitable parsers to re-use in the various tomcat utils packages, but haven't found them yet, even though tomcat MUST be doing similar work in an elegant and robust manner. I haven't found any unit tests, either. Then, I looked at the apache HttpClient project. An ideal solution would have been to use the parsers from that project, or perhaps even the entire client. This would have required starting with a blank sheet of paper, and I am very reluctant to take that approach. I might have been swayed if I had found HttpClient already in use by other tomcat unit tests, but I couldn't find it in the dependencies and didn't want to add a new one. Next, the current version only supports cookies, so I had to add some extra boolean arguments to control the use of server and client cookies in each test case. In my professional work, I would have use singleton inner classes to achieve type-safety and make these crucial arguments self-documenting, but this wouldn't be compatible with the existing style of the various current authenticator unit test classes. Also, I wanted to make my initial change as transparent as possible, so it could be reviewed (and accepted) with as little effort from others as possible. I didn't want to touch SimpleHttpClient at all, but that turned out to be unavoidable. This class does most of the http header processing, and so it seemed ugly to split this work between the two classes. On the other hand, all the url handling is done by FormAuthenticatorTest, so it felt ugly to start doing any of that work in SimpleHttpClient. The consequence is that the two classes need to be cross-wired to some extent. This was always the case, but I had to cross some more wires for the new test cases. So, to summarise: I would like to make quite a bulky change to these two classes. I am somewhat embarrassed by my ugly style and DIY approach to parsing. Many of the line-changes in the patch are trivial, but a lot of lines will be hit at once. I haven't gone mad with comments, but have tried to add useful tips when an existing section of uncommented code didn't make sense to me. On the other hand, to maintain similar look'n'feel, I haven't been heavy-handed with comments in my new code. Of course, I will make sure it passes checkstyle before I actually cut the patches! To put things in perspective, the tests only demonstrate that Mark's fix works - and that wasn't even in question. However, I'd like to get my change committed soon, so that I can move forward with additional test cases. What do you think? Should I publish and be damned, or would you like me to do more work to eliminate some of my compromises? 1. If you a set of changes (a, b, c) and you cannot separate them into distinct patches, I would prefer to see (a), (a+b) and (a+b+c). Seeing (a+b+c) is usually also good enough if you can explain the changes such that a committer would be able to separate them. Thanks for thinking about my worries, Konstantin. I appreciate you spending time analysing what must appear to be a peripheral issue. In fact, when I didn't
Re: svn commit: r1394104 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/connector/ webapps/docs/ webapps/docs/config/
Konstantin Kolinko wrote: >2012/10/5 Christopher Schultz : >> RFCs 2616, 2068, and 1945 all agree that method name is >case-sensitive: >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1 >> > >OK. Agreed. > >Looking at Servlet spec 2.5, SRV.3.1.1 says "The HTTP method is POST". > > >I tested 6.0.35 using telnet as a client. >The result is that it sometimes allow lowercase methods (or maybe it >does not care about a method in that case) but generally it responds >with an error. > >get /index.jsp HTTP/1.0 >post /index.jsp HTTP/1.0 >- result in the welcome page being rendered The JSP servlet responds to any and every method. Personally, I think that is wrong. On my todo list for Tomcat 8 (not yet documented because I was hoping for some guidance form the JSP EG first) is to limit JSPs to responding to GET, POST, TRACE (blocked at the connector anyway) HEAD and OPTIONS and a servlet init parameter to enable more methods. I was also planning on providing similar functionality to that in HttpServlet. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1394104 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/connector/ webapps/docs/ webapps/docs/config/
2012/10/6 Mark Thomas : > > Konstantin Kolinko wrote: > >>2012/10/5 Christopher Schultz : > >>> RFCs 2616, 2068, and 1945 all agree that method name is >>case-sensitive: >>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1 >>> >> >>OK. Agreed. >> >>Looking at Servlet spec 2.5, SRV.3.1.1 says "The HTTP method is POST". >> >> >>I tested 6.0.35 using telnet as a client. >>The result is that it sometimes allow lowercase methods (or maybe it >>does not care about a method in that case) but generally it responds >>with an error. >> >>get /index.jsp HTTP/1.0 >>post /index.jsp HTTP/1.0 >>- result in the welcome page being rendered > > The JSP servlet responds to any and every method. Personally, I think that is > wrong. On my todo list for Tomcat 8 (not yet documented because I was hoping > for some guidance form the JSP EG first) is to limit JSPs to responding to > GET, POST, TRACE (blocked at the connector anyway) HEAD and OPTIONS and a > servlet init parameter to enable more methods. I was also planning on > providing similar functionality to that in HttpServlet. > Thinking more about the JSPs, JSPs are often used as views in an MVC pattern, being called from a controller servet using forward or include. Forwards and includes do not change the method name. In this scenario it is good that JSPs can render the response regardless of the HTTP methods supported by the controller servet. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 5.5.36
On 05.10.2012 15:49, Mark Thomas wrote: The proposed Apache Tomcat 5.5.36 release is now available for voting. It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-5/v5.5.36/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc5.5.x/tags/TOMCAT_5_5_36/ The proposed 5.5.36 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 5.5.36 Stable Note that this is expected to be the last 5.5.x release. +1 for release. - KEYS and RELEASE-NOTES files are missing in top level directory They had been put there for previous 5.5 releases. - MD5 OK - signatures OK - gz and zip for src and bin consistent - src mostly consistent with svn tag - builds fine - build result looks consistent with binaries - No errors in run-tester, even the four previously FAILED tests are OK now. - JMX MBeans only expected change is the new maxHeaderCount with value 100 in HTTP protocol handler, so looks OK Build was done using Java 1.4.2_19, OS was Solaris 10 Sparc. - Minor things: - STATUS.txt in svn, but not in src tar and zip (I guess that's expected) - Some javadoc warnings (but no regression from 5.5.35), TC 5.5 was never 100% clean for javadoc (details see below) Details for Javadoc: [javadoc] .../connectors/util/java/org/apache/tomcat/util/http/Cookies.java:566: warning - Tag @link: can't find getTokenEndPosition(byte[], int, int, boolean) in org.apache.tomcat.util.http.Cookies [javadoc] .../container/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java:315: and 344: warning - End Delimiter } missing for possible See Tag in comment string: "If the forward to the login page fails and the call [javadoc] .../container/catalina/src/share/org/apache/catalina/connector/Request.java:941: warning - Tag @link: reference not found: Globals.DISPATCHER_TYPE_ATTR Globals.DISPATCHER_REQUEST_PATH_ATTR Globals.CERTIFICATES_ATTR Globals.CIPHER_SUITE_ATTR Globals.KEY_SIZE_ATTR Globals.SSL_SESSION_ID_ATTR [javadoc] .../container/catalina/src/share/org/apache/catalina/connector/Request.java:2239: warning - @param argument "session" is not a parameter name. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53977] New: 32bits isapi connector cannot work in wow64 mode
https://issues.apache.org/bugzilla/show_bug.cgi?id=53977 Priority: P2 Bug ID: 53977 Assignee: dev@tomcat.apache.org Summary: 32bits isapi connector cannot work in wow64 mode Severity: major Classification: Unclassified OS: Windows Server 2003 Reporter: m...@gaya.cn Hardware: PC Status: NEW Version: unspecified Component: isapi Product: Tomcat Connectors I tested it both in Windows Server 2003 x64 Edition SP2 and in Windows Server 2008R2 (64bit). Both OS (IIS) can load 64bits connector, but fail with 32bits connector. Reproduce steps: In Windows Server 2003 x64 Edition SP2, IIS works in 64bits mode, the connector can be properly loaded. Then run the command to make IIS work in wow64 mode: cscript.exe %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1 Restart server and configure 32bits tomcat connector, it cannot be successfully loaded. In Windows Server 2008R2, make the website use 32bit application pool and then configure 32bits tomcat connector, it failed to be loaded. Same as 2003 x64 Edition 64bits IIS mode, 64bits tomcat connector can be successfully loaded. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
