date:20120312


On 03/12/2012 02:08 AM, Konstantin Preißer wrote:

Hello Tomcat developers,


Advantages:
- Easier to maintain. I have looked a bit at the ISAPI code, and as it is C++ 
code, it is probably somewhat hard to maintain. As I said, for this connector 
(in the current stage) I only spend one day to read the AJP documentation and 
to program the module, so it is probably very easy to write a AJP connector 
this way. :)
- Easier to install (you don't have to setup virtual directories etc).



I would rather see SPDY connector over AJP.
AJP has serious limitations, and recently we discussed using SPDY for
server-to-server communication.


Disadvantages:
-Probably worse Performance. Although I haven't done any performance tests (and 
when testing with a normal browser, I didn't notice any performance slowdown), 
such a managed connector probably has a bit worse performance compared to the 
ISAPI connector. (However, the current implementation also doesn't use an AJP 
Connection pool; and you would need to precompile the C# code to a .dll file 
for optimal performance).



Well, you have a very optimistic list here ;)
Think that the performance is of least concern.




Please let me know what you think about it. I won't be disappointed if you 
aren't interested in it or if there's no requirement for such a connector, but 
I'm happy for any feedback, and I would also be willing to give the code, 
licences etc. to the Apache software foundation, if that's possible.



Like said. Not sure if the AJP protocol is the right direction.
The current connector does the job and exploits the AJP protocol to its
maximum and I see no purpose for another AJP connector.

Sure install might be simpler, but only if you don't
count differences in .NET each IIS requires so hardly binary portable like
isapi_redirector which can basically run on any IIS for XP up.



Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat Connectors 1.2.33

2012-03-12 Thread Henri Gomez

I add to add --with-apxs=/usr/sbin/apxs to configure line :

CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386 -arch x86_64'
./configure --with-apr=/usr --with-ssl=/usr
--with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/A/
--with-apxs=/usr/sbin/apxs

Why did we need now apache apxs ?

2012/3/9 Mladen Turk :
> Release candidate artefacts [1] based on tag [2] are ready for vote.
> The vote will stay open for at least 72 hours.
>
> Apache Tomcat Connectors 1.2.33 release candidate is
>  [+1] Stable, release
>  [-1] Do not release because of ...
>
>
>  [1] https://svn.apache.org/repos/asf/tomcat/jk/tags/JK_1_2_33
>  [2] http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.33
>
>
> Regards
> --
> ^TM
>
> -
> 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

DO NOT REPLY [Bug 52722] An incomplete fix for the resource leak bug in HTMLManagerServlet.java

https://issues.apache.org/bugzilla/show_bug.cgi?id=52722

liangg...@sei.pku.edu.cn changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |

--- Comment #2 from liangg...@sei.pku.edu.cn 2012-03-12 08:11:28 UTC ---
The buggy method is "list()" at line 300 in the file
"/tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java"
(head revision 1226777)

please reconsider this resource leak. 

When the statements at lines 309-540 throw any eception, the objects
"writer"can not be closed as expected. 

You said that "The container
*always* closing the Stream/Writer regardless of whether the app does or not",
what is about your stated "container"? How to guaranteeing its normal
execution? what if any other caller invokes this method ?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 52722] An incomplete fix for the resource leak bug in HTMLManagerServlet.java

https://issues.apache.org/bugzilla/show_bug.cgi?id=52722

Mark Thomas  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID

--- Comment #3 from Mark Thomas  2012-03-12 08:37:22 UTC ---
My statements in comment 1 are correct. If you don't understand them, the users
list is the place to ask for an explanation, not Bugzilla.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat Connectors 1.2.33


On 03/12/2012 09:07 AM, Henri Gomez wrote:

I add to add --with-apxs=/usr/sbin/apxs to configure line :

CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386 -arch x86_64'
./configure --with-apr=/usr --with-ssl=/usr
--with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/A/
--with-apxs=/usr/sbin/apxs

Why did we need now apache apxs ?



We always did?


Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat Connectors 1.2.33


On 03/12/2012 09:07 AM, Henri Gomez wrote:

I add to add --with-apxs=/usr/sbin/apxs to configure line :

CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386 -arch x86_64'
./configure --with-apr=/usr --with-ssl=/usr
--with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/A/
--with-apxs=/usr/sbin/apxs

Why did we need now apache apxs ?



We always required apxs, probably be before you had /usr/sbin in PATH.

Also, --with-java-home is removed (been deprecated for a long time)
so this will cause configure to fail.

Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat Connectors 1.2.33


On 03/12/2012 10:18 AM, Mladen Turk wrote:

On 03/12/2012 09:07 AM, Henri Gomez wrote:

I add to add --with-apxs=/usr/sbin/apxs to configure line :

CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386 -arch x86_64'
./configure --with-apr=/usr --with-ssl=/usr
--with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/A/
--with-apxs=/usr/sbin/apxs

Why did we need now apache apxs ?



We always required apxs, probably be before you had /usr/sbin in PATH.


What I mean is
./configure --with-apxs(presumes apxs in PATH)
./configure --with-apxs=/path/to/apxs


Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat Connectors 1.2.33

2012-03-12 Thread Rainer Jung


On 09.03.2012 13:00, Mladen Turk wrote:

Release candidate artefacts [1] based on tag [2] are ready for vote.
The vote will stay open for at least 72 hours.

Apache Tomcat Connectors 1.2.33 release candidate is
[+1] Stable, release
[-1] Do not release because of ...


+1 as stable.

