Slashdot Mirror
How Tomcat Works
First of all, this is the only book I know of that explains how the complete system works. You can find good documentation on how to use this most popular servlet container on the Tomcat project's Web site, but little is said about how it works. If you want to join this open source project, good luck. You should consider yourself lucky (or very brilliant) if you can understand how the system works in less than 3 months by browsing through its millions of lines of code.
However, why I find this book appealing is because of the approach the authors take in analyzing it: build Tomcat from scratch, line of code by line of code, module by module. Miraculously, in doing so they never fail to make sure their readers can follow the technical discussions. In their hands, Tomcat looks easy that even beginners of Java can understand. There are many complex technologies used in Tomcat, and they are all explained well.
The book starts off by building a dummy Web server that can do no more than sending a static HTML page. The web server is simple and consists of only three classes. The backbone of this application is the java.net.Socket class, and the authors take their time explaining this class at the beginning of the chapter. Basically, this is how the application in this chapter works: for each HTTP request, open a socket connection to the client, read the content of the static file, and send the file to the browser. As simple as that.
Chapter 2 builds on the application in Chapter 1. In this chapter, the web server gets some intelligence. It is now able to invoke a basic servlet by calling the servlet's service method. However, more complex servlets are beyond this simple servlet container, mainly because the container passes a null ServletRequest and a null ServletResponse objects to the service method. Before the authors start coding, they explain the javax.servlet package in general so that those new to servlet programming can understand this chapter.
Chapter 3 explains how to create ServletRequest and ServletResponse objects so that the servlet container in Chapter 2 can do more. The excitement comes in Chapter 4 when the authors explain how to pool ServletRequest and ServletResponse objects to beef up performance. This topic is not only relevant to Tomcat, but also Java programming in general. Object instantiation is expensive, and one way to avoid it is by reusing objects. However, you must be careful when your application will be used by many clients, as you must then think about thread safety. Chapter 4 elegantly explains how Tomcat developers solve this problem, as well as teach you a general solution for object pooling. Interestingly, a servlet is always represented by a single instance, and the same instance services all incoming requests.
The authors are also patient in explaining everything step by step, until the last chapters where they tackle more difficult problems such as Digester, JMX, class loaders and session management.
Not only will you be good at configuring Tomcat after you are finished reading this, you will also be able to tell straight away what's going on whenever your Tomcat installation throws up some error message. In addition, if you are really serious about Tomcat, you can start thinking of writing your own modules or extending the existing ones. For example, as the authors have demonstrated, you can extend Tomcat's application loader to automatically reload a Struts application when the struts-config.xml is modified, making the application development process quicker.
This book is also great in answering many questions that seasoned servlet/JSP programmers might have long been pondering. For example, this book discusses the difference between an OutputStream and a PrintWriter, and why you can only use one of them rather than both. It also tells you why you cannot write to the request parameters or headers.
Now, as much as I liked it, this book is not perfect. The first noticeable flaw is that there are quite a number of disturbing spelling mistakes. Also, the index could have been better, not to mention a cover that is plain and uninspiring. However, I have to admit I am very happy with this book and will recommend it to any Java programmer.
You can purchase How Tomcat Works from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
What's Tomcat?
~Ilyanep
To get message, take amount of carrier pigeons at each stage mod 2. Then decode binary.
Whoa there... Java Apps (by which I presume you actually meant "Java applets", or you were trolling) have nothing to do with Tomcat, unless Tomcat itself were serving said applets. This is about web applications, which are (in an overly simplified explanation) pages generated by Java code in some sense or another, and only use as many system resources as an HTML webpage would.
-Rob
Marriage doesn't have to suck!
But I thought we weren't supposed to judge the book by it's cover?
...that some buisness need to read. The local school system here runs Blackboard which seems to use Apache Tomcat, and it really has problems, both with sessions and general speed. Perhaps some bigger corporations shoudl go back-to-basics with nice books like these.
WASTE - The Secure P2P
Tomcat is a software project to implement the Java Servlet specification. It's developed by the Apache group.
It lets you deploy your Java Servlets and JSP pages, among other things.
or do java apps take up a huge amount of system resources? Everytime I launch one, my system crawls.
Look, I used to hate Java, and quite frankly I can't say I love it much yet. But to be honest, it's come a long way since the days it was unbearable. So please come off the Java bashing, it's passé. Either that or upgrade your system for crying out loud...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
What Tomcat Is
From TFA, it seems tha book is quite basic. Would be great if it would actually discuss "how tomcat works, internally", something like a really advanced course. The material in book can be found in tutorials and stuff, but its slightly more difficult to figure out for the first time that you can "precompile" the jsp pages so the site is fast right from the very first hit.
Is is funny or ironic that the authors web page runs on php? http://www.brainysoftware.com/
I have been paid to build MS apps for years now, but I have "watched" Java from a distance and have to say that if I started a business of my own, all applications would be written in Java/JSP. I was one of the first to attempt to build Tomcat on a Windows system and after many disasters came to love it. The inner workings of Tomcat often baffled me and now I am gonna have a book! Sadly nothing I learn will translate to my current job, but it'll be damn fun.
--I smoked my sig.
What? If I had a servlet, what would I do with it?
Simon's Rock College
Have you got Tomcat development experience? Automating Open Exchange? Want a job? Reply to my journal.
--
make install -not war
Anyone know how this books compares to the O'Reilly book, " Tomcat: The Definitive Guide"? Also, it might be helpfull for people to know what a Servlet and JSP is before spouting out terms.
/.land using Tomcat for their production site? Also, any care to give any recomendations for an eclipse plug-in?
About the only thing common between an Applet and a Servlet is that both are writen in Java. Anyone out in
To have known how Tomcat works this past weekend when I was setting it up for a client. WHat a nightmare. Reminds me TOO MUCH of setting up Chilisoft ASP for Apache. Sure its a good idea, but I think its implemented poorly and from an administrators point of view, I found it hard to know where to start. The documentation for setting up Tomcat needs to assume that the administrator doesn't have any knowledge (or little) of Java.
I actually think that cover is elegant.
nice. But, I want "How Struts Works." Debuging struts applications is one of the closest things to hell that I've experienced in some time.
Ishmael
Click on the "Tomcat project's Web site" link in the second sentence of the "rest of the review". We can't click for you. But be advised, if you have to ask these lazy questions, you probably can't program a Tomcat app, no matter what it does.
--
make install -not war
Netcraft says they also have FrontPage(!), SSL, Apache, and Linux(no !). Must be a standard hosting package from Interland.
Simon's Rock College
Servlets are Java programs that handle specific events (such as requests to a URL) and Tomcat is an apache plugin that lets you run servlets from apache.
New web cartoon: Jendini.com
Oh yeah?
And maybe someone just wants to make money on their amazon referral?
It is available from BN for $10 less.
I passed the Turing test.
Whoa there... Java Apps (by which I presume you actually meant "Java applets", or you were trolling) have nothing to do with Tomcat, unless Tomcat itself were serving said applets.
Well, Tomcat itself is an application... written in Java... often abbreviated as a "Java App". Deploy a couple of webapps in tomcat and then check out the memory footprint of Java.exe and you'll see what he means. I've never used tomcat for production use although i do have 5.0.28 running on my workstation to test stuff, and i've found the solution to any perceived performance problems (esp. in single user mode as i do) to be RAM, RAM, and more RAM. At today's prices, why quibble: throw a gig at the problem - even if your problem isn't memory bound you'll *still* have a gig of ram! You can cackle like a maniac every time you think about it!
#!/usr/bin/english
Actually, Tomcat isn't an Apache plugin. Tomcat is a stand-alone server that can also be configured to support Apache for serving up Java web applications (which Apache cannot do on its own).
No, please have people keep the Java bashing. That is a way to know the stupid from the smart. The stupid people don't release that Java has improved greatly since 1996 and all the major software companies (except Microsoft) are betting heavily on it. The smart ones realize this and wouldn't bash it.
Like I told a guy (or girl :)) up above, you shuld really think of switchign to gentoo and using their tomcat ebuilds. I did and they really do totally rock.
G3ntooDud3
Java addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use JSP. Hell, I could hand deliver web pages halfway around the world faster than this.
Seems obvious to me that you do want to start a flamewar, but, this is a serious question, actually - why would anyone choose to use JSP?
You get all the problems of mixing buisness logic with content, plus all the problems that come with Java (slowness, memory use), plus a multiple-compiled language - good luck if your generated Java code fails! (Error on line 1,342 in Your.jsp - hmm, but it's a 20 line JSP, how is that possible? Oh, it's reporting errors in the massive bloat of the generated Java file, not in the JSP! Of course!)
I can't think of a single reason to use JSPs, other than to ensure that you'll never be able to maintain your system.
Java Servlets I can almost see, but JSPs just cause problems.
From this follows that object pools are counterproductive for performance (unless, of course, if resources are associated with them, like Database connections, open sockets, etc.).
I heard that quite a few app servers (including JBoss) started to refactor to get rid of object pools, but I don't have a link to back this up.
Under capitalism man exploits man. Under communism it's the other way around.
Add to that security.
I keep getting flamed by the moderators but do a search on the CIA's website for insecure langauges and software.
Php is the least secure langauge in existance and has more holes than even ASP.
I do not mean to sound trollish but its the truth and the next big wave of worms will probably be targetting at websites running php.
http://saveie6.com/
You should consider yourself lucky (or very brilliant) if you can understand how the system works in less than 3 months by browsing through its millions of lines of code.
If that's true, it sounds like it is bloated and not very well designed.
I'm posting this in IE - which I had to open just to read this writeup. Slashdot's HTML is flaky and when viewed in Mozilla Firefox, it blows out the table to 3x screen width (1024) and puts black text on black background.
Please fix your code. A lot of us use Mozilla around here!
Thank you,
Brian
--
http://www.assortedinternet.com/
i think the "enterprise" buzzword translates to "large projects". java's pretty easy to maintain stuff like that. java also offers run-time optimizations which would be helpful for something that gets a lot of traffic. i guess it scales better? (or at least that's the hype, i'm no expert)
with that said, php/apache is truly a joy and is my preferred web-deployment platform. java is my preferred platform for regular old applications.
Well, there is also porting to other containers (i.e. WebSphere). You also can take advantage of all the industrial strenght (and tested) libraries available. Not to mention the volume of books on the subject.
I think of it this way... PHP for web applications is inevitably like building your own house from scratch... mixing the concrete, cutting down the trees, etc. All by yourself. As I've developed some web applications in PHP, this is acceptable if you're building a yurt or something.
Java servlets are what you want to use if you want to ensure some level of expandability, or at least standardized web development practices (in theory). Companies generally don't have one mega web application they run, they have anywhere from several to dozens. You don't really want to start from scratch there. Authentication? Yeah, servlets can do that. Flow control? Yeah, that's covered too. In general, if it's something you're probably going to need, the specification covers it and you can implement it based off the specification, as opposed to winging it. Or, to get back to the house thing, buying precut steel instead of making it yourself. Or, having ready-made shingles instead of copying a design that was made earlier that may be kinda shoddy even though you don't know it.
This doesn't necessarily knock down existing frameworks like Ruby on Rails, which looks pretty sweet, or anything with frameworks. Servlet containers just happen to be (more) secure, time tested foundation from which to build web applications. Tomcat is a good servlet container. We also use BEA WebLogic.
-Rob
Marriage doesn't have to suck!
This may be off subject, but is somewhat related. The main computer in my house is a dual-boot P4. The disk has three partitions, NTFS, Reiser, and FAT. It is VERY nice to have a single location for my web server application (located on the FAT).
When I boot XP, Tomacat run my web app. When I boot Linux, I can run the EXACT SAME web application.
Granted, I could probably do the same with some other environmnets (which I choose not to mess with).
Keep in mind this is a family web site accessed mainly by family member. (Christmas lists, little league info, etc. etc.).
I'd really like to see some docs (a book, notes on the web, etc.) for admins.
I'm not a java developer, I don't want to be a Java developer, but I have users who do.
All of the Tomcat docs I've seen are written from the developer perspective. I need to be able to set up and maintain a development environment for students where they can work, and that doesn't crash the tomcat server every time somebody makes a coding error. But I have no desire to learn Java, only enough Tomcat to keep it running.
Ignorance killed the cat. Curiosity was framed.
You can read some sample chapters here. Just use your favorite archiving application and acrobat reader(neither included).
Even if you're doing Java, not all Java is going to be web-server-side Java. It really annoys me all these people who think that their little corner of the development world represents the totality of existance.
Don't blame me, I didn't vote for either of them!
My boss came into my office a few minutes ago, saw this book on my desk, and asked if I had seen the review on Slashdot. I laughed a bit and said I had. I read this book many months ago, and told my boss about it.
"How Tomcat Works" is a potentially good idea, done badly.
The writing is awful. Not just inelegant, but frequently so bad that it gets in the way of the ideas being presented. Spelling, typos, grammar problems, convoluted sentences, miswordings that invert the meaning of a sentence entirely: this book has all that, and more. A fourth grade teacher with a red pen would have made this a much better book.
A book on "Tomcat Internals" is a wonderful idea; Tomcat's a somewhat complicated beast. But the approach that this book takes... it just didn't work for me. It's possible that I simply couldn't get past the bad writing. Or it may simply be that it doesn't meet my needs. I'm familiar enough with Tomcat that I don't need it explained in tiny little baby steps. What I do need, when I'm up to my ankles in Tomcat internals and trying to solve a particular problem and get on with my life, is a clean, well organized book that will quickly get me oriented, refresh my memory on the relevant bits of Tomcat's architecture, and point me to the solution to my problem. This book fails to do that.
The production values in this book leave a lot to be desired. There aren't enough diagrams, and, at least in my edition, the few that do appear are printed at very low resolution. The index is a joke. (Hint for the authors: a quick indexing script doesn't always make a useful index, okay? Second hint: hyphens denoting sequential pages are cool.)
I've learned a lot about Tomcat since reading this book... mostly by wading through the source code. After a quick initial read-through, "How Tomcat Works" has stayed on my bookshelf, untouched, for at least five or six months. This book will join "Apache Server Commentary" in the pile of books that seemed like a really good idea, but in the end, were much less helpful than I had hoped.
If you just need a book on installing or using Tomcat, or writing Java servlets in general, there are many better books. If you need a book on Tomcat internals, you probably need a better book than this one.
"This doesn't necessarily knock down existing frameworks like Ruby on Rails, which looks pretty sweet, or anything with frameworks."
http://www.beta4.com/seaside2/
Yeah, java is more than a applet dude, well at least since 1995. You can build full blown java applications, that work and in some cases even look like windows applications. Not only that you can also build server side applications. IBM is big into java, they have a highly popular editor named eclipse http://www.eclipse.org. Visit my sig, that is a java serverside application in essence!
especially in an environment where the guy in charge of the jboss deployment couldn't make it run from an exploded WAR file. so every change meant a wait for the compile, zip up into a 1.5meg WAR file, copy it to deployment directory. Jboss then unexpands it and starts deployment.
:)
you then go through the whole login thing only to find out you screwed the configuration file.
java/html/struts single handedly killed my love of coding within a year. coded since i was 11, now 33. hardly touch code now even for fun.
php is much better adapted for the web. php 5 is getting 'closer' to java (integration as well as the language) so if i was to do anything that required a middleware layer now i'd do the front in PHP and use java for the middleware. and get somebody else to do that, screw EJBs
anyway, so they're (BB inc's) idiotic set up of Tomcat, your stuck with it. A better idea is to get them to switch to Moodle, it's every bit as good as BB, faster, and runs on straight LMAP, no need for stinky ol'Tomcat (nor MS SQL & IIS, ak-pffft!).
Comment removed based on user account deletion
Flow control!? Finally a language with flow control! It's about time...
Nup. I feel like Java bashing. It started off as a slow incapable not quite free software solution that doesn't quite work on all platforms (write once, test and tweak everyfuckingwhere). It's developed into an over-engineered (Java2 Everyfuckingthing Edition) not quite free software solution that doesn't quite work on all platforms.
I WANT to love Java. Honest I do. But its gone to shit.
anyway, so they're (BB inc's) idiotic set up of Tomcat, your stuck with it.
What are you trying to change that you haven't been able to? I've changed a few of BB's tomcat settings.
no need for stinky ol'Tomcat (nor MS SQL & IIS, ak-pffft!)
Don't need MSSQL or IIS for BB either.
Remember that JSP's are simple shorthand for objects that eventually get compiled into full-fledged servlets upon their use (or earlier, if you precompile them when deploying your app). The difference between JSP's & servlets is a development-time issue only.
.NET framework. Unless you're coding your web pages in C, this "slowness" or "memory use" will be an issue, as anything else (.NET, perl, php, etc.) is all interpreted.
And there is no reason at all to mix business logic & content - in fact, application frameworks like Struts make it *hard* to do so.
The rest - slowness, memory use, etc. - could apply to any commonly used platform. I've seen studies that put certain types of java code as faster than the "managed" code of the
Or perhaps IHBT. HAND.
One of the biggest problems so far has been finding good info on the process of integrating Tomcat/mod_jk with Apache under Win32.
Good luck using any official Guides for the task.
Check...
http://www.devside.net/web/server/windows/Tomcat
http://www.devside.net/web/server/windows/mod-jk
>> I keep getting flamed by the moderators
might have more to do with your user id than with your opinions.
Tomcat is many things:
The key is understanding what a servlet is. A servlet is an instance of a Java class that is invoked in response to an HTTP request. In other words, it's custom Java code for handling and responding to HTTP request by web browsers and other clients. Think the Java equivalent of CGI applications. If you like Java, servlets (and the JSP technology that is built on top of them -- JSP pages compile into servlets) are a nice way to build dynamic websites.
You can use Tomcat in standalone mode or by hooking it up to a web server like Apache -- it ships with a module for the latter that directs servlet requests from Apache to Tomcat and back.
It's getting easier to find hosting services that offer servlet support, and they usually run Tomcat to do it. Personally, I use KGB Internet, but check the list of servlet ISPs for other alternatives.
Ericwho has a Java-powered website
The stupid people don't release that Java has improved greatly since 1996
The way I tell the stupid people from the smart ones, is to look at their spelling, and word usage. Since I am quite confident that you did not really mean to use the word "release" which means "to let go", but rather probably meant "realize", you are leaning to the stupid side. The really stupid people, manage to use the word properly in one place and not in another.
The smart ones realize this and wouldn't bash it.
I wonder, do you take the short bus to work?
BTW, Java really does suck ass. Does a whole pile of stuff OK, and does nothing well. However, I RELEASE that it doesn't SUCK as much today as it did in 1996.
I am done. I am confirmed smart by your yard stick, you are confirmed painfully stupid by mine, and I still get to mention that Java totally sucks.
Just because something sucks less today than it did in 1996, doesn't mean it doesn't still suck to this day. There is a "Just ask your mom" joke in here that I will avoid.
It is useful for not only those using Tomcat or those working with servlets/JSP/J2EE ...
As a J2EE programmer, I find the reviewer's statement to be a bit misleading.
Tomcat is not a J2EE server. The J2EE specification deals with Web Components (Servlets, JSPs) and EJBs (various EJB types and related services). Tomcat only satisfies part of the the full J2EE specification by serving Servlets and JSPs. Therefore, Tomcat is only a Web Container.
JBoss is an example of a J2EE compliant app server.
I'll bet this is a troll. No specific details, could do a s/Tomcat/whatever/ and get the same review, the classic calling cards of a book review troll. You make the call...
distributed, load balanced, objects -- it will load balance across a cluster as well as on SMP machines, which are very common in SUN installations. A servlet must be serializable so that at any point the container can externalize it and resume it on another node.
Well, it's OK to do presentation stuff -- taking stuff you've done out of the session and request and generating output for the user. Granted, there are dangers involved -- sooner or later somebody will make a huge jsp with tons of business logic. Granted, there are ways of doing presentation that aren't as dangerous. But it's simple and good enough for a lot of tasks, especialy combined with css.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Like strong Java OOD/OOP*. Like JDBC for database access that beats all other database abstraction layers I have seen. What about a lot of mature libraries and frameworks that make MVC2** application much easier. Ability to reuse your code in dekstop applications. And many more.
* Object Oriented Design/Programming
** Model-View-Controller 2 app architecture
--Coder
on server side. I code web-apps for a living in java, and it beats anything maybe except apache plugins coded in C in performance. The myth that java is slow comes from poorly coded desktop GUI apps using Swing toolkit. That doesn't mean language itself is slow. On server side, where there's no GUI, it's screaming fast. Oh, and who cares about startup, you only need to start your server once. And now that IBM has made a decent GUI toolkit for java (SWT), it is becoming a decent language to write desktop apps too. Check out Azureus bittorrent client. I don't think you will complain it is slow. I had SWT plain text editor start up faster than gedit.
--Coder
I just completed an evaluation of the leading servlet engines for my employer, including the fabled Resin, and Tomcat 5 came out ahead in nearly every respect. It even had a 16% - 20% performance boost over Resin. We couldn't believe it ourselves... If you weren't considering Tomcat because of outdated opinions, it's time to take a second look.
By comparisson Tomcat is one of the best and quickest servers to run J2EE, servlets and JSP (it is also the best static content server around, Apache you know).
:|
I have used many other java application servers and they don't really come close. WebLogic dev environment and stability made me appreciate a root canal. WebSphere taught me patience while waiting for the debugger to start (if it doesn't crash while starting); not to mention the debugger can easily use up 1GB of ram while running. iPlanet, well I won't even go into that, I'd rather forget those 6 months I had to write code for it and it's bastard brother Kiva.
Tomcat is relatively lightweight, you can use Eclipse to develop and deploy to it. But most important, the code executed on it is as good as the writer of the code and too often people writing apps for Tomcat should have just stuck with thier non-CS background and found an appropriate job
On a side note, J2EE is a big hype, it's slow, cumbersome and overly complicated. You can do almost enything you want with a servlet or JSP page (and people should always try to keep as much of the content static as possible to take advantage of caches and reduce pointless execution cycles). Marshalling code in many implementations adds too much overhead to justify any benefits you may get from distribution, but your mileage may vary.
Tomcat is free, people can just download it (http://www.apache.org) and try it out, the online docs and FAQs are pretty good, then once you have it running and you like it, buy some good books on it.
Dear Billy Troll,
it's not languages that are insecure; no matter what language you use, you need to have competent programmers.
Php is safe and robust, simple and elegant. You can build small or big applications. It is technically *simple*, and that means you don't need books like the one we're discussing here. Just learn the language and you're all set.
Now take an incompetent programmer, and they will build you an insecure system, no matter what language you use.
-- http://matteo.vaccari.name/
recommended for all web developers out there
Well, that it does offer. Dealing with a HEAD request: buffer the generated contents, and only send the headers. A PUT request? No problem.
Just beacause you don't know how to do it, doesn't mean it can't be done. (No offence.)
-- ArienI was under the same impression when I had a look at struts.
I also tried a project with a struts-like PHP framework and it was awkward. Can you recommend any alternatives to struts?
it scares me that I DO judge a book by its cover, but I do. all of us do.
For instance, I judge cereals by the cover, a whole new box. Now bearing in mind a box of cereals fills that quasi-intimate moment where I am still half awake, and I lovingly spoon it into my mou... oh, sorry.
You see, books have to be appealing to us, technical books have to say, read my witty and easy going words, and you will be amused and infused!
In a semi-related issue. In the new world of e-publishing, we see the internet is 99% utterly useless.
Now real-world publishing on demand is sparking a torrent of even worse writing that is, shockingly, taking itself seriously.
I am quite happy the way many OS developers have written authorative books on thier works, but in the future some enterprising scum might cloud the market place with bound copies of man pages and other scamful publishing.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
I had similar experiences with Tomcat. However, Jetty has worked great for me.
Last time I got IIS and Tomcat talking was after I abandoned the jk2 and went back to the jk connector.
c at_iis6_resources.html
There are some additional steps including permission setting to get IIS to use the redirector.
More info here: http://www.rit.edu/~ack5504/tomcat-iis6-howto/tom
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
one idiots opinion
Slowness is an issue with any type of "interpreted page" (Perl/CGI, PHP, SSI). You get that with CGI in general--needs to fork and execute external script or program). mod_perl, though, imbeds Perl into the Apache. If properly loaded on startup, you really don't have any interpretation overhead--same with precompiling jsps. One issue, though, that Java truly has is memory usage. When it comes to RAM, Java is a pig. I'm starting to write basic jsps and servlets (go Struts!). My simple, one-application instance of Tomcat is using 28M resident memory. Apache with mod_perl and a few small apps is only using 5M. After hitting the app in Tomcat mem usage goes up to 34M, while Apache's mem usage only goes up to 7M. On another machine I have two sites with a total of 40 jsp pages. Tomcat mem usage there is at 44M. Apache on the same box is only 5M. While Java is neat and does give you many features, it requires an order of magnitude more hardware to support it (cpu, ram, fast disk.) Perhaps if Tomcat was written in C it would be more resource-friendly. Seriously. (No, it's not a troll. ;-)
Good luck
You already got the answer to question 2.
... like cron jobs?
ad 3) I know it's hard to unterstand if you're thinking differently, but PHP is strongly typed. It's so strong it's changed by PHP itself to match the value.
And the other think is we're using HTTP. PHP is written for Webapps. That's why it sees everything like HTTP or HTML: as string. Thus it doesn't matter if a number is in an int or a string. The only think that matters for your validation is that it only has digits in it (like with is_numeric()).
ad 4) You mean
ad 1) Yeah that's still a thing worked on. SRM might really be a solution to it.
See PHP is not standing still, but your arguments are. I don't see you working with PHP often enough to be able to argue.
b4n
You have just described a weakly typed language.
No. Cron jobs are not running continuously (or whenever there's an event that needs handling), and are not in the same process space as your application.
You must not be looking. I use PHP most days.
Ok I'm not going to argue about calling it strong or weak. There're different meanings ... However in the end it doesn't matter in the field of webapplications.
But both, a continuosuly running script and exchaning data with the other scripts (or just have some data saved between the scripts) is very easy with stuff like shared memory.
I don't see PHP being worse or better as Tomcat or other Java stuff. It just works different, but without problems.
b4n
That's not the question. The question was:
Which is what I (and others) answered. It called for no value judgement.
Nice try, asshole.
it's not languages that are insecure; no matter what language you use, you need to have competent programmers.
Well, you're right that you *do* need competent programmers to build a secure system, no matter what language you are using. You're wrong on your first point, though. PHP and Java both run in interpreters -- that's software which *itself* can have exploitable flaws.
Language design also does make a difference in security. Even if all interpreters and runtimes were perfectly secure (they're not, and PHP in particular still has a lot of maturing to do), you still have a level of "gotchas" that a programmer must know to avoid for their site to be secure.
Java *and* PHP, for example, are designed so that buffer overflows are impossible. All of the buffer overflow exploits that keep showing up in even well-designed software like Apache... those are a hugely dangerous gotcha because the level of careful, intelligent programming required to avoid them is very high for complex software.
Alas, PHP has features designed to make programming quick and easy that also introduce lots of gotchas, like the loose-typing. You can take random input from the user, like $username = $_POST['username'], and execute that *inputted text* like a function if you screw up and put extra parentheses after it:
$other_var = $username();
You make that mistake, and an external user can call any function they want, just by tinkering with the username field. They are gotchas in any language, but the ones in Java are more likely to break your code logic, NOT to give lots of power where you didn't mean it (thanks to the integrated security model and strict typing). I've only been learning PHP for about a week now, and I've already noticed a bunch... so I don't really know the full extent, but of course a more "flexible" language will have more of them.
-- http://matteo.vaccari.name/
That's a good point, though I've seen enough bad code to say that errors like this actually COULD make it out -- there's a shocking number of developers out there who just make changes until it "works"... even if they're still broken code being executed (in PHP you just put an "@" in front of any function call to suppress errors, and people DO this so they can keep working without sorting out the problem!). You see multiple attempts to do the same thing, and only ONE of them actually does it. Ugh.
That's back to incompetent programmers, though..
Here's a better review of security issues in PHP, with much better examples than I had. I'm out of my areas of expertise....