Tomcat runtime

[Costin Manolache]

Could someone give it a try ? I think I checked in all the changes that 
are needed. Just type "ant runtime" ( using JDK1.5 ), and when it's 
done, "java -jar runtime/tomcat-runtime.jar".


( you will need only one directory - webapps/ - no conf, lib or anything 
else should be needed. Best to try it in an empty dir, and only create a 
webapps/ROOT/WEB-INF and place some html inside ROOT )


Costin


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

Re: tomcat/build/tc5.5.x/resources/build.xml

[Costin Manolache]

Isn't possible to get a svn tree using http download ? I tought one of
the benefits of svn is that it uses http.

Costin

On 10/18/05, Jean-frederic Clere <[EMAIL PROTECTED]> wrote:
> hi,
>
> This file uses cvs but it should do the same with svn. The question is
> how to solve the problem:
> 1 - using a  like:
> +++
>   
> 
> 
>
>   
> +++
>
> 2 - Using svnant (http://subclipse.tigris.org/svnant.html).
>
> 3 - Using AntSvnTask (http://antsvntask.sourceforge.net/subtask.html).
>
> 4 - Something else? (like using javasvn: http://tmate.org/svn/).
>
> Comments?
>
> Cheers
>
> Jean-Frederic
>
> -
> 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]

Sandbox ?

[Costin Manolache]

Hi,

Could someone who understand svn make a /sandbox or /experimental
directory ? I undertand it should be top level, and linked somehow
into tc5.5 - or do we want to be downloaded separately ?
Or can I just create it directly under tc5.5 ? I'm lost.

Thanks,
Costin

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

Re: Sandbox ?

[Costin Manolache]

Thanks !

I'll add few things I've worked on in the past - if people don't mind,
I'll create a sandbox/java and put everything in one tree, ant and
IDEs are smart enough to exclude/include different packages.

Let me know if any of this seems wrong:
- a smaller commons-logging impl, without any discovery tricks ( for runtime )
- attempt to refactor util.buf to use ByteBuffers
- coyote standalone
- a small demo for coyote standalone, using a rhino adapter.
- some additions to coyote - to make it a bit easier to use in standalone mode.

Costin

On 10/19/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Done. See http://svn.apache.org/repos/asf/tomcat/sandbox/
>
> Mark
>
> > -Original Message-
> > From: Costin Manolache [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, October 19, 2005 6:33 AM
> > To: Tomcat Developers List
> > Subject: Sandbox ?
> >
> > Hi,
> >
> > Could someone who understand svn make a /sandbox or /experimental
> > directory ? I undertand it should be top level, and linked somehow
> > into tc5.5 - or do we want to be downloaded separately ?
> > Or can I just create it directly under tc5.5 ? I'm lost.
> >
> > Thanks,
> > Costin
> >
> > -
> > 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: Sandbox ?

[Costin Manolache]

On 10/21/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > Thanks !
> >
> > I'll add few things I've worked on in the past - if people don't mind,
> > I'll create a sandbox/java and put everything in one tree, ant and
> > IDEs are smart enough to exclude/include different packages.
> >
> > Let me know if any of this seems wrong:
> > - a smaller commons-logging impl, without any discovery tricks ( for 
> > runtime )
>
> Another option is to rewrite using a robust platform (I favor
> java.util.logging). I don't know if that's really a possibility, though,
> as I didn't ask my boss about it ;)
>

Well, that's what I'm  doing actually - I just hardcoded
java.util.logging ( well, I have 2 impl, one with println and one with
j.u.l ). The only thing is that I HATE the default formatting and
config - so I want to add a saner formatter, and use a
log4j.properties subset.



> > - attempt to refactor util.buf to use ByteBuffers
>
> And CharBuffer, I hope. So you'll be extending (ByteChunk extends
> ByteBuffer) ?

CharBuffer would go to MessageBytes.

I'm thinking more as an 'uses' - you create ByteBuffers ( maybe direct
buffers ), and
you set it in the ByteChunk. "Extend" is not the best choice - it
would be hard to work with direct ( or other ) buffers. I'm actually
thinking about adding some static methods as well for all the utils we
have in BB.



>
> I'd like to add BufferedReader features to CharChunk (marking and
> readLine, as implementing these without owning the buffer is both hard
> and inefficient).

That's a good idea.


>
> > - coyote standalone
> > - a small demo for coyote standalone, using a rhino adapter.
> > - some additions to coyote - to make it a bit easier to use in standalone 
> > mode.
>
> I have plans to use it to implement a coyote provider for JBoss
> remoting. This would be a good use case for your stuff.

Cool. It would also be interesting to do a small 'ab' test with coyote
standalone - with a small adapter that can take advantage of direct
access to buffers and converters.

I have most of the code - but needs cleanup, some is quite old ( 6-7
months for the logger ).

Costin

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

Re: Sandbox ?

[Costin Manolache]

On 10/23/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:

> > I'm thinking more as an 'uses' - you create ByteBuffers ( maybe direct
> > buffers ), and
> > you set it in the ByteChunk. "Extend" is not the best choice - it
> > would be hard to work with direct ( or other ) buffers. I'm actually
> > thinking about adding some static methods as well for all the utils we
> > have in BB.
>
> I didn't do any tests, but accessing direct buffers contents seems
> vastly more expensive. I don't see how they could be used other than for:
> - buffering (as done in the APR connectors)
> - transferring bytes without manipulating them in Java (ex: sending a
> file on a socket)
>
> Did you do some microbenchmarks ?

No - and I'm sure they wouldn't look very good, the current
implementation seems to just do JNI on each operation, so they are
probably more expensive

However - the fact that it is badly implemented now doesn't mean they
can't be implemented better in future or in a different VM :-), i.e.
with special support from the garbage collector, so it can be backed
by an unmovable byte[].  Realtime java JSR requires support for
unmovable objects ( afaik ) - so sooner or later we may have such a
VM, and then direct buffers would be the fastest way to communicate
between java and native.

For sending a file on a socket - I'm sure using apr would be faster (
is sendfile wrapper implemented ? ), you shouldn't have to read the
file in java.

Anyway - this is just a sandbox experiment, we can try different things.

An unrelated subject - don't know if you saw
http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html

I don't like very much the implementation ( with Exceptions to control
the flow ), but I think there is a good idea to have support in the
thread pool to temporary release the thread for long-running servlets,
and then get a thread back on some event. How this is made visible to
servlets is debatable - I think there are few better ways than what
jetty is doing - but the low level is probably more important.

BTW - where do we deal with keep-alive http connections ? ( I remember
you or Mladen added code to not keep the thread busy ).


Costin

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

Re: Sandbox ?

[Costin Manolache]

On 10/24/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:

> > For sending a file on a socket - I'm sure using apr would be faster (
> > is sendfile wrapper implemented ? ), you shouldn't have to read the
> > file in java.
>
> You need to look a bit into the code ;)
>
> There is:
> - APRized HTTP connector with sendfile and poller usage for keepalive
> - HTTPS support using OpenSSL
> - APRized AJP connector with poller usage for keepalive

I tought there is something for keepalive in the java connector as
well - I guess I was looking in the wrong place, I know apr can do all
the cool things, but I couldn't find the equivalent code.
It may be nice - and maybe that would make the apr and java code share
more code :-)

> > An unrelated subject - don't know if you saw
> > http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html
> >
> > I don't like very much the implementation ( with Exceptions to control
> > the flow ), but I think there is a good idea to have support in the
> > thread pool to temporary release the thread for long-running servlets,
> > and then get a thread back on some event. How this is made visible to
> > servlets is debatable - I think there are few better ways than what
> > jetty is doing - but the low level is probably more important.
>
> I don't like it:
> - the naming is bad (this is using a poller to get read events, so it's
> basically an IO event mechanism)

Yes, the naming is horible - just some buzzwords with little
connection with the real feature.

It is a way to do even-based IO for servlets - but regardless of name,
the actual feature can be
usefull. At least for a sandbox setting :-)  Not a big priority for me
- I was hoping other people would be interested too.


> - it shouldn't just reinvoke the service method unless it can actually
> just continue transparently execution (also, in the "compatibility"
> mode, the execution path isn't the same), and creates the need for
> proprietary routing logic

I agree, the high-level doesn't look good - and it never does, for all
event-based systems :-), even those who don't try to hide this behind
a thread-based interface like service().


> - it encourages a design for servlets which will run very badly on other
> servlet containers

Well, long running servlets ( bound to events or slow IO ) will run
bad anyway on pure threads servers. But if more servers support the
concept - maybe a good solution would emerge, and become part of a
future standard. It would certainly be better than seeing it in the
next servlet spec - without enough implementation experimentation.


> It could be implemented relatively easily in the APRized connectors, but
> given the cost to process a small request over a keepalive connection
> (it's cheap; for example, the use case for this being a chat room, I
> don't see how it would perform bad if using separate requests for each
> message), I don't see any reason to support this.

In the chat room case - you can never get 'instant' messages, you
depend on the polling
 frequency.


Costin

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

Re: Status/Authority of AJP/1.5

[Costin Manolache]

I tought some time ago AJP was 'deprecated' - to be replaced with
plain HTTP and mod_proxy ?

Costin

On 10/24/05, Bill Barker <[EMAIL PROTECTED]> wrote:
>
> - Original Message -
> From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, October 24, 2005 1:52 PM
> Subject: Status/Authority of AJP/1.5
>
>
> > Questions since some interesting ideas have popped up with respect to the
> > next flavor of AJP...  firstoff, who holds the AJP standard; is it the
> ASF?
> >
>
> Yes, it's entirely owned by the ASF.  It evolved from JServ, which is also
> owned by the ASF.
>
> > Second, what is the status of AJP/1.5 and where is it discussed?
> >
>
> Well, http://issues.apache.org/bugzilla/show_bug.cgi?id=37100 sort of
> wandered off-topic into this area :).  Otherwise, probably
> http://tomcat.apache.org/connectors-doc/common/ajpv13ext.html is your best
> bet.
>
> > I would like to float some various questions to not only introduce some
> > 'flush' signal, to inform the outward facing server to stop caching (if
> > it was) and push out a partial response; and I'd like to explore other
> > information that could be captured with respect to balancing.
> >
>
> By itself, client-flush wouldn't be hard to implement.
>
> > Thanks!
> >
> > Bill
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> This message is intended only for the use of the person(s) listed above as 
> the intended recipient(s), and may contain information that is PRIVILEGED and 
> CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, 
> or distribute this message or any attachment. If you received this 
> communication in error, please notify us immediately by e-mail and then 
> delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent 
> through the Internet is not secure. Do not send confidential or sensitive 
> information, such as social security numbers, account numbers, personal 
> identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
> -
> 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: Status/Authority of AJP/1.5

[Costin Manolache]

I see. Sorry, I've been sleeping for quite a while, I'm slowly getting
up to speed with the latest developments.

Are you saying that mod_proxy_ajp is significantly faster than
mod_proxy ? That's interesting.

To answer your question - ajp10 and ajp11 were used in JServ,
developed in Apache.
Ajp12 is based on 11, developed in the early days of tomcat. I think
jetty also suppors ( or supported ) the protocol at some time.

IMHO - if a new version of the protocol is developed, there are 2 choices:
- preserve backwards compatibility - there are few ugly way to do this
- break backwards compatibility - in wich case it may be better to
redo the protocol so it is extensible, and maybe even better reuse an
existing protocol. An example to look at is the DBUS protocol ( from
freedesktop ) - or maybe classical RPC. Ad-hoc arbitrary binary
protocols can be a bad idea - as we see with ajp12 extensibility
problems.


Costin

On 10/24/05, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > I tought some time ago AJP was 'deprecated' - to be replaced with
> > plain HTTP and mod_proxy ?
>
> Why?
>
> It turns out that mod_proxy_ajp v.s. mod_proxy_http does prove the validity
> of optimizing the backend connection.  I don't think anyone forsees mod_jk
> being deprecated (at least, not insofar as it supports IIS/Netscape/Sun
> http servers), but from an Apache perspective, hopefully mod_proxy_ajp will
> make mod_jk/Apache a footnote in history :)
>
> Bill
>
> -
> 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: Status/Authority of AJP/1.5

[Costin Manolache]

Henri, I can understand that a binary protocol is ( a bit ) faster
than plain http.

But what you describe is relatively light monitoring and management -
you won't do 1000 reconfigs per second.

There is absolutely no reason to extend the protocol with this - just
use a separate mechanism. Even in the complex world of Corba - the
discovery and configuration is not part of the core wire protocol, but
a separate API.

Just define whatever directory you like on top of JMX, with either JMX
or http interface - you could use JINI if you want, or zeroconfig/dns
or anything else. The only tricky part is Apache - but even there you
can do this kind of stuff in a separate module.

Security ( i.e. authentication ) might be the only reason to extend
AJP - but even this can be done on top of the existing protocol, using
a custom header and connection initiation.

AJP12 == binary HTTP.
Just tell me what you can't do using HTTP request/response mechanism.

Of course - I agree what you need is important, and it would be great
to have it - but
you would do it much faster and simpler if you don't touch ajp, but
work at jmx/servlet layer.

Costin

On 10/24/05, Henri Gomez <[EMAIL PROTECTED]> wrote:
> AJP 1.5 should support automatic discovery of tomcat backend, new
> systems and new webapps.
>
> That's the current need for many of us when adding tomcats / webapp
> behind Apache 2 webservers. In such case we need to restart them and
> it's sad.
>
> How could it be accomplished, may be via a master tomcat who will give
> the tomcat farm topology to Apache HTTP2.
>
> What do you think ?
>
> 2005/10/25, Costin Manolache <[EMAIL PROTECTED]>:
> > I see. Sorry, I've been sleeping for quite a while, I'm slowly getting
> > up to speed with the latest developments.
> >
> > Are you saying that mod_proxy_ajp is significantly faster than
> > mod_proxy ? That's interesting.
> >
> > To answer your question - ajp10 and ajp11 were used in JServ,
> > developed in Apache.
> > Ajp12 is based on 11, developed in the early days of tomcat. I think
> > jetty also suppors ( or supported ) the protocol at some time.
> >
> > IMHO - if a new version of the protocol is developed, there are 2 choices:
> > - preserve backwards compatibility - there are few ugly way to do this
> > - break backwards compatibility - in wich case it may be better to
> > redo the protocol so it is extensible, and maybe even better reuse an
> > existing protocol. An example to look at is the DBUS protocol ( from
> > freedesktop ) - or maybe classical RPC. Ad-hoc arbitrary binary
> > protocols can be a bad idea - as we see with ajp12 extensibility
> > problems.
> >
> >
> > Costin
> >
> > On 10/24/05, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> > > Costin Manolache wrote:
> > > > I tought some time ago AJP was 'deprecated' - to be replaced with
> > > > plain HTTP and mod_proxy ?
> > >
> > > Why?
> > >
> > > It turns out that mod_proxy_ajp v.s. mod_proxy_http does prove the 
> > > validity
> > > of optimizing the backend connection.  I don't think anyone forsees mod_jk
> > > being deprecated (at least, not insofar as it supports IIS/Netscape/Sun
> > > http servers), but from an Apache perspective, hopefully mod_proxy_ajp 
> > > will
> > > make mod_jk/Apache a footnote in history :)
> > >
> > > Bill
> > >
> > > -
> > > 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]
>
>

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

Re: Status/Authority of AJP/1.5

[Costin Manolache]

On 10/25/05, Mladen Turk <[EMAIL PROTECTED]> wrote:

> Although I was evangelizing the new protocol for a long time...
> Looking more deeply on the subject IMHO there is no much purpose for
> developing such stuff unless the HTTPD offers the dynamic
> reconfiguration, and I doubt something like that will be considered
> before Apache 3.0 (as I understood).

Httpd offers some reconfiguration - usually enough for what we need (
i.e. mappings ).
See my previous mail - you can control this as well using a normal
module and http requests ( over ajp or text http )




> Introducing new protocol would bring more problems if we try to

and will give no solution !.

> One of the advances would be to extend the CPING/CPONG messages
> with worker/balancer status data, so that we can collect data in
> the runtime like load, etc... The other would be to introduce private
> headers within AJP channels for status data exchange between nodes.

Or you could do this as well at a higher layer - by making HTTP
requests ( binary or not ).

This would also benefit other use-cases - like general monitoring and
non-ajp load balancing.

Costin

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

Re: Status/Authority of AJP/1.5

[Costin Manolache]

Yes, this is a valid case, but as I said, I think it could be added
without breaking binary compatibility. But if we just can't find one -
I think it would be far better to use a real protocol, with some
build-in extensibility - rather than invent our own brand-new protocol
or ( even worse ) patch ajp12. DBUS is a good example in IMO - I'm not
saying to use their impl, which doesn't fit, just the protocol spec. I
used to think RPC/XDR would be good too - light enough, well-defined,
etc - but right now it looks dbus is a bit better ( there are few
dubious things there as well..).

I was referring was authentication for the apache-tomcat connection -
and this can be done by making a first set of HTTP request to a
special URL ( not starting with /, so it's invalid ), and on top of
this any auth.

Costin


On 10/25/05, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> >
> > Security ( i.e. authentication ) might be the only reason to extend
> > AJP - but even this can be done on top of the existing protocol, using
> > a custom header and connection initiation.
>
> Only partly true.  Let's take the HTTPS state, for example... if tomcat looks
> for X-PROTOCOL=HTTPS, for example, passing this from the proxy as a typical
> header is simply wrong for security reasons.  It's too trivial to fake, and
> it's too expensive to guard against.
>
> The safe way is to have two header-types, one, a client HTTP-type header.  The
> other, proxy metadata such as the protocol, SSL keys and other server 
> variables.
> These wouldn't be relayed as HTTP-style headers, so therefore all sorts of 
> proxy
> to backend data can be trusted.
>
> (FYI - w.r.t. the client/server certs, I don't suggest a full blown mod_ssl
> type of decomposition.  If they want to tear apart the certificates, it sure
> makes sense to introspect them through jsse, no?)
>
> Bill
>
> -
> 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: Status/Authority of AJP/1.5

[Costin Manolache]

On 10/25/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > DBUS is a good example in IMO - I'm not
> > saying to use their impl, which doesn't fit, just the protocol spec.
>
> The major power of AJP protocol is known-header-name indexing, and
> IMHO there is no other protocol that is HTTP application focused.

Well, any protocol can do this - with the right message.

In this case: it'll be:
 enum  knownHeadersCode={  }
 and the message will have an array of ( knownHeaderCode, string ) and
then ( string string)

Or some other variation - there is nothing so special in Ajp that
can't be encoded in a standard protocol. Except the fact that ajp is
not extensible - so it may save a few bytes.


> If there is really a need for a completely new protocol,
> and I doubt there is a real need for that right now, we must presume
> that the primary intent of the protocol is to allow communication of
> two well known and defined http applications.

Sure - but this can be expressed as well on top of a more standard (
or common ) marshalling. Marshalling is not specific to any
application, not even in ajp ( maybe the stupid 'first chunk' - but
even this can be expressed with few extra bytes in a normal protocol
).

The API you expose - i.e. the message signatures - should remain
specific to the http
app. And a standard protocol would allow you to add all kind of extra
signatures.


> If you look at the XDR protocol, each 'string' type message is prefixed
> with additional two bytes compared with AJP, so beside that, the lack of
> header indexing would at least double the packet size, and downgrade the
> performance by twice.

I don't think the 2 extra bytes is such a big problem.

Actually there is one thing that is unique to AJP - the callbacks done
over the same connection, as responses ( since tomcat can't initiate a
call ). But even this can be expressed in a proper RPC - by having the
callback as a normal response.

Costin

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

Re: svn commit: r329081 [1/2] - /tomcat/sandbox/java/org/apache/tomcat/util/buf/

[Costin Manolache]

I'll try.

My biggest problem is to do this without breaking too much backward compat.
After we add BB - the rest might be easier.

Costin

On 10/28/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Author: costin
> > Date: Thu Oct 27 21:11:42 2005
> > New Revision: 329081
> >
> > URL: http://svn.apache.org/viewcvs?rev=329081&view=rev
> > Log:
> > Import the current version of o.a.t.util.buf, for refactoring. I'm
> > trying to use nio.
> >
> > Added:
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/Ascii.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/B2CConverter.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/Base64.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java   (with 
> > props)
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/C2BConverter.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/CharChunk.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/DateTool.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/HexUtils.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/MessageBytes.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/StringCache.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/TimeStamp.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/UDecoder.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/UEncoder.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/UTF8Decoder.java
> > tomcat/sandbox/java/org/apache/tomcat/util/buf/package.html
>
> Along with the CharChunk funcionality update, can CharSequence support
> be added to it as well ? (the JDK regexp engine uses that interface)
>
> 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: svn commit: r329053 - in /tomcat/sandbox/java: ./ org/ org/apache/ org/apache/commons/ org/apache/commons/logging/

[Costin Manolache]

On 10/28/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Author: costin
> > Date: Thu Oct 27 19:55:08 2005
> > New Revision: 329053
> >
> > URL: http://svn.apache.org/viewcvs?rev=329053&view=rev
> > Log:
> > Implementation of commons-logging that doesn't use any discovery or
> > tricks, just plain java.util.logging.
> >
> > There is a trick actually - at startup it'll try to load a different
> > handler ( without 2-lines logs ) and a different config ( from classpath
> > like log4j ). I'll probably remove this later, but I can't stand the
> > default handler and behavior
>
> I'm ok with including your formatter in the JULI bundle, and using it in
> the default configuration (the one which is in conf/logging.properties).

I've been wondering - was is the reason for having JULI as a separate
module ? It would fit
well under util/. If JDK1.4 is the concern - exclude is pretty easy,
there are other files depending on 1.4 or even 1.5 in the tree.

Costin

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

Re: Status/Authority of AJP/1.5

[Costin Manolache]

On 10/29/05, Henri Gomez <[EMAIL PROTECTED]> wrote:
> using AJP or HTTP or WHATEVERP protocol you want, the current need for
> me in my production systems is to be able to add / remove a tomcat
> machine to a LoadBalancing farm without having to restart the Apache 2
> web server.

Sounds like a very reasonable requirement. My point was that this is
not a requirement for the AJP protocol itself - but a requirement for
Apache and whatever modules are used in apache for load balancing and
forwarding.

How you interact with Apache to dynamically add machines ( and
generally - to configure it ) is yet another separate problem.

I think it is far better for anyone who has this requirement to
decouple the problems, and not try to mix wire protocol for forwarding
with the mechanism and protocol for management.



> A  WEB admin (I work with them each days) would like to add / remove a
> tomcat dynamically, for example using an admin webapp on an
> 'load-balancing administrator console'  running on a webapp hosted by
> a tomcat or may be even a pure Apache 2 application.
>
> If you told me it's impossible to add a REQUEST mapper (ie JkMount)
> dynamically to a running Apache 2.0, I say amen and we'll wait for
> HTTPD team to allow that.

AFAIK apache2 can do this with a restart, or with a module that does
dynamic mapping and has runtime reconfiguration support, like jk2 did.


>
> But something we could do allready is to add/remove a tomcat from a lb worker 
> ?

Yes, it should be possible to do this - but I'm not sure what that has
to do with the AJP protocol.

You need some support in the apache module, and then a way to
interface with the module - eihter using a file + a signal or special
URL, etc, etc.

Costin


>
> 2005/10/25, Costin Manolache <[EMAIL PROTECTED]>:
> > On 10/25/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
> > > Costin Manolache wrote:
> > > > DBUS is a good example in IMO - I'm not
> > > > saying to use their impl, which doesn't fit, just the protocol spec.
> > >
> > > The major power of AJP protocol is known-header-name indexing, and
> > > IMHO there is no other protocol that is HTTP application focused.
> >
> > Well, any protocol can do this - with the right message.
> >
> > In this case: it'll be:
> >  enum  knownHeadersCode={  }
> >  and the message will have an array of ( knownHeaderCode, string ) and
> > then ( string string)
> >
> > Or some other variation - there is nothing so special in Ajp that
> > can't be encoded in a standard protocol. Except the fact that ajp is
> > not extensible - so it may save a few bytes.
> >
> >
> > > If there is really a need for a completely new protocol,
> > > and I doubt there is a real need for that right now, we must presume
> > > that the primary intent of the protocol is to allow communication of
> > > two well known and defined http applications.
> >
> > Sure - but this can be expressed as well on top of a more standard (
> > or common ) marshalling. Marshalling is not specific to any
> > application, not even in ajp ( maybe the stupid 'first chunk' - but
> > even this can be expressed with few extra bytes in a normal protocol
> > ).
> >
> > The API you expose - i.e. the message signatures - should remain
> > specific to the http
> > app. And a standard protocol would allow you to add all kind of extra
> > signatures.
> >
> >
> > > If you look at the XDR protocol, each 'string' type message is prefixed
> > > with additional two bytes compared with AJP, so beside that, the lack of
> > > header indexing would at least double the packet size, and downgrade the
> > > performance by twice.
> >
> > I don't think the 2 extra bytes is such a big problem.
> >
> > Actually there is one thing that is unique to AJP - the callbacks done
> > over the same connection, as responses ( since tomcat can't initiate a
> > call ). But even this can be expressed in a proper RPC - by having the
> > callback as a normal response.
> >
> > Costin
> >
> > -
> > 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: r329853 - /tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java

[Costin Manolache]

Sorry, eclipse autocompletion tricks... There is no crypto in byte
buffer - no idea how it got there, but I have the imports folded.

The code doesn't work anyway - the ByteBuffer has some very flippy
behavior, I'm still trying to figure out the best workaround. (
position and limit have different behavior when the buffer is in
append mode - start-end in ByteChunk meant start/end of the data
portion, but in ByteBuffer it can also mean start/end of the empty
portion )


