[Bug 53619] New: If absolute-ordering is defined, only fragments mentioned in it shall get class-scanned
https://issues.apache.org/bugzilla/show_bug.cgi?id=53619 Priority: P2 Bug ID: 53619 Assignee: dev@tomcat.apache.org Summary: If absolute-ordering is defined, only fragments mentioned in it shall get class-scanned Severity: normal Classification: Unclassified Reporter: strub...@yahoo.de Hardware: PC Status: NEW Version: 7.0.29 Component: Catalina Product: Tomcat 7 There was a discussion at the dev list how one could prevent his app from scanning all the classpath if a ServletContextInitializer is found: http://tomcat.10.n6.nabble.com/tomcat-7-0-29-startup-time-td4984446.html Mark pointed me at a current EG discussion: http://java.net/jira/browse/SERVLET_SPEC-36 The agreed status seems to be that _if_ an absolute-ordering element exists in WEB-INF/web.xml, then only the web-fragments mentioned therein shall be scanned. This is especially true if the absolute-ordering contains no others/ element. An empty absolute-ordering/ shall therefore disable scanning at all as far as I understood. This seems already be reflected in servlet-3.0 section 8.2.2 Ordering of web.xml and web-fragment.xml paragraph 1.d: If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer. What I do not yet completely understand is that servlet-3.0 section 8.2.1 Modularity of web.xml explicitly defines as general rule: As before, if the metadata-complete element is set to true in the web.xml descriptor, annotations in the class files and web-fragments bundled in jars will not be processed. This not only contradicts the 'clarification' of the EG regarding the ServletContextInitializer which is in question here, but also could be interpreted as : if metadata-complete is true, then no web-fragment handling is done. Thus also no absolute-ordering will be evaluated. Not that I would like this, I just like to have this clarified upfront (before we have to throw away some work afterwards). Did I miss something in this regard? -- 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 53619] If absolute-ordering is defined, only fragments mentioned in it shall get class-scanned
https://issues.apache.org/bugzilla/show_bug.cgi?id=53619 Mark Struberg strub...@yahoo.de changed: What|Removed |Added OS||All --- Comment #1 from Mark Struberg strub...@yahoo.de --- whoops s/ServletContextInitializer/ServletContainerInitializer/ -- 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 53620] New: [juli] delay opening a file until something gets logged
https://issues.apache.org/bugzilla/show_bug.cgi?id=53620 Priority: P2 Bug ID: 53620 Assignee: dev@tomcat.apache.org Summary: [juli] delay opening a file until something gets logged Severity: enhancement Classification: Unclassified OS: All Reporter: karol.bucek+apa...@gmail.com Hardware: All Status: NEW Version: unspecified Component: Catalina Product: Tomcat 7 Created attachment 29137 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29137action=edit patch had troubles configuring the FileHandler while bootstraping Tomcat, this patch sums up a few (minor) changes that allows one to setup a FileHandler instance programatically. the changes are the following : - delay opening a file until something gets logged (since the code is already there within publish() to support rolling it kind of made sense to open the file from publish() instead of the constructor) - add a constructor where all 'configurable' properties of the handler can be provided programatically - since FileHandler.close() is public API so should be open() I'm very sorry to have no tests, I've happened to test the desired FileHandler behavior with https://github.com/trinidad/trinidad and is currently contained within the 1.4.0 release of Trinidad. -- 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: tomat-jdbc hashCode
nope, I will fix that Filip - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: Tomcat Developers List dev@tomcat.apache.org Sent: Tuesday, July 24, 2012 5:18:32 PM Subject: tomat-jdbc hashCode Hi, just noticed tomcat jdbc doesn't manage hashCode if the connection is already close (it is in org.apache.tomcat.jdbc.pool.JdbcInterceptor). Any reason to do so? - Romain - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53621] New: Response code incorrect for requests to contexts in stopped state.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53621 Priority: P2 Bug ID: 53621 Assignee: dev@tomcat.apache.org Summary: Response code incorrect for requests to contexts in stopped state. Severity: normal Classification: Unclassified OS: Linux Reporter: kylejhar...@gmail.com Hardware: PC Status: NEW Version: 7.0.26 Component: Catalina Product: Tomcat 7 Overview: When a request is made to a valid location inside of a context while the context is stopped (either crashed or manually stopped) tomcat will return HTTP status code 404. Steps to Reproduce: Simply create a context (e.g.: /foo) with a page in it. View the page, stop the context (I used probe), refresh the page. Tomcat will return the mapped 404 handler. I have tested this on 6.0.24 as well as 7.0.26. Actual vs. Expected Results: I expected to receive a form of unavailable error returned. The context and page are not unknown to Tomcat, they are simply unavailable. I believe the HTTP Status code 503 would be more aptly suited here. I found this behavior while attempting to enable the Apache2 mod_proxy failonstatus attribute to be set to 503, to remove BalancerMembers on a per-ProxyPass level (potentially, per context). This would be a nice benefit to the clustering/balancing systems already in place with Tomcat and Apache HTTPD. Thanks, Kyle -- 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 53621] Response code incorrect for requests to contexts in stopped state.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53621 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Mark Thomas ma...@apache.org --- Reading RFC 2616 any one of several error codes may be appropriate (404, 410, 503). Tomcat has no way of knowing the circumstances and therefore no way of determining which code is most appropriate. Given this, 404 is a reasonable default. My reading of the RFC is that the 400 series of codes is more appropriate than the 500 series in this case. If you would like to re-open this as an enhancement request to make the returned code configurable in this case then please feel free to do so. Enhancement requests with patches are more likely to be implemented than those without. -- 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: [Proposal] Preparatory refactoring for Resource handling refactoring
On 30/07/2012 01:16, Konstantin Kolinko wrote: If we remove JNDI stuff from resource handling, one of challenges might be to re-implement DefaultServlet using only Servlet API methods. Well, if the former is not possible, it might use the new resources API (that you are going to implement instead of jndi one) and be thus still tied with Tomcat internals... This is a non-issue in my view. The current DefaultServlet uses Tomcat internals extensively. The new implementation will to. If one reimplements DefaultServlet, one of the tasks would be to generate directory listings. Those include file size and file timestamp. One needs to obtain URL of a resource, open its URLConnection and ask those attributes. Only if doing so entirely via the Servlet API which we don't need to do. One good thing with jndi: URLs returned via Servlet API is that they are backed by an instance of ProxyDirContext class and it has a cache (*). If we change implementation and return true URLs, they will bypass the cache. I suspect that using a jar: URL directly (in case of an unpacked WAR file) may have poor performance. The new Resources implementation will include caching where necessary. At the moment there is none. I intend to add it as required. I agree JARs/WARs are likely to need it to have performance that is comparable with expanded WARs. Other good thing is that you can create relative URLs as new URL(Url, String), which inherits URLStreamHandler instance from the original URL, and thus inherits access to ProxyDirContext instance. If it is a jndi URL it will have access to the full resources hierarchy of the web application. If it is a true URL, it will be limited to its origin file system. That is true, but why is that necessary? Is it a specification requirement? I'm not aware of it. The canonical identifier is the path of the resource within the app, not the URL returned from getResource() The above two are the reasons why I think that in Tomcat 8 we cannot return true URLs from ServletContext.getResource(String) method and must still support the jndi: or some other proprietary URL schema. I agree that the second issue would require a custom URL scheme if it were a requirement but I am not aware of anything that states that it is. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53621] Response code incorrect for requests to contexts in stopped state.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53621 --- Comment #2 from Konstantin Kolinko knst.koli...@gmail.com --- Note that 1. A stopped application is effectively absent from Tomcat and its request Mapper. The request is thus served by whatever other web application that is available for that request path, the common fallback being the ROOT web application. If you configure a filter or servlet in the ROOT web application to serve 503 response for those requests, that will fulfill your requirement. I remember this having been discussed on the users list about a month ago. 2. Your issue has to be distinguished from bug 53024. The latter talks about paused web applications (a state when an application is reloaded) and was a valid issue. It was fixed in 7.0.28. -- 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: [Proposal] Preparatory refactoring for Resource handling refactoring
2012/7/30 Mark Thomas ma...@apache.org:
On 30/07/2012 01:16, Konstantin Kolinko wrote:
If we remove JNDI stuff from resource handling, one of challenges
might be to re-implement DefaultServlet using only Servlet API
methods. Well, if the former is not possible, it might use the new
resources API (that you are going to implement instead of jndi one)
and be thus still tied with Tomcat internals...
This is a non-issue in my view. The current DefaultServlet uses Tomcat
internals extensively. The new implementation will to.
I am just saying that it is feels unfair.
If it were using the servlet API only, the code were more reusable,
both inside and outside of Tomcat. There must be specific issue why
Servlet API is not used there. Is the API lacking? Well, bypassing
the API we can get hands on simpler objects and waste less time
processing them.
If it is not a replacement for the current implementation, it might be
a new sample servlet for the examples webapp.
If one reimplements DefaultServlet, one of the tasks would be to
generate directory listings. Those include file size and file
timestamp. One needs to obtain URL of a resource, open its
URLConnection and ask those attributes.
Only if doing so entirely via the Servlet API which we don't need to do.
Others will use Servlet API, and dropping performance is a bad option.
One good thing with jndi: URLs returned via Servlet API is that they
are backed by an instance of ProxyDirContext class and it has a cache
(*). If we change implementation and return true URLs, they will
bypass the cache. I suspect that using a jar: URL directly (in case
of an unpacked WAR file) may have poor performance.
The new Resources implementation will include caching where necessary.
At the moment there is none. I intend to add it as required. I agree
JARs/WARs are likely to need it to have performance that is comparable
with expanded WARs.
Other good thing is that you can create relative URLs as new URL(Url,
String), which inherits URLStreamHandler instance from the original
URL, and thus inherits access to ProxyDirContext instance. If it is a
jndi URL it will have access to the full resources hierarchy of the
web application. If it is a true URL, it will be limited to its
origin file system.
That is true, but why is that necessary? Is it a specification
requirement? I'm not aware of it. The canonical identifier is the path
of the resource within the app, not the URL returned from getResource()
It is an existing feature. Removing a feature is bad and needs a good reason.
BTW, it you wanna take a look at a use case of it, I noticed one place
yesterday.
In ContextConfig.processAnnotationsJndi(...) there is code
[[[
EnumerationString dirs = dcUrlConn.list();
while (dirs.hasMoreElements()) {
String dir = dirs.nextElement();
URL dirUrl = new URL(url.toString() + '/' + dir);
processAnnotationsJndi(dirUrl, fragment, handlesTypesOnly);
}
]]]
It creates a relative URL there.
If it were using the constructor for relative URLs, new URL(url,
dir), it would have better performance, because URLStreamHandler were
inherited from the old URL. A question that needs testing before
making a change there, though, is whether the old URL ends with /
(and thus is a directory). The code behaves as if it did not have the
trailing /.
The above two are the reasons why I think that in Tomcat 8 we cannot
return true URLs from ServletContext.getResource(String) method and
must still support the jndi: or some other proprietary URL schema.
I agree that the second issue would require a custom URL scheme if it
were a requirement but I am not aware of anything that states that it is.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53621] Response code incorrect for requests to contexts in stopped state.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53621 --- Comment #3 from Kyle Harper kylejhar...@gmail.com --- Regarding RFC 2616 and 4xx vs. 5xx codes, I agree that 4xx is more appropriate. I'm not sure I agree that 404 is the best option as it lacks information for the client, but given Konstantin's remark #1 A stopped context is absent to tomcat, it makes sense. I did bring this to the users group via email and the solution of adding a servlet in the ROOT context to handle mappings for contexts in the stopped state was suggested. I implemented this and it works in 7.0.26, and does not work in 6.0.35. Here is a link to the archive for that issue: http://markmail.org/thread/wk7d5zxkp2lsflmz (I can open a different bug for 6.0.35 Request Mapper not falling back to /ROOT if you wish to patch 6.x.) 1. A stopped application is effectively absent from Tomcat and its request Mapper. Given this, tomcat is working as intended. Leaving bug resolved:invalid. If time permits I'll research a patch to enable configurable status codes in stopped states. Thanks. -- 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: [Proposal] Preparatory refactoring for Resource handling refactoring
On 30/07/2012 15:48, Konstantin Kolinko wrote: 2012/7/30 Mark Thomas ma...@apache.org: On 30/07/2012 01:16, Konstantin Kolinko wrote: If we remove JNDI stuff from resource handling, one of challenges might be to re-implement DefaultServlet using only Servlet API methods. Well, if the former is not possible, it might use the new resources API (that you are going to implement instead of jndi one) and be thus still tied with Tomcat internals... This is a non-issue in my view. The current DefaultServlet uses Tomcat internals extensively. The new implementation will to. I am just saying that it is feels unfair. It is no better or worse than the current approach in that respect. If it were using the servlet API only, the code were more reusable, both inside and outside of Tomcat. There must be specific issue why Servlet API is not used there. Is the API lacking? In lot of ways. For example, where is the API to create or delete resources? That is deliberately left as a container implementation detail. Well, bypassing the API we can get hands on simpler objects and waste less time processing them. There is some of that, but a lot of it is functionality that we have to implement. If it is not a replacement for the current implementation, it might be a new sample servlet for the examples webapp. If one reimplements DefaultServlet, one of the tasks would be to generate directory listings. Those include file size and file timestamp. One needs to obtain URL of a resource, open its URLConnection and ask those attributes. Only if doing so entirely via the Servlet API which we don't need to do. Others will use Servlet API, and dropping performance is a bad option. The jndi layer has caused performance problems as well. The special handling for JARs is a direct result of that. The new approach will simplify a lot of that and hopefully improve performance as well. Like we have with the current approach, if there are specific areas causing problems, we can take a look. I hope and expect that far fewer of these 'tweaks' would be required with the new implementation. One good thing with jndi: URLs returned via Servlet API is that they are backed by an instance of ProxyDirContext class and it has a cache (*). If we change implementation and return true URLs, they will bypass the cache. I suspect that using a jar: URL directly (in case of an unpacked WAR file) may have poor performance. The new Resources implementation will include caching where necessary. At the moment there is none. I intend to add it as required. I agree JARs/WARs are likely to need it to have performance that is comparable with expanded WARs. Other good thing is that you can create relative URLs as new URL(Url, String), which inherits URLStreamHandler instance from the original URL, and thus inherits access to ProxyDirContext instance. If it is a jndi URL it will have access to the full resources hierarchy of the web application. If it is a true URL, it will be limited to its origin file system. That is true, but why is that necessary? Is it a specification requirement? I'm not aware of it. The canonical identifier is the path of the resource within the app, not the URL returned from getResource() It is an existing feature. Removing a feature is bad and needs a good reason. The good reason is cleaning up the code, making the 'overlay' feature in Servlet 3.1 possible. You only have to look at the catalogue of problems the VirtualClassLoader and VirtualDirContext have introduced to imagine how difficult it would be to implement 'overlays' with the current code base. The refactoring makes things a lot, lot cleaner. BTW, it you wanna take a look at a use case of it, I noticed one place yesterday. That code is a direct result of a jndi URL being returned. No jndi URLs, no need for that code. The ContextConfig is one of the few parts of the code base I still need to refactor. The other part that is left is the Mapper. The rest is complete but untested. I'd like to have something that at least passes the TCK before committing it. I can put a patch of the changes so far on people.a.o if you are interested (note: it won't compile yet). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1367121 - /tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
Author: markt
Date: Mon Jul 30 15:32:45 2012
New Revision: 1367121
URL: http://svn.apache.org/viewvc?rev=1367121view=rev
Log:
Remove deprecated, unused code
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java?rev=1367121r1=1367120r2=1367121view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
Mon Jul 30 15:32:45 2012
@@ -173,28 +173,10 @@ public class McastService implements Mem
properties.setProperty(mcastAddress, addr);
}
-/**
- * @deprecated use setAddress
- * @param addr String
- */
-@Deprecated
-public void setMcastAddr(String addr) {
-setAddress(addr);
-}
-
public String getAddress() {
return properties.getProperty(mcastAddress);
}
-/**
- * @deprecated use getAddress
- * @return String
- */
-@Deprecated
-public String getMcastAddr() {
-return getAddress();
-}
-
public void setMcastBindAddress(String bindaddr) {
setBind(bindaddr);
}
@@ -202,28 +184,11 @@ public class McastService implements Mem
public void setBind(String bindaddr) {
properties.setProperty(mcastBindAddress, bindaddr);
}
-/**
- * @deprecated use getBind
- * @return String
- */
-@Deprecated
-public String getMcastBindAddress() {
-return getBind();
-}
public String getBind() {
return properties.getProperty(mcastBindAddress);
}
-/**
- * @deprecated use setPort
- * @param port int
- */
-@Deprecated
-public void setMcastPort(int port) {
-setPort(port);
-}
-
public void setPort(int port) {
properties.setProperty(mcastPort, String.valueOf(port));
}
@@ -276,41 +241,15 @@ public class McastService implements Mem
return false;
}
-/**
- * @deprecated use getPort()
- * @return int
- */
-@Deprecated
-public int getMcastPort() {
-return getPort();
-}
public int getPort() {
String p = properties.getProperty(mcastPort);
return new Integer(p).intValue();
}
-/**
- * @deprecated use setFrequency
- * @param time long
- */
-@Deprecated
-public void setMcastFrequency(long time) {
-setFrequency(time);
-}
-
public void setFrequency(long time) {
properties.setProperty(mcastFrequency, String.valueOf(time));
}
-/**
- * @deprecated use getFrequency
- * @return long
- */
-@Deprecated
-public long getMcastFrequency() {
-return getFrequency();
-}
-
public long getFrequency() {
String p = properties.getProperty(mcastFrequency);
return new Long(p).longValue();
@@ -323,15 +262,6 @@ public class McastService implements Mem
properties.setProperty(memberDropTime, String.valueOf(time));
}
-/**
- * @deprecated use getDropTime
- * @return long
- */
-@Deprecated
-public long getMcastDropTime() {
-return getDropTime();
-}
-
public long getDropTime() {
String p = properties.getProperty(memberDropTime);
return new Long(p).longValue();
@@ -569,42 +499,15 @@ public class McastService implements Mem
}
}
-/**
- * @deprecated use getSoTimeout
- * @return int
- */
-@Deprecated
-public int getMcastSoTimeout() {
-return getSoTimeout();
-}
-
public int getSoTimeout() {
return mcastSoTimeout;
}
-/**
- * @deprecated use setSoTimeout
- * @param mcastSoTimeout int
- */
-@Deprecated
-public void setMcastSoTimeout(int mcastSoTimeout) {
-setSoTimeout(mcastSoTimeout);
-}
-
public void setSoTimeout(int mcastSoTimeout) {
this.mcastSoTimeout = mcastSoTimeout;
properties.setProperty(mcastSoTimeout,
String.valueOf(mcastSoTimeout));
}
-/**
- * @deprecated use getTtl
- * @return int
- */
-@Deprecated
-public int getMcastTTL() {
-return getTtl();
-}
-
public int getTtl() {
return mcastTTL;
}
@@ -617,15 +520,6 @@ public class McastService implements Mem
return domain;
}
-/**
- * @deprecated use setTtl
- * @param mcastTTL int
- */
-@Deprecated
-public void setMcastTTL(int mcastTTL) {
-setTtl(mcastTTL);
-}
-
public void setTtl(int mcastTTL) {
this.mcastTTL = mcastTTL;
properties.setProperty(mcastTTL, String.valueOf(mcastTTL));
[jira] [Commented] (MTOMCAT-168) Nullpointer exception in run mojo
[ https://issues.apache.org/jira/browse/MTOMCAT-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13425046#comment-13425046 ] Olivier Lamy (*$^¨%`£) commented on MTOMCAT-168: that must be fixed with 2.0-SNAPSHOT. Can you try it ? see http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/snapshot-test.html Nullpointer exception in run mojo - Key: MTOMCAT-168 URL: https://issues.apache.org/jira/browse/MTOMCAT-168 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0-beta-1 Environment: windows mingw Reporter: Jiri Peinlich Assignee: Olivier Lamy (*$^¨%`£) when using enpty aditionalClasspathDir tag in the the plugin settings and running the mvn tomcat7:run mojo I got the following nullpointer exception. I am currently learning how the whole plugin works. I got the initial plugin configuration from here: http://tomcat.apache.org/maven-plugin-2/run-mojo-features.html I removed parts that are not applicable for my project but i kept the empty additionalClasspathDir as in the example: additionalClasspathDirs additionalClasspathDir/additionalClasspathDir /additionalClasspathDirs When removing this section i did not get the exception anymore Null Pointer exception: [ERROR] Failed to execute goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.0- beta-1:run (default-cli) on project ITA: Execution default-cli of goal org.apach e.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o rg.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run (default-cli) on proj ect ITA: Execution default-cli of goal org.apache.tomcat.maven:tomcat7-maven-plu gin:2.0-beta-1:run 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.buildProje ct(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu ild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl eStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) 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(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun cher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav a:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La uncher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: 352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-c li of goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:209) ... 19 more Caused by: java.lang.NullPointerException at org.apache.tomcat.maven.plugin.tomcat7.run.RunMojo.createWebappLoader (RunMojo.java:268) at org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.createCont ext(AbstractRunMojo.java:415) at org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.startConta iner(AbstractRunMojo.java:719) at org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.execute(Ab stractRunMojo.java:353) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:101) ... 20 more [ERROR] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information
[jira] [Commented] (MTOMCAT-169) Unable to Deploy WAR Defined via webapps Declaration
[ https://issues.apache.org/jira/browse/MTOMCAT-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13425055#comment-13425055 ] Olivier Lamy (*$^¨%`£) commented on MTOMCAT-169: Hi, Your patch file doesn't provide any informations on which class has been modified. Thanks Unable to Deploy WAR Defined via webapps Declaration -- Key: MTOMCAT-169 URL: https://issues.apache.org/jira/browse/MTOMCAT-169 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Environment: MAC OSX Reporter: Josh Harness Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor Attachments: MTOMCAT-169.patch Web app does not deploy via embedded tomcat (tomat7:run) when I define the following in my plugin config: webapps webapp groupIdcom.company/groupId artifactIdmywebapp/artifactId version1.0/version typewar/type /webapp /webapps I only see the following and am unable to use the web application: [INFO] Deploy warfile: /Users/joshar1/.m2/repository/com/company/mywebapp//1.0/mywebapp-1.0.war to contextPath: /mywebapp I have a patch I'll attach to this ticket. -- 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] [Commented] (MTOMCAT-170) Unable to Specify Additional Classpath for WAR Defined via webapps Declaration
[ https://issues.apache.org/jira/browse/MTOMCAT-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13425056#comment-13425056 ] Olivier Lamy (*$^¨%`£) commented on MTOMCAT-170: patch file doesn't say which class has been patched. Thanks Unable to Specify Additional Classpath for WAR Defined via webapps Declaration Key: MTOMCAT-170 URL: https://issues.apache.org/jira/browse/MTOMCAT-170 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Reporter: Josh Harness Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor Attachments: MTOMCAT-170.patch I need the ability for web application defined in the webapps portion of the plugin configuration to have the ability to use the classpath of the main plugin configuration. A reasonable approach might be to allow the webapp to inherit the additional classpath of the main web application config. I'll apply a patch shortly for feedback/review. -- 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
svn commit: r1367193 - /tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/AbstractRunMojo.java
Author: olamy Date: Mon Jul 30 18:02:51 2012 New Revision: 1367193 URL: http://svn.apache.org/viewvc?rev=1367193view=rev Log: [MTOMCAT-171] Multiple executions (i.e. sep tomcats clash due to identical JMX naming) Submitted by Neale Upstone. Modified: tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/AbstractRunMojo.java Modified: tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/AbstractRunMojo.java URL: http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/AbstractRunMojo.java?rev=1367193r1=1367192r2=1367193view=diff == --- tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/AbstractRunMojo.java (original) +++ tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/AbstractRunMojo.java Mon Jul 30 18:02:51 2012 @@ -809,7 +809,7 @@ public abstract class AbstractRunMojo // create engine Engine engine = container.createEngine(); -engine.setName( localEngine ); +engine.setName( localEngine- + port ); engine.addChild( host ); engine.setDefaultHost( host.getName() ); container.addEngine( engine ); - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-169) Unable to Deploy WAR Defined via webapps Declaration
[ https://issues.apache.org/jira/browse/MTOMCAT-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13425057#comment-13425057 ] Josh Harness commented on MTOMCAT-169: -- Sorry about that. MTOMCAT-170 has the same problem, too. I'll generate a new patch shortly and then attach it to both tickets. Unable to Deploy WAR Defined via webapps Declaration -- Key: MTOMCAT-169 URL: https://issues.apache.org/jira/browse/MTOMCAT-169 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Environment: MAC OSX Reporter: Josh Harness Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor Attachments: MTOMCAT-169.patch Web app does not deploy via embedded tomcat (tomat7:run) when I define the following in my plugin config: webapps webapp groupIdcom.company/groupId artifactIdmywebapp/artifactId version1.0/version typewar/type /webapp /webapps I only see the following and am unable to use the web application: [INFO] Deploy warfile: /Users/joshar1/.m2/repository/com/company/mywebapp//1.0/mywebapp-1.0.war to contextPath: /mywebapp I have a patch I'll attach to this ticket. -- 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-171) Multiple executions (i.e. sep tomcats clash due to identical JMX naming)
[ https://issues.apache.org/jira/browse/MTOMCAT-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-171. -- Resolution: Fixed Fix Version/s: 2.0 patch applied. Thanks! Multiple executions (i.e. sep tomcats clash due to identical JMX naming) Key: MTOMCAT-171 URL: https://issues.apache.org/jira/browse/MTOMCAT-171 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat6 Reporter: Neale Upstone Assignee: Olivier Lamy (*$^¨%`£) Fix For: 2.0 Attachments: mtomcat-171.patch If two executions are configured, for example to create two tomcat instances running on separate ports, these do not behave independently, as they get identified to JMX using the same names. Some disambiguation is required, for which the httpPort might be enough (this works for me for tomcat6) // create engine Engine engine = container.createEngine(); -engine.setName( localEngine ); +engine.setName( localEngine- + port); engine.addChild( host ); engine.setDefaultHost( host.getName() ); -- 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] [Updated] (MTOMCAT-170) Unable to Specify Additional Classpath for WAR Defined via webapps Declaration
[ https://issues.apache.org/jira/browse/MTOMCAT-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Harness updated MTOMCAT-170: - Attachment: (was: MTOMCAT-170.patch) Unable to Specify Additional Classpath for WAR Defined via webapps Declaration Key: MTOMCAT-170 URL: https://issues.apache.org/jira/browse/MTOMCAT-170 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Reporter: Josh Harness Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor Attachments: MTOMCAT-170.patch I need the ability for web application defined in the webapps portion of the plugin configuration to have the ability to use the classpath of the main plugin configuration. A reasonable approach might be to allow the webapp to inherit the additional classpath of the main web application config. I'll apply a patch shortly for feedback/review. -- 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] [Updated] (MTOMCAT-170) Unable to Specify Additional Classpath for WAR Defined via webapps Declaration
[ https://issues.apache.org/jira/browse/MTOMCAT-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Harness updated MTOMCAT-170: - Attachment: MTOMCAT-170.patch Patch file for issue - generated from local development repo. Unable to Specify Additional Classpath for WAR Defined via webapps Declaration Key: MTOMCAT-170 URL: https://issues.apache.org/jira/browse/MTOMCAT-170 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Reporter: Josh Harness Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor Attachments: MTOMCAT-170.patch I need the ability for web application defined in the webapps portion of the plugin configuration to have the ability to use the classpath of the main plugin configuration. A reasonable approach might be to allow the webapp to inherit the additional classpath of the main web application config. I'll apply a patch shortly for feedback/review. -- 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
svn commit: r1367206 - in /tomcat/trunk/java/org/apache/catalina/tribes/membership: LocalStrings.properties McastService.java
Author: markt
Date: Mon Jul 30 18:19:27 2012
New Revision: 1367206
URL: http://svn.apache.org/viewvc?rev=1367206view=rev
Log:
Fix unused StringManager`. i18n for all log messages
Added:
tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings.properties
(with props)
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
Added:
tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings.properties?rev=1367206view=auto
==
---
tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings.properties
(added)
+++
tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings.properties
Mon Jul 30 18:19:27 2012
@@ -0,0 +1,20 @@
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the License); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an AS IS BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+McastService.parseTTL=Unable to parse TTL: [{0}]
+McastService.parseSoTimeout=Unable to parse SoTimeout: [{0}]
+McastService.stopFail=Unable to stop the mcast service, level: [{0}]
+McastService.payload=Unable to send payload update
+McastService.domain=Unable to send domain update
Propchange:
tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings.properties
--
svn:eol-style = native
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java?rev=1367206r1=1367205r2=1367206view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
Mon Jul 30 18:19:27 2012
@@ -330,14 +330,16 @@ public class McastService implements Mem
try {
ttl = Integer.parseInt(properties.getProperty(mcastTTL));
} catch ( Exception x ) {
-log.error(Unable to parse
mcastTTL=+properties.getProperty(mcastTTL),x);
+log.error(sm.getString(McastService.parseTTL,
+properties.getProperty(mcastTTL)), x);
}
}
if ( properties.getProperty(mcastSoTimeout) != null ) {
try {
soTimeout =
Integer.parseInt(properties.getProperty(mcastSoTimeout));
} catch ( Exception x ) {
-log.error(Unable to parse
mcastSoTimeout=+properties.getProperty(mcastSoTimeout),x);
+log.error(sm.getString(McastService.parseTTL,
+properties.getProperty(mcastSoTimeout)), x);
}
}
@@ -374,7 +376,8 @@ public class McastService implements Mem
try {
if ( impl != null impl.stop(svc) ) impl = null;
} catch ( Exception x) {
-log.error(Unable to stop the mcast service, level:+svc+.,x);
+log.error(sm.getString(
+McastService.stopFail, Integer.valueOf(svc)), x);
}
}
@@ -534,7 +537,7 @@ public class McastService implements Mem
try {
if (impl != null) impl.send(false);
}catch ( Exception x ) {
-log.error(Unable to send payload update.,x);
+log.error(sm.getString(McastService.payload), x);
}
}
}
@@ -548,7 +551,7 @@ public class McastService implements Mem
try {
if (impl != null) impl.send(false);
}catch ( Exception x ) {
-log.error(Unable to send domain update.,x);
+log.error(sm.getString(McastService.domain), x);
}
}
}
@@ -565,8 +568,6 @@ public class McastService implements Mem
* @throws Exception If an error occurs
*/
public static void main(String args[]) throws Exception {
-if(log.isInfoEnabled())
-log.info(Usage McastService hostname tcpport);
McastService service = new McastService();
java.util.Properties p
[jira] [Updated] (MTOMCAT-169) Unable to Deploy WAR Defined via webapps Declaration
[ https://issues.apache.org/jira/browse/MTOMCAT-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Harness updated MTOMCAT-169: - Attachment: (was: MTOMCAT-169.patch) Unable to Deploy WAR Defined via webapps Declaration -- Key: MTOMCAT-169 URL: https://issues.apache.org/jira/browse/MTOMCAT-169 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Environment: MAC OSX Reporter: Josh Harness Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor Attachments: MTOMCAT-169.patch Web app does not deploy via embedded tomcat (tomat7:run) when I define the following in my plugin config: webapps webapp groupIdcom.company/groupId artifactIdmywebapp/artifactId version1.0/version typewar/type /webapp /webapps I only see the following and am unable to use the web application: [INFO] Deploy warfile: /Users/joshar1/.m2/repository/com/company/mywebapp//1.0/mywebapp-1.0.war to contextPath: /mywebapp I have a patch I'll attach to this ticket. -- 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] [Updated] (MTOMCAT-169) Unable to Deploy WAR Defined via webapps Declaration
[ https://issues.apache.org/jira/browse/MTOMCAT-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Harness updated MTOMCAT-169: - Attachment: MTOMCAT-169.patch patch generated from local development repository. Note that it will conflict with M170, but I wanted to have the patches stand by themselves. Unable to Deploy WAR Defined via webapps Declaration -- Key: MTOMCAT-169 URL: https://issues.apache.org/jira/browse/MTOMCAT-169 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Environment: MAC OSX Reporter: Josh Harness Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor Attachments: MTOMCAT-169.patch Web app does not deploy via embedded tomcat (tomat7:run) when I define the following in my plugin config: webapps webapp groupIdcom.company/groupId artifactIdmywebapp/artifactId version1.0/version typewar/type /webapp /webapps I only see the following and am unable to use the web application: [INFO] Deploy warfile: /Users/joshar1/.m2/repository/com/company/mywebapp//1.0/mywebapp-1.0.war to contextPath: /mywebapp I have a patch I'll attach to this ticket. -- 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
svn commit: r1367214 - /tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
Author: markt
Date: Mon Jul 30 18:34:57 2012
New Revision: 1367214
URL: http://svn.apache.org/viewvc?rev=1367214view=rev
Log:
Deprecate unused code
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java?rev=1367214r1=1367213r2=1367214view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java Mon
Jul 30 18:34:57 2012
@@ -41,11 +41,21 @@ public class MemberImpl implements Membe
* default is false
*/
public static final boolean DO_DNS_LOOKUPS =
Boolean.parseBoolean(System.getProperty(org.apache.catalina.tribes.dns_lookups,false));
+
/**
- * Public properties specific to this implementation
+ * @deprecated Unused - will be removed in Tomcat 8.0.x
*/
+@Deprecated
public static final transient String TCP_LISTEN_PORT = tcpListenPort;
+/**
+ * @deprecated Unused - will be removed in Tomcat 8.0.x
+ */
+@Deprecated
public static final transient String TCP_LISTEN_HOST = tcpListenHost;
+/**
+ * @deprecated Unused - will be removed in Tomcat 8.0.x
+ */
+@Deprecated
public static final transient String MEMBER_NAME = memberName;
public static final transient byte[] TRIBES_MBR_BEGIN = new byte[] {84,
82, 73, 66, 69, 83, 45, 66, 1, 0};
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1367215 - /tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
Author: markt
Date: Mon Jul 30 18:36:04 2012
New Revision: 1367215
URL: http://svn.apache.org/viewvc?rev=1367215view=rev
Log:
Remove unused code
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java?rev=1367215r1=1367214r2=1367215view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java Mon
Jul 30 18:36:04 2012
@@ -42,22 +42,6 @@ public class MemberImpl implements Membe
*/
public static final boolean DO_DNS_LOOKUPS =
Boolean.parseBoolean(System.getProperty(org.apache.catalina.tribes.dns_lookups,false));
-/**
- * @deprecated Unused - will be removed in Tomcat 8.0.x
- */
-@Deprecated
-public static final transient String TCP_LISTEN_PORT = tcpListenPort;
-/**
- * @deprecated Unused - will be removed in Tomcat 8.0.x
- */
-@Deprecated
-public static final transient String TCP_LISTEN_HOST = tcpListenHost;
-/**
- * @deprecated Unused - will be removed in Tomcat 8.0.x
- */
-@Deprecated
-public static final transient String MEMBER_NAME = memberName;
-
public static final transient byte[] TRIBES_MBR_BEGIN = new byte[] {84,
82, 73, 66, 69, 83, 45, 66, 1, 0};
public static final transient byte[] TRIBES_MBR_END = new byte[] {84,
82, 73, 66, 69, 83, 45, 69, 1, 0};
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1367218 - in /tomcat/trunk/java/org/apache/catalina/tribes/membership: McastServiceImpl.java Membership.java
Author: markt
Date: Mon Jul 30 18:40:34 2012
New Revision: 1367218
URL: http://svn.apache.org/viewvc?rev=1367218view=rev
Log:
Partial code clean-up for o.a.catalina.tribes
- Add final prompted by UCDetector
- Java 7 use of
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java?rev=1367218r1=1367217r2=1367218view=diff
==
---
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
Mon Jul 30 18:40:34 2012
@@ -53,7 +53,7 @@ public class McastServiceImpl
private static final org.apache.juli.logging.Log log =
org.apache.juli.logging.LogFactory.getLog( McastService.class );
-protected static int MAX_PACKET_SIZE = 65535;
+protected static final int MAX_PACKET_SIZE = 65535;
/**
* Internal flag used for the listen thread that listens to the
multicasting socket.
*/
@@ -67,23 +67,23 @@ public class McastServiceImpl
/**
* The local member that we intend to broad cast over and over again
*/
-protected MemberImpl member;
+protected final MemberImpl member;
/**
* The multicast address
*/
-protected InetAddress address;
+protected final InetAddress address;
/**
* The multicast port
*/
-protected int port;
+protected final int port;
/**
* The time it takes for a member to expire.
*/
-protected long timeToExpiration;
+protected final long timeToExpiration;
/**
* How often to we send out a broadcast saying we are alive, must be
smaller than timeToExpiration
*/
-protected long sendFrequency;
+protected final long sendFrequency;
/**
* Reuse the sendPacket, no need to create a new one everytime
*/
@@ -99,11 +99,11 @@ public class McastServiceImpl
/**
* The actual listener, for callback when stuff goes down
*/
-protected MembershipListener service;
+protected final MembershipListener service;
/**
* The actual listener for broadcast callbacks
*/
-protected MessageListener msgservice;
+protected final MessageListener msgservice;
/**
* Thread to listen for pings
*/
@@ -116,7 +116,7 @@ public class McastServiceImpl
/**
* Time to live for the multicast packets that are being sent out
*/
-protected int mcastTTL = -1;
+protected final int mcastTTL;
/**
* Read timeout on the mcast socket
*/
@@ -124,7 +124,7 @@ public class McastServiceImpl
/**
* bind address
*/
-protected InetAddress mcastBindAddress = null;
+protected final InetAddress mcastBindAddress;
/**
* nr of times the system has to fail before a recovery is initiated
@@ -144,12 +144,13 @@ public class McastServiceImpl
/**
* Dont interrupt the sender/receiver thread, but pass off to an executor
*/
-protected ExecutorService executor = ExecutorFactory.newThreadPool(0, 2,
2, TimeUnit.SECONDS);
+protected final ExecutorService executor =
+ExecutorFactory.newThreadPool(0, 2, 2, TimeUnit.SECONDS);
/**
* disable/enable local loopback message
*/
-protected boolean localLoopbackDisabled = false;
+protected final boolean localLoopbackDisabled;
/**
* Create a new mcast service impl
@@ -552,7 +553,7 @@ public class McastServiceImpl
}//class ReceiverThread
public class SenderThread extends Thread {
-long time;
+final long time;
int errorCounter=0;
public SenderThread(long time) {
this.time = time;
@@ -596,7 +597,7 @@ public class McastServiceImpl
}
-McastServiceImpl parent = null;
+final McastServiceImpl parent;
public RecoveryThread(McastServiceImpl parent) {
this.parent = parent;
}
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java?rev=1367218r1=1367217r2=1367218view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java Mon
Jul 30 18:40:34 2012
@@ -48,12 +48,12 @@ public class Membership implements Clone
* The name of this membership, has to be the same as the name for the
local
* member
*/
-protected MemberImpl
[jira] [Commented] (MTOMCAT-171) Multiple executions (i.e. sep tomcats clash due to identical JMX naming)
[ https://issues.apache.org/jira/browse/MTOMCAT-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13425118#comment-13425118 ] Hudson commented on MTOMCAT-171: Integrated in TomcatMavenPlugin-mvn3.x #184 (See [https://builds.apache.org/job/TomcatMavenPlugin-mvn3.x/184/]) [MTOMCAT-171] Multiple executions (i.e. sep tomcats clash due to identical JMX naming) Submitted by Neale Upstone. (Revision 1367193) Result = FAILURE olamy : http://svn.apache.org/viewvc/?view=revrev=1367193 Files : * /tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/AbstractRunMojo.java Multiple executions (i.e. sep tomcats clash due to identical JMX naming) Key: MTOMCAT-171 URL: https://issues.apache.org/jira/browse/MTOMCAT-171 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat6 Reporter: Neale Upstone Assignee: Olivier Lamy (*$^¨%`£) Fix For: 2.0 Attachments: mtomcat-171.patch If two executions are configured, for example to create two tomcat instances running on separate ports, these do not behave independently, as they get identified to JMX using the same names. Some disambiguation is required, for which the httpPort might be enough (this works for me for tomcat6) // create engine Engine engine = container.createEngine(); -engine.setName( localEngine ); +engine.setName( localEngine- + port); engine.addChild( host ); engine.setDefaultHost( host.getName() ); -- 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
[Bug 53623] New: Incorrect request properties after AsyncContext.dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=53623 Priority: P2 Bug ID: 53623 Assignee: dev@tomcat.apache.org Summary: Incorrect request properties after AsyncContext.dispatch Severity: normal Classification: Unclassified OS: Linux Reporter: rstoyanc...@yahoo.com Hardware: PC Status: NEW Version: 7.0.29 Component: Catalina Product: Tomcat 7 In a scenario that involves a forward, a call to startAsync, and then dispatch(path), the properties of the request after the dispatch do not match the path and query params used to send the dispatch. A project demonstrating the issue: https://github.com/rstoyanchev/dispatch-test Build and deploy the sources in the 'tomcat-issue-repro' branch. From the home page of the deployed application, select the Dispatch via AsyncContext scenario. The scenario involves a couple of forwards from ServletA to Servlet B and then ServletC, which in turn starts a thread and dispatches to Servlet D that forwards to a JSP. See WebAppInitializer.setupDispatchScenario(ServletContext) for details on the setup. The log output shows the content of the request as each Servlet is entered. It all looks as expected until after the dispatch to ServletD where the requestUri, servletPath, and pathInfo are for ServletC. --- The second scenario on the home page, Dispatch via AsyncContext and wrap request, wraps the request and that yields slightly different (but also incorrect) results. The requestUri/servletPath/pathInfo and also the parameterMap, in the application thread and after dispatch, both match the state of the request in ServletA. --- FWIW there are also a couple of similar scenarios that use forwarding instead of dispatching. The Forward via RequestDispatcher scenario appears to work all the way through while the Forward via RequestDispatcher and wrap request almost works except the state of the request in the async thread only matches that of ServletA. -- 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 53624] New: sendRedirect doesn't work after a dispatch through the AsyncContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=53624 Priority: P2 Bug ID: 53624 Assignee: dev@tomcat.apache.org Summary: sendRedirect doesn't work after a dispatch through the AsyncContext Severity: normal Classification: Unclassified OS: Linux Reporter: rstoyanc...@yahoo.com Hardware: PC Status: NEW Version: 7.0.29 Component: Catalina Product: Tomcat 7 A call to sendRedirect after AsyncContext.dispatch doesn't redirect and returns with a 200 status code instead. A project demonstrating the issue: https://github.com/rstoyanchev/dispatch-test Build and deploy the source in the 'tomcat-issue-repro'. From the home page of the deployed application, select the Redirect scenario. The scenario involves Servlet RedirectA that creates a thread and dispatches to Servlet RedirectB, which in turn redirects to Servlet RedirectC and that forwards to a simple JSP page. Instead of the JSP page rendering, you should see a blank page and the log output will show that processing ended at ServletC. For details on the setup see WebAppInitializer.setupRedirectScenario(ServletContext). --- FWIW if a forward is used instead of a dispatch from the async thread, the scenario works. To do that, modify the line that creates servlet RedirectA to be ForwardingAsyncServlet instead of DispatchingAsyncServlet. --- This issue is very similar to 51197, which was marked resolved in 7.0.25. The current issue was tested against 7.0.29. -- 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: r1367313 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/mapper/ java/org/apache/catalina/startup/
Author: markt Date: Mon Jul 30 21:23:18 2012 New Revision: 1367313 URL: http://svn.apache.org/viewvc?rev=1367313view=rev Log: Refactoring. Move Mapper. Preparation for further mapper related refactoring to follow. Added: tomcat/trunk/java/org/apache/catalina/mapper/ - copied from r1366723, tomcat/trunk/java/org/apache/tomcat/util/http/mapper/ tomcat/trunk/test/org/apache/catalina/mapper/ - copied from r1366723, tomcat/trunk/test/org/apache/tomcat/util/http/mapper/ Removed: tomcat/trunk/java/org/apache/tomcat/util/http/mapper/ tomcat/trunk/test/org/apache/tomcat/util/http/mapper/ Modified: tomcat/trunk/java/org/apache/catalina/Context.java tomcat/trunk/java/org/apache/catalina/connector/Connector.java tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java tomcat/trunk/java/org/apache/catalina/connector/Request.java tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java tomcat/trunk/java/org/apache/catalina/core/StandardContext.java tomcat/trunk/java/org/apache/catalina/mapper/Mapper.java tomcat/trunk/java/org/apache/catalina/mapper/MappingData.java tomcat/trunk/java/org/apache/catalina/startup/FailedContext.java tomcat/trunk/test/org/apache/catalina/mapper/TestMapper.java tomcat/trunk/test/org/apache/catalina/mapper/TestMapperContextRoot.java tomcat/trunk/test/org/apache/catalina/mapper/TestMapperWelcomeFiles.java Modified: tomcat/trunk/java/org/apache/catalina/Context.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Context.java?rev=1367313r1=1367312r2=1367313view=diff == --- tomcat/trunk/java/org/apache/catalina/Context.java (original) +++ tomcat/trunk/java/org/apache/catalina/Context.java Mon Jul 30 21:23:18 2012 @@ -35,8 +35,8 @@ import org.apache.catalina.deploy.Filter import org.apache.catalina.deploy.LoginConfig; import org.apache.catalina.deploy.NamingResources; import org.apache.catalina.deploy.SecurityConstraint; +import org.apache.catalina.mapper.Mapper; import org.apache.tomcat.JarScanner; -import org.apache.tomcat.util.http.mapper.Mapper; /** * A bContext/b is a Container that represents a servlet context, and Modified: tomcat/trunk/java/org/apache/catalina/connector/Connector.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Connector.java?rev=1367313r1=1367312r2=1367313view=diff == --- tomcat/trunk/java/org/apache/catalina/connector/Connector.java (original) +++ tomcat/trunk/java/org/apache/catalina/connector/Connector.java Mon Jul 30 21:23:18 2012 @@ -27,13 +27,13 @@ import org.apache.catalina.LifecycleExce import org.apache.catalina.LifecycleState; import org.apache.catalina.Service; import org.apache.catalina.core.AprLifecycleListener; +import org.apache.catalina.mapper.Mapper; import org.apache.catalina.util.LifecycleMBeanBase; import org.apache.coyote.Adapter; import org.apache.coyote.ProtocolHandler; import org.apache.juli.logging.Log; import org.apache.juli.logging.LogFactory; import org.apache.tomcat.util.IntrospectionUtils; -import org.apache.tomcat.util.http.mapper.Mapper; import org.apache.tomcat.util.res.StringManager; Modified: tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java?rev=1367313r1=1367312r2=1367313view=diff == --- tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java (original) +++ tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java Mon Jul 30 21:23:18 2012 @@ -28,10 +28,10 @@ import org.apache.catalina.LifecycleExce import org.apache.catalina.LifecycleListener; import org.apache.catalina.LifecycleState; import org.apache.catalina.Wrapper; +import org.apache.catalina.mapper.Mapper; import org.apache.catalina.util.LifecycleMBeanBase; import org.apache.juli.logging.Log; import org.apache.juli.logging.LogFactory; -import org.apache.tomcat.util.http.mapper.Mapper; import org.apache.tomcat.util.res.StringManager; Modified: tomcat/trunk/java/org/apache/catalina/connector/Request.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?rev=1367313r1=1367312r2=1367313view=diff == --- tomcat/trunk/java/org/apache/catalina/connector/Request.java (original) +++ tomcat/trunk/java/org/apache/catalina/connector/Request.java Mon Jul 30 21:23:18 2012 @@ -72,6 +72,7 @@ import org.apache.catalina.Wrapper; import org.apache.catalina.core.ApplicationPart; import org.apache.catalina.core.ApplicationSessionCookieConfig; import org.apache.catalina.core.AsyncContextImpl; +import
svn commit: r1367314 - /tomcat/trunk/TOMCAT-NEXT.txt
Author: markt Date: Mon Jul 30 21:23:46 2012 New Revision: 1367314 URL: http://svn.apache.org/viewvc?rev=1367314view=rev Log: Update progress Modified: tomcat/trunk/TOMCAT-NEXT.txt Modified: tomcat/trunk/TOMCAT-NEXT.txt URL: http://svn.apache.org/viewvc/tomcat/trunk/TOMCAT-NEXT.txt?rev=1367314r1=1367313r2=1367314view=diff == --- tomcat/trunk/TOMCAT-NEXT.txt (original) +++ tomcat/trunk/TOMCAT-NEXT.txt Mon Jul 30 21:23:46 2012 @@ -45,7 +45,6 @@ but possibly 7.1.x). Supporting re-factoring to consider arising from the above - Move Mapper from Connector to Service/Engine (saves duplication) - Remove Mapper from Context - use Mapper from Service -- Move mapper classes to o.a.catalina 8. Review the connector shutdown code for timing and threading issues particularly any that may result in a client socket being left open after a - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1367329 - in /tomcat/trunk: ./ java/org/apache/catalina/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/mapper/ webapps/docs/
Author: markt
Date: Mon Jul 30 21:53:56 2012
New Revision: 1367329
URL: http://svn.apache.org/viewvc?rev=1367329view=rev
Log:
Move Mapper from Connector to Service removing potential duplication.
Added:
tomcat/trunk/java/org/apache/catalina/mapper/Constants.java (with props)
tomcat/trunk/java/org/apache/catalina/mapper/MapperListener.java
- copied, changed from r1367313,
tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java
Removed:
tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java
Modified:
tomcat/trunk/TOMCAT-NEXT.txt
tomcat/trunk/java/org/apache/catalina/Service.java
tomcat/trunk/java/org/apache/catalina/connector/Connector.java
tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/connector/LocalStrings_es.properties
tomcat/trunk/java/org/apache/catalina/connector/LocalStrings_fr.properties
tomcat/trunk/java/org/apache/catalina/connector/LocalStrings_ja.properties
tomcat/trunk/java/org/apache/catalina/core/StandardService.java
tomcat/trunk/java/org/apache/catalina/mapper/LocalStrings.properties
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/TOMCAT-NEXT.txt
URL:
http://svn.apache.org/viewvc/tomcat/trunk/TOMCAT-NEXT.txt?rev=1367329r1=1367328r2=1367329view=diff
==
--- tomcat/trunk/TOMCAT-NEXT.txt (original)
+++ tomcat/trunk/TOMCAT-NEXT.txt Mon Jul 30 21:53:56 2012
@@ -43,7 +43,7 @@ but possibly 7.1.x).
7. Rip out all the JNDI code in resource handling and replace it with straight
URLs (File or WAR).
Supporting re-factoring to consider arising from the above
-- Move Mapper from Connector to Service/Engine (saves duplication)
+- Move Mapper from Connector to Service (saves duplication)
- Remove Mapper from Context - use Mapper from Service
8. Review the connector shutdown code for timing and threading issues
Modified: tomcat/trunk/java/org/apache/catalina/Service.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Service.java?rev=1367329r1=1367328r2=1367329view=diff
==
--- tomcat/trunk/java/org/apache/catalina/Service.java (original)
+++ tomcat/trunk/java/org/apache/catalina/Service.java Mon Jul 30 21:53:56 2012
@@ -19,6 +19,7 @@
package org.apache.catalina;
import org.apache.catalina.connector.Connector;
+import org.apache.catalina.mapper.Mapper;
/**
* A strongService/strong is a group of one or more
@@ -147,4 +148,8 @@ public interface Service extends Lifecyc
*/
public void removeExecutor(Executor ex);
+/**
+ * The mapper associated with this Service.
+ */
+Mapper getMapper();
}
Modified: tomcat/trunk/java/org/apache/catalina/connector/Connector.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Connector.java?rev=1367329r1=1367328r2=1367329view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Connector.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Connector.java Mon Jul 30
21:53:56 2012
@@ -27,7 +27,6 @@ import org.apache.catalina.LifecycleExce
import org.apache.catalina.LifecycleState;
import org.apache.catalina.Service;
import org.apache.catalina.core.AprLifecycleListener;
-import org.apache.catalina.mapper.Mapper;
import org.apache.catalina.util.LifecycleMBeanBase;
import org.apache.coyote.Adapter;
import org.apache.coyote.ProtocolHandler;
@@ -223,19 +222,6 @@ public class Connector extends Lifecycle
/**
- * Mapper.
- */
- protected final Mapper mapper = new Mapper();
-
-
- /**
- * Mapper listener.
- */
- protected final MapperListener mapperListener =
- new MapperListener(mapper, this);
-
-
- /**
* URI encoding.
*/
protected String URIEncoding = null;
@@ -390,14 +376,6 @@ public class Connector extends Lifecycle
/**
- * Return the mapper.
- */
-public Mapper getMapper() {
-return (mapper);
-}
-
-
-/**
* Return the maximum number of headers that are allowed by the container.
A
* value of less than 0 means no limit.
*/
@@ -970,9 +948,6 @@ public class Connector extends Lifecycle
(sm.getString
(coyoteConnector.protocolHandlerInitializationFailed), e);
}
-
-// Initialize mapper listener
-mapperListener.init();
}
@@ -1004,8 +979,6 @@ public class Connector extends Lifecycle
(errPrefix + + sm.getString
(coyoteConnector.protocolHandlerStartFailed), e);
}
-
-mapperListener.start();
}
@@ -1026,15 +999,11 @@ public
svn commit: r1367330 - /tomcat/trunk/java/org/apache/catalina/mapper/Mapper.java
Author: markt
Date: Mon Jul 30 21:57:05 2012
New Revision: 1367330
URL: http://svn.apache.org/viewvc?rev=1367330view=rev
Log:
Avoid unlikely NPE
Modified:
tomcat/trunk/java/org/apache/catalina/mapper/Mapper.java
Modified: tomcat/trunk/java/org/apache/catalina/mapper/Mapper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/mapper/Mapper.java?rev=1367330r1=1367329r2=1367330view=diff
==
--- tomcat/trunk/java/org/apache/catalina/mapper/Mapper.java (original)
+++ tomcat/trunk/java/org/apache/catalina/mapper/Mapper.java Mon Jul 30
21:57:05 2012
@@ -740,7 +740,7 @@ public final class Mapper {
}
// Context mapping
-if (mappingData.context == null) {
+if (mappingData.context == null contexts != null) {
int pos = find(contexts, uri);
if (pos == -1) {
return;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1367331 - /tomcat/trunk/TOMCAT-NEXT.txt
Author: markt Date: Mon Jul 30 21:58:43 2012 New Revision: 1367331 URL: http://svn.apache.org/viewvc?rev=1367331view=rev Log: More progress Modified: tomcat/trunk/TOMCAT-NEXT.txt Modified: tomcat/trunk/TOMCAT-NEXT.txt URL: http://svn.apache.org/viewvc/tomcat/trunk/TOMCAT-NEXT.txt?rev=1367331r1=1367330r2=1367331view=diff == --- tomcat/trunk/TOMCAT-NEXT.txt (original) +++ tomcat/trunk/TOMCAT-NEXT.txt Mon Jul 30 21:58:43 2012 @@ -43,7 +43,6 @@ but possibly 7.1.x). 7. Rip out all the JNDI code in resource handling and replace it with straight URLs (File or WAR). Supporting re-factoring to consider arising from the above -- Move Mapper from Connector to Service (saves duplication) - Remove Mapper from Context - use Mapper from Service 8. Review the connector shutdown code for timing and threading issues - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53605] use tcnative-1.1.24 Tomcat shutdown still crash
https://issues.apache.org/bugzilla/show_bug.cgi?id=53605 Michael Hobbs michael.ho...@infusionsoft.com changed: What|Removed |Added CC||michael.hobbs@infusionsoft. ||com -- 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
[GUMP@vmgump]: Project tomcat-trunk-validate-eoln (in module tomcat-trunk) 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-trunk-validate-eoln has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 35 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-validate-eoln : 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-validate-eoln/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/gump_work/build_tomcat-trunk_tomcat-trunk-validate-eoln.html Work Name: build_tomcat-trunk_tomcat-trunk-validate-eoln (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec 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 validate-eoln [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar - Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml build-prepare: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/classes [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/bin [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/conf [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/lib [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/logs [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/temp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/webapps compile-prepare: [copy] Copying 1 file to /srv/gump/public/workspace/tomcat-trunk/java/org/apache/catalina/startup [copy] Copying 1 file to /srv/gump/public/workspace/tomcat-trunk/webapps/docs validate-eoln: [javac] Compiling 1 source file to /srv/gump/public/workspace/tomcat-trunk/output/classes [javac] javac: invalid target release: 1.7 [javac] Usage: javac options source files [javac] use -help for a list of possible options BUILD FAILED /srv/gump/public/workspace/tomcat-trunk/build.xml:523: Compile failed; see the compiler error output for details. Total time: 1 second - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/rss.xml - Atom: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1231072012, vmgump.apache.org:vmgump:1231072012 Gump E-mail Identifier (unique within run) #14. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53627] New: Content-Type header not written after dispatch via AsyncContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=53627 Priority: P2 Bug ID: 53627 Assignee: dev@tomcat.apache.org Summary: Content-Type header not written after dispatch via AsyncContext Severity: normal Classification: Unclassified OS: Linux Reporter: rstoyanc...@yahoo.com Hardware: PC Status: NEW Version: 7.0.29 Component: Catalina Product: Tomcat 7 After a dispatch via AsyncContext, the 'Content-Type' header does not appear in the response on the client side even though it is set on the server side via response.setContentType(String). A project demonstrating the issue: https://github.com/rstoyanchev/dispatch-test Checkout the source from the 'tomcat-issue-repro' branch. When the application is deployed, from the home page choose the JSON content scenario. The scenario involves one Servlet that creates a thread and dispatches to a second Servlet that sets the contentType property of the response to application/json and writes some JSON content. However, the 'Content-Type' header does not appear in the response. For details on the setup see WebAppInitializer.setupJsonSecnario(ServletContext). FWIW, if forwarding is used from the application thread instead of a dispatch through the AsyncContext, the response contains the 'Content-Type' header. To see that modify the line that sets up servlet JsonA in WebAppInitializer.setupJsonScenario(ServletContext) to create a ForwardingAsyncServlet instead of a DispatchingAsyncServlet. -- 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
