[jira] [Updated] (MTOMCAT-153) align all Maven dependency versions to 2.0.11
[ https://issues.apache.org/jira/browse/MTOMCAT-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) updated MTOMCAT-153: --- Fix Version/s: 2.0 Assignee: Olivier Lamy (*$^¨%`£) > align all Maven dependency versions to 2.0.11 > - > > Key: MTOMCAT-153 > URL: https://issues.apache.org/jira/browse/MTOMCAT-153 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Peter lynch >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 2.0 > > Attachments: align-maven-versions.patch > > > There are several different, old versions of Maven artifact dependencies in > use. > Attached patch align's all of these to 2.0.11 -- 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: r1340916 - /tomcat/maven-plugin/trunk/pom.xml
Author: olamy
Date: Mon May 21 08:10:26 2012
New Revision: 1340916
URL: http://svn.apache.org/viewvc?rev=1340916&view=rev
Log:
[MTOMCAT-153] align all Maven dependency versions to 2.0.11
Submitted by Peter lynch.
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=1340916&r1=1340915&r2=1340916&view=diff
==
--- tomcat/maven-plugin/trunk/pom.xml (original)
+++ tomcat/maven-plugin/trunk/pom.xml Mon May 21 08:10:26 2012
@@ -38,12 +38,12 @@
http://tomcat.apache.org/maven-plugin-${project.version}
-
+
UTF-8
1.5
1.5
-2.0.8
+2.0.11
false
2.12
@@ -403,6 +403,46 @@
org.apache.maven
+maven-model
+${mavenVersion}
+
+
+org.apache.maven
+maven-core
+${mavenVersion}
+
+
+org.apache.maven
+maven-plugin-parameter-documenter
+${mavenVersion}
+
+
+org.apache.maven
+maven-repository-metadata
+${mavenVersion}
+
+
+org.apache.maven
+maven-error-diagnostics
+${mavenVersion}
+
+
+org.apache.maven
+maven-plugin-descriptor
+${mavenVersion}
+
+
+org.apache.maven
+maven-monitor
+${mavenVersion}
+
+
+org.apache.maven
+maven-settings
+${mavenVersion}
+
+
+org.apache.maven
maven-archiver
2.4.2
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1340917 - /tomcat/maven-plugin/trunk/pom.xml
Author: olamy Date: Mon May 21 08:10:33 2012 New Revision: 1340917 URL: http://svn.apache.org/viewvc?rev=1340917&view=rev Log: add Peter Lynch in contributor section 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=1340917&r1=1340916&r2=1340917&view=diff == --- tomcat/maven-plugin/trunk/pom.xml (original) +++ tomcat/maven-plugin/trunk/pom.xml Mon May 21 08:10:33 2012 @@ -101,6 +101,9 @@ Mark Michaelis + + Peter Lynch + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Closed] (MTOMCAT-153) align all Maven dependency versions to 2.0.11
[ https://issues.apache.org/jira/browse/MTOMCAT-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-153. -- Resolution: Fixed fixed. Thanks ! > align all Maven dependency versions to 2.0.11 > - > > Key: MTOMCAT-153 > URL: https://issues.apache.org/jira/browse/MTOMCAT-153 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Peter lynch >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 2.0 > > Attachments: align-maven-versions.patch > > > There are several different, old versions of Maven artifact dependencies in > use. > Attached patch align's all of these to 2.0.11 -- 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: r1340918 - /tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java
Author: olamy Date: Mon May 21 08:12:53 2012 New Revision: 1340918 URL: http://svn.apache.org/viewvc?rev=1340918&view=rev Log: [MTOMCAT-154] support exec-war war run dependencies with classifiers Submitted by Peter Lynch. Modified: tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java Modified: tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java URL: http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java?rev=1340918&r1=1340917&r2=1340918&view=diff == --- tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java (original) +++ tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java Mon May 21 08:12:53 2012 @@ -322,9 +322,9 @@ public abstract class AbstractExecWarMoj Dependency dependency = warRunDependency.dependency; // String groupId, String artifactId, String version, String scope, String type Artifact artifact = -artifactFactory.createArtifact( dependency.getGroupId(), dependency.getArtifactId(), - dependency.getVersion(), dependency.getScope(), - dependency.getType() ); +artifactFactory.createArtifactWithClassifier( dependency.getGroupId(), dependency.getArtifactId(), + dependency.getVersion(), dependency.getType(), + dependency.getClassifier() ); artifactResolver.resolve( artifact, this.remoteRepos, this.local ); File warFile = new File( buildDirectory, artifact.getFile().getName() ); - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Closed] (MTOMCAT-154) support exec-war war run dependencies with classifiers
[ https://issues.apache.org/jira/browse/MTOMCAT-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-154. -- Resolution: Fixed Fix Version/s: 2.0 fixed. Thanks! > support exec-war war run dependencies with classifiers > -- > > Key: MTOMCAT-154 > URL: https://issues.apache.org/jira/browse/MTOMCAT-154 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement > Components: tomcat7 >Reporter: Peter lynch >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 2.0 > > Attachments: support-warRunDependency-classifier.patch > > > Specifying war run dependency with a classifier is not resolved. > Current code does not specify the classifier when resolving the war run > dependency artifact. Attached patch supports resolving wars with classifiers. -- 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-153) align all Maven dependency versions to 2.0.11
[ https://issues.apache.org/jira/browse/MTOMCAT-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280017#comment-13280017 ] Hudson commented on MTOMCAT-153: Integrated in TomcatMavenPlugin-mvn3.x #150 (See [https://builds.apache.org/job/TomcatMavenPlugin-mvn3.x/150/]) [MTOMCAT-153] align all Maven dependency versions to 2.0.11 Submitted by Peter lynch. (Revision 1340916) Result = SUCCESS olamy : http://svn.apache.org/viewvc/?view=rev&rev=1340916 Files : * /tomcat/maven-plugin/trunk/pom.xml > align all Maven dependency versions to 2.0.11 > - > > Key: MTOMCAT-153 > URL: https://issues.apache.org/jira/browse/MTOMCAT-153 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Peter lynch >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 2.0 > > Attachments: align-maven-versions.patch > > > There are several different, old versions of Maven artifact dependencies in > use. > Attached patch align's all of these to 2.0.11 -- 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-154) support exec-war war run dependencies with classifiers
[ https://issues.apache.org/jira/browse/MTOMCAT-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280018#comment-13280018 ] Hudson commented on MTOMCAT-154: Integrated in TomcatMavenPlugin-mvn3.x #150 (See [https://builds.apache.org/job/TomcatMavenPlugin-mvn3.x/150/]) [MTOMCAT-154] support exec-war war run dependencies with classifiers Submitted by Peter Lynch. (Revision 1340918) Result = SUCCESS olamy : http://svn.apache.org/viewvc/?view=rev&rev=1340918 Files : * /tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java > support exec-war war run dependencies with classifiers > -- > > Key: MTOMCAT-154 > URL: https://issues.apache.org/jira/browse/MTOMCAT-154 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement > Components: tomcat7 >Reporter: Peter lynch >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 2.0 > > Attachments: support-warRunDependency-classifier.patch > > > Specifying war run dependency with a classifier is not resolved. > Current code does not specify the classifier when resolving the war run > dependency artifact. Attached patch supports resolving wars with classifiers. -- 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: r1340932 - /tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java
Author: olamy
Date: Mon May 21 08:36:51 2012
New Revision: 1340932
URL: http://svn.apache.org/viewvc?rev=1340932&view=rev
Log:
[MTOMCAT-156] exec-war should allow creation of exec-war in projects with any
packaging type
Submitted by Peter Lynch.
Modified:
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java
Modified:
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java?rev=1340932&r1=1340931&r2=1340932&view=diff
==
---
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java
(original)
+++
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java
Mon May 21 08:36:51 2012
@@ -311,9 +311,7 @@ public abstract class AbstractExecWarMoj
properties.put( Tomcat7Runner.WARS_KEY,
StringUtils.removeStart( path, "/" ) + ".war|" + path );
}
-
-if ( "pom".equals( project.getPackaging() ) && (
warRunDependencies != null
-&& !warRunDependencies.isEmpty() ) )
+else if ( warRunDependencies != null &&
!warRunDependencies.isEmpty() )
{
for ( WarRunDependency warRunDependency : warRunDependencies )
{
@@ -353,8 +351,6 @@ public abstract class AbstractExecWarMoj
}
}
-// FIXME if no war has been added here we must stop with a human
readable and user friendly error message
-
if ( serverXml != null && serverXml.exists() )
{
os.putArchiveEntry( new JarArchiveEntry( "conf/server.xml" ) );
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Closed] (MTOMCAT-156) exec-war should allow creation of exec-war in projects with any packaging type
[ https://issues.apache.org/jira/browse/MTOMCAT-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-156. -- Resolution: Fixed Fix Version/s: 2.0 fixed. Thanks! > exec-war should allow creation of exec-war in projects with any packaging type > -- > > Key: MTOMCAT-156 > URL: https://issues.apache.org/jira/browse/MTOMCAT-156 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement > Components: tomcat7 >Affects Versions: 2.0 >Reporter: Peter lynch >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 2.0 > > Attachments: exec-war-any-packaging.patch > > > Currently exec-wars in tomcat7 can only be created in projects with packaging > 'pom' or 'war'. > There are scenarios where one could want to use another packaging type and > still create an exec-war. This restriction should be removed. > Attached patch removes this restriction. -- 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-156) exec-war should allow creation of exec-war in projects with any packaging type
[ https://issues.apache.org/jira/browse/MTOMCAT-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280040#comment-13280040 ] Hudson commented on MTOMCAT-156: Integrated in TomcatMavenPlugin-mvn3.x #151 (See [https://builds.apache.org/job/TomcatMavenPlugin-mvn3.x/151/]) [MTOMCAT-156] exec-war should allow creation of exec-war in projects with any packaging type Submitted by Peter Lynch. (Revision 1340932) Result = FAILURE olamy : http://svn.apache.org/viewvc/?view=rev&rev=1340932 Files : * /tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java > exec-war should allow creation of exec-war in projects with any packaging type > -- > > Key: MTOMCAT-156 > URL: https://issues.apache.org/jira/browse/MTOMCAT-156 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement > Components: tomcat7 >Affects Versions: 2.0 >Reporter: Peter lynch >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 2.0 > > Attachments: exec-war-any-packaging.patch > > > Currently exec-wars in tomcat7 can only be created in projects with packaging > 'pom' or 'war'. > There are scenarios where one could want to use another packaging type and > still create an exec-war. This restriction should be removed. > Attached patch removes this restriction. -- 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: r1340935 - /tomcat/jk/trunk/native/common/jk_status.c
Author: mturk
Date: Mon May 21 08:48:59 2012
New Revision: 1340935
URL: http://svn.apache.org/viewvc?rev=1340935&view=rev
Log:
Ensure force update
Modified:
tomcat/jk/trunk/native/common/jk_status.c
Modified: tomcat/jk/trunk/native/common/jk_status.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_status.c?rev=1340935&r1=1340934&r2=1340935&view=diff
==
--- tomcat/jk/trunk/native/common/jk_status.c (original)
+++ tomcat/jk/trunk/native/common/jk_status.c Mon May 21 08:48:59 2012
@@ -4162,8 +4162,8 @@ static int update_worker(jk_ws_service_t
aw->addr_sequence++;
}
if (rv & (JK_STATUS_NEEDS_PUSH | JK_STATUS_NEEDS_ADDR_PUSH)) {
-wr->sequence = 0;
-lb->sequence = 0;
+wr->sequence = -1;
+lb->sequence = -1;
jk_lb_push(lb, JK_TRUE, l);
}
if (rv & JK_STATUS_NEEDS_RESET_LB_VALUES)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1340942 - /tomcat/jk/trunk/native/common/jk_status.c
Author: mturk
Date: Mon May 21 09:15:54 2012
New Revision: 1340942
URL: http://svn.apache.org/viewvc?rev=1340942&view=rev
Log:
Ensure force update
Modified:
tomcat/jk/trunk/native/common/jk_status.c
Modified: tomcat/jk/trunk/native/common/jk_status.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_status.c?rev=1340942&r1=1340941&r2=1340942&view=diff
==
--- tomcat/jk/trunk/native/common/jk_status.c (original)
+++ tomcat/jk/trunk/native/common/jk_status.c Mon May 21 09:15:54 2012
@@ -3188,7 +3188,7 @@ static void commit_worker(jk_ws_service_
}
}
if (sync_needed == JK_TRUE) {
-lb->sequence = 0;
+lb->sequence = -1;
jk_lb_push(lb, JK_TRUE, l);
}
}
@@ -3658,7 +3658,7 @@ static void commit_all_members(jk_ws_ser
/* Recalculate the load multiplicators wrt. lb_factor */
update_mult(lb, l);
if (rc) {
-lb->sequence = 0;
+lb->sequence = -1;
jk_lb_push(lb, JK_TRUE, l);
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Updated] (MTOMCAT-155) allow exec-war war run dependencies that are generated in current mvn execution, but not yet installed to maven repo
[ https://issues.apache.org/jira/browse/MTOMCAT-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter lynch updated MTOMCAT-155: Summary: allow exec-war war run dependencies that are generated in current mvn execution, but not yet installed to maven repo (was: allow exec-war war run dependencies that are generated in current mvn execuion, but not yet installed to maven repo) > allow exec-war war run dependencies that are generated in current mvn > execution, but not yet installed to maven repo > > > Key: MTOMCAT-155 > URL: https://issues.apache.org/jira/browse/MTOMCAT-155 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Peter lynch > Attachments: warRunDependency-in-current-execution.patch > > > If a war run dependency ( used in exec-war) was generated as part of current > mvn execution maven module as executing tomcat plugin, then artifact file > will be in target dir and not yet installed into maven repo yet ( since > install phase has not been run) - so copy from ./target to > ./target/(pluginWorkDirectory) to allow modifying war run dependency to avoid > potential attempt of current code to overrite existing target dir exec-war. > See attached patch file fo fix. -- 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
native connector tool chain
I am trying to build the 1.1.x native connector from trunk so I can test the changes I plan to make to support per socket time outs. I can build using dynamic linking but not statically. What tool chain are folks currently using to build the native connector binaries we currently ship? My current issue relates to statically linking to OpenSSL. I get the same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html - Targeting 64-bit platform I am working through the VS6 GUI and the errors I am getting are variations of this: ssleay32MT.lib(t1_enc.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Porting native fixes from trunk to 1.1.x
Just a quick check before I hit commit. Am I correct in thinking that r1296944 [1] should be back-ported to 1.1.x? Cheers, Mark [1] http://svn.apache.org/viewvc?view=revision&revision=1296944 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1340215 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
- Mensaje original -
> De: "Rainer Jung"
}
>
> Was that intentional? I'd say the timestamp should be provided by the
> log framework and not by java.sql.Date. But maybe the whole message
> is
> just a leftover from debugging the issue.
>
> The same for the TC 7 backport.
>
hi Rainer, no, not intentional, it is left over from debugging. I will remove
the Date object
Filip
> > try {
> > unreg(sk, attachment, sk.readyOps());
> > SendfileData sd = attachment.getSendfileData();
> > +//setup the file channel
> > if ( sd.fchannel == null ) {
> > File f = new File(sd.fileName);
> > if ( !f.exists() ) {
>
> ...
>
> Regards,
>
> Rainer
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Porting native fixes from trunk to 1.1.x
On 21/05/2012 13:25, Mark Thomas wrote: > Just a quick check before I hit commit. Am I correct in thinking that > r1296944 [1] should be back-ported to 1.1.x? Ignore me. I now realise I am wrong since interrupt() isn't implemented in the 1.1.x branch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: APR/native and per socket timeouts.
On 20/05/2012 21:47, Mladen Turk wrote: > On 05/20/2012 08:37 PM, Mark Thomas wrote: >> Therefore, I intend modifying the APR/native code to support per socket >> time outs. I would be grateful if those of you with more C knowledge >> than I (which is most people on this list) could: >> a) tell me now if this is a crazy idea (and why) >> b) keep an extra close eye on any commit of mine that touches the C code. >> > > This should be easy to implement. > Inside native we track socket_ttl for each socket. > Currently when socket is added it's set to apr_time_now() > and later compared with max_ttl (usually keepAliveTimeout). > > We can add new API that would add socket with timeout relative > to max_ttl. A bit awkward but wouldn't create backward incompatibility. > > Take a look at poll.c add function. > The new addt would have additional timeout parameter and > you would set: > ... > if (p->max_ttl > 0) > p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout); > ... > > Now that new timeout param would actually be called as > Poll.add(pollset, socket, events, perSocketPollTimeout - keepAliveTimeout); > given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout); > > So effectively socket_ttl would become 'now() - ttlOffset' Thanks for confirming I am heading in the right direction with this. I'm hesitant to follow exactly the path above. While it is a minimal change from the current code, I think it could be difficult for folks new to the code to figure out what is going on. I'd like to see if I can come up with a change that will be more obvious on first reading. I expect it will be a little more invasive than the change you suggested. Depending on my level of confidence, I'll either post a patch or commit the change when I have something concrete. Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-155) allow exec-war war run dependencies that are generated in current mvn execution, but not yet installed to maven repo
[ https://issues.apache.org/jira/browse/MTOMCAT-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280146#comment-13280146 ] Olivier Lamy (*$^¨%`£) commented on MTOMCAT-155: I miss you here. You are not using mvn install ? > allow exec-war war run dependencies that are generated in current mvn > execution, but not yet installed to maven repo > > > Key: MTOMCAT-155 > URL: https://issues.apache.org/jira/browse/MTOMCAT-155 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Peter lynch > Attachments: warRunDependency-in-current-execution.patch > > > If a war run dependency ( used in exec-war) was generated as part of current > mvn execution maven module as executing tomcat plugin, then artifact file > will be in target dir and not yet installed into maven repo yet ( since > install phase has not been run) - so copy from ./target to > ./target/(pluginWorkDirectory) to allow modifying war run dependency to avoid > potential attempt of current code to overrite existing target dir exec-war. > See attached patch file fo fix. -- 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
Re: APR/native and per socket timeouts.
My understanding is that the timeout is implemented in poll.c maintain() - by scanning the socket list in C. Why not doing the same thing in java - i.e. don't touch native code, have all sockets 'long', and close whenever you need from java ? Costin On Mon, May 21, 2012 at 5:55 AM, Mark Thomas wrote: > On 20/05/2012 21:47, Mladen Turk wrote: > > On 05/20/2012 08:37 PM, Mark Thomas wrote: > >> Therefore, I intend modifying the APR/native code to support per socket > >> time outs. I would be grateful if those of you with more C knowledge > >> than I (which is most people on this list) could: > >> a) tell me now if this is a crazy idea (and why) > >> b) keep an extra close eye on any commit of mine that touches the C > code. > >> > > > > This should be easy to implement. > > Inside native we track socket_ttl for each socket. > > Currently when socket is added it's set to apr_time_now() > > and later compared with max_ttl (usually keepAliveTimeout). > > > > We can add new API that would add socket with timeout relative > > to max_ttl. A bit awkward but wouldn't create backward incompatibility. > > > > Take a look at poll.c add function. > > The new addt would have additional timeout parameter and > > you would set: > > ... > > if (p->max_ttl > 0) > > p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout); > > ... > > > > Now that new timeout param would actually be called as > > Poll.add(pollset, socket, events, perSocketPollTimeout - > keepAliveTimeout); > > given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout); > > > > So effectively socket_ttl would become 'now() - ttlOffset' > > Thanks for confirming I am heading in the right direction with this. I'm > hesitant to follow exactly the path above. While it is a minimal change > from the current code, I think it could be difficult for folks new to > the code to figure out what is going on. > > I'd like to see if I can come up with a change that will be more obvious > on first reading. I expect it will be a little more invasive than the > change you suggested. Depending on my level of confidence, I'll either > post a patch or commit the change when I have something concrete. > > Cheers, > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Porting native fixes from trunk to 1.1.x
Any plan to do a release out of trunk (1.2 ) ? interrupt() and the others seem useful. Costin On Mon, May 21, 2012 at 5:41 AM, Mark Thomas wrote: > On 21/05/2012 13:25, Mark Thomas wrote: > > Just a quick check before I hit commit. Am I correct in thinking that > > r1296944 [1] should be back-ported to 1.1.x? > > Ignore me. I now realise I am wrong since interrupt() isn't implemented > in the 1.1.x branch. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[jira] [Commented] (MTOMCAT-155) allow exec-war war run dependencies that are generated in current mvn execution, but not yet installed to maven repo
[
https://issues.apache.org/jira/browse/MTOMCAT-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280182#comment-13280182
]
Peter lynch commented on MTOMCAT-155:
-
Suppose the Maven project both creates the non exec war (A), to be included as
a warRunDependency in exec-war-only goal and also the exec-war war (B) which
will use (A) in the same Maven execution. Since (A) and (B) creation happens
in package phase, before install phase, artifact.getFile() of warRunDependency
resolves to ./target/A.war instead of somewhere in{{ ~/.m2/repository}}. Old
code tried to copy from ./target/mywar.war to ./target/mywar.war in this case
before modifying the warRunDependency and failed because file already existed.
> allow exec-war war run dependencies that are generated in current mvn
> execution, but not yet installed to maven repo
>
>
> Key: MTOMCAT-155
> URL: https://issues.apache.org/jira/browse/MTOMCAT-155
> Project: Apache Tomcat Maven Plugin
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Peter lynch
> Attachments: warRunDependency-in-current-execution.patch
>
>
> If a war run dependency ( used in exec-war) was generated as part of current
> mvn execution maven module as executing tomcat plugin, then artifact file
> will be in target dir and not yet installed into maven repo yet ( since
> install phase has not been run) - so copy from ./target to
> ./target/(pluginWorkDirectory) to allow modifying war run dependency to avoid
> potential attempt of current code to overrite existing target dir exec-war.
> See attached patch file fo fix.
--
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
Re: native connector tool chain
Sorry, haven't compiled on windows in last >10 years. I suspect the easiest path would be cygwin and gcc. If you want to use vcc - you need to find a way to generate the project file with the right flags. One option would be to use the CMakeLists.txt - you'll probably need to adjust the options and file list for windows. It can generate native projects for both visual studio and eclipse. The file is still there in main branch, the official solution is autoconf, but sometimes it's good to consider alternatives too. Costin On Mon, May 21, 2012 at 5:05 AM, Mark Thomas wrote: > I am trying to build the 1.1.x native connector from trunk so I can test > the changes I plan to make to support per socket time outs. I can build > using dynamic linking but not statically. What tool chain are folks > currently using to build the native connector binaries we currently ship? > > My current issue relates to statically linking to OpenSSL. I get the > same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: > - Visual Studio 6 + SP6 > - Win 2003 r2 Platform SDK > - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html > - Targeting 64-bit platform > > I am working through the VS6 GUI and the errors I am getting are > variations of this: > ssleay32MT.lib(t1_enc.obj) : error LNK2001: unresolved external symbol > __GSHandlerCheck > > Cheers, > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[jira] [Comment Edited] (MTOMCAT-155) allow exec-war war run dependencies that are generated in current mvn execution, but not yet installed to maven repo
[
https://issues.apache.org/jira/browse/MTOMCAT-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280182#comment-13280182
]
Peter lynch edited comment on MTOMCAT-155 at 5/21/12 2:35 PM:
--
Suppose the Maven project both creates the non exec war (A), to be included as
a warRunDependency in exec-war-only goal and also the exec-war war (B) which
will use (A) in the same Maven execution. Since (A) and (B) creation happens
in package phase, before install phase, artifact.getFile() of warRunDependency
resolves to {{./target/A.war}} instead of somewhere in {{ ~/.m2/repository}}.
Old code tried to copy from {{./target/A.war to {{./target/A.war}} in this case
before modifying the warRunDependency and failed because file already existed.
was (Author: peterlynch):
Suppose the Maven project both creates the non exec war (A), to be included
as a warRunDependency in exec-war-only goal and also the exec-war war (B) which
will use (A) in the same Maven execution. Since (A) and (B) creation happens
in package phase, before install phase, artifact.getFile() of warRunDependency
resolves to ./target/A.war instead of somewhere in{{ ~/.m2/repository}}. Old
code tried to copy from ./target/mywar.war to ./target/mywar.war in this case
before modifying the warRunDependency and failed because file already existed.
> allow exec-war war run dependencies that are generated in current mvn
> execution, but not yet installed to maven repo
>
>
> Key: MTOMCAT-155
> URL: https://issues.apache.org/jira/browse/MTOMCAT-155
> Project: Apache Tomcat Maven Plugin
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Peter lynch
> Attachments: warRunDependency-in-current-execution.patch
>
>
> If a war run dependency ( used in exec-war) was generated as part of current
> mvn execution maven module as executing tomcat plugin, then artifact file
> will be in target dir and not yet installed into maven repo yet ( since
> install phase has not been run) - so copy from ./target to
> ./target/(pluginWorkDirectory) to allow modifying war run dependency to avoid
> potential attempt of current code to overrite existing target dir exec-war.
> See attached patch file fo fix.
--
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
Re: APR/native and per socket timeouts.
On 05/21/2012 02:55 PM, Mark Thomas wrote: On 20/05/2012 21:47, Mladen Turk wrote: On 05/20/2012 08:37 PM, Mark Thomas wrote: Therefore, I intend modifying the APR/native code to support per socket time outs. I would be grateful if those of you with more C knowledge than I (which is most people on this list) could: a) tell me now if this is a crazy idea (and why) b) keep an extra close eye on any commit of mine that touches the C code. This should be easy to implement. Inside native we track socket_ttl for each socket. Currently when socket is added it's set to apr_time_now() and later compared with max_ttl (usually keepAliveTimeout). We can add new API that would add socket with timeout relative to max_ttl. A bit awkward but wouldn't create backward incompatibility. Take a look at poll.c add function. The new addt would have additional timeout parameter and you would set: ... if (p->max_ttl> 0) p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout); ... Now that new timeout param would actually be called as Poll.add(pollset, socket, events, perSocketPollTimeout - keepAliveTimeout); given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout); So effectively socket_ttl would become 'now() - ttlOffset' Thanks for confirming I am heading in the right direction with this. I'm hesitant to follow exactly the path above. While it is a minimal change from the current code, I think it could be difficult for folks new to the code to figure out what is going on. The easier solution would be to use the math inside native by providing a desired perSocketTimeout and internally substracting from pollset's ttl. In that case pollset's ttl can be almost anything (well as long it's not zero which means disabled) Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Comment Edited] (MTOMCAT-155) allow exec-war war run dependencies that are generated in current mvn execution, but not yet installed to maven repo
[
https://issues.apache.org/jira/browse/MTOMCAT-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280182#comment-13280182
]
Peter lynch edited comment on MTOMCAT-155 at 5/21/12 2:37 PM:
--
Suppose the Maven project both creates the non exec war (A), to be included as
a warRunDependency in exec-war-only goal and also the exec-war war (B) which
will use (A) in the same Maven execution. Since (A) and (B) creation happens
in package phase, before install phase, artifact.getFile() of warRunDependency
resolves to ./target/A.war instead of somewhere in ~/.m2/repository. Old code
tried to copy from ./target/A.war to ./target/A.war in this case before
modifying the warRunDependency and failed because file already existed.
was (Author: peterlynch):
Suppose the Maven project both creates the non exec war (A), to be included
as a warRunDependency in exec-war-only goal and also the exec-war war (B) which
will use (A) in the same Maven execution. Since (A) and (B) creation happens
in package phase, before install phase, artifact.getFile() of warRunDependency
resolves to {{./target/A.war}} instead of somewhere in {{ ~/.m2/repository}}.
Old code tried to copy from {{./target/A.war to {{./target/A.war}} in this case
before modifying the warRunDependency and failed because file already existed.
> allow exec-war war run dependencies that are generated in current mvn
> execution, but not yet installed to maven repo
>
>
> Key: MTOMCAT-155
> URL: https://issues.apache.org/jira/browse/MTOMCAT-155
> Project: Apache Tomcat Maven Plugin
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Peter lynch
> Attachments: warRunDependency-in-current-execution.patch
>
>
> If a war run dependency ( used in exec-war) was generated as part of current
> mvn execution maven module as executing tomcat plugin, then artifact file
> will be in target dir and not yet installed into maven repo yet ( since
> install phase has not been run) - so copy from ./target to
> ./target/(pluginWorkDirectory) to allow modifying war run dependency to avoid
> potential attempt of current code to overrite existing target dir exec-war.
> See attached patch file fo fix.
--
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 53267] New: The JreMemoryLeakPreventionListener causes a full GC every hour when gcDaemonProtection=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=53267 Priority: P2 Bug ID: 53267 Assignee: dev@tomcat.apache.org Summary: The JreMemoryLeakPreventionListener causes a full GC every hour when gcDaemonProtection=true Severity: enhancement Classification: Unclassified OS: All Reporter: bugzi...@pidster.com Hardware: All Status: NEW Version: trunk Component: Catalina Product: Tomcat 7 Created attachment 28809 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28809&action=edit Increases timeout on sun.misc.GC.requestLatency in JreMemoryLeakPreventionListener The JreMemoryLeakPreventionListener causes a full GC every hour when gcDaemonProtection=true. The prevention technique invokes sun.misc.GC.requestLatency with a value of 36. Increasing the value to Long.MAX_VALUE would be beneficial. The attached patches add a default setting of Long.MAX_VALUE (add documentation update), but also permit it to be configured to a lower value using a System property. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53267] The JreMemoryLeakPreventionListener causes a full GC every hour when gcDaemonProtection=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=53267 --- Comment #1 from Pid --- Created attachment 28810 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28810&action=edit Docs patch for JreMemoryLeakPreventionListener. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 44454] busy count reported in mod_jk inflated, causes incorrect balancing
https://issues.apache.org/bugzilla/show_bug.cgi?id=44454 --- Comment #27 from Paul Martin --- For anyone having this issue, you should know that mod_proxy can essentially be used as a functional replacement to mod_jk. While mod_proxy is theoretically less efficient than mod_jk, we found that the overhead added was minimal and of essentially no consequence as the apache-tomcat bridge was far from being the bottleneck. I had worked around this issue by moving to mod_proxy - if this avenue is available to you, it is worth exploring. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53267] The JreMemoryLeakPreventionListener causes a full GC every hour when gcDaemonProtection=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=53267 Leon Rosenberg changed: What|Removed |Added CC||rosenberg.l...@gmail.com -- You are receiving this mail because: You are the assignee for the bug.
tomcat & deploywar & context.xml
Hi, how does tomcat manage context.xml at startup? from what i saw it uses org.apache.catalina.startup.HostConfig.DeployWar but in org.apache.catalina.startup.HostConfig#deployWAR it reads the context.xml file before overriding it with contextname info which ignores the context.xml file: context.setName(cn.getName()); context.setPath(cn.getPath()); context.setWebappVersion(cn.getVersion()); context.setDocBase(cn.getBaseName() + ".war"); did i miss sthg or is it a bug? - Romain
Re: APR/native and per socket timeouts.
On 21/05/2012 15:26, Costin Manolache wrote: > My understanding is that the timeout is implemented in poll.c maintain() - > by scanning the socket list in C. > > Why not doing the same thing in java - i.e. don't touch native code, have > all sockets 'long', and close whenever you need from java ? The timeout is also used in poll so it wouldn't be a completely clean solution. It would probably work but there might be some odd edge cases. It think it is probably better - for now - to keep this in native. Mark > > Costin > > On Mon, May 21, 2012 at 5:55 AM, Mark Thomas wrote: > >> On 20/05/2012 21:47, Mladen Turk wrote: >>> On 05/20/2012 08:37 PM, Mark Thomas wrote: Therefore, I intend modifying the APR/native code to support per socket time outs. I would be grateful if those of you with more C knowledge than I (which is most people on this list) could: a) tell me now if this is a crazy idea (and why) b) keep an extra close eye on any commit of mine that touches the C >> code. >>> >>> This should be easy to implement. >>> Inside native we track socket_ttl for each socket. >>> Currently when socket is added it's set to apr_time_now() >>> and later compared with max_ttl (usually keepAliveTimeout). >>> >>> We can add new API that would add socket with timeout relative >>> to max_ttl. A bit awkward but wouldn't create backward incompatibility. >>> >>> Take a look at poll.c add function. >>> The new addt would have additional timeout parameter and >>> you would set: >>> ... >>> if (p->max_ttl > 0) >>> p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout); >>> ... >>> >>> Now that new timeout param would actually be called as >>> Poll.add(pollset, socket, events, perSocketPollTimeout - >> keepAliveTimeout); >>> given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout); >>> >>> So effectively socket_ttl would become 'now() - ttlOffset' >> >> Thanks for confirming I am heading in the right direction with this. I'm >> hesitant to follow exactly the path above. While it is a minimal change >> from the current code, I think it could be difficult for folks new to >> the code to figure out what is going on. >> >> I'd like to see if I can come up with a change that will be more obvious >> on first reading. I expect it will be a little more invasive than the >> change you suggested. Depending on my level of confidence, I'll either >> post a patch or commit the change when I have something concrete. >> >> Cheers, >> >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: native connector tool chain
On 21/05/2012 15:35, Costin Manolache wrote: > Sorry, haven't compiled on windows in last >10 years. > I suspect the easiest path would be cygwin and gcc. > > If you want to use vcc - you need to find a way to generate the project > file with the right flags. One option would be to use the CMakeLists.txt - > you'll probably need to adjust the options and file list for windows. It > can generate native projects for both visual studio and eclipse. The file > is still there in main branch, the official solution is autoconf, but > sometimes it's good to consider alternatives too. I have Visual studio working for 95% of the build. As long as I link OpenSSL dynamically, all is fine. It is just the static linking I am having trouble with. This is good enough for what I need right now but I'd like to be able to repeat the binary build process if only as protection against the current release manager being run over by a bus. Mark > > Costin > > On Mon, May 21, 2012 at 5:05 AM, Mark Thomas wrote: > >> I am trying to build the 1.1.x native connector from trunk so I can test >> the changes I plan to make to support per socket time outs. I can build >> using dynamic linking but not statically. What tool chain are folks >> currently using to build the native connector binaries we currently ship? >> >> My current issue relates to statically linking to OpenSSL. I get the >> same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: >> - Visual Studio 6 + SP6 >> - Win 2003 r2 Platform SDK >> - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html >> - Targeting 64-bit platform >> >> I am working through the VS6 GUI and the errors I am getting are >> variations of this: >> ssleay32MT.lib(t1_enc.obj) : error LNK2001: unresolved external symbol >> __GSHandlerCheck >> >> Cheers, >> >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: native connector tool chain
On 05/21/2012 02:05 PM, Mark Thomas wrote: I am trying to build the 1.1.x native connector from trunk so I can test the changes I plan to make to support per socket time outs. I can build using dynamic linking but not statically. What tool chain are folks currently using to build the native connector binaries we currently ship? My current issue relates to statically linking to OpenSSL. I get the same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html If those binaries were not compiled with VS6 you can't statically link them. When I build binaries I build both of those (and apr) with the same compiler. Yeah, it's not trivial task. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-tc7.0.x-test (in module tomcat-7.0.x) 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-tc7.0.x-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-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-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-tc7.0.x-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-tc7.0.x-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-7.0.x/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test (Type: Build) Work ended in a state of : Failed Elapsed: 22 mins 23 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-21052012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-21052012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-21052012-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-7.0.x/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-21052012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/ srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-21052012.jar test [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-7.0.x/output/testclasses:/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:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/outp ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-util.jar:/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-21052012.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-21052012.jar:/srv/gump/ public/workspace/junit/dist/junit-21052012.jar - [junit] May 21, 2012 4:53:19 PM org.apache.catalina.startup.Conte
Re: native connector tool chain
On 21/05/2012 17:52, Mladen Turk wrote: > On 05/21/2012 02:05 PM, Mark Thomas wrote: >> I am trying to build the 1.1.x native connector from trunk so I can test >> the changes I plan to make to support per socket time outs. I can build >> using dynamic linking but not statically. What tool chain are folks >> currently using to build the native connector binaries we currently ship? >> >> My current issue relates to statically linking to OpenSSL. I get the >> same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: >> - Visual Studio 6 + SP6 >> - Win 2003 r2 Platform SDK >> - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html > > If those binaries were not compiled with VS6 you can't statically link > them. When I build binaries I build both of those (and apr) with the > same compiler. > > Yeah, it's not trivial task. :). Thanks. That explains what is going on. I might look into building OpenSSL with Visual Studio 6 if I get a spare week and a desire to make my brain hurt :) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: APR/native and per socket timeouts.
On Mon, May 21, 2012 at 9:29 AM, Mark Thomas wrote: > On 21/05/2012 15:26, Costin Manolache wrote: > > My understanding is that the timeout is implemented in poll.c maintain() > - > > by scanning the socket list in C. > > > > Why not doing the same thing in java - i.e. don't touch native code, have > > all sockets 'long', and close whenever you need from java ? > > The timeout is also used in poll so it wouldn't be a completely clean > solution. How is it used in poll ? The poll can be arbitrary - there is no need to guarantee that sockets timeout at the exact moment, it can happen later. If poll time is 1/2 hour - than if no event happens you'll check every 1/2 hour which sockets are expired. The benefit of doing it in java is that you have more control - and may use more advanced structures ( C is just a loop over the list of sockets, wouldn't scale very well to 100K+ sockets - which are probably normal case for websocket ). Costin > It would probably work but there might be some odd edge cases. > It think it is probably better - for now - to keep this in native. > > > Mark > > > > > > Costin > > > > On Mon, May 21, 2012 at 5:55 AM, Mark Thomas wrote: > > > >> On 20/05/2012 21:47, Mladen Turk wrote: > >>> On 05/20/2012 08:37 PM, Mark Thomas wrote: > Therefore, I intend modifying the APR/native code to support per > socket > time outs. I would be grateful if those of you with more C knowledge > than I (which is most people on this list) could: > a) tell me now if this is a crazy idea (and why) > b) keep an extra close eye on any commit of mine that touches the C > >> code. > > >>> > >>> This should be easy to implement. > >>> Inside native we track socket_ttl for each socket. > >>> Currently when socket is added it's set to apr_time_now() > >>> and later compared with max_ttl (usually keepAliveTimeout). > >>> > >>> We can add new API that would add socket with timeout relative > >>> to max_ttl. A bit awkward but wouldn't create backward incompatibility. > >>> > >>> Take a look at poll.c add function. > >>> The new addt would have additional timeout parameter and > >>> you would set: > >>> ... > >>> if (p->max_ttl > 0) > >>> p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout); > >>> ... > >>> > >>> Now that new timeout param would actually be called as > >>> Poll.add(pollset, socket, events, perSocketPollTimeout - > >> keepAliveTimeout); > >>> given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout); > >>> > >>> So effectively socket_ttl would become 'now() - ttlOffset' > >> > >> Thanks for confirming I am heading in the right direction with this. I'm > >> hesitant to follow exactly the path above. While it is a minimal change > >> from the current code, I think it could be difficult for folks new to > >> the code to figure out what is going on. > >> > >> I'd like to see if I can come up with a change that will be more obvious > >> on first reading. I expect it will be a little more invasive than the > >> change you suggested. Depending on my level of confidence, I'll either > >> post a patch or commit the change when I have something concrete. > >> > >> Cheers, > >> > >> Mark > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: native connector tool chain
On Mon, May 21, 2012 at 10:31 AM, Mark Thomas wrote: > On 21/05/2012 17:52, Mladen Turk wrote: > > On 05/21/2012 02:05 PM, Mark Thomas wrote: > >> I am trying to build the 1.1.x native connector from trunk so I can test > >> the changes I plan to make to support per socket time outs. I can build > >> using dynamic linking but not statically. What tool chain are folks > >> currently using to build the native connector binaries we currently > ship? > >> > >> My current issue relates to statically linking to OpenSSL. I get the > >> same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: > >> - Visual Studio 6 + SP6 > >> - Win 2003 r2 Platform SDK > >> - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html > > > > If those binaries were not compiled with VS6 you can't statically link > > them. When I build binaries I build both of those (and apr) with the > > same compiler. > > > > Yeah, it's not trivial task. > > :). Thanks. That explains what is going on. I might look into building > OpenSSL with Visual Studio 6 if I get a spare week and a desire to make > my brain hurt :) > I think chrome has some build files for openssl similar with cmake, i.e. one config that can generate visual studio, eclipse, makefile, etc. My brain hurts whenever I touch autoconfig, I suppose the pain with VS6 is similar. Costin > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: APR/native and per socket timeouts.
On 21/05/2012 18:30, Costin Manolache wrote: > On Mon, May 21, 2012 at 9:29 AM, Mark Thomas wrote: > >> On 21/05/2012 15:26, Costin Manolache wrote: >>> My understanding is that the timeout is implemented in poll.c maintain() >> - >>> by scanning the socket list in C. >>> >>> Why not doing the same thing in java - i.e. don't touch native code, have >>> all sockets 'long', and close whenever you need from java ? >> >> The timeout is also used in poll so it wouldn't be a completely clean >> solution. > > > How is it used in poll ? The poll can be arbitrary - there is no need to > guarantee that sockets timeout at the exact moment, it can happen later. > If poll time is 1/2 hour - than if no event happens you'll check every 1/2 > hour which sockets are expired. It is used to ensure that the poll does not last beyond the next expected time out. While I agree time out can happen later, the current API isn't written that way and I not happy changing something like that in a point release. > The benefit of doing it in java is that you have more control - and may use > more advanced structures ( C is just a loop over the list of sockets, > wouldn't scale very well to 100K+ sockets - which are probably normal case > for websocket ). In the WebSocket case, the time out will be in Java. I just need the ability to set it to infinite without creating yet another PollSet. While I currently think per socket timeout is the way to go (it will simplify the current APR/native Poller code) I'm not wedded to the idea. If this doesn't work, I'm happy to look at alternatives. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: APR/native and per socket timeouts.
On Mon, May 21, 2012 at 10:48 AM, Mark Thomas wrote: > On 21/05/2012 18:30, Costin Manolache wrote: > > On Mon, May 21, 2012 at 9:29 AM, Mark Thomas wrote: > > > >> On 21/05/2012 15:26, Costin Manolache wrote: > >>> My understanding is that the timeout is implemented in poll.c > maintain() > >> - > >>> by scanning the socket list in C. > >>> > >>> Why not doing the same thing in java - i.e. don't touch native code, > have > >>> all sockets 'long', and close whenever you need from java ? > >> > >> The timeout is also used in poll so it wouldn't be a completely clean > >> solution. > > > > > > How is it used in poll ? The poll can be arbitrary - there is no need to > > guarantee that sockets timeout at the exact moment, it can happen later. > > If poll time is 1/2 hour - than if no event happens you'll check every > 1/2 > > hour which sockets are expired. > > It is used to ensure that the poll does not last beyond the next > expected time out. While I agree time out can happen later, the current > API isn't written that way and I not happy changing something like that > in a point release. > My point was that you don't need to change anything in native. Leave APR as it is - just use '0' as timeout for the websocket sockets ( or any scoket that needs arbitrary timeout ). That will disable the processing in maintain - and java side can do the expiration. No compilation headaches - the only downside is that the actual expiration may happen a bit later. > > The benefit of doing it in java is that you have more control - and may > use > > more advanced structures ( C is just a loop over the list of sockets, > > wouldn't scale very well to 100K+ sockets - which are probably normal > case > > for websocket ). > > In the WebSocket case, the time out will be in Java. I just need the > ability to set it to infinite without creating yet another PollSet. > While I currently think per socket timeout is the way to go (it will > simplify the current APR/native Poller code) I'm not wedded to the idea. > If this doesn't work, I'm happy to look at alternatives. > What's the problem with creating another PollSet ? The spdy implementation does create one ( AprSocketContext ), doesn't seem so bad. BTW - given the use case for web sockets, i.e. very large number of mostly idle sockets, you may have to create multiple pollsets anyway, don't remember what are the limits on one pollset but you probably don't want to mix 100K idle websockets in the active http pollset. Costin > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: tomcat & deploywar & context.xml
2012/5/21 Romain Manni-Bucau : > Hi, > > how does tomcat manage context.xml at startup? > > from what i saw it uses org.apache.catalina.startup.HostConfig.DeployWar > but in org.apache.catalina.startup.HostConfig#deployWAR it reads the > context.xml file before overriding it with contextname info which ignores > the context.xml file: > > context.setName(cn.getName()); > context.setPath(cn.getPath()); > context.setWebappVersion(cn.getVersion()); > context.setDocBase(cn.getBaseName() + ".war"); > > > did i miss sthg or is it a bug? > 1. There are several context.xml files (App's context.xml, Host's "context.xml.default" file, common conf/context.xml). See Context in config. reference for details. 2. App's context.xml is read twice, with different configuration of Digester. When it is read by the second time, the name etc. are ignored. That relates with the following documented feature: You cannot specify path attribute on Context in app's own context.xml, because it is already known a-priori from the name and location of the context file itself. The name and version are calculated from path. The same with docBase. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat & deploywar & context.xml
ok thank you for the quick answer sorry to have missed it on the website - Romain 2012/5/21 Konstantin Kolinko > 2012/5/21 Romain Manni-Bucau : > > Hi, > > > > how does tomcat manage context.xml at startup? > > > > from what i saw it uses org.apache.catalina.startup.HostConfig.DeployWar > > but in org.apache.catalina.startup.HostConfig#deployWAR it reads the > > context.xml file before overriding it with contextname info which ignores > > the context.xml file: > > > >context.setName(cn.getName()); > >context.setPath(cn.getPath()); > >context.setWebappVersion(cn.getVersion()); > >context.setDocBase(cn.getBaseName() + ".war"); > > > > > > did i miss sthg or is it a bug? > > > > 1. There are several context.xml files (App's context.xml, Host's > "context.xml.default" file, common conf/context.xml). See Context in > config. reference for details. > > 2. App's context.xml is read twice, with different configuration of > Digester. > > When it is read by the second time, the name etc. are ignored. > > That relates with the following documented feature: You cannot specify > path attribute on Context in app's own context.xml, because it is > already known a-priori from the name and location of the context file > itself. > > The name and version are calculated from path. > > The same with docBase. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: APR/native and per socket timeouts.
On 05/21/2012 08:01 PM, Costin Manolache wrote: On Mon, May 21, 2012 at 10:48 AM, Mark Thomas wrote: My point was that you don't need to change anything in native. Leave APR as it is - just use '0' as timeout for the websocket sockets ( or any scoket that needs arbitrary timeout ). That will disable the processing in maintain - and java side can do the expiration. No compilation headaches - the only downside is that the actual expiration may happen a bit later. This approach would be bad for performance. The reason why I put the maintenance inside native is to lower down the number of JNI calls. If you do it in java for each socket, then you will have to inform the poller to remove each expired from the native pollset. This mean N*sockets extra JNI calls. If you look at the implementation I return array of all expired sockets at once, meaning 1 JNI call. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: APR/native and per socket timeouts.
On Mon, May 21, 2012 at 12:16 PM, Mladen Turk wrote: > On 05/21/2012 08:01 PM, Costin Manolache wrote: > >> On Mon, May 21, 2012 at 10:48 AM, Mark Thomas wrote: >> >> >> My point was that you don't need to change anything in native. >> >> Leave APR as it is - just use '0' as timeout for the websocket sockets ( >> or >> any scoket that needs arbitrary timeout ). That will disable the >> processing >> in maintain - and java side can do the expiration. >> >> No compilation headaches - the only downside is that the actual expiration >> may happen a bit later. >> >> > This approach would be bad for performance. > The reason why I put the maintenance inside native is to > lower down the number of JNI calls. > > If you do it in java for each socket, then you will have to > inform the poller to remove each expired from the native pollset. > This mean N*sockets extra JNI calls. > > If you look at the implementation I return array of all expired sockets > at once, meaning 1 JNI call. > You could send an array of sockets to close and get the same 1 JNI call if performance is the main reason. My point is that you can implement per-socket timeout with no native code changes. If you are to make native code changes - bulk close seems a simple change. Costin > > > Regards > -- > ^TM > > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@tomcat.apache.**org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: native connector tool chain
On 21/05/2012 17:52, Mladen Turk wrote: > On 05/21/2012 02:05 PM, Mark Thomas wrote: >> I am trying to build the 1.1.x native connector from trunk so I can test >> the changes I plan to make to support per socket time outs. I can build >> using dynamic linking but not statically. What tool chain are folks >> currently using to build the native connector binaries we currently ship? >> >> My current issue relates to statically linking to OpenSSL. I get the >> same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: >> - Visual Studio 6 + SP6 >> - Win 2003 r2 Platform SDK >> - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html > > If those binaries were not compiled with VS6 you can't statically link > them. When I build binaries I build both of those (and apr) with the > same compiler. > > Yeah, it's not trivial task. :) Got it working! For the benefit of the archives, I ended up using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL source bundle 0.9.x - APR 1.4.x src (I used the 1.4.6 tag) - native source (I used the 1.1.x branch) OpenSSL 1.x will not work with the VS6 tool chain. My aim is to build the 64-bit APR/native DLL. 32-bit should be pretty similar. Stage 1: OpenSSL build This is pretty close to the OpenSSL docs INSTALL.W64 - Set up the environment to build with the Platform SDK %PLATFORM_SDK_HOME%\SetEnv.Cmd /X64 /RETAIL - Follow the OpenSSL build instructions perl Configure VC-WIN64A ms\do_win64a nmake -f ms\nt.mak The *.lib files you'll need are in the out32 directory. Stage 2: Start VS6 in x64 mode You'll need a batch file that looks something like this: call "C:\Program Files\PlatformSDK\SetEnv.Cmd" /X64 /RETAIL start "" "C:\Program Files (x86)\Microsoft Visual Studio\Common\MSDev98\Bin\MSDEV.EXE" /useenv Stage 3: Open the workspace Depending on where APR is, you'll need to specify paths to the projects Stage 4: Build APR Make sure you can build the "apr x64" Release target You may need to tweak src and library paths. Stage 5: Create a tcnative x64 target Copy the Win32 release configuration and name it x64 Release Add /machine:AMD64 to the link options (you can't remove the I368 option - just make sure you add the new one after it) Tweak the src and library paths as required. For both stage 4 and 5 you may need to add additional standard libraries. Google the linking error you get to figure out which. HTH, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53266] ServletContainerInitializer will crash catalina if dependcy is not present.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53266 Christopher Schultz changed: What|Removed |Added OS||All --- Comment #1 from Christopher Schultz --- Would you expect anything else to happen? -- 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 53266] ServletContainerInitializer will crash catalina if dependcy is not present.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53266 Kevin Rose changed: What|Removed |Added Severity|minor |enhancement --- Comment #2 from Kevin Rose --- I would like to see tomcat gracefully shutdown with an error message prudent to the reason instead of an ArrayStoreException. As it is possible for any library to contain a ServlerContainerInitializer if for any reason a need dependency in any library is missing this is possible to occur. -- 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-tc7.0.x-test (in module tomcat-7.0.x) 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-tc7.0.x-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-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-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-tc7.0.x-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-tc7.0.x-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-7.0.x/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test (Type: Build) Work ended in a state of : Failed Elapsed: 22 mins 38 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-22052012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-22052012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-22052012-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-7.0.x/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-22052012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/ srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-22052012.jar test [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-7.0.x/output/testclasses:/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:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/outp ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-util.jar:/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-22052012.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-22052012.jar:/srv/gump/ public/workspace/junit/dist/junit-22052012.jar - [junit] at org.junit.runners.model.FrameworkMethod.invokeExp
[GUMP@vmgump]: Project tomcat-trunk-test (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-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 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-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: 23 mins 10 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-22052012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-22052012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-22052012-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-22052012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/ srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-22052012.jar test [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/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/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:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-trunk/outp ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-jni.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-util.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/packages/eclipse/plugins/org .eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-22052012.jar:/srv/gump/public/workspace
Re: Porting native fixes from trunk to 1.1.x
On 05/21/2012 04:28 PM, Costin Manolache wrote: Any plan to do a release out of trunk (1.2 ) ? interrupt() and the others seem useful. Yeah. plan to do this as soon as Mark finishes its pollset changes. Since apr 1.4.x was released for quite a while think we are safe. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
