Re: [VOTE] Send trunk to the sandbox

[Henri Gomez]

+0, could we see the pros and cons ?

2007/8/20, Bill Barker <[EMAIL PROTECTED]>:
> I'm so tired of this thread, so let's settle it once and for all.  I'm
> backing Remy's suggestion to send the current trunk to the sandbox:
> [ ] +1 Let's end the revolution
> [ ] +0 What revolution?
> [ ] -1 Viva the revolultion
>
> My vote is +1.
>
>
>
>
> -
> 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] Send trunk to the sandbox

[jean-frederic clere]

Bill Barker wrote:
> I'm so tired of this thread, so let's settle it once and for all.  I'm 
> backing Remy's suggestion to send the current trunk to the sandbox:
> [X] +1 Let's end the revolution

I would also propose that we take an handling of releases similar to httpd.
See http://svn.apache.org/repos/asf/httpd/httpd/

branches contains the productions branches and the experimental
developpemnt branches.

trunk contains the place where the commmun developement and the new
agreed features and bugs fixes are going.
To move something from the "experimental developpement branches" to
trunk (or to a production branche) we vote it. (in a file named STATUS)
once accepted (no -1) the stuff enters the production or trunk. If
someone starts something in trunk and gets a -1 he should create a new
branche with the new code and propose a vote to get it back in trunk.

What does that means.
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ will be moved to
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/comet_dev (or
filip_dev)
A new http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ (or  better
http://svn.apache.org/repos/asf/tomcat/trunk/) will be created there we
put what we agree to put for the actual trunk (by voting).
Everyone that when to try something could try it in a new branche.

Comments?

Cheers

Jean-Frederic

> [ ] +0 What revolution?
> [ ] -1 Viva the revolultion
> 
> My vote is +1.
> 
> 
> 
> 
> -
> 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] Send trunk to the sandbox

[Henri Gomez]

+1

Good idea to get the httpd release handling, a big +1.

I'll be more confortable with more eyes (commiters) on a new piece of code

2007/8/20, jean-frederic clere <[EMAIL PROTECTED]>:
> Bill Barker wrote:
> > I'm so tired of this thread, so let's settle it once and for all.  I'm
> > backing Remy's suggestion to send the current trunk to the sandbox:
> > [X] +1 Let's end the revolution
>
> I would also propose that we take an handling of releases similar to httpd.
> See http://svn.apache.org/repos/asf/httpd/httpd/
>
> branches contains the productions branches and the experimental
> developpemnt branches.
>
> trunk contains the place where the commmun developement and the new
> agreed features and bugs fixes are going.
> To move something from the "experimental developpement branches" to
> trunk (or to a production branche) we vote it. (in a file named STATUS)
> once accepted (no -1) the stuff enters the production or trunk. If
> someone starts something in trunk and gets a -1 he should create a new
> branche with the new code and propose a vote to get it back in trunk.
>
> What does that means.
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ will be moved to
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/comet_dev (or
> filip_dev)
> A new http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ (or  better
> http://svn.apache.org/repos/asf/tomcat/trunk/) will be created there we
> put what we agree to put for the actual trunk (by voting).
> Everyone that when to try something could try it in a new branche.
>
> Comments?
>
> Cheers
>
> Jean-Frederic
>
> > [ ] +0 What revolution?
> > [ ] -1 Viva the revolultion
> >
> > My vote is +1.
> >
> >
> >
> >
> > -
> > 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]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: POJO Application Server for Tomcat

[Johnny Kewl]

- Original Message - 
From: "Smith Norton" <[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Sent: Monday, August 20, 2007 7:05 AM
Subject: Re: POJO Application Server for Tomcat



I am still waiting for this response. Could you please tell us why is
this specific to Tomcat?


Sorry I live on the other side of the world, I was sleeping ;)
In theory, its not, its a servlet and thus should run on any servlet 
container, but its one hell of a servlet, and internally there is some 
serious class loader stuff going on. A little like having Tomcat run inside 
Tomcat, if that makes sense. It also uses TC's security setup and thats 
preconfigured in WEB.xml and I imagine a little different on other 
containers, so users may find that a hassle factor.


It's certified for Tomcat really just because thats the only servlet 
container we use... and my way of giving back, yes I do want new comers to 
come to the TC mailing lists. Or let me say it this way, I could have taken 
the tomcat code and combined it with this servlet internally and then given 
it the name of some fish, but I wanted all credits to come back to TC for 
the servlet container... so maybe its just misguided loyalty ;)


But there is a technical reason as well, when class loaders run inside class 
loaders, or class loaders run inside another container, it really brings out 
issues with the underlying class loaders inside a container.  So I feel it 
should be tested carefully on any other servlet container.
I havnt tested on other servlet containers, because I think half of them run 
on TC code anyway, not much of a test, but if you want to see a container 
fail, try make WebStart use an RMI program, or a program that has its own 
class loaders... it will likely fail.
When testing I actually ran TC from the source and traced into TC just to 
make sure classloaders were doing the right thing, they do, fortunately.


So there is a degree of caution, and a whole lot of loyalty ;)
By all means if you use something else, try it but I do have a feeling 
the security side may need a rework of the configuration, and may not work 
at all because it twists normal web security to protect classes, so that one 
can protect access to their applications.




On 8/20/07, Lilianne E. Blaze <[EMAIL PROTECTED]> wrote:

Hello,
Be more specific please? What problems does it solve?
How is that specific to Tomcat, instead of just any servlet container?



-
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: svn commit: r567298 - /tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/

[Takayuki Kaneko]

Hi Peter,

