Slashdot Mirror

Jakarta runs on Windows or Linux.

It's not really fair to equate mod_perl to per-page interpreted languages.

mod_perl, and to a certain extent Java servlets, gives you a huge amount of power over the web serving process, and are suitable for developing web applications that can do almost anything with HTTP.

PHP, ASP and the like give you a per-page interpreted language, oriented to producing one page of HTML at a time. They are much easier to get started with, and they're the "right" choice for most websites.

Of course middle-men between the two camps exist: Servlets have JSPs, for example, which obey a per-page paradigm but are run by servlets. There are also third-party templating system with greater or lesser degrees of flexibility/depth/power (Tapestry is a particularly impressive one.) My own website (http://n3dst4.com , rather than the one in my profile) is written in Mason, which is an interpreted component and template layer on top of mod_perl. Because of the depth of control that mod_perl has, Mason can do some things that PHP can't, like having a completely programmable request handler, global or per-directory pre-handlers, a seamless component model).

I'm not dissing PHP, though. The site in my profile (Sacred Steel) is written in PHP, because it was the right tool for that job.

Oh, and remember that .net and J2EE are allegedly complete enterprise programming platforms, while mod_perl is just one specific technology for web application programming.

Heck, you could offer your customers a "turn-key" solution. Put together a cheap server running Linux with Tomcat for J2EE or Apache/Mono for .Net. Sell that for a fair price. Your customers just have to plug it in and turn it on. Your customers will have no extra license fees from MS to worry about. If you have any half decent developers on your team, they could write _standards compliant_ HTML and then you don't need to worry if your clients are hitting your web app with IE, Firefox or Safari. If your customers have a net connection, you can plug it into this Linux server you sell them and charge a small annual maintenance fee for support. If there is a problem, just VNC or SSH in and fix it.

If you go with a fat GUI client, then I personally would do it in Java with SWT (the toolkit used by Eclipse) for the GUI. SWT is very fast and lightweight. You can even get good SWT GUI designers to make coding easy. By going with Java for the GUI, you don't have to worry about what OS your customers use.

If you go with .Net, then you should use Mono and GTK# or QT# for the GUI. That won't lock you into just MS Windows for your customers. You would be able to deploy to Mac, Linux and Windows. I know my doctor uses an iBook. She carries it into the exam room all the time and manages all her patient records from it. So if you went with an MS-only solution, you would lose customers like her.

If you are developing an internal only solution, then use what you want. However, if you want to sell software (especially as a small company), you really should give your customers the most choice. If you went with a fat GUI client, you could sell a turn-key solution that ran Linux with Mono. Again, your customers will have no license fees to worry about, just your bill : )

I work as a senior programmer for a fortune 500. A few months back we went through a similar situation. However, we don't sell software, so everything we develop is for corporate use only. We had two camps. The J2EE camp and the .Net camp. We even hired three outside consulting companies to help make the choice. All three companies said that our web apps should be done in J2EE. However, politics won out and now we have different groups doing different things. Some are doing J2EE and some are doing ASP.Net C# and I get to be involved with both.

IMO, your senior manager should have no say in the technology used, just the features. The technology choice should be done by those who are going to _implement_ the technology.

"My senior manager recommended using .NET. His argument is that most desktops he has seen in hospitals already run Windows, the development time will be cut down for this small to mid-size project, rich desktop clients are possible and there will be no application server costs involved. He also contends that .NET has more templates and abilities than J2EE (which is simply 'web targeted' in his opinion.

That sounds like he has already be "won over" by some MS sales guy. .Net development is not going to be any faster then J2EE. .Net might even be a little slower at the start because you have

First of all don't use EJB's unless you have to. If you don't need distributed transactions then stay away. You don't want heavy weight frameworks to drag you down. Read: Better, Faster, Lighter Java. http://www.oreilly.com/catalog/bfljava/ For a free introduction read: http://www.onjava.com/lpt/a/4744

My personal advice is a stack made of:

1. JSF for the webfront. Struts if you are a bit more conservative. http://struts.apache.org/
2. Spring for the business logic. http://www.springframework.org/
3. Hibernate for persistence. http://www.hibernate.org/

Don't forget to have fun.