Costin

On 11/1/05, Peter Rossbach <[EMAIL PROTECTED]> wrote:
> Hey,
>
> means the package import "sun.security.krb5.**"  that we can't use ByteChunk 
> at other JVm's like jrockit?
>
> I don't see the usage? :-)
>
>
> Peter
>
> http://svn.apache.org/viewcvs/tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java?rev=329853&r1=329852&r2=329853&view=diff
> ==
> --- tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java (original)
> +++ tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java Mon Oct 31 
> 08:39:42 2005
> @@ -18,6 +18,10 @@
>
>  import java.io.IOException;
>  import java.io.Serializable;
> +import java.nio.ByteBuffer;
> +
> +import sun.security.krb5.internal.crypto.b;
> +import sun.security.krb5.internal.crypto.t;
>
> ---
>
>
>
> -
> 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: Rewrite features

[Costin Manolache]

Have you considered placing it at a lower level, as a coyote adapter ?
The reason I ask - I'm playing with coyote standalone, I have a
trivial mapper, file server, hello world adapter - for simple http
serving. This would fit well before entering the servlet engine.

Costin

On 11/3/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> As part of the JBoss Web project, I have developed a URL rewrite valve,
> more or less cloned on mod_rewrite. It doesn't support everything from
> mod_rewrite, and there's no docs at the moment, but it's not too hard to
> figure out how to use it.
>
> For looking at it and testing, it's here (of course, it's neither
> polished nor well tested at the moment):
> http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jboss/web/rewrite/
>
> 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: Rewrite features

[Costin Manolache]

On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote:
> It probably doesn't matter (since nobody uses it :), but using ThreadLocal
> won't work with the Nio/AJP Connector.  That one doesn't bind a Request
> instance to a Thread instance, so a particular Request instance will process
> on many different Threads during its lifecycle.

Does the spec say anything about the thread model when executing a
servlet ? ( too lazy to search, I know some people on the list have
memorized the spec already :-)

I'm not sure how this happens - I tought that the request is bound to
a thread during service() execution, and kept-alive connections are no
longer bound. How do we unbind the service() from the thread ???


Costin

>
> The alternative (which, IMHO looks nicer) is to use (Coyote)Request Notes
> instead of ThreadLocal.
>
> - Original Message -
> From: "Remy Maucherat" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" 
> Sent: Thursday, November 03, 2005 8:40 AM
> Subject: Rewrite features
>
>
> Hi,
>
> As part of the JBoss Web project, I have developed a URL rewrite valve,
> more or less cloned on mod_rewrite. It doesn't support everything from
> mod_rewrite, and there's no docs at the moment, but it's not too hard to
> figure out how to use it.
>
> For looking at it and testing, it's here (of course, it's neither
> polished nor well tested at the moment):
> http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jbos
> s/web/rewrite/
>
> Rémy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> This message is intended only for the use of the person(s) listed above as 
> the intended recipient(s), and may contain information that is PRIVILEGED and 
> CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, 
> or distribute this message or any attachment. If you received this 
> communication in error, please notify us immediately by e-mail and then 
> delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent 
> through the Internet is not secure. Do not send confidential or sensitive 
> information, such as social security numbers, account numbers, personal 
> identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
> -
> 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: Rewrite features

[Costin Manolache]

On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote:
>
> - Original Message -----
> From: "Costin Manolache" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" 
> Sent: Thursday, November 03, 2005 11:30 AM
> Subject: Re: Rewrite features
>
>
> On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote:
> >> It probably doesn't matter (since nobody uses it :), but using
> ThreadLocal
> >> won't work with the Nio/AJP Connector.  That one doesn't bind a Request
> >> instance to a Thread instance, so a particular Request instance will
> process
> >> on many different Threads during its lifecycle.
> >
> >Does the spec say anything about the thread model when executing a
> >servlet ? ( too lazy to search, I know some people on the list have
> >memorized the spec already :-)
>
> When an AJP Request comes in, the Connector gets a Thread from the Pool to
> process the Request.  After the Request is done processing, it returns the
> Thread to the Pool.  There is no reason that it should get the same Thread
> instance each time it does this.

Yes, but I tought all the service() method is still running in one
thread from start to finish.
The next AJP Request is a different servlet request - in the past it
was in the same thread only if Keep-Alive was used. If the connection
has expired ( keep alive timeout, or multiple connections from browser
) - it'll go to different thread.

The only case I knew where a service() will lose thread in the middle
is the Jetty continuation, where the thread is released by a sepecial
exception and extrenal event reaquire a random thread to continue.



> >
> >I'm not sure how this happens - I tought that the request is bound to
> >a thread during service() execution, and kept-alive connections are no
> >longer bound. How do we unbind the service() from the thread ???
> >
>
> We don't unbind the service() from the Thread.  However, in Coyote Request
> instances are very long lived objects that (at least for HTTP/1.1) persist
> over many connections.

But this is not guaranteed - you can't rely on this, there are many
cases where you would get a different thread.


> The APR Connector uses a ThreadLocal to bind the Request instance to a
> single Thread instance.  The next request that it handles may have been
> received on a different Socket than the last, but it is bound to the Thread.
> With the Java HTTP/1.1 Connector, the Request is bound to the Thread via the
> init() method of ThreadPoolRunnable.

I still don't understand the problem.
2 requests from the same browser can be assigned different threads in
both connectors. They get same thread in the old connector more often
- if they happen to use the same socket, but this is not allways the
case.

I suppose I'm missing something trivial here...

>
> The Nio/AJP Connector binds the Request instance to a Socket connection (via
> the SelectionKey.attachment).

Costin

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

Re: Sloppy, Lazy Tomcat Developers (Was: Persistent "xmlValidation" Problem)

[Costin Manolache]

I wonder what Bob does when his Windows XP is crashing or catches a virus :-)
Well, at least whoever reads the user mail at MSFT is paid for reading
his rants, we're not. And they got his money too.

As for the 'validate' flag - maybe we should just remove it:
- it slows down startup
- it is optional in the spec
- we know it doesn't work with most parsers, including versions bundled in JDK
- the whole schema validation thing is a bad idea anyway.

Is anyone really using this flag ?

Bob, if you're still on the list - why would you want to turn on this
flag ? I never found any use for it ( except to slow down startup and
get exceptions ).

Costin


On 11/4/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Bob Bronson wrote:
> > Another lazy copout!! Even the web.xml that is distributed w/Tomcat does
> > not validate! Did you even test this before you replied to my note or
> > did you just assume the user was at fault???
> >
> > When someone criticizes the poor state of an open sores project (as I am
> > doing now), the typical response from the open sores programmer is to
> > shift responsibility to the user -- the user is often told to dig
> > through the change logs or browse the forum archives or even to fix the
> > bug/documentation themselves instead of "complaining". What an
> > unprofessional, lazy attitude from programmers! The open sores
> > programmers try to cast *their* laziness as the user's laziness for "not
> > digging deeply enough" to resolve their own problem, or even fixing the
> > problem themselves by going into the source code. The fact that the
> > Tomcat User mailing list often receives over 150 messages a day is more
> > a testament to Tomcat's crappy documentation than to its popularity.
> >
> > Yes, yes, I know Tomcat is "not for me". You're damned right. I'm happy
> > to pay money for quality. I guess Tomcat bares out the old adage, "you
> > get what you pay for".
>
> If you don't feel special enough, I can do it in two seconds and can get
> you a cool membership to the "dev-deny" list :)
>
> 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: Sloppy, Lazy Tomcat Developers (Was: Persistent "xmlValidation" Problem)

[Costin Manolache]

Well, my point was - do we really need this feature ?

If nobody is really using it - it doesn't work out of box and we
didn't see any major complaint except Bob  - it may be simpler to just
remove the flag from the docs and server.xml - and maybe even remove
the code that does this validation. Or move it to some module that is
not distributed by default, in case we have 2-3 users.

I believe we no longer include the xerces parser in some of the
distros - so even a fix in xerces will be useless, users will need to
upgrade the VM.

It is silly to depend on a very specific parser and version - and keep
options, code, documentation - for a feature that nobody really uses.

Costin

On 11/4/05, Jeanfrancois Arcand <[EMAIL PROTECTED]> wrote:
>
>
> Costin Manolache wrote:
> > I wonder what Bob does when his Windows XP is crashing or catches a virus 
> > :-)
> > Well, at least whoever reads the user mail at MSFT is paid for reading
> > his rants, we're not. And they got his money too.
> >
> > As for the 'validate' flag - maybe we should just remove it:
> > - it slows down startup
> > - it is optional in the spec
> > - we know it doesn't work with most parsers, including versions bundled in 
> > JDK
> > - the whole schema validation thing is a bad idea anyway.
> >
> > Is anyone really using this flag ?
>
> I think the problem right now is a bug in the web-xml schema:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=31125
>
> I should have added that link to the response :-) Once this is fixed,
> XML validation should works.
>
> -- Jeanfrancois
>
> >
> > Bob, if you're still on the list - why would you want to turn on this
> > flag ? I never found any use for it ( except to slow down startup and
> > get exceptions ).
> >
> > Costin
> >
> >
> > On 11/4/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> >
> >>Bob Bronson wrote:
> >>
> >>>Another lazy copout!! Even the web.xml that is distributed w/Tomcat does
> >>>not validate! Did you even test this before you replied to my note or
> >>>did you just assume the user was at fault???
> >>>
> >>>When someone criticizes the poor state of an open sores project (as I am
> >>>doing now), the typical response from the open sores programmer is to
> >>>shift responsibility to the user -- the user is often told to dig
> >>>through the change logs or browse the forum archives or even to fix the
> >>>bug/documentation themselves instead of "complaining". What an
> >>>unprofessional, lazy attitude from programmers! The open sores
> >>>programmers try to cast *their* laziness as the user's laziness for "not
> >>>digging deeply enough" to resolve their own problem, or even fixing the
> >>>problem themselves by going into the source code. The fact that the
> >>>Tomcat User mailing list often receives over 150 messages a day is more
> >>>a testament to Tomcat's crappy documentation than to its popularity.
> >>>
> >>>Yes, yes, I know Tomcat is "not for me". You're damned right. I'm happy
> >>>to pay money for quality. I guess Tomcat bares out the old adage, "you
> >>>get what you pay for".
> >>
> >>If you don't feel special enough, I can do it in two seconds and can get
> >>you a cool membership to the "dev-deny" list :)
> >>
> >>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]
> >
> >
>
> -
> 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: r331062 - in /tomcat/sandbox/java/org/apache/coyote: ./ adapters/ standalone/

[Costin Manolache]

I think cocoon is also using rhino, and few other projects - ant is
using it via BSF.

In any case - it is just an example, not required in any way - it's
easier to do some tests and experiments in a scripting language. The
build.xml file will just detect if js.jar is available and skip this
file otherwise ( nothing depends on the JsAdapter ).

Costin

On 11/5/05, Bill Barker <[EMAIL PROTECTED]> wrote:
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: 
> Sent: Saturday, November 05, 2005 7:13 PM
> Subject: svn commit: r331062 - in /tomcat/sandbox/java/org/apache/coyote: ./
> adapters/ standalone/
>
>
> > Author: costin
> > Date: Sat Nov  5 19:13:06 2005
> > New Revision: 331062
> >
> > URL: http://svn.apache.org/viewcvs?rev=331062&view=rev
> > Log:
> > Code for testing ( and using ) coyote standalone.
> 
> > +import org.mozilla.javascript.Context;
> > +import org.mozilla.javascript.EvaluatorException;
> > +import org.mozilla.javascript.Function;
> > +import org.mozilla.javascript.JavaScriptException;
> > +import org.mozilla.javascript.Scriptable;
> > +import org.mozilla.javascript.ScriptableObject;
> > +import org.mozilla.javascript.WrappedException;
>
> I take it that MPL is compatible with ASF?  For those that don't want to
> search the archives, my vote is +1 on this issue.  I just wanted to make
> certain that everyone is aware of this, since it is buried in a long commit
> message.
>
>
>
> This message is intended only for the use of the person(s) listed above as 
> the intended recipient(s), and may contain information that is PRIVILEGED and 
> CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, 
> or distribute this message or any attachment. If you received this 
> communication in error, please notify us immediately by e-mail and then 
> delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent 
> through the Internet is not secure. Do not send confidential or sensitive 
> information, such as social security numbers, account numbers, personal 
> identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
> -
> 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: r331062 - in /tomcat/sandbox/java/org/apache/coyote: ./ adapters/ standalone/

[Costin Manolache]

My understanding is that tomcat can't _distribute_ code that isn't
apache license compatible,
and  we shouldn't depend on such code to compile or run a functional tomcat.

Talking about agendas :-), I think that any code that is not required
to have a working servlet container should be in a separate add-on
module. SSL modules are excelent examples. Actually, a lot of the
things that are in the normal tomcat distro would be make good add-on
modules. Firefox is a good example.


Costin

On 11/6/05, Bill Barker <[EMAIL PROTECTED]> wrote:
> Actually (having spent way too much time in Gump-land recently :), Tomcat
> depends on rhino in Gump.
>
> What I'm looking for is a clear statement from the Tomcat PMC about MPL
> compatibility.  Sorry about hijacking your commit for my agenda ;-).  It
> looks like Christina can't contribute her code for BZ #36133.  However, it
> looks like a fun project if I can do it myself.
>
> - Original Message -
> From: "Costin Manolache" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" 
> Sent: Saturday, November 05, 2005 10:33 PM
> Subject: Re: svn commit: r331062 - in
> /tomcat/sandbox/java/org/apache/coyote: ./ adapters/ standalone/
>
>
> I think cocoon is also using rhino, and few other projects - ant is
> using it via BSF.
>
> In any case - it is just an example, not required in any way - it's
> easier to do some tests and experiments in a scripting language. The
> build.xml file will just detect if js.jar is available and skip this
> file otherwise ( nothing depends on the JsAdapter ).
>
> Costin
>
> On 11/5/05, Bill Barker <[EMAIL PROTECTED]> wrote:
> >
> > - Original Message -
> > From: <[EMAIL PROTECTED]>
> > To: 
> > Sent: Saturday, November 05, 2005 7:13 PM
> > Subject: svn commit: r331062 - in /tomcat/sandbox/java/org/apache/coyote:
> > ./
> > adapters/ standalone/
> >
> >
> > > Author: costin
> > > Date: Sat Nov  5 19:13:06 2005
> > > New Revision: 331062
> > >
> > > URL: http://svn.apache.org/viewcvs?rev=331062&view=rev
> > > Log:
> > > Code for testing ( and using ) coyote standalone.
> > 
> > > +import org.mozilla.javascript.Context;
> > > +import org.mozilla.javascript.EvaluatorException;
> > > +import org.mozilla.javascript.Function;
> > > +import org.mozilla.javascript.JavaScriptException;
> > > +import org.mozilla.javascript.Scriptable;
> > > +import org.mozilla.javascript.ScriptableObject;
> > > +import org.mozilla.javascript.WrappedException;
> >
> > I take it that MPL is compatible with ASF?  For those that don't want to
> > search the archives, my vote is +1 on this issue.  I just wanted to make
> > certain that everyone is aware of this, since it is buried in a long
> > commit
> > message.
> >
> >
> >
> > This message is intended only for the use of the person(s) listed above as
> > the intended recipient(s), and may contain information that is PRIVILEGED
> > and CONFIDENTIAL.  If you are not an intended recipient, you may not read,
> > copy, or distribute this message or any attachment. If you received this
> > communication in error, please notify us immediately by e-mail and then
> > delete all copies of this message and any attachments.
> >
> > In addition you should be aware that ordinary (unencrypted) e-mail sent
> > through the Internet is not secure. Do not send confidential or sensitive
> > information, such as social security numbers, account numbers, personal
> > identification numbers and passwords, to us via ordinary (unencrypted)
> > e-mail.
> >
> >
> > -
> > 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]
>
>
>
>
>
> This message is intended only for the use of the person(s) listed above as 
> the intended recipient(s), and may contain information that is PRIVILEGED and 
> CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, 
> or distribute this message or any attachment. If you received this 
> communication in error, please notify us immediately by e-mail and then 
> delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent 
> through the Internet is not secure. Do not send confidential or sensitive 
> information, such as social security numbers, account numbers, personal 
> identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
> -
> 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: 1 year free webhosting for anyone who can solve this Tomcat problem!

[Costin Manolache]

Nice, it would be good if everyone asking a question would offer
something - a beer, hosting, etc :-)

So - are you sure port 8005 is free ? Do a quick "netstat -an |grep
8005", maybe
you forgot to change it in  ( I noticed you're using
8180 for http )

Costin