I'd like to point out that some attributes contains "(msec)" in the name.
If it was a mistake, I made a patch.

Regards,

- Takayuki

Index: 
/container/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
===
--- 
/container/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
 (revision
567470)
+++ 
/container/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
 (working
copy)
@@ -170,8 +170,8 @@
   description="received processing time (msec)"
  type="long"
  writeable="false"/>
-
 
-
  wrote:
> Author: pero
> Date: Sat Aug 18 10:14:07 2007
> New Revision: 567298
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=567298
> Log:
> Fix some timeout regression bugs with 5.5.23 and the new advanced socket 
> config.
>
> Modified:
> 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ClusterReceiverBase.java
> 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/DataSender.java
> 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ReplicationListener.java
> 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/SocketReplicationListener.java
> 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/SocketReplicationThread.java
> 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
>
> Modified: 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ClusterReceiverBase.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ClusterReceiverBase.java?view=diff&rev=567298&r1=567297&r2=567298
> ==
> --- 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ClusterReceiverBase.java
>  (original)
> +++ 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ClusterReceiverBase.java
>  Sat Aug 18 10:14:07 2007
> @@ -102,7 +102,7 @@
>  private boolean soLingerOn = true;
>  private int soLingerTime = 3;
>  private int soTrafficClass = 0x04 | 0x08 | 0x010;
> -private int timeout = 3000; //3 seconds
> +private int timeout = -1; // Regression with older release, better set 
> timeout at production env
>
>  /**
>   * Compress message data bytes
>
> Modified: 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/DataSender.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/DataSender.java?view=diff&rev=567298&r1=567297&r2=567298
> ==
> --- 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/DataSender.java
>  (original)
> +++ 
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/DataSender.java
>  Sat Aug 18 10:14:07 2007
> @@ -94,7 +94,7 @@
>
>  private int rxBufSize = 25188;
>  private int txBufSize = 43800;
> -private long timeout = 3000;
> +private int timeout = 3;
>  private boolean tcpNoDelay = true;
>  private boolean soKeepAlive = false;
>  private boolean ooBInline = true;
> @@ -221,7 +221,7 @@
>  /**
>   * After failure make a resend
>   */
> -private boolean resend = false ;
> +private boolean resend = true ;
>
>  // - 
> Constructor
>
> @@ -627,7 +627,7 @@
>   * @return the timeout
>   * @since 5.5.25
>   */
> -public long getTimeout() {
> +public int getTimeout() {
>  return timeout;
>  }
>
> @@ -635,7 +635,7 @@
>   * @param timeout the timeout to set
>   * @since 5.5.25
>   */
> -public void setTimeout(long timeout) {
> +public void setTimeout(int timeout) {
>  this.timeout = timeout;
>  }
>
> @@ -666,7 +666,7 @@
>   * @deprecated since 5.5.25 use timeout instead
>   */
>  public void setAckTimeout(long ackTimeout) {
> -this.timeout = ackTimeout;
> +this.timeout = (int)ackTimeout;
>  }
>
>  public long getKeepAliveTimeout() {
> @@ -892,15 +892,15 @@
>  protected void createSocket() throws IOException, SocketException {
>  SocketAddress sockAddr = new InetSocketAddress(getAddress(), 
> getPort());
>  socket = new Socket();
> -int timeout = (int) getTimeout();
> +int timeout = getTimeout();
>  if (timeout > 0) {
> socket.connect(sockAddr, timeout);
> +   socket.setSoTimeout(timeou

Re: POJO Application Server for Tomcat

[Johnny Kewl]

- Original Message - 
From: "George MATKOVITS" <[EMAIL PROTECTED]>

To: 
Sent: Monday, August 20, 2007 7:29 AM
Subject: Re: POJO Application Server for Tomcat



I like its Java Application/Java Class like behavior. Unfortunately it
seems to miss probably the EJB's most important function: 'Transaction
Support'. Please describe how to add or point to some documentation.
Thank you -- George


Thanks George, I will be posting some examples of the way we do it, its a
pure POJO approach, name we do transactions using dB engines, there is no
concept of an entity bean as such in POJO. It amounts to a library that one
uses, as does a database pool.
Listen I'll be happy to answer any questions, but I think for specific
issues on Harbor its better is people just mail me direct, Harbor exists
because of Tomcat, but I dont want to kidnap the Tomcat mailing lists, I
havnt setup a mailing list for harbor yet, but I will.
It kinda cool though huh ;)





Original Message Follows
From: "Lilianne E. Blaze" <[EMAIL PROTECTED]>
Reply-To: "Tomcat Developers List" 
To: Tomcat Developers List 
Subject: Re: POJO Application Server for Tomcat
Date: Sun, 19 Aug 2007 21:55:41 +0200
MIME-Version: 1.0
Received: from mail.apache.org ([140.211.11.2]) by
bay0-mc7-f22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun,
19 Aug 2007 12:56:14 -0700
Received: (qmail 27609 invoked by uid 500); 19 Aug 2007 19:56:05 -
Received: (qmail 27598 invoked by uid 99); 19 Aug 2007 19:56:05 -
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Aug 2007 12:56:05 -0700
Received: pass (nike.apache.org: domain of [EMAIL PROTECTED]
designates 193.17.41.142 as permitted sender)
Received: from [193.17.41.142] (HELO poczta.o2.pl) (193.17.41.142)by
apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Aug 2007 19:56:29 +
Received: from poczta.o2.pl (mx12 [127.0.0.1])by poczta.o2.pl (Postfix)
with ESMTP id DADA93E80C2for ; Sun, 19 Aug 2007
21:55:38 +0200 (CEST)
Received: from [82.210.169.62] (62-mo4-2.acn.waw.pl [82.210.169.62])by
poczta.o2.pl (Postfix) with ESMTPfor ; Sun, 19 Aug
2007 21:55:38 +0200 (CEST)
X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w
X-Message-Info:
R00BdL5giqoOmdk4EwMMUOZg9GLUfyAG82u/Ccb1L0a5JmnPzFJioIXKJICIknaaLfTti6qC8cwlNkMQgsRMyQ==
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Help: 
List-Unsubscribe: 
List-Post: 
List-Id: 
Delivered-To: mailing list dev@tomcat.apache.org
X-ASF-Spam-Status: No, hits=-0.0 required=10.0tests=SPF_PASS
X-Spam-Check-By: apache.org
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
References: <[EMAIL PROTECTED]>
X-Virus-Checked: Checked by ClamAV on apache.org
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 19 Aug 2007 19:56:14.0832 (UTC)
FILETIME=[FFD4B700:01C7E29A]

Hello,
Be more specific please? What problems does it solve?
How is that specific to Tomcat, instead of just any servlet container?

Greetings, Lilianne E. Blaze

Johnny Kewl wrote:
> I'd like to show you guys something that I think may blow your minds.
>
> Firstly let me just say that I call myself a hobbyist, dont consider
myself in the same league as the guru's that work on Tomcat and Apache,
but I do spend an enormous amount of time playing with technology. One can
almost measure how much I like a technology by how much time I stay in the
mailing lists, on Postgresql I think it was 3 months, and I really like
that product, on Tomcat it must be close to a year and still counting,
what a fantastic product.
>
> In our office Tomcat is now officially the delivery mechanism for
everything.
>  First I was impressed with Tomcats web abilities, then more and more
with its container ability, we discovered that it can run any code, and
even if it wasnt intended for the web, we started sticking applications
into Tomcat anywaythat idea has now come a long way.
>
> I call it a POJO Application server, I've mentioned before that we
actually popping full java applications out of browsers, but then it was
very much something only I could use, messy libraries etc. What I've done
now is (try) make a more professional package, and it would be really nice
if the guru's just have a little read about this unbelievable servlet, and
let me know what you think, if just to see how someone is using your
Tomcat, in a very unusual way.
>
> As you will see, I dont like EJB containers, but I love Tomcat, and it
was almost inevitable that this would happen.
> All I will say is that this is no ordinary application server... not
unless I missed something and you can also just drop a POJO application
into the others and make it remoteable.
>
> I think its a new way of looking at application servers, it feels like a
discovery to me, but then who knows maybe there is something out there
like this, I dont know, all I do know is that when we drop this se

Re: POJO Application Server for Tomcat

[George MATKOVITS]

Just please post a generic example for  one of your favorite 'Open Source' 
Data Base engines! That would be more than enough! Thank you -- George


PS. Many years ago I used to be a committer on Apache but for the last few 
years I just watched the various stuff flowing bye! IMHO there is some 
bandwidth left for  nice KISS stuff! Frankly EJBs are too complicated for 
the average VB programmer and that is why they do not migrate to nice cheap 
'universal' Java on Linux! We either do something about it or Java is going 
to die! Life ether advances or shrinks to nothing! Your POJO just might do 
it for Java! EJB people tend to be a bunch of stuck up Aristocrats! Just 
please keep on ignoring them! Did you talk to anyone at Sun? Any application 
could be written in POJO if transactionality for Data Base access could be 
easily added in!  Even Sun People like to keep on eating! They might even 
standardize some of your interfaces.


Original Message Follows
From: "Johnny Kewl" <[EMAIL PROTECTED]>
Reply-To: "Tomcat Developers List" 
To: "Tomcat Developers List" 
Subject: Re: POJO Application Server for Tomcat
Date: Mon, 20 Aug 2007 10:31:31 +0200
MIME-Version: 1.0
Received: from mail.apache.org ([140.211.11.2]) by 
bay0-mc6-f7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 20 
Aug 2007 01:32:07 -0700

Received: (qmail 75957 invoked by uid 500); 20 Aug 2007 08:32:01 -
Received: (qmail 75944 invoked by uid 99); 20 Aug 2007 08:32:01 -
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)by 
apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Aug 2007 01:32:01 -0700

Received: neutral (nike.apache.org: local policy)
Received: from [196.25.240.77] (HELO ctb-mesg7.saix.net) (196.25.240.77)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Aug 2007 08:32:24 +
Received: from animal (dsl-243-65-79.telkomadsl.co.za [41.243.65.79])by 
ctb-mesg7.saix.net (Postfix) with SMTP id 033BF3261for 
; Mon, 20 Aug 2007 10:31:12 +0200 (SAST)
X-Message-Info: 
HKIYGN+H3D+QShLNGWNUtb8urlI/48fz0WaMEa4yBu+RyfrTjlCA4aE3ynsoZEQuEf2GPiKHGKQ=

Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Help: 
List-Unsubscribe: 
List-Post: 
List-Id: 
Delivered-To: mailing list dev@tomcat.apache.org
X-ASF-Spam-Status: No, hits=0.2 
required=10.0tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL

X-Spam-Check-By: apache.org
References: <[EMAIL PROTECTED]>
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Antivirus: avast! (VPS 000757-4, 2007/07/18), Outbound message
X-Antivirus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 20 Aug 2007 08:32:07.0733 (UTC) 
FILETIME=[98443650:01C7E304]



- Original Message - From: "George MATKOVITS" <[EMAIL PROTECTED]>
To: 
Sent: Monday, August 20, 2007 7:29 AM
Subject: Re: POJO Application Server for Tomcat



I like its Java Application/Java Class like behavior. Unfortunately it
seems to miss probably the EJB's most important function: 'Transaction
Support'. Please describe how to add or point to some documentation.
Thank you -- George


Thanks George, I will be posting some examples of the way we do it, its a
pure POJO approach, name we do transactions using dB engines, there is no
concept of an entity bean as such in POJO. It amounts to a library that one
uses, as does a database pool.
Listen I'll be happy to answer any questions, but I think for specific
issues on Harbor its better is people just mail me direct, Harbor exists
because of Tomcat, but I dont want to kidnap the Tomcat mailing lists, I
havnt setup a mailing list for harbor yet, but I will.
It kinda cool though huh ;)





Original Message Follows
From: "Lilianne E. Blaze" <[EMAIL PROTECTED]>
Reply-To: "Tomcat Developers List" 
To: Tomcat Developers List 
Subject: Re: POJO Application Server for Tomcat
Date: Sun, 19 Aug 2007 21:55:41 +0200
MIME-Version: 1.0
Received: from mail.apache.org ([140.211.11.2]) by
bay0-mc7-f22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun,
19 Aug 2007 12:56:14 -0700
Received: (qmail 27609 invoked by uid 500); 19 Aug 2007 19:56:05 -
Received: (qmail 27598 invoked by uid 99); 19 Aug 2007 19:56:05 -
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Aug 2007 12:56:05 -0700
Received: pass (nike.apache.org: domain of [EMAIL PROTECTED]
designates 193.17.41.142 as permitted sender)
Received: from [193.17.41.142] (HELO poczta.o2.pl) (193.17.41.142)by
apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Aug 2007 19:56:29 +
Received: from poczta.o2.pl (mx12 [127.0.0.1])by poczta.o2.pl (Postfix)
with ESMTP id DADA93E80C2for ; Sun, 19 Aug 2007
21:55:38 +0200 (CEST)
Received: from [82.210.169.62] (62-mo4-2.acn.waw.pl [82.210.169.62])by
pocz

Re: [VOTE] Send trunk to the sandbox

[Remy Maucherat]

jean-frederic clere wrote:

Bill Barker wrote:
I'm so tired of this thread, so let's settle it once and for all.  I'm 
backing Remy's suggestion to send the current trunk to the sandbox:

[X] +1 Let's end the revolution


I would also propose that we take an handling of releases similar to httpd.
See http://svn.apache.org/repos/asf/httpd/httpd/

branches contains the productions branches and the experimental
developpemnt branches.

trunk contains the place where the commmun developement and the new
agreed features and bugs fixes are going.
To move something from the "experimental developpement branches" to
trunk (or to a production branche) we vote it. (in a file named STATUS)
once accepted (no -1) the stuff enters the production or trunk. If
someone starts something in trunk and gets a -1 he should create a new
branche with the new code and propose a vote to get it back in trunk.

What does that means.
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ will be moved to
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/comet_dev (or
filip_dev)
A new http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ (or  better
http://svn.apache.org/repos/asf/tomcat/trunk/) will be created there we
put what we agree to put for the actual trunk (by voting).
Everyone that when to try something could try it in a new branche.

Comments?


Since the community is a bit small, it could be useful to precise that a 
single +1 (from the committer who proposes the commit) is enough for a 
commit to go through, rather than the usual 3 +1s.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Send trunk to the sandbox

[jean-frederic clere]

Remy Maucherat wrote:
> jean-frederic clere wrote:
>> Bill Barker wrote:
>>> I'm so tired of this thread, so let's settle it once and for all. 
>>> I'm backing Remy's suggestion to send the current trunk to the sandbox:
>>> [X] +1 Let's end the revolution
>>
>> I would also propose that we take an handling of releases similar to
>> httpd.
>> See http://svn.apache.org/repos/asf/httpd/httpd/
>>
>> branches contains the productions branches and the experimental
>> developpemnt branches.
>>
>> trunk contains the place where the commmun developement and the new
>> agreed features and bugs fixes are going.
>> To move something from the "experimental developpement branches" to
>> trunk (or to a production branche) we vote it. (in a file named STATUS)
>> once accepted (no -1) the stuff enters the production or trunk. If
>> someone starts something in trunk and gets a -1 he should create a new
>> branche with the new code and propose a vote to get it back in trunk.
>>
>> What does that means.
>> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ will be moved to
>> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/comet_dev (or
>> filip_dev)
>> A new http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ (or  better
>> http://svn.apache.org/repos/asf/tomcat/trunk/) will be created there we
>> put what we agree to put for the actual trunk (by voting).
>> Everyone that when to try something could try it in a new branche.
>>
>> Comments?
> 
> Since the community is a bit small, it could be useful to precise that a
> single +1 (from the committer who proposes the commit) is enough for a
> commit to go through, rather than the usual 3 +1s.

Well my idea was to force two other committers to review a proposal
before it gets/returns in the "stable/released" code. Allowing only one
+1 from the initial committer to get the code in (or back) prevents this.

Cheers

Jean-Frederic

> 
> Rémy
> 
> -
> 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] Send trunk to the sandbox

[Remy Maucherat]

jean-frederic clere wrote:

Comments?

Since the community is a bit small, it could be useful to precise that a
single +1 (from the committer who proposes the commit) is enough for a
commit to go through, rather than the usual 3 +1s.


Well my idea was to force two other committers to review a proposal
before it gets/returns in the "stable/released" code. Allowing only one
+1 from the initial committer to get the code in (or back) prevents this.


Ok. I think it can work, but it's a tougher requirement.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: POJO Application Server for Tomcat

[Johnny Kewl]

- Original Message - 
From: "George MATKOVITS" <[EMAIL PROTECTED]>

To: 
Sent: Monday, August 20, 2007 11:30 AM
Subject: Re: POJO Application Server for Tomcat


Just please post a generic example for  one of your favorite 'Open Source' 
Data Base engines! That would be more than enough! Thank you -- George


PS. Many years ago I used to be a committer on Apache but for the last few 
years I just watched the various stuff flowing bye! IMHO there is some 
bandwidth left for  nice KISS stuff! Frankly EJBs are too complicated for 
the average VB programmer and that is why they do not migrate to nice 
cheap 'universal' Java on Linux! We either do something about it or Java 
is going to die! Life ether advances or shrinks to nothing! Your POJO just 
might do it for Java! EJB people tend to be a bunch of stuck up 
Aristocrats! Just please keep on ignoring them! Did you talk to anyone at 
Sun? Any application could be written in POJO if transactionality for Data 
Base access could be easily added in!  Even Sun People like to keep on 
eating! They might even standardize some of your interfaces.


And I thought I didnt like EJB containers ha ha.
I would have just said, there does seem to be an uprising on the web against 
Super-Cans, they just too complex.
George I have a POJO class that is a dB pool, allows for transactions and 
does persistence... all POJO style and its

easier than saying EJB specification ;)
Thing about POJO libs is that they not worth a thing without a sample so 
you making me work, but it you

can wait just 2 days... I'll have the sample code for that on the site.
The library is tiny, and it will be posted as source so you can see how it 
actually all works, and change it if you like.

Best I can do


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Send trunk to the sandbox

[Jim Jagielski]

On Aug 20, 2007, at 5:38 AM, Remy Maucherat wrote:



Since the community is a bit small, it could be useful to precise  
that a single +1 (from the committer who proposes the commit) is  
enough for a commit to go through, rather than the usual 3 +1s.




If the community is so small as to not be able to scour up three
+1s, then the community is in trouble...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r567689 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

[hgomez]

Author: hgomez
Date: Mon Aug 20 06:16:13 2007
New Revision: 567689

URL: http://svn.apache.org/viewvc?rev=567689&view=rev
Log:
Fix for send_bodyct on i5/OS. The problem was in jk (not flushing) and not on 
IBM implementation (my bad)

Modified:
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=567689&r1=567688&r2=567689&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Mon Aug 20 06:16:13 
2007
@@ -319,12 +319,6 @@
 /* ap_send_http_header(r); */
 p->response_started = JK_TRUE;
 
-   /* [EMAIL PROTECTED]: under i5/OS this flag is not set correctly */
-   /* We should check with Rochester Labs what could be the problem */
-#ifdef AS400
-r->sent_bodyct = 1;
-#endif
-
 return JK_TRUE;
 }
 
@@ -375,7 +369,7 @@
 
 static void JK_METHOD ws_flush(jk_ws_service_t *s)
 {
-#ifndef AS400
+#if ! (defined(AS400) && !defined(AS400_UTF8))
 if (s && s->ws_private) {
 apache_private_data_t *p = s->ws_private;
 ap_rflush(p->r);
@@ -423,7 +417,7 @@
 }
 }
 if (p->r->header_only) {
-#ifndef AS400
+#if ! (defined(AS400) && !defined(AS400_UTF8))
 ap_rflush(p->r);
 #endif
 return JK_TRUE;
@@ -2248,8 +2242,6 @@
 /* If tomcat returned no body and the status is not OK,
let apache handle the error code */
 
-/* [EMAIL PROTECTED] : under i5/OS sent_bodyct is not set correctly */
-/*   check for header_only to see if there was a body */
 if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST) {
 jk_log(xconf->log, JK_LOG_INFO, "No body with status=%d"
" for worker=%s",



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Send trunk to the sandbox

[Remy Maucherat]

Jim Jagielski wrote:

On Aug 20, 2007, at 5:38 AM, Remy Maucherat wrote:

Since the community is a bit small, it could be useful to precise that 
a single +1 (from the committer who proposes the commit) is enough for 
a commit to go through, rather than the usual 3 +1s.


If the community is so small as to not be able to scour up three
+1s, then the community is in trouble...


Yes, I now think it works, but that's what I had understood initially.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r567714 - /tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java

[fhanik]

Author: fhanik
Date: Mon Aug 20 07:25:14 2007
New Revision: 567714

URL: http://svn.apache.org/viewvc?rev=567714&view=rev
Log:
improved upon the existing virtualwebapploader,
new feature: can configure the path separator
new feature: can create a local repository for runtime
new feature: jar files are added as addJar to prevent locking of files


Modified:
tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java

Modified: tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java?rev=567714&r1=567713&r2=567714&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java Mon 
Aug 20 07:25:14 2007
@@ -17,9 +17,14 @@
 package org.apache.catalina.loader;
 
 import java.io.File;
+import java.util.ArrayList;
 import java.util.StringTokenizer;
+import java.util.jar.JarFile;
 
 import org.apache.catalina.LifecycleException;
+import org.apache.catalina.startup.ExpandWar;
+import org.apache.juli.logging.Log;
+import org.apache.juli.logging.LogFactory;
 
 /**
  * Simple webapp classloader that allows a customized classpath to be added
@@ -27,11 +32,22 @@
  * added to the default webapp classpath, making easy to emulate a standard
  * webapp without the need for assembly all the webapp dependencies as jars in
  * WEB-INF/lib.
+ * 
+ * The VirtualWebappLoader will add directories and regular files as 
org.apache.catalina.Loader.addRepository
+ * Jar files, or files ending with .jar, file be added as 
org.apache.catalina.loader.WebappClassLoader.addJar
+ * 
+ * If the attribute makeLocalCopy is set to true, the VirtualWebappLoader will 
make a local copy of the 
+ * virtual class path into the java.io.tmpdir directory, so that webapps can 
point to the same master repository,
+ * but be kept separate during runtime.
+ * 
+ * The separator for the virtualClasspath defaulted to ; but can be configured 
using the separator attribute
  *
  * 
  * 
  *   
+ *  virtualClasspath="\dir\classes:\somedir\somejar.jar"
+ *  makeLocalCopy="true"
+ *  separator=":"/>
  * 
  * 
  *
@@ -42,17 +58,33 @@
  *
  *
  *
+ * @author Filip Hanik
  * @author Fabrizio Giustina
  * @version $Id: $
  */
 public class VirtualWebappLoader extends WebappLoader {
 
+public static final Log log = LogFactory.getLog(VirtualWebappLoader.class);
 /**
  * ; separated list of additional path elements.
  */
 private String virtualClasspath = "";
 
 /**
+ * Should we make a copy of the libraries upon startup
+ */
+protected boolean makeLocalCopy = false;
+
+/**
+ * The location of the libraries.
+ */
+protected File tempDir = null;
+
+/**
+ * The path seperator
+ */
+protected String separator = ";";
+/**
  * Construct a new WebappLoader with no defined parent class loader (so 
that
  * the actual parent will be the system class loader).
  */
@@ -80,11 +112,36 @@
 virtualClasspath = path;
 }
 
+public void setMakeLocalCopy(boolean makeLocalCopy) {
+this.makeLocalCopy = makeLocalCopy;
+}
+
+public void setSeparator(String separator) {
+this.separator = separator;
+}
+
 @Override
 public void start() throws LifecycleException {
+if (log.isInfoEnabled()) log.info("Starting VirtualWebappLoader 
for:"+getContainer().getName());
+ArrayList jarFiles = new ArrayList();
+
 // just add any jar/directory set in virtual classpath to the
 // repositories list before calling start on the standard WebappLoader
-StringTokenizer tkn = new StringTokenizer(virtualClasspath, ";");
+if (makeLocalCopy) {
+tempDir = new File(System.getProperty("java.io.tmpdir"), 
"VirtualWebappLoader-"+System.identityHashCode(this));
+if (log.isDebugEnabled()) log.debug("Creating temporary directory 
for virtual classpath:"+tempDir.getAbsolutePath());
+if (tempDir.exists()) {
+if (log.isDebugEnabled()) log.debug("Temporary directory 
exists, will clean out the old one.");
+boolean result = false;
+if (tempDir.isDirectory())
+result = ExpandWar.deleteDir(tempDir);
+else
+result = ExpandWar.delete(tempDir);
+if (!result) throw new LifecycleException("Unable to create 
temp dir for virtual app loader:"+tempDir.getAbsolutePath());
+}
+tempDir.mkdirs();
+}
+StringTokenizer tkn = new

Re: [VOTE] Send trunk to the sandbox

[Filip Hanik - Dev Lists]

[X] +0 What revolution?

everything is backwards compatible, even Comet, if you take a 6.0.x 
comet app, it would work in trunk, there was just new features added
I think this whole thing is a big shame, there was no revolution going 
on here. not a single thing in trunk is, and now, we are simply going to 
have to redo it all over again.


Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Send trunk to the sandbox

[Henri Gomez]

And what about using a modular design 'à la http modules' ?

2007/8/20, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>:
> [X] +0 What revolution?
>
> everything is backwards compatible, even Comet, if you take a 6.0.x
> comet app, it would work in trunk, there was just new features added
> I think this whole thing is a big shame, there was no revolution going
> on here. not a single thing in trunk is, and now, we are simply going to
> have to redo it all over again.
>
> 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] Send trunk to the sandbox

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

[X] +0 What revolution?

everything is backwards compatible, even Comet, if you take a 6.0.x 
comet app, it would work in trunk, there was just new features added


Given the additional calls that were added, it didn't look to me it was 
compatible. Regardless, it's still a non approved proposal that is kept 
in an official sounding branch (the vote would be to rename the branch 
from "trunk" to "filip_trunk").


I think this whole thing is a big shame, there was no revolution going 
on here. not a single thing in trunk is, and now, we are simply going to 
have to redo it all over again.


Given the likely patch process update, it would have to be done over 
again anyway. I don't see this many patches which were not also mirrored 
in 6.0.x.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Send trunk to the sandbox

[Yoav Shapira]

Hey,

On 8/20/07, Bill Barker <[EMAIL PROTECTED]> wrote:
> I'm so tired of this thread, so let's settle it once and for all.  I'm
> backing Remy's suggestion to send the current trunk to the sandbox:
> [ ] +1 Let's end the revolution
> [ X ] +0 What revolution?

+0 on this specific proposal.

-1 on mixing up this proposal with various other options, like
adopting httpd-style branches, or release numbers.  Those might be
worthy issues, but let's keep one VOTE thread for one issue, please.

Yoav

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Send trunk to the sandbox

[Filip Hanik - Dev Lists]

Henri Gomez wrote:

And what about using a modular design 'à la http modules' ?
  
not sure what you mean, but if you are referring to the "6.x wishlist", 
none of those items are implemented, and were brought up as proposals 
for consensus.

no revolution here either

Filip

2007/8/20, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>:
  

[X] +0 What revolution?

everything is backwards compatible, even Comet, if you take a 6.0.x
comet app, it would work in trunk, there was just new features added
I think this whole thing is a big shame, there was no revolution going
on here. not a single thing in trunk is, and now, we are simply going to
have to redo it all over again.

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]



  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Send trunk to the sandbox

[Jim Jagielski]

On Aug 20, 2007, at 11:13 AM, Remy Maucherat wrote:


Filip Hanik - Dev Lists wrote:

[X] +0 What revolution?
everything is backwards compatible, even Comet, if you take a  
6.0.x comet app, it would work in trunk, there was just new  
features added


Given the additional calls that were added, it didn't look to me it  
was compatible. Regardless, it's still a non approved proposal that  
is kept in an official sounding branch (the vote would be to rename  
the branch from "trunk" to "filip_trunk").




What would become trunk?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r567689 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

[Rainer Jung]

Hi Henri,

so now i5/OS should use send_bodyct like the other platforms. What I 
don't understand is:


[EMAIL PROTECTED] wrote:

@@ -375,7 +369,7 @@
 
 static void JK_METHOD ws_flush(jk_ws_service_t *s)

 {
-#ifndef AS400
+#if ! (defined(AS400) && !defined(AS400_UTF8))
 if (s && s->ws_private) {
 apache_private_data_t *p = s->ws_private;
 ap_rflush(p->r);
@@ -423,7 +417,7 @@
 }
 }
 if (p->r->header_only) {
-#ifndef AS400
+#if ! (defined(AS400) && !defined(AS400_UTF8))
 ap_rflush(p->r);
 #endif
 return JK_TRUE;



This looks like, if we have i5/OS and not UTF8, then we still won't use 
the flush. But without flush I think, that send_bodyct will not be set.


Can't you simply call the ap_rflush() for that platform exactly the same 
way, as for the other platforms?


Regards,

Rainer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: POJO Application Server for Tomcat

[Leon Rosenberg]

On 8/19/07, Johnny Kewl <[EMAIL PROTECTED]> wrote:
>
> I call it a POJO Application server, I've mentioned before that we actually 
> popping full java >applications out of browsers, but then it was very much 
> something only I could use, messy >libraries etc. What I've done now is (try) 
> make a more professional package, and it would be >really nice if the guru's 
> just have a little read about this unbelievable servlet, and let me >know 
> what you think, if just to see how someone is using your Tomcat, in a very 
> unusual >way.
>
...
> I think its a new way of looking at application servers, it feels like a 
> discovery to me, but >then who knows maybe there is something out there like 
> this, I dont know, all I do know is >that when we drop this servlet into 
> Tomcat, we run POJO applications over the wire as if >they were right their 
> on the client machine, the same applications that will also run >standalone 
> on the machine. Its so different that I really struggled to find the relevent 
> theory >behind this technology, I think I'm close, but any pointers or 
> corrections would be much >appreciated there as well.

Just one question, what do you need tomcat for?
Remove the tomcat from your app server, add rmi, corba, and, if you
really wish, a http connector (which could be tomcat or a small http
listener with xml parser) , and yeah, you are back to the good old
days...

Leon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r567828 - /tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml

[pero]

Author: pero
Date: Mon Aug 20 14:08:41 2007
New Revision: 567828

URL: http://svn.apache.org/viewvc?rev=567828&view=rev
Log:
Fix some bad typos, many thanks to Takayuki Kaneko find.

Modified:

tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml

Modified: 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml?rev=567828&r1=567827&r2=567828&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
 (original)
+++ 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/mbeans-descriptors.xml
 Mon Aug 20 14:08:41 2007
@@ -170,8 +170,8 @@
   description="received processing time (msec)"
  type="long"
  writeable="false"/>
-
 
-
 

Re: svn commit: r567298 - /tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/

[Peter Rossbach]

Sorry for wrong line pasting ;.( Many Thanks and it is fixed.

Regards
Peter


Am 20.08.2007 um 10:28 schrieb Takayuki Kaneko:


Hi Peter,

I'd like to point out that some attributes contains "(msec)" in the  
name.

If it was a mistake, I made a patch.

Regards,

- Takayuki

Index: /container/modules/cluster/src/share/org/apache/catalina/ 
cluster/tcp/mbeans-descriptors.xml

===
--- /container/modules/cluster/src/share/org/apache/catalina/ 
cluster/tcp/mbeans-descriptors.xml	(revision

567470)
+++ /container/modules/cluster/src/share/org/apache/catalina/ 
cluster/tcp/mbeans-descriptors.xml	(working

copy)
@@ -170,8 +170,8 @@
   description="received processing time (msec)"
  type="long"
  writeable="false"/>
-
 
-
  wrote:

Author: pero
Date: Sat Aug 18 10:14:07 2007
New Revision: 567298

URL: http://svn.apache.org/viewvc?view=rev&rev=567298
Log:
Fix some timeout regression bugs with 5.5.23 and the new advanced  
socket config.


Modified:
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/ 
catalina/cluster/tcp/ClusterReceiverBase.java
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/ 
catalina/cluster/tcp/DataSender.java
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/ 
catalina/cluster/tcp/ReplicationListener.java
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/ 
catalina/cluster/tcp/SocketReplicationListener.java
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/ 
catalina/cluster/tcp/SocketReplicationThread.java
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/ 
catalina/cluster/tcp/mbeans-descriptors.xml


Modified: tomcat/container/tc5.5.x/modules/cluster/src/share/org/ 
apache/catalina/cluster/tcp/ClusterReceiverBase.java
URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/ 
cluster/src/share/org/apache/catalina/cluster/tcp/ 
ClusterReceiverBase.java?view=diff&rev=567298&r1=567297&r2=567298
= 
=
--- tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/ 
catalina/cluster/tcp/ClusterReceiverBase.java (original)
+++ tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/ 
catalina/cluster/tcp/ClusterReceiverBase.java Sat Aug 18 10:14:07  
2007

@@ -102,7 +102,7 @@
 private boolean soLingerOn = true;
 private int soLingerTime = 3;
 private int soTrafficClass = 0x04 | 0x08 | 0x010;
-private int timeout = 3000; //3 seconds
+private int timeout = -1; // Regression with older release,  
better set timeout at production env


 /**
  * Compress message data bytes

Modified: tomcat/container/tc5.5.x/modules/cluster/src/share/org/ 
apache/catalina/cluster/tcp/DataSender.java
URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/ 
cluster/src/share/org/apache/catalina/cluster/tcp/DataSender.java? 
view=diff&rev=567298&r1=567297&r2=567298
= 
=
--- tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/ 
catalina/cluster/tcp/DataSender.java (original)
+++ tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/ 
catalina/cluster/tcp/DataSender.java Sat Aug 18 10:14:07 2007

@@ -94,7 +94,7 @@

 private int rxBufSize = 25188;
 private int txBufSize = 43800;
-private long timeout = 3000;
+private int timeout = 3;
 private boolean tcpNoDelay = true;
 private boolean soKeepAlive = false;
 private boolean ooBInline = true;
@@ -221,7 +221,7 @@
 /**
  * After failure make a resend
  */
-private boolean resend = false ;
+private boolean resend = true ;

 //  
-  
Constructor


@@ -627,7 +627,7 @@
  * @return the timeout
  * @since 5.5.25
  */
-public long getTimeout() {
+public int getTimeout() {
 return timeout;
 }

@@ -635,7 +635,7 @@
  * @param timeout the timeout to set
  * @since 5.5.25
  */
-public void setTimeout(long timeout) {
+public void setTimeout(int timeout) {
 this.timeout = timeout;
 }

@@ -666,7 +666,7 @@
  * @deprecated since 5.5.25 use timeout instead
  */
 public void setAckTimeout(long ackTimeout) {
-this.timeout = ackTimeout;
+this.timeout = (int)ackTimeout;
 }

 public long getKeepAliveTimeout() {
@@ -892,15 +892,15 @@
 protected void createSocket() throws IOException,  
SocketException {
 SocketAddress sockAddr = new InetSocketAddress(getAddress 
(), getPort());

 socket = new Socket();
-int timeout = (int) getTimeout();
+int timeout = getTimeout();
 if (timeout > 0) {
socket.connect(sockAddr, timeout);
+   socket.setSoTimeout(timeout);
 } else {
so

real simple setup question

[stephano]

I'm a programmer stuck doing admin setup work, so I apologize for my
ignorance.

I've got a webserver with a bunch of web sites on it.  Each site points to a
usr/home/SOMEUSER/public_html folder.  I'd like to setup tomcat in such a
way that usr/home/Stephano/public_html is where I drop all my code.  I've
never setup tomcat in this situation, I usually just develop on my box in
the webapps directory.  As a side note, I do have admin rights.  My admin
just has no idea what a Tomcat is ;).

If you all could point me in the right direction, that would rock.  Links
are welcome.

Thanks,
Stephano
-- 
View this message in context: 
http://www.nabble.com/real-simple-setup-question-tf4302022.html#a12245400
Sent from the Tomcat - Dev mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Send trunk to the sandbox

[Mark Thomas]

Bill Barker wrote:
> I'm so tired of this thread, so let's settle it once and for all.  I'm 
> backing Remy's suggestion to send the current trunk to the sandbox:
> [X] +1 Let's end the revolution
> [ ] +0 What revolution?
> [ ] -1 Viva the revolultion

This applies to this proposal only. Other changes should be proposed
in other threads.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Send trunk to the sandbox

[Mark Thomas]

jean-frederic clere wrote:
> I would also propose that we take an handling of releases similar to httpd.
> See http://svn.apache.org/repos/asf/httpd/httpd/

-1 for review-then-commit for all commits.

Commit-then-review has worked well for us and I see no reason to move
to the additional overhead and burden of review-then-commit for
everything.

> trunk contains the place where the commmun developement and the new
> agreed features and bugs fixes are going.
> To move something from the "experimental developpement branches" to
> trunk (or to a production branche) we vote it. (in a file named STATUS)
> once accepted (no -1) the stuff enters the production or trunk. If
> someone starts something in trunk and gets a -1 he should create a new
> branch with the new code and propose a vote to get it back in trunk.

+1 to this combined approach. I like it.

> What does that means.
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ will be moved to
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/comet_dev (or
> filip_dev)
> A new http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/

We already have this and it is, as far as I am concerned, the current
trunk.

I like the idea of keeping each major release in a separate directory
under http://svn.apache.org/repos/asf/tomcat/. It keeps everything
nice and consistent (something I like). Therefore I am -0 on moving
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/* to
http://svn.apache.org/repos/asf/tomcat/

Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43173] New: - Logging documentation says to put logging.properties in common/classes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43173

   Summary: Logging documentation says to put logging.properties in
common/classes
   Product: Tomcat 6
   Version: 6.0.14
  Platform: All
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In the java.util.logging section of the logging documentation there's the
following line:

"Example logging.properties file to be placed in common/classes:"

I think it should say:
"Example logging.properties contained in $CATALINA_HOME/conf:"

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]