• Hibernate for object relational mapping and cross compatibility with most major databases (ie, develop on MySQL, deploy on Oracle, Informix, whatever you want).
• Spring which manages your mappings and helps maintain consistency across your data connections and helps you abstract your business logic, keeping it out of the actual pages. It also integrates with . . .
• Struts which gives you a great Model-View-Controller framework to practice good development and good security.

There is not such thing as "Red Hat" webserver.

Yes there is. It's based on Apache software, but the Apache software license forbids Red Hat from abusing the APACHE mark on derivative works.

The recently released Apache Software License (ASL) 2.0 already includes a patent clause. To the best of my understanding the ASL does not have anything in it against patents per se, but ASL's patent clause is only triggered when actual patent litigation occurs. This, as well as an interpretation of the current GPL patent stance is explained in great detail here.

Being a fan of java, Apache JAMES is my current mail server favorite. The Mailet API is a really cool for customization and it boasts really good performance numbers (check the wiki for more info). And it runs on anything with a recent JRE.

True, NT does favor threads vs processes as they are much lighter, but even more than that, NT favors a very small amount of threads running as asynchronous workers. NT inherited the heavily asynch IO model from VMS.

On NT, instead of creating 64* threads (or whatever the maximum number of concurrent clients will be, possibly hundreds) where one thread waits on each connected client, it would be better to create about 1 thread per CPU and have them take work items off of a completion port. Instead of blocking on IO, always do it asynchronously and have the result posted as another work item.
Both files and sockets can be connected to completion ports. Always have a pending read on open sockets so when a packet is recieved, the OS posts a work item.
Client wants dynamic content but you have to read something first? Start the read now and immediately go back to waiting for another work item in case you could be doing something else in the meantime. When it completes, the OS will post it and you can finish the operation: do the necessary processing, start an asynch write of the result to the socket and go back to waiting for more work.
Client wants a static file? Start the transfer with TransmitFile (it's like UNIX sendfile) and immediately wait for another work item.
The only thing you should be blocking on are locks to synchronize multiple threads. Never IO.

On a single processor machine, you might as well only have one worker thread since it should never be blocked except for lack of work: this means that nothing has to be threadsafe. The buggy PHP extensions could live in a happy single-threaded world without sacrificing any performance. Hopefully you can upgrade to better software if your server has multiple CPUs to take advantage of, or use one process per CPU.

* Apache has to have 200 threads if I ever expected that many clients to connect at one time, just in case? Can't they at least be started dynamically? No wonder it doesn't perform well on Windows. I just hope they aren't used round-robin.

User directive
Special note: Use of this directive in <VirtualHost> requires a properly configured suEXEC wrapper. When used inside a in this manner, only the user that CGIs are run as is affected . Non-CGI requests are still processed with the user specified in the main User directive.

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

http://merjis.com/developers/mod_caml/apache_2.0

Rich.

IIRC, it was a license issue. The AFS wanted the PHP project to switch to using one of the ASF licenses while the PHP folks did not. PHP is still listed as a sister project. It's just not under the official ASF umbrella.

The biggest problem with PHP-based virtual hosting is that any script running has full permissions as user "nobody".

PHP SafeMode is an ugly hack fraught with security holes. The real answer is RIGHT HERE but alas, it's been dropped.

these guys have done some more work with it, and the best bet (so far) seems to be this one which (at least) has active development on it.

I LOVE the idea - from a security standpoint, this is the best news for Apache/Unix shared hosting since the invention of the password. I have a fairly busy server (about 700 active domains) and I'll be slowly migrating over the next 6 months or so to using this tool.

It works with PHP and Apache2. I just won't use any non-threadsafe libs, so no issues there.

I checked the front page of Apache and there were release announcements for the latest version of both lines. Neither announcement carried a statement indicating when you should use it over the other.

P.S. Apache 2.0 is great and there is no reason not to use it IMO.

The project home page (number one hit on a google seach for SpamAssassin) has a link to a list of commercial support solutions written with a large font at the top of the page.

No, it was named after Native American Indian tribe of Apache. See this: http://httpd.apache.org/docs/misc/FAQ.html#name

If you're doing shared hosting and you allow your users to run CGIs-- regardless of what CGI it is-- you should have reasonable limits in place that keep child processes in check. Apache has had such directives for doing this for some time, one of them being RLimitNPROC. This directive allows you to limit the number of subprocesses that Apache will run concurrently.

You can even specify subprocess limits on a per-virtual host basis. With Apache 2, you can even limit based on directory. Using RLimitMEM is also a good idea.

Yes, MT's comment system can use some improvement. We're working on that. But these servers are getting hammered; in effect a denial-of-service style attack.

Even a "Hello, world" type script can be hit hard enough to bring down a server, assuming there are no process limits in place. Invoking a modern interpreter to execute a CGI script is no small feat. Perl, Python, Ruby, and even PHP (when run as a CGI as many shared hosting companies do for security reasons) consume enormous amounts of resources at startup regardless of the size or complexity of the script they are summoned to execute.

So, sure, code can be added to MT to recognize and adapt to a flood of comments coming in, but by the time the CGI runs, it's already chewing up CPU and memory. In my opinion, a better defense for these flood-style attacks is for Apache itself (or third-party in-memory Apache modules) to handle such situations.

mod_security, mod_dosevasive and others are excellent defensive tools for any public Apache server admin to use.

I'd love to know what others have done to configure Apache to prevent denial-of-service attacks.

If you're doing shared hosting and you allow your users to run CGIs-- regardless of what CGI it is-- you should have reasonable limits in place that keep child processes in check. Apache has had such directives for doing this for some time, one of them being RLimitNPROC. This directive allows you to limit the number of subprocesses that Apache will run concurrently.

You can even specify subprocess limits on a per-virtual host basis. With Apache 2, you can even limit based on directory. Using RLimitMEM is also a good idea.

Yes, MT's comment system can use some improvement. We're working on that. But these servers are getting hammered; in effect a denial-of-service style attack.

Even a "Hello, world" type script can be hit hard enough to bring down a server, assuming there are no process limits in place. Invoking a modern interpreter to execute a CGI script is no small feat. Perl, Python, Ruby, and even PHP (when run as a CGI as many shared hosting companies do for security reasons) consume enormous amounts of resources at startup regardless of the size or complexity of the script they are summoned to execute.

So, sure, code can be added to MT to recognize and adapt to a flood of comments coming in, but by the time the CGI runs, it's already chewing up CPU and memory. In my opinion, a better defense for these flood-style attacks is for Apache itself (or third-party in-memory Apache modules) to handle such situations.

mod_security, mod_dosevasive and others are excellent defensive tools for any public Apache server admin to use.

I'd love to know what others have done to configure Apache to prevent denial-of-service attacks.

I take play nice to mean work, here. Don't let the parent scare you. There is documentation to help you out.

oops, what the hell, the link didn't come through ... http://www.apache.org/dist/httpd/Announcement2.htm l that's the apache link.

How long until...people start banging on Firefox hard enough to expose vulnerabilities?

How long until people start banging on Apache hard enough to expose vulnerabilities?

This is a tired argument: the development of IE and Firefox run at different speeds - I've upgraded Firefox several times this year alone, while there have been only two or three updates to IE6 since it was released - way back whenever that was. Firefox is exposed to many eyes, and bugs are shallow. IE is exposed to as many developers as the Microsoft marketing department feel it needs right now, and bugs are deep. Meanwhile, IIS remains a buggy POS, and isn't the World's Favourite Web Server, and Apache improves daily and - get this - is the World's Favourite Web Server by a wide margin.

He's saying "lend us a tool to do our work.". You're saying: "limit the tools to linux, screw the rest." (paraphrasing, I know).

Why should linux be required for running any software application? Why should windows be required? The most widespread software has the minimum of requirements in all respects.

As a software developer looking at my toolset and my professional future, the tools I value the most are those that work regardless of my working environment. Tools which can (for example) compile from CVS using libraries I have (pre-existing, added, accompanied or otherwise). In turn the most valuable libraries are those that work, again regardless of their working environment. libraries and tools like wxWidgets, Apache, which have been ported to more platforms than you can shake a stick at show that NOT porting to a platform goes against the "open" spirit of Open Source.

Lets take apache for example. They were #1. They are #1. Not just #1 in linux, but on any platform. They don't care where they run on. They want to run well. I'm sure they'd be pleasantly amused if they saw a Dreamcast running an Apache server (,I know I would).

Note that for the paragraphs on tools no specific platform was mentioned. That's because the OS should not matter. Imagine if the first thing people did with their windows machines was install KDE! that would be an exciting future indeed. Imagine the first thing people did on a linux box was install KDE! that happens now. Imagine any , newly acquired where the first thing installed is KDE!

Developers limiting themselves to any OS are shortchanging their applications. Open Source will be the norm, when we have a world where Things Just Work.*

*no exceptions or limitations

Interesting, this is the first post I could find that mentions any framework libraries. Does everyone here just use straight JSP?

I would be interested in /.er's opinions on framework libraries such as struts and hibernate.

Another templating package is Jelly the avantage is that it uses a syntax that's quite similar to JSLT.

A couple of template packages that are good:
Freemarker
Velocity.

And if you need to perform pdf manipulation: Big Faceless Java PDF Library It's not free but it's a really nice package

Maybe he meant Jakarta Commons.

http://jakarta.apache.org/commons/index.html

• Unfortunately, the project never gained critical mass, so it was deemed best to close it (in August, 2004).

Wrong Commons. It's called Jakarta Commons and is alive and, despite a certain tendency to include crappy, hastily-thought-out and sloppily-designed implementations, generally considered well.

Xalan for XSLT and XPath processing. Here's a tip: Never, ever use SAX for XML parsing of application-specific data structures. SAX is a nice low-level interface for building upon, but unless you're programmatically emitting a document from scratch, it's painful to use -- you always end up writing a stack-based content handler to keep nesting state. XPath makes parsing a breeze.

JGroups (formerly JavaGroups) is a protocol stack for building reliable, fairly efficient network communications based on, among other things, multicast IP. The entire stack is user-defineable, so you can pick and choose the level of reliability and which features you want (TCP support, pinging, group membership management etc.).

Lucene is a text-indexing engine. It's actually pretty crap, and does not scale very far (we're talking a few seconds for result sets of only a few thousand documents), and the code is pure spaghetti (abstract base classes! Inheritance!), but if you need a little indexing engine or some decent text tokenization classes, and your performance requirements are modest, it works well enough.

