Slashdot Mirror

Well, it's pretty good actually, no need to put Apache in there just for that - it creates an access.log file just the same. Check the Server HTTP Logging help page. Only thing it doesn't do is merge the access logs for you across different servers in a cluster like it can do with normal logs - too much traffic I guess.

Filters appear in WebLogic 7 (they came in servlet 2.3 I think) - you write the class and then mention it in the web app deployment descriptor, e.g. using WebLogic Builder.

Well, it's pretty good actually, no need to put Apache in there just for that - it creates an access.log file just the same. Check the Server HTTP Logging help page. Only thing it doesn't do is merge the access logs for you across different servers in a cluster like it can do with normal logs - too much traffic I guess.

Filters appear in WebLogic 7 (they came in servlet 2.3 I think) - you write the class and then mention it in the web app deployment descriptor, e.g. using WebLogic Builder.

No they don't - check here.

What's much more interesting is that Linux on Intel (OK, and probably Wintel too) is the prime focus of BEA's own JRockit VM.

With Sun, IBM and BEA all investing heavily, the outlook for Java on Linux has never looked better.

No they don't - check here.

What's much more interesting is that Linux on Intel (OK, and probably Wintel too) is the prime focus of BEA's own JRockit VM.

With Sun, IBM and BEA all investing heavily, the outlook for Java on Linux has never looked better.

What exactly is the issue, here? Have you looked at any modern-day JVMs? None of them interpret bytecode on the fly anymore. They all just-in-time compile their code, and can do adaptive optimizations as the program runs.

For a "server-side" JVM, check out BEA's JRockit. I it is available as a free download (registration required). Right now it only runs on Intel boxes (Linux and Windows) though.

What exactly is the issue, here? Have you looked at any modern-day JVMs? None of them interpret bytecode on the fly anymore. They all just-in-time compile their code, and can do adaptive optimizations as the program runs.

For a "server-side" JVM, check out BEA's JRockit. I it is available as a free download (registration required). Right now it only runs on Intel boxes (Linux and Windows) though.

The reason for this is most likely BEA, a company desperately struggling now that it is obvious that the J2EE platform will be commotidized. BEA does not have the Global Services and hardware solutions IBM does, and is really on its way out of the J2EE market. The question that remains is who will buy them: Sun? IBM? Oracle? Anyway you look at it, BEA is a dead company. Sun is still protecting them and responding to their pleas to not let Open Source to compete with equal standing with them. We will see how long that will last.

Java provides the basis of a much more coherent security and concurrency model than Apache 1.x + Unix, and products such as WebLogic, JBoss and Jetty take good advantage of it.

Essentially, the thread serving a user's request has their authenticated ID associated with it, and cannot access any resource to which that ID hasn't been explicitly authorized, e.g. in mappings in the web.xml file. If the resource corresponds to an external file or process, it is easy enough to assign it ACLs in the app server and let the server decide whether / how to run it.

The server itself doesn't need to be root.

For example, see the WebLogic security docs - you probably won't find similar these features in free products now, but with the impressive capabilities that Java 1.4 provides it shouldn't be too long before they appear.

Bea (Weblogic 6.1), IBM(Websphere 4.0) and Oracle (9iAs) are all available for trial downloads.
BEA
Oracle
IBM
I recommend Jboss to my customers..

It all depends.

Web Developer and Web Designer are two completely different things.

If you want to work at a small company, and develop from scratch, learn Perl, PHP, and PostgreSQL. These seem to be the standards. They work well (I have built several sites with PHP/PgSQL), and are pretty easy to learn, plus they are pretty good under heavy loads.

If you want to work for a larger company with more divisions than Einstein, you will need to know Java. SQL of some sort. That's about it.