On 11/11/05, Richard Schilling <[EMAIL PROTECTED]> wrote:
> I've been trying for about 12 hours now, and can't figure out why Tomcat
> won't bind to a port.  The ports aren't being used, and in JVMs are running.
>
> I'm out of ideas and this is delaying a production box.
>
> I'll give free webhosting for a year to anyone who wants to take the
> time to log onto the box and can fix this while talking to me on the
> phone.  The web server that does the hosting has e-mail, awstats, pgsql,
> mysql, postnuke, Apache 1.3, mod_ssl, mod_perl, mod_jk and of course
> Tomcat (when you get it running).
>
> Using JDK1.5 and FreeBSD 6.0.
>
>
> I get theses errors in stdout.log:
>
>
> Nov 11, 2005 11:49:14 AM org.apache.coyote.http11.Http11Protocol init
> INFO: Initializing Coyote HTTP/1.1 on http-8180
> Nov 11, 2005 11:49:15 AM org.apache.catalina.startup.Catalina load
> INFO: Initialization processed in 3095 ms
> Nov 11, 2005 11:49:15 AM org.apache.catalina.core.StandardService start
> INFO: Starting service Catalina
> Nov 11, 2005 11:49:15 AM org.apache.catalina.core.StandardEngine start
> INFO: Starting Servlet Engine: Apache Tomcat/5.5.9
> Nov 11, 2005 11:49:15 AM org.apache.catalina.core.StandardHost start
> INFO: XML validation disabled
> Nov 11, 2005 11:49:21 AM org.apache.catalina.core.ApplicationContext log
> INFO: org.apache.webapp.balancer.BalancerFilter: init(): ruleChain:
> [org.apache.
> webapp.balancer.RuleChain:
> [org.apache.webapp.balancer.rules.URLStringMatchRule:
>   Target string: News / Redirect URL: http://www.cnn.com],
> [org.apache.webapp.bal
> ancer.rules.RequestParameterRule: Target param name: paramName / Target
> param va
> lue: paramValue / Redirect URL: http://www.yahoo.com],
> [org.apache.webapp.balanc
> er.rules.AcceptEverythingRule: Redirect URL: http://jakarta.apache.org]]
> Nov 11, 2005 11:49:22 AM org.apache.catalina.core.ApplicationContext log
> INFO: ContextListener: contextInitialized()
> Nov 11, 2005 11:49:22 AM org.apache.catalina.core.ApplicationContext log
> INFO: SessionListener: contextInitialized()
> Nov 11, 2005 11:49:22 AM org.apache.catalina.core.ApplicationContext log
> INFO: ContextListener: contextInitialized()
> Nov 11, 2005 11:49:22 AM org.apache.catalina.core.ApplicationContext log
> INFO: SessionListener: contextInitialized()
> Nov 11, 2005 11:49:23 AM org.apache.coyote.http11.Http11Protocol start
> INFO: Starting Coyote HTTP/1.1 on http-8180
> Nov 11, 2005 11:49:23 AM org.apache.jk.common.ChannelSocket init
> INFO: JK: ajp13 listening on /0.0.0.0:8009
> Nov 11, 2005 11:49:23 AM org.apache.jk.server.JkMain start
> INFO: Jk running ID=0 time=0/17  config=null
> Nov 11, 2005 11:49:24 AM org.apache.catalina.storeconfig.StoreLoader load
> INFO: Find registry server-registry.xml at classpath resource
> Nov 11, 2005 11:49:24 AM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 9128 ms
> Nov 11, 2005 11:49:24 AM org.apache.catalina.core.StandardServer await
> SEVERE: StandardServer.await: create[8005]:
> java.net.BindException: Can't assign requested address
>  at java.net.PlainSocketImpl.socketBind(Native Method)
>  at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
>  at java.net.ServerSocket.bind(ServerSocket.java:319)
>  at java.net.ServerSocket.(ServerSocket.java:185)
>  at
> org.apache.catalina.core.StandardServer.await(StandardServer.java:346
> )
>  at org.apache.catalina.startup.Catalina.await(Catalina.java:600)
>  at org.apache.catalina.startup.Catalina.start(Catalina.java:560)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:585)
>  at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271)
>  at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409)
>
>
> -
> 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: r332766 - in /tomcat: connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11BaseProtocol.java connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11Protocol.java co

[Costin Manolache]

On 11/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: pero
> Date: Sat Nov 12 04:29:58 2005
> New Revision: 332766
>
> URL: http://svn.apache.org/viewcvs?rev=332766&view=rev
> Log:
> Fix that the RequestProcessor registered at JMX.
> It was nice to see this information back inside manager app :-)


tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11BaseProtocol.java
Sat Nov 12 04:29:58 2005
> @@ -54,11 +54,6 @@
>  public class Http11BaseProtocol implements ProtocolHandler
>  {
>  public Http11BaseProtocol() {
> -cHandler = new Http11ConnectionHandler( this );
> -setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
> -setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
> -setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
> -setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
>  }
>
>  /**
>  public class Http11Protocol extends Http11BaseProtocol implements 
> MBeanRegistration
>  {
>  public Http11Protocol() {
> -super();
> +cHandler = new JmxHttp11ConnectionHandler( this );
> +setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
> +setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
> +setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
> +setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
>  }
>


Can we have the setSoLinger, etc in the base as well ? After this
change, the base is probably broken - I'm using it as non-jmx,
standalone http connector.
Maybe in an init function - overriden ?


Costin

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

Re: [Fwd: Re: svn commit failed]

[Costin Manolache]

At least with subclipse 0.9.37 - I can't import existing projects
checked out with CLI svn.

The name change is to allow "checkout" - and have the checked out
files match the normal structure, so build with ant will work too.

Costin

On 11/12/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Others might find this useful. Note this was before Costin made his
> changes to the .project and .classpath files and I haven't seen what
> effect those changes have.
>
> Mark
>
>  Original Message 
> To: [EMAIL PROTECTED]
>
> Henri,
>
> There are lots of different ways to do this. I have been playing
> around for a few hours and I think this is the best.
>
> Pre-requisites:
> - svn command line client
> - Eclipse 3.1 (workspace of c:\workspace)
> - Subclipse
>
> 1. Open the SVN Repository View
>
> 2. Add a new repository
> - URL:  https://svn.apache.org/repos/asf/tomcat
> - Root URL: https://svn.apache.org/repos/asf
> - User: hgomez
> - Password: **
>
> 3. Checkout the tc5.5.x sources into your workspace using the command
> line svn client
> svn checkout https://svn.apache.org/repos/asf/tomcat/current/tc5.5.x
> c:\workspace
>
> 4. Use Windows->Preferences and then Java->Build Path->Classpath
> Variables to add a new Classpath variable called "TOMCAT_LIBS_BASE"
> and set this to the base path where the binary dependencies have been
> downloaded.
>
> 5. Create new Java projects called Connectors, Container, Jasper and
> ServletAPI. Since the project name you specify matches the name of one
> of the directories created by step 3, Eclipse will use the existing
> .project and .classpath files
>
> 6. Away you go...
>
> If you want to browse the whole ASF repo, use
> https://svn.apache.org/repos/asf as the URL as well as the Root URL in
> step 2
>
> HTH,
>
> Mark
>
> Henri Gomez wrote:
> > Mark, what's the correct settings to connect to SVN from Eclipse to
> > get Tomcat 5, Jasper and JTC (as a commiter of course) ?
> >
> > Regards and thanks for your advices
> >
> > 2005/11/7, Mark Thomas <[EMAIL PROTECTED]>:
> >
> >>Tim Funk wrote:
> >>
> >>>I was trying to update the faq and on commit I get:
> >>>
> >>>svn: Commit failed (details follow):
> >>>svn: MKACTIVITY of
> >>>'/repos/asf/!svn/act/cbfb08b7-fd04-0410-812a-daddc51de6cc': 403
> >>>Forbidden (http://svn.apache.org)
> >>>
> >>>I (think I) have the correct ID and password. Am I missing karma?
> >>>
> >>>-Tim
> >>
> >>Looks like this was over http. Commits must be over https.
> >>
> >>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]
>
>

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

Re: svn commit: r332806 - in /tomcat/jasper/tc5.5.x: .classpath .project

[Costin Manolache]

I'll fix this, sorry - I think I have made few changes to my properties.

What is "svn co .../current" doing - I was using this before realizing
that current doesn't work in eclipse, never used resources/build.xml

In the top level build.xml - jasper project is still called "jasper" -
are we supposed to co jasper2 as jasper ? This is all so confusing and
painfull...

Is it too late to just move everything in one directory - and avoid
all this forest ? I think we allways tag and branch all the components
( jasper, container, connectors, etc ), it is so much easier to work
with a single tree. Really - there are historic reasons why we had
this in CVS, but they are long gone..

Costin


On 11/12/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> The command line build doesn't check out this directory, it checks out
> the jasper2 directory. That is why the .project & .classpath files
> were created one level lower down. Are you using the latest build.xml
> (http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x/resources/build.xml)?
>
>
> Mark
>
> [EMAIL PROTECTED] wrote:
> > Author: costin
> > Date: Sat Nov 12 10:07:58 2005
> > New Revision: 332806
> >
> > URL: http://svn.apache.org/viewcvs?rev=332806&view=rev
> > Log:
> > Another change - sorry if I mess up everything, but the svn plugin is
> > really frustrating and I think it is important to have a consistent
> > environment when working in eclise and in ant/CLI.
> >
> >
> > Added:
> > tomcat/jasper/tc5.5.x/.classpath
> > tomcat/jasper/tc5.5.x/.project
> >
> > Added: tomcat/jasper/tc5.5.x/.classpath
> > URL: 
> > http://svn.apache.org/viewcvs/tomcat/jasper/tc5.5.x/.classpath?rev=332806&view=auto
> > ==
> > --- tomcat/jasper/tc5.5.x/.classpath (added)
> > +++ tomcat/jasper/tc5.5.x/.classpath Sat Nov 12 10:07:58 2005
> > @@ -0,0 +1,11 @@
> > +
> > +
> > + 
> > +  > path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
> > +  > path="servletapi"/>
> > +  > path="TOMCAT_LIBS_BASE/commons-logging-1.0.4/commons-logging-api.jar"/>
> > +  > path="TOMCAT_LIBS_BASE/apache-ant-1.6.5/lib/ant.jar"/>
> > +  > path="TOMCAT_LIBS_BASE/commons-el-1.0/commons-el.jar"/>
> > +  > path="TOMCAT_LIBS_BASE/eclipse/plugins/org.eclipse.jdt.core_3.1.1.jar"/>
> > + 
> > +
> >
> > Added: tomcat/jasper/tc5.5.x/.project
> > URL: 
> > http://svn.apache.org/viewcvs/tomcat/jasper/tc5.5.x/.project?rev=332806&view=auto
> > ==
> > --- tomcat/jasper/tc5.5.x/.project (added)
> > +++ tomcat/jasper/tc5.5.x/.project Sat Nov 12 10:07:58 2005
> > @@ -0,0 +1,17 @@
> > +
> > +
> > + jasper
> > + 
> > + 
> > + 
> > + 
> > + 
> > + org.eclipse.jdt.core.javabuilder
> > + 
> > + 
> > + 
> > + 
> > + 
> > + org.eclipse.jdt.core.javanature
> > + 
> > +
> >
> >
> >
> > -
> > 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: svn commit: r332806 - in /tomcat/jasper/tc5.5.x: .classpath .project

[Costin Manolache]

On 11/12/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > I'll fix this, sorry - I think I have made few changes to my properties.
> >
> > What is "svn co .../current" doing - I was using this before realizing
> > that current doesn't work in eclipse, never used resources/build.xml
>
> It is using svn:externals to bring the various modules together under
> a single directory. See the svn manual for an explanation of what
> externals are and how they work.

Except they don't seem to work from the eclipse plugin ( at least not for me ).



>
> > In the top level build.xml - jasper project is still called "jasper" -
> > are we supposed to co jasper2 as jasper ? This is all so confusing and
> > painfull...
>
> Agreed this is painful but the build script does all this for you.
> build.xml and Subclipse are not totally interchangeable. They will
> work together if you do the initial checkout using build.xml as per
> the directions I wrote for Henri.

No luck with this - subclipse refused to import. What version of
eclipse/subclipse is working
for you ?



> Removing the jasper2 directory would be best but I didn't have the
> time to fix everything this might break.

Ok, but if we are checking out jasper2 directly  - can we call the directory
"jasper2" and use "jasper2" in the build.xml ?

My problem is that there are too many variations and indirection and
conflicting naming
schemes that are involved - in jasper case, the project is called
"Jasper", the svn dir is jasper2,
and build.xml is using "jasper". And it is checked out in a different
way than all other components - not from tc5.5.x ( or truck - another
variation in connector ), but a subdir.



> > Is it too late to just move everything in one directory - and avoid
> > all this forest ?
>
> The current directory does exactly this using externals.

Except it doesn't allways work - and it doesn't match what
resources/build.xml is doing.
If someone is using current/ ( as I did in CLI ) - he'll have a
different structure than someone using build.xml.  And if someone uses
"checkout project" from eclipse - he'll get yet another structure, not
compatible with either build.xml or  resources/build.xml.



>
> > I think we allways tag and branch all the components
> > ( jasper, container, connectors, etc ), it is so much easier to work
> > with a single tree. Really - there are historic reasons why we had
> > this in CVS, but they are long gone..
>
> I did look at other structures when we moved to SVN. Our current
> structure is the one that:
> - enabled us to migrate in stages
> - required minimal changes to our build scripts
> - made little/no difference to the effort required to create a release
> - required minimal manual (actually scripted) intervention to do the
> migration
> - enabled us to maintain the traceability of our previous releases
>
> All the other options I considered caused big problems in one or more
> of these areas and offered little benefit. That being said, if you
> have a proposal for an alternative structure then I would love to see it.

Well, my proposal is to at least keep the naming and scheme consistent.

No Jasper/jasper/jasper2 - only one. If current/ can be made to work
with subclipse - use it
in resources/build.xml as well. If not - remove it, and stick with
what is used in resources/

Is it possible to "move" svn repositories, preserving history ?

To be honest - if having a spaghetti tree is the price for preserving
history, let's just create a new repo, copy the current head from all
the subtrees we care - and move on. It sucks - but at least in future
things will be simpler.

Or just move back to CVS - it just worked. It ASF infra can't host it
- maybe find someone who can, or move it to sourceforge or some place
that can support CVS.

Costin

>
> 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: svn commit: r332806 - in /tomcat/jasper/tc5.5.x: .classpath .project

[Costin Manolache]

BTW - Mark, many thanks for all this work in moving to SVN, I
understand how difficult it is
and how limiting and immature SVN  and svn tools are.

Costin

On 11/12/05, Costin Manolache <[EMAIL PROTECTED]> wrote:
> On 11/12/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> > Costin Manolache wrote:
> > > I'll fix this, sorry - I think I have made few changes to my properties.
> > >
> > > What is "svn co .../current" doing - I was using this before realizing
> > > that current doesn't work in eclipse, never used resources/build.xml
> >
> > It is using svn:externals to bring the various modules together under
> > a single directory. See the svn manual for an explanation of what
> > externals are and how they work.
>
> Except they don't seem to work from the eclipse plugin ( at least not for me 
> ).
>
>
>
> >
> > > In the top level build.xml - jasper project is still called "jasper" -
> > > are we supposed to co jasper2 as jasper ? This is all so confusing and
> > > painfull...
> >
> > Agreed this is painful but the build script does all this for you.
> > build.xml and Subclipse are not totally interchangeable. They will
> > work together if you do the initial checkout using build.xml as per
> > the directions I wrote for Henri.
>
> No luck with this - subclipse refused to import. What version of
> eclipse/subclipse is working
> for you ?
>
>
>
> > Removing the jasper2 directory would be best but I didn't have the
> > time to fix everything this might break.
>
> Ok, but if we are checking out jasper2 directly  - can we call the directory
> "jasper2" and use "jasper2" in the build.xml ?
>
> My problem is that there are too many variations and indirection and
> conflicting naming
> schemes that are involved - in jasper case, the project is called
> "Jasper", the svn dir is jasper2,
> and build.xml is using "jasper". And it is checked out in a different
> way than all other components - not from tc5.5.x ( or truck - another
> variation in connector ), but a subdir.
>
>
>
> > > Is it too late to just move everything in one directory - and avoid
> > > all this forest ?
> >
> > The current directory does exactly this using externals.
>
> Except it doesn't allways work - and it doesn't match what
> resources/build.xml is doing.
> If someone is using current/ ( as I did in CLI ) - he'll have a
> different structure than someone using build.xml.  And if someone uses
> "checkout project" from eclipse - he'll get yet another structure, not
> compatible with either build.xml or  resources/build.xml.
>
>
>
> >
> > > I think we allways tag and branch all the components
> > > ( jasper, container, connectors, etc ), it is so much easier to work
> > > with a single tree. Really - there are historic reasons why we had
> > > this in CVS, but they are long gone..
> >
> > I did look at other structures when we moved to SVN. Our current
> > structure is the one that:
> > - enabled us to migrate in stages
> > - required minimal changes to our build scripts
> > - made little/no difference to the effort required to create a release
> > - required minimal manual (actually scripted) intervention to do the
> > migration
> > - enabled us to maintain the traceability of our previous releases
> >
> > All the other options I considered caused big problems in one or more
> > of these areas and offered little benefit. That being said, if you
> > have a proposal for an alternative structure then I would love to see it.
>
> Well, my proposal is to at least keep the naming and scheme consistent.
>
> No Jasper/jasper/jasper2 - only one. If current/ can be made to work
> with subclipse - use it
> in resources/build.xml as well. If not - remove it, and stick with
> what is used in resources/
>
> Is it possible to "move" svn repositories, preserving history ?
>
> To be honest - if having a spaghetti tree is the price for preserving
> history, let's just create a new repo, copy the current head from all
> the subtrees we care - and move on. It sucks - but at least in future
> things will be simpler.
>
> Or just move back to CVS - it just worked. It ASF infra can't host it
> - maybe find someone who can, or move it to sourceforge or some place
> that can support CVS.
>
> Costin
>
> >
> > 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: Repo clean up

[Costin Manolache]

connectors/naming, connectors/webapp, connectors/jk/native2.

I'm not sure touching 4.1 tree is a good idea - we should do it in
HEAD ( i.e. 5.5 ) first ( and maybe only in HEAD ).


Costin

On 11/12/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Back we I was doing the SVN migration, a clean-up of our code base was
> briefly mentioned. At the time, I said I would start a thread to
> gather candidates for clean-up once the migration was complete. Since
> the migration is complete, this is the thread.
>
> I will post a question to the infra@ list to see what is the
> recommended/official way of doing this. The options appear to be
> delete it or move it. Since it is easily retrievable from a previous
> tag, I see no reason not to just delete it.
>
> I'll collate everyone's suggestions/comments into a single proposal in
> a week or so.
>
> To start the list off:
> /tomcat/container/branches/tc4.1.x/jasper/
>
> 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: svn commit: r332806 - in /tomcat/jasper/tc5.5.x: .classpath .project

[Costin Manolache]

On 11/12/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> >>>What is "svn co .../current" doing - I was using this before realizing
> >>>that current doesn't work in eclipse, never used resources/build.xml
> >>
> >>It is using svn:externals to bring the various modules together under
> >>a single directory. See the svn manual for an explanation of what
> >>externals are and how they work.
> >
> >
> > Except they don't seem to work from the eclipse plugin ( at least not for 
> > me ).
>
> You can't see the contents through the http interface either :(
>
> These directories aren't browseable through any svn client that I have
> tried. The externals are properties of the directory and get processed
> on checkout. This is why you need to do the checkout using build.xml
> first. Once checked out via build.xml , Subclipse works fine for me.

I'm confused - build.xml seems to checkout the real dirs, not current
- I found no reference to current/ in build.xml

How are you making subclipse see the project ? Team->share doesn't do it for me.

Costin

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

Re: svn commit: r332823 - in /tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11: Http11BaseProtocol.java Http11Protocol.java

[Costin Manolache]

Thanks.

Costin

On 11/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: pero
> Date: Sat Nov 12 11:23:00 2005
> New Revision: 332823
>
> URL: http://svn.apache.org/viewcvs?rev=332823&view=rev
> Log:
> Refactor connection handler for better standalone support
> without JMX.
>
> Modified:
> 
> tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11BaseProtocol.java
> 
> tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
>
> Modified: 
> tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11BaseProtocol.java
> URL: 
> http://svn.apache.org/viewcvs/tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11BaseProtocol.java?rev=332823&r1=332822&r2=332823&view=diff
> ==
> --- 
> tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11BaseProtocol.java
>  (original)
> +++ 
> tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11BaseProtocol.java
>  Sat Nov 12 11:23:00 2005
> @@ -104,11 +104,20 @@
>  public Adapter getAdapter() {
>  return adapter;
>  }
> -
> +
> +protected Http11ConnectionHandler createConnectionHandler() {
> +Http11ConnectionHandler cHandler = new Http11ConnectionHandler( this 
> );
> +setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
> +setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
> +setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
> +setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
> +return cHandler ;
> +}
>
>  /** Start the protocol
>   */
>  public void init() throws Exception {
> +cHandler = createConnectionHandler() ;
>  ep.setConnectionHandler( cHandler );
>  try {
>  checkSocketFactory();
>
> Modified: 
> tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
> URL: 
> http://svn.apache.org/viewcvs/tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11Protocol.java?rev=332823&r1=332822&r2=332823&view=diff
> ==
> --- 
> tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
>  (original)
> +++ 
> tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
>  Sat Nov 12 11:23:00 2005
> @@ -59,13 +59,23 @@
>  public class Http11Protocol extends Http11BaseProtocol implements 
> MBeanRegistration
>  {
>  public Http11Protocol() {
> +/*
>  cHandler = new JmxHttp11ConnectionHandler( this );
>  setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
>  setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
>  setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
>  setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
> +*/
> +}
> +
> +protected Http11ConnectionHandler createConnectionHandler() {
> +Http11ConnectionHandler cHandler = new JmxHttp11ConnectionHandler( 
> this );
> +setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
> +setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
> +setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
> +setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
> +return cHandler ;
>  }
> -
>
>  ObjectName tpOname;
>  ObjectName rgOname;
>
>
>
> -
> 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: r332806 - in /tomcat/jasper/tc5.5.x: .classpath .project

[Costin Manolache]

On 11/13/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > I'm confused - build.xml seems to checkout the real dirs, not current
> > - I found no reference to current/ in build.xml
>
> I think that makes two of us ;)
> You are right. We could change build.xml to use current. I'll test
> this and if it works, make the change.


> I am going to try and create a new, clean TC5.5.x build environment. I'll try 
> and iron out any
> inconsistencies as I go.

That makes two of us :-)  What do you think of the build.xml in sandbox ?

The current multi-layer build.xml, combined with svn, naming
conventions, etc gives me headaches - unfortunately I no longer have a
lot of time for tomcat, so keeping track is much harder. But I'm very
happy with eclipse build - I run tomcat from inside eclipse, using the
launcher I checkedin - since it's the same environment with
runtime-all.jar that I'm working on.


>
> > How are you making subclipse see the project ? Team->share doesn't do it 
> > for me.
>
> I had to add https://svn.apache.org/asf/repos/tomcat to my list of
> repositories in Subclipse SVN repository view. Once I did that, it all
> just worked.

What version are you using ? I have it in my list of repos.

Please check the same thing with current/ - if it doesn't work, then
don't change build.xml :-)

Costin

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

Re: Is the JSSE15SocketFactory class missing from the standard tomcat 5.5.12 binary distribution?

[Costin Manolache]

+1 on building with 1.5 by default. And cleaning the remaining few warnings too.

Costin

On 11/17/05, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> Hi,
> Mmm, I'm not sure.  The download page is already somewhat cluttered with a
> bunch of different distributions and their assorted files (zip/tar.gz, PGP and
> MD5 for each, etc.)  I don't want to double the number of binary distributions
> per release.
>
> And I'm even less excited about doing something like retroweaver
> (http://retroweaver.sourceforge.net/) to cross-compile 1.5 source to 1.4
> compatibility.
>
> But perhaps it's time we just start building with J2SE 5.0 by default, instead
> of 1.4?
>
> Yoav
>
> --- Bruce Keats <[EMAIL PROTECTED]> wrote:
>
> > Is is possible to put 5.0 JSK version up on the downloads site? I can
> > certainly build the missing JSSE components, but I would rather stick with a
> > prebuilt official version.
> >  Bruce
> >
> >  On 11/17/05, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > > Bill is correct.
> > >
> > > I do have both the 1.4 and 5.0 JDKs on my build machine. I wonder if we
> > > should
> > > change the build.xml to build both if both are present, rather than just
> > > one.
> > > Would we have multiple JAVA_HOMEs? Seems dirty...
> > >
> > > Yoav
> > >
> > > --- Bill Barker <[EMAIL PROTECTED]> wrote:
> > >
> > > > I believe that Yoav creates the binary distro with a 1.4 JVM, so the
> > > > 15SocketFactory is excluded.
> > > >
> > > > You need to compile at least JSSE15*.java. However it's probably easier
> > > to
> > > > just build all of j-t-c/util.
> > > >
> > > > - Original Message -
> > > > From: "Bruce Keats" <[EMAIL PROTECTED]>
> > > > To: "Tomcat Developers List" 
> > > > Sent: Thursday, November 17, 2005 2:45 PM
> > > > Subject: Is the JSSE15SocketFactory class missing from the standard
> > > tomcat
> > > > 5.5.12 binary distribution?
> > > >
> > > >
> > > > Hi,
> > > > I am trying to track down an issue with the lack of CRL support in
> > > tomcat
> > > > 5.5.12. I turned on logging in
> > > > org.apache.tomcat.util.net.jsee.JSSEImplementation and low and behold,
> > > the
> > > > debug log on line 57 generated a ClassNotFoundException when trying to
> > > load
> > > > JSSE15SocketFactory. However, it was able to load the
> > > JSSE14SocketFactory
> > > > (which is in the same directory/classpath). Since it was able to load
> > > the
> > > > JSSE14SocketFactory, I assume this is not a class path issue.
> > > > We are using tomcat 5.5.12 with JAVA 1.5.0_05.
> > > > I checked the source distribution and the class is there. Is
> > > > JSSE15SocketFactory class not part of the standard binary distribution?
> > > Is
> > > > there a different JAR file I have to use? Is there a configuation option
> > > I
> > > > need? Do I need to rebuild the source using JAVA 1.5?
> > > > Bruce
> > > >
> > > >
> > > >
> > > > This message is intended only for the use of the person(s) listed above
> > > as
> > > > the intended recipient(s), and may contain information that is
> > > PRIVILEGED and
> > > > CONFIDENTIAL. If you are not an intended recipient, you may not read,
> > > copy,
> > > > or distribute this message or any attachment. If you received this
> > > > communication in error, please notify us immediately by e-mail and then
> > > > delete all copies of this message and any attachments.
> > > >
> > > > In addition you should be aware that ordinary (unencrypted) e-mail sent
> > > > through the Internet is not secure. Do not send confidential or
> > > sensitive
> > > > information, such as social security numbers, account numbers, personal
> > > > identification numbers and passwords, to us via ordinary (unencrypted)
> > > > e-mail.
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > > Yoav Shapira
> > > System Design and Management Fellow
> > > MIT Sloan School of Management
> > > Cambridge, MA, USA
> > > [EMAIL PROTECTED] / www.yoavshapira.com 
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>
> Yoav Shapira
> System Design and Management Fellow
> MIT Sloan School of Management
> Cambridge, MA, USA
> [EMAIL PROTECTED] / www.yoavshapira.com
>
> -
> 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: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?

[Costin Manolache]

Check the build.xml files, look for 'unless'.

Probably the right solution to avoid this would be to stop using
'unless' and ant checks,
and instead move all the 'conditional' code in separate targets and
jar files. In particular, the
whole SSL stuff is an unpredictible mess.

I'm not even sure if/how can we use OpenSSL via APR ( I found some
code, and it should work ). The whole connection layer should be
refactored to allow better abstraction for APR, NIO, old-style
sockets/threads... The current approach in APR ( duplicate everything
) may be good for quick tests, but it can't be the long term solution
( some people like to add a NIO equivalent ).

Costin

On 11/18/05, Bruce Keats <[EMAIL PROTECTED]> wrote:
> Hi,
>  Given the discussion on missing JSSE15SocketFactory because tomcat
> 5.5.12was build using JAVA
> 1.4, I am trying to determine if I need to rebuild the whole source tree
> under JSDK 5.0 or just the missing JSSE15SocketFactory. In order to make
> that judgement call, I need to understand if there is any other
> functionality that is missing.
>  Other than JSSE15SocketFactory, is there any other functionality missing
> from tomcat 5.5.12 because it was build using JAVA 1.4?
>  Bruce
>
>

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

Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?

[Costin Manolache]

On 11/18/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:

> >
> > I'm not even sure if/how can we use OpenSSL via APR ( I found some
> > code, and it should work ). The whole connection layer should be
>
> It actually works.

I'm happy I got regular HTTP/APR working, wasn't easy :-)


