Re: svn commit: r1226975 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
On 01/03/2012 11:51 PM, ma...@apache.org wrote: Correct error in r1666072 Hm sure? Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
Only one test failed: TEST-org.apache.catalina.mbeans.TestRegistration.BIO.txt.html [[[ Testsuite: org.apache.catalina.mbeans.TestRegistration Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 1.716 sec - Standard Error - Jan 5, 2012 3:36:03 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler [http-bio-auto-1] Jan 5, 2012 3:36:03 AM org.apache.catalina.core.StandardService startInternal INFO: Starting service Tomcat Jan 5, 2012 3:36:03 AM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/8.0.0-dev Jan 5, 2012 3:36:04 AM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [http-bio-50089] Jan 5, 2012 3:36:04 AM org.apache.coyote.AbstractProtocol pause INFO: Pausing ProtocolHandler [http-bio-50089] Jan 5, 2012 3:36:04 AM org.apache.catalina.core.StandardService stopInternal INFO: Stopping service Tomcat Jan 5, 2012 3:36:04 AM org.apache.coyote.AbstractProtocol stop INFO: Stopping ProtocolHandler [http-bio-50089] Jan 5, 2012 3:36:04 AM org.apache.catalina.core.StandardService startInternal INFO: Starting service Tomcat Jan 5, 2012 3:36:04 AM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/8.0.0-dev Jan 5, 2012 3:36:04 AM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [http-bio-50089] Jan 5, 2012 3:36:04 AM org.apache.coyote.AbstractProtocol pause INFO: Pausing ProtocolHandler [http-bio-50089] Jan 5, 2012 3:36:04 AM org.apache.catalina.core.StandardService stopInternal INFO: Stopping service Tomcat Jan 5, 2012 3:36:04 AM org.apache.coyote.AbstractProtocol stop INFO: Stopping ProtocolHandler [http-bio-50089] Jan 5, 2012 3:36:04 AM org.apache.coyote.AbstractProtocol destroy INFO: Destroying ProtocolHandler [http-bio-50089] - --- Testcase: testMBeanDeregistration took 1.699 sec FAILED Remaining: [Tomcat:type=RequestProcessor,worker=http-bio-auto-1,name=HttpRequest2] expected:0 but was:1 junit.framework.AssertionFailedError: Remaining: [Tomcat:type=RequestProcessor,worker=http-bio-auto-1,name=HttpRequest2] expected:0 but was:1 at org.apache.catalina.mbeans.TestRegistration.testMBeanDeregistration(TestRegistration.java:189) ]]] 2012/1/5 Bill Barker billbar...@apache.org: 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-trunk-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-test : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp-src.jar. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp.home. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_work/build_tomcat-trunk_tomcat-trunk-test.html Work Name: build_tomcat-trunk_tomcat-trunk-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 mins 3 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-05012012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-05012012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-05012012-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps -Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-05012012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-src.jar -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x
svn propchange: r1226975 - svn:log
Author: kkolinko Revision: 1226975 Modified property: svn:log Modified: svn:log at Thu Jan 5 08:29:37 2012 -- --- svn:log (original) +++ svn:log Thu Jan 5 08:29:37 2012 @@ -1,4 +1,4 @@ -Correct error in r1666072 +Correct error in r1158426 return true was originally continue that would have continued the for loop and was, in fact, unnecessary since it was at the end of the loop. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn propchange: r1226976 - svn:log
Author: kkolinko Revision: 1226976 Modified property: svn:log Modified: svn:log at Thu Jan 5 08:34:21 2012 -- --- svn:log (original) +++ svn:log Thu Jan 5 08:34:21 2012 @@ -1,2 +1,3 @@ -Correct error in r1666072 +Merged revision 1226975 from tomcat/trunk: +Correct error in r1158426 return true was originally continue that would have continued the for loop and was, in fact, unnecessary since it was at the end of the loop. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1226975 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
2012/1/5 jean-frederic clere jfcl...@gmail.com: On 01/03/2012 11:51 PM, ma...@apache.org wrote: Correct error in r1666072 Hm sure? I corrected Mark's log message. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52318] Version in POM is conflicted with Version in MANIFEST for JULI JAR
https://issues.apache.org/bugzilla/show_bug.cgi?id=52318 --- Comment #2 from pan4o ssku4...@web.de 2012-01-05 12:15:13 UTC --- Bug or not a bug? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52318] Version in tomcat-jdbc POM is conflicted with Version in MANIFEST for JULI JAR
https://issues.apache.org/bugzilla/show_bug.cgi?id=52318 pan4o ssku4...@web.de changed: What|Removed |Added Summary|Version in POM is |Version in tomcat-jdbc POM |conflicted with Version in |is conflicted with Version |MANIFEST for JULI JAR |in MANIFEST for JULI JAR -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52429] New: Wrong exports in tomcat-jdbc MANIFEST
https://issues.apache.org/bugzilla/show_bug.cgi?id=52429 Bug #: 52429 Summary: Wrong exports in tomcat-jdbc MANIFEST Product: Tomcat Modules Version: unspecified Platform: All OS/Version: All Status: NEW Severity: critical Priority: P2 Component: jdbc-pool AssignedTo: dev@tomcat.apache.org ReportedBy: ssku4...@web.de Classification: Unclassified We are using Apache Karaf in our environment, so all MANIFEST files schould be correct ... to get it work :) All versions of tomcat-jdbc [7.0.19 - 7.0.23] export the same version=1.1.0.1 and imports version=0 of some dependencies. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52381] Please add OSGi metadata
https://issues.apache.org/bugzilla/show_bug.cgi?id=52381 pan4o ssku4...@web.de changed: What|Removed |Added CC||ssku4...@web.de -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52381] Please add OSGi metadata
https://issues.apache.org/bugzilla/show_bug.cgi?id=52381 --- Comment #4 from pan4o ssku4...@web.de 2012-01-05 12:45:51 UTC --- This is a very important issue for us too, because of our Apache Karaf environment. See bugs 52318 and 52429 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
[jira] [Closed] (MTOMCAT-113) Show progress on WAR uploads
[ https://issues.apache.org/jira/browse/MTOMCAT-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MTOMCAT-113. Resolution: Fixed Show progress on WAR uploads Key: MTOMCAT-113 URL: https://issues.apache.org/jira/browse/MTOMCAT-113 Project: Apache Tomcat Maven Plugin Issue Type: Improvement Reporter: Adrian Petrescu Assignee: Olivier Lamy Priority: Minor Labels: features Fix For: 2.0 This may seem frivolous, but it would be really great to have some indication of progress when uploading a WAR to a remote server, as part of a tomcat:deploy or tomcat:redeploy goal. I often find myself uploading large WARs using Maven, and I have no idea how long I should expect to be waiting. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Closed] (MTOMCAT-67) Add automatic integration tests
[
https://issues.apache.org/jira/browse/MTOMCAT-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MTOMCAT-67.
---
Assignee: Olivier Lamy (was: Mark Michaelis)
Add automatic integration tests
---
Key: MTOMCAT-67
URL: https://issues.apache.org/jira/browse/MTOMCAT-67
Project: Apache Tomcat Maven Plugin
Issue Type: Test
Affects Versions: 1.1
Reporter: Mark Michaelis
Assignee: Olivier Lamy
Fix For: 2.0
Attachments: restructuring-and-itests.patch, svn-diff.patch
Because of MTOMCAT-62 I think it is necessary to have automatic integration
tests to see if the migration to Tomcat 7 works without problems. To achieve
this I have a proposal for integration tests. In addition I also restructured
the whole tomcat-maven-plugin. The main artifact is now tomcat6x-maven-plugin
as I think we will need tomcat7x-maven-plugin as extra module and perhaps
tomcat-maven-plugin-common for shared artifacts.
The first integration test added is the one you already provided in the
sources. But now it is automatically executed.
To test the whole plugin call the parent POM with:
{noformat}
tomcat-maven-plugin/# mvn clean verify -P integration-test
{noformat}
This will ensure that the plugin is installed in the phase
pre-integration-test rather than install and that the Integration Test module
is actually added.
Because of the Major change I suggest to move to version number 2.0-SNAPSHOT
so that version 2.0 will come with Tomcat 7 support eventually.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Closed] (MTOMCAT-104) Running java -jar from a parent directory causes a Zip file error
[ https://issues.apache.org/jira/browse/MTOMCAT-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MTOMCAT-104. Running java -jar from a parent directory causes a Zip file error - Key: MTOMCAT-104 URL: https://issues.apache.org/jira/browse/MTOMCAT-104 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Environment: Mac OSX 10.6.8 Reporter: Keith Corbin Assignee: Olivier Lamy Priority: Minor Fix For: 2.0 If you attempt to run the executable jar rather than from the directory the jar file is in you get an error with Zip extraction. java -jar ./target/smapi-1.0-war-exec.jar Exception in thread main java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:127) at java.util.jar.JarFile.init(JarFile.java:135) at java.util.jar.JarFile.init(JarFile.java:72) at sun.net.www.protocol.jar.URLJarFile.init(URLJarFile.java:72) at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:48) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:55) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:132) at org.apache.tomcat.maven.runner.Tomcat7Runner.getContextXml(Tomcat7Runner.java:229) at org.apache.tomcat.maven.runner.Tomcat7Runner.run(Tomcat7Runner.java:208) at org.apache.tomcat.maven.runner.Tomcat7RunnerCli.main(Tomcat7RunnerCli.java:144) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Release 2.0-beta-1 of Tomcat Maven Plugin
Hello, I'd like to release a first version of Tomcat Maven Plugin. As it's the first version here and some features have been added, this version will be called 2.0-beta-1. I will do that early next week. Let me know if you have any comments. Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Updated] (MTOMCAT-105) creating executable war failed
[ https://issues.apache.org/jira/browse/MTOMCAT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MTOMCAT-105: - Fix Version/s: (was: 2.0) moreinfo creating executable war failed -- Key: MTOMCAT-105 URL: https://issues.apache.org/jira/browse/MTOMCAT-105 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Environment: C:\Users\albert\workspace\BasicSetupmvn --version Apache Maven 3.0.3 (r1075438; 2011-03-01 00:31:09+0700) Maven home: C:\Users\albert\Desktop\myapps\apache-maven-3.0.3\bin\.. Java version: 1.7.0, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows Reporter: albert kam Assignee: Olivier Lamy Priority: Critical Labels: exec-war Fix For: moreinfo Attachments: BasicSetup.zip Original Estimate: 0.05h Remaining Estimate: 0.05h Just today on November 3rd, i tried out the tomcat7 maven plugin to try out the executable war. Following the configuration from the http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/executable-war-jar.html, here's the output of my tomcat7:exec-war-only -X : ... lot of lines removed ... org.codehaus.plexus:plexus-archiver:jar:2.0.1:compile, junit:junit:jar:4.9:compile, org.hamcrest:hamcrest-core:jar:1.1:compile, org.codehaus.plexus:plexus-io:jar:2.0.1:compile] [DEBUG] (f) project = MavenProject: kam.albert.study:BasicSetup:0.0.1-SNAPSHOT @ C:\Users\albert\workspace\BasicSetup\pom.xml [DEBUG] (f) projectArtifact = kam.albert.study:BasicSetup:war:0.0.1-SNAPSHOT [DEBUG] (f) remoteRepos = [ id: jvnet-nexus-releases url: https://maven.java.net/content/repositories/releases/ layout: default snapshots: [enabled = true, update = daily] releases: [enabled = true, update = daily] ,id: central url: http://repo1.maven.org/maven2 layout: default snapshots: [enabled = false, update = daily] releases: [enabled = true, update = daily] ] [DEBUG] (f) serverXml = C:\Users\albert\workspace\BasicSetup\src\main\tomcatconf\server.xml [DEBUG] (f) tomcatConfigurationFilesDirectory = C:\Users\albert\workspace\BasicSetup\src\main\tomcatconf [DEBUG] -- end configuration -- [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.827s [INFO] Finished at: Thu Nov 03 13:06:40 ICT 2011 [INFO] Final Memory: 6M/15M [INFO] [ERROR] Failed to execute goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT:exec-war-only (default-cli) on project BasicSetup: Execution default-cli of goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT:exec-war-only failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT:exec-war-only (default-cli) on project BasicSetup: Execution default-cli of goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT:exec-war-only failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at
DO NOT REPLY [Bug 52432] New: HTTP Error 500.0 from IIS 7.5 when configure tomcat connector 1.2.32
https://issues.apache.org/bugzilla/show_bug.cgi?id=52432 Bug #: 52432 Summary: HTTP Error 500.0 from IIS 7.5 when configure tomcat connector 1.2.32 Product: Tomcat Connectors Version: 1.2.32 Platform: PC Status: NEW Severity: normal Priority: P2 Component: isapi AssignedTo: dev@tomcat.apache.org ReportedBy: crasher_...@hotmail.com Classification: Unclassified Hello, We are configuring Tomcat-Connector 1.2.32 for IIS 7.5 in Windows Server 2008 R2. After we finish all steps for properties settings and IIS settings, we always got following error even trying to browse the default web site in IIS manager. HTTP Error 500.0 - Internal Server Error The page cannot be displayed because an internal server error has occurred. Detailed Error Information Module IsapiFilterModule Notification AuthenticateRequest Handler StaticFile Error Code 0x80070001 Requested URL http://localhost:80/ Physical Path C:\inetpub\wwwroot Logon Method Anonymous Logon User Anonymous Below is the content of file isapi_redirect.properties. extension_uri=/jarkarta/isapi_redirect.dll log_file=c:\tomcat-7.0.23\logs\isapi_redirect.log log_level=info worker_file=c:\tomcat7.0.23\conf\workers.properties worker_mount_file=c:\tomcat-7.0.23\conf\uriworkermap.properties The content of file workers.properties is as following. worker.list=ajp13w worker.ajp13w.type=ajp13 worker.ajp13w.host=localhost worker.ajp13w.port=8009 Content of file uriworkermap.properties /example/*=ajp13w /example=ajp13w Can anybody share your experiences and advise on this? Thanks a lot! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51181] Add support for Web Sockets
https://issues.apache.org/bugzilla/show_bug.cgi?id=51181 gober...@msn.com changed: What|Removed |Added CC||gober...@msn.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51181] Add support for Web Sockets
https://issues.apache.org/bugzilla/show_bug.cgi?id=51181
--- Comment #22 from gober...@msn.com 2012-01-05 22:33:32 UTC ---
Mark,
Is there any estimate when WebSockets support will be implemented?
As far as API, I would not mind if it is somewhat similar to the Comet
functionality. In fact it would be nice if the same Servlet instance could
handle both WebSocket and Comet requests.
So it may looks something like:
public class WebFrameworkServlet extends HttpServlet implements
WebSocketProcessor /*, CometProcessor*/ {
/*
// comet event processor
public void event(CometEvent event) throws IOException, ServletException {
HttpServletRequest request = event.getHttpServletRequest();
HttpServletResponse response = event.getHttpServletResponse();
if (event.getEventType() == CometEvent.EventType.BEGIN) {
...
}
...
}
*/
// WebSocket event processor
public void event(WebSocketEvent event) throws IOException, ServletException
{
WebSocketServletRequest request = event.getHttpServletRequest();
WebSocketServletResponse response = event.getHttpServletResponse();
// initial connection
if (event.getEventType() == WebSocketEvent.EventType.BEGIN) {
...
}
//
if (event.getEventType() == WebSocketEvent.EventType.MESSAGE) {
// Get message
WebSocketMessage inboundMessage = request.getMessage();
// Send message back to the client
response.sendMessage(new WebSocketMessage(...));
...
}
...
}
...
}
One longstanding limitation to the Tomcat Comet API is the ability to specify
maximum send queue size threshold to disconnect slow consumers when send
backlog crosses a limit. I have requested this in the past with no luck. This
is is absolutely critical for the production application. We had situations
when a slow consumer would block IO thread dedicated to multiple clients
eventually causing Tomcat run out of memory.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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: r1227902 - /tomcat/maven-plugin/trunk/pom.xml
Author: olamy
Date: Fri Jan 6 00:02:38 2012
New Revision: 1227902
URL: http://svn.apache.org/viewvc?rev=1227902view=rev
Log:
release will go to nexus now
Modified:
tomcat/maven-plugin/trunk/pom.xml
Modified: tomcat/maven-plugin/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/pom.xml?rev=1227902r1=1227901r2=1227902view=diff
==
--- tomcat/maven-plugin/trunk/pom.xml (original)
+++ tomcat/maven-plugin/trunk/pom.xml Fri Jan 6 00:02:38 2012
@@ -52,7 +52,7 @@
verifier.maven.debugfalse/verifier.maven.debug
verifier.debugJvmfalse/verifier.debugJvm
maven.resources.escapeString\/maven.resources.escapeString
-
distributionReleaseUrlscp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository/distributionReleaseUrl
+
distributionReleaseUrlhttps://repository.apache.org/service/local/staging/deploy/maven2/distributionReleaseUrl
distributionSiteUrlscp://people.apache.org/www/tomcat.apache.org/maven-plugin-${project.version}/distributionSiteUrl
distributionSnapshotsUrlhttps://repository.apache.org/content/repositories/snapshots/distributionSnapshotsUrl
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1227903 - in /tomcat/maven-plugin/trunk: pom.xml src/site/site.xml
Author: olamy Date: Fri Jan 6 00:02:47 2012 New Revision: 1227903 URL: http://svn.apache.org/viewvc?rev=1227903view=rev Log: add an auto generated changelog from jira entries Modified: tomcat/maven-plugin/trunk/pom.xml tomcat/maven-plugin/trunk/src/site/site.xml Modified: tomcat/maven-plugin/trunk/pom.xml URL: http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/pom.xml?rev=1227903r1=1227902r2=1227903view=diff == --- tomcat/maven-plugin/trunk/pom.xml (original) +++ tomcat/maven-plugin/trunk/pom.xml Fri Jan 6 00:02:47 2012 @@ -697,6 +697,27 @@ artifactIdmaven-report/artifactId version0.1/version /plugin + plugin +groupIdorg.apache.maven.plugins/groupId +artifactIdmaven-changes-plugin/artifactId +version2.6/version +inheritedfalse/inherited +configuration + columnNamesType,Fix Version,Key,Summary,Assignee,Status,Created/columnNames + maxEntries200/maxEntries + onlyCurrentVersiontrue/onlyCurrentVersion + resolutionIdsFixed/resolutionIds + sortColumnNamesType/sortColumnNames + fixVersionIds12317943/fixVersionIds +/configuration +reportSets + reportSet +reports + reportjira-report/report +/reports + /reportSet +/reportSets + /plugin /plugins /reporting /profile Modified: tomcat/maven-plugin/trunk/src/site/site.xml URL: http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/src/site/site.xml?rev=1227903r1=1227902r2=1227903view=diff == --- tomcat/maven-plugin/trunk/src/site/site.xml (original) +++ tomcat/maven-plugin/trunk/src/site/site.xml Fri Jan 6 00:02:47 2012 @@ -45,11 +45,12 @@ /breadcrumbs menu name=Apache Tomcat Mojo - item name=About href=index.html/ - item name=Context Goals href=context-goals.html/ - item name=Container Goals href=container-goals.html/ - item name=Executable War href=executable-war-jar.html/ + item name=About href=index.html/ + item name=Context Goals href=context-goals.html/ + item name=Container Goals href=container-goals.html/ + item name=Executable Warhref=executable-war-jar.html/ item name=Developement Test href=snapshot-test.html/ + item name=Changelog href=jira-report.html/ /menu - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
problem using default Realm in new unit tests
I am developing some new unit tests to validate SingleSignOn and Authenticator logic. I have used this existing test class as my template: org.apache.catalina.authenticator.TestDigestAuthenticator .. which extends org.apache.catalina.startup.TomcatBaseTest. I noticed that TestDigestAuthenticator sets up its own MapRealm and assigns it to its single Context. I thought this logic was unnecessary, and so my own initial test logic simply used the default RealmBase provided by the underlying Tomcat instance. I add my test user and role to that. It worked fine with my simple cases, however... To test SSO, I need to set up two Contexts under the same Realm. I see the following message in the output log: INFO: The start() method was called on component [Realm[Simple]] after start() had already been called. The second call will be ignored. I know it is an INFO message. I know the second start (and its associated stop) are ignored and therefore are harmless. However, I am reluctant to simply shrug and ignore it. My instincts tell me something isn't right. I have done quite a lot of investigating, but the underlying logic is very hard for me to follow. Here is what I am sure about: 1. The message is ONLY emitted in tests that create two Contexts and each have the same Realm assigned with setRealm. 2. The message is NOT emitted at the time the Contexts are created and defined (servlets, security constraints, etc). 3. The message IS emitted after the Tomcat.start method is called. 4. The message is emitted by one of the two threads which are started on behalf of my two contexts. The messages are issued by the start and stop methods in the abstract class org.apache.catalina.util.LifecycleBase. 5. org.apache.catalina.realm.RealmBase extends org.apache.catalina.util.LifecycleMBeanBase which extends LifecycleBase. My currently unanswered questions are: 1. Is this message normal? (I don't see it when I start multiple contexts under a real tomcat server, but perhaps the logging properties are different). 2. Why isn't the redundant startup of the Realm detected earlier and simply avoided (maybe the Threads are intended to race to be first with startup - but then I think the message should be debug level and not sound so scary). Please don't waste your time investigating this for me. I am only asking the question because I don't want too get side-tracked if one of you already knows the answers to my questions. I'd like to settle the matter quickly and get back to my original task! Thanks for listening, Brian - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: problem using default Realm in new unit tests
2012/1/6 Brian Burch br...@pingtoo.com: I am developing some new unit tests to validate SingleSignOn and Authenticator logic. I have used this existing test class as my template: org.apache.catalina.authenticator.TestDigestAuthenticator .. which extends org.apache.catalina.startup.TomcatBaseTest. I noticed that TestDigestAuthenticator sets up its own MapRealm and assigns it to its single Context. I thought this logic was unnecessary, and so my own initial test logic simply used the default RealmBase provided by the underlying Tomcat instance. I add my test user and role to that. It worked fine with my simple cases, however... To test SSO, I need to set up two Contexts under the same Realm. I see the following message in the output log: INFO: The start() method was called on component [Realm[Simple]] after start() had already been called. The second call will be ignored. I know it is an INFO message. I know the second start (and its associated stop) are ignored and therefore are harmless. However, I am reluctant to simply shrug and ignore it. My instincts tell me something isn't right. I have done quite a lot of investigating, but the underlying logic is very hard for me to follow. Here is what I am sure about: 1. The message is ONLY emitted in tests that create two Contexts and each have the same Realm assigned with setRealm. 2. The message is NOT emitted at the time the Contexts are created and defined (servlets, security constraints, etc). 3. The message IS emitted after the Tomcat.start method is called. 4. The message is emitted by one of the two threads which are started on behalf of my two contexts. The messages are issued by the start and stop methods in the abstract class org.apache.catalina.util.LifecycleBase. 5. org.apache.catalina.realm.RealmBase extends org.apache.catalina.util.LifecycleMBeanBase which extends LifecycleBase. My currently unanswered questions are: 1. Is this message normal? (I don't see it when I start multiple contexts under a real tomcat server, but perhaps the logging properties are different). 2. Why isn't the redundant startup of the Realm detected earlier and simply avoided (maybe the Threads are intended to race to be first with startup - but then I think the message should be debug level and not sound so scary). Please don't waste your time investigating this for me. I am only asking the question because I don't want too get side-tracked if one of you already knows the answers to my questions. I'd like to settle the matter quickly and get back to my original task! Thanks for listening, The message is expected. I would say that the configuration is wrong, or at least unusual. If you look at the default server.xml file you will note that the Realm element there belongs to Engine. That is why it is started once. When Contexts are created and their context.xml files are parsed, the Contexts always get distinct new Realm instances. Instead of assigning the same Realm instance to both Contexts you should assign it to an upper container (I have not looked at the API though). Or maybe you can have different Realm instances, but which connect to the same backing storage? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for 5.5.35?
Good to see a new 5.5.x release soon :-) On Mon, Dec 26, 2011 at 8:49 AM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2011/12/21 Mark Thomas ma...@apache.org: On 20/12/2011 10:03, Jim Jagielski wrote: On Dec 20, 2011, at 2:42 AM, jean-frederic clere wrote: On 12/19/2011 10:49 PM, Mark Thomas wrote: All, I know the 5.5.x change log is short but [1] is one of those annoying (for me any way) bugs it would be nice to get in a fixed release. Jim: Any chance of a 5.5.x tag later this week? I won't suggest this coming weekend ;) +1 for middle of next week. Fine w/ me... The status file is clear. Bugzilla is clear (!) I think we are good to go. I'd suggest waiting ~24 hours for folks to spot anything else that needs doing and aim for a tag on Thursday. 1. There was a bug report about exception when DEBUG logging is enabled. https://issues.apache.org/bugzilla/show_bug.cgi?id=52384 Already fixed in 7.0 and backports proposed. 2. I reduced one warning to info (per BZ 52184 concerns) - also proposed. Neither issue is a showstopper, but should be easy to fix. X. It might be interesting to backport UserDataHandler (BZ 52184) from TC7 to earlier versions, but I am not sure how much interest is there in that. It is not a showstopper, because one can configure its logging to take care of BZ 52184. Should be easy for 6.0. Will be more work for 5.5 (replace enums with int constants?). For reference, the revisions that implement this feature are: http://svn.apache.org/viewvc?view=revisionrevision=1212102 (initial, Cookies) http://svn.apache.org/viewvc?view=revisionrevision=1212110 (changelog) http://svn.apache.org/viewvc?view=revisionrevision=1213470 (JULI build fix) http://svn.apache.org/viewvc?view=revisionrevision=1220297 (catalina.policy) http://svn.apache.org/viewvc?view=revisionrevision=1224654 (API review) http://svn.apache.org/viewvc?view=revisionrevision=1224664 (Parameters) I expect to be rather busy next week. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Thanks! Regards, Forrest
