Re: [Proposal] Remove older of the two BIO AJP connectors
> It's disturbing that you fail to mention Geronimo altogether. If we can't > have cohesion within the ASF - you expect to create it externally? It wasn't a list of J2EE engine but a list of applications/corps who drive Tomcat life. And Geronimo didn't take/fork/guide Tomcat isn't it ? :) >> That's my wishes for Tomcat, not just code, bits and specs compliance, >> but recreate a new wider commiters/contributors community. > > It takes outreach to make that happen. Mark isn't offbase, keep posting > your wishes here, but if you want to make it happen, engage these other > communities. I could engage but there should be an acceptance here. I couldn't attract Mina/Felix people and got a veto here, it will be unfair and unproductive for other commuties. I call for openess and if it receive a positive feedback here, we could next contact others ASF projects. > The ASF isn't about being the only code solution. It's about collaboration > to create what the active developers determine is the best solution. If > anything is lacking in Tomcat, address it, and work with others to address > it, but certainly don't spend your time wishing things were otherwise. Yes ASF is not the only solution, but with the rich apis/tools/peoples in various ASF projects, it seems to me more elegant and pragmatic to involve ASFers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
>> It's disturbing that you fail to mention Geronimo altogether. If we can't >> have cohesion within the ASF - you expect to create it externally? >> > > I think that where Henri is going is that Tomcat has always been dependant > on corporate sponsorship. First on Sun (who forked the code to GlassFish), > then on JBoss (whom I understand from messages on the list has forked as > well), and currently on SpringSource. Geronimo has historically considered > Tomcat as a poor cousin ;), and preferred Jetty. Admittedly that has > changed recently, and we're getting more patch submissions from Geronimo. > But AFAIK, there are still no committers to both Tomcat and Geronimo. Right Bill. And I wonder why Geronimo, OSGI, Eclipse or GWT select Jetty ? It's a good product but may be it's more attractive and open to newcomers ? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. It takes outreach to make that happen. Mark isn't offbase, keep posting your wishes here, but if you want to make it happen, engage these other communities. I could engage but there should be an acceptance here. I couldn't attract Mina/Felix people and got a veto here, it will be unfair and unproductive for other commuties. I call for openess and if it receive a positive feedback here, we could next contact others ASF projects. I doubt you will get veto if this starts as module project that can be used as drop-in component without changing the overall API. The guys from MINA even use our tomcat native for high performance polling, so it's natural in a way to cooperate more closely. We can use two current BIO connectors as part of the core, and see how MINA can be used for async connectors. Since it supports both Java NIO and Tomcat Native, it's just cooperating with the guys and see what we would need to use it more effectively (and how at the first place :) Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
> I doubt you will get veto if this starts as module project > that can be used as drop-in component without changing the > overall API. > > The guys from MINA even use our tomcat native for high > performance polling, so it's natural in a way to cooperate > more closely. > > We can use two current BIO connectors as part of the core, > and see how MINA can be used for async connectors. > Since it supports both Java NIO and Tomcat Native, it's > just cooperating with the guys and see what we would need > to use it more effectively (and how at the first place :) Thanks Mladen, happy to get a such positive feedback ! Under Tomcat umbrella we have now : - a Servlet container - an Apache/IIS connector (jk) - a native connector First guess, but I may be wrong, why not split in 3 projects ? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: I doubt you will get veto if this starts as module project that can be used as drop-in component without changing the overall API. Under Tomcat umbrella we have now : - a Servlet container - an Apache/IIS connector (jk) - a native connector First guess, but I may be wrong, why not split in 3 projects ? Don't think that's a smart way to move right now because a) We simply don't have resources (community) for that. However at least part of the native connector could in the future go somewhere else (commons probably). I'm trying to create one or two commons projects that would allow more easier java/native integration, and if someone creates a workable MINA based connector, native is already in there. JK is different, because we still don't know which way to go in the future. If we came up with something bright and shiny like JK3, and create enough community we could ask for a TLP status and move the 1.2 native code to that new project, leaving tomcat to what it essentially is (servlet container) Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r761581 - in /tomcat/site/trunk: docs/bugreport.html xdocs/bugreport.xml
Author: markt Date: Fri Apr 3 09:35:17 2009 New Revision: 761581 URL: http://svn.apache.org/viewvc?rev=761581&view=rev Log: Fix broken irc link reported on dev list Modified: tomcat/site/trunk/docs/bugreport.html tomcat/site/trunk/xdocs/bugreport.xml Modified: tomcat/site/trunk/docs/bugreport.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/bugreport.html?rev=761581&r1=761580&r2=761581&view=diff == --- tomcat/site/trunk/docs/bugreport.html (original) +++ tomcat/site/trunk/docs/bugreport.html Fri Apr 3 09:35:17 2009 @@ -380,7 +380,7 @@ #tomcat at irc.us.openprojects.net. -Click here to +Click here to connect to the channel using Mozilla. Modified: tomcat/site/trunk/xdocs/bugreport.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/bugreport.xml?rev=761581&r1=761580&r2=761581&view=diff == --- tomcat/site/trunk/xdocs/bugreport.xml (original) +++ tomcat/site/trunk/xdocs/bugreport.xml Fri Apr 3 09:35:17 2009 @@ -101,7 +101,7 @@ An IRC channel dedicated to Apache Tomcat exists on OpenProjects. #tomcat at irc.us.openprojects.net. -Click here to +Click here to connect to the channel using Mozilla. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
On 27.03.2009 21:22, Mark Thomas wrote: > Mladen Turk wrote: >> Mark Thomas wrote: >>> All, >>> >>> I have been looking at trunk for opportunities to remove duplicate / >>> obsolete >>> code. We currently have two BIO AJP connectors: >>> - org.apache.jk.server.JkCoyoteHandler >>> - org.apache.coyote.ajp.AjpProtocol >>> >>> I would like to remove org.apache.jk.server.JkCoyoteHandler and >>> associated classes. >>> >>> What do folks think? >>> >> Ain't those used for 5.5? >> You can however just remove them from the build. >> Other option is to copy them to the 5.5 and not referencing >> the connectors for those set of classes. > > Sorry - should have been clear. I only meant in Tomcat 7. I didn't intend > changing 5.5.x or 6.0.x +1: I support removing org.apache.jk.server.JkCoyoteHandler from TC trunk (aka TC 7). I would be interested in any comments, what kind of feature or quality might still be missing in org.apache.coyote.ajp.AjpProtocol and help to implement them (if any). Rémy, others: are there improvements that should be done to this connector? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat website IRC address
Photodeus wrote: > Hello, > as I was reading on how to submit a bug report, I noticed that the page > http://tomcat.apache.org/bugreport.html links to a non-existing IRC server. > > On the left hand side navigation there's a separate link to Freenode, so the > broken link should be removed. > Didn't seem appropriate to open up a full bug report for such a minor thing. Fixed. It will take an hour or so to sync to the mirrors. Thanks for reporting it. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r761601 - in /tomcat/trunk/java/org/apache: catalina/servlets/WebdavServlet.java naming/resources/FileDirContext.java
Author: markt
Date: Fri Apr 3 10:28:40 2009
New Revision: 761601
URL: http://svn.apache.org/viewvc?rev=761601&view=rev
Log:
Fix a handful of failures when using the litmus WebDAV testsuite.
Still other failures but these appear to relate to the lack of PROPPATCH
support.
Modified:
tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java
tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java
Modified: tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java?rev=761601&r1=761600&r2=761601&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java (original)
+++ tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java Fri Apr
3 10:28:40 2009
@@ -19,6 +19,7 @@
package org.apache.catalina.servlets;
+import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.StringReader;
import java.io.StringWriter;
@@ -463,7 +464,7 @@
Node propNode = null;
-if (req.getInputStream().available() > 0) {
+if (req.getContentLength() > 0) {
DocumentBuilder documentBuilder = getDocumentBuilder();
try {
@@ -494,9 +495,11 @@
}
}
} catch (SAXException e) {
-// Something went wrong - use the defaults.
+// Something went wrong - bad request
+resp.sendError(WebdavStatus.SC_BAD_REQUEST);
} catch (IOException e) {
-// Something went wrong - use the defaults.
+// Something went wrong - bad request
+resp.sendError(WebdavStatus.SC_BAD_REQUEST);
}
}
@@ -1662,14 +1665,20 @@
path, destinationPath);
if ((!result) || (!errorList.isEmpty())) {
-
-sendReport(req, resp, errorList);
+if (errorList.size() == 1) {
+resp.sendError(errorList.elements().nextElement().intValue());
+} else {
+sendReport(req, resp, errorList);
+}
return false;
-
}
// Copy was successful
-resp.setStatus(WebdavStatus.SC_CREATED);
+if (exists) {
+resp.setStatus(WebdavStatus.SC_NO_CONTENT);
+} else {
+resp.setStatus(WebdavStatus.SC_CREATED);
+}
// Removing any lock-null resource which would be present at
// the destination path
@@ -1739,9 +1748,15 @@
try {
resources.bind(dest, object);
} catch (NamingException e) {
-errorList.put
-(source,
- new Integer(WebdavStatus.SC_INTERNAL_SERVER_ERROR));
+if (e.getCause() instanceof FileNotFoundException) {
+// We know the source exists so it must be the
+// destination dir that can't be found
+errorList.put(source,
+new Integer(WebdavStatus.SC_CONFLICT));
+} else {
+errorList.put(source,
+new
Integer(WebdavStatus.SC_INTERNAL_SERVER_ERROR));
+}
return false;
}
} else {
Modified: tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java?rev=761601&r1=761600&r2=761601&view=diff
==
--- tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java (original)
+++ tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java Fri Apr
3 10:28:40 2009
@@ -578,8 +578,10 @@
is.close();
}
} catch (IOException e) {
-throw new NamingException
-(sm.getString("resources.bindFailed", e));
+NamingException ne = new NamingException
+(sm.getString("resources.bindFailed", e));
+ne.initCause(e);
+throw ne;
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r761602 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Fri Apr 3 10:31:09 2009 New Revision: 761602 URL: http://svn.apache.org/viewvc?rev=761602&view=rev Log: Propose some WebDAV fixes 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=761602&r1=761601&r2=761602&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Apr 3 10:31:09 2009 @@ -209,3 +209,8 @@ +1: remm, rjung -1: + +* Fix some failures when testing WebDAV with litmus test suite + http://svn.apache.org/viewvc?view=rev&revision=761601 + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r761606 - /tomcat/current/tc5.5.x/STATUS.txt
Author: markt Date: Fri Apr 3 10:41:25 2009 New Revision: 761606 URL: http://svn.apache.org/viewvc?rev=761606&view=rev Log: Propose webdav fixes backport Modified: tomcat/current/tc5.5.x/STATUS.txt Modified: tomcat/current/tc5.5.x/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS.txt?rev=761606&r1=761605&r2=761606&view=diff == --- tomcat/current/tc5.5.x/STATUS.txt (original) +++ tomcat/current/tc5.5.x/STATUS.txt Fri Apr 3 10:41:25 2009 @@ -205,3 +205,8 @@ from OACC to tc5.5.x. +1: rjung -1: + +* Fix some litmus test suite failures with WebDAV + http://people.apache.org/~markt/patches/2009-04-03-webdav.patch + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GSOC] Filters & Async Support in Servlet 3.0
anas Ahmed wrote: > Hello all, > As i have read from Servlet 3.0 specification about filters "A Filter and > the target servlet or resource at the end of the filter chain must execute in > the same invocation thread". > > This mean if there are many Async Requests which are connected to filters, > many filters will be init but not destroyed until response come back or > filter work finish. My understanding is that the filter processing in the outbound direction will take place after the Servlet completes (without generating a response). The filters will not have to wait until the Async processing completes. However, any wrappers they put in place may have to remain until the async processing completes. > As we know Tomcat uses thread per request through Java NIO. Tomcat uses one thread per request for BIO, NIO and APR/native. The differences are with connections where BIO uses 1 thread per connection (including those in keep-alive) whereas NIO and APR/native use polling threads that each maintain a number of connections. > More simultaneous requests(connected to filters) cause more threads to be > consumed, More concurrent requests does equal more threads but the number of filters is not a factor. > which cancels out the benefit of the thread-per-request approach to a high > degree. Given the number of filters is not a factor, I don't think this is the case. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
GSOC: Convert current Tomcat valves to Servlet Filters
Hello, Dear All, After Mark's valuable comments, I revised my proposal according to your comments, and added the deliverables and time schedule part. Any more comments, feedback and criticism to my proposal are welcomed. -- Sincerely yours and Best Regards, Xie Xiaodong
Re: [Proposal] Remove older of the two BIO AJP connectors
On Fri, 2009-04-03 at 11:20 +0200, Rainer Jung wrote: > Rémy, others: are there improvements that should be done to this connector? This is AJP, and the connector is made up from creative cut & pasting. So it could be missing stuff. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GSOC] Feedback on my project proposal "Improve the JMX support within Apache Tomcat"
hello Dear all, i have posted my proposal for "Improve the JMX support within Apache Tomcat". please give your comments and suggestions. Thanks Anas Ahmed _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_042009
svn commit: r761682 - /tomcat/current/tc5.5.x/STATUS.txt
Author: pero Date: Fri Apr 3 13:59:57 2009 New Revision: 761682 URL: http://svn.apache.org/viewvc?rev=761682&view=rev Log: Cast my Vote Modified: tomcat/current/tc5.5.x/STATUS.txt Modified: tomcat/current/tc5.5.x/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS.txt?rev=761682&r1=761681&r2=761682&view=diff == --- tomcat/current/tc5.5.x/STATUS.txt (original) +++ tomcat/current/tc5.5.x/STATUS.txt Fri Apr 3 13:59:57 2009 @@ -172,7 +172,7 @@ the remote port. Backport of http://svn.apache.org/viewvc?rev=756926&view=rev and http://svn.apache.org/viewvc?rev=757223&view=rev - +1: rjung, markt + +1: rjung, markt, pero -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026 @@ -180,7 +180,7 @@ Part 2 of the backport proposed and approved above (r697183), now also for the other AJP connectors. http://svn.apache.org/viewvc?rev=757721&view=rev - +1: rjung, markt + +1: rjung, markt, pero -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=41606 @@ -203,7 +203,7 @@ For details see the log messages of r759694. Port of http://svn.apache.org/viewvc?rev=759694&view=rev from OACC to tc5.5.x. - +1: rjung + +1: rjung, pero -1: * Fix some litmus test suite failures with WebDAV - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46961] New: org.apache.catalina.loader.WebappClassLoader throws exception related to Java 6 Bug 6434149
https://issues.apache.org/bugzilla/show_bug.cgi?id=46961
Summary: org.apache.catalina.loader.WebappClassLoader throws
exception related to Java 6 Bug 6434149
Product: Tomcat 5
Version: 5.5.27
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: eduardo.torres-pa...@infor.com
Our application uses JSF. Upon defining navigation with NavigationRuleRule, we
get the exception
WARN NavigationRuleRule - [NavigationRuleRule]{faces-config/navigation-rule}
Me
rge(*)
java.lang.ClassNotFoundException: [Ljava.lang.String;
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1352)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1198)
at
com.sun.faces.config.ConfigureListener.configure(ConfigureListener.ja
va:615)
at
com.sun.faces.config.ConfigureListener.configure(ConfigureListener.ja
va:402)
at
com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureLi
stener.java:328)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContex
t.java:3729)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4
187)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442
)
at org.apache.catalina.startup.Embedded.start(Embedded.java:821)
This is due to Java 6 Bug 6434149
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434149)
This link recommends the following actions to solve this bug:
1) Add -Dsun.lang.ClassLoader.allowArraySyntax=true if you want to use a
library for which you don't have the source with JDK6
2) Change loader.loadClass( name ) to Class.forName( name, false, loader ) if
you own the code.
class org.apache.catalina.loader.WebAppClassLoader
uses this code to load classes:
clazz = loader.loadClass(name);
Can you please change the sections of code where this line is used (1352 and
others) to
clazz = Class.forName( name, false, loader);
so this problem is solved?
Thanks
--
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: [Proposal] Remove older of the two BIO AJP connectors
+1 on removing from trunk. IMHO AJP as a protocol is a dead end - it is not worth extending, and certainly not worth creating a new protocol. We need to pick one of thrift/protobuf/hessian for marshaling, and start doing some mux-ing in the protocol. If we end up using MINA or some other RPC - all the better, as long as it has a decent native side. Costin On Fri, Apr 3, 2009 at 2:20 AM, Rainer Jung wrote: > On 27.03.2009 21:22, Mark Thomas wrote: > > Mladen Turk wrote: > >> Mark Thomas wrote: > >>> All, > >>> > >>> I have been looking at trunk for opportunities to remove duplicate / > >>> obsolete > >>> code. We currently have two BIO AJP connectors: > >>> - org.apache.jk.server.JkCoyoteHandler > >>> - org.apache.coyote.ajp.AjpProtocol > >>> > >>> I would like to remove org.apache.jk.server.JkCoyoteHandler and > >>> associated classes. > >>> > >>> What do folks think? > >>> > >> Ain't those used for 5.5? > >> You can however just remove them from the build. > >> Other option is to copy them to the 5.5 and not referencing > >> the connectors for those set of classes. > > > > Sorry - should have been clear. I only meant in Tomcat 7. I didn't intend > > changing 5.5.x or 6.0.x > > +1: I support removing org.apache.jk.server.JkCoyoteHandler from TC > trunk (aka TC 7). > > I would be interested in any comments, what kind of feature or quality > might still be missing in org.apache.coyote.ajp.AjpProtocol and help to > implement them (if any). > > Rémy, others: are there improvements that should be done to this connector? > > Regards, > > Rainer > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [Proposal] Remove older of the two BIO AJP connectors
Costin Manolache wrote: +1 on removing from trunk. IMHO AJP as a protocol is a dead end - it is not worth extending, Agreed. It has to many limitations to satisfy the modern webserver/backend connector. and certainly not worth creating a new protocol. We need to pick one of thrift/protobuf/hessian for marshaling, and start doing some mux-ing in the protocol. All those framework you mention are just helpers for *building* the custom protocol. They actually mandate that we will have one but now hidden inside some IDL language description. Any such framework makes almost impossible to change the protocol specification while preserving backward compatibility (One huge problem why AJP is not usable any more) I'm kind of more fun of http://www.wsgi.org/wsgi/ At least it's human readable and already working :) Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
On Fri, Apr 3, 2009 at 10:24 AM, Mladen Turk wrote: > Costin Manolache wrote: > >> +1 on removing from trunk. >> >> IMHO AJP as a protocol is a dead end - it is not worth extending, >> > > Agreed. It has to many limitations to satisfy the > modern webserver/backend connector. > > and certainly not >> worth creating a new protocol. We need to pick one of >> thrift/protobuf/hessian for >> marshaling, and start doing some mux-ing in the protocol. >> > > All those framework you mention are just helpers for > *building* the custom protocol. They actually mandate > that we will have one but now hidden inside some IDL > language description. Any such framework makes > almost impossible to change the protocol specification > while preserving backward compatibility > (One huge problem why AJP is not usable any more) You preserve backward compat by keeping the protocol stable and supporting all methods you define in the IDL. What is needed is bi-directional communication between web server and tomcat - so you can do all the extensions on the list. The stability of the actual method definition is probably more important than the protocol itself - if we start using an IDL, it is even possible to expose the methods over multiple protocols if there is a compelling reason. > > > I'm kind of more fun of > http://www.wsgi.org/wsgi/ > > At least it's human readable and already working :) Well, the spec is not so human readable :-) - can you point me to the description of the communication protocol - i.e. the marshaling, framing, etc ? I don't mind 'human readable', or even supporting multiple formats. Are they multiplexing or request-waiting-response ? Do they already define methods for load balancing, etc ? If yes - sure, it's one valid option. Costin > > Regards > -- > ^(TM) > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
Please Help, I just tested my gwt app with RPC on host mode it works fine. When I deployed the app to Tomcat it does not work. I get the \ following message when the client issue a RPC call to the server: "The call failed on the server; see server log for details\ " . When I looked at the logs of Tomcat I see the following error: Apr 3, 2009 2:05:00 PM org.apache.catalina.core.ApplicationContext log SEVERE: Exception while dispatching incoming RPC call java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.extract(ServerSerializationStreamReader.java:\ \ 610) at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.readInt(ServerSerializationStreamReader.java:\ \ 427) at com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamReader.prepareToRead(AbstractSerializationStreamRe\ \ ader.java:38) at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.prepareToRead(ServerSerializationStreamReader\ \ .java:382) at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:234) at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:162) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:85) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Below is the content of my web.xml file: http://java.sun.com/xml/ns/javaee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd";> AvlDispatch Application Application for Avl Dispatch System webmaster ad...@mycompany.com The EMAIL address of the administrator to whom questions and comments about this application should be addres\ \ sed. RemoteServices com.mycompany.teledispatch.avldispatch.server.RemoteServicesImpl RemoteServicesCompanies com.mycompany.teledispatch.avldispatch.server.RemoteServicesCompaniesImpl RemoteServicesDrivers com.mycompany.teledispatch.avldispatch.server.RemoteServicesDriversImpl RemoteServicesZones com.mycompany.teledispatch.avldispatch.server.RemoteServicesZonesImpl RemoteServices /RemoteServices RemoteServicesCompanies /RemoteServicesCompanies RemoteServicesDrivers /RemoteServicesDrivers RemoteServicesZones /RemoteServicesZones Mike. -- Oumar Ndiaye CTO ANTG Telecom www.antg.com ondi...@antg.com ondi...@alum.mit.edu ond4...@gmail.com Tel: +1-919-291-8742 -- Oumar Ndiaye CTO ANTG Telecom www.antg.com ondi...@antg.com ondi...@alum.mit.edu ond4...@gmail.com Tel: +1-919-291-8742
DO NOT REPLY [Bug 34110] The message "SEVERE: Error listenerStart" should be more explicit
https://issues.apache.org/bugzilla/show_bug.cgi?id=34110 --- Comment #4 from Dan Armbrust 2009-04-03 11:45:41 PST --- Created an attachment (id=23439) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23439) webapp which reproduces the error My comment #3 was missing a step that is required to reproduce this problem. You need to have log4j and commons-logging.jar in your war file to reproduce the issue. This war file will fail to deploy due to an invalid listener in tomcat 5.5.27, and fails to log the stack trace containing the cause of the problem anywhere. The only output given is: SEVERE: Error listenerStart SEVERE: Context [/a] startup failed due to previous errors After tomcat has expanded the warfile, if you rename webapps/a/WEB-INF/classes/log4j.properties.hidden to log4j.properties - then you will get a stack trace - but only because it has been sent to the logger within the webapp. It doesn't get sent to tomcats logging system. I don't understand why tomcat is changing how it logs, depending on if log4j and commons-logging are present in the classpath of a webapp being deployed. -- 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 34110] The message "SEVERE: Error listenerStart" should be more explicit
https://issues.apache.org/bugzilla/show_bug.cgi?id=34110 Dan Armbrust changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #5 from Dan Armbrust 2009-04-03 11:47:38 PST --- I believe my attachment should be enough to support reopening this bug. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
Hello, but I see your stacktrace ends with gwt, could you please check it first? Your stacktrace touches tomcat long before exception happens. 2009/4/3 oumar ndiaye > Please Help, > I just tested my gwt app with RPC on host mode it works fine. When I > deployed the app to Tomcat it does not work. I get the \ > following message when the client issue a RPC call to the server: "The call > failed on the server; see server log for details\ > " . > > When I looked at the logs of Tomcat I see the following error: > Apr 3, 2009 2:05:00 PM org.apache.catalina.core.ApplicationContext log > SEVERE: Exception while dispatching incoming RPC call > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 >at java.util.ArrayList.RangeCheck(ArrayList.java:547) >at java.util.ArrayList.get(ArrayList.java:322) >at > > com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.extract(ServerSerializationStreamReader.java:\ > \ > 610) >at > > com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.readInt(ServerSerializationStreamReader.java:\ > \ > 427) >at > > com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamReader.prepareToRead(AbstractSerializationStreamRe\ > \ > ader.java:38) >at > > com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.prepareToRead(ServerSerializationStreamReader\ > \ > .java:382) >at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:234) >at > > com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:162) >at > > com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:85) >at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) >at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) >at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) >at > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) >at > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) >at > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) >at > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) >at > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) >at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) >at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) >at > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) >at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) >at java.lang.Thread.run(Thread.java:619) > > Below is the content of my web.xml file: > > > > > http://java.sun.com/xml/ns/javaee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd";> > > AvlDispatch Application > Application for Avl Dispatch System > > > webmaster > ad...@mycompany.com > > The EMAIL address of the administrator to whom questions and > comments about this application should be addres\ \ > sed. > > > > > RemoteServices > > > com.mycompany.teledispatch.avldispatch.server.RemoteServicesImpl > > > > RemoteServicesCompanies > > > com.mycompany.teledispatch.avldispatch.server.RemoteServicesCompaniesImpl > > > > RemoteServicesDrivers > > > com.mycompany.teledispatch.avldispatch.server.RemoteServicesDriversImpl > > > > > RemoteServicesZones > > > com.mycompany.teledispatch.avldispatch.server.RemoteServicesZonesImpl > > > > > RemoteServices > /RemoteServices > > > > RemoteServicesCompanies > /RemoteServicesCompanies > > > > RemoteServicesDrivers > /RemoteServicesDrivers > > > > RemoteServicesZones > /RemoteServicesZones > > > > > Mike. > -- > Oumar Ndiaye > CTO > ANTG Telecom > www.antg.com > ondi...@antg.com > ondi...@alum.mit.edu > ond4...@gmail.com > Tel: +1-919-291-8742 > > > > > -- > Oumar Ndiaye > CTO > ANTG Telecom > www.antg.com > ondi...@antg.com > ondi...@alum.mit.edu > ond4...@gmail.com > Tel: +1-919-291-8742 > -- Sincerely yours and Best Regards, Xie Xiaodong
DO NOT REPLY [Bug 46965] New: Expression Language fails parsing a correct expression.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46965
Summary: Expression Language fails parsing a correct
expression.
Product: Tomcat 6
Version: 6.0.18
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: major
Priority: P2
Component: Jasper
AssignedTo: dev@tomcat.apache.org
ReportedBy: juanhernandezgo...@gmail.com
Hi,
If you create a JSP and paste the following expression Tomcat fails executing
it.
Test ${not(true)}
if you put a space between the "not" and "(" it works:
Test ${not (true)}
This worked in Tomcat 6.0.16 but not in Tomcat 6.0.18.
This the exception that you get when it fails.
Stacktrace:
at
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:505)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:416)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassCastException: java.lang.NullPointerException cannot
be cast to javax.el.ELException
at org.apache.el.lang.ExpressionBuilder.prepare(ExpressionBuilder.java:135)
at org.apache.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:147)
at
org.apache.el.lang.ExpressionBuilder.createValueExpression(ExpressionBuilder.java:190)
at
org.apache.el.ExpressionFactoryImpl.createValueExpression(ExpressionFactoryImpl.java:68)
at
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:924)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:54)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
... 15 more
Cheers
Juan
--
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 46965] Expression Language fails parsing a correct expression.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46965 Juan Hernandez changed: What|Removed |Added CC||juanhernandezgo...@gmail.co ||m -- 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 46965] Expression Language fails parsing a correct expression.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46965 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Mark Thomas 2009-04-03 15:26:56 PST --- *** This bug has been marked as a duplicate of bug 45511 *** -- 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 45511] EL "empty" keyword does not work
https://issues.apache.org/bugzilla/show_bug.cgi?id=45511 Mark Thomas changed: What|Removed |Added CC||juanhernandezgo...@gmail.co ||m --- Comment #7 from Mark Thomas 2009-04-03 15:26:56 PST --- *** Bug 46965 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46967] New: ManagerBase.setRandomFile error handling fix
https://issues.apache.org/bugzilla/show_bug.cgi?id=46967
Summary: ManagerBase.setRandomFile error handling fix
Product: Tomcat 6
Version: 6.0.18
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: k...@wolf-associates.com
On some platforms (z/OS for sure), the device file /dev/urandom can pass the
"f.exists()" test, but throws an IOException of some kind when trying to open
it. The current code in ManagerBase.setRandomFile() doesn't handle this, which
results in EVERY call to getRandom() to try again and log the error "Failed to
close randomIS".
The following changes to the method will add proper error handling to correct
this (my changes marked "// kjw")
public void setRandomFile( String s ) {
// as a hack, you can use a static file - and genarate the same
// session ids ( good for strange debugging )
if (Globals.IS_SECURITY_ENABLED){
randomIS = (DataInputStream)AccessController.doPrivileged(new
PrivilegedSetRandomFile());
} else {
try{
devRandomSource=s;
File f=new File( devRandomSource );
if( ! f.exists() ) return;
randomIS= new DataInputStream( new FileInputStream(f));
randomIS.readLong();
if( log.isDebugEnabled() )
log.debug( "Opening " + devRandomSource );
} catch( IOException ex ) {
log.debug("Error reading " + devRandomSource, ex); //kjw
if (randomIS != null) { // kjw: if opened
try {
randomIS.close();
} catch (Exception e) {
log.warn("Failed to close randomIS.");
}
} // kjw
devRandomSource = null; // kjw: don't try again automatically
randomIS=null;
}
}
}
--
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: Tomcat newbie developer tasks?
Hi all, Can anyone suggest some trivial newbie projects for the Tomcat code base? I don't care how menial it is, typo changes, logging, testing (something specific), etc. I've been lurking on the list for awhile and want to start getting my hands dirty. Thanks, Kirk Kirk True wrote: Hi all, Is there a list of tasks with which one can begin to get familiar with the Tomcat source and contribute? Most of the bugs in the Bugzilla look difficult (at least without some guidance) or already have patches. Thanks, Kirk - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
