Re: svn commit: r823603 - in /tomcat/trunk/java/org/apache/catalina/ha/backend: CollectedInfo.java HeartbeatListener.java MultiCastSender.java TcpSender.java
On 10/10/2009 12:24 AM, Filip Hanik - Dev Lists wrote: you're gonna run into all the same issues we already worked through with tribes. I'm not sure why you don't just use tribes rather than reinventing everything from scratch Well it is not exactly solving the same problem, here we need a protocol between the node of a cluster to the front-end. I though tribes was just to be used between the nodes of a cluster, did I miss something? Additionally the httpd part doesn't work only with Tomcat but could also front-end other httpd making the use of tribes a bit complex Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r823603 - in /tomcat/trunk/java/org/apache/catalina/ha/backend: CollectedInfo.java HeartbeatListener.java MultiCastSender.java TcpSender.java
On 10/12/2009 01:06 AM, jean-frederic clere wrote: On 10/10/2009 12:24 AM, Filip Hanik - Dev Lists wrote: you're gonna run into all the same issues we already worked through with tribes. I'm not sure why you don't just use tribes rather than reinventing everything from scratch Well it is not exactly solving the same problem, here we need a protocol between the node of a cluster to the front-end. I though tribes was just to be used between the nodes of a cluster, did I miss something? Tribes is generic, just a communication component. Can be used for anything. And if there are changes needed we can make them. What you are developing right now, looking at the code, you may be reinventing a lot of code that already exists. What is Tomcat specific is the org.apache.catalina.ha package that sits on top of Tribes. Additionally the httpd part doesn't work only with Tomcat but could also front-end other httpd making the use of tribes a bit complex what is the httpd part right now, is it in trunk? however, since all you need is communicate data back and forth, you could make it work with any comm layer underneath, instead of writing one from scratch. best Filip Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r823603 - in /tomcat/trunk/java/org/apache/catalina/ha/backend: CollectedInfo.java HeartbeatListener.java MultiCastSender.java TcpSender.java
On 10/12/2009 07:27 AM, Filip Hanik - Dev Lists wrote: On 10/12/2009 01:06 AM, jean-frederic clere wrote: On 10/10/2009 12:24 AM, Filip Hanik - Dev Lists wrote: you're gonna run into all the same issues we already worked through with tribes. I'm not sure why you don't just use tribes rather than reinventing everything from scratch Well it is not exactly solving the same problem, here we need a protocol between the node of a cluster to the front-end. I though tribes was just to be used between the nodes of a cluster, did I miss something? Tribes is generic, just a communication component. Can be used for anything. And if there are changes needed we can make them. What you are developing right now, looking at the code, you may be reinventing a lot of code that already exists. What is Tomcat specific is the org.apache.catalina.ha package that sits on top of Tribes. Additionally the httpd part doesn't work only with Tomcat but could also front-end other httpd making the use of tribes a bit complex what is the httpd part right now, is it in trunk? however, since all you need is communicate data back and forth, you could make it work with any comm layer underneath, instead of writing one from scratch. additionally, the beauty with trunk is that its open for dev, you can continue with your component that does TCP and multicasting, you can even take code out of tribes since it does that exact thing, or we can adjust tribes to be more generic (unless it already is) best Filip best Filip Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r823603 - in /tomcat/trunk/java/org/apache/catalina/ha/backend: CollectedInfo.java HeartbeatListener.java MultiCastSender.java TcpSender.java
On 10/12/2009 03:27 PM, Filip Hanik - Dev Lists wrote: On 10/12/2009 01:06 AM, jean-frederic clere wrote: On 10/10/2009 12:24 AM, Filip Hanik - Dev Lists wrote: you're gonna run into all the same issues we already worked through with tribes. I'm not sure why you don't just use tribes rather than reinventing everything from scratch Well it is not exactly solving the same problem, here we need a protocol between the node of a cluster to the front-end. I though tribes was just to be used between the nodes of a cluster, did I miss something? Tribes is generic, just a communication component. Can be used for anything. And if there are changes needed we can make them. What you are developing right now, looking at the code, you may be reinventing a lot of code that already exists. What is Tomcat specific is the org.apache.catalina.ha package that sits on top of Tribes. Additionally the httpd part doesn't work only with Tomcat but could also front-end other httpd making the use of tribes a bit complex what is the httpd part right now, is it in trunk? however, since all you need is communicate data back and forth, you could make it work with any comm layer underneath, instead of writing one from scratch. Well the first step was just extending existing stuff in httpd. The existing protocol is quite open so I don't think we will need another one. If you have tribes in C I would use it immediately. Cheers Jean-Frederic best Filip Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47983] New: typo in documentation
https://issues.apache.org/bugzilla/show_bug.cgi?id=47983 Summary: typo in documentation Product: Tomcat Connectors Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: dev@tomcat.apache.org ReportedBy: matt.c.t...@gmail.com on page... http://tomcat.apache.org/connectors-doc/generic_howto/workers.html in the "A sample worker.properties" section the sample creates a worker connecting to locahost instead of localhost (note the missing l). so it caused a bit of a headache trying to track down why it couldn't resolve the host. closer inspection revealed the typo. please fix this on the documentation site. 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
DO NOT REPLY [Bug 47785] Cluster MBean not registered
https://issues.apache.org/bugzilla/show_bug.cgi?id=47785 eyindanga changed: What|Removed |Added Severity|blocker |regression -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r824432 - /tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java
Author: markt
Date: Mon Oct 12 17:28:49 2009
New Revision: 824432
URL: http://svn.apache.org/viewvc?rev=824432&view=rev
Log:
Add an explicit test for JSPs. Grails - that is using a variant of this - seems
to have issues with JSPs. Looks OK here.
Modified:
tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java
Modified: tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java?rev=824432&r1=824431&r2=824432&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java (original)
+++ tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java Mon Oct 12
17:28:49 2009
@@ -137,6 +137,21 @@
assertTrue(res.toString().indexOf("Hello World!") > 0);
}
+public void testJsps() throws Exception {
+Tomcat tomcat = getTomcatInstance();
+
+File appDir =
+new File("output/build/webapps/examples");
+// app dir is relative to server home
+tomcat.addWebapp(null, "/examples", appDir.getAbsolutePath());
+
+tomcat.start();
+
+ByteChunk res = getUrl("http://localhost:"; + getPort() +
+"/examples/jsp/jsp2/el/basic-arithmetic.jsp");
+assertTrue(res.toString().indexOf("${(1==2) ? 3 : 4}") > 0);
+}
+
public void testLaunchTime() throws Exception {
Tomcat tomcat = getTomcatInstance();
long t0 = System.currentTimeMillis();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question ad alternative of BSF taglib in Tomcat ? [Fwd: In the move of some taglibs to Tomcat, the BSF taglib got retired]
Not sure where Christopher's email was, but: If there is any interest in a retired taglib, I'm all for it being merged into the Extended Taglib. Currently I plan to consider replacing the functionality from String Taglib (mostly as EL functions), Log Taglib and JNDI Taglib (perhaps). It sounds like BSF taglib, given it has only the two tags, might be very interesting if a dependency on BSF itself can be avoided (ie: base it on javax.script). Hen On Sun, Oct 11, 2009 at 4:31 AM, Rony G. Flatscher (Apache) wrote: > Christopher, > > thanks for your information! > >> > AFAIK the BSF taglib has been allowing one to add code in all of the >> > BSF supported scripting languages to JSPs. Not knowing, wheter there >> > are alternatives available in the current Tomcat >> >> Tomcat itself contains little in the way of tag libraries, except for >> the JSTL required by the JSP 2.1 specification (and higher). >> >> > In case the BSF taglib is needed for adding scripts in scripting >> > languages to JSPs, I would kindly suggest to not retire it, but to >> > keep it available for interested parties in the Tomcat realm. >> >> So, let me clear a few things up: >> >> 1. The Tomcat team didn't retire the BSF tag library. The Jakarta BSF >> tag library folks retired it. You should complain to them. > They are all off (enjoying retirement) ... > ;-) > >> 2. The Apache Software Foundation (ASF) never deletes code forever. Just >> because it's retired doesn't mean it's no longer available: it just >> means that they will no longer be maintaining it by adding features, >> fixing bugs, or answering questions about it. > Yes, but the semantics of "retirement" indicates that they go out of > service (are not useful in todays world anymore). > >> Note that the jakarta-taglibs-BSF project hadn't had a news announcement >> since 2002, so it was pretty much already dead. > Yes, but does that mean it is not useful anymore, needs to get retired, > has become irrelevant? > > In this particular case it is just a sign that this particular > functionality has become stable and there has not been a need to add new > functionality (what functionality would have been needed in this taglib, > other than enabling scripting languages to become usable to create > scripts embedded in JSPs) ? > > Coming from BSF (which BSF taglib exploits) it is not clear to me, > whether Tomcat users have been exploiting this taglib or not (actually, > if it gets retired, this means that either the taglib is not needed > anymore, because of an alternative technology put in place, or the > taglib has not been exploited, used at all). > >> > In case there are alternatives available in Tomcat to the BSF taglib, >> > please be so kind and point them out (just short pointers would >> > suffice!). >> >> What is it that you are trying to do, exactly? It's possible that simply >> using the BSF library directly (without a tag library) is your best >> option. There was a fad for a while where everything was being wrapped >> into a tag library and JSP was starting to look like ColdFusion. CF was >> eventually re-implemented in Java using JSP tag libraries so I guess JSP >> had the last laugh. >> >> I never thought non-UI-related tag libraries had any business existing >> because I firmly believe in separation between model/controller and >> view: the view simply should not be sending emails, communicating with >> databases (at least not directly), sending JMS messages, or copying >> files around. > E.g. if you look into the MS world you will immediately stumble over > tons of ASPs which employ tons (even a mix) of scripting languages. > Scripting languages in that world empower even end-user kind of > programmers to quickly and easily insert code in a language they can > master for web-based applications (and again, they take advantage of > that possibility). (There are more reasons, arguments, why it may > actually make sense to allow scripting languages to be used in server > pages, of cours.) > > Also, experts in once scripting language are enabled to apply their > knowledge for Web apps by creating the needed logic in their scripting > language for server pages, removing the need for them to learn a new > programming language. (Again, there are other good reasons as well.) > >> If you want to use another scripting language to generate content, then >> why bother with JSP in the first place? Why not use a tool geared >> towards allowing you to use your scripting-language of choice outside of >> a JSP context? > This would lead to environments that lock-in the developers in specific > environments, which only are available for themselves (cf. PHP, Ruby, > etc. environments). Having an established and proven environment > available, like Tomcat, making it possible to mix-in code in scripting > languages, would be a boon. > > If it is possible to include script code into JSPs, then why not allow > for that? The BSF taglib would allow for that, making it possible to > mix-an
DO NOT REPLY [Bug 47987] New: Out of memory being caused by notFoundResources in org.apache.catalina.loader.WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=47987 Summary: Out of memory being caused by notFoundResources in org.apache.catalina.loader.WebappClassLoader Product: Tomcat 6 Version: 6.0.20 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: da...@twocats.co.uk Guys Tomcat 6.0.20, java 1.6, linux x64 org.apache.catalina.loader.WebappClassLoader records every resource you asked for that doesn't exist. On our site we have alot of pages ( > 800,000 ) all of which are using struts2 with validation. every hit means the validator does a request for a resource actionName-validation.xml This then gets cached in the WebappClassLoader about line 249 /** * The list of not found resources. */ protected HashMap notFoundResources = new HashMap(); Can this be made into a weak hash map perchance ? or something so that it won't invoke a out of memory. I'm also looking at removing the validator from those urls if anyone knows how to tell the validation interceptor that we don't use the xml files and ONLY use annotations then that would be great :) Ta D -- 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 27717] very slow in JSTL 1.1
https://issues.apache.org/bugzilla/show_bug.cgi?id=27717 Josh Landin changed: What|Removed |Added CC||j...@cyntact.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 27717] very slow in JSTL 1.1
https://issues.apache.org/bugzilla/show_bug.cgi?id=27717 Josh Landin changed: What|Removed |Added Priority|P3 |P2 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r824589 - /tomcat/taglibs/extended/trunk/src/main/resources/META-INF/tlds/taglibs-extended.tld
Author: bayard Date: Tue Oct 13 04:48:16 2009 New Revision: 824589 URL: http://svn.apache.org/viewvc?rev=824589&view=rev Log: Adding todo note Modified: tomcat/taglibs/extended/trunk/src/main/resources/META-INF/tlds/taglibs-extended.tld Modified: tomcat/taglibs/extended/trunk/src/main/resources/META-INF/tlds/taglibs-extended.tld URL: http://svn.apache.org/viewvc/tomcat/taglibs/extended/trunk/src/main/resources/META-INF/tlds/taglibs-extended.tld?rev=824589&r1=824588&r2=824589&view=diff == --- tomcat/taglibs/extended/trunk/src/main/resources/META-INF/tlds/taglibs-extended.tld (original) +++ tomcat/taglibs/extended/trunk/src/main/resources/META-INF/tlds/taglibs-extended.tld Tue Oct 13 04:48:16 2009 @@ -186,5 +186,6 @@ + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question ad alternative of BSF taglib in Tomcat ? [Fwd: In the move of some taglibs to Tomcat, the BSF taglib got retired]
Henri Yandell wrote: > Not sure where Christopher's email was, but: > > If there is any interest in a retired taglib, I'm all for it being > merged into the Extended Taglib. Currently I plan to consider > replacing the functionality from String Taglib (mostly as EL > functions), Log Taglib and JNDI Taglib (perhaps). > > It sounds like BSF taglib, given it has only the two tags, might be > very interesting if a dependency on BSF itself can be avoided (ie: > base it on javax.script). > +1 If you include just the taglib (the JSR-223 to be created), then its usage would be restricted to Java 6 and up, such that current Java 1.4 and 1.5 installations in the field could not take advantage of it. To cover Java 1.4 and 1.5 BSF 3.0 got created, which implements the javax.script specifications. If BSF 3.0 is included then the scripting support will be available from Java 1.4 on. Starting with Java 6 the Java 6 javax.script would prevail due to using its own package by placement of the classes. ---rony - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