SableCC is a good BNF-based parser generator that generates type-safe parse trees that can navigated at runtime. Unlike the more well-known JavaCC, it's easy to get started, not least because the BNF-like grammar is so simple.

Xalan for XSLT and XPath processing. Here's a tip: Never, ever use SAX for XML parsing of application-specific data structures. SAX is a nice low-level interface for building upon, but unless you're programmatically emitting a document from scratch, it's painful to use -- you always end up writing a stack-based content handler to keep nesting state. XPath makes parsing a breeze.

JGroups (formerly JavaGroups) is a protocol stack for building reliable, fairly efficient network communications based on, among other things, multicast IP. The entire stack is user-defineable, so you can pick and choose the level of reliability and which features you want (TCP support, pinging, group membership management etc.).

Lucene is a text-indexing engine. It's actually pretty crap, and does not scale very far (we're talking a few seconds for result sets of only a few thousand documents), and the code is pure spaghetti (abstract base classes! Inheritance!), but if you need a little indexing engine or some decent text tokenization classes, and your performance requirements are modest, it works well enough.

SableCC is a good BNF-based parser generator that generates type-safe parse trees that can navigated at runtime. Unlike the more well-known JavaCC, it's easy to get started, not least because the BNF-like grammar is so simple.

First, make a plan of what your trying to do.. then go browse apache Commons.