>
> > refactored to allow better abstraction for APR, NIO, old-style
> > sockets/threads... The current approach in APR ( duplicate everything
> > ) may be good for quick tests, but it can't be the long term solution
> > ( some people like to add a NIO equivalent ).
>
> I'm perfectly fine with it. I prefer duplicating things than having a
> complex abstraction layer (if you compare the APR API with the NIO/Java
> IO API, you'll see APR is simpler, so the connector code can be a bit
> simpler - for equivalent functionality at least). At this point, I see
> non APR connectors as having no future production wise.

So for NIO - we should create another copy of 5 large files ? Most of
the functions are complete duplicates - a simple extend would eliminate
them.

The problems are in few abstractions - like Handler - which can be
easily fixed to
accomodate NIO / APR or traditional.

NIO is a valid solution - and may be as fast as APR, in particular
with JDK1.6 -
and it avoids the JNI layer.

I like APR more too - but I don't think it's wise to say there will be
no better solution
in the future :-) It just happens that today APR is faster - and has a
lot of features beyond
NIO.

IMO the future is in features integrated at the low-level with the VM
- in particular
if they can bypass JNI or use non-garbage-collected heaps ( as in
real-time java ). It
would be hard for any JNI solution to beat this - but of course,
that's future, not so easy
to predict...

Costin

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

Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?

[Costin Manolache]

On 11/18/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > So for NIO - we should create another copy of 5 large files ? Most of
> > the functions are complete duplicates - a simple extend would eliminate
> > them.
> >
> > The problems are in few abstractions - like Handler - which can be
> > easily fixed to
> > accomodate NIO / APR or traditional.
> >
> > NIO is a valid solution - and may be as fast as APR, in particular
> > with JDK1.6 -
> > and it avoids the JNI layer.
> >
> > I like APR more too - but I don't think it's wise to say there will be
> > no better solution
> > in the future :-) It just happens that today APR is faster - and has a
> > lot of features beyond
> > NIO.
> >
> > IMO the future is in features integrated at the low-level with the VM
> > - in particular
> > if they can bypass JNI or use non-garbage-collected heaps ( as in
> > real-time java ). It
> > would be hard for any JNI solution to beat this - but of course,
> > that's future, not so easy
> > to predict...
>
> I completely disagree. APR is a well accepted IO impl for webservers
> (obviously), and works very well.

For C++ servers - yes.
For Java servers - is anyone else using it besides tomcat ? Even in
tomcat - how many
people are using the bindings ( compared with the non-apr connector ) ?

Unfortunately - NIO is the well-accepted solution for java servers (
all except tomcat
are using it ). We know APR is better - but can't pretend it's an
'accepted' solution.


> There's room for experimentation as
> separate implementations, but should NIO get better and support the
> features we need (somehow, I doubt the second one will ever be the case
> ...), there's going to be ample time to switch to it later (emphasis on
> later; Java 6 as the Tomcat target is quite far away). In the meantime,
> I don't see the point of yet another abstraction layer.

Not a new abstraction layer - just adjustments to the current one.
For example - add the 'long' socket to TcpConnection - and adjust comments in
TcpConnectionHandler - so it can be used instead of the Handler. Then most Apr
classes could extend the corresponding non-APR classes, and only
override what's
different.

It's not the perfect abstraction - but if you also add NIO, you could
later extract
a base class that has none of the apr/nio/classic methods, and avoid
duplication.
Adding NIO in the same way as APR was added would be a nightmare - the current
APR code is already messy ( Sendfile for example ).

I'm sorry, I like APR, but I can't like the current implementation (
except as a good
initial step ).

Costin

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

Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?

[Costin Manolache]

On 11/18/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > For C++ servers - yes.
> > For Java servers - is anyone else using it besides tomcat ? Even in
> > tomcat - how many
> > people are using the bindings ( compared with the non-apr connector ) ?
> >
> > Unfortunately - NIO is the well-accepted solution for java servers (
> > all except tomcat
> > are using it ). We know APR is better - but can't pretend it's an
> > 'accepted' solution.
>
> The truth is, few people are using Java web servers, and it's not going
> to change. I'm curious to know how NIO is a well accepted solution for
> web servers, BTW.

NIO is used AFAIK by Jetty and Resin, and probably others. And it's
the 'standard'
solution for select-like operations ( even if the standard is as usual
not the best solution ).


> > I'm sorry, I like APR, but I can't like the current implementation (
> > except as a good
> > initial step ).
>
> Again, I completely disagree. The low level code is small enough that an
> abstraction layer is useless. Similarly, a lot of the code in j-t-c/util
> should go (starting with the "threads" package).

Agree, the threads package shouldn't be used as an API - and a lot of code in
j-t-c/util should be deprecated. One of the nice things about NIO is
that you can't
get rid of a lot of some stuff.

Duplicating the entire HTTP parser class just because you don't want a
small abstraction
( which was actually already there ) is not right.



> To get down to the root of the problem, I don't like the argument that
> NIO is any good as an IO API. Besides the (many) utility classes like
> the buffers, and as a JNI access method, both of which can be used
> without sencond thoughts (and are actually used right now), all the
> actual IO code is still all native (no surprise) and the Java API on top
> is over engineered. It doesn't make sense to me.

Well, most java APIs - including the servlet - are over engineered.
And most are
far from perfect solution ( again, servlet is a good example :-). Yes,
I also hate
the way buffers flip and you can't know where is the data ( before or
after position ),
most of the channel and select are more complex than the APR equivalent.

But NIO is a valid solution - with 1.6 I'm pretty sure the performance
will be comparable
( with poll, etc ). APR is not the only valid solution ( and on top of
that - the way we
implement the connector on top of APR is far from either simple or right ).


Costin

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

Re: [VOTE] APR or NIO ? (was:Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?)

[Costin Manolache]

On 11/19/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> 
> I think the IO design for connectors used by Tomcat should be:
> [X] NIO selectors, etc (this means 100% NIO)
> [X] APR (this means 50% NIO, where NIO is only used for all the objects
> exposed at the higher level)
> 

Obviously, I vote both - plus the classical style. There is no reason
to have only one,
just like we support multiple SSL implementations and multiple realms
- we can support
multiple techniques to do IO.

Costin

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

Re: [VOTE] APR or NIO ?

[Costin Manolache]

On 11/19/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Mladen Turk wrote:
> > No.
> > I would like that we accept in our (Tomcat) community much
> > more pluralism, in a similar way the Apache httpd community
> > does with mpm models.
> >
> > Neither blocking, APR or eventually NIO will ever be
> > the best solution for a particular user needs.
> > Blocking will outperform any solution for a complex
> > applications. APR will outperform any other solution
> > where large static file delivery is required, etc...
> >
> > Let's focus and actually see if the current connector
> > API allows to build those various connectors.
> > I think it does, so it's up to implementor to implement
> > the connector.
> >
> > Then, we can simply have multiple connectors that will
> > allow users to choose the optimal one according to the
> > needs, not to what we think he might need.
>
> I do not wish to have any pluralism in this area, as it is not the same
> as having the httpd pluralism. There's a functional need for this
> pluralism (process friendly OS, thread unsafe modules, etc), and besides
> we're talking about the IO API, not the thread pool.
>
> The question is: should we redesign the low level stuff *again* to be
> more abstract, etc, to be able to have as little IO API specific code in
> the connectors ? (and most likely standardize on the limited NIO feature
> set) My answer to this is no, APR is the only good solution right now,
> so there's no need for more abstraction layers.

HTTPD did that to support multiple mpms.

Remy - the actual issue is not NIO or APR.

The question is:

Do you think APR implementation, and the low leve APIs ( with all the
duplicate code, and the current abstractions, incliuding sendfile )
are the right ones ?

< > 1. Yes, it's how things should be done
< >  2. No, it can be done better

My opionion is (2).

Costin

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

Re: [VOTE] APR or NIO ?

[Costin Manolache]

> The question is:
>
> Do you think APR implementation, and the low leve APIs ( with all the
> duplicate code, and the current abstractions, incliuding sendfile )
> are the right ones ?

To clarify - this is not only about APR, but also  *Endpoint,
TcpConnectoin/TcpConectionHandler, util.buf, util.thread,
coyote.httpd.
All were designed without considering 'mpm's correctly, and I think
that forced the current APR impl.

Costin

>
> < > 1. Yes, it's how things should be done
> < >  2. No, it can be done better
>
> My opionion is (2).
>
> Costin
>

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

Re: [VOTE] APR or NIO ? (was:Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?)

[Costin Manolache]

On 11/19/05, Yoav Shapira <[EMAIL PROTECTED]> wrote:

> On a related note, we can add a server-highperformance.xml configuration file
> that ships with Tomcat, and uses APR and whatever else we can think of to
> increase perfdormance out of the box.  This is similar to the multiple
> httpd-XXX.conf files that ship with the HTTP web server.

That brings up another issue - you only have to have the .so file in
your path and the
current httpd.conf will pick it up and magically use APR. Having a
clear option 'use apr'
or a clear apr connector is IMO a cleaner solution, and can avoid some
headaches ( I had
problems with debugging inside eclipse when the .so was loaded, etc )

Costin

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

Re: [VOTE] APR or NIO ?

[Costin Manolache]

On 11/19/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > < > 1. Yes, it's how things should be done
> > < >  2. No, it can be done better
> >
> > My opionion is (2).
>
> My opinion is 1. I will not participate in the design of the upcoming
> Tomcat branch, then.

Well, I'm not planning any 'upcoming branch' - or 'design' for that
matter, just
small adjustments, in sandbox first.

Costin

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

Labels in SVN ?

[Costin Manolache]

Does anyone know what's the best way to put a small label in a subdir
( connectors/util and
connectors/http11 ). I don't want to label anything else - I need this
to track changes for the sandbox version. Is SVN tag the same as in
cvs ?

Costin

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

Re: Labels in SVN ?

[Costin Manolache]

What I want is to be able to do "cvs diff -r my_label_before_sandbox_copy",
so I can see what changed.
I want to keep my experiments in the sandbox - instead of a branch.

Costin


On 11/19/05, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm not an SVN expert, but I understanding is you have two options.
>
> The more basic option is to branch the directory and work in your branch,
> occassionally updating the tag label as you want.  The relevant SVN commands
> are at http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-4-sect-4.4.2.
> This is similar to the CVS way of doing things.
>
> The other option is to use SVN properties.  This is different from the CVS way
> and it seems riskier, as there's still only one version of the file itself, 
> but
> you have labels on any file / directories you want, and the labels themselves
> are version-controlled.
> http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-2
>
> So it kind of depends on what exactly you want to do, and specifically the
> probability that you will want your own branch as opposed to just tracking
> labels and other metadata...
>
> Yoav
>
> --- Costin Manolache <[EMAIL PROTECTED]> wrote:
>
> > Does anyone know what's the best way to put a small label in a subdir
> > ( connectors/util and
> > connectors/http11 ). I don't want to label anything else - I need this
> > to track changes for the sandbox version. Is SVN tag the same as in
> > cvs ?
> >
> > Costin
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> Yoav Shapira
> System Design and Management Fellow
> MIT Sloan School of Management
> Cambridge, MA, USA
> [EMAIL PROTECTED] / www.yoavshapira.com
>
> -
> 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: Labels in SVN ?

[Costin Manolache]

I was not sure if you can tag a small subtree ( connectors/util/java )
, or only the entire connectors/.

I think I'll just do diffs by date - it's probably easier.

Costin



On 11/20/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > What I want is to be able to do "cvs diff -r my_label_before_sandbox_copy",
> > so I can see what changed.
> > I want to keep my experiments in the sandbox - instead of a branch.
> >
> > Costin
>
> Copies are cheap in SVN, so tags are just copies. And in a similar
> manner to CVS branches are just tags that you start making changes to.
>
> What I suggest is that I make the following SVN changes:
> - create /sandbox/trunk, /sandbox/tags, /sandbox/branches
> - move the current contents of /sandbox to /sandbox/trunk
>
> Then when you want to make a tag you just do a copy of the form
> svn copy https://svn.apache.org/repos/asf/tomcat/sandbox/optional/path
> https://svn.apache.org/repos/asf/tomcat/sandbox/tags/nameOfTag
>
> This way you can tag all of sandbox or just part of it.
>
> Let me know if you want me to make the top level changes to sandbox or
> if you are happy making them yourself.
>
> 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: [VOTE] APR or NIO ?

[Costin Manolache]

I hope you are not serious... Sorry if I sounded too critical of the
APR code - it is a great
piece of code in many ways, I just didn't like some (probably minor) things.

If you have a problem with 'refactoring' - right now it is in sandbox,
and I can as well
change the package name and make it a completely separate connector.
And I'm in no hurry to
check anything in the main branch - the sandbox is prefect for me, so
no need to worry about this.

Costin

On 11/20/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > On 11/19/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> >
> >>Costin Manolache wrote:
> >>
> >>>< > 1. Yes, it's how things should be done
> >>>< >  2. No, it can be done better
> >>>
> >>>My opionion is (2).
> >>
> >>My opinion is 1. I will not participate in the design of the upcoming
> >>Tomcat branch, then.
> >
> > Well, I'm not planning any 'upcoming branch' - or 'design' for that
> > matter, just
> > small adjustments, in sandbox first.
>
> Fair enough. The minute you commit your "refactoring" to the main
> branch, I will leave this project (besides casual bugfixing).
>
> 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: svn commit: r345767 - in /tomcat/sandbox/java/org/apache/coyote/http11: Http11AprProcessor.java Http11Processor.java InternalAprInputBuffer.java InternalInputBuffer.java

[Costin Manolache]

On 11/20/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Author: costin
> > Date: Sun Nov 20 10:19:56 2005
> > New Revision: 345767
> >
> > URL: http://svn.apache.org/viewcvs?rev=345767&view=rev
> > Log:
> > Remove even more dups. It seems the apr and non-apr were not actually in
> > sync, there are at least 2 places where extra SecurityManager magic was
> > used in non-apr.
> >
> > Modified:
> > tomcat/sandbox/java/org/apache/coyote/http11/Http11AprProcessor.java
> > tomcat/sandbox/java/org/apache/coyote/http11/Http11Processor.java
> > tomcat/sandbox/java/org/apache/coyote/http11/InternalAprInputBuffer.java
> > tomcat/sandbox/java/org/apache/coyote/http11/InternalInputBuffer.java
>
> I am not going to bother tetsing this stuff. As you may have noticed,
> many of the algorithms used behaves in subtly different ways. The result
> of the merge is of course going to be exponentially more difficult to
> maintain (and, obviously, I am not going to be the one doing it). Why
> not removing APR support instead since you (and all the other members of
> the community, it seems) don't like it ?