I wouldn't even bother 'learning' ASP, because truth is truth, it's ridiculously simple, and can be learned in a weekend(besides, it's microsoft!!)

Look at the large sites out there: IBM, Target, and Bluelight.com. They all use J2EE compliant Application servers.

Look at some of these: Art Technology Group's Dynamo, Blue Martini, BEA's WebLogic, and IBM's WebSphere.

Some of these guys even have demo downloads, so you can see what you might be working with. Basically, learn the basics(HTML, CSS, Javascript), learn a programming language(C, C++, Perl, Java) and then start playing with the combination. Good luck, and have fun!!

My guess is the author has never actually admin'd Apache. He's probably been just an Apache user his whole life. (I see nothing to the contrary in his bio at the bottom of the article). Apache is a wonderful tool that is upto /any/ job we throw at it. Jakarta is a great example of a web-services enabling extension to the Apache project.

I'm working on a project to actually do this well. I'm not claiming it's all it can be, but it's better than a lot of the nat. lang. support bits out there.

Can I ask you guys to bang on it for a while if you use WebLogic or Tuxedo or other BEA products? It's at the BEA's support site. It clearly won't answer things like "I just got a computer, what do I do?" but it's not aimed at that. It's supposed to help sysadmins and knowledgeable users like many slashdot readers get to their info quicker. Give it a whirl, eh?

Gremio

And why should anyone ally with Sun and Java? I've read their license and billj's justification for it. Why should anyone surrender their rights in this manner?

What does writing Java software or implementing Java API's have to do with Sun's community license?

There are plenty of Java implementations out there, both commercial and open source, that directly compete with .NET. Yet you never hear any of them mentioned in /. news. Seems the editors are to keen on spreading the .NET hype.

Jakarta
JBoss
Enhydra
BEA Weblogic
IBM WebSphere

IBM had a distributed database project going on back in the System-R days, and they never really got it working. I worked on the Mariposa project at U.C. Berkeley which attempted to solve some of this problem, and it didn't really get that far beyond a data warehousing context. The problem of ensuring that replication along with ownership and transactional semantics were preserved just became too difficult to solve in a purely generic way.

If you're just interested in high availability query processing, the Mariposa work is probably pretty relevant (a company called Cohera tried to commercialize it). If you're interested in distributed transactions, you've walked into the realm of Tuxedo (by BEA systems, caveat, a former employer). While specific instances of the problem CAN be solved, one general purpose system is going to have significant problems, so it's best to categorize what you're interested in solving.

I highly recommend that you dive into the big Stonebraker/Hellerstein book on database system implementation research papers and start reading up. It's a VERY difficult problem. Hellerstein is part of a new project which is also trying to solve some of the problems in a different way.

IBM had a distributed database project going on back in the System-R days, and they never really got it working. I worked on the Mariposa project at U.C. Berkeley which attempted to solve some of this problem, and it didn't really get that far beyond a data warehousing context. The problem of ensuring that replication along with ownership and transactional semantics were preserved just became too difficult to solve in a purely generic way.

If you're just interested in high availability query processing, the Mariposa work is probably pretty relevant (a company called Cohera tried to commercialize it). If you're interested in distributed transactions, you've walked into the realm of Tuxedo (by BEA systems, caveat, a former employer). While specific instances of the problem CAN be solved, one general purpose system is going to have significant problems, so it's best to categorize what you're interested in solving.

I highly recommend that you dive into the big Stonebraker/Hellerstein book on database system implementation research papers and start reading up. It's a VERY difficult problem. Hellerstein is part of a new project which is also trying to solve some of the problems in a different way.

Amazon.com does. So does eTrade and Priceline

Of course, some of these sites might be using more servlets than JSP's, but since JSPs are compiled to servlets there is no performance difference, anyway.

Read Sun's dot-com-builder website on how priceline was built sometime. It's pretty interesting (although full of marketing rubbish).

If you visit TPC.org , you will find that they don't have one benchmark, but rather about four, with substantially different purposes:

• TPC-C is intended to determine throughput of a transaction processing system in creating transactions;
• TPC-H measures performance on what is intended to be an "ad-hoc DSS environment."
• TPC-R measures performance on "business reporting," intended to be more like "typical DSS reports."
• TPC-W measures performance on a "web transaction" workload.

The notion that there can be a comparable benchmark between the databases is something of which people should disabuse themselves.

If you need to have high performance transactional behaviour, I would point out that ODBC is NOT the issue; regardless of whether the SQL-CLI drivers suck, the important point is that neither database fully supports the industry standard SQL/XA or X/Open DTP and XA standards.

Serious transaction systems commonly use transaction monitors like BEA Tuxedo or Encina, interfacing via XA to a relational database (like Oracle, Sybase, DB/2, Sleepycat DB, TimesTen, ...). From that perspective, MySQL and PostgreSQL are both still "toys," although SDTP - A Multilevel-Secure Distributed Transaction Processing System outlines how an XA interface to PostgreSQL was constructed in Common Lisp for use in a set of applications running on FreeBSD.

If you build a benchmark based on an application exercising the strengths of MySQL, it will probably perform badly when used with PostgreSQL, and vice-versa.

Take these systems seriously when they start supporting things like XA, and when BEA makes Tuxedo available for use with them.

First, going with BEA is the right choice on the EJB front. I don't mean to be all conceited, but WebSphere really sucks. In competitive situations, we found that WebSphere couldn't point to a single marquee customer which was using their EJB technology in a production site. Their Servlets and JSPs were okay, and their JMS definitely was better than WebLogic's, but their EJB infrastructure was pretty much unusable. An ironic thing to note here is that one of the largest systems integrators working with WebLogic Server is IBM Services....they don't even pitch their own product for their own customers. That should be a sign of the relative strengths of WebSphere vs. WebLogic on this front.

BEA's technical support people are extremely overworked. It's just a fact of life there after the BEA acquisition of WebLogic that BEA hasn't spent that much on the technical support infrastructure. However, there are two mitigating factors there:

• The actual engineers for the product lines read the WebLogic newsgroups, and regularly post messages. This is probably the best form of technical support you can get. (Take a look at them here )
• WebLogic people have an enormous amount of experience cobbling together best-of-breed systems (i.e. DB from vendor A, App Server from WebLogic, OS from Vendor B), and it shows.

Specifically on your choice of Oracle for the database, I'd recommend that you think again. The Oracle model of concurrency control makes doing serializable transactions damn near impossible for real-world EJB-enabled applications, and you'll find Oracle rolling back your TX_SERIALIZABLE transactions all over the place. Either move to a different DBMS (DB/2 rocks, actually....), mark your transactions TX_READ_COMMITTED, or be prepared for constant rollbacks of far-along transactions at COMMIT time. Unfortunately, there isn't much of an option otherwise, because Oracle does crazy things internally to try to maximize concurrency at the expense of transactional semantics. Think carefully about this one!

In short, WebLogic rocks, DB/2 rocks, AIX rocks, and if you know how to work the system, WebLogic support is the best of the three.

Kirk

bea.com/products/weblogi c/server/datasheet.html

Weblogic has been supported on Linux for a couple of years now - BEA sent me a promo disc when it first came out (I was a Tuxedo consultant) but I haven't had time to evaluate it and compare Linux vs Solaris.
/*He who controls Purple controls the Universe. *