Bad mojo man...

From the site:

Unfortunately, the project never gained critical mass, so it was deemed best to close it (in August, 2004).

Looks like you'll have to find a new way to start projects. Bummer.

Mozilla's LDAP SDK when doing LDAP work

The pre-1.5 concurrent threading classes

Command-line argument handler library

Log4J logging.

Mozilla's LDAP SDK when doing LDAP work

The pre-1.5 concurrent threading classes

Command-line argument handler library

Log4J logging.

In no particular order...

Commons Logging. Yeah, you said you wanted to avoid extra libraries, but the overhead of commons logging is so incredibly small, and the extra libraries you'll want to otherwise use are going to require it anyway. It's a measly 28KB last I checked, and well worth it.

HttpClient If you want to do any form of HTTP transfers, avoid HttpUrlConnection (built in to Java) at all costs. The HttpUrlConnection code is broken in many ways (too many to list), so you'll need another library. HttpClient does a good job of hiding the HTTP transfer behind the scenes, and has easy ways of letting you extend/change what you need.

JGoodies Looks Swing is getting better every day, but for that extra polish, you'll want to use the JGoodies Looks library. It does a great job of making Metal look just that much better, and also helps out the Windows L&F in some places.

Xerces I'm not sure if the bulk of this is included in the latter versions of Java, but Xerces is definitely a must-have for any XML parsing.