I didn't say I don't like it - I like having APR support very much,
and I like APR more than
I like NIO.

I don't like 'alghoritms that behave in sublty different ways', or
duplicating extremely complex
classes just for 3-4 lines of code that is different. I know it is
simpler to write and probably maintain the code ( for people who wrote
it ), but not easier to understand for me.

In any case - it's sandbox. People can try things in sandbox - many
may not work. Think of this as a way for me to understand those subtle
alghoritms by seeing what is really different.


Costin

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

Re: [VOTE] APR or NIO ?

[Costin Manolache]

On 11/21/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > I hope you are not serious... Sorry if I sounded too critical of the
> > APR code - it is a great
> > piece of code in many ways, I just didn't like some (probably minor) things.
>
> Ok, but it helped make me realize I should maintain my own tree anyway,
> since my plans are a bit opposed to your refactoring. Also, I have
> medium term requirements which most likely are going to not fit with
> what Tomcat needs :(

Well, my need is the sandbox - so I can experiment and understand the
many things
that happened in the last years.

I didn't propose any major refactoring or new requirements - I might
need 2-3 lines of code changed in the main branch for single-jar ( it
works now with the main branch as is, but it's not
perfect ). For NIO - all I want is to see for myself how it works and
what it can do. That's what the  sandbox is supposed to do.

If you want to maintain your own tree and have some new requirements -
say so, and maybe they can go in the main branch, or maybe if they are
extremely unusual ( I doubt ) in sandbox.

>
> Yes, I guess I shouldn't complain too much about code which is being
> designed in the sandbox, sorry about that :)

Again, 'designed' is a too strong word. "Toyed with" maybe.


>
>  > I don't like 'alghoritms that behave in sublty different ways', or
>  > duplicating extremely complex
>  > classes just for 3-4 lines of code that is different. I know it is
>  > simpler to write and probably maintain the code ( for people who wrote
>  > it ), but not easier to understand for me.
>
> Yes, I understand that, but for me the algorithm is already a bit
> complex since, although it looks similar, the process method is
> completely different. Hopefully, it has no bugs right now !

Everything has bugs :-)

Yes, that is my point - it looks similar, but I had problems to
understand the differences. It's not
about comments or documentation - but about the code organization,
looking at the diffs was my
only way to understand.

Again, I don't want to touch something that works - just to
understand, and maybe create a similar prototype using NIO. Or maybe a
smaller APR connector that I can play with in 'coyote
standalone' mode ( I want to keep it as small as possible ). Or maybe
try to write a small NIO provider using APR ( and put to rest this
debate about what is better ). I don't know - just want to play in the
sandbox :-)

Costin

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

Re: SVN oddities with "current" link

[Costin Manolache]

Well, can't stop myself:

The right solution is to stop playing SVN tricks, and just reorganize
the code as a single
codebase instead of 4  (or 5). So my question remains: can we _move_
build, connectors, etc as
subdirs in a single svn tree, while preserving some file history ?


Costin

On 11/22/05, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> Hi,
> I like checking out the current link (
> https://svn.apache.org/repos/asf/tomcat/current/tc5.5.x) which uses svn
> externals to grab the container, build, connectors, etc. It's nice and
> convenient.
>
> But for committing and updating, it kind of sucks. Doing an "svn commit" or
> "svn update" at the top-level does not recursively check the modules under
> it. It just says "Skipping '.'" Even going down one level and doing "svn
> commit container connectors" for example does not work. I have to
> individually do "svn commit container" and "svn commit connectors" which
> results in two separate revisions and two commit emails to the list.
>
> Is there a way to make the commit and update work as nicely as the checkout?
> I'm not an SVN expert, just wanted to inquire...
>
> --
> Yoav Shapira
> System Design and Management Fellow
> MIT Sloan School of Management
> Cambridge, MA, USA
> [EMAIL PROTECTED] / www.yoavshapira.com 
>
>

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

Re: SVN oddities with "current" link

[Costin Manolache]

What problems ? I think it would be cleaner and more consistent with
what we do - i.e.
label/branch all components at the same time and same way.

Well, maybe 6.x would be the right time to reorg the code to a single
tree, I'll ask again when we get there ( BTW - what are the plans for
6.x ? )

Costin

On 11/22/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > Well, can't stop myself:
> >
> > The right solution is to stop playing SVN tricks, and just reorganize
> > the code as a single
> > codebase instead of 4  (or 5). So my question remains: can we _move_
> > build, connectors, etc as
> > subdirs in a single svn tree, while preserving some file history ?
>
> We could do this but I see this creating more problems when we reach a
> point where we want to start on 6.x than it will solve for us now.
>
> 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: SVN oddities with "current" link

[Costin Manolache]

Container, jasper and build are a good start. I think connectors
should be included too.

Servletapi is obviously different, and even in the current build it's
downloaded as a jar AFAIK.

You can still have separate releases and release cycles for different
components - even if they
reside in the same SVN tree ( or even same java/ source tree ). As we
learned, labels are cheap,
so there's no problem if you release and label different things.

I hope more components could follow the 'separate release' model -
/admin and most webapps,
many other things that could be modules. At least in 6.x timeframe.

Costin


On 11/22/05, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> Hi,
> I also think a re-org into a single codebase for build, container,
> jasper is in order.  Connectors and servletapi are a bit different
> because they have their own releases (and release cycles).  I think
> from the users' perspective, a single SVN repository is cleaner and
> makes building easier.
>
> 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: SVN oddities with "current" link

[Costin Manolache]

Yes, that's what I'm talking about - but on the tomcat svn :-).

Can we do the same here ? Only for HEAD ( or at least for 6.0 ), so
moving forward we could
keep things simpler.

BTW - a nice facility in eclipse and ant is the exclude, so the tree
can include multiple connectors, and multiple features - but still
have full flexibility in what is released and in what packaging.

What do you mean by "JNDI removed" - removed from the classloader and
file servlet ? That would be really nice ( at least like an option ) 
:-) What is the license on your changes ? Anything that can be
contributed back ?

Costin

> Yes, I can testify it's easier to work with, and it only took me a few
> minutes to put together (warning: it's APR only, JNDI is removed, etc,
> so a full Tomcat repository has to be more complex to build), the setup
> in Eclipse only takes a few minutes, and building is faster (no webapps,
> though).
>
> http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/
>
> 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: svn commit: r348665 - /tomcat/sandbox/java/org/apache/coyote/standalone/MainInetd.java

[Costin Manolache]

On 11/24/05, Bill Barker <[EMAIL PROTECTED]> wrote:

> > URL: http://svn.apache.org/viewcvs?rev=348665&view=rev
> > Log:
> > Another experiment - this class uses NIO to get the socket from Xinetd (
> > I'll also try
> > with launchd ). This allows starting tomcat on-demand, from xinetd/lauchd.
> > Work in progress, I also want to shutdown when idle for too long.


> About the most useless waste of svn space I could imagine.  I mean, it's
> like a total reason to close off the sandbox right here.

I can move this to sf, but it is far more usefull than a lot of code in tomcat.

Costin

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

Re: svn commit: r348665 - /tomcat/sandbox/java/org/apache/coyote/standalone/MainInetd.java

[Costin Manolache]

I'm a bit puzzled - can you explain a bit why you think it's a bad idea ???

I hope you realize this is not 'prefork' mode ( i.e. forking a tomcat
on each request ), just wait
for the first connection and pass the server socket descriptor. It's
by far the cleanest method to run tomcat on port 80 - either via
xinetd/launchd, or via another native wrapper ( compare it with
commons-daemon ). And the only clean method I know of loading tomcat
on demand - instead of keeping it running and taking memory all the
time. Tomcat is not used only for big servers, but also for
development and smaller servers - I don't like my memory used by code
that I run only once in a while.

Costin

On 11/24/05, Bill Barker <[EMAIL PROTECTED]> wrote:
>
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Author: costin
> > Date: Wed Nov 23 21:34:19 2005
> > New Revision: 348665
> >
> > URL: http://svn.apache.org/viewcvs?rev=348665&view=rev
> > Log:
> > Another experiment - this class uses NIO to get the socket from Xinetd (
> > I'll also try
> > with launchd ). This allows starting tomcat on-demand, from xinetd/lauchd.
> > Work in progress, I also want to shutdown when idle for too long.
> >
> > This is also targeted to embeded/desktop use.
> >
>
> About the most useless waste of svn space I could imagine.  I mean, it's
> like a total reason to close off the sandbox right here.
>
>
>
>
> -
> 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: r349085 - /tomcat/sandbox/java/org/apache/tomcat/util/net/NioEndpoint.java

[Costin Manolache]

On 11/25/05, Bill Barker <[EMAIL PROTECTED]> wrote:

> > The nio endpoint. Uses the thread pool. Only accept is implemented - the
> > polling of keep alive needs merging some code in the http11protocol.
> >
>
> Yup, it's still too incomplete to evaluate.  However from my work with
> NIO/AJP, using blocking sockets after the accept will totally s*ck in
> performance with NIO.  Unless you come up with something totally brilliant
> :), I still agree with JFA that non-blocking sockets is the only way to go
> with NIO.

Well, I also agree that non-blocking sockets are faster than blocking.
But as someone said, raw performance is not the most important thing
for most people :-)
My initial goal is to deal with the keep alives - i.e. not keep the
threads busy for all the idle connections. That would be a nice
improvement over the current non-nio connector, which can't do this,
and is pretty minimal and consistent with the current model.

I will eventually use the APR code for non-blocking parsing of the
request. Not sure if in this endpoint or I'll try another one - I kind
of like the fact that this code is very simple. I'm more interested in
experiments with how to do non-blocking processing at coyote level,
whatever happens in a servlet is limited by other factors - blocking
socket is not the biggest overhead.

I'll announce when it's 'complete' or 'ready to evaluate' - right now
it's just 'sandbox experiment'.
Right now - there is little point in benchmarking.

Costin

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

Re: svn commit: r349085 - /tomcat/sandbox/java/org/apache/tomcat/util/net/NioEndpoint.java

[Costin Manolache]

On 11/25/05, Bill Barker <[EMAIL PROTECTED]> wrote:

> Urm, APR uses blocking sockets.  It uses APR to get around the fact that (at
> least with Sun's JVM) blocking NIO sockets totally s*ck.
>
> Just look at the differences between the logic for ChannelNioSocket and
> AjpAprProcessor.

>From what I've seen, apr does some reads with short timeout and some
non-blocking in sendfile.
I'm not interested in anything more complex for my experiments - at
least not right now. I kind of expect blocking NIO sockets to be
comparable with blocking java sockets and apr sockets for normal  I/O
- maybe 1.4 has some problems, but probably 1.5 or 1.6 will improve
things.

I could try reading the http request in non-blocking mode - but what's
the point when the servlet will spend most of the time in service and
writing to a blocking stream ? It's more interesting how to do some of
the service() with a non-blocking socket, for files and few other
things.

Costin

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

Re: Improving memory efficiency

[Costin Manolache]

One of the problems is that jasper is a tricky piece of code, and
usually reducing memory this way can have unexpected impact. Maybe a
more 'moderate' approach would be more acceptable, like checking the
size of the buffers, and only reset it if it is indeed 'huge'. This
would take care of the worse case, yet still allow keeping the buffers
around for normal use.

Don't know what testing you did  (to evaluate the performance impact
of the change), but try with a very large number of concurent
requests. That's where avoiding buffer allocations is most visible,
Remy spent a lot of time making sure no buffer is allocated in the
critical path under load.


Costin



On 12/18/05, Tino Schwarze <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 05:02:39PM +0100, Remy Maucherat wrote:
>
> > >What do you think about this issue?
> >
> > It's a fine solution for your "problem", I suppose. Thanks for the
> > patch, but we are not going to use it.
>
> So could you please give me a hint, why you are not going to use it? My
> "problem" is a real PROBLEM in production environments. There are
> Tomcat's starving with OutOfMemoryErrors. What would be your approach to
> solving this (apart from "give tomcat more memory")?
>
> Bye+Thanks!
>
> Tino.
>
>
> -
> 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: Improving memory efficiency

[Costin Manolache]

On 12/19/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > One of the problems is that jasper is a tricky piece of code, and
> > usually reducing memory this way can have unexpected impact. Maybe a
> > more 'moderate' approach would be more acceptable, like checking the
> > size of the buffers, and only reset it if it is indeed 'huge'. This
> > would take care of the worse case, yet still allow keeping the buffers
> > around for normal use.
>
> I think I will do the following changes:
> - Use a system property to initialize USE_POOL

> - maybe switch to using a thread local rather than the current pool (now
> that the thread count is supposed to correspond to actual concurrency),
> which I don't like

That's a good one - of course the thread count == concurrency only for
APR/nio type connectors afaik, it's still not true for regular
connector.


> - as for "like checking the size of the buffers, and only reset it if it
> is indeed 'huge'. This would take care of the worse case", performance
> of tags using this would really suck since allocating char arrays and
> System.arraycopying many many times will be needed for every tag
> invocation (the API design is to be blamed, I guess); I suppose I can
> add another system property flag to allow using the crap-performance-mode

Assuming that most of the pages use 'huge' buffers - you're right.

However, if you have few pages that need large buffers - and most
don't - this will help.
And you would pay the price of System.arraycopy on the bad pages - i.e. normal
pages will be faster, and jsps that abuse the buffer will be even
slower than before. I think it's a good tradeoff, having bad
performance for pages that abuse the tag buffers is a given anyway :-)

Costin




>
> 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: Tomcat 6 plans (JSP 2.1)

[Costin Manolache]

+1

Costin


On 12/20/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Besides adding support for Servlet 2.5 which does not seem too
> overwhelming, most of the specification work is on support of JSP 2.1. I
> am happy to report that Jacob Hookom is willing to contribute code to
> add the necessary JSP support in Tomcat (he has done such an
> implementation already, and owns the copyright on that code). To host
> the code, a new branch is going to be needed for Jasper (as well as a
> new folder in servletapi).
>
> For testing the implementation, Jacob is going to need access to the JSP
> 2.1 TCK (I suppose he'll need to be a committer to do that, but it
> should be ok by then).
>
> Comments ?
>
> 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: Tomcat 6 plans (JSP 2.1)

[Costin Manolache]

I would really like to have something more modular too - I understand
that NIO and the
other connector stuff is unlikely to see the main branch, but I think
'minimal standalone + modules'  deserves a chance.

Even if we continue to ship by default a bloated tomcat, with all the
features anyone can think of or ever wanted - having those features
organized like modules would make a lot of things easier and better.

Almost all important platforms are designed this way - apache,  jboss,
firefox, etc, it would be time for tomcat as well..

By minimal standalone tomcat I mean: coyote http11 + servlet + jsp +
minimal set of valves to have a TCK-accepted container. Modules == 
jdbc authenticators, load balancing, ssl, jk, even APR, and anything
that could be eventually released or upgraded independently.

Costin


On 12/21/05, Henri Gomez <[EMAIL PROTECTED]> wrote:
> > Sorry, so far nobody has had the sense to propose returning to the good old
> > TC 3.3 Interceptors ;-).  It looks like Evolution is here to stay.
>
> I don't know if Interceptors would be a good solutions but I'd really
> like to have something similar to Apache modules.
>
> -
> 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 6 plans (JSP 2.1)

[Costin Manolache]

Well, it's not about 'vote' or plans, it's more about what people have
time to do.

I have checked in the build files for a 'standalone' tomcat in the
sandbox, I've been using the single jar almost exclusively, seems to
work fine. But I have a feeling I'm the only one interested in this
:-). Removing more features to make it really minimal is quite simple,
but requires testing and a bit of work. I don't think we need any new
code - just small adjustments and different packaging - and a bit of
will.

Costin


On 12/21/05, Henri Gomez <[EMAIL PROTECTED]> wrote:
> - What could prevent TC 6.x to became more modular ?
>
> - Design, commercial dependencies or personal decisions.
>
> Why not send a sort of vote on some possible architectures and plans ?
>
>
> 2005/12/21, Yoav Shapira <[EMAIL PROTECTED]>:
> > +1 to Costin's stuff... I've been itching for a truly minimal Tomcat
> > distro for a while...
> >
> > Yoav
> >
> > On 12/21/05, Costin Manolache <[EMAIL PROTECTED]> wrote:
> > > I would really like to have something more modular too - I understand
> > > that NIO and the
> > > other connector stuff is unlikely to see the main branch, but I think
> > > 'minimal standalone + modules'  deserves a chance.
> > >
> > > Even if we continue to ship by default a bloated tomcat, with all the
> > > features anyone can think of or ever wanted - having those features
> > > organized like modules would make a lot of things easier and better.
> > >
> > > Almost all important platforms are designed this way - apache,  jboss,
> > > firefox, etc, it would be time for tomcat as well..
> > >
> > > By minimal standalone tomcat I mean: coyote http11 + servlet + jsp +
> > > minimal set of valves to have a TCK-accepted container. Modules ==
> > > jdbc authenticators, load balancing, ssl, jk, even APR, and anything
> > > that could be eventually released or upgraded independently.
> > >
> > > Costin
> > >
> > >
> > > On 12/21/05, Henri Gomez <[EMAIL PROTECTED]> wrote:
> > > > > Sorry, so far nobody has had the sense to propose returning to the 
> > > > > good old
> > > > > TC 3.3 Interceptors ;-).  It looks like Evolution is here to stay.
> > > >
> > > > I don't know if Interceptors would be a good solutions but I'd really
> > > > like to have something similar to Apache modules.
> > > >
> > > > -
> > > > 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]
> > >
> > >
> >
> >
> > --
> > Yoav Shapira
> > System Design and Management Fellow
> > MIT Sloan School of Management
> > Cambridge, MA, USA
> > [EMAIL PROTECTED] / www.yoavshapira.com
> >
> > -
> > 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: Tomcat 6 plans (JSP 2.1)

[Costin Manolache]

On 12/22/05, Henri Gomez <[EMAIL PROTECTED]> wrote:
> 2005/12/22, Remy Maucherat <[EMAIL PROTECTED]>:
> > Henri Gomez wrote:
> > > Well a Tomcat will a small memory footprint is also very interesting for 
> > > me :)
> >
> > How is Tomcat memory usage large ? Personally, I would think it's
> > extremely reasonable given the feature set, at least when using APR. It
> > would seem the base Java runtime would completely offset any gain there.
>
> Well memory is not the only point, faster start and less class to be
> loaded is also very important for me. In my company we're still using
> Tomcat 3.3.2 on our production servers (iSeries) since they are quite
> fast to start and that's very important when you have at the same time
> not less than 20 or 25 instances of Tomcat starting in its own JVM
> (one tomcat for a customer since the applications hosted have
> differents life cycle and constraint).
>

I didn't do any real benchmark, but the single-jar 5.5 should be as
fast on startup as 3.3.

Less class loaded - and less classes/features you need to worry when
setting up and maintainig is what I meant by footprint - Jetty is
around 0.5M I think.

The fact that we have features for everyone is nice - but a developer
doesn't need clustering
or APR, and a production server doesn't need the old connector, the
simple realm or the even the jasper compiler. It's more about beeing
simpler for everyone - by providing the functionality they use.

And no - it doesn't require any major refactoring - just small tweakings.

I understand this doesn't help for JBoss - but tomcat != jboss.


As for JMX - I think we do have a lot of things exposed, and adding
more is quite easy. I think part of the problem is that we may have
too much :-), and most generic JMX tools are not that good when you
have too much data to browse. IMO organizaing a bit the information
and maybe providing simpler interfaces would help.

Having a minimal set of features in the base package doesn't mean you
can't have a lot of features, and it doesn't mean it's much harder to
add features. In a production environment it's the same - either you
remove all the components you don't need or don't understand ( and
might break something ), or just add the components that you need.

Think about Firefox versus Mozilla. We are in exactly the same
situation, just on server side :-)

It's funny that JBoss does have most of this capability already - so I
understand Remy not wanting to reinvent the wheel :-), but I don't
think he can deny that this is a good thing to have.


Costin

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

Re: Tomcat 6 plans (JSP 2.1)

[Costin Manolache]

On 12/22/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Henri Gomez wrote:
> > Well memory is not the only point, faster start and less class to be
> > loaded is also very important for me. In my company we're still using
> > Tomcat 3.3.2 on our production servers (iSeries) since they are quite
> > fast to start and that's very important when you have at the same time
> > not less than 20 or 25 instances of Tomcat starting in its own JVM
> > (one tomcat for a customer since the applications hosted have
> > differents life cycle and constraint).
>
> Did you actually compare memory usage of an JVM instance with 3.3.2 with
> 5.5.14/APR (using APR and AJP will make the thread count much lower
> which should save you a decent amount of memory - see the appropriate
> parameters for the connector) ?

Or you can try the NIO connector in sandbox if you want to play :-), same
benefits as AJP in terms of lower thread count and concurrency...

( if we do the modular tomcat - I can remove the nio connector from
sandbox, and move
it to sourceforge :-)