The only unexpected thing I noticed was a strange JK_REVISION, just 
"()". When I run the release script, the real svn revision is put into 
the variable. The value goes into the full exposed version. It was only 
introduced a few versions ago and the missing svn revision is not a real 
problem (as long as we don't reuse the tag).


I didn't yet have time to actually test the builds I did, but I did test 
some snapshots and I don't expect a last minute problem.


Details:

- Sigs and hashes OK
- key in KEYS file
- gz and zip for src identical
- src consistent with svn tag, except for the following minor points
  (no regression or fixed now)
  - LICENSE and NOTICE moved one directory up (OK)
  - KEYS not in dist (OK)
  - deprectated jk2 xdocs missing in dist (OK)
  - additional generated files in dist: aclocal.m4, configure,
Makefile.in, config.h.in, html docs in docs (OK)
  - additional auto tool copied files in dist: install-sh, ltmain.sh,
missing (OK)
  - HOWTO-RELEASE.tx, README.txt and CHANGES.txt (the antique changelog)
not in dist. I think we could include the first two files
and integrate the antique CHANGES.txt into changelog.xml to get rid
of it. No regression, not a real problem.
  - build.properties.autoconf, native/build.xml and the jkant directory
missing from dist. Not sure whether those still would do anything
useful. Not a regression.
  - build.properties.autoconf

Builds succesfully on

- Solaris 8 Sparc as 32 Bit Binaries against 1.3, 2.0, 2.2
- SLES 10 (32/64 Bits) against 1.3, 2.0, 2.2
- SLES 11 (64 Bits) against 2.2
- RHEL 5 and 6 (64 Bits) against 2.2

- Tool chain:
- platform gcc except for Solaris
  (gcc 4.1.2 for Solaris 8)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
  (and -mpcu=v9 on Solaris)

Rainer

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 52887] New: Tomcat getting crashed frequently

https://issues.apache.org/bugzilla/show_bug.cgi?id=52887

 Bug #: 52887
   Summary: Tomcat getting crashed frequently
   Product: Tomcat 6
   Version: 6.0.13
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P2
 Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: hirenpatel5...@yahoo.com
Classification: Unclassified


Created attachment 28451
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=28451
Error PID file

Hello Team,

We are facing Tomcat crash issue frequently .

Tomcat version:6.0.13

OS:linux

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Commented] (MTOMCAT-125) mvn tomcat7:run got "javax.naming.NameNotFoundException: Name jdbc is not bound in this Context"

2012-03-12 Thread Olivier Lamy (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/MTOMCAT-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227456#comment-13227456
 ] 

Olivier Lamy commented on MTOMCAT-125:
--

Do you have more logs ? (especially container start )
How do you add dependency on your jdbc driver when you use the plugin ?

> mvn tomcat7:run got "javax.naming.NameNotFoundException: Name jdbc is not 
> bound in this Context"
> 
>
> Key: MTOMCAT-125
> URL: https://issues.apache.org/jira/browse/MTOMCAT-125
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>  Components: tomcat7
>Affects Versions: 2.0-beta-1
> Environment: JDK 7, Tomcat 7.0.25, tomcat7-maven-plugin/2.0-beta-1
>Reporter: guofeng zhang
>Assignee: Olivier Lamy
>
> I configured the datatsource as global naming datasource in server.xml,
>   
> auth="Container"
>maxPoolSize="100" minPoolSize="10"
>name="jdbc/iviewDS"
>testQuery="select count(*) from T_ROLE"
>factory=".."
>type="javax.sql.DataSource"
>uniqueResourceName="jdbc/iviewDS"/>
> The server.xml is copied to src\main\tomcatconf, (this also copyied by the 
> plugin to target\tomcat\conf, so it is used).
> then in webapp/META-INF/context.xml, I have:
> name="jdbc/iviewDS"
> global="jdbc/iviewDS"
> type="javax.sql.DataSource"
> />
> And in web.xml:
> 
> datasoruce
> jdbc/iviewDS
> javax.sql.DataSource
> Container
> 
> In my code, I lookup the datasource using 'java:/comp/env/jdbc/iviewDS'.
> This works well when I deploy the app into tomcat/app directory.

--
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

DO NOT REPLY [Bug 52887] Tomcat getting crashed frequently

https://issues.apache.org/bugzilla/show_bug.cgi?id=52887

Konstantin Kolinko  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #1 from Konstantin Kolinko  2012-03-12 
12:48:24 UTC ---
Bugzilla is not a support forum.

The crash is not caused by Tomcat code.

Both Tomcat 6.0.13 and JRE 1.6.0_06-b02 are many years old. You should consider
upgrading them.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Created] (MTOMCAT-126) Add support for keystoreType

2012-03-12 Thread Created

Add support for keystoreType


 Key: MTOMCAT-126
 URL: https://issues.apache.org/jira/browse/MTOMCAT-126
 Project: Apache Tomcat Maven Plugin
  Issue Type: New Feature
  Components: tomcat6, tomcat7
Affects Versions: 2.0
Reporter: Cédric Couralet
Assignee: Olivier Lamy
Priority: Minor


I think it would be interesting to add the possibility of changing the keystore 
type for the https connector.

It could be done in exactly the same way as keystoreFile or keystorePass.

--
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-126) Add support for keystoreType