Other goodies...

For rendevous (multicast DNS) support, use jmDNS. It just works.

If you need i18n handling (normalization, etc..), IBM's icu4j does a great job.

In no particular order...

Commons Logging. Yeah, you said you wanted to avoid extra libraries, but the overhead of commons logging is so incredibly small, and the extra libraries you'll want to otherwise use are going to require it anyway. It's a measly 28KB last I checked, and well worth it.

HttpClient If you want to do any form of HTTP transfers, avoid HttpUrlConnection (built in to Java) at all costs. The HttpUrlConnection code is broken in many ways (too many to list), so you'll need another library. HttpClient does a good job of hiding the HTTP transfer behind the scenes, and has easy ways of letting you extend/change what you need.

JGoodies Looks Swing is getting better every day, but for that extra polish, you'll want to use the JGoodies Looks library. It does a great job of making Metal look just that much better, and also helps out the Windows L&F in some places.

Xerces I'm not sure if the bulk of this is included in the latter versions of Java, but Xerces is definitely a must-have for any XML parsing.

Other goodies...

For rendevous (multicast DNS) support, use jmDNS. It just works.

If you need i18n handling (normalization, etc..), IBM's icu4j does a great job.

In no particular order...

Commons Logging. Yeah, you said you wanted to avoid extra libraries, but the overhead of commons logging is so incredibly small, and the extra libraries you'll want to otherwise use are going to require it anyway. It's a measly 28KB last I checked, and well worth it.

HttpClient If you want to do any form of HTTP transfers, avoid HttpUrlConnection (built in to Java) at all costs. The HttpUrlConnection code is broken in many ways (too many to list), so you'll need another library. HttpClient does a good job of hiding the HTTP transfer behind the scenes, and has easy ways of letting you extend/change what you need.

JGoodies Looks Swing is getting better every day, but for that extra polish, you'll want to use the JGoodies Looks library. It does a great job of making Metal look just that much better, and also helps out the Windows L&F in some places.

Xerces I'm not sure if the bulk of this is included in the latter versions of Java, but Xerces is definitely a must-have for any XML parsing.

Other goodies...

For rendevous (multicast DNS) support, use jmDNS. It just works.

If you need i18n handling (normalization, etc..), IBM's icu4j does a great job.

Of course the web pages are stored locally. Not only are they stored locally, they are also _indexed_, which is what makes searches fast. Think Google - the same type of technology is behind Simpy.

Actually, Simpy uses Lucene [1], a search tool I know a little bit about. [2] (no, this is not a promo)

[1] http://jakarta.apache.org/lucene
[2] http://www.manning.com/hatcher2

This is a completely useless article. Why blame the Desktop searches??? Once they're in, they have control. If a Sys Admin let the user have enough permissions to index the file with the vital data, surely that is the Sys Admin's fault.

On UNIX the old adage was that once an intruder had a shell access to the box, you had to assume they could escalate their priveleges. This may not be possible in reality, but makes you focus on shoring up the ways in instead.

If you'd like some help tuning your mod_perl server, we'd be happy to oblige over on the mod_perl mailing list. Off-hand, I would say MaxClients at 256 sounds pretty high and may send your server into swap unless it has tons of memory.

ServerLimit 768
MaxClients 768

ServerLimit 768
MaxClients 768

Actually, there are already several open source text indexing engines. Lucene is pretty popular. Putting a user interface and a plug-in architecture around it is not so difficult. The main problem with it is that it's written in Java, but it can be compiled with gcj and the UI could be written in SWT.