>
> As for faster start, sorry, there is not much that can be done: the spec
> requires a lot of stuff now, and modern webapps actually tend to do much
> more than Tomcat itself.


There is a lot that can be done. I agree that many webapps do more
than tomcat ( in the servlet init for auto-started servlets ), but
that doesn't mean we can't reduce our part.

One thing that 3.3 did ( or tried to do - I don't remember if it got
finished ) was to avoid parsing web.xml/tld files unless modified.
This and skiping all the modules you don't need are a good start in
reducing startup time.

For a production env it doesn't matter, but for development - or
normal use - it is a big deal.

Costin

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

Re: Tomcat 6 plans (JSP 2.1)

[Costin Manolache]

On 12/22/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > I understand this doesn't help for JBoss - but tomcat != jboss.
>
> I don't see the need for refactorings, and that's my *personal* opinion.


That's my opinion as well - if by refactoring you mean major code changes.

Are you saying that jboss modularity is a bad thing ? Or we shouldn't
do the same thing because it's already done in jboss ? Or it's not
worth having it, and it's better to stick with the monolithic approach
?


>
> > It's funny that JBoss does have most of this capability already - so I
> > understand Remy not wanting to reinvent the wheel :-), but I don't
> > think he can deny that this is a good thing to have.
>
> Very funny. Who implemented hot deployment in Tomcat ?
>

Thanks for that, but why stop there ? :-)


Costin

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

Re: Tomcat 6 plans (JSP 2.1)

[Costin Manolache]

On 12/22/05, Henri Gomez <[EMAIL PROTECTED]> wrote:
>
> > Less class loaded - and less classes/features you need to worry when
> > setting up and maintainig is what I meant by footprint - Jetty is
> > around 0.5M I think.
>
>
> what's the expected class/size for this SmallCat single jar ?

Around 1.4M without jasper compiler ( but with support for precompiled jsps ).

> +1 even if 2 of the major tomcat mainteners are JBOSS employees and we
> should all recognize it helped to people working full time on TC
> 5.5.x. Thanks JBOSS

+1 :-)


Costin

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

Re: svn commit: r365858 - /tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java

[Costin Manolache]

On 1/4/06, Tino Schwarze <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 04, 2006 at 07:48:43AM -, [EMAIL PROTECTED] wrote:
>
> > Modified: tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java
> > URL: 
> > http://svn.apache.org/viewcvs/tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java?rev=365858&r1=365857&r2=365858&view=diff
> > > > +try {
> >   for( int srcPos=srcOff + 1; srcPos< srcEnd; ) {
> >  if( bb.get(myPos++) != src.charAt( srcPos++ ))
> >   break;
> >  if( srcPos==srcEnd ) return i-start; // found it
> >   }
> > +} catch( Throwable t ) {
> > +t.printStackTrace();
> > +}
>
> Argh! Never ever do that!
> 1) don't catch Throwable - you'll happily consume OutOfMemoryError and
>similar bad things here which should certainly be passed along.
> 2) don't use printStackTrace() - use a suitable logger instead

Will go away - using the buffers is very messy right now, I'm trying
to find a better way.

Costin

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

Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method

[Costin Manolache]

I'm curious - why would you need the options method ?

Obviously, as you found, tomcat does not support it ( and many other
servers ), and I never heard of any use of it, even if it is in the
spec.

Well, in theory servlets could respond to 'options' method if they
choose to - and so could the default servlet.

Costin

On 1/6/06, Mauro Bertapelle <[EMAIL PROTECTED]> wrote:
> Is it correct that coyote reply with the home page contents on an HTTP
> OPTIONS method request ?
>
> Client request:
>
>   OPTIONS / HTTP/1.1\r\n
>   Request Method: OPTIONS
>   Request URI: /
>   Request Version: HTTP/1.1
>   Translate: f\r\n
>   User-Agent: Microsoft Data Access Internet Publishing Provider
> Protocol Discovery\r\n
>   Host: lan2\r\n
>   Content-Length: 0\r\n
>   Connection: Keep-Alive\r\n
>   \r\n
>
> Server response:
>
> Hypertext Transfer Protocol
>   HTTP/1.1 200 OK\r\n
>   Request Version: HTTP/1.1
>   Response Code: 200
>   Content-Type: text/html;charset=ISO-8859-1\r
> \n
>   Transfer-Encoding: chunked\r\n
>   Date: Fri, 06 Jan 2006 10:32:07 GMT\r\n
>   Server: Apache-Coyote/1.1\r\n
>   \r\n
>   HTTP chunked response
> 
>   3e 3c 2f 74 72 3e 0d 0a 20 20 20 20 20 20 20 20   >..
> 0010  20 20 20 20 3c 2f 74 61 62 6c 65 3e 0d 0a 20 20   ..
> 0020  20 20 20 20 20 20 3c 2f 74 64 3e 0d 0a 20 20 20 ..
> 0030  20 20 20 20 20 3c 74 64 20 61 6c 69 67 6e 3d 22http://jakarta.a
> 0060  70 61 63 68 65 2e 6f 72 67 2f 22 3e 3c 69 6d 67   pache.org/"
> > 0070  20 73 72 63 3d 22 6a 61 6b 61 72 74 61 2d 62 61src="jakarta-ba
> 0080  6e 6e 65 72 2e 67 69 66 22 20 68 65 69 67 68 74   nner.gif" height
> 0090  3d 22 34 38 22 20 77 69 64 74 68 3d 22 35 30 35   ="48" width="505
> 00a0  22 20 62 6f 72 64 65 72 3d 22 30 22 20 61 6c 74   " border="0" alt
> 00b0  3d 22 54 68 65 20 4a 61 6b 61 72 74 61 20 50 72   ="The Jakarta Pr
> 00c0  6f 6a 65 63 74 22 3e 3c 2f 61 3e 3c 2f 74 64 3e   oject">
> 00d0  0d 0a 20 20 20 20 3c 2f 74 72 3e 0d 0a 3c 2f 74   .... 00e0  61 62 6c 65 3e 0d 0a 0d 0a 3c 62 72 3e 0d 0a 0d   able>...
> 
>
> mauro
> --
>
> -
> 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: EL and JSP 2.1

[Costin Manolache]

On 12/27/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> My own views in line.
>
> Mark
>
> Mark Thomas wrote:
> > Jacob Hookom wrote:
> >
> >>I'd like to get the ball rolling on a branch for JSP 2.1.
> >
> > I can get the SVN stuff set up over the next few days. There has been
> > some debate about how we arrange things so we need to get agreement on
> > the way forward.
> >
> > The key questions are:
> >  - does 6.0.x become the main development branch?
> Yes. We did this for 5.5.x and it worked.

Yes, you'll need to create a branch for 5.5.


>
> >  - do we merge jasper and container?
> No. Good to keep them independent.

The independence is not given by the fact they are in different trees - the
connector and container are not independent, yet in different trees.

And the 'separation' of jasper and container can be achieved as well
by continuing to use
differet packages :-).


> >  - do we merge build and container
> Maybe. If someone wants to take the time to do this and update the
> build scripts great. Personally, not an itch I feel the need to scratch.

Probably doesn't make sense if this is the only change.

It seems people are not ok with a single source tree.


>
> >  - do we maintain servletapi for 6.0?
> No for the api stuff proper. We don't host it, can't change it and our
> own implementation would be more trouble than it is worth.
>
> Maybe for the examples. It is useful to be able to fix problems with
> them. The examples could always be merged in with the container module.


IMO - 6.0 would be the best chance to reorg the tree structure. Given
that JDK1.5 will be required, it means we could remove all <1.4 code
and hacks, and a lot of the build hacks that are used to deal with
multiple VMs and options.

I think we should just create a tomcat6/ repository, and then take a
snapshot of all subtrees
in the current tomcat and place the all in the same tree, under
tomcat6/java. Then start with a fresh build.xml - excluding or
removing the 1.1 - 1.4 support classes.

Well - I would go even further, on creating a smaller number of jars
for the distribution, but I guess that would be even less popular than
the singe tree.

I do understand I'm in a very small minority with this proposal, just
want to have it on the record  :-)

Costin

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

Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method

[Costin Manolache]

Interesting.

Well, Remy is the expert in webdav, but I guess you'll need to talk
with him on the users list  :-)
I suppose the default servlet could handle 'options', since it's part
of the standard, but for regular servlets there is nothing to be done,
it's up to them to implement whatever methods they want.

Costin

On 1/6/06, Mauro Bertapelle <[EMAIL PROTECTED]> wrote:
> Costin,
>
> I'm tweaking with internet explorer and his web folder feature (access to
> webdav resource).
>
> When accessing a webdav resource, ie fire a lot of "OPTIONS" requests,
> not only to the specified url but as you see from my example even to the
> "/" uri
> which is obviously catched by the default servlet and not by the webdav
> servlet.
>
> Mauro
> --
>
> Costin Manolache wrote:
>
> >I'm curious - why would you need the options method ?
> >
> >Obviously, as you found, tomcat does not support it ( and many other
> >servers ), and I never heard of any use of it, even if it is in the
> >spec.
> >
> >Well, in theory servlets could respond to 'options' method if they
> >choose to - and so could the default servlet.
> >
> >Costin
> >
> >On 1/6/06, Mauro Bertapelle <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Is it correct that coyote reply with the home page contents on an HTTP
> >>OPTIONS method request ?
> >>
> >>Client request:
> >>
> >>  OPTIONS / HTTP/1.1\r\n
> >>  Request Method: OPTIONS
> >>  Request URI: /
> >>  Request Version: HTTP/1.1
> >>  Translate: f\r\n
> >>  User-Agent: Microsoft Data Access Internet Publishing Provider
> >>Protocol Discovery\r\n
> >>  Host: lan2\r\n
> >>  Content-Length: 0\r\n
> >>  Connection: Keep-Alive\r\n
> >>  \r\n
> >>
> >>Server response:
> >>
> >>Hypertext Transfer Protocol
> >>  HTTP/1.1 200 OK\r\n
> >>  Request Version: HTTP/1.1
> >>  Response Code: 200
> >>  Content-Type: text/html;charset=ISO-8859-1\r
> >>\n
> >>  Transfer-Encoding: chunked\r\n
> >>  Date: Fri, 06 Jan 2006 10:32:07 GMT\r\n
> >>  Server: Apache-Coyote/1.1\r\n
> >>  \r\n
> >>  HTTP chunked response
> >>
> >>  3e 3c 2f 74 72 3e 0d 0a 20 20 20 20 20 20 20 20   >..
> >>0010  20 20 20 20 3c 2f 74 61 62 6c 65 3e 0d 0a 20 20   ..
> >>0020  20 20 20 20 20 20 3c 2f 74 64 3e 0d 0a 20 20 20 ..
> >>0030  20 20 20 20 20 3c 74 64 20 61 6c 69 67 6e 3d 22http://jakarta.a
> >>0060  70 61 63 68 65 2e 6f 72 67 2f 22 3e 3c 69 6d 67   pache.org/"
> >><http://pache.org/%22>> >>0070  20 73 72 63 3d 22 6a 61 6b 61 72 74 61 2d 62 61src="jakarta-ba
> >>0080  6e 6e 65 72 2e 67 69 66 22 20 68 65 69 67 68 74   nner.gif" height
> >>0090  3d 22 34 38 22 20 77 69 64 74 68 3d 22 35 30 35   ="48" width="505
> >>00a0  22 20 62 6f 72 64 65 72 3d 22 30 22 20 61 6c 74   " border="0" alt
> >>00b0  3d 22 54 68 65 20 4a 61 6b 61 72 74 61 20 50 72   ="The Jakarta Pr
> >>00c0  6f 6a 65 63 74 22 3e 3c 2f 61 3e 3c 2f 74 64 3e   oject">
> >>00d0  0d 0a 20 20 20 20 3c 2f 74 72 3e 0d 0a 3c 2f 74   .... >>00e0  61 62 6c 65 3e 0d 0a 0d 0a 3c 62 72 3e 0d 0a 0d   able>...
> >>
> >>
> >>mauro
> >>--
> >>
> >>-
> >>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]
>
>

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

Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method

[Costin Manolache]

I guess the problem was that the default servlet ( part of tomcat )
doesn't handle options for static files like "/", instead returns the
page as if it would be a GET. I tried on www.apache.org - and apache
seems to return the right thing ( no body, etc ).


Costin

On 1/6/06, Keith Wannamaker <[EMAIL PROTECTED]> wrote:
> Tomcat "handles" it just fine -- if you implement it in your servlet :-)
>   Options conveys not only whether a resource is dav-enabled and the
> class of dav support, but it has a well-defined xml response body for a
> number of ACL and DeltaV properties, all of which needs to be handled by
> the application, not tomcat.  You are going to have to override it
> anyway to specify the DAV: header, at a minimum.  Tomcat can't know
> whether your application supports dav locking or not, for instance.
>
> Keith
>
> Costin Manolache wrote:
> > Interesting.
> >
> > Well, Remy is the expert in webdav, but I guess you'll need to talk
> > with him on the users list  :-)
> > I suppose the default servlet could handle 'options', since it's part
> > of the standard, but for regular servlets there is nothing to be done,
> > it's up to them to implement whatever methods they want.
> >
> > Costin
> >
> > On 1/6/06, Mauro Bertapelle <[EMAIL PROTECTED]> wrote:
> >
> >>Costin,
> >>
> >>I'm tweaking with internet explorer and his web folder feature (access to
> >>webdav resource).
> >>
> >>When accessing a webdav resource, ie fire a lot of "OPTIONS" requests,
> >>not only to the specified url but as you see from my example even to the
> >>"/" uri
> >>which is obviously catched by the default servlet and not by the webdav
> >>servlet.
> >>
> >>Mauro
> >>--
> >>
> >>Costin Manolache wrote:
> >>
> >>
> >>>I'm curious - why would you need the options method ?
> >>>
> >>>Obviously, as you found, tomcat does not support it ( and many other
> >>>servers ), and I never heard of any use of it, even if it is in the
> >>>spec.
> >>>
> >>>Well, in theory servlets could respond to 'options' method if they
> >>>choose to - and so could the default servlet.
> >>>
> >>>Costin
> >>>
> >>>On 1/6/06, Mauro Bertapelle <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>
> >>>>Is it correct that coyote reply with the home page contents on an HTTP
> >>>>OPTIONS method request ?
> >>>>
> >>>>Client request:
> >>>>
> >>>> OPTIONS / HTTP/1.1\r\n
> >>>> Request Method: OPTIONS
> >>>> Request URI: /
> >>>> Request Version: HTTP/1.1
> >>>> Translate: f\r\n
> >>>> User-Agent: Microsoft Data Access Internet Publishing Provider
> >>>>Protocol Discovery\r\n
> >>>> Host: lan2\r\n
> >>>> Content-Length: 0\r\n
> >>>> Connection: Keep-Alive\r\n
> >>>> \r\n
> >>>>
> >>>>Server response:
> >>>>
> >>>>Hypertext Transfer Protocol
> >>>> HTTP/1.1 200 OK\r\n
> >>>> Request Version: HTTP/1.1
> >>>> Response Code: 200
> >>>> Content-Type: text/html;charset=ISO-8859-1\r
> >>>>\n
> >>>> Transfer-Encoding: chunked\r\n
> >>>> Date: Fri, 06 Jan 2006 10:32:07 GMT\r\n
> >>>> Server: Apache-Coyote/1.1\r\n
> >>>> \r\n
> >>>> HTTP chunked response
> >>>>
> >>>>  3e 3c 2f 74 72 3e 0d 0a 20 20 20 20 20 20 20 20   >..
> >>>>0010  20 20 20 20 3c 2f 74 61 62 6c 65 3e 0d 0a 20 20   ..
> >>>>0020  20 20 20 20 20 20 3c 2f 74 64 3e 0d 0a 20 20 20 ..
> >>>>0030  20 20 20 20 20 3c 74 64 20 61 6c 69 67 6e 3d 22http://jakarta.a
> >>>>0060  70 61 63 68 65 2e 6f 72 67 2f 22 3e 3c 69 6d 67   pache.org/"
> >>>><http://pache.org/%22>> >>>>0070  20 73 72 63 3d 22 6a 61 6b 61 72 74 61 2d 62 61src="jakarta-ba
> >>>>0080  6e 6e 65 72 2e 67 69 66 22 20 68 65 69 67 68 74   nner.gif" height
> >>>>0090  3d 22 34 38 22 20 77 69 64 74 68 3d 22 35 30 35   ="48" width="505
> >>>>00a0  22 20 62 6f 72 64 65 72 3d 22 30 22 20 61 6c 74   " border="0" 

Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method

[Costin Manolache]

DefaultServlet doesn't implement OPTIONS either, and I don't remember
ever implementing or seeing an implementation of the method in
anything except webdav servlet.

Since it is part of the standard - and it seems it is even used - we
should support it, but this has been broken forever. I'm curious if it
could be implemented at container level, maybe detecting if a servlet
doesn't implement it and returning a default implemenation ? Tomcat
can detect what methods are implemented - unless the servlet overrides
service().

Costin

On 1/7/06, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Mark Thomas wrote:
> > Mauro Bertapelle wrote:
> >>this has nothing to do with
> >>webdav and the naive
> >>way in which ie implements it, but probably Tomcat should handle
> >>"options" better when
> >>it's acting as a static web server.
> >>
> >>Mauro
> >
> > I have confirmed this behaviour with the latest source from SVN. It is
> > a bug. I'll look into it.
> >
>
> It is as a result Jasper. A request for:
> OPTIONS http://localhost:8080/ HTTP/1.1
>
> or
> OPTIONS http://localhost:8080/index.jsp HTTP/1.1
>
> eventually calls the _jspService method created by Jasper in
> org.apache.jasper.compiler.Generate.generatePreamble() which assumes a
> request method of GET.
>
> I have commitments which mean I will not be able to look at this for a
> day or two at the earliest. If no one else fixes it between now and
> early next week, I'll look at it then.
>
> 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 5.8.0 - weird response on HTTP OPTIONS method

[Costin Manolache]

On 1/7/06, Bill Barker <[EMAIL PROTECTED]> wrote:
>
> Which is exactly what the JSP spec says it should do, and why Remy was
> absolutely correct to consider that this is a users@ question.  It's up to
> the page author to decide how to deal with the request method.

The page author is us, index.jsp is shipped with tomcat, and so is the
default servlet.
My understanding is that the http1.1 spec requires this method to be
implemented in a particular way - and tomcat code doesn't. Not sure
what users@ could do about it, except from replacing the default
servlet.

For JSPs - IMO the JSP spec or our implementation is badly broken in
this aspect, the fact is that no jsp in existence deals works
correctly ( according to HTTP spec ).
 I don't thing it matters that this is a problem with the lazy users
or tomcat developers who forget to implement it. The spec could
require a default implementation, or require users to implement it if
running in a http11 server.


Costin

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

Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method

[Costin Manolache]

On 1/7/06, Bill Barker <[EMAIL PROTECTED]> wrote:

> DefaultServlet inherits doOptions from HttpServlet.  This works correctly
> (and, has back at least to the Sevlet-2.2 days), and is why Servlets rarely
> have to implement it.  If you had index.html instead of index.jsp, you would
> see exactly what you expect to see.

You're right, I forgot about the base class. Yes, it does
getDeclaredMethods - so works for all servlets that use doGet, doPost,
etc. I was looking for something specific in DefaultServlet.


> >For JSPs - IMO the JSP spec or our implementation is badly broken in
> >this aspect, the fact is that no jsp in existence deals works
> >correctly ( according to HTTP spec ).
> > I don't thing it matters that this is a problem with the lazy users
> >or tomcat developers who forget to implement it. The spec could
> >require a default implementation, or require users to implement it if
> >running in a http11 server.
> >
>
> It's primarily the JSP spec that is broken.  The few times that I've cared,
> I've used the extends="..." to get the correct HTTP behavior (but
> technically broken JSP spec behavior).  This is about the only solution that
> works (and why it's a users@ issue), since it is impossible for the JSP
> container to determine what methods a JSP Page implements.
>
> I suppose it would be possible to change HttpJspBase.service to call
> super.doOptions if it sees an OPTIONS method instead of what it's supposed
> to do.  The output will be meaningless (if syntactically correct), but so
> would anything else be :).  I'm -0 on this, since IMHO it takes a pretty
> streached reading of the spec to allow it.

What about returning just GET, HEAD as supported method for Jsps that
don't override this ?

Costin

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

Re: svn commit: r367115 - /tomcat/connectors/trunk/coyote/src/java/org/apache/coyote/Response.java

[Costin Manolache]

If you're looking to reduce complexity - one idea would be to check if
the redundant fields are actually needed, because that's the actual
source of the problem.

I can only think of performance benefits - storing the contentLength
as an int may be a good way to avoid conversion to and from String -
but the headers are stored as MessageBytes, and that supports storing
the int value. If the redundant values are used to avoid looking up
the header - storing the MessageBytes value could solve this.

If you decide to fix it at the higher layer - maybe you can also
deprecate the method containsHeader in Response or put a big javadoc
saying that it's not very accurate.


Costin

On 1/9/06, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Remy Maucherat wrote:
> > [EMAIL PROTECTED] wrote:
> >> Fix bug 29214. containsHeader() not working for Content-Length and
> >> Content-Type
> >
> > Rather than adding complexity in code which is critical, I would have
> > hacked instead the org.apache.catalina.connector.Response.containsHeader
> > method, which is not actually used at all (except by application code,
> > IMO for weird reasons).
>
> I'll look into an alternative patch that has less impact on the
> critical code.
>
> 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: svn commit: r367826 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/connector/Response.java webapps/docs/changelog.xml

