buildbot success in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a restored build on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/1045 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1439758 Blamelist: kfujino Build succeeded! sincerely, -The Buildbot
buildbot success in ASF Buildbot on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/3852 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1439757 Blamelist: kfujino Build succeeded! sincerely, -The Buildbot
svn commit: r1439780 - /tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java
Author: kfujino
Date: Tue Jan 29 08:24:02 2013
New Revision: 1439780
URL: http://svn.apache.org/viewvc?rev=1439780view=rev
Log:
Additional fix for r1439757.
Prevent SSO deregister when node shutdown normally in cluster environment.
Modified:
tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java
Modified: tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java?rev=1439780r1=1439779r2=1439780view=diff
==
--- tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java Tue
Jan 29 08:24:02 2013
@@ -197,6 +197,10 @@ public class SingleSignOn extends ValveB
@Override
public void sessionEvent(SessionEvent event) {
+if (!getState().isAvailable()) {
+return;
+}
+
// We only care about session destroyed events
if (!Session.SESSION_DESTROYED_EVENT.equals(event.getType())
(!Session.SESSION_PASSIVATED_EVENT.equals(event.getType( {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54499] New: Implementation of Extensible EL Interpreter
https://issues.apache.org/bugzilla/show_bug.cgi?id=54499
Bug ID: 54499
Summary: Implementation of Extensible EL Interpreter
Product: Tomcat 7
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
Assignee: dev@tomcat.apache.org
Reporter: xs...@ebay.com
Depends on: 54239
Classification: Unclassified
Created attachment 29898
-- https://issues.apache.org/bugzilla/attachment.cgi?id=29898action=edit
JasperELInterpreter implementation
Jasper ELInterpreter Implementation
Simple ELInterpreter. It can transfer simple ELs to java code directly.
EL is a big bottleneck of JSP. EL resolving takes much CPU expense.
The performance is better when simple ELs were transfered to java code.
However the code will by pass all ELResolvers. This interpreter is not a
standard of JSP specification.
When activate this ELInterpreter. User must know how it works.
Here are the cases of Simple ELs,
1.Simple EL, only contains one part of expression, for example ${elemId}. This
kind of EL will be generated as
this.getJspContext().findAttribute(elemId)
2.EL with two parts of expression and type of first part is specified by
attribute in Tag File.
For example, ${model.location} . model is specified on the top of tag
file,
%@ attribute name=model required=true
type=org.apache.jasper.model.results.ItemModel %.
It is generated as (getModel() != null ? getModel().getLocation() : null)
3.EL with logic or arithmetic and the value part can be generated.
For example: ${(intlExpansion eq 'true' not empty model.location) ||
sortType==7}
It is generated as
(org.apache.jasper.runtime.ELRuntimeUtil.equals(getIntlExpansion(),
true)(!org.apache.jasper.runtime.ELRuntimeUtil.isEmpty((getModel() != null
? getModel().getLocation() : null
How to apply this ELInterpreter?
It is based on BUG 54239.
--
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 54239] Extensible EL Interpreter
https://issues.apache.org/bugzilla/show_bug.cgi?id=54239 Sheldon Shao xs...@ebay.com changed: What|Removed |Added Blocks||54499 -- 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 54499] Implementation of Extensible EL Interpreter
https://issues.apache.org/bugzilla/show_bug.cgi?id=54499 --- Comment #1 from Sheldon Shao xs...@ebay.com --- Created attachment 29899 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29899action=edit EL code generation -- 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 54499] Implementation of Extensible EL Interpreter
https://issues.apache.org/bugzilla/show_bug.cgi?id=54499 --- Comment #2 from Sheldon Shao xs...@ebay.com --- Created attachment 29900 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29900action=edit ELRuntime Utility for JasperELInterpreter -- 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 54499] Implementation of Extensible EL Interpreter
https://issues.apache.org/bugzilla/show_bug.cgi?id=54499 --- Comment #3 from Sheldon Shao xs...@ebay.com --- Created attachment 29901 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29901action=edit Test case for JasperELInterpreter -- 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: r1439783 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/authenticator/SingleSignOn.java webapps/docs/changelog.xml
Author: kfujino
Date: Tue Jan 29 08:29:57 2013
New Revision: 1439783
URL: http://svn.apache.org/viewvc?rev=1439783view=rev
Log:
Additional fix for r1439758.
Prevent SSO deregister when node shutdown normally in cluster environment.
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java?rev=1439783r1=1439782r2=1439783view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java
Tue Jan 29 08:29:57 2013
@@ -214,6 +214,10 @@ public class SingleSignOn extends ValveB
@Override
public void sessionEvent(SessionEvent event) {
+if (!getState().isAvailable()) {
+return;
+}
+
// We only care about session destroyed events
if (!Session.SESSION_DESTROYED_EVENT.equals(event.getType())
(!Session.SESSION_PASSIVATED_EVENT.equals(event.getType(
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1439783r1=1439782r2=1439783view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Tue Jan 29 08:29:57 2013
@@ -141,6 +141,10 @@
to maker clear that the minimum length of the destination member array
is one, not two. (markt)
/fix
+ fix
+Prevent SSO deregister when node shutdown normally in cluster
+environment. (kfujino)
+ /fix
/changelog
/subsection
subsection name=Web applications
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54499] Implementation of Extensible EL Interpreter
https://issues.apache.org/bugzilla/show_bug.cgi?id=54499 --- Comment #4 from Sheldon Shao xs...@ebay.com --- Created attachment 29902 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29902action=edit Comparison testing from our site -- 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 Native 1.1.26
On 01/25/2013 05:01 PM, jean-frederic clere wrote: The Apache Tomcat Native 1.1.26 is [X] Stable, go ahead and release [ ] Broken because of ... Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54503] New: SAML2 based single sign on
https://issues.apache.org/bugzilla/show_bug.cgi?id=54503 Bug ID: 54503 Summary: SAML2 based single sign on Product: Tomcat 8 Version: trunk Hardware: Macintosh Status: NEW Severity: enhancement Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: toby.hob...@cloudseal.com Classification: Unclassified Created attachment 29906 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29906action=edit Unified diff including new and changed files SAML2 is a standard for cross-domain single sign on and federation. We have developed a Tomcat authenticator which acts as a SAML2 service provider i.e. it allows Tomcat applications to delegate authentication to a single sign on server (identity provider). We already offer this authenticator to our customers but we would now like to contribute it to the wider Tomcat community. Whilst Tomcat already offers single sign on between webapps, SAML2 allows SSO between different platforms (.NET, PHP etc) and different hosts so we feel it's a useful contribution. The authenticator we have developed supports the most common SAML2 profiles and binding i.e. the Web browser SSO profile using the redirect/post binding. We have tested it with our own SSO server and also with a PHP implementation (Simple SAML PHP). It should also work with other SAML2 implementations although this has not been tested. I've attached quite a large patch which includes couple of changes to the core code and several additions: - A new authenticator (SamlAuthenticator) - An example webapp which demonstrates some of the features - Various tests (which make use of the example webapp) - Updates to the build.xml script - Updates to the documentation, explaining how to use the new authenticator. We still need to add some more detail here - Minor changes to Realm and RealmBase (see below) The SamlAuthenticator always retrieves the username from the IDP (SSO server) and it can retrieve the Principal's roles one of two ways: 1) The IDP can pass the roles across to Tomcat along with the username. 2) Tomcat can lookup the roles from a configured Realm. To achieve this we had to make a change to Realm to allow allow authentication using a username alone. The authenticator has 4 dependencies: - saml2-core (our general saml2 library, in maven central with an Apache 2 license) - log4j (required by saml2-core) - commons-codec (required by saml2-core) - commons-io (required by saml2-core) This patch should be applied at p0 i.e. patch -p0 saml2.diff. I'm sure there will be plenty of questions which I'm happy to answer Toby -- 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 54503] SAML2 based single sign on
https://issues.apache.org/bugzilla/show_bug.cgi?id=54503 Toby Hobson toby.hob...@cloudseal.com changed: What|Removed |Added CC||toby.hob...@cloudseal.com OS||All -- 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: r1439959 - /tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
Author: markt
Date: Tue Jan 29 15:57:43 2013
New Revision: 1439959
URL: http://svn.apache.org/viewvc?rev=1439959view=rev
Log:
Fix one cause of WebSocket unit test failures. There may be others.
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java?rev=1439959r1=1439958r2=1439959view=diff
==
--- tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
(original)
+++ tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
Tue Jan 29 15:57:43 2013
@@ -181,6 +181,12 @@ public class TestWsWebSocketContainer ex
WebSocketContainer wsContainer =
ContainerProvider.getClientContainer();
+// Reset client buffer size as client container is retained between
+// tests
+
+wsContainer.setMaxBinaryMessageBufferSize(8192);
+wsContainer.setMaxTextMessageBufferSize(8192);
+
if (isServerBuffer) {
if (isTextBuffer) {
ctx.addParameter(
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/3854 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1439959 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot
[Bug 54505] New: Resource 'closeMethod' is only documented under Context documentation
https://issues.apache.org/bugzilla/show_bug.cgi?id=54505 Bug ID: 54505 Summary: Resource 'closeMethod' is only documented under Context documentation Product: Tomcat 7 Version: trunk Hardware: PC OS: Mac OS X 10.4 Status: NEW Severity: enhancement Priority: P2 Component: Documentation Assignee: dev@tomcat.apache.org Reporter: ch...@christopherschultz.net Classification: Unclassified cf. http://markmail.org/message/zvwyy5csr3bi4whj The 'closeMethod' attribute is documented in the Context documentation, but in neither the JNDI Resources page of the users' guide nor the Resources page of the configuration guide. Thus, it's a little tough to find out about this configuration option. -- 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 54503] SAML2 based single sign on
https://issues.apache.org/bugzilla/show_bug.cgi?id=54503 Christopher Schultz ch...@christopherschultz.net changed: What|Removed |Added Attachment #29906|0 |1 is patch|| Attachment #29906|application/octet-stream|text/plain mime type|| -- 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 54503] SAML2 based single sign on
https://issues.apache.org/bugzilla/show_bug.cgi?id=54503 --- Comment #1 from Christopher Schultz ch...@christopherschultz.net --- I'm floored: a great idea, backed-up with a complete set of diffs including test cases and examples. I'm looking forward to diving-into the code further when I get some time. I did have two initial reactions when doing a (very) brief overview of the patch: 1. Is the term Cloudseal a requirement? I see that, for instance, the type of authentication is registered as CLOUDSEAL instead of, say, SAML2. I think we'd prefer to use the generic name (SAML2) rather than a particular service (Cloudseal). 2. I noticed that you changed CombinedRealm.getPrincipal(). Can you explain why that needed to change? I don't see any of your code that calls Realm.getPrincipal. Again, thanks for the great contribution. -- 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: svn commit: r1439959 - /tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
On 29/01/2013 15:57, ma...@apache.org wrote: Author: markt Date: Tue Jan 29 15:57:43 2013 New Revision: 1439959 URL: http://svn.apache.org/viewvc?rev=1439959view=rev Log: Fix one cause of WebSocket unit test failures. There may be others. And buildbot tells me there are. Back to the debugger for me... Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1440082 - /tomcat/trunk/java/org/apache/tomcat/websocket/server/ServerContainerImpl.java
Author: markt
Date: Tue Jan 29 19:46:34 2013
New Revision: 1440082
URL: http://svn.apache.org/viewvc?rev=1440082view=rev
Log:
Make sure buffer sizes are picked up from the servlet context initialisation
parameters
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/server/ServerContainerImpl.java
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/server/ServerContainerImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/server/ServerContainerImpl.java?rev=1440082r1=1440081r2=1440082view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/websocket/server/ServerContainerImpl.java
(original)
+++
tomcat/trunk/java/org/apache/tomcat/websocket/server/ServerContainerImpl.java
Tue Jan 29 19:46:34 2013
@@ -38,7 +38,7 @@ import org.apache.tomcat.websocket.pojo.
/**
* Provides a per class loader (i.e. per web application) instance of a
* ServerContainer. Web application wide defaults may be configured by setting
- * the following sevrlet context initialisation parameters to the desired
+ * the following servlet context initialisation parameters to the desired
* values.
* ul
* li{@link Constants#BINARY_BUFFER_SIZE_SERVLET_CONTEXT_INIT_PARAM}/li
@@ -160,7 +160,7 @@ public class ServerContainerImpl extends
}
// Set the ServletContext if it hasn't already been set
if (servletContext == null) {
-servletContext = ctxt;
+setServletContext(ctxt);
} else if (ctxt != servletContext) {
// Should never happen
throw new IllegalStateException(sm.getString(
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1440087 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsSession.java
Author: markt
Date: Tue Jan 29 19:56:12 2013
New Revision: 1440087
URL: http://svn.apache.org/viewvc?rev=1440087view=rev
Log:
Failure to send the close message should not stop the rest of the close
processing.
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsSession.java
Modified: tomcat/trunk/java/org/apache/tomcat/websocket/WsSession.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/WsSession.java?rev=1440087r1=1440086r2=1440087view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/WsSession.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/WsSession.java Tue Jan 29
19:56:12 2013
@@ -250,7 +250,13 @@ public class WsSession implements Sessio
msg.put(reason.getBytes(UTF8));
}
msg.flip();
-wsRemoteEndpoint.sendMessageBlocking(Constants.OPCODE_CLOSE, msg,
true);
+try {
+wsRemoteEndpoint.sendMessageBlocking(
+Constants.OPCODE_CLOSE, msg, true);
+} catch (IOException ioe) {
+// Unable to send close message.
+// TODO - Ignore?
+}
// Fire the onClose event
Thread t = Thread.currentThread();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1440088 - /tomcat/trunk/java/org/apache/tomcat/websocket/server/WsServlet.java
Author: markt
Date: Tue Jan 29 20:03:11 2013
New Revision: 1440088
URL: http://svn.apache.org/viewvc?rev=1440088view=rev
Log:
Currently no extension support (and none planned)
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/server/WsServlet.java
Modified: tomcat/trunk/java/org/apache/tomcat/websocket/server/WsServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/server/WsServlet.java?rev=1440088r1=1440087r2=1440088view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/server/WsServlet.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/server/WsServlet.java Tue Jan
29 20:03:11 2013
@@ -100,12 +100,8 @@ public class WsServlet extends HttpServl
subProtocol = sec.getNegotiatedSubprotocol(subProtocols);
}
// Extensions
-ListString requestedExtensions = getTokensFromHeader(req,
-Sec-WebSocket-Extensions);
-if (!requestedExtensions.isEmpty()) {
-// TODO
-// extensions = sec.getNegotiatedExtensions(requestedExtensions);
-}
+// Currently no extensions are supported by this implementation
+
// If we got this far, all is good. Accept the connection.
resp.setHeader(Constants.UPGRADE_HEADER_NAME,
Constants.UPGRADE_HEADER_VALUE);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1440089 - /tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java
Author: markt
Date: Tue Jan 29 20:03:25 2013
New Revision: 1440089
URL: http://svn.apache.org/viewvc?rev=1440089view=rev
Log:
Clean-up line length
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java
Modified: tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java?rev=1440089r1=1440088r2=1440089view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java Tue Jan 29
20:03:25 2013
@@ -42,7 +42,8 @@ public class WsSci implements ServletCon
return;
}
for (Class? clazz : clazzes) {
-WebSocketEndpoint annotation =
clazz.getAnnotation(WebSocketEndpoint.class);
+WebSocketEndpoint annotation =
+clazz.getAnnotation(WebSocketEndpoint.class);
sc.publishServer(clazz, ctx, annotation.value());
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
latency - websockets vs. REST
I'm seeing some differences in the latency of making a post request via jQuery versus sending a websockets message. It maybe that this is overhead in my application caused by processing the json I am sending in the message, but I find this hard to believe. I imagined that web socket connection should be faster than REST due to it not creating and destroying the socket, however this does not seem to be the case. Is there a reason why websockets should be slower? I thing I can code up a small test case to illustrate this if this is something people are interested in .. MR
svn commit: r1440091 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsFrameBase.java
Author: markt
Date: Tue Jan 29 20:04:48 2013
New Revision: 1440091
URL: http://svn.apache.org/viewvc?rev=1440091view=rev
Log:
Remove a TODO
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsFrameBase.java
Modified: tomcat/trunk/java/org/apache/tomcat/websocket/WsFrameBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/WsFrameBase.java?rev=1440091r1=1440090r2=1440091view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/WsFrameBase.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/WsFrameBase.java Tue Jan 29
20:04:48 2013
@@ -121,7 +121,8 @@ public abstract class WsFrameBase {
fin = (b 0x80) 0;
rsv = (b 0x70) 4;
if (rsv != 0) {
-// TODO Extensions may use rsv bits
+// Note extensions may use rsv bits but currently no extensions are
+// supported
throw new WsIOException(new CloseReason(
CloseCodes.PROTOCOL_ERROR,
sm.getString(wsFrame.wrongRsv, Integer.valueOf(rsv;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: latency - websockets vs. REST
On 29/01/2013 20:04, Michael Roberts wrote: I'm seeing some differences in the latency of making a post request via jQuery versus sending a websockets message. It maybe that this is overhead in my application caused by processing the json I am sending in the message, but I find this hard to believe. I imagined that web socket connection should be faster than REST due to it not creating and destroying the socket, however this does not seem to be the case. Is there a reason why websockets should be slower? I thing I can code up a small test case to illustrate this if this is something people are interested in .. Tomcat version? Connector? How much difference? REST can (and should for performance) use HTTP keep-alive. There is some overhead in upgrading an HTTP connection to use WebSocket so for a single request I'd expect the REST request to be faster. Once both connections are established, WebSocket should be faster (note that binary messages will be faster than text ones). If you have a test case that demonstrates this with established connections I'd certainly be interested. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1440095 - /tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java
Author: markt
Date: Tue Jan 29 20:16:30 2013
New Revision: 1440095
URL: http://svn.apache.org/viewvc?rev=1440095view=rev
Log:
Include the exception in the error message
Modified:
tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java
Modified: tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java?rev=1440095r1=1440094r2=1440095view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java Tue Jan 29
20:16:30 2013
@@ -553,7 +553,7 @@ public class HostConfig
} catch (Exception e) {
log.error(sm.getString(
hostConfig.deployDescriptor.error,
-contextXml.getAbsolutePath()));
+contextXml.getAbsolutePath()), e);
} finally {
if (context == null) {
context = new FailedContext();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1440096 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/startup/HostConfig.java webapps/docs/changelog.xml
Author: markt
Date: Tue Jan 29 20:17:59 2013
New Revision: 1440096
URL: http://svn.apache.org/viewvc?rev=1440096view=rev
Log:
Include the exception in the error message
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/HostConfig.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1440095
Modified: tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/HostConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/HostConfig.java?rev=1440096r1=1440095r2=1440096view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/HostConfig.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/HostConfig.java Tue
Jan 29 20:17:59 2013
@@ -612,7 +612,7 @@ public class HostConfig
} catch (Exception e) {
log.error(sm.getString(
hostConfig.deployDescriptor.error,
-contextXml.getAbsolutePath()));
+contextXml.getAbsolutePath()), e);
context = new FailedContext();
} finally {
digester.reset();
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1440096r1=1440095r2=1440096view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Tue Jan 29 20:17:59 2013
@@ -90,6 +90,10 @@
In this case, because most sessions is not time-out, SSO deregister was
triggered. (kfujino)
/fix
+ fix
+Include the exception in the log message if the parsing of the
+context.xml file fails. (markt)
+ /fix
/changelog
/subsection
subsection name=Coyote
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1440097 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Tue Jan 29 20:18:51 2013 New Revision: 1440097 URL: http://svn.apache.org/viewvc?rev=1440097view=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=1440097r1=1440096r2=1440097view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Jan 29 20:18:51 2013 @@ -112,6 +112,12 @@ PATCHES PROPOSED TO BACKPORT: +1: schultz -1: +* Better error reporting id context.xml cannot be parsed + http://svn.apache.org/viewvc?rev=1440096view=rev + +1: markt + -1: + + PATCHES/ISSUES THAT ARE STALLED * Backport JSP unloading patch (BZ48358). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: latency - websockets vs. REST
This was using .35 with the default connector (just a generic tomcat install using the installer, on windows 7 64bit) from current firefox. I can't tell you the exact time difference currently, but I can say that if I chain the calling of the REST API off the end off the completion of the WebSocket's sendMessage, the REST API call will consistently beat the web socket to the end point. Which (I think) means that either it's latency in moz's web socket implementation, or it's at the server end. I will make a test case which does exact timing and is separated from our application and report back on what I find. MR On Tue, Jan 29, 2013 at 12:11 PM, Mark Thomas ma...@apache.org wrote: On 29/01/2013 20:04, Michael Roberts wrote: I'm seeing some differences in the latency of making a post request via jQuery versus sending a websockets message. It maybe that this is overhead in my application caused by processing the json I am sending in the message, but I find this hard to believe. I imagined that web socket connection should be faster than REST due to it not creating and destroying the socket, however this does not seem to be the case. Is there a reason why websockets should be slower? I thing I can code up a small test case to illustrate this if this is something people are interested in .. Tomcat version? Connector? How much difference? REST can (and should for performance) use HTTP keep-alive. There is some overhead in upgrading an HTTP connection to use WebSocket so for a single request I'd expect the REST request to be faster. Once both connections are established, WebSocket should be faster (note that binary messages will be faster than text ones). If you have a test case that demonstrates this with established connections I'd certainly be interested. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: latency - websockets vs. REST
oh, and this was using an established connection. text message however. On Tue, Jan 29, 2013 at 12:19 PM, Michael Roberts m...@7f.com wrote: This was using .35 with the default connector (just a generic tomcat install using the installer, on windows 7 64bit) from current firefox. I can't tell you the exact time difference currently, but I can say that if I chain the calling of the REST API off the end off the completion of the WebSocket's sendMessage, the REST API call will consistently beat the web socket to the end point. Which (I think) means that either it's latency in moz's web socket implementation, or it's at the server end. I will make a test case which does exact timing and is separated from our application and report back on what I find. MR On Tue, Jan 29, 2013 at 12:11 PM, Mark Thomas ma...@apache.org wrote: On 29/01/2013 20:04, Michael Roberts wrote: I'm seeing some differences in the latency of making a post request via jQuery versus sending a websockets message. It maybe that this is overhead in my application caused by processing the json I am sending in the message, but I find this hard to believe. I imagined that web socket connection should be faster than REST due to it not creating and destroying the socket, however this does not seem to be the case. Is there a reason why websockets should be slower? I thing I can code up a small test case to illustrate this if this is something people are interested in .. Tomcat version? Connector? How much difference? REST can (and should for performance) use HTTP keep-alive. There is some overhead in upgrading an HTTP connection to use WebSocket so for a single request I'd expect the REST request to be faster. Once both connections are established, WebSocket should be faster (note that binary messages will be faster than text ones). If you have a test case that demonstrates this with established connections I'd certainly be interested. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: latency - websockets vs. REST
You can check with Google Chrome and/or IE10 to see whether it is not something in Firefox On Tue, Jan 29, 2013 at 9:19 PM, Michael Roberts m...@7f.com wrote: This was using .35 with the default connector (just a generic tomcat install using the installer, on windows 7 64bit) from current firefox. I can't tell you the exact time difference currently, but I can say that if I chain the calling of the REST API off the end off the completion of the WebSocket's sendMessage, the REST API call will consistently beat the web socket to the end point. Which (I think) means that either it's latency in moz's web socket implementation, or it's at the server end. I will make a test case which does exact timing and is separated from our application and report back on what I find. MR On Tue, Jan 29, 2013 at 12:11 PM, Mark Thomas ma...@apache.org wrote: On 29/01/2013 20:04, Michael Roberts wrote: I'm seeing some differences in the latency of making a post request via jQuery versus sending a websockets message. It maybe that this is overhead in my application caused by processing the json I am sending in the message, but I find this hard to believe. I imagined that web socket connection should be faster than REST due to it not creating and destroying the socket, however this does not seem to be the case. Is there a reason why websockets should be slower? I thing I can code up a small test case to illustrate this if this is something people are interested in .. Tomcat version? Connector? How much difference? REST can (and should for performance) use HTTP keep-alive. There is some overhead in upgrading an HTTP connection to use WebSocket so for a single request I'd expect the REST request to be faster. Once both connections are established, WebSocket should be faster (note that binary messages will be faster than text ones). If you have a test case that demonstrates this with established connections I'd certainly be interested. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
buildbot success in ASF Buildbot on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/3855 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1440082 Blamelist: markt Build succeeded! sincerely, -The Buildbot
Re: latency - websockets vs. REST
ok, I'll get to this start of next week with a comprehensive test case and report back. M On Tue, Jan 29, 2013 at 12:23 PM, Martin Grigorov mgrigo...@apache.orgwrote: You can check with Google Chrome and/or IE10 to see whether it is not something in Firefox On Tue, Jan 29, 2013 at 9:19 PM, Michael Roberts m...@7f.com wrote: This was using .35 with the default connector (just a generic tomcat install using the installer, on windows 7 64bit) from current firefox. I can't tell you the exact time difference currently, but I can say that if I chain the calling of the REST API off the end off the completion of the WebSocket's sendMessage, the REST API call will consistently beat the web socket to the end point. Which (I think) means that either it's latency in moz's web socket implementation, or it's at the server end. I will make a test case which does exact timing and is separated from our application and report back on what I find. MR On Tue, Jan 29, 2013 at 12:11 PM, Mark Thomas ma...@apache.org wrote: On 29/01/2013 20:04, Michael Roberts wrote: I'm seeing some differences in the latency of making a post request via jQuery versus sending a websockets message. It maybe that this is overhead in my application caused by processing the json I am sending in the message, but I find this hard to believe. I imagined that web socket connection should be faster than REST due to it not creating and destroying the socket, however this does not seem to be the case. Is there a reason why websockets should be slower? I thing I can code up a small test case to illustrate this if this is something people are interested in .. Tomcat version? Connector? How much difference? REST can (and should for performance) use HTTP keep-alive. There is some overhead in upgrading an HTTP connection to use WebSocket so for a single request I'd expect the REST request to be faster. Once both connections are established, WebSocket should be faster (note that binary messages will be faster than text ones). If you have a test case that demonstrates this with established connections I'd certainly be interested. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
buildbot failure in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a new failure on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/1047 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1440096 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot
[Bug 54503] SAML2 based single sign on
https://issues.apache.org/bugzilla/show_bug.cgi?id=54503 --- Comment #2 from Toby Hobson toby.hob...@cloudseal.com --- Hi Christopher Cloudseal is certainly not a requirement, SAML2 would indeed be a better name. I think the term is a hangover from our current implementation of the authenticator which we offer with our product (we describe it as a Cloudseal Authenticaor). The only thing I would point out is that the code uses a class called CloudsealPrincipal. This would have to remain because CloudsealPrincipal is defined in our saml2-core library. We may refactor this class at some stage but there's nothing SAML specific about it (and we also use it for our OAUTH2 implementation) There's a transitive dependency on CombinedRealm.getPrincipal(String) - As mentioned in the bugzilla comments the SamlAuthenticator can lookup roles against a configured realm. We modified Realm to add authenticate(String). RealmBase.authenticate(String) calls getPrincipal(String) and CombinedRealm extends RealmBase. The modification allows a developer to use CombinedRealm with the SamlAuthenticator if he wants. -- 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-204) ClassNotFoundException: org.apache.catalina.util.StringManager
Alain Perreault created MTOMCAT-204: --- Summary: ClassNotFoundException: org.apache.catalina.util.StringManager Key: MTOMCAT-204 URL: https://issues.apache.org/jira/browse/MTOMCAT-204 Project: Apache Tomcat Maven Plugin Issue Type: Question Components: tomcat7 Environment: Microsoft Windows XP Professionnel Version 2002 Sertvice Pack 3 Reporter: Alain Perreault Assignee: Olivier Lamy (*$^¨%`£) During deployment I get this exeption org.apache.catalina.core.ContainerBase addChildInternalOrg.apache.cata GRAVE: ContainerBase addChild: start: org.apache.catalinaLifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/MyServer]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java 154) ... Caused by: java.lang.NoClassDefFoundError: Lorg/apache/catalina/util/StringManager; at java.lang.Class.getDeclaredFieldFields0(Native Method) at java.lang.Class.privateGetDeclaredFields (Unknown Source) at java.lang.Class.getDeclaredFields (Unknown Source) at org.apache.catalina.util.Introspection.getDeclaredFields (Introspection.java:106) ... Cased by: java.lang.ClassNotFoundException: org.apache.catalina.util.StringManager I used apache-tomcat-7.0.35-windows-x86 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-204) ClassNotFoundException: org.apache.catalina.util.StringManager
[ https://issues.apache.org/jira/browse/MTOMCAT-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alain Perreault updated MTOMCAT-204: Description: During deployment I get this exeption org.apache.catalina.core.ContainerBase addChildInternalOrg.apache.cata GRAVE: ContainerBase addChild: start: org.apache.catalinaLifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/MyServer]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java 154) ... Caused by: java.lang.NoClassDefFoundError: Lorg/apache/catalina/util/StringManager; at java.lang.Class.getDeclaredFieldFields0(Native Method) at java.lang.Class.privateGetDeclaredFields (Unknown Source) at java.lang.Class.getDeclaredFields (Unknown Source) at org.apache.catalina.util.Introspection.getDeclaredFields (Introspection.java:106) ... Caused by: java.lang.ClassNotFoundException: org.apache.catalina.util.StringManager I used apache-tomcat-7.0.35-windows-x86 was: During deployment I get this exeption org.apache.catalina.core.ContainerBase addChildInternalOrg.apache.cata GRAVE: ContainerBase addChild: start: org.apache.catalinaLifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/MyServer]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java 154) ... Caused by: java.lang.NoClassDefFoundError: Lorg/apache/catalina/util/StringManager; at java.lang.Class.getDeclaredFieldFields0(Native Method) at java.lang.Class.privateGetDeclaredFields (Unknown Source) at java.lang.Class.getDeclaredFields (Unknown Source) at org.apache.catalina.util.Introspection.getDeclaredFields (Introspection.java:106) ... Cased by: java.lang.ClassNotFoundException: org.apache.catalina.util.StringManager I used apache-tomcat-7.0.35-windows-x86 ClassNotFoundException: org.apache.catalina.util.StringManager -- Key: MTOMCAT-204 URL: https://issues.apache.org/jira/browse/MTOMCAT-204 Project: Apache Tomcat Maven Plugin Issue Type: Question Components: tomcat7 Environment: Microsoft Windows XP Professionnel Version 2002 Sertvice Pack 3 Reporter: Alain Perreault Assignee: Olivier Lamy (*$^¨%`£) During deployment I get this exeption org.apache.catalina.core.ContainerBase addChildInternalOrg.apache.cata GRAVE: ContainerBase addChild: start: org.apache.catalinaLifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/MyServer]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java 154) ... Caused by: java.lang.NoClassDefFoundError: Lorg/apache/catalina/util/StringManager; at java.lang.Class.getDeclaredFieldFields0(Native Method) at java.lang.Class.privateGetDeclaredFields (Unknown Source) at java.lang.Class.getDeclaredFields (Unknown Source) at org.apache.catalina.util.Introspection.getDeclaredFields (Introspection.java:106) ... Caused by: java.lang.ClassNotFoundException: org.apache.catalina.util.StringManager I used apache-tomcat-7.0.35-windows-x86 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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: svn commit: r1440097 - /tomcat/tc6.0.x/trunk/STATUS.txt
2013/1/30 ma...@apache.org: Author: markt Date: Tue Jan 29 20:18:51 2013 New Revision: 1440097 URL: http://svn.apache.org/viewvc?rev=1440097view=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=1440097r1=1440096r2=1440097view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Jan 29 20:18:51 2013 @@ -112,6 +112,12 @@ PATCHES PROPOSED TO BACKPORT: +1: schultz -1: +* Better error reporting id context.xml cannot be parsed + http://svn.apache.org/viewvc?rev=1440096view=rev + +1: markt + -1: Looking at where digester.parse(..) is called in HostConfig in Tomcat 6, there is no need for this patch. There is wider try/catch(Throwable) around there that already prints the exception. The local try/catch(Exception) that you fixed was added to implement FailedContext and that feature was not backported to Tomcat 6. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1440186 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Tue Jan 29 22:24:33 2013 New Revision: 1440186 URL: http://svn.apache.org/viewvc?rev=1440186view=rev Log: Unnecessary 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=1440186r1=1440185r2=1440186view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Jan 29 22:24:33 2013 @@ -112,11 +112,6 @@ PATCHES PROPOSED TO BACKPORT: +1: schultz -1: -* Better error reporting id context.xml cannot be parsed - http://svn.apache.org/viewvc?rev=1440096view=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
Re: svn commit: r1440096 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/startup/HostConfig.java webapps/docs/changelog.xml
2013/1/30 ma...@apache.org:
Author: markt
Date: Tue Jan 29 20:17:59 2013
New Revision: 1440096
URL: http://svn.apache.org/viewvc?rev=1440096view=rev
Log:
Include the exception in the error message
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/HostConfig.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1440095
} catch (Exception e) {
log.error(sm.getString(
hostConfig.deployDescriptor.error,
-contextXml.getAbsolutePath()));
+contextXml.getAbsolutePath()), e);
context = new FailedContext();
} finally {
digester.reset();
digester.parse( is called in 4 places in HostConfig.java.
The other 3 need the same fix.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of GettingStarted by KonstantinKolinko
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The GettingStarted page has been changed by KonstantinKolinko: http://wiki.apache.org/tomcat/GettingStarted?action=diffrev1=15rev2=16 Comment: Correct links. Remove link to a tutorial that uses Tomcat 4.1. TableOfContents == Getting your first webapp up and running == - * [[http://tomcat.apache.org/tomcat-6.0-doc/appdev/index.html|Introduction in the Application Developer Guide]] + * [[http://tomcat.apache.org/tomcat-7.0-doc/appdev/index.html|Introduction in the Application Developer Guide]] - * [[http://tomcat.jaxmao.org/appdev/index.html|应用开发人员指南]] Chinese translation of the Application Developer Guide + * [[http://tomcat.jaxmao.org/appdev/index.html|应用开发人员指南]] Chinese translation of the Application Developer Guide (warning: it is for Tomcat 5, which is an old and unsupported version) - * [[http://keyboardsamurais.de/2004/01/15/tomcat_tutorial_helloworld_for_complete_fools_-_english/ | Tomcat servlet tutorial ]] A quite good tutorial, even though it is a very simple example. == Useful links == * HowTo - Some how-tos assembled here * [[http://benhutchison.wordpress.com/2008/07/30/how-to-configure-tomcat-root-context/#comment-336]] How to make tomcat serve content from www.exampledomain.com instead of www.exampledomain.com/examplewebapp. Basically, just make a directory inside tomcat's webapps directory called ROOT and your content will be served to the root domain www.exampledomain.com. - * [[http://bitnami.org/stack/tomcatstack|BitNami Tomcat Stack]]: Provides an all-in-one installer, free virtual machines and cloud images for Tomcat. + * [[http://bitnami.org/stack/tomcat|BitNami Tomcat Stack]]: Provides an all-in-one installer, free virtual machines and cloud images for Tomcat. - * [[http://www.turnkeylinux.org/appliances/tomcat|TurnKey Tomcat Appliance]]: Open source installable Live CD based on Ubuntu. Features minimal footprint, automatic security updates, SSL support and an elegant Web administration interface. + * [[http://www.turnkeylinux.org/tomcat|TurnKey Tomcat Appliance]]: Open source installable Live CD based on Ubuntu. Features minimal footprint, automatic security updates, SSL support and an elegant Web administration interface. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of GettingStarted by KonstantinKolinko
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The GettingStarted page has been changed by KonstantinKolinko: http://wiki.apache.org/tomcat/GettingStarted?action=diffrev1=16rev2=17 Comment: Link to our FAQ. * [[http://tomcat.jaxmao.org/appdev/index.html|应用开发人员指南]] Chinese translation of the Application Developer Guide (warning: it is for Tomcat 5, which is an old and unsupported version) == Useful links == - * HowTo - Some how-tos assembled here + * [[HowTo]] mdash; Some how-tos assembled here - * [[http://benhutchison.wordpress.com/2008/07/30/how-to-configure-tomcat-root-context/#comment-336]] How to make tomcat serve content from www.exampledomain.com instead of www.exampledomain.com/examplewebapp. Basically, just make a directory inside tomcat's webapps directory called ROOT and your content will be served to the root domain www.exampledomain.com. + * [[HowTo#How_do_I_make_my_web_application_be_the_Tomcat_default_application.3F|How To / How do I make my web application be the Tomcat default application?]] mdash; How to make tomcat serve content from www.exampledomain.com instead of www.exampledomain.com/examplewebapp. Basically, just make a directory inside tomcat's webapps directory called ROOT and your content will be served to the root domain www.exampledomain.com. * [[http://bitnami.org/stack/tomcat|BitNami Tomcat Stack]]: Provides an all-in-one installer, free virtual machines and cloud images for Tomcat. * [[http://www.turnkeylinux.org/tomcat|TurnKey Tomcat Appliance]]: Open source installable Live CD based on Ubuntu. Features minimal footprint, automatic security updates, SSL support and an elegant Web administration interface. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of HowTo by KonstantinKolinko
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Tomcat Wiki for change
notification.
The HowTo page has been changed by KonstantinKolinko:
http://wiki.apache.org/tomcat/HowTo?action=diffrev1=119rev2=120
Comment:
Remove suggestion of replacing the default servlet. It is irrelevant to the
issue. Correct links.
Just by doing this, you have already made you webapp into the Tomcat
''default webapp''.
- One step is left : you also need to have, within your application, a
''default servlet''. If you don't want to use the standard one supplied by
Tomcat that does nothing but deliver static content, you'll need to supply one
of your own. This you do by means of an appropriate url-mapping in the
WEB-INF/web.xml configuration file of your application. Make sure you have
something like this in that file:
-
- {{{
-servlet
- servlet-nameMy First Servlet/servlet-name
- servlet-classmy.Servlet.Number1/servlet-class
- /servlet
-
- servlet-mapping
- servlet-nameMy First Servlet/servlet-name
- url-pattern/*/url-pattern
- /servlet-mapping
- }}}
- The above will override the mapping for Tomcat's DefaultServlet in the global
conf/web.xml file.
-
Restart Tomcat and you're done.BR Call up http://myhost.company.com/;
and enjoy.
'''Addendum 1 : If you are deploying your application as a war file..'''
The above instructions relate to the situation where you are manually
deploying your application as a directory-and-files structure under the
/webapps directory. If instead you are using the war method to deploy your
application, the principle is about the same :BR - delete the ROOT
directoryBR - name your war file ROOT.war (capitals mandatory)BR -
drop the ROOT.war file directly in the /webapps directory.BR Tomcat will
automatically deploy it.
- For more information about this topic in general, consult this page :
[[http://tomcat.apache.org/tomcat-6.0-doc/config/context.html|The Context
Container]]
+ For more information about this topic in general, consult this page :
[[http://tomcat.apache.org/tomcat-7.0-doc/config/context.html|Configuration
Reference / Context]]
'''Addendum 2 : If for some reason you want another method..'''
- If, for some reason, you do not want to deploy your application under the
CATALINA_BASE/webapps/ROOT subdirectory, or you do not want to name your
war-file ROOT.war, then read on. But you should first read this :
[[http://tomcat.apache.org/tomcat-6.0-doc/config/context.html|The Context
Container]] and make sure you understand the implications.
+ If, for some reason, you do not want to deploy your application under the
CATALINA_BASE/webapps/ROOT subdirectory, or you do not want to name your
war-file ROOT.war, then read on. But you should first read this :
[[http://tomcat.apache.org/tomcat-7.0-doc/config/context.html|Configuration
Reference / Context]] and make sure you understand the implications.
The method described above is the simple method. The two methods below are
more complex, and the second one has definite implications on the way you
manage and run your Tomcat.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Trivial Update of FAQ by KonstantinKolinko
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The FAQ page has been changed by KonstantinKolinko: http://wiki.apache.org/tomcat/FAQ?action=diffrev1=57rev2=58 Comment: Correct wording * [[UsefulLinks|Other Resources]] - A lot of links to tomcat related documentation and experiences. * [[/Performance_and_Monitoring|Performance Monitoring]] - Performance Monitoring questions. * [[/Security|Security]] - Common security issues. - * [[/Tomcat_User|Tomcat User]] - More information about the tomcat-user list. + * [[/Tomcat_User|Tomcat User]] - More information about the tomcat-user mailing list. * [[/Troubleshooting_and_Diagnostics|Troubleshooting Diagnostics]] - Tools and techniques for diagnosing problems. * [[TomcatVersions|Version]] - About the different tomcat versions. * [[../Tomcat/WebDav|WebDav]] - Questions on using Tomcat Webdav servlet. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of FAQ/CharacterEncoding by KonstantinKolinko
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Tomcat Wiki for change
notification.
The FAQ/CharacterEncoding page has been changed by KonstantinKolinko:
http://wiki.apache.org/tomcat/FAQ/CharacterEncoding?action=diffrev1=21rev2=22
Comment:
Correct links. s/6.0/7.0/
1. Set the `URIEncoding` attribute on the Connector element in server.xml
to something specific (e.g. `URIEncoding=UTF-8`).
1. Set the `useBodyEncodingForURI` attribute on the Connector element in
server.xml to `true`. This will cause the Connector to use the request body's
encoding for GET parameters.
- References: [[http://tomcat.apache.org/tomcat-6.0-doc/config/http.html|Tomcat
6 HTTP Connector]],
[[http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html|Tomcat 6 AJP
Connector]]
+ References: [[http://tomcat.apache.org/tomcat-7.0-doc/config/http.html|Tomcat
7 HTTP Connector]],
[[http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html|Tomcat 7 AJP
Connector]]
BR
@@ -117, +117 @@
In order to completely switch to using UTF-8, you need to make the following
changes:
- 1. Set {{{URIEncoding=UTF-8}}} on your Connector in `server.xml`.
References: [[http://tomcat.apache.org/tomcat-6.0-doc/config/http.html|HTTP
Connector]], [[http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html|AJP
Connector]].
+ 1. Set {{{URIEncoding=UTF-8}}} on your Connector in `server.xml`.
References: [[http://tomcat.apache.org/tomcat-7.0-doc/config/http.html|HTTP
Connector]], [[http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html|AJP
Connector]].
1. Use a [[#Q3|character encoding filter]] with the default encoding set to
UTF-8
1. Change all your JSPs to include charset name in their contentType.
For example, use {{{%@page contentType=text/html; charset=UTF-8 %}}} for
the usual JSP pages and {{{jsp:directive.page contentType=text/html;
charset=UTF-8 /}}} for the pages in XML syntax (aka JSP Documents).
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of FAQ/Class_Not_Found by KonstantinKolinko
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Tomcat Wiki for change
notification.
The FAQ/Class_Not_Found page has been changed by KonstantinKolinko:
http://wiki.apache.org/tomcat/FAQ/Class_Not_Found?action=diffrev1=13rev2=14
Comment:
Correct file names.
This page discusses the various ways you see Class Not Found errors or very
similar errors. It is strongly advised you read the following topics:
- * Classloader HOWTO pages:
[[http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html|Tomcat 7.0]],
[[http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html|Tomcat 6.0]],
[[http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html|Tomcat 5.5]].
+ * Classloader HOWTO pages:
[[http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html|Tomcat 7.0]],
[[http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html|Tomcat 6.0]].
* [[http://marc.info/?t=10431752924r=1w=2|Don't]]
[[http://marc.info/?t=10438044013r=1w=2|use]]
[[http://marc.info/?t=9694765692r=1w=2|packageless]]
[[http://marc.info/?t=10449102012r=1w=2|classes]]
[[http://marc.info/?t=10426557623r=1w=2|and]]
[[http://marc.info/?t=10424974831r=1w=2|declare]]
[[http://marc.info/?t=10299695013r=1w=2|all]]
[[http://marc.info/?t=10292218941r=1w=2|imported classes]]!
* [[http://marc.info/?l=tomcat-userm=103843452413727w=2|Another answer to
a classloader issue]]
@@ -28, +28 @@
Anchor(Q2)'''Why do I get {{{ java.lang.NoClassDefFoundError:
javax/servlet/Filter}}}?'''
- You probably have servlet.jar floating around somewhere it shouldn't be. This
really messes up the classloaders since Tomcat's classloaders don't act quite
as normal as one expects (see links above). servlet.jar should only be found
only once in $CATALINA_HOME/common/lib.
+ You probably have servlet-api.jar floating around somewhere it shouldn't be.
This really messes up the classloaders since Tomcat's classloaders don't act
quite as normal as one expects (see links above). servlet-api.jar should only
be found only once in $CATALINA_HOME/lib.
Anchor(Q3)'''Why do I get {{{ java.lang.NoClassDefFoundError:
org/xml/sax/InputSource }}}?'''
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of FAQ/Connectors by KonstantinKolinko
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The FAQ/Connectors page has been changed by KonstantinKolinko: http://wiki.apache.org/tomcat/FAQ/Connectors?action=diffrev1=15rev2=16 Comment: Correct links. s/6.0/7.0/ Anchor(Q6)'''How do I bind to a specific ip address?''' - Each Connector element allows an `address` property. See the [[http://tomcat.apache.org/tomcat-6.0-doc/config/http.html|HTTP Connector docs]] or the [[http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html|AJP Connector docs]]. + Each Connector element allows an `address` property. See the [[http://tomcat.apache.org/tomcat-7.0-doc/config/http.html|HTTP Connector docs]] or the [[http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html|AJP Connector docs]]. BR - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of FAQ/Database by KonstantinKolinko
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The FAQ/Database page has been changed by KonstantinKolinko: http://wiki.apache.org/tomcat/FAQ/Database?action=diffrev1=5rev2=6 Comment: Correct links. s/6.0/7.0/ Other Links of interest: - * [[http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html|JNDI Datasource HOW-TO]] + * [[http://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html|JNDI Datasource HOW-TO]] Other notes: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of FAQ/Developing by KonstantinKolinko
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The FAQ/Developing page has been changed by KonstantinKolinko: http://wiki.apache.org/tomcat/FAQ/Developing?action=diffrev1=15rev2=16 Comment: Correct links. s/6.0/7.0/ Anchor(Q4) How do I change the monitoring interval for modified resources and application reloading? - Monitoring interval for application reloading is controlled by the `backgroundProcessorDelay` property on `Context` element or on its parent containers: `Host` and `Engine`. See [[http://tomcat.apache.org/tomcat-6.0-doc/config/index.html|Tomcat Configuration Reference]] for details. By default there is a single background processing thread that is run by Engine. See its [[http://tomcat.apache.org/tomcat-6.0-doc/config/engine.html|configuration]] for the default delay value. + Monitoring interval for application reloading is controlled by the `backgroundProcessorDelay` property on `Context` element or on its parent containers: `Host` and `Engine`. See [[http://tomcat.apache.org/tomcat-7.0-doc/config/index.html|Tomcat Configuration Reference]] for details. By default there is a single background processing thread that is run by Engine. See its [[http://tomcat.apache.org/tomcat-7.0-doc/config/engine.html|configuration]] for the default delay value. - Interval that controls reloading of the changed JSP pages is set in the [[http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html|Jasper configuration]] in `web.xml`. + Interval that controls reloading of the changed JSP pages is set in the [[http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html|Jasper configuration]] in `web.xml`. - [[CategoryFAQ|CategoryFAQ]] + [[CategoryFAQ]] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On Mon, Jan 28, 2013 at 3:46 AM, Mark Thomas ma...@apache.org wrote: On 26/01/2013 21:51, Henri Yandell wrote: On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes jer...@boynes.com wrote: On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: Regarding the two taglibs that are not yet in the attic, I have no interest in RDC taglib, but I am interested in JSTL one. +1 I think once we make the first release, things should go easier after that. A few notes after quick review of the sources: 1. Can we go up from Java 5 and require/use at least Java 6 to build the project? I am even OK to be brave and go up to Java 7. I do not like Java 5, because a) It is outdated. It would be strange for a new project to use that if we are going to support it for long. b) It is not opensource. OpenJDK is since Java 6. The version of Java is important for this class, that implements javax.sql.DataSource: \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java Java 7 will allow us to support a later version of JDBC and will allow this project to build on Gump. There is also an issue with the I18N tags taking a long time to start on a Java6 platform due to changes in the way Locales are located by the JRE. I remember some discussion on fixing this but a requirement to stay on Java 5 meant having to build two implementations and switch between them which I'd planned to do once a release was out. If we pre-req 6 or 7 then the implementation can just be updated and this issue closed easier. Would the TCK pass if it was on Java 7? We are talking about Taglibs 1.2 right? (If not adjust versions below accordingly). Taglibs 1.2 requires JSP 2.1. JSP 2.1 requires Java 5 or later (as does Servlet 2.5 and J2EE 5). Based on that, I would say that the TCK has to pass when running on Java 5. /me goes looking for some TCK docs I've just checked the latest version of the TCK documentation for JSTL 1.2 and while the TCK has been updated so it will run on Java 7, the reference runtime remains Java 5. My interpretation of that is that the TCK must pass when running with a Java 5 JRE. We could use the Tomcat trick though. if(passTCKFlag) then do the no-one-wants option. Then by default it could run smoothly on JDK 7. I've vague memories that the SQL side of things makes that painful. Did you look at that Jeremy? Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54499] Implementation of Extensible EL Interpreter
https://issues.apache.org/bugzilla/show_bug.cgi?id=54499 --- Comment #5 from Sheldon Shao xs...@ebay.com --- Created attachment 29907 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29907action=edit Make id as public -- 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
[Tomcat Wiki] Trivial Update of MarcelaOl by MarcelaOl
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The MarcelaOl page has been changed by MarcelaOl: http://wiki.apache.org/tomcat/MarcelaOl New page: Got nothing to tell about myself at all.BRFeels good to be a part of apache.org.BRI just hope I am useful in some way here.BRBRmy web-site ... [[http://www.encuentrosleadership.org/member/611898/|browse around this web-site on online bachelors health information management degree]] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of LocalBadContent by ChuckCaldarale
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The LocalBadContent page has been changed by ChuckCaldarale: http://wiki.apache.org/tomcat/LocalBadContent?action=diffrev1=70rev2=71 easyday\.cn electronic-wire\.com elgg\.summervillecountryclub\.com + encuentrosleadership\.org envy\.nu erectiledysfunctiontreatment\.org eseo\.cn - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On Jan 28, 2013, at 3:46 AM, Mark Thomas wrote: On 26/01/2013 21:51, Henri Yandell wrote: On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes jer...@boynes.com wrote: On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: There is also an issue with the I18N tags taking a long time to start on a Java6 platform due to changes in the way Locales are located by the JRE. I remember some discussion on fixing this but a requirement to stay on Java 5 meant having to build two implementations and switch between them which I'd planned to do once a release was out. If we pre-req 6 or 7 then the implementation can just be updated and this issue closed easier. Would the TCK pass if it was on Java 7? We are talking about Taglibs 1.2 right? (If not adjust versions below accordingly). Taglibs 1.2 requires JSP 2.1. JSP 2.1 requires Java 5 or later (as does Servlet 2.5 and J2EE 5). Based on that, I would say that the TCK has to pass when running on Java 5. /me goes looking for some TCK docs I've just checked the latest version of the TCK documentation for JSTL 1.2 and while the TCK has been updated so it will run on Java 7, the reference runtime remains Java 5. My interpretation of that is that the TCK must pass when running with a Java 5 JRE. My interpretation was that a product must pass the TCK in all its configurations. In other words, you can't claim compatibility on Java7 unless you've tested on Java7. If we test on Java7 and pass, we can claim we're a compatible implementation in that mode; if we don't test on Java5 then we can't claim compatibility on Java5 but that does not stop us being compatible on Java7. I read it as being sufficient if we document what we require as a resource. @Henri, I ran all tests on Java6 and have not tried SQL on Java7. I'll pull the newer version and retest. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
