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
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 - us
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
--
as <[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 Lis
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
&
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
> > th
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 conn
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: St
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
d.
>
> 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
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 tha
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]>
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 i
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: 32908
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 discove
y 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,
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
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 Mauche
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 differen
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
>
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 option
nd 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
> >
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 o
de 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
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 <[EMAI
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 man
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 mig
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 suppos
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 curre
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:
> > C
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 o
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
> >>
&
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
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 co
+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,
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/
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 :-)
>
> > refactore
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
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 ( co
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 bo
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 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.
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
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
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
-
bels 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 met
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
e 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/0
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 a
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) thing
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/0
r
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)
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 s
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 featu
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.
> >
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 -
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
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
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 wors
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
+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 n
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
; +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 und
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
> > extr
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
>
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 wel
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
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
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 defa
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 h
t;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
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.
>
>
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
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.js
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 w
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
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 expec
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 :)
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.
&
t/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 Cha
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/apa
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.
> 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
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 woul
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.
Do
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 compil
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
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
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 wit
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
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 Of
> 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 wr
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,
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
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 -
w
n 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 pat
t 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
&
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
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
> >> scriptl
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 reduc
1 - 100 of 426 matches
Mail list logo