[Costin Manolache]

I guess the better solutions are to either deal with this in the
servlet facade ( i.e. the HttpServletResponse impl ) - or to just
remove the cached fields from coyote Response.

The second is harder - but the right one IMO, it's bad to have methods
in Response that don't do what people would expect them to do and
workaround in facade to deal with complexity. And we already have a
cache ( for converted int values ) in MessageBytes.

I'm sure Remy would be happier with the first solution, and it's
simpler to implement. But I agree that we shouldn't add this to
Response.

Costin


On 1/10/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Author: markt
> > Date: Tue Jan 10 15:06:22 2006
> > New Revision: 367826
> >
> > URL: http://svn.apache.org/viewcvs?rev=367826&view=rev
> > Log:
> > Alternative patch for bug 29214 based on Remy's comments
>
> I didn't have time to look into it much, but I would have thought using
> coyoteResponse.getContentLength() != -1 would be more good enough.
> Otherwise, the code isn't really that much simpler.
>
> 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: Initial EL/JSP 2.1 Contribution

[Costin Manolache]

On 1/10/06, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Remy Maucherat wrote:
> > Jacob Hookom wrote:
> >> I've been rolling this code base into JSP 2.1 within a local sandbox,
> >> but I still have questions about the particulars of the overal project
> >> packaging for Tomcat 6.
> >
> > Very good :)
> > Personally, I still would like to "start slow" and for now create a tree
> > or something only inside the jasper module.
>
> Based on this, I propose the following changes to svn.
>
> copy /tomcat/jasper/tc5.5.x/ to /tomcat/jasper/tc6.0.x/
> create /tomcat/jasper/tags/tc6.0.x/
>
> Eventually, /tomcat/jasper/tc5.5.x/ will move to
> /tomcat/jasper/branches/tc5.5.x/ but I think this move should take
> place when all of the tc5.5.x modules are moved to
> modulename/branches/ and the full tc6.0.x modules are created.
>
> Commits to /tomcat/jasper/tc5.5.x/ will have to be merged with
> /tomcat/jasper/tags/tc6.0.x/
>
> If I don't get any -1's in the next 72 hours, I'll make the changes
> set out above.

What about:

1. create tomcat/tomcat6.0

2. mkdir tomcat/tomcat6.0/jasper

Or even better:

2. mkdir tomcat/tomcat6.0/java/org/apache/tomcat/jasper

You can do all the work on jasper in the tomcat6.0 svn module, and
maybe in time other components will move here as well.

The build.xml changes for this case will be the same with what you
propose, you still need to get jasper from a different place when
building tomcat6.0, etc.

Costin

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

Re: svn commit: r367826 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/connector/Response.java webapps/docs/changelog.xml

[Costin Manolache]

On 1/10/06, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > I guess the better solutions are to either deal with this in the
> > servlet facade ( i.e. the HttpServletResponse impl ) - or to just
> > remove the cached fields from coyote Response.
> >
> > The second is harder - but the right one IMO, it's bad to have methods
> > in Response that don't do what people would expect them to do and
> > workaround in facade to deal with complexity. And we already have a
> > cache ( for converted int values ) in MessageBytes.
> >
> > I'm sure Remy would be happier with the first solution, and it's
> > simpler to implement. But I agree that we shouldn't add this to
> > Response.
> >
> > Costin
>
> Given we are working around the cached fields in coyote response, I
> wanted to keep the work around as close to coyote response as possible.
>
> I agree removing the cached fields is the right way to go if we can. I
> did take a quick look at it but was concerned about possible
> performance impacts and wanted to get a better fix out sooner that I
> would have been able to otherwise.

The quickest fix is on the facade ( servlet implementation ), as Remy suggested.



> A related concern was a lack of a test case to check any performance
> impact. I'll put together a simple JMeter test for this. Given that we
> are concerned about request overhead, does the following test case
> sound reasonable?
> - simple servlet (approx 1K output)

Since you want to test the header - probably a small output would be better.


> - explicitly set content length and type in servlet
> - JMeter test case that uses 50 concurrent threads to make 1 requests

I would test this kind of change with a larger thread count ( 100 + ).
I usually use "ab", not sure how much overhead is in jmeter.

> - set min threads on the connector to >50
> - measure average time per request

All 3 times matter. Make sure you 'warm up' the server.


BTW - I was suggesting to cache instead the MessageBytes corresponding
to the value in the MimeHeaders. But it may be interesting to find if
just removing the cache completely and having simpler code would have
any impact - there are a lot of surprises when you deal with
performance...

Another way to test that would minimize the tomcat overhead is to use
the connector 'standalone' - i.e. write a simple main() that
instantiates the connector, with a simple Adapter that just generates
the content in the buffer. There is some code in sandbox that does
most of this ( in standalone ). This way you test the raw performance
of coyote, without mapper / servlet API / valves / etc.


Costin

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

Re: svn commit: r376730 - /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java

[Costin Manolache]

I don't remember refusing making CharChunk implement CharSequence, at least
not recently - I think it would
be a great idea ! Older versions of tomcat that need pre-1.5 support will
need to use a branch.

Costin

On 2/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Author: remm
> Date: Fri Feb 10 07:20:44 2006
> New Revision: 376730
>
> URL: http://svn.apache.org/viewcvs?rev=376730&view=rev
> Log:
> - Have CharCHunk implement CharSequence, so that a CharChunk can be given
> to a Java 5 regexp matcher
>   without having to do a useless toString on it first. Typically, it would
> be the URL.
> - For some reason Costin refused this a while ago. Maybe there was a
> misunderstanding as to what
>   the proposed change was about, as there's no functional change to
> CharChunk.
>   Is this change still refused ?
>
> Modified:
>
> 
> tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java
>
> Modified:
> tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java
> URL:
> http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java?rev=376730&r1=376729&r2=376730&view=diff
>
> ==
> ---
> tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java
> (original)
> +++
> tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java
> Fri Feb 10 07:20:44 2006
> @@ -30,7 +30,7 @@
>   * @author Costin Manolache
>   * @author Remy Maucherat
>   */
> -public final class CharChunk implements Cloneable, Serializable {
> +public final class CharChunk implements Cloneable, Serializable,
> CharSequence {
>
>  // Input interface, used when the buffer is emptied.
>  public static interface CharInputChannel {
> @@ -695,4 +695,26 @@
> return b;
>  }
>
> +// Char sequence impl
> +
> +public char charAt(int index) {
> +return buff[index + start];
> +}
> +
> +public CharSequence subSequence(int start, int end) {
> +try {
> +CharChunk result = (CharChunk) this.clone();
> +result.setOffset(this.start + start);
> +result.setEnd(this.start + end);
> +return result;
> +} catch (CloneNotSupportedException e) {
> +// Cannot happen
> +return null;
> +}
> +}
> +
> +public int length() {
> +return end - start;
> +}
> +
> }
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: svn commit: r376730 - /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java

[Costin Manolache]

Why not make MessageBytes implement CharSeq as well, for consistency ? And
maybe even ByteChunk - we're doing some
(bad) conversions and toString() inside already.

Costin

On 2/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Author: remm
> Date: Fri Feb 10 07:20:44 2006
> New Revision: 376730
>
> URL: http://svn.apache.org/viewcvs?rev=376730&view=rev
> Log:
> - Have CharCHunk implement CharSequence, so that a CharChunk can be given
> to a Java 5 regexp matcher
>   without having to do a useless toString on it first. Typically, it would
> be the URL.
> - For some reason Costin refused this a while ago. Maybe there was a
> misunderstanding as to what
>   the proposed change was about, as there's no functional change to
> CharChunk.
>   Is this change still refused ?
>
> Modified:
>
> 
> tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java
>
> Modified:
> tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java
> URL:
> http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java?rev=376730&r1=376729&r2=376730&view=diff
>
> ==
> ---
> tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java
> (original)
> +++
> tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java
> Fri Feb 10 07:20:44 2006
> @@ -30,7 +30,7 @@
>   * @author Costin Manolache
>   * @author Remy Maucherat
>   */
> -public final class CharChunk implements Cloneable, Serializable {
> +public final class CharChunk implements Cloneable, Serializable,
> CharSequence {
>
>  // Input interface, used when the buffer is emptied.
>  public static interface CharInputChannel {
> @@ -695,4 +695,26 @@
> return b;
>  }
>
> +// Char sequence impl
> +
> +public char charAt(int index) {
> +return buff[index + start];
> +}
> +
> +public CharSequence subSequence(int start, int end) {
> +try {
> +CharChunk result = (CharChunk) this.clone();
> +result.setOffset(this.start + start);
> +result.setEnd(this.start + end);
> +return result;
> +} catch (CloneNotSupportedException e) {
> +// Cannot happen
> +return null;
> +}
> +}
> +
> +public int length() {
> +return end - start;
> +}
> +
> }
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: svn commit: r376730 - /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java

[Costin Manolache]

On 2/10/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
>
> Costin Manolache wrote:
> > Why not make MessageBytes implement CharSeq as well, for consistency ?
> And
> > maybe even ByteChunk - we're doing some
> > (bad) conversions and toString() inside already.
>
> I think it could be useful in some rare cases. This was mostly to be
> used on the URL, which goes through many (mandatory) transformations,
> and ends up as a CharChunk.


Well, long time ago CharChunk and ByteChunk were supposed to be just an
implementation
detail of MessageBytes - which was supposed to hide the detail of chars and
bytes and avoid the strings.
But they were supposed to work together, and stay kind of consistent.



> I don't remember refusing making CharChunk implement CharSequence, at
> least
> > not recently - I think it would
>
> Yes, you did refuse it.



Sorry :-)

I guess it had something to do with  jdk compat ? Well, too lazy to search -
but
I doubt any reason would be valid today, most VMs have this.


> be a great idea ! Older versions of tomcat that need pre-1.5 support will
> > need to use a branch.
>
> Woops, sorry. I don't think the older branch are going to be able to use
> HEAD forever due to the JDK dependencies (a branch can be created right
> before my patch).


+1


Costin

Re: never say never...

[Costin Manolache]

> No. Bill gave a wrong answer. He ignored in the fact that java.io.tmpdirand
> javax.servlet.context.tempdir are equivalent in implementation in Tomcat,
> and that to be compliant, Tomcat has to make java.io.tmpdir writable.


File.createTempFile spec says that if a dir is not specified, the file must
be created based on
java.io.tempdir - which probably means it must be writable.

Expressing frustration and anger can be healthy for you and maybe for the
community - but
it can't change much in terms of time people have to deal with the bugs and
the user requests.

Costin

Re: New clustering module proposal - WAS: Long rants

[Costin Manolache]

I'm curious, do you need anything in server.xml ?

+1 on making it a module, as independent of tomcat version ( or tomcat
in general ) as possible. Add any hooks you need to avoid strong
dependencies. I think the connectors worked pretty well as a
version-independent tomcat module.

I think it would be even better if the clustering modules would be
released independently of tomcat - i.e. as an add-on module, in a
separate download, with it's own config file ( the 'trusted webapps'
have access to internal classes - so it can be even packaged as a .war
:-).

Costin

On 2/23/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> Sounds like there is a consensus amongst folks. So to summarize
> everyones thoughts, let me know if this sounds like a solution agreeable
> to everyone.
>
> 1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross context
>
> 2. Break out cluster config from catalina.jar to catalina-cluster.jar
> that way we can enable more than one config
>In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet()
> that will load the rule set run time.
>
> 3. Create two new modules (to use for TC6 and as an optional library for
> TC 5.5.x)
>a) Name:groupcom
>   Lib : catalina-groups.jar
>   Purpose: Group messaging component
>b) Name: ha
>   Lib : catalina-cluster.jar
>   Purpose: session replication logic, context attribute replication
> and other new features
>
>
> Lets gather one round of feedback and then vote so that I can move on
> with new dev.
>
> 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: Strange Google search text for Tomcat

[Costin Manolache]

If you do a search for the snippet, one of the first links is in the
directory - 
http://www.google.com/Top/Computers/Programming/Languages/Java/Server-Side/Servlets/Servlet_Engines/

Searching for resin or servletexec will also show the snippents from
the directory - so it's likely the source.

Don't know how it could be fixed - either submit it with the right
description, or maybe ask to become an editor ?

Costin
( with standard disclaimers, I just did a quick search :-)


On 2/25/06, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> Hi,
> When I do a Google search for Tomcat, the first result is
> tomcat.apache.org as expected, but the snippet line that google
> displays is strange, saying something about Tomcat growing into a
> fuller J2EE container.  Does anyone have a clue where the line under
> the top result ("has grown into...") comes from?
>
> Attaching a screenshot to show this, though it's easy to reproduce by
> just googling for tomcat...
>
> --
> Yoav Shapira
> System Design and Management Fellow
> MIT Sloan School of Management
> Cambridge, MA, USA
> [EMAIL PROTECTED] / www.yoavshapira.com
>
>
>
> -
> 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 6 source organisation

[Costin Manolache]

Why would you want to change ant ???

Re. source folders versus modules - we can have both of them, it's not
exclusive.
Single source tree makes it easy to navigate, more IDE-friendly, etc.
The build file can compile as many modules as needed - either by compiling a
subset of the tree, or by compiling the entire tree and generating
several modules.

IMO it is a bad practice to scatter sources around without very good reason.
JDK sources don't seem to be scattered in modules like 'io', 'net',
but in packages,
and modules for platform-specific stuff.

Having a single source tree would also greatly simplify the ant file,
and with eclipse
it can completely skip the compilation task ( i.e. if the ant file
uses the same build/classes
dir as eclipse, it'll detect the already-compiled classes and just
create the jars, while
eclipse can keep the source updated on save ).

Costin

On 2/28/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I think it is time to decide how the source repository is going to be
> organized, with the questions being:
> - how many source folders do we need (Costin wanted one, while others
> like Jacob seem to want "modules") ?
> - do we continue to use Ant ?
> - etc
>
> Any ideas ?
>
> 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: Tomcat 6 source organisation

[Costin Manolache]

On 2/28/06, Keith Wannamaker <[EMAIL PROTECTED]> wrote:
> +1 for consolidating into a single module/src folder.
>
> maven has matured since I last looked.  It seems the biggest advantages
> for us would be dependency management and a common build layout.  I
> don't have a feel for how much work it would take to convert, but it
> doesn't seem like we would loose much if that approach were taken.

Well, 'make' is also mature - it doesn't mean we should switch to it -
or to any tool
that happens to 'mature'.

I'm -0.99 on switching to maven. We already have dependency download  and we
can use a more modern version -  I think there are several options
that don't come with a framework attached. As for 'common build
layout' - that's up to us to decide :-)

Costin




>
> Keith
>
>
> Remy Maucherat wrote:
> > Hi,
> >
> > I think it is time to decide how the source repository is going to be
> > organized, with the questions being:
> > - how many source folders do we need (Costin wanted one, while others
> > like Jacob seem to want "modules") ?
> > - do we continue to use Ant ?
> > - etc
> >
> > Any ideas ?
> >
> > 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: New EL - Split Off from Tomcat 6

[Costin Manolache]

The most important question IMO is 'who is going to maintain it'. For
example - AFAIK
 we are the main users and maintainer of modeler, so IMO it would make
sense to move
it back into tomcat source tree.

If EL has a lot of indepenent developers who are not interested in the
rest of tomcat ( so
it doesn't make sense to add them to tomcat project ) - then yes, +1
on splitting it
to a separate sub-project or jakarta-commons.

Until this happens - I think it should be in the same source tree with
everything else.

The fact that it has it's own specification or deps is not an issue -
each component
of tomcat has it's own evolution and might be released independently
or with the bundle.
We made this argument for connector, jasper, container, etc - I don't think it
helped in any way to have each of them as a separate module, and I
don't think it helped
anyone to have modeler in jakarta-commons.

Again - we can release any package we want, and we should start doing that.

Right now we release few packaging variations of jakarta-tomcat - IMO
we should start
releasing things like 'el', modeler, maybe standalone jasper compiler,
maybe standalone connector, cluster module, etc.


Costin

On 2/27/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> I would like to suggest splitting EL off as a separate library from
> Tomcat.  The EL-API is expected to rev in it's own specification in the
> future.  It is not have any dependencies on the Servlet API or JSP API
> and can be utilized in the same fashion as the commons-el project.
>
> --
> Jacob Hookom  -  Minneapolis
> 
> JSF-EG, JSF-RI, EL, Facelets
>
>
> -
> 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 6 source organisation

[Costin Manolache]

On 2/28/06, Peter Rossbach <[EMAIL PROTECTED]> wrote:
> We can have maven2 dependency management without use maven2 complete.
>
> see. http://maven.apache.org/ant-tasks.html

I have no problem with using maven or similar tasks for downloading
the deps, if they
can provide the same functionality with our build hacks, or at least
use them for the simple
cases.

I'm just -1 on using a framework that forces a particular way to do
things ( nothing personal
with maven, same -1 for any other framework :-). I know people have
religious ideas about
right and wrong, and frameworks is an expression of this - I just hope
I won't see this in tomcat...

It may be good to look at what other options exists for download and
pick one that is easy to use and fits well - maven might be the best
or not, that's one benefit of picking components and tools instead of
'they know better' frameworks.

Costin

>
> I thing maven is good for standard prepare/compile/test, but is heavy
> to use with spezial things like the current tomcat release build. I
> have heard that some "go back to ant" discussion start at the
> jetspeed project.
>
> Peter
>
>
>
> Am 28.02.2006 um 17:50 schrieb Keith Wannamaker:
>
> > +1 for consolidating into a single module/src folder.
> >
> > maven has matured since I last looked.  It seems the biggest
> > advantages for us would be dependency management and a common build
> > layout.  I don't have a feel for how much work it would take to
> > convert, but it doesn't seem like we would loose much if that
> > approach were taken.
> >
> > Keith
> >
> >
> > Remy Maucherat wrote:
> >> Hi,
> >> I think it is time to decide how the source repository is going to
> >> be organized, with the questions being:
> >> - how many source folders do we need (Costin wanted one, while
> >> others like Jacob seem to want "modules") ?
> >> - do we continue to use Ant ?
> >> - etc
> >> Any ideas ?
> >> 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]
>
>

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

Re: Tomcat 6 source organisation

[Costin Manolache]

On 2/28/06, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Remy Maucherat wrote:
> > Hi,
> >
> > I think it is time to decide how the source repository is going to be
> > organized, with the questions being:
> > - how many source folders do we need (Costin wanted one, while others
> > like Jacob seem to want "modules") ?
> > - do we continue to use Ant ?
> > - etc
>
> I am +0 on any changes.
>
> Assuming some changes are made, there needs to be some thought given
> to where in the source tree we put the trunk/branch/tag structure
> before we start moving things around.


Well, single source tree means all source will be in one svn repo.

My understanding is that you can label/tag/branch subdirs - and that a
tag is cheap enough that you can do it for the entire tree.

I think it's better to tag the entire tree - not just the component,
so it's easier to reproduce ( since it has deps, etc ). That seems the
current practice.






> There have also been various comments made that different components
> may be released on different release cycles. If this route is
> followed, there needs to be a reasonably clear idea of what these
> components might be as this will also have an impact on the best way
> to structure the source.
>

I don't think the source structure should be related to release structure.

>From one source tree you can generate as many jars and packages as you
want, in any structure or variation.

Things like 'el' or 'jspc' or maybe cluster could chose to release -
either as a jar, or as a .tar.gz or anything else. Or maybe not - that
should be an independent decision from source tree layout or build
mechanism.

Costin

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

Re: New EL - Split Off from Tomcat 6

[Costin Manolache]

On 2/28/06, Bill Barker <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Costin Manolache [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 28, 2006 9:58 AM
> > To: Tomcat Developers List
> > Subject: Re: New EL - Split Off from Tomcat 6
> >
> > The most important question IMO is 'who is going to maintain it'. For
> > example - AFAIK
> >  we are the main users and maintainer of modeler, so IMO it would make
> > sense to move
> > it back into tomcat source tree.
> >
>
> IMHO, 'maintainer' is an over statement ;-).  However, it's probably true
> that it would have trouble getting it's 3 +1s for a release in commons
> (since even commons-logging can't manage that :).  I'd be +1 to branching it
> back into Tomcat.

That's what I meant :-)


>
> > If EL has a lot of indepenent developers who are not interested in the
> > rest of tomcat ( so
> > it doesn't make sense to add them to tomcat project ) - then yes, +1
> > on splitting it
> > to a separate sub-project or jakarta-commons.
> >
>
> You could try putting a copy of EL in the Jakarta commons-sandbox, and see
> if it gets a community.  If it does, than that's probably better for
> everyone.  If it doesn't, then there would never be a release of it
> independent of Tomcat anyway.

+1 - as long as developement continues in tomcat ( i.e. the branch
that can be released )

>
> > Right now we release few packaging variations of jakarta-tomcat - IMO
> > we should start
> > releasing things like 'el', modeler, maybe standalone jasper compiler,
> > maybe standalone connector, cluster module, etc.
> >
>
> Well, a couple of projects use Jasper independently of Tomcat.  For the
> others, I don't really see the point (and Jasper is a bit under-maintained
> at the moment :).

The point for cluster and other add-on style modules would be to
reduce the size and complexity of tomcat releases, i.e. simpler is
better :-)  IMO jk could also be a separate module - i.e. have the
base tomcat only include the basic http connector, if someone is using
apache he could get the extra module.

