DO NOT REPLY [Bug 46041] Tomcat service is terminated unexpectedly (tcnative-1.dll)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46041 Marcin Zajaczkowski <[EMAIL PROTECTED]> changed: What|Removed |Added Version|unspecified |1.1.4 --- Comment #3 from Marcin Zajaczkowski <[EMAIL PROTECTED]> 2008-10-21 00:15:05 PST --- This is a version 1.1.4.0 of tcnative-1.dll. It was downloaded automatically during the installation process of Tomcat 5.5.26 a few weeks ago. It was strange, but when the available memory was increased (from 512MB) there were no errors in Tomcat log, just Java/Tomcat process had been terminated. But there may be something wrong with a memory usage. In every stacktrace there is 99% usage of perm gen: compacting perm gen total 45312K, used 45063K [0x53d7, 0x569b, 0x57d7) the space 45312K, 99% used [0x53d7, 0x56971f40, 0x56972000, 0x569b) Probably It isn't normal. I will try to set up JMX and monitor it. Currently I switched a configuration to not use native DLL to check if the problem remains. Btw, I don't know if it could be a reason, but with your suggestion it read some Java documnetn and there are suggested to set maximum head size to 1GB for 32-bits machine. I will try to lower it. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[JNI/native]: recvfrom vs recvFrom
Hi folks, I am new to this stuff, so please bear with me... I am working on some extensions to the APR transport in the MINA project. I was trying to use Socket.recvFrom() from the org.apache.tomcat.jni package and kept getting UnsatisfiedLink errors... I think I tracked the problem to a case mismatch between the java Socket.class and the native network.c files. The java code specifies a recvFrom() method (capital F) whereas the native code defines a recvfrom() function (all lowercase)... A quick rebuild of the tomcat sources after renaming the java method recvfrom() seems to have fixed my initial problem, as the UnsatisfiedLink error has disappeared... Was that really the (only) problem? I didn't find any other report on this issue, and assuming a bunch of people use the apr libraries, I am not quite sure if I have found a bug or not... Anyway, if that really is an issue, you may want to fix either the jave or the native code... cheers, Lorenz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 46047] New: Issue when using include directive inside tag files that are inside jar files
https://issues.apache.org/bugzilla/show_bug.cgi?id=46047
Summary: Issue when using include directive inside tag files that
are inside jar files
Product: Tomcat 6
Version: 6.0.18
Platform: PC
OS/Version: Linux
Status: NEW
Severity: critical
Priority: P2
Component: Jasper
AssignedTo: dev@tomcat.apache.org
ReportedBy: [EMAIL PROTECTED]
Created an attachment (id=22760)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22760)
patch for ParserController class
When we use the include directive inside a tag file like :
<%@ tag body-content="empty" description="Renders a date control to query the
creation date of a content object." %>
<[EMAIL PROTECTED] file="/META-INF/tags/search/declaration.tagf" %>
And that this tag file is inside a jar file, jasper has an issue dealing the
dependencies by losing the fact that the included file is inside a jar file.
static {
_jspx_dependants = new java.util.ArrayList(4);
_jspx_dependants.add("/META-INF/tags/search/declaration.tagf");
_jspx_dependants.add("/META-INF/tags/search/date.tagf");
_jspx_dependants.add("jar:file:/home/rincevent/tools/apache-tomcat-6.0.18/webapps/jahia/WEB-INF/lib/jahia-taglib-6.0-SNAPSHOT.jar!/META-INF/search.tld");
_jspx_dependants.add("jar:file:/home/rincevent/tools/apache-tomcat-6.0.18/webapps/jahia/WEB-INF/lib/jahia-taglib-6.0-SNAPSHOT.jar!/META-INF/tags/search/resultsPageUrl.tag");
}
The other dependencies are handled correctly thanks to patch
https://issues.apache.org/bugzilla/show_bug.cgi?id=43741 .
I propose a patch to ParserController so that when we detect that we are inside
a jarFile we prepend the jarFileUrl to absFileName.
The patch has been made on the trunk source code of tomcat.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706574 - /tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Socket.java
Author: mturk Date: Tue Oct 21 03:47:24 2008 New Revision: 706574 URL: http://svn.apache.org/viewvc?rev=706574&view=rev Log: Fix API function name recvFrom -> recvfrom. Modified: tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Socket.java Modified: tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Socket.java URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Socket.java?rev=706574&r1=706573&r2=706574&view=diff == --- tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Socket.java (original) +++ tomcat/connectors/trunk/jni/java/org/apache/tomcat/jni/Socket.java Tue Oct 21 03:47:24 2008 @@ -418,7 +418,7 @@ * @param nbytes The number of bytes to read (-1) for full array. * @return the number of bytes received. */ -public static native int recvFrom(long from, long sock, int flags, +public static native int recvfrom(long from, long sock, int flags, byte[] buf, int offset, int nbytes); /** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JNI/native]: recvfrom vs recvFrom
Lorenz Breu wrote: Hi folks, Socket.class and the native network.c files. The java code specifies a recvFrom() method (capital F) whereas the native code defines a recvfrom() function (all lowercase)... A quick rebuild of the tomcat sources after renaming the java method recvfrom() seems to have fixed my initial problem, as the UnsatisfiedLink error has disappeared... Thanks for spotting that. Fixed as r706574 in trunk Regards -- ^(TM) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[JNI/native] retrieving the port of the remote end of a socket
Glad I could help ;)
Maybe somebody can give me a hint now. I am trying to retrieve the port
of the sender of a datagram using recvfrom() as shown below:
protected SocketAddress receive(Long handle, IoBuffer buffer)
throws Exception {
/*initialize a new byte array for now. Is the data correctly
transferred to the
* MINA framework like this? There must be some way to write
directly to buffer...
*/
byte b[] = new byte[buffer.capacity()];
//initialize a new apr_sockaddr_t
long ra = Address.info("123.123.123.123", 0, 14, 0, pool);
//use recFrom() to read the datagram and fill in the
apr_sockaddr_t with the remote address
int bytesRecv = Socket.recvfrom(ra,(long)
handle,0,b,0,buffer.capacity());
//move the acquired data to the buffer used in the future.
Performance problem, there must be a direct way to do this
buffer.put(b);
//fill in the data to return (remote address)
SocketAddress sa = new InetSocketAddress(Address.getip(ra),
Address.getInfo(ra).port);
return sa;
}
Now data seems to be correctly received, and Address.getip(ra) returns
the correct IP address, however the port passed to the constructor of
InetSocketAddress is always the one used during the initialization of
the apr_sockaddr_t. Hence the port is either not fetched during the
underlying native call to recvfrom, or incorrectly fetched in the
getInfo() call, or I have made a mistake somewhere. Has anybody used
these methods successfully before?
Cheers,
Lorenz
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706626 - /tomcat/container/tags/tc4.1.x/TOMCAT_4_1_38/
Author: markt Date: Tue Oct 21 06:42:22 2008 New Revision: 706626 URL: http://svn.apache.org/viewvc?rev=706626&view=rev Log: Tagging 4.1.38 Added: tomcat/container/tags/tc4.1.x/TOMCAT_4_1_38/ - copied from r706625, tomcat/container/branches/tc4.1.x/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706629 - /tomcat/servletapi/tags/servlet2.3-jsp1.2-tc4.x/TOMCAT_4_1_38/
Author: markt Date: Tue Oct 21 06:42:58 2008 New Revision: 706629 URL: http://svn.apache.org/viewvc?rev=706629&view=rev Log: Tagging 4.1.38 Added: tomcat/servletapi/tags/servlet2.3-jsp1.2-tc4.x/TOMCAT_4_1_38/ - copied from r706628, tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706627 - /tomcat/connectors/tags/tc4.1.x/TOMCAT_4_1_38/
Author: markt Date: Tue Oct 21 06:42:34 2008 New Revision: 706627 URL: http://svn.apache.org/viewvc?rev=706627&view=rev Log: Tagging 4.1.38 Added: tomcat/connectors/tags/tc4.1.x/TOMCAT_4_1_38/ - copied from r706626, tomcat/connectors/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706628 - /tomcat/jasper/tags/tc4.1.x/TOMCAT_4_1_38/
Author: markt Date: Tue Oct 21 06:42:46 2008 New Revision: 706628 URL: http://svn.apache.org/viewvc?rev=706628&view=rev Log: Tagging 4.1.38 Added: tomcat/jasper/tags/tc4.1.x/TOMCAT_4_1_38/ - copied from r706627, tomcat/jasper/branches/tc4.1.x/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
if there are no objections, I'll start integrating this into trunk tonight or tomorrow, Filip Filip Hanik - Dev Lists wrote: gentlemen, having run into issues with performance around commons-dbcp as number of logical cpus increase, no such method exceptions using newer JDKs, I've made a small code contribution https://issues.apache.org/bugzilla/show_bug.cgi?id=46038 description and documentation is in the bug, and attached to the bug as an XML document. I would propose 1. add as default connection pool when type=javax.sql.DataSource in trunk 2. ship as an alternate pool with 6.0.x but not enabled by default what are your thoughts? best Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
On Tue, 2008-10-21 at 08:09 -0600, Filip Hanik - Dev Lists wrote: > if there are no objections, I'll start integrating this into trunk > tonight or tomorrow, -1. Tomcat does not do connection pools. Commons-pool/-dbcp is used instead, so you should contribute your code to the right project, I think. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
Filip, On Tue, Oct 21, 2008 at 10:09 AM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > if there are no objections, I'll start integrating this into trunk tonight or > tomorrow, I've read the bug in Bugzilla and looked at the code. I understand why you want a new connection pool implementation, and I like what you've done with it, code-wise. In fact, I'd probably like to use it myself. (I use c3p0, which I like better than DBCP, but that's another story). However, I don't think we should stick a connection pool implementation in Tomcat proper. It should go in Commons DbUtils, or DBCP, or another existing project. Heck, it can even start out on Google Code, idealy with an ASL license. I don't want to bloat Tomcat with extra stuff, no matter how good. I'd much rather remove stuff and keep the core way smaller. I really like what Costin is doing with his "Tomcat lite." Of course, that's just my personal opinion. But I wanted to speak up because I'm pretty close to a -1 on this one. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706633 - /tomcat/container/branches/tc4.1.x/build.properties.default
Author: markt Date: Tue Oct 21 07:09:14 2008 New Revision: 706633 URL: http://svn.apache.org/viewvc?rev=706633&view=rev Log: Update version for next release Modified: tomcat/container/branches/tc4.1.x/build.properties.default Modified: tomcat/container/branches/tc4.1.x/build.properties.default URL: http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/build.properties.default?rev=706633&r1=706632&r2=706633&view=diff == --- tomcat/container/branches/tc4.1.x/build.properties.default (original) +++ tomcat/container/branches/tc4.1.x/build.properties.default Tue Oct 21 07:09:14 2008 @@ -28,7 +28,7 @@ #flags.hide=on #Version number -version=4.1.38 +version=4.1.39 #Proxy to download subproject #proxy.host=proxy.domain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
I think there is a solution that would make everyone happy :-) - put this code and everything that depends on it in a separate module ( separate == different release cycle and binary ). I don't know if it should be in a separate svn tree, probably would be better. Then you can cut a release - and with a bit of tricks may work with existing tomcat5 or 6. Regarding scope - yes, maybe moving it to commons would be better, but the essential question is who's going to maintain it. If other projects pick it up - no problem with moving it, but as long as tomcat is the main user and you probably the main maintainer, it's better to keep it in tomcat ( and hopefully other tomcat people get enough familiarity with the code to be able to vote +1 on releasing it :-). My primary concern is to have the dependency right - the new module can depend on tomcat, but tomcat should not have any direct dep. on the new code. I wouldn't mind if all the existing JDBC related components would move to the new module as well :-). Costin On Tue, Oct 21, 2008 at 7:19 AM, Yoav Shapira <[EMAIL PROTECTED]> wrote: > Filip, > > On Tue, Oct 21, 2008 at 10:09 AM, Filip Hanik - Dev Lists > <[EMAIL PROTECTED]> wrote: > > if there are no objections, I'll start integrating this into trunk > tonight or tomorrow, > > I've read the bug in Bugzilla and looked at the code. I understand > why you want a new connection pool implementation, and I like what > you've done with it, code-wise. In fact, I'd probably like to use it > myself. (I use c3p0, which I like better than DBCP, but that's > another story). > > However, I don't think we should stick a connection pool > implementation in Tomcat proper. It should go in Commons DbUtils, or > DBCP, or another existing project. Heck, it can even start out on > Google Code, idealy with an ASL license. > > I don't want to bloat Tomcat with extra stuff, no matter how good. > I'd much rather remove stuff and keep the core way smaller. I really > like what Costin is doing with his "Tomcat lite." > > Of course, that's just my personal opinion. But I wanted to speak up > because I'm pretty close to a -1 on this one. > > Yoav > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Tomcat connection pool contribution
> My primary concern is to have the dependency right - the new module can > depend on tomcat, > but tomcat should not have any direct dep. on the new code. I wouldn't mind > if all the existing JDBC > related components would move to the new module as well :-). Costin is a long time supporter of modularity :) I agree and even more when life cycle of each 'components' are very differents - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
On Tue, 2008-10-21 at 10:19 -0400, Yoav Shapira wrote: > However, I don't think we should stick a connection pool > implementation in Tomcat proper. It should go in Commons DbUtils, or > DBCP, or another existing project. Heck, it can even start out on > Google Code, idealy with an ASL license. > > I don't want to bloat Tomcat with extra stuff, no matter how good. > I'd much rather remove stuff and keep the core way smaller. I really > like what Costin is doing with his "Tomcat lite." So you would not even ship one "default" connection pool, as we do now ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706648 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: remm Date: Tue Oct 21 08:02:10 2008 New Revision: 706648 URL: http://svn.apache.org/viewvc?rev=706648&view=rev Log: - Votes. 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=706648&r1=706647&r2=706648&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Oct 21 08:02:10 2008 @@ -230,23 +230,23 @@ Don't use xml parser from web-app to process tld files http://svn.apache.org/viewvc?rev=701355&view=rev +1: markt - -1: + -0: remm (it is a refactoring, and is not appropriate to me in 6.0.x) * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45403 See commit message for details of negligable performance impact http://svn.apache.org/viewvc?rev=701358&view=rev +1: markt - -1: + -0: remm (I also do not think the patch is a good idea as a backport) * Fix regression in https://issues.apache.org/bugzilla/show_bug.cgi?id=43656 Patch provided by Nils Eckert http://svn.apache.org/viewvc?rev=702632&view=rev - +1: markt + +1: markt, remm -1: * Fix issue with nested contexts and context.xml files http://svn.apache.org/viewvc?rev=702208&view=rev - +1: markt + +1: markt, remm -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45951 @@ -257,27 +257,31 @@ * Derefence socket when the request is complete http://svn.apache.org/viewvc?rev=702676&view=rev - +1: fhanik + +1: fhanik, remm -1: * Port remaining EL changes. This is all the remaining EL related patches from trunk http://people.apache.org/~markt/patches/2008-10-19-el-tck-various.patch - +1: markt + +1: markt, remm (let's try it) -1: * Backport NCDFE fix from trunk (TCK failures without it) http://svn.apache.org/viewvc?rev=640888&view=rev +1: markt + 0: remm (no clue how it can cause a NCDF, and the TCK actually works for me; besides that code is +really old to me, so where would this come from ?) -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45285 Correctly handle annotations in parent classes http://people.apache.org/~markt/patches/2008-10-20-bug45285-v2.patch Based on a patch by Florent BENOIT - +1: markt + +1: markt, remm -1: * Fix classcast exception upon shutdown(edgecase) http://svn.apache.org/viewvc?rev=706433&view=rev - +1: fhanik \ No newline at end of file + +1: fhanik + -1: + \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
Remy and Yoav, I totally understand where you are coming from, and I have thought about it for while before I suggested adding it here 1. commons-dbcp is very stagnant, they are not even accepting performance improvement patches https://issues.apache.org/jira/browse/POOL-75 2. Remy's comment -"Tomcat does not do connection pools" We sure do, the fact that we ship with one, means we do connection pools. and we are in the job of refactoring commons-dbcp, and now you can't even compile Tomcat with JDK 1.6, nor run it with JDK 1.6 since the java.sql API's are not implemented. a user doesn't care of this is a project from elsewhere, he/she just feels it is a hinder. 3. Yoav's comment - "I don't want to bloat Tomcat with extra stuff" Depends on the definition of bloating, our hacks around commons-dbcp, the size of the library (commons-dbcp-193k, new pool-36k) itself, and the build script we've already bloated our system with crud from commons-dbcp, not working properly here Look at the build script for commons-dbcp->tomcat-dbcp, that is *code*, and that is bloat. 4. Going with the little piece of code (8classes) elsewhere is a bit moot, the code is complete, it's not gonna attract a community based on 8classes. And that is why it would be awkward putting it anywhere else, its not like this code is gonna grow and evolve into a large organic project, hence within the ASF, it would be considered dead even before it started. I hear both of your concerns, and I will withdraw the proposal, thanks for speaking up Filip Yoav Shapira wrote: Filip, On Tue, Oct 21, 2008 at 10:09 AM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: if there are no objections, I'll start integrating this into trunk tonight or tomorrow, I've read the bug in Bugzilla and looked at the code. I understand why you want a new connection pool implementation, and I like what you've done with it, code-wise. In fact, I'd probably like to use it myself. (I use c3p0, which I like better than DBCP, but that's another story). However, I don't think we should stick a connection pool implementation in Tomcat proper. It should go in Commons DbUtils, or DBCP, or another existing project. Heck, it can even start out on Google Code, idealy with an ASL license. I don't want to bloat Tomcat with extra stuff, no matter how good. I'd much rather remove stuff and keep the core way smaller. I really like what Costin is doing with his "Tomcat lite." Of course, that's just my personal opinion. But I wanted to speak up because I'm pretty close to a -1 on this one. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
On Tue, Oct 21, 2008 at 11:15 AM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > I hear both of your concerns, and I will withdraw the proposal, thanks for > speaking up These are all good comments. Is it possible to package up in a way that core Tomcat does not depend on it, like Costin said? I know the current DBCP packaging sucks, and that the current DBCP project is stagnant. That's why I said I'd use your new code. I don't want to lose it completely ;) Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
On Tue, 2008-10-21 at 09:15 -0600, Filip Hanik - Dev Lists wrote: > Remy and Yoav, I totally understand where you are coming from, and I > have thought about it for while before I suggested adding it here > > 1. commons-dbcp is very stagnant, they are not even accepting > performance improvement patches > https://issues.apache.org/jira/browse/POOL-75 You could start dbcp2 if dbcp is frozen. If that really doesn't work, and there's really nowhere to put the component, then this can be reconsidered. > 2. Remy's comment -"Tomcat does not do connection pools" > We sure do, the fact that we ship with one, means we do connection > pools. and we are in the job of refactoring commons-dbcp, and now you > can't even compile Tomcat with JDK 1.6, nor run it with JDK 1.6 since > the java.sql API's are not implemented. a user doesn't care of this is a > project from elsewhere, he/she just feels it is a hinder. Tomcat ships a thirdparty pool for convenience. > 3. Yoav's comment - "I don't want to bloat Tomcat with extra stuff" > Depends on the definition of bloating, our hacks around commons-dbcp, > the size of the library (commons-dbcp-193k, new pool-36k) itself, and > the build script > we've already bloated our system with crud from commons-dbcp, not > working properly here > Look at the build script for commons-dbcp->tomcat-dbcp, that is *code*, > and that is bloat. Without the script, it could cause CL conflicts with the commons libs, and it would be even bigger. OTOH, replacing the pool is annoying. People don't like bugs in their pool. > 4. Going with the little piece of code (8classes) elsewhere is a bit > moot, the code is complete, it's not gonna attract a community based on > 8classes. And that is why it would be awkward putting it anywhere else, > its not like this code is gonna grow and evolve into a large organic > project, hence within the ASF, it would be considered dead even before > it started. > > I hear both of your concerns, and I will withdraw the proposal, > thanks for speaking up Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
Oddly enough - I started reading the code today. There are some minor
tweaks without digging too deep into the code:
ProxyConnection.java
This should be CLOSE_VAL.equals(method.getName())
if (CLOSE_VAL==method.getName()) {
PoolProperties
protected String name = "Filip Connection Pool["+(poolCounter++)+"]";
What I haven't read through is how concurrent threads return/borrow at
the same time.
Given that dbcp feels like it has one foot in the grave, has many
dependencies, it would reduce the bloat by adding this as a module and
removing dbcp. If this would go to 6.0.x - it can't be default since it
would break many installations.
-Tim
Filip Hanik - Dev Lists wrote:
gentlemen,
having run into issues with performance around commons-dbcp as number of
logical cpus increase, no such method exceptions using newer JDKs, I've
made a small code contribution
https://issues.apache.org/bugzilla/show_bug.cgi?id=46038
description and documentation is in the bug, and attached to the bug as
an XML document.
I would propose
1. add as default connection pool when type=javax.sql.DataSource in trunk
2. ship as an alternate pool with 6.0.x but not enabled by default
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
On Tue, Oct 21, 2008 at 5:15 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > Remy and Yoav, I totally understand where you are coming from, and I have > thought about it for while before I suggested adding it here > 4. Going with the little piece of code (8classes) elsewhere is a bit moot, > the code is complete, it's not gonna attract a community based on 8classes. > And that is why it would be awkward putting it anywhere else, its not like > this code is gonna grow and evolve into a large organic project, hence > within the ASF, it would be considered dead even before it started. > On a side note, myself and probably many others would be very interested in alternative (better) connection pools, so starting it as a new, independent project at java.net, sourceforge or what not, would be worth a try! Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
Filip Hanik - Dev Lists wrote: > Remy and Yoav, I totally understand where you are coming from, and I > have thought about it for while before I suggested adding it here > > 1. commons-dbcp is very stagnant, they are not even accepting > performance improvement patches > https://issues.apache.org/jira/browse/POOL-75 That patch hasn't been rejected. It is more a case of no-one has had the cycles to review the latest patch. The commons folks were very accommodating with https://issues.apache.org/bugzilla/show_bug.cgi?id=43552 once I showed up on [EMAIL PROTECTED] and started to offer to help. Reviewing the open commons-pool and commons-dbcp issues has been on my to do list for a while but to date, no-one has raised a Tomcat bug or complained on the users list so I haven't got around to it yet. > 2. Remy's comment -"Tomcat does not do connection pools" > We sure do, the fact that we ship with one, means we do connection > pools. and we are in the job of refactoring commons-dbcp, and now you > can't even compile Tomcat with JDK 1.6, nor run it with JDK 1.6 since > the java.sql API's are not implemented. a user doesn't care of this is a > project from elsewhere, he/she just feels it is a hinder. I am pretty sure it will run on a 1.6 JDK - it just has to be compiled on 1.5 > 3. Yoav's comment - "I don't want to bloat Tomcat with extra stuff" > Depends on the definition of bloating, our hacks around commons-dbcp, > the size of the library (commons-dbcp-193k, new pool-36k) itself, and > the build script > we've already bloated our system with crud from commons-dbcp, not > working properly here Calling commons-dbcp crud is rather harsh. If there are issues, join the commons-dev list and offer to help fix them. > 4. Going with the little piece of code (8classes) elsewhere is a bit > moot, the code is complete, it's not gonna attract a community based on > 8classes. And that is why it would be awkward putting it anywhere else, > its not like this code is gonna grow and evolve into a large organic > project, hence within the ASF, it would be considered dead even before > it started. As a refactoring of DBCP (as Remy suggested) in Commons I think there would be enough a community behind it. Putting it in extras is another possibility. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
Yoav Shapira wrote: On Tue, Oct 21, 2008 at 11:15 AM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: I hear both of your concerns, and I will withdraw the proposal, thanks for speaking up These are all good comments. Is it possible to package up in a way that core Tomcat does not depend on it, like Costin said? sure is, tomcat doesn't depend on it today, the new dbcp depends on tomcat-juli.jar, so the dependency is the other way I know the current DBCP packaging sucks, and that the current DBCP project is stagnant. That's why I said I'd use your new code. I don't want to lose it completely ;) there are two questions two be answered 1. what source repository does it sit in 2. If it sits under the tomcat umbrella, is it released with tomcat or as an independent module (like mod_jk, tcnative, etc) Filip Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
Tim Funk wrote:
Oddly enough - I started reading the code today. There are some minor
tweaks without digging too deep into the code:
ProxyConnection.java
This should be CLOSE_VAL.equals(method.getName())
if (CLOSE_VAL==method.getName()) { .
aren't method names in the constant pool?
PoolProperties
protected String name = "Filip Connection Pool["+(poolCounter++)+"]";
you don't like it :) LOL, things are still to be fixed.
What I haven't read through is how concurrent threads return/borrow at
the same time.
that is the core of the pool, and could still be tuned, but in
comparison to other choices, its a non issue for quite a while
Given that dbcp feels like it has one foot in the grave, has many
dependencies, it would reduce the bloat by adding this as a module and
removing dbcp. If this would go to 6.0.x - it can't be default since
it would break many installations.
it wouldn't default in 6.0.x, that's not been on the table. It also
wouldn't break a single installation, it uses the exact same settings,
(unless of course someone uses casting)
Filip
-Tim
Filip Hanik - Dev Lists wrote:
gentlemen,
having run into issues with performance around commons-dbcp as number
of logical cpus increase, no such method exceptions using newer JDKs,
I've made a small code contribution
https://issues.apache.org/bugzilla/show_bug.cgi?id=46038
description and documentation is in the bug, and attached to the bug
as an XML document.
I would propose
1. add as default connection pool when type=javax.sql.DataSource in
trunk
2. ship as an alternate pool with 6.0.x but not enabled by default
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
Mark Thomas: > Filip Hanik - Dev Lists wrote: >> 2. Remy's comment -"Tomcat does not do connection pools" >> We sure do, the fact that we ship with one, means we do connection >> pools. and we are in the job of refactoring commons-dbcp, and now you >> can't even compile Tomcat with JDK 1.6, nor run it with JDK 1.6 since >> the java.sql API's are not implemented. a user doesn't care of this is a >> project from elsewhere, he/she just feels it is a hinder. > > I am pretty sure it will run on a 1.6 JDK - it just has to be compiled on 1.5 All my Tomcat installations run on 1.6. I even compile Tomcat using 1.6 quite frequently - once the download ant task is run with 1.5 I don't see a problem with this either. Regards mks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
Mark Thomas wrote: Filip Hanik - Dev Lists wrote: Remy and Yoav, I totally understand where you are coming from, and I have thought about it for while before I suggested adding it here 1. commons-dbcp is very stagnant, they are not even accepting performance improvement patches https://issues.apache.org/jira/browse/POOL-75 That patch hasn't been rejected. It is more a case of no-one has had the cycles to review the latest patch. The commons folks were very accommodating with https://issues.apache.org/bugzilla/show_bug.cgi?id=43552 once I showed up on [EMAIL PROTECTED] and started to offer to help. Reviewing the open commons-pool and commons-dbcp issues has been on my to do list for a while but to date, no-one has raised a Tomcat bug or complained on the users list so I haven't got around to it yet. again, we're talking about such a small project, that is considered complete, and would not build a new community around it. 2. Remy's comment -"Tomcat does not do connection pools" We sure do, the fact that we ship with one, means we do connection pools. and we are in the job of refactoring commons-dbcp, and now you can't even compile Tomcat with JDK 1.6, nor run it with JDK 1.6 since the java.sql API's are not implemented. a user doesn't care of this is a project from elsewhere, he/she just feels it is a hinder. I am pretty sure it will run on a 1.6 JDK - it just has to be compiled on 1.5 it will run until you get a NoSuchMethodException cause it doesn't have the method implemented, so that would qualify as not running in a production system 3. Yoav's comment - "I don't want to bloat Tomcat with extra stuff" Depends on the definition of bloating, our hacks around commons-dbcp, the size of the library (commons-dbcp-193k, new pool-36k) itself, and the build script we've already bloated our system with crud from commons-dbcp, not working properly here Calling commons-dbcp crud is rather harsh. If there are issues, join the commons-dev list and offer to help fix them. I wasn't calling commons-dbcp crud, however, our refactoring of it is a hack around class loading issues, so that is what I referred to, it was a necessary evil, but doesn't mean its good nor pretty. 4. Going with the little piece of code (8classes) elsewhere is a bit moot, the code is complete, it's not gonna attract a community based on 8classes. And that is why it would be awkward putting it anywhere else, its not like this code is gonna grow and evolve into a large organic project, hence within the ASF, it would be considered dead even before it started. As a refactoring of DBCP (as Remy suggested) in Commons I think there would be enough a community behind it. db.apache.org would probably be more appropriate, but that brings back the original point I brought up http://db.apache.org/newproject.html this is not something that draws a big crowd, we'd be fighting over what source file to maintain :) Putting it in extras is another possibility. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
Markus Schönhaber wrote: Mark Thomas: Filip Hanik - Dev Lists wrote: 2. Remy's comment -"Tomcat does not do connection pools" We sure do, the fact that we ship with one, means we do connection pools. and we are in the job of refactoring commons-dbcp, and now you can't even compile Tomcat with JDK 1.6, nor run it with JDK 1.6 since the java.sql API's are not implemented. a user doesn't care of this is a project from elsewhere, he/she just feels it is a hinder. I am pretty sure it will run on a 1.6 JDK - it just has to be compiled on 1.5 All my Tomcat installations run on 1.6. I even compile Tomcat using 1.6 quite frequently - once the download ant task is run with 1.5 I don't see a problem with this either. that just means you're not using any API in java.sql from JDK 1.6 Regards mks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat connection pool contribution
I would go one step further and not ship jdbc-related components in the basic distro :-), and bundle dbcp and jdbc-related code as a separate module. If someone is using a database - there are few setup steps anyways, and downloading a separate tomcat module may be the easiest of them. From a tomcat-lite perspective, it would be great if the interfacing between the jdbc+dbcp code and tomcat would be lighter and not dependent on much catalina internals. Costin On Tue, Oct 21, 2008 at 8:02 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: > On Tue, 2008-10-21 at 10:19 -0400, Yoav Shapira wrote: > > However, I don't think we should stick a connection pool > > implementation in Tomcat proper. It should go in Commons DbUtils, or > > DBCP, or another existing project. Heck, it can even start out on > > Google Code, idealy with an ASL license. > > > > I don't want to bloat Tomcat with extra stuff, no matter how good. > > I'd much rather remove stuff and keep the core way smaller. I really > > like what Costin is doing with his "Tomcat lite." > > So you would not even ship one "default" connection pool, as we do now ? > > Rémy > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Tomcat connection pool contribution
On Tue, Oct 21, 2008 at 9:00 AM, Filip Hanik - Dev Lists <[EMAIL PROTECTED] > wrote: > Yoav Shapira wrote: > >> On Tue, Oct 21, 2008 at 11:15 AM, Filip Hanik - Dev Lists >> <[EMAIL PROTECTED]> wrote: >> >> >>> I hear both of your concerns, and I will withdraw the proposal, thanks >>> for speaking up >>> >>> >> >> These are all good comments. Is it possible to package up in a way >> that core Tomcat does not depend on it, like Costin said? >> >> > sure is, tomcat doesn't depend on it today, the new dbcp depends on > tomcat-juli.jar, so the dependency is the other way > > > > I know the current DBCP packaging sucks, and that the current DBCP >> project is stagnant. That's why I said I'd use your new code. I >> don't want to lose it completely ;) >> >> > there are two questions two be answered > 1. what source repository does it sit in > 2. If it sits under the tomcat umbrella, is it released with tomcat or as > an independent module (like mod_jk, tcnative, etc) For 1 - I'm ok with all options ( separate svn or separate dir under tomcat - maybe even with placing it in the same source tree, but with excludes and separate build file) For 2 - I think independent module has the most advantages for both tomcat and the module. Costin > > > Filip > > Yoav >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[VOTE] Release build 4.1.38
The source tarball and other packages are available here: http://tomcat.apache.org/dev/dist/apache-tomcat-4.1.38/ According to the release process, the 4.1.38 tag is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 46051] New: Servlet response writer does not respect line.separator system property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46051
Summary: Servlet response writer does not respect line.separator
system property
Product: Tomcat 6
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: [EMAIL PROTECTED]
Created an attachment (id=22763)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22763)
remove special CoyoteWriter println handling
public void doGet(final HttpServletRequest request, final HttpServletResponse
response) throws ServletException, IOException {
response.setContentType("text/plain");
PrintWriter writer = response.getWriter();
writer.print("hello world");
writer.println(); //FIXME ignores System.getProperty("line.separator") and
always outputs \r\n
return;
}
This means that if you use a servlet Writer on a Unix system to output any text
based data format which is defined as requiring Unix format line endings
('\n'), that data will be corrupted.
This appears to be because org.apache.catalina.connector.CoyoteWriter does:
private static final char[] LINE_SEP = { '\r', '\n' };
public void println() {
write(LINE_SEP);
}
This used to work in Tomcat 4.
Looking at the old code at
http://svn.apache.org/repos/asf/tomcat/archive/tc4.0.x/tags/tc4.0.6/connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java
it appears to defer line endings to the PrintWriter base class which does the
right thing.
Was this change was made to output HTTP headers properly or something? It
specifically seems to override the default behavior to do this. I don't know
the code well enough to determine if the attached patch to revert to the
default behavior again would break something?
Thanks for your consideration.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706696 - in /tomcat/trunk: java/org/apache/tomcat/bayeux/ test/org/apache/cometd/bayeux/samples/ webapps/cometd/ webapps/cometd/WEB-INF/ webapps/cometd/examples/simplechat/
Author: fhanik
Date: Tue Oct 21 11:07:04 2008
New Revision: 706696
URL: http://svn.apache.org/viewvc?rev=706696&view=rev
Log:
work on the bayeux samples
Added:
tomcat/trunk/test/org/apache/cometd/bayeux/samples/BayeuxStockTicker.java
tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html
Modified:
tomcat/trunk/java/org/apache/tomcat/bayeux/BayeuxServlet.java
tomcat/trunk/java/org/apache/tomcat/bayeux/ClientImpl.java
tomcat/trunk/java/org/apache/tomcat/bayeux/RequestBase.java
tomcat/trunk/test/org/apache/cometd/bayeux/samples/EchoChatClient.java
tomcat/trunk/webapps/cometd/WEB-INF/web.xml
tomcat/trunk/webapps/cometd/index.html
Modified: tomcat/trunk/java/org/apache/tomcat/bayeux/BayeuxServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/bayeux/BayeuxServlet.java?rev=706696&r1=706695&r2=706696&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/bayeux/BayeuxServlet.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/bayeux/BayeuxServlet.java Tue Oct 21
11:07:04 2008
@@ -92,7 +92,7 @@
protected int getReconnectInterval() {
String rs = servletConfig.getInitParameter("reconnectInterval");
-int rct = 5000; //5 seconds
+int rct = 1000; //1 seconds
try {
rct = Integer.parseInt(rs);
}catch (NumberFormatException nfe) {
Modified: tomcat/trunk/java/org/apache/tomcat/bayeux/ClientImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/bayeux/ClientImpl.java?rev=706696&r1=706695&r2=706696&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/bayeux/ClientImpl.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/bayeux/ClientImpl.java Tue Oct 21
11:07:04 2008
@@ -115,9 +115,10 @@
//local clients must have a listener
ArrayList list = new ArrayList();
for (int i=0; msgs!=null && i0) {
getListener().deliver(list.toArray(new Message[0]));
}
} else {
Modified: tomcat/trunk/java/org/apache/tomcat/bayeux/RequestBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/bayeux/RequestBase.java?rev=706696&r1=706695&r2=706696&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/bayeux/RequestBase.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/bayeux/RequestBase.java Tue Oct 21
11:07:04 2008
@@ -76,7 +76,7 @@
protected static Log log = LogFactory.getLog(RequestBase.class);
-protected int reconnectInterval;
+protected int reconnectInterval = 1000;
protected RequestBase(TomcatBayeux tb, CometEvent event, JSONObject jsReq)
throws JSONException {
this.tomcatBayeux = tb;
Added: tomcat/trunk/test/org/apache/cometd/bayeux/samples/BayeuxStockTicker.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/cometd/bayeux/samples/BayeuxStockTicker.java?rev=706696&view=auto
==
--- tomcat/trunk/test/org/apache/cometd/bayeux/samples/BayeuxStockTicker.java
(added)
+++ tomcat/trunk/test/org/apache/cometd/bayeux/samples/BayeuxStockTicker.java
Tue Oct 21 11:07:04 2008
@@ -0,0 +1,215 @@
+package org.apache.cometd.bayeux.samples;
+
+import javax.servlet.ServletContextEvent;
+import javax.servlet.ServletContextListener;
+import javax.servlet.ServletContextAttributeListener;
+import javax.servlet.ServletContextAttributeEvent;
+import org.apache.cometd.bayeux.Bayeux;
+
+import java.text.DecimalFormat;
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.atomic.AtomicInteger;
+import org.apache.cometd.bayeux.Client;
+import org.apache.cometd.bayeux.Listener;
+import org.apache.cometd.bayeux.Message;
+import org.apache.cometd.bayeux.Channel;
+
+public class BayeuxStockTicker implements ServletContextListener,
+ServletContextAttributeListener, Listener {
+
+static AtomicInteger counter = new AtomicInteger(0);
+protected int id;
+protected Bayeux b;
+protected Client c;
+protected boolean alive = true;
+protected boolean initialized = false;
+protected TickerThread tt = new TickerThread();
+
+public BayeuxStockTicker() {
+id = counter.incrementAndGet();
+System.out.println("new listener created with id:" + id);
+}
+
+public void contextDestroyed(ServletContextEvent servletContextEvent) {
+alive = false;
+tt.run = false;
+tt.interrupt();
+}
+
+public void contextInitialized(ServletContextEvent servletContextEvent) {
+}
+
+public void attributeAdded(ServletContextAttributeEvent scae) {
+if (scae.getName().equals(Bayeux.DOJOX_COMETD_BAYEUX)) {
+if (initialized) return;
+
DO NOT REPLY [Bug 42409] Extra response headers not sent when using custom error page
https://issues.apache.org/bugzilla/show_bug.cgi?id=42409 Brian Curnow <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706726 - /tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html
Author: fhanik
Date: Tue Oct 21 12:16:15 2008
New Revision: 706726
URL: http://svn.apache.org/viewvc?rev=706726&view=rev
Log:
improve the stock ticker example
Modified:
tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html
Modified: tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html?rev=706726&r1=706725&r2=706726&view=diff
==
--- tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html (original)
+++ tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html Tue Oct 21
12:16:15 2008
@@ -3,6 +3,10 @@
Bayeux Stock Ticker
+
+ .red{background-color: red;}
+ .white{background-color: white;}
+
@@ -30,26 +34,6 @@
});
-function trim(str) {
-return str.replace(/(^\s+|\s+$)/g,'');
-}
-
-
-function clear() {
- dojo.byId("msgtext").value = "";
- dojo.byId("msgtext").focus();
-}
-
-
-function enterKeyHandler(e) {
-if (!e) e = window.event;
- if (e.keyCode == 13) {
- send(trim(dojo.byId("msgtext").value));
- clear();
- }
-
-}
-
function subscribe(box, symbol) {
if (box.checked) {
dojox.cometd.subscribe("/stock/"+symbol, onMsgEvent);
@@ -90,6 +74,19 @@
changelabel.value = pricechange;
pricenode.appendChild(pricelabel);
changenode.appendChild(changelabel);
+
+ var table = dojo.byId("stocktable");
+ var rows = table.getElementsByTagName("tr");
+ for(i = 0; i < rows.length; i++){
+ rows[i].bgColor = "white";
+ }
+ //manipulate rows
+ var rowCurrent = dojo.byId("row."+symbol);
+ if (pricechange<=0) {
+ rowCurrent.bgColor = "red";
+ } else {
+ rowCurrent.bgColor = "cyan";
+ }
}
@@ -99,29 +96,29 @@
Bayeux Stock Ticker
-
-
+
+
SYMBOL
PRICE
LAST CHANGE
SUBSCRIBE
-
+
SPRG
-
+
-
+
GOOG
-
+
-
+
YHOO
-
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 46051] Servlet response writer does not respect line.separator system property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46051
--- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-10-21 12:23:58 PST ---
The change is http://svn.apache.org/viewvc?view=rev&revision=298149
I am tempted to leave this as is. Whilst strict adherence to the PrintWriter
interface requires that System.getProperty("line.separator") is used, any truly
portable web application is going to have to write it's own new lines anyway to
be resilient against the case where it runs on a different platform.
If this was fixed, I would change the initialisation of LINE_SEP.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706729 - /tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html
Author: fhanik
Date: Tue Oct 21 12:27:36 2008
New Revision: 706729
URL: http://svn.apache.org/viewvc?rev=706729&view=rev
Log:
fancier now
Modified:
tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html
Modified: tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html?rev=706729&r1=706728&r2=706729&view=diff
==
--- tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html (original)
+++ tomcat/trunk/webapps/cometd/examples/simplechat/ticker.html Tue Oct 21
12:27:36 2008
@@ -3,10 +3,6 @@
Bayeux Stock Ticker
-
- .red{background-color: red;}
- .white{background-color: white;}
-
@@ -37,8 +33,12 @@
function subscribe(box, symbol) {
if (box.checked) {
dojox.cometd.subscribe("/stock/"+symbol, onMsgEvent);
+ var rowCurrent = dojo.byId("row."+symbol);
+ rowCurrent.bgColor="white";
} else {
dojox.cometd.unsubscribe("/stock/"+symbol, onMsgEvent);
+ var rowCurrent = dojo.byId("row."+symbol);
+ rowCurrent.bgColor="gray";
}
}
@@ -78,7 +78,9 @@
var table = dojo.byId("stocktable");
var rows = table.getElementsByTagName("tr");
for(i = 0; i < rows.length; i++){
- rows[i].bgColor = "white";
+ if (rows[i].bgColor != "gray") {
+ rows[i].bgColor = "white";
+ }
}
//manipulate rows
var rowCurrent = dojo.byId("row."+symbol);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 46051] Servlet response writer does not respect line.separator system property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46051 --- Comment #2 from Chris Hubick <[EMAIL PROTECTED]> 2008-10-21 12:50:48 PST --- I see where you are coming from, and somewhat agree - though I think there is value in strict adherance to the API. The decision is yours - I just wanted to make sure you were aware of it. Luckily, I had the code to this servlet and patched it to work around this. Just to note, we were actually bit by this bug when we upgraded from Tomcat 4 on our CAS ( http://www.ja-sig.org/products/cas/ ) central authentication server. The Yale CAS server code writes out XML using the response Writer, and after the upgrade this output then contained the additional '\r'. Of course, this technically shouldn't matter to the XML either, except that the old (2.0.10) mod_cas C client we are using on some old servers apparently doesn't use a real XML parser and breaks reading these line endings in. We can't upgrade the client in our legacy environment because their newer mod_auth_cas client requires a newer Apache. So, yeah, I patched the server to work as before, and we are working to upgrade all our old client servers, but as with any enterprise, that takes time. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE/SENSUS] connection pool
Let's get a feel for what we think we should do. Based on https://issues.apache.org/bugzilla/show_bug.cgi?id=46038 I believe (pick only one): a. [ ] It doesn't belong here, take it elsewhere b. [ ] Bring it here, we'll ship it with next major version of Tomcat c. [ ] Bring it here, we'll make it an independent module with its own release cycle d. [ ] I'm ok with any these option e. [ ] Lets discuss it some more, to bring more options to the table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE/SENSUS] connection pool
On Tue, Oct 21, 2008 at 4:05 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > Let's get a feel for what we think we should do. > > Based on > https://issues.apache.org/bugzilla/show_bug.cgi?id=46038 > > I believe (pick only one): > > a. [ ] It doesn't belong here, take it elsewhere > b. [ ] Bring it here, we'll ship it with next major version of Tomcat > c. [ X ] Bring it here, we'll make it an independent module with its own > release cycle Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE/SENSUS] connection pool
On Tue, Oct 21, 2008 at 1:05 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED] > wrote: > Let's get a feel for what we think we should do. > > Based on > https://issues.apache.org/bugzilla/show_bug.cgi?id=46038 > > I believe (pick only one): > > a. [ ] It doesn't belong here, take it elsewhere > b. [ ] Bring it here, we'll ship it with next major version of Tomcat > c. [X] Bring it here, we'll make it an independent module with its own > release cycle > d. [ ] I'm ok with any these option > e. [ ] Lets discuss it some more, to bring more options to the table Costin > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
svn commit: r706762 - /tomcat/sandbox/bz-svn/
Author: markt Date: Tue Oct 21 13:45:40 2008 New Revision: 706762 URL: http://svn.apache.org/viewvc?rev=706762&view=rev Log: testing svn-bz client side integration Added: tomcat/sandbox/bz-svn/ (with props) Propchange: tomcat/sandbox/bz-svn/ -- bugtraq:append = false Propchange: tomcat/sandbox/bz-svn/ -- --- bugtraq:message (added) +++ bugtraq:message Tue Oct 21 13:45:40 2008 @@ -0,0 +1 @@ +Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=%BUGID% Propchange: tomcat/sandbox/bz-svn/ -- bugtraq:url = https://issues.apache.org/bugzilla/show_bug.cgi?id=%BUGID% - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706763 - /tomcat/sandbox/bz-svn/test.txt
Author: markt Date: Tue Oct 21 13:47:40 2008 New Revision: 706763 URL: http://svn.apache.org/viewvc?rev=706763&view=rev Log: Test Added: tomcat/sandbox/bz-svn/test.txt (with props) Added: tomcat/sandbox/bz-svn/test.txt URL: http://svn.apache.org/viewvc/tomcat/sandbox/bz-svn/test.txt?rev=706763&view=auto == (empty) Propchange: tomcat/sandbox/bz-svn/test.txt -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r706764 - /tomcat/sandbox/bz-svn/test.txt
Author: markt Date: Tue Oct 21 13:48:30 2008 New Revision: 706764 URL: http://svn.apache.org/viewvc?rev=706764&view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46051 This is the only sentence I entered in the log message. Modified: tomcat/sandbox/bz-svn/test.txt Modified: tomcat/sandbox/bz-svn/test.txt URL: http://svn.apache.org/viewvc/tomcat/sandbox/bz-svn/test.txt?rev=706764&r1=706763&r2=706764&view=diff == --- tomcat/sandbox/bz-svn/test.txt (original) +++ tomcat/sandbox/bz-svn/test.txt Tue Oct 21 13:48:30 2008 @@ -0,0 +1 @@ +hello world \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE/SENSUS] connection pool
Filip Hanik - Dev Lists wrote: Let's get a feel for what we think we should do. Based on https://issues.apache.org/bugzilla/show_bug.cgi?id=46038 I believe (pick only one): a. [ ] It doesn't belong here, take it elsewhere b. [ ] Bring it here, we'll ship it with next major version of Tomcat c. [ ] Bring it here, we'll make it an independent module with its own release cycle d. [X] I'm ok with any these option e. [ ] Lets discuss it some more, to bring more options to the table Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE/SENSUS] connection pool
Filip Hanik - Dev Lists wrote: > Let's get a feel for what we think we should do. > > Based on > https://issues.apache.org/bugzilla/show_bug.cgi?id=46038 > > I believe (pick only one): > > a. [ ] It doesn't belong here, take it elsewhere > b. [ ] Bring it here, we'll ship it with next major version of Tomcat > c. [X] Bring it here, we'll make it an independent module with its own > release cycle > d. [ ] I'm ok with any these option > e. [ ] Lets discuss it some more, to bring more options to the table To caveat my vote: In the early days I think it makes sense to keep this separate as the module matures. This would enable a more rapid response to bugs than would be possible/desirable if it were packaged with a release. Once it is stable then I think we need to revist how it is packaged, possibly adding it to the standard Tomcat distro, maybe transferring it to the commons or db projects. (My expectation is that whilst Tomcat 7.x will be more modular, the stable modules will be packaged together to keep release management / version numbering simple but that is a debate for another time.) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE/SENSUS] connection pool
On Tue, 2008-10-21 at 14:05 -0600, Filip Hanik - Dev Lists wrote: > c. [X] Bring it here, we'll make it an independent module with its own > release cycle And it could replace dbcp once it is tested, but you should probably look at moving the code elsewhere eventually. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