2012-03-12 Thread Updated


 [ 
https://issues.apache.org/jira/browse/MTOMCAT-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cédric Couralet updated MTOMCAT-126:


Attachment: patch.txt

a patch to add support for keystoreType.

> Add support for keystoreType
> 
>
> Key: MTOMCAT-126
> URL: https://issues.apache.org/jira/browse/MTOMCAT-126
> Project: Apache Tomcat Maven Plugin
>  Issue Type: New Feature
>  Components: tomcat6, tomcat7
>Affects Versions: 2.0
>Reporter: Cédric Couralet
>Assignee: Olivier Lamy
>Priority: Minor
>  Labels: newbie
> Attachments: patch.txt
>
>
> I think it would be interesting to add the possibility of changing the 
> keystore type for the https connector.
> It could be done in exactly the same way as keystoreFile or keystorePass.

--
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: r1299689 - in /tomcat/maven-plugin/trunk: tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/AbstractRunMojo.java tomcat7-maven-plugin/src/main/java/org/apache/tomca

2012-03-12 Thread olamy

Author: olamy
Date: Mon Mar 12 14:36:22 2012
New Revision: 1299689

URL: http://svn.apache.org/viewvc?rev=1299689&view=rev
Log:
[MTOMCAT-126] Add support for keystoreType
Submitted by Cédric Couralet.

Modified:

tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/AbstractRunMojo.java

tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/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=1299689&r1=1299688&r2=1299689&view=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 Mar 12 14:36:22 2012
@@ -71,7 +71,7 @@ import java.util.Set;
  *
  * @author Jurgen Lust
  * @author Mark Hobson 
- * @version $Id: AbstractRunMojo.java 14033 2011-05-04 17:51:15Z bimargulies $
+ * @version $Id$
  */
 public abstract class AbstractRunMojo
 extends AbstractI18NTomcat6Mojo
@@ -253,6 +253,14 @@ public abstract class AbstractRunMojo
  * @since 1.1
  */
 private String keystorePass;
+
+/**
+ * Override the default keystoreType for the HTTPS connector (if enabled)
+ *
+ * @parameter
+ * @since 1.1
+ */
+private String keystoreType;
 
 /**
  * 
@@ -767,6 +775,10 @@ public abstract class AbstractRunMojo
 {
 httpsConnector.setAttribute( "keystorePass", 
keystorePass );
 }
+if ( keystoreType != null )
+{
+httpsConnector.setAttribute( "keystoreType", 
keystoreType );
+}
 container.addConnector( httpsConnector );
 
 }

Modified: 
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunMojo.java
URL: 
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunMojo.java?rev=1299689&r1=1299688&r2=1299689&view=diff
==
--- 
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunMojo.java
 (original)
+++ 
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunMojo.java
 Mon Mar 12 14:36:22 2012
@@ -254,7 +254,13 @@ public abstract class AbstractRunMojo
  * @since 1.1
  */
 private String keystorePass;
-
+
+/**
+ * Override the type of keystore file to be used for the server 
certificate. If not specified, the default value is "JKS".
+ * @parameter default-value="JKS"
+ */
+private String keystoreType;
+
 /**
  * 
  * Enables or disables naming support for the embedded Tomcat server.
@@ -752,6 +758,10 @@ public abstract class AbstractRunMojo
 {
 httpsConnector.setAttribute( "keystorePass", 
keystorePass );
 }
+if ( keystoreType != null )
+{
+   httpsConnector.setAttribute( "keystoreType", 
keystoreType);
+}
 embeddedTomcat.getEngine().getService().addConnector( 
httpsConnector );
 
 }



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Closed] (MTOMCAT-126) Add support for keystoreType

2012-03-12 Thread Olivier Lamy (Closed) (JIRA)


 [ 
https://issues.apache.org/jira/browse/MTOMCAT-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed MTOMCAT-126.


   Resolution: Fixed
Fix Version/s: 2.0

patch applied.
Thanks !! 

> Add support for keystoreType
> 
>
> Key: MTOMCAT-126
> URL: https://issues.apache.org/jira/browse/MTOMCAT-126
> Project: Apache Tomcat Maven Plugin
>  Issue Type: New Feature
>  Components: tomcat6, tomcat7
>Affects Versions: 2.0
>Reporter: Cédric Couralet
>Assignee: Olivier Lamy
>Priority: Minor
>  Labels: newbie
> Fix For: 2.0
>
> Attachments: patch.txt
>
>
> I think it would be interesting to add the possibility of changing the 
> keystore type for the https connector.
> It could be done in exactly the same way as keystoreFile or keystorePass.

--
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-126) Add support for keystoreType

2012-03-12 Thread Hudson (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/MTOMCAT-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227611#comment-13227611
 ] 

Hudson commented on MTOMCAT-126:


Integrated in TomcatMavenPlugin-mvn3.x #116 (See 
[https://builds.apache.org/job/TomcatMavenPlugin-mvn3.x/116/])
[MTOMCAT-126] Add support for keystoreType
Submitted by Cédric Couralet. (Revision 1299689)

 Result = FAILURE
olamy : http://svn.apache.org/viewvc/?view=rev&rev=1299689
Files : 
* 
/tomcat/maven-plugin/trunk/tomcat6-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat6/AbstractRunMojo.java
* 
/tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunMojo.java


> Add support for keystoreType
> 
>
> Key: MTOMCAT-126
> URL: https://issues.apache.org/jira/browse/MTOMCAT-126
> Project: Apache Tomcat Maven Plugin
>  Issue Type: New Feature
>  Components: tomcat6, tomcat7
>Affects Versions: 2.0
>Reporter: Cédric Couralet
>Assignee: Olivier Lamy
>Priority: Minor
>  Labels: newbie
> Fix For: 2.0
>
> Attachments: patch.txt
>
>
> I think it would be interesting to add the possibility of changing the 
> keystore type for the https connector.
> It could be done in exactly the same way as keystoreFile or keystorePass.

--
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

[GUMP@vmgump]: Project tomcat-tc7.0.x-test (in module tomcat-7.0.x) failed

2012-03-12 Thread Bill Barker

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: 20 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-12032012.jar 
-Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-12032012-native-src.tar.gz
 
-Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-12032012-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-12032012.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-12032012.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/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-7.
 
0.x/tomcat-deps/tomcat-dbcp-12032012.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-12032012.jar:/srv/gump/public/workspace/junit/dist/

DO NOT REPLY [Bug 51237] SlowQueryReport interceptor does not log anything

https://issues.apache.org/bugzilla/show_bug.cgi?id=51237

Lucas Pouzac  changed:

   What|Removed |Added

 CC||lucas.pouzac@gmail.com

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 51388] SlowQueryReport should respect Statement.getQueryTimeout() value

https://issues.apache.org/bugzilla/show_bug.cgi?id=51388

Lucas Pouzac  changed:

   What|Removed |Added

 CC||lucas.pouzac@gmail.com

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 51388] SlowQueryReport should respect Statement.getQueryTimeout() value

https://issues.apache.org/bugzilla/show_bug.cgi?id=51388

Lucas Pouzac  changed:

   What|Removed |Added

 CC|lucas.pouzac@gmail.com  |

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 52830] DataSource JNDI lookup with javax.naming.Name failed

https://issues.apache.org/bugzilla/show_bug.cgi?id=52830

--- Comment #3 from lachame...@gmail.com 2012-03-12 18:20:16 UTC ---
The same bug happen on Tomcat 6.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

RE: Possible alternative Tomcat IIS Connector implementation

2012-03-12 Thread Konstantin Preißer

Hello Mladen,

> -Original Message-
> From: Mladen Turk [mailto:mt...@apache.org]
> Sent: Monday, March 12, 2012 8:24 AM
> To: dev@tomcat.apache.org
> Subject: Re: Possible alternative Tomcat IIS Connector implementation
> 
> 
> I would rather see SPDY connector over AJP.
> AJP has serious limitations, and recently we discussed using SPDY for
> server-to-server communication.
> 

Thank you very much for your reply.

I had a quick look at SPDY, and you're right, SPDY has features for using a TCP 
connection more efficiently (e.g. to multiplex streams over a single TCP 
connection). Maybe when I have some time again, I should look into creating an 
SPDY connector for IIS to Tomcat? :)


However, currently I'm having a small doubt about a server-to-server 
communication with SPDY, but maybe it is only because I didn't look that much 
into SPDY, so please correct me if I'm saying something wrong now.

>From what I read from SPDY specification, it allows to multiplex lot of 
>streams over a single TCP connection. E.g. when IIS would communicate to 
>Tomcat over SPDY, a single TCP connection would allow to process multiple 
>requests at a time.
Now imagine that a Client with a very slow connection requests a file from 
Tomcat which is very big. IIS would create a SPDY stream over an existing TCP 
connection to start retrieving the file. However, When the stream is 
established and Tomcat begins to send the file, IIS would not be able to send 
all the chunks which it gets from the SPDY connection to the client 
immediately, since there is a very slow connection to the client. However, IIS 
can't simply stop reading from the SPDY connection, because there may be frames 
which belongs to other SPDY streams (e.g. other clients). This would mean that 
IIS needs to continue reading and cache the output from Tomcat somewhere, until 
the connected client reads it. Is this correct? (E.g. imagine a servlet creates 
dynamically 1 GB of data, which IIS would need to cache somewhere in order to 
be able to get chunks from other SPDY streams. Whereas with AJP, IIS would 
simply stop reading from the AJP connection which doesn't affect other 
clients.) Wouldn't this be a problem? (But probably  I'm just missing something 
which allows to control this behavior).


Thank you!

Regards,
Konstantin Preißer


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Possible alternative Tomcat IIS Connector implementation

2012-03-12 Thread William Churchill (Issue Comment Edited) (JIRA)


On 03/12/2012 07:51 PM, Konstantin Preißer wrote:


Now imagine that a Client with a very slow connection requests a file from 
Tomcat which is very big. IIS would create a SPDY stream over an existing TCP 
connection to start retrieving the file. However, When the stream is 
established and Tomcat begins to send the file, IIS would not be able to send 
all the chunks which it gets from the SPDY connection to the client 
immediately, since there is a very slow connection to the client. However, IIS 
can't simply stop reading from the SPDY connection


You would need to read at least one frame.
Suppose a thread that would drain the frame would be needed
in case client closes the connection prematurely.


Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Possible alternative Tomcat IIS Connector implementation

2012-03-12 Thread Jordan Michaels

Hi Konstantin,

If you're interested in a IIS->Tomcat connector in .NET, there's already
one that exists over here:

http://tomcatiis.riaforge.org/

It's licensed under the Apache license, and works well. I am not a .NET
developer, so I haven't looked at the code myself, but I have worked
with Bilal (the author) on several projects; he's sharp, accommodating,
and even speaks German I believe. I'd encourage you guys to coordinate
since you obviously have similar interests.

Perhaps you all could implement SPDY?

Warm Regards,
Jordan Michaels

On 03/11/2012 06:08 PM, Konstantin Preißer wrote:

Hello Tomcat developers,

I'm Konstantin Preißer, a german student of Computer Science. I'm developing
programs with Java and .Net/C#.

Since I have been using Tomcat with IIS (JK ISAPI Connector) for quite some time now,
I wondered if it may be an option for the Apache software foundation / Tomcat
developers to have an alternative implementation of a IIS<-> Tomcat connector.

IIS 7.0 introduced a new module-based request pipeline, which allows to add
managed (.Net) and native (C++) modules to the request processing pipeline. A
managed module means that it is written in a language of the Microsoft .Net
Framework (e.g. C#), which is very similar to Java. Specifically, it is a Class
which implements the System.Net.IHttpModule interface, and for example can get
called each time a request is made to IIS. It then has access to HttpRequest
and HttpResponse objects (like a Java HttpServlet).

Since I had some free time today, I decided to try to start an implementation
of a IIS-Tomcat connector by creating a managed IIS module, which would
intercept requests and send them on a AJP connection to Tomcat. For this, I
used the AJP protocol documentation here:
http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
I know there's already another implementation of such a module, but it is from
another site/organisation and not from Apache. However, I thought it might be
good if there's an official Apache implementation of such a IIS module, and I
would happily give the complete source and licenses etc. to Apache, if anyone
is interested.

I started with the implementation today and got now to a point where basic
features (redirecting GET/POST requests (with message body) to Tomcat) seems to
work well, although, of couse, a lot of features are not yet implemented
(logging, configuration, error handling, ...). The code is written in C# (using
the .Net Framework 4.0). If you want to take a look at it, you can download the
sources from the SVN repo here:
https://pleier-it.de:8543/svn/testRepo/trunk/.Net-Projekte/IIS_AJP_Module/
(note that the site uses a self-signed certificate, causing a certificate
warnings in browsers). It is a Visual Studio 2010/Framework 4.0 project.

If you want to try it on IIS 7.0/7.5/8.0 Beta, you can do the following:

0. Ensure that Tomcat is running with an AJP connector on localhost:8009. Also ensure
that you have the .Net Framework 4.0 (Full version) installed, and that the IIS
application pool which you would like to try the connector with is using the Framework
4.0 and "Integrated" Managed Pipeline Mode. (You can also try with an earlier
version, but I'm not sure if the code will compile there)

1. In your IIS site root directory (e.g. C:\inetpub\wwwroot\), create a folder with the
name "App_Code", and copy all *.cs files from the source code into that
directory (or a subdirectory).

2. In the IIS manager, click on the site/virtual host where you would like to test the
connector, then click on item "Modules".

3. Click on "Add Managed Module...". In the combobox, type
"MyModuleNamespace.IisAjpModule.AjpModule" (without quotes) and enter a name for the module in the
textbox above. Make sure "Invoke only for requests to ASP.Net managed applications etc" is not
selected. Then click OK, and when a Message appears that the type could not be found in referenced libraries,
click Yes.

4. Open a browser and goto http://localhost/. You should now see a page served
by Tomcat.

As I already said, the current code is far from being considered as "finished",
but it can demonstrate the principle. (I'm also not sure how exactly the IIS request
pipelining works, and if the current way how the module intercepts the request is
correct, but at least it seems to work ;) ).

I think, compared to the ISAPI approach, there are some advantages and
disadvantages of this connector:

Advantages:
- Easier to maintain. I have looked a bit at the ISAPI code, and as it is C++
code, it is probably somewhat hard to maintain. As I said, for this connector
(in the current stage) I only spend one day to read the AJP documentation and
to program the module, so it is probably very easy to write a AJP connector
this way. :)
- Easier to install (you don't have to setup virtual directories etc).

Disadvantages:
-Probably worse Performance. Although I haven't done any performance tests

[jira] [Commented] (MTOMCAT-116) NonRepeatableRequestException when executing goal tomcat6:deploy

2012-03-12 Thread William Churchill (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/MTOMCAT-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227814#comment-13227814
 ] 

William Churchill commented on MTOMCAT-116:
---

I have a similar problem on a Linux System.  I am able to deploy my war file to 
a locally running instance of Tomcat (6.0.33).  When I try to deploy my war to 
a remote system running 6.0.24, I receive the above exception.  I can see the 
manager console for the remote system to which I am trying to deploy.

> NonRepeatableRequestException when executing goal tomcat6:deploy
> 
>
> Key: MTOMCAT-116
> URL: https://issues.apache.org/jira/browse/MTOMCAT-116
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>  Components: tomcat6
>Affects Versions: 2.0-beta-1
> Environment: Client: Windows 7/Eclipse Indigo/Java 5/m2eclipse 
> (embedded mvn 3.0.2/1.0.100.20110804-1717)
> Server: Windows 2003 Server/Tomcat 6.0.32/Java 6/
>Reporter: Michael Yockey
>Assignee: Olivier Lamy
>
> Deployment to Tomcat fails after war upload. The war file does not appear on 
> the server but the maven log marks the upload progess to completion. The 
> application is not successfully deployed. Here is the relevant stack trace 
> from the Maven debugging output:
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.tomcat.maven:tomcat6-maven-plugin:2.0-SNAPSHOT:deploy 
> (default-cli) on project web-integration: Cannot invoke Tomcat manager
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
>   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:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:592)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot invoke 
> Tomcat manager
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractCatalinaMojo.execute(AbstractCatalinaMojo.java:152)
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractWarCatalinaMojo.execute(AbstractWarCatalinaMojo.java:71)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 19 more
> Caused by: org.apache.http.client.ClientProtocolException
>   at 
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:926)
>   at 
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:822)
>   at 
> org.apache.tomcat.maven.common.deployer.TomcatManager.invoke(TomcatManager.java:718)
>   at 
> org.apache.tomcat.maven.common.deployer.TomcatManager.deployImpl(TomcatManager.java:681)
>   at 
> org.apache.tomcat.maven.common.deployer.TomcatManager.deploy(TomcatManager.java:363)
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractDeployWarMojo.deployWar(AbstractDeployWarMojo.java:87)
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractDeployMojo.invokeManager(AbstractDeployMojo.java:86)
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractCatalinaMojo.execute(AbstractCatalinaMojo.java:143)
>   ... 22 more
> Caused by: org.apache.http.clie

[jira] [Issue Comment Edited] (MTOMCAT-116) NonRepeatableRequestException when executing goal tomcat6:deploy


[ 
https://issues.apache.org/jira/browse/MTOMCAT-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227814#comment-13227814
 ] 

William Churchill edited comment on MTOMCAT-116 at 3/12/12 7:46 PM:


I have a similar problem on a Linux System.  I am able to deploy my war file to 
a locally running instance of Tomcat (6.0.33).  When I try to deploy my war to 
a remote system running 6.0.24, I receive the above exception.  I can see the 
manager console for the remote system to which I am trying to deploy.  

The remote system has all requests to port 80 NAT'ed to 8080 where Tomcat is 
listening.  When I explicitly used port 8080 in my url, it worked.  So it 
appears port re-directs do not work here.  Hope that helps.

  was (Author: wchurchill):
I have a similar problem on a Linux System.  I am able to deploy my war 
file to a locally running instance of Tomcat (6.0.33).  When I try to deploy my 
war to a remote system running 6.0.24, I receive the above exception.  I can 
see the manager console for the remote system to which I am trying to deploy.
  
> NonRepeatableRequestException when executing goal tomcat6:deploy
> 
>
> Key: MTOMCAT-116
> URL: https://issues.apache.org/jira/browse/MTOMCAT-116
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>  Components: tomcat6
>Affects Versions: 2.0-beta-1
> Environment: Client: Windows 7/Eclipse Indigo/Java 5/m2eclipse 
> (embedded mvn 3.0.2/1.0.100.20110804-1717)
> Server: Windows 2003 Server/Tomcat 6.0.32/Java 6/
>Reporter: Michael Yockey
>Assignee: Olivier Lamy
>
> Deployment to Tomcat fails after war upload. The war file does not appear on 
> the server but the maven log marks the upload progess to completion. The 
> application is not successfully deployed. Here is the relevant stack trace 
> from the Maven debugging output:
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.tomcat.maven:tomcat6-maven-plugin:2.0-SNAPSHOT:deploy 
> (default-cli) on project web-integration: Cannot invoke Tomcat manager
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
>   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:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:592)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot invoke 
> Tomcat manager
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractCatalinaMojo.execute(AbstractCatalinaMojo.java:152)
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractWarCatalinaMojo.execute(AbstractWarCatalinaMojo.java:71)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 19 more
> Caused by: org.apache.http.client.ClientProtocolException
>   at 
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:926)
>   at 
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:822)
>   at 
> org.apache.tomcat.maven.common.deployer.TomcatManager

DO NOT REPLY [Bug 52830] DataSource JNDI lookup with javax.naming.Name failed

https://issues.apache.org/bugzilla/show_bug.cgi?id=52830

Mark Thomas  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Component|Catalina|Catalina
 Resolution|FIXED   |
Product|Tomcat 7|Tomcat 6
   Target Milestone|--- |default

--- Comment #4 from Mark Thomas  2012-03-12 19:52:17 UTC ---
Re-opening to fix in Tomcat 6.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1299812 - /tomcat/tc6.0.x/trunk/STATUS.txt

Author: markt
Date: Mon Mar 12 19:53:40 2012
New Revision: 1299812

URL: http://svn.apache.org/viewvc?rev=1299812&view=rev
Log:
Proposal

Modified:
tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1299812&r1=1299811&r2=1299812&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 12 19:53:40 2012
@@ -160,6 +160,12 @@ PATCHES PROPOSED TO BACKPORT:
   +1: markt
   -1:
 
+* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52830
+  Lookups using javax.naming.Name fail
+  http://svn.apache.org/viewvc?rev=1298635&view=rev
+  +1: markt
+  -1:
+
 
 PATCHES/ISSUES THAT ARE STALLED
 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 52830] DataSource JNDI lookup with javax.naming.Name failed

https://issues.apache.org/bugzilla/show_bug.cgi?id=52830

--- Comment #5 from Mark Thomas  2012-03-12 19:53:46 UTC ---
Fix proposed for 6.0.x.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1299819 - /tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java

Author: markt
Date: Mon Mar 12 20:11:11 2012
New Revision: 1299819

URL: http://svn.apache.org/viewvc?rev=1299819&view=rev
Log:
UCDetector.
- use final where appropriate
- deprecate unused code

Modified:
tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java

Modified: tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java?rev=1299819&r1=1299818&r2=1299819&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java Mon Mar 
12 20:11:11 2012
@@ -158,7 +158,7 @@ public class DefaultServlet
 /**
  * Array containing the safe characters set.
  */
-protected static URLEncoder urlEncoder;
+protected static final URLEncoder urlEncoder;
 
 
 /**
@@ -211,7 +211,7 @@ public class DefaultServlet
 /**
  * Full range marker.
  */
-protected static ArrayList FULL = new ArrayList();
+protected static final ArrayList FULL = new ArrayList();
 
 
 // - Static Initializer
@@ -716,7 +716,10 @@ public class DefaultServlet
 
 /**
  * Display the size of a file.
+ * @deprecated Will be removed in Tomcat 8.0.x. Replaced by
+ * {@link #renderSize(long)}
  */
+@Deprecated
 protected void displaySize(StringBuilder buf, int filesize) {
 
 int leftside = filesize / 1024;



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Upgrade Tomcat 6 from ECJ 3.7 to ECJ 3.7.1?

2012-03-12 Thread Nick Williams

We are researching upgrading our application from Java 6 to Java 7. From
what I can tell, Tomcat 6, and our application in Tomcat 6, run fine in
Java 7. No problems whatsoever. Until you use Java 7 language features in a
JSP. Tomcat 7, however, does not have this problem.



>From what I can tell, the key is the ECJ library. Tomcat 7 has ECJ 3.7.1,
which has full Java 7 support, while Tomcat 6 has JCT 3.7.0, which has NO
Java 7 support.



Seeing as how these versions of ECJ are a mere 1 patch apart, are there any
plans to upgrade Tomcat 6 to ECJ 3.7.1? It would sure be nice to tell our
customers they can still run our application on Tomcat 6.



Furthermore, are there any compelling reasons *not* to upgrade Tomcat 6 to
ECJ 3.7.1?



Thanks,



Nick Williams

svn commit: r1299821 - /tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java

Author: markt
Date: Mon Mar 12 20:12:01 2012
New Revision: 1299821

URL: http://svn.apache.org/viewvc?rev=1299821&view=rev
Log:
Delete deprecated and unused code.

Modified:
tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java

Modified: tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java?rev=1299821&r1=1299820&r2=1299821&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java Mon Mar 
12 20:12:01 2012
@@ -715,25 +715,6 @@ public class DefaultServlet
 
 
 /**
- * Display the size of a file.
- * @deprecated Will be removed in Tomcat 8.0.x. Replaced by
- * {@link #renderSize(long)}
- */
-@Deprecated
-protected void displaySize(StringBuilder buf, int filesize) {
-
-int leftside = filesize / 1024;
-int rightside = (filesize % 1024) / 103;  // makes 1 digit
-// To avoid 0.0 for non-zero file, we bump to 0.1
-if (leftside == 0 && rightside == 0 && filesize != 0)
-rightside = 1;
-buf.append(leftside).append(".").append(rightside);
-buf.append(" KB");
-
-}
-
-
-/**
  * Serve the specified resource, optionally including the data content.
  *
  * @param request The servlet request we are processing



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Commented] (MTOMCAT-116) NonRepeatableRequestException when executing goal tomcat6:deploy

2012-03-12 Thread Olivier Lamy (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/MTOMCAT-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227843#comment-13227843
 ] 

Olivier Lamy commented on MTOMCAT-116:
--

NAT'ed ? or using some redirect or mod_proxy ?

> NonRepeatableRequestException when executing goal tomcat6:deploy
> 
>
> Key: MTOMCAT-116
> URL: https://issues.apache.org/jira/browse/MTOMCAT-116
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>  Components: tomcat6
>Affects Versions: 2.0-beta-1
> Environment: Client: Windows 7/Eclipse Indigo/Java 5/m2eclipse 
> (embedded mvn 3.0.2/1.0.100.20110804-1717)
> Server: Windows 2003 Server/Tomcat 6.0.32/Java 6/
>Reporter: Michael Yockey
>Assignee: Olivier Lamy
>
> Deployment to Tomcat fails after war upload. The war file does not appear on 
> the server but the maven log marks the upload progess to completion. The 
> application is not successfully deployed. Here is the relevant stack trace 
> from the Maven debugging output:
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.tomcat.maven:tomcat6-maven-plugin:2.0-SNAPSHOT:deploy 
> (default-cli) on project web-integration: Cannot invoke Tomcat manager
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
>   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:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:592)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot invoke 
> Tomcat manager
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractCatalinaMojo.execute(AbstractCatalinaMojo.java:152)
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractWarCatalinaMojo.execute(AbstractWarCatalinaMojo.java:71)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 19 more
> Caused by: org.apache.http.client.ClientProtocolException
>   at 
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:926)
>   at 
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:822)
>   at 
> org.apache.tomcat.maven.common.deployer.TomcatManager.invoke(TomcatManager.java:718)
>   at 
> org.apache.tomcat.maven.common.deployer.TomcatManager.deployImpl(TomcatManager.java:681)
>   at 
> org.apache.tomcat.maven.common.deployer.TomcatManager.deploy(TomcatManager.java:363)
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractDeployWarMojo.deployWar(AbstractDeployWarMojo.java:87)
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractDeployMojo.invokeManager(AbstractDeployMojo.java:86)
>   at 
> org.apache.tomcat.maven.plugin.tomcat6.AbstractCatalinaMojo.execute(AbstractCatalinaMojo.java:143)
>   ... 22 more
> Caused by: org.apache.http.client.NonRepeatableRequestException: Cannot retry 
> request with a non-repeatable request entity.
>   at 
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:686)
>   at 
> org.apache.http.impl.client.DefaultRequestDirector.exe

svn commit: r1299822 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/servlets/DefaultServlet.java

Author: markt
Date: Mon Mar 12 20:13:06 2012
New Revision: 1299822

URL: http://svn.apache.org/viewvc?rev=1299822&view=rev
Log:
UCDetector improvements. Use final. Deprecate unused code.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/servlets/DefaultServlet.java

Propchange: tomcat/tc7.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Mar 12 20:13:06 2012
@@ -1 +1 @@
-/tomcat/trunk:1156115-1157160,1157162-1157859,1157862-1157942,1157945-1160347,1160349-1163716,1163718-1166689,1166691-1174340,1174342-1175596,1175598-1175611,1175613-1175932,1175934-1177783,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187381,1187753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339
 
,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1201931,1202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208
 
145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121,1220293,1220295,1221038,1221842,1222189,101,176,1222300,1222690,1222850,1222852,1222855,1224607,1224617,1224648-1224652,1224657,1224662-1224663,1224682,1224801,1224910,1225000,1225219,1225343,1225465,1225627,1225629,1225634,1226069,1226158-1226159,1226177,1226196,1226214-1226215,1226385,1226394,1226500,1226537-1226538,1226546,1226551,1226975,1228196,1228360,1228376,1228724,1228908,1228918,1228920,1228922,1228929,1228969,1229307,1229536,1229549,1229724,1229726-1229731,1229997,1230539,1230711,1230729,1230762-1230763,1230765,1230955,1230957,1231285,1231290,1231308,1231310,1231337,1231460-1231461,1231542-1231543,1231546-1231547,1231620-1231621,1231624-1231625,1231630,1231654-1231655,1231738,1231740,1231762-1231763,1231856,1231886,1231923,1231947,1232345,1232368,1232380,1232447,1232760,1232813,1232842-1232843,1
 
232869,1233413,1233423,1233426,1234143,1234567,1235207,1236906-1236907,1236914,1237146,1237154-1237156,1237332,1237334,1237425,1237427,1237604,1237975,1237981,1237985,1238070,1238073,1239024,1239048,1239050,1239060,1239135,1239483,1239485,1240101,1240106,1240109,1240112,1240114,1240116,1240118,1240121,1240329,1240697,1240795,1240821,1240842,1240857,1241087,1241160,1241908-1241909,1241982,1242099,1242110,1242371,1242434,1242495,1242947,1243034,1243038,1244302,1244511,1244567,1244718-1244719,1244935-1244938,1245274,1245449,1245849,1290875,1292334,1292338,1292345-1292347,1293155,1293831-1293832,1295998,1297014-1297015,1297017,1297158,1297177,1297202,1297209,1297213,1297717,1297722,1297729,1297768,1297778,1297818,1297828,1297979,1297987,1298121,1298140,1298590,1298592,1298628-1298629,1298794,1298983-1298984,1299020,1299034
+/tomcat/trunk:1156115-1157160,1157162-1157859,1157862-1157942,1157945-1160347,1160349-1163716,1163718-1166689,1166691-1174340,1174342-1175596,1175598-1175611,1175613-1175932,1175934-1177783,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1

DO NOT REPLY [Bug 52744] [Jasper] JSP files are always recompiled in development mode

https://issues.apache.org/bugzilla/show_bug.cgi?id=52744

--- Comment #7 from Jarek Gawor  2012-03-12 20:28:56 UTC ---
I was able to reproduce this issue. The key here is that the jsp must live in a
jar file that has a timestamp with a better precision then the file system.
Nothing is modifying the .jsp file and therefore its timestamp does not change
but each access causes it to be recompiled because of the difference in the
timestamp precision.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

RE: Possible alternative Tomcat IIS Connector implementation

2012-03-12 Thread Konstantin Preißer

Hello Mladen,

> -Original Message-
> From: Mladen Turk [mailto:mt...@apache.org]
> Sent: Monday, March 12, 2012 8:00 PM
> To: dev@tomcat.apache.org
> Subject: Re: Possible alternative Tomcat IIS Connector implementation
> 
> You would need to read at least one frame.
> Suppose a thread that would drain the frame would be needed
> in case client closes the connection prematurely.
> 

Sorry, I think I didn't fully understand you here, but probably I didn't 
express myself well.
Actually I meant to talk about flow control in SPDY per stream - but I see now 
that I read an old draft of the SPDY protocol where this wasn't mentioned. The 
current draft 3 
(http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml) talks 
about flow control in SPDY streams (e.g. section 2.6.8 "WINDOW_UPDATE"), so 
there shouldn't be a problem with this when implementing server-to-server 
communication. So maybe I can try to start an IIS SPDY connector. :)


Thanks,

Konstantin Preißer



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

RE: Possible alternative Tomcat IIS Connector implementation

2012-03-12 Thread Konstantin Preißer

Hello Jordan,

> -Original Message-
> From: Jordan Michaels [mailto:jor...@viviotech.net]
> Sent: Monday, March 12, 2012 8:15 PM
> To: Tomcat Developers List
> Subject: Re: Possible alternative Tomcat IIS Connector implementation
> 
> Hi Konstantin,
> 
> If you're interested in a IIS->Tomcat connector in .NET, there's
> already
> one that exists over here:
> 
> http://tomcatiis.riaforge.org/
> 
> It's licensed under the Apache license, and works well. I am not a .NET
> developer, so I haven't looked at the code myself, but I have worked
> with Bilal (the author) on several projects; he's sharp, accommodating,
> and even speaks German I believe. I'd encourage you guys to coordinate
> since you obviously have similar interests.
> 
> Perhaps you all could implement SPDY?
> 
> Warm Regards,
> Jordan Michaels
> 

Thanks. Yes, that project was what I meant with "another implementation", but I 
wanted to try it a bit myself :)
However, I think I will not continue my IIS-AJP connector as the connector 
which you mentioned is already finished and works well, and as Mladen pointed 
me to SPDY, so I think I will try that instead. I agree that it might be a good 
idea to collaborate on such a project. :)

Regards,
Konstantin Preißer


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat Connectors 1.2.33

2012-03-12 Thread Henri Gomez

>>> I add to add --with-apxs=/usr/sbin/apxs to configure line :
>>>
>>> CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386 -arch x86_64'
>>> ./configure --with-apr=/usr --with-ssl=/usr
>>> --with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/A/
>>> --with-apxs=/usr/sbin/apxs
>>>
>>> Why did we need now apache apxs ?
>>>
>>
>> We always required apxs, probably be before you had /usr/sbin in PATH.

Hum may be.
A change in OSX XCode 4.3 or Lion 10.7.3

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 51181] Add support for Web Sockets