Having independent releases of jasper / el / jspc might help if they
can be used in other projects, or if they need a more frequent release
cycle ( bug fixes, etc )

I'm just suggesting options - I'm not saying we should do it now, but
think about it for future, when it makes sense.

Costin

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

Re: Tomcat 6 source organisation

[Costin Manolache]

Of course, this is a case where you need a separate module.

IMHO it is a bad sign when you have to do this - maybe you could use a
different
package name instead of same class names, or refactor a bit so you don't depend
on the class name.
But if for any reason you have to use the same classname, then use a
different module for
that code. JDK does this for platform-specific things in IO, awt, etc.

I think this should be the exception, not the rule.

Costin

On 2/28/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> I would prefer to keep the module source tree separate.
> For example, the "ha" module (cluster2) uses the same classes as the
> "cluster", but they are being enhanced for performance and modularity.
> merging all this into one tree would be a pain in the neck.
>
> Filip
>
>
> Costin Manolache wrote:
> > On 2/28/06, Mark Thomas <[EMAIL PROTECTED]> wrote:
> >
> >> Remy Maucherat wrote:
> >>
> >>> Hi,
> >>>
> >>> I think it is time to decide how the source repository is going to be
> >>> organized, with the questions being:
> >>> - how many source folders do we need (Costin wanted one, while others
> >>> like Jacob seem to want "modules") ?
> >>> - do we continue to use Ant ?
> >>> - etc
> >>>
> >> I am +0 on any changes.
> >>
> >> Assuming some changes are made, there needs to be some thought given
> >> to where in the source tree we put the trunk/branch/tag structure
> >> before we start moving things around.
> >>
> >
> >
> > Well, single source tree means all source will be in one svn repo.
> >
> > My understanding is that you can label/tag/branch subdirs - and that a
> > tag is cheap enough that you can do it for the entire tree.
> >
> > I think it's better to tag the entire tree - not just the component,
> > so it's easier to reproduce ( since it has deps, etc ). That seems the
> > current practice.
> >
> >
> >
> >
> >
> >
> >
> >> There have also been various comments made that different components
> >> may be released on different release cycles. If this route is
> >> followed, there needs to be a reasonably clear idea of what these
> >> components might be as this will also have an impact on the best way
> >> to structure the source.
> >>
> >>
> >
> > I don't think the source structure should be related to release structure.
> >
> > >From one source tree you can generate as many jars and packages as you
> > want, in any structure or variation.
> >
> > Things like 'el' or 'jspc' or maybe cluster could chose to release -
> > either as a jar, or as a .tar.gz or anything else. Or maybe not - that
> > should be an independent decision from source tree layout or build
> > mechanism.
> >
> > Costin
> >
> > -
> > 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: Tomcat 6 source organisation part 2

[Costin Manolache]

We still need separate dirs for native code and java I think.

What about:

tc6(.0.x ?)/trunk/java
tc6/trunk/native
tc6/trunk/webapps
tc6/trunk/res

and the docs webapp at top level, as Yoav suggested.

"share" has a long history - I think JDK is organized this way, with
separate dirs for windows, linux, etc.

I assume native would host apr ? Or both apr and jk ? And maybe the
win installer ?

Costin



On 3/1/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Given the comments, I propose using a single repository with the
> following structure (based on our root "tomcat" repository):
> - tc6.0.x/trunk:
>- src/share: all the relevant sources go there
>- webapps: all our current webapps, including the examples webapps
> (note: portions of the source of certain webapps could be included in
> the main source tree)
>- src/native: the current tcnative code
> - tc6.0.x/branches
> - tc6.0.x/tags
>
> I suppose mod_jk will stay where it is right now. I was also thinking
> about merging commons-modeler in the tomcat.util packages, retaining the
> functionality that we use (AFAIK, there are commons-modeler users out
> there, I saw at least a couple articles over the years).
>
> Any other ideas ?
>
> 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: Tomcat 6 source organisation part 2

[Costin Manolache]

On 3/1/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
> >> tc6(.0.x ?)/trunk/java
> >> tc6/trunk/native
> >> tc6/trunk/webapps
> >> tc6/trunk/res
> Isn't it widely used to have:
>
> src/java
> src/tests
> src/native

Widely used doesn't mean it's good in all cases :-)

For most simple native projects, the source was under src/ - with
Makefile at top level, and also an include/, doc/ folder.
This got cut&pasted probably to src/java, src/test, etc

The extra src/ is useless in our code organization.

Costin

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

Re: What's about unloading policy of jsp-servlets ?

[Costin Manolache]

Thanks for the patch...

This is a well known problem, JSPs are not unloaded unless the entire
webapp is unloaded. And to make things worse - by default all JSP
static content is compiled to strings, that take all the memory. I
think we have ( or had ) an option to generate some non .class file -
which could be more easily managed.

Unfortunately I'm not familiar enough with jasper code - but it looks
good to me. The model of keeping the entire jsp static content in
memory forever is IMO very broken... It may help cheat on some
benchmarks ( i.e. jsp versus html, etc ), but it's wrong for real
world.


Costin

On 3/3/06, Yaroslav Sokolov <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have found, that once loaded jsp-servlets are never unloaded.
>
> To test I just configured tomcat to process *.html files by JspServlet
> and then traversed jdk documentation. The result was not very exciting -
> after browsing ~ 150 pages tomcat cried "java.lang.OutOfMemoryError: Java 
> heap space"
> and started not to work...
>
> So maybe it would be not a bad idea to try to keep in memeory just some fixed
> number of jsp-servlets ?
>
> I have written a sample implementation of such a policy, but it is not very 
> elegant
> as internal structure containing jsp-servlets, it seems, was not designed for 
> such actions...
>
> Regards,
> Yarick.
>
>
> diff -rdu 
> apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java
>  
> apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java
> --- 
> apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java
> 2006-01-03 10:14:04.0 +0100
> +++ 
> apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java
>  2006-02-21 13:26:44.984221000 +0100
> @@ -174,6 +174,17 @@
>   */
>  private boolean xpoweredBy;
>
> +/**
> + * The maxim number of loaded jsps per web-application. If there are more
> + * jsps loaded, they will be unloaded.
> + */
> +private int maxLoadedJsps = 20;
> +
> +/**
> + * How often it is tryed to unload jsps (in seconds)
> + */
> +private int jspUnloadTestInterval = 4;
> +
>  public String getProperty(String name ) {
>  return settings.getProperty( name );
>  }
> @@ -355,6 +366,14 @@
>  return null;
>  }
>
> +public int getMaxLoadedJsps() {
> +return maxLoadedJsps;
> +}
> +
> +public int getJspUnloadTestInterval() {
> +return jspUnloadTestInterval;
> +}
> +
>  /**
>   * Create an EmbeddedServletOptions object using data available from
>   * ServletConfig and ServletContext.
> @@ -636,6 +655,40 @@
>  }
>  }
>
> +String maxLoadedJsps = config.getInitParameter("maxLoadedJsps");
> +if (maxLoadedJsps != null) {
> +try {
> +this.maxLoadedJsps = Integer.parseInt(maxLoadedJsps);
> +if (this.maxLoadedJsps <= 0) {
> +this.maxLoadedJsps = 20;
> +if (log.isWarnEnabled()) {
> +
> log.warn(Localizer.getMessage("jsp.warning.maxLoadedJsps", 
> ""+this.maxLoadedJsps));
> +}
> +}
> +} catch(NumberFormatException ex) {
> +if (log.isWarnEnabled()) {
> +
> log.warn(Localizer.getMessage("jsp.warning.maxLoadedJsps", 
> ""+this.maxLoadedJsps));
> +}
> +}
> +}
> +
> +String jspUnloadTestInterval = 
> config.getInitParameter("jspUnloadTestInterval");
> +if (jspUnloadTestInterval != null) {
> +try {
> +this.jspUnloadTestInterval = 
> Integer.parseInt(jspUnloadTestInterval);
> +if (this.jspUnloadTestInterval <= 0) {
> +this.jspUnloadTestInterval = 4;
> +if (log.isWarnEnabled()) {
> +
> log.warn(Localizer.getMessage("jsp.warning.jspUnloadTestInterval",""+this.jspUnloadTestInterval));
> +}
> +}
> +} catch(NumberFormatException ex) {
> +if (log.isWarnEnabled()) {
> +
> log.warn(Localizer.getMessage("jsp.warning.jspUnloadTestInterval",""+this.jspUnloadTestInterval));
> +}
> +}
> +}
> +
>  // Setup the global Tag Libraries location cache for this
>  // web-application.
>  tldLocationsCache = new TldLocationsCache(context);
> diff -rdu 
> apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/JspC.java
>  
> apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/JspC.java
> --- 
> apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/JspC.java
>   2006-01-03 10:14:04.0 +0100
> +++ 
> apache-tomcat-5.5.15-src-patched/jasp

Re: What's about unloading policy of jsp-servlets ?

[Costin Manolache]

On 3/3/06, Yaroslav Sokolov <[EMAIL PROTECTED]> wrote:
>Actually I found this strings-problem as well. I even created a patch to
> test how it affects on memory filling.
>
>The result was the next. When strings were stored outside of *.class files,
> number of loaded jsp-servlets increased about 3 times. Time of generation of
> *.jsp -> *.java -> *.class files was moderate decreased. But finally, all the
> memory were occupied by jsp-servlets and tomcat threw OOME exception...

The compile time is lower because the .java source is smaller.

Are you sure the soft strings were unloaded ? I would expect the
remaining .java/.class to be quite small for a static .html -
eventually it'll throw OOM, but after a lot of .html files.

But it's a separate issue - I agree that unloading unused jsps is the
most important.

The difficult question is - how does it affect the spec compliance ?
My understanding was that container is allowed to unload servlets and
jsps and webapps whenever he wants. The only problem I see is
servlets/jsps using fields - static or not, I assume people don't
expect them to go away and don't have code in destroy() to save state.
So it might break a lot of code.



Costin


>
> (I put strings to separated file, loaded them only of necessity and kept only
> soft references to these strings.)
>
> Regards,
> Yarick.
>
> Costin Manolache wrote:
> > Thanks for the patch...
> >
> > This is a well known problem, JSPs are not unloaded unless the entire
> > webapp is unloaded. And to make things worse - by default all JSP
> > static content is compiled to strings, that take all the memory. I
> > think we have ( or had ) an option to generate some non .class file -
> > which could be more easily managed.
> >
> > Unfortunately I'm not familiar enough with jasper code - but it looks
> > good to me. The model of keeping the entire jsp static content in
> > memory forever is IMO very broken... It may help cheat on some
> > benchmarks ( i.e. jsp versus html, etc ), but it's wrong for real
> > world.
> >
> >
> > Costin
> >
> > On 3/3/06, Yaroslav Sokolov <[EMAIL PROTECTED]> wrote:
> >
> >>Hi,
> >>
> >>I have found, that once loaded jsp-servlets are never unloaded.
> >>
> >>To test I just configured tomcat to process *.html files by JspServlet
> >>and then traversed jdk documentation. The result was not very exciting -
> >>after browsing ~ 150 pages tomcat cried "java.lang.OutOfMemoryError: Java 
> >>heap space"
> >>and started not to work...
> >>
> >>So maybe it would be not a bad idea to try to keep in memeory just some 
> >>fixed
> >>number of jsp-servlets ?
> >>
> >>I have written a sample implementation of such a policy, but it is not very 
> >>elegant
> >>as internal structure containing jsp-servlets, it seems, was not designed 
> >>for such actions...
> >>
> >>Regards,
> >>Yarick.
>
> [skipped]
>
> -
> 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: What's about unloading policy of jsp-servlets ?

[Costin Manolache]

Good point, fixing jasper servlet is a not going to help in production
env ( and precompiled jsps), so it's probably not worth it.

However - I disagree that JSPs are 'just' servlets - or at least they
should not be plain and stupid translation of text to 'println'
servlets. The current behavior of jsps wrt memory is horrible if you
have lot of content - all the plain text ends up in memory, as part of
the class. It's good for cheating on benchmarks - bad for production.
There are far better ways to use the memory.

IMO separating the strings and loading/unloading them using a cache
would help a lot in such situations ( i.e. large number of jsps ==
huge memory use ). Unloading not frequently/recently used jsps ( and
servlets, and webapps ) might also be very nice, assuming they can
handle being unloaded. But I agree that the current patch is  not the
right solution.

Costin

On 3/4/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > But it's a separate issue - I agree that unloading unused jsps is the
> > most important.
>
> The recommended production usage (= optimal) of JSPs is when they are
> precommpiled, which means that the Jasper servlet is not used, and the
> JSPs are plain servlets. Their lifecycle is then identical to the
> lifecycle of servlets.
>
> I understand the Jasper servlet is junk, and is a testing ground for bad
> ideas, though (ex: the background compilation thread, and now this).
>
> 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: What's about unloading policy of jsp-servlets ?

[Costin Manolache]

On 3/4/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > Good point, fixing jasper servlet is a not going to help in production
> > env ( and precompiled jsps), so it's probably not worth it.
> >
> > However - I disagree that JSPs are 'just' servlets - or at least they
> > should not be plain and stupid translation of text to 'println'
> > servlets. The current behavior of jsps wrt memory is horrible if you
> > have lot of content - all the plain text ends up in memory, as part of
> > the class. It's good for cheating on benchmarks - bad for production.
> > There are far better ways to use the memory.
>
> The alternative is wasting CPU and disk reading stuff from disk all over
> again for nothing, which for most servers are even more useful
> resources. We're talking about using less than 128MB of memory here, so
> it's not too much (who has more than 128MB of static text in his JSPs ?).

The point is not how much memory you have - but to have control over
how it is used. There are plenty of other things that might benefit
from staying in memory - a large cache for the data, etc. Many servers
might have 4+ G RAM, but they tend to run multiple processes and a JVM
might not get all the memory  ( also keep in mind the interaction
between java and swap might not be pleasant - and jsp/class data can't
be paged out, it's very MM unfriendly )


>
> If you're interested in the lowest footprint, JSP is not the right
> technology: you need a templating (or anything not compiled) technology
> and disable its caching features (it will be quite slow, but will use
> minimal amounts of resident memory).

I'm interested in having control over memory use.
Jasper currently requires that all JSP content is kept in RAM - but it
can as well use some fixed cache ( like 64M or 128M ) and work better
for sites with lots of jsps or less ram.

I think JSP is not that bad ( well, there are a lot of bad things in
it ) - it is good to have the logic compiled to a java class. My
problem is with the static data implementation in jasper.



> The only solution is to forbid
> scriptlets (or as an option use a processing when a page does not
> contain scriptlets - and of course, rewrite a significant amount of
> Jasper - way cool :D), in which case compilation is not needed, and we
> can simply execute the nodes (memory is saved by optionally discarding
> the nodes between requests).

Why ? It could as well save all static content in a separate file ( I
remember this was implemented at least in part ), and instead of
generating the strings in the class, use
a cache that manages the string table.

That would be more flexible than this patch - and allow more control
over how much memory is used. Well - with all the APR and sendfile you
could even try to send large chunks of static content from disk - not
sure what's the performance benefits in the static servlet for
example.


>
> > IMO separating the strings and loading/unloading them using a cache
> > would help a lot in such situations ( i.e. large number of jsps ==
> > huge memory use ). Unloading not frequently/recently used jsps ( and
> > servlets, and webapps ) might also be very nice, assuming they can
> > handle being unloaded. But I agree that the current patch is  not the
> > right solution.
>
> Unloading the servlet's instance is possible, not the class definition.

That's because of the class loader per webapps - I think a flat
classloader ( jboss-style ) could handle unloading serlvet definition.

But this is not the problem with jsps - if the static content is
stored as data ( in separate file from .class ), you don't even need
to unload the jsp instance. Unlike a servlet, jsp has the flexibility
to generate any code it wants.


> Unloading webapps is not possible at the moment (even if it was, modern
> webapps take ages and tons of resources to start, so it wouldn't be
> practical IMO).

Case by case. Unloading and loading webapps dynamically used to work :-)


> It still doesn't cost much to give some more perm gen to Sun's VM (still
> a fairly manageable amount IMO, but of course, if you want to do hosting
> or it's an embedded situation, it's a problem).

Many cases would benefit from more control over memory - hosting or
embedded or sites with lots of jsps or lots of data. Forcing all
static content in memory  is not the best use of the memory.

> BTW, I am ok with shipping additional presentation technologies with
> Tomcat, we do not need to give JSP any special treatment anymore.

True, may be better to implement such a thing without all the
complexity of taglibs, etc.

Well - my home web server has 32M RAM on a 200 Mhz arm ... :-). Of
course, I don't plan to  run jsp on it - but coyote works well enough.


Costin

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

Re: What's about unloading policy of jsp-servlets ?

[Costin Manolache]

On 3/4/06, Bill Barker <[EMAIL PROTECTED]> wrote:
>
> "Costin Manolache" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> On 3/4/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> >> The only solution is to forbid
> >> scriptlets (or as an option use a processing when a page does not
> >> contain scriptlets - and of course, rewrite a significant amount of
> >> Jasper - way cool :D), in which case compilation is not needed, and we
> >> can simply execute the nodes (memory is saved by optionally discarding
> >> the nodes between requests).
> >
> >Why ? It could as well save all static content in a separate file ( I
> >remember this was implemented at least in part ), and instead of
> >generating the strings in the class, use
> >a cache that manages the string table.
> >
>
> The Jasper with 3.3 has this as an option.  Since it's main use was to
> shrink the size of the _jspservice method, and Jasper2 has a better
approach
> to this, it was dropped in Jasper2.  Also, in 3.3 Jasper, the static text
> object is a static object in the class, so you don't get any memory
benifits
> from using it.
>
> I'm also with Remy on this that almost all users would rather trade memory
> for speed on this issue.  However, if you want to make it an optional
> behavior for Jasper to store the static text as either a serialized char
> [][] as in TC 3.3, or ResourceBundle, by all means, knock yourself out
;-).

3.3 implementation was far from perfect, but I think it was in a good
direction.

It seems this patch won't pass - but maybe other patches could make at least
small improvements in reducing the required memory use, and let users do the
trade they want.

I agree with you and Remy that memory is cheap and it's good to trade memory
for
speed - if you can fit all your database, plus all the pages and servlets in
memory - you have a perfect situation. But there are a lot of cases where
you can't put everything in memory, and you have to choose what to keep in
memory - maybe a large buffer for database, and some common pages - but keep
infrequently used stuff out, or unload
things that are not in use. It's not always as simple as 'just keep
everything in ram'.

>
> >That would be more flexible than this patch - and allow more control
> >over how much memory is used. Well - with all the APR and sendfile you
> >could even try to send large chunks of static content from disk - not
> >sure what's the performance benefits in the static servlet for
> >example.
> >
>
> In most non-example JSPs, there really aren't many big blocks of static
text
> to sendfile.  They tend to look more like:
>
>   ${foo.name}${foo.price}${foo.available
}
>   
>

Unfortunately jasper ( and JSPs ) are a bit too complex - maybe a simpler
template system
could be used to play with such memory management experiments.

Well - since JSP has no chance of fitting in my memory requirements ( 32M
RAM on my NSLU2 ) -
I'll probably have to try something...



Costin

Re: What's about unloading policy of jsp-servlets ?

[Costin Manolache]

On 3/5/06, Yaroslav Sokolov <[EMAIL PROTECTED]> wrote:
>
>
>
> On 3/5/06, Costin Manolache <[EMAIL PROTECTED]> wrote:
> >
> > It seems this patch won't pass - but maybe other patches could make at
> > least
> > small improvements in reducing the required memory use, and let users do
> > the
> > trade they want.
>
>
> I do not position this patch as solution of the problem. This patch is
> just illustration
> that there is such a problem and it is possible to be solved solved.
>

We actually know that jsp is keeping all content as class data for a very
long time :-).
And also suspect it can be solved - there are few other things tried in the
past.


And finally, it is interesting the oppinion if we want to unload
> jsp-servlets at all or not.
> (My opinion is that we should not waste memory by rare or just-once used
> things, as
> finally it makes the web server out of service.)
>

It seems the answer is no - tomcat require consensus and at least Remy is
-1.

I kind if agree it's not the right solution ( most people don't expect jsps
to get unloaded, and don't code for
that ) - but I tought it might be a nice option to have.

If you really need this - try a different patch, and check with Remy on what
are his concerns and how
to address them.


If yes, I offer to have fixed maximal number of loaded jsp-servlets per
> web-application
> and true handling of this policy. I mean, that is must not be possible to
> have at the
> same time more loaded jsp-servlets than it is set by the policy. Of
> course, such a
> policy should be optional.
>
> Implementation of such a policy, as I already have written, is more
> complex patch than
> the illustration: "as internal structure containing jsp-servlets, it
> seems, was not designed for
> such actions..."
>

Yes, it may  be  better to fix jasper and do the harder solutions.

My understanding of Remy's veto is that JSPs should behave like all servlets
- i.e. shouldn't get unloaded
or loaded unexpectedly. It was also my concern ( users not expecting jsps to
get unloaded, and using statics, etc)
So you will need a more complex patch - I suggested unloading the string
tables ( which in your case are the bulk of  the memory used ), but there
are probably other solutions as well. Good luck, IMO it would be great to
have this
improved !


Costin