I use a better compressor.

The Internet (specifically WWW) in its current form did not exist before advertising. To think that the Internet today can continue without ads based on some magical elf business model is simply absurd. Everyone says "Well they'll just have to find a new business model," but no one has any suggestions.

How the *%^& did this get modded as insightful?

The internet was born before advertising, and it was pretty bloody useful too, probably more useful than the cluttered space it has become.

Almost every large company on the web is selling something - that's how they make their money. If they're not selling something, then they use the web to place pre- or post-sales information: specs, drivers, downloads and so on. Using the web is much cheaper than manning a telephone helpline and sending out paper copies.

OK, There are some useful places on the web that may be funded by ad. revenue - places like Google, Google Groups and Yahoo Groups. To be honest, I'd pay a _small_ fee for search engines and archives (I'd pay a *lot* for a Cable TV service without adverts too, by the way.)

But personally, I think that the web is too clutered with far too many crappy blogs, geocities pages, band fan pages, lyrics pages, guitar tabs pages, and so on. If these people had to pay for their web space, there would be a dramatic reduction in this crappy content.

People who want to be heard, like Gentoo, Wikipedia and Apache already fund their rather large bandwidth and hosting needs through donations and such like.

If these sites would just take advantage of HTTP Compression and buy some cheaper bandwidth they wouldn't have a problem.

These places are all so uppity they'd never consider anything less than highlevel colocation with high bandwidth costs, or in-house connections. And while that's fine for what they normally do, they shouldn't be complaining about RSS eating up much bandwidth if they won't consider all their options.

Alternately, check out MailScanner for one-stop mail sanitization, virus checking, and spam filtering.

SOAP uses HTTP as a transport layer option (usually). The reason why the added complexity is worth it is because it allows client applications to do things like "float temp = weatherSerivce.getTemp(cityID);" much more easily. (Note: I completely made up that example, but it's similar to what would actually be used.) The point is that the client doesn't really have to know and/or care that "weatherService" isn't a local call. The client also doesn't need to care that it's running Java locally and the server is running .NET (or whatever else it might be using).

SOAP is just a piece of the larger and much more complicated Web Services unbrella. Understanding all of the specs involved is a huge task, but you can do some client-side tutorials that will explain quite a bit of the basics anyway. Most of the real work is done on the server, so if you ignore that bit of it to start with, the learning curve isn't anywhere near as steep. The Apache Axis project is a decent starting point, if you just want to play around with the technology. Installing Axis into Tomcat is about a minutes worth of effort, then you can spend hours exploring the various documents, examples, and tutorials.

What ant are you talking about? Obviously not Ant, right?

I can't be the only one who read this summary and thought "What does AbiWord have to do with the Java-based build tool?"

Sometimes I really hate comments like this. Just how heavy to you think Apache is? With PHP/Perl/Python/Kitchensink support loaded in, sure.

Try loading Apache with just the barest essentials of modules (core functionality in Apache 2). The resource footprint ain't very big. Also, in terms of speed, Apache 2 can use the sendfile(...) API, memory map resources, and mod_cache if you load in support for it. In this configuration, you can easily saturate a gigabit ethernet connection. So unless you've got a gigabit internet pipe, use of thttpd vs. Apache is a moot point.

And besides, if raw web file serving performance is your goal, your script algorithms, internal caching model and judicious use of reverse proxies will make far bigger differences than your choice of web server.

Now then, on to WebDAV. Your comment, "Are there any small, light tools that will just do WebDAV and nothing else, that I can add to my setup?" belies a fundamental ignorance of what WebDAV is. It's an HTTP layer for file handling. By definition, anything that "will just do WebDAV" will need to be a web server. Subversion has it's own transport, but prefers the use of Apache for access to its version control repository. Why? Because Apache handles HTTP well. Why reinvent the wheel?

So in summary, in order to use thttpd with WebDAV, you would need to use thttpd as a proxy to another web server that also handles WebDAV, or you can get someone to write extensions to thttpd so that the WebDAV HTTP extensions PUT, DELETE, MOVE, PROPFIND, LOCK/UNLOCK, etc. are implemented correctly. Of course you would just be rewriting Apache+mod_dav, but suit yourself.