tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Claassen <mclaas...@ocie.net>
Subject RE: Binary build procedures
Date Thu, 25 May 2006 15:55:51 GMT
I have a question about two optional packages: mx4j and junit.

Are they really optional?  I realize that some build processes may use junit
to test the build, but does it need to in the distribution?

Also, what is mx4j used for.  If I don't it, can I not use JMX?

Thanks,
Mark
 
-----Original Message-----
From: Mark Claassen [mailto:mclaassen@ocie.net] 
Sent: Thursday, May 25, 2006 10:04 AM
To: 'Tomcat Developers List'
Subject: RE: Binary build procedures

> Just out of curiosity, when you say above "if something goes wrong" do 
> you
mean with your stuff or with the Tomcat build?

Here is an anecdote to describe what I mean.

While using 5.0, we had problems with the CGIServlet.  It would not handle
uploads well at all.  The problem was that the read was implemented with a
single 'read(buffer)' where buffer was the size of the content.

This works with small content lengths, but with larger ones it has problems.
The correct method is, of course, something like:
while (soFar < total)
	read(buffer,soFar,total-soFar)

Anyway, I located the problem and fixed it.  (I also submitted a bug report
and it was immediately added into the 5.5 builds.)

So, I believe the theory is that if we can build it from source, then we
know that we have what we need to attempt to track down something that comes
up.

I, personally, am a bit fearful of the whole build process.  The binary
build of tomcat has been thoroughly tested, and I am going to try to
shoe-string one together as best I can.  In the anecdote described above, I
actually started by downloading the source from the archives when we had the
problem (at that point I was allowed to just used the binary builds).  I
then, instead of building a whole tomcat installation, made my own
CGIServlet based on the Tomcat CGIServlet code.  But, it was just a lucky
break that the CGIServlet was just one file.  (Heavier used pieces of Tomcat
are undoubtedly more thoroughly tested and probably much harder for someone
like me to patch.)

Mark


 
-----Original Message-----
From: yoavshapira@gmail.com [mailto:yoavshapira@gmail.com] On Behalf Of Yoav
Shapira
Sent: Wednesday, May 24, 2006 4:36 PM
To: Tomcat Developers List
Subject: Re: Binary build procedures

Hi,

> As it turns out there is a second motivation for building everything 
> from source, and that is so if something goes wrong, we can find the 
> problem and fix it.  If we go through all the hoops now, then we won't 
> have this additional problem when we are hurrying to fix and issue.

Just out of curiosity, when you say above "if something goes wrong" do you
mean with your stuff or with the Tomcat build?

> In light of this, I was wondering if there was a way to not include 
> the eclipse stuff.  Is there an option to use just the Sun JDK 
> compiler?  I doesn't look like that is an option in the build.xml 
> file.  However, even if it has to be included to make the build happy, 
> is there a runtime configuration for this?

To be clear: when building Tomcat distributions, the Sun JDK compiler is
used.  The Eclipse compiler is used only to compile JSPs at runtime on a
running Tomcat server.  And yes, you can choose to use the Sun JDK compiler
at runtime instead of the Eclipse one: RTFM on the "compiler" option at
http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html.

Yoav

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional
commands, e-mail: dev-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional
commands, e-mail: dev-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message