BEA WebLogic Server Bible

RickHigh writes "The BEA WebLogic Server Bible is an enjoyable read. If you have been using WebLogic off and on since before EJB (Enterprise JavaBeans) existed, you will still learn a bunch of new tricks. This is an excellent reference that can be read from cover to cover. The book focuses on small examples with an emphasis of deploying and configuring the examples in the WebLogic environment." BEA's WebLogic is an application server -- as such, it sits in a small enough niche that you won't find a full shelf of helpful books at your local Borders. If hosting applications for a large organization is part of your work, though, you should read on. BEA Weblogic Server Bible author Joe Zuffoletto et al pages 1000 publisher Hungry Minds rating 5 stars reviewer Rick Hightower ISBN 0764548549 summary The WebLogic Bible reference to have on hand.

There are plenty of examples of setting up your WebLogic configuration, with explanations of what the different parameters are and when to use them for Servlets, JSP, EJB, JMS, and more; just what you need when you are having those configuration problems and a great reference to have around when you get stuck. If you like going from concept to implementation, then this is the book for you.

Unlike some other WebLogic centric books, the Bible's coverage of EJB CMP/CMR was good. Also, the coverage of performance monitoring was really well done. And, the ideas for optimization and the thought process behind it was also really well done. These are just a few examples of a really well written technical manual--the missing WebLogic Manual.

A couple areas of concern (some just nits):

1) A few times the examples were WebLogic centric when they could have been written them in a cross platform manner (wrt J2EE ). (Note: A prerequisite of this book is a working knowledge of J2EE.)

2) The EJB examples hard coded the JNDI parameters instead of using the jndi.properties file in the classpath, which is the preferred approach for cross platform J2EE development.

Granted, at times you have to write things WebLogic centric to utilize WebLogic-specific extensions to J2EE, but the book also did this at times when it was not really necessary to do so. A J2EE veteran will catch the difference, and a J2EE novice will not. Bottom line: you should have a working knowledge of J2EE before reading this book and there will not be any problem.

Another problem with the book is that it covers WebLogic 6.1, while WebLogic 7.0 is already out. However, the material is still applicable to WebLogic 7.0. The book was released this year as was WebLogic 7.0. This in an unavoidable problem with books focused on such a target market. By the time they update the 1000-page book to WebLogic 7.0, WebLogic 8.0 will probably be out.

Also, in the next edition they should cover the Weblogic specific Ant tags in addition to the console and other means of deploying applications. Ant is the de facto method for building, deploying and testing J2EE applications, and a book like this should reflect this reality.

If you are new to WebLogic, I suggest that you get this book. If you have been working with WebLogic since before the EJB .8 spec., I suggest that you get this book. This book is not a J2EE tutorial, but it covers the basics and focuses on WebLogic specific areas of concern.

Consider this book recommended.

Links of note:

• WebLogic Bible website
• Books on WebLogic
• EJB 2.0 Tutorial that deploys examples to WebLogic
• Book on building, deploying and testing J2EE components.

You can purchase WebLogic Bible from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Does it cover known "features"?

[FortKnox]

Does it cover Weblogic community known hangups?
Like if you have a large enterprise application running (which is typical if you are running WebLogic), that hotdeploying more than twice tends to cause trouble.
And that its a wise idea to delete the temp directories between restarts, because weblogic likes to keep stuff in memory, regardless if the files/apps still exist?

Stuff like that cause many newbie Weblogic developers hours of confusion. I'd like so see it documented in some weblogic texts.

Vendor lock-in

[MSBob]

Isn't the purpose of J2EE to avoid vendor lock-in? If that is the case then a generic EJB book coupled with the WebLogic manual should do the trick. Otherwise (and that is my suspicion) J2EE has failed to create a level playing field for application server vendors. Personally I'd rather see a good book on how to effectively set up a J2EE development environment using open source tools such as JBoss, Tomcat, Ant, XDoclet etc.

There is a plethora of Open Source tools out there now that help you avoid vendor lock-in by providing a common interface to vendor specific settings (XDoclet) or actually give you a full fledged app server to begin with (JBoss). A book covering those tools would have a much more lasting value. Not to mention a book on good enterprise application design...

Re:Vendor lock-in

[Fnkmaster]

Unfortunately, as your app gets complicated, and you need, most importantly, high performance, you tend to need vendor specific features. And so much is unspecified, and so much just won't work within the EJB framework, that you end up always doing SOMETHING outside the standards in any sufficiently large J2EE application. Weblogic has always been fairly egregious in offering lots of stuff outside the standard and not really encouraging you to do things the standard way.

The thing is though even with the wide array of things covered by the J2EE standard, there are so many vendor-specific tools and vendor-specific deployment descriptors and so on and so forth - there's always a lot to learn and minor changes (a few lines of code and several XML configuration files here and there) to get things up and running on a new vendor's J2EE app server.

My personal favorite is the way EVERY goddamned J2EE app server has a slightly different understanding of JNDI naming conventions: is it java:comp/env or just /env? Blah... at least every app server I've ever screwed with requires you to mess around with JNDI names in different places and never document exactly which form of the JNDI name you are supposed to use where. Pain in the royal arse.

Re:Vendor lock-in

[Kerg]

Personally I'd rather see a good book on how to effectively set up a J2EE development environment using open source tools such as JBoss, Tomcat, Ant, XDoclet etc

You can find JBoss related documentation here, both for free and for pay docs.

Re:Vendor lock-in

[MSBob]

And you recon that's ok? I think that if we have a standard that is so underspecified that half of the spec is left up to vendor's imagination we have no spec to speak of. Unless I can deploy my app on any compliant app server without changing my code (some configuration is OK but not code) the promise of J2EE is a failed one. I do not want to get suckered into Bea's or IBM's upgrade treadmill just because they decided to implement stuff 'their way' or because the spec was underdefined. Sun must get their act together soon and clean up J2EE's grey areas.

Re:Vendor lock-in

[cpfeifer]

Isn't the purpose of J2EE to avoid vendor lock-in? If that is the case then a generic EJB book coupled with the WebLogic manual should do the trick.

Don't make me laugh, my lips are chapped.

But seriously, yes that is the point. But each vendor has it's own little deployment nits. In my own experience, an app will cross deploy between BEA and JBoss with little/no effort. But cross deploying between BEA and iPlanet or WebSphere is a totally different (and far more frustrating) story.

or actually give you a full fledged app server to begin with (JBoss)

This is true, but BEA is the largest player in the app server market and many large organizations that currently are betting big on J2EE have a hard time basing their business on free software. You need someone on the hook when things go wrong. You need guarantees.

Re:Vendor lock-in

[pbur]

This is true, but BEA is the largest player in the app server market and many large organizations that currently are betting big on J2EE have a hard time basing their business on free software. You need someone on the hook when things go wrong. You need guarantees.

Have you ever called BEA weblogic support? You practically have to tell them how to solve the problem. I have never really had anything successfully resolved without coming up with the solution myself. Not to mention they make you buy a support contract for every purchase of Weblogic. That means if you have a 4 CPU machine, you need to buy 4 1 year contracts of support that run concurrently. How crazy is that? They are a required purchase, there's no getting out of it.

One of the many reasons we dropped them like a bad habit.

Re:Vendor lock-in

[MSBob]

You see the purpose of J2EE was to free you from having to always shop from one vendor. If that promise remains unfulfilled then what is the incentive of sticking with j2ee over .NET? I mean either way you're tied to a single vendor. At least with .NET you'd have the assurance that the vendor isn't going away in a hurry...

My initial point was that we need books that educate people on how they can avoid vendor lock-in so their apps deploy with minimal effort. There is a lot of (mainly Open Source) tools out there that help you get there but there isn't a hell of a lot in terms of a guide of how to pull it all together but I think with stuff like XDoclet and Ant most pieces of the puzzle are already on the table. Now there must be more effort to educate companies and their development teams that they can write J2EE apps that are vendor independent.

Re:Vendor lock-in

[cpfeifer]

That means if you have a 4 CPU machine, you need to buy 4 1 year contracts of support that run concurrently. How crazy is that?

I agree with you, but Management(r)(tm) eats this stuff up with a spoon as "cost of doing business."

Either way it doesn't matter to me, I just want a fast java app server that always works and doesn't provide any surprises. If JBoss suits your needs, use it and keep your money in your pocket. If the suits want name brand parts, show them the price tag and hold out your hand.

Or better yet, show them the two price tags (BEA vs. JBoss) and ask them to pick one.

Re:Vendor lock-in

[j3110]

There are no books because it's that d***ed easy :) Create your standandard ejb-jar or .ear or .war, and copy it to the deploy directory of jboss. That's it, you're done. You don't need the custom jboss.xml file AFAIK, it's only there for tuning performance. You can buy all the JBoss documentation from their site for 30$ or so. That will teach you to use things that haven't made it to the spec yet. JBoss supports Dynamic-QL, which is EJB-QL that is dynamically compiled. It's not part of the spec, but its just the natural progression of the standards. JBoss does this kind of thing quite often, and one would think that it would make them less J2EE compliant, but really, this is why they are usually the first to comply with a new standard. They begin implementing features while they're still in JSR's and sometimes they spawn a few good ideas themselves.

BEA's weblogic comes with a plethora of tools that few other app-servers do. You won't need a book on how to use it, but maybe how to get the most out of it, since it costs 1000's of $/CPU.

Then there is websphere. It's a documentation magnet. If you looked in a bookstore, you'ld think they were #1, but few new people are going there. I haven't met a person that said setting up web-sphere for their project was any less than a weekend project.

I would love a GOOD book on J2EE design. I'm not much of a subscriber to patterns. (They all seem to be obvious solutions for a given problem. Why not refer to them the old way, by the problem they solve.) I've read a few books, but they read like instruction manuals, cook books, and how-to's. Most of the chapters are titled "Setting up ____", "___ and J2EE", or "How to ____ with J2EE". I'm looking more for a point by point coverage with example code of what each class/interface/file in J2EE does (a technical manual) with best use cases that aren't obvious (session facade, etc.).

Re:Vendor lock-in

[gorilla]

J2EE is a standard for what an application server should provide. However, it doesn't say anything about how the app server should provide it. In particular, the administration is wide open. This is quite similar to webservers. We have CGI which says how the webserver should interface with the program, but there are lots of different ways that the server can be implemented, and admined. If you write a program using CGI, you can be sure it will work on any server which supports CGI, but there are still books on how Apache is configured. This is no different.

Re:Vendor lock-in

[SimonK]

Many people buy Weblogic. Many people who buy it also ignore it and then develop and deploy on JBoss because it is less painful. Just like many companies that have an official policy to use WebSphere find many of their applications being deployed on Weblogic.

Re:Vendor lock-in

[cpfeifer]

Just like many companies that have an official policy to use WebSphere find many of their applications being deployed on Weblogic.

Now that's shelling out the big bucks. I don't know many orgs that could afford lic's for 2 different app servers, no matter how many of each there are deployed.

Either that or they're downloading the demo versions and reinstalling each month. =^)

Re:Vendor lock-in

[toriver]

Have you ever called BEA weblogic support? You practically have to tell them how to solve the problem.

No, eDocs has answered all my questions. :-)

I wish more companies would take the cost of putting all their docs online, like BEA and Oracle do...

Small niche ?

[MosesJones]

$819.8m revenue in a year is not "niche" in my book. Slashdot editors yet again demonstrate their inability to understand that the corporate enterprise market is a billion dollar industry which contains lots of professionals for whom "cool scripts" "Perl" "PHP" and "MySQL" exist only to cause issues.

The Application Server market is over 2 billion dollars a year.

Niche my arse

Re:Small niche ?

[Nadir]

>Niche my arse

Well, I guess your arse may be a niche :)

Re:Small niche ?

[silversurf]

I don't think they meant "small" in terms of revenue or application size, I took it to mean size of deployment. The number of WebLogic users is relatively small because the number of possible customers is relatively small, they just pay alot of money for it. Sure the Enterprise Application Server market maybe 2 billion a year, that doesn't mean a company that makes products for it isn't in a niche. Niche just means you specialize for a specific industry and market and nothing else.

-s

weblogic... so much potential

[Anonymous Coward]

having worked with them in the past, we had to decline the use of their system simply because they were making the same exact mistakes as so many before them have. We needed their system as PART of an integration solution. However, even though they spouted more buzz words that we liked (like: :open and published standards", "data, logic and presentation abstraction", "platform independence" (sorta), and "component based for easy integration") we found that in fact many of the parts were very hard coded. We even found that in order to add some custom or third party components (mainly servlets) that did various things to the entire system, they said it could only be done if we set up either a separate instance of Apache (and Tomcat) or an entire separate system. According to them, it was an issue that the components could not be added to. Hmmm, sounds like a bad design to me. Well, they lost a ton of money and I sincerely hope they have produced a true component system that can interchange now. In other words, if I need or want to use another component to do some functionality of one they offer, then I should easily be able to switch them out.

If they have made their system like that, then I would be happy to use it in the future (instead of custom coding under a tight schedule)

I love Java...

[Fnkmaster]

I love Java as much as the next guy. Well probably even more. But if I never have to touch Weblogic again, that'll be too soon. I know, I know, 6.1 ain't so bad, and I've been away from this POS since before 7.0 came out, but I was one of the serious victims of Weblogic 5.1. Worst piece of commercial software ever - I had an engineer on my time who was devoted for about 2 weeks to being on the phone with BEA to make sure their next SP fixed some serious issues with non-J2EE compliant transaction handling that broke our entire product.

Frankly, with JBoss 3.0 out, if you do need EJB support in an application, that's a great place to start - 3.0 supports clustering using the excellent JavaGroups system, and this was the MAJOR weakness of 2.x vs. Weblogic.

And as somebody with more J2EE experience than I would care to admin, you might really want to think about whether spraying EJBs all over an application is the best architectural solution for the problem at hand. Not every "enterprise class web application" needs EJBs. Can you and will you use CMP? If so, then it's worth it, but REALLY make sure CMP will work for your app (by the way, strong CMP capabilities are one area where Weblogic may still shine more strongly than JBoss). Do you need and will you use declarative transactional boundaries? These can certainly come in handy, though you can take advantage of them with session beans, no need to use bulky entity beans if you don't need them.

By the way - one important thing I should mention - as of 6.1 JBoss was still 2-3x faster than Weblogic 6.1 for all of our applications at my company. YMMV though, depending on the nature of what you are doing, and these weren't formal benchmarks. 7.0 may have finally solved their performance issues - I don't know though, and with my past BEA experiences, I don't think I ever want to know.

Re:I love Java...

[pbur]

I too love Java. I too hate weblogic and think it is the worst piece of overrated and overhyped software on the planet. Our new preference is Jrun 4.0 (it has quirks, but much better document than JBoss 3.0. At least to me) Lightweight and fast. Runs our stuff in half the time of Weblogic.

And you comments on EJB are pefect. Our project invested heavily into Entity Beans and we paid a nasty price. We ended up having to rewrite large sections to do their own database work ( under the transaction of a Session Bean ) instead of using Entity beans. They are DAMN slow. And by looking at the Entity design, it seems to be built in to be DAMN slow. We have pretty much gone with just Session beans to do transactions for us and do everything with the database ourselves. That way tou can do a million inserts or updates in a second or 2 instead of hours using techniques not available with Entity Beans.

Re:I love Java...

[borzwazie]

Lord help you if you install BEA Portal - that piece of crap changes your startup time from about 45 seconds to around !6! freaking minutes.

Between the startup times and the constant CR patches it's madness. I will say that it's nice to be able to call and talk to a person instead of just email support, though. I pity the fools on Metalink.

Re:I love Java...

[Black Perl]

Jrun 4.0 is EOL.

Can you provide proof of this? Or is this conjecture?

Should be a good read.

[bdowne01]

We use WebLogic 6.1 heavily on our production website.

We inherited the platform from another development team that was married to MS, and hence put WebLogic on all Win2k servers. On this platform, I've found WebLogic to be stable--but quirky. Getting things tweaked to your liking can be a little strenuous.

We're toying with the Linux version of Weblogic, the biggest plus being that it forces our developers to write code that drops to log files (right now they insist on using Weblogic running in DOS boxes interactively on the desktop(!!!) so they can monitor it realtime).

Early testing is going well, hopefully having a book like this will make the transition a bit easier. I like BEA for supporting the Linux platform, though their support for problems is a little touch 'n go.

Re:Should be a good read.

[bdowne01]

They're square, have a C:\ prompt in there.

I call the DOS boxes.

Fine, fine, "Command Prompt" Windows. Same diff. :)

Re:Should be a good read.

[bdowne01]

Yea, I'm all for that... 'cept the Deveopers are lazy and they don't drop stuff to log files (I'm serious!)

So you think WebLogic's bad, huh?

[MSBob]

That's cuz you haven't tried Websphere yet. That's a piece of junk if I ever so one. Overpriced, overhyped and underachieving. They shipped WS5.0 saying it's a EJB2.0 app server but... they did not implement CMP2.0! I mean give me a goddamn break! The main difference between 1.1 and 2.0 is the new CMP stuff! Eclipse rocks but Websphere app server is a steaming pile of crap.

Thoughts on Weblogic

[pbur]

The organization I work for has just dumped weblogic in favor of Jrun mostly because Weblogic was too bloated and needs to be restarted too often for the simplest changes (like adding a database connection). Not to mention its price. At $15k/CPU, it's a bit pricey and Jrun does all of it at a much lower resource footprint and less restarts (actually, not many at all) for only $1k/CPU.

Pbur

Niche?

[oops]

as such, it sits in a small enough niche that you won't find a full shelf of helpful books at your local Borders

No. But you will find books on servlets, EJBs, JNDI, JCA, JDBC etc., all of which are of use in app servers. App servers (rightly or wrongly) are the big thing in large enterprises right now, and by no means are they any sort of niche.

Weblogic & JBoss

[signe]

I'm actually in the middle of load/performance testing WebLogic and JBoss right now, and I'm suddenly realizing how pointless this is.

Say our server hardware costs $6k. To use that box with WebLogic, it costs $40k total (hardware + 2 licenses because it's dual-CPU). To use that box with JBoss, it costs $6k (just hardware).

It doesn't matter what the performance is. JBoss would have to perform incredibly poorly for it to be worth using WebLogic instead, because I can deploy 6 JBoss servers plus load balancing hardware for the cost of a single WebLogic server. So where WebLogic does 400 ops/sec for a particular load configuration, JBoss would have to do about 65 ops/sec to "break even". As it is, JBoss does about 300 ops/sec for the same load config.

Now if I can just convince the developers that no, they do not *have* to have WebLogic...

-Todd

Re:Weblogic & JBoss

[glwtta]

hmm, I am not going to go into WebLogic vs. JBoss (ok, I like JBoss), but it seems your developers are at least used to, or maybe even like WebLogic... how much is your company paying for their time? It's always something to consider.

Re:Weblogic & JBoss

[puppetman]

We've been running with Weblogic for about 4 years now. We are currently looking at moving to Resin, for the same cost-per-licence issue.

Weblogic is a great App server, but the costs are ridiculous. Oracle is a great database, but ditto on the price.

PostgresQL or MySQL, and Resin hopefully in 2 years.

Re:Weblogic & JBoss

[iabervon]

Just tell them that JBoss actually implements the specs correctly and doesn't take forever to compile your application. We switched to JBoss and the time it took to make the switch was probably recovered in the next two weeks in the shorter build cycle.

The main thing you have to deal with in going from WebLogic to JBoss is that WL supports a number of intermediate and non-strict versions of EJB, and JBoss is a pretty strict implementation of the final versions. Also, there are a number of mistakes that JBoss doesn't give useful errors about, which makes switching annoying.

Re:Weblogic & JBoss

[mgkimsal2]

The Tomcat effort had to be somewhat "under the radar" whereas the WebLogic could be banner headlines.

Cause you don't want to piss off the vendor of the pricey product. If you piss them off by publicizing how much a free version does, you'll not get the same level of support/helpfulness from them. They'll do the bare minimum to keep you, as opposed to going the extra mile to help out when you need it.

WebSphere 5 shipped?

[Software]

According to this page, WebSphere 5 hasn't even shipped: "Install V4 now and be ready for V5 when it becomes available." I did a search for downloading V5 software, but they only have "preview" versions.

Does IBM not plan to support CMP 2.0 in WebSphere 5?

Re:WebSphere 5 shipped?

[MSBob]

I guess they do but when it will happen is anybody's guess. I got a cd from them that didn't claim to be a beta and it did not have CMP2

Weblogic 6.1 better than iPlanet at least...

[SuperKendall]

We moved from the iPlanet app server to Weblogic 6.1 about a year or two ago and are so far pretty satisfied.

Weblogic is WAY easier to use than iPlanet, and also a lot more stable...

That said, we have had some Weblogic issues. I'm trying to convince the company to think about running JBoss in some areas, but so far they are very reluctant to move away from Weblogic. TCO, stability, ease of use, all arguments fall on deaf ears who are fearful of using an "open source" solution.

The really funny thing is they bring up again and again - "If it has a problem who will fix it?", when we've had one ongoing crashing problem (where the VM coredumps) with Weblogic that's lasted weeks!! Good thing we have an app server with a dedicated team of people to "fix" things. (Never mind that JBoss also has such a team, only a more responsive one!! Or that I could fix something myself if I have the source!!!).

The issue is not hardware or software costs

[mikael]

I have been using WebLogic since 6.0, and I am under heavy pressure to make the switch to JBoss. The problem is just that THE DOCUMENTATION SUCKS.

If you are working for free and have the time to look into the JBoss code, it might be ok. But for everyone who loves great documentation and standards compliance, there is no need to look back from WebLogic. I need SOAP access to my system, and there is no documentation whatsoever from JBOss. Guess if there is an entire book devoted to this in WebLogic?

When JBoss gets proper documentation, I'll be the first one to make the switch.

Re:The issue is not hardware or software costs

[fishbowl]

Did you buy the PDF Book for $10?

Is this the documentation that you say, sucks?

http://www.jboss.org/docs/

I found it far better than what we got with Weblogic!

Re:Can someone please explain...

[Fnkmaster]

Well, the J2EE "platform" does provide some very useful services that are more than a library, and pieces of which define how your application is actually deployed and operated -- thus the need to run it in what is now called an "application server".

The parts that I think are useful of J2EE:

1. JNDI - Java Naming and Directory Interface. If you've built a large application that involves many parts that need to cooperate in some way with each other, you've faced the problem of trying to avoid hardcoding hostnames/ip addresses/port numbers/communication mechanisms/etc. JNDI is a good way to find services on a network, allowing them to be mobile and redeployable. Not anywhere near as good as JINI, which has unfortunately never caught on like it should have in the corporate world, but JNDI is decent.
   
2. JMS - The Java Messaging Service API is a decent wrapper API for queue-based and pub/sub messaging. This is a generally useful paradigm for networked applications that operates at a substantially higher level than mucking around with TCP or UDP packets directly. Applications can be interfaced over a JMS-compliant messaging system focused entirely on semantic content connection, you don't generally have to worry about deciphering packet level details, etc. A good timesaver. The weakness is that many real enterprise class messaging systems (TIB Rendezvous and Talarian for example) have lots of juicy features that fall outside of the lowest-common-denominator JMS API. These either require that you use some extensions to JMS provided by the vendor, or lots of configuration, or you use the vendor's non-JMS API in the end, having wasted effort with JMS. In other words, if you need the speed and power of TIB RV or Talarian, you'll need to stray outside of JMS to get it, but porting a JMS app to these powerful vendors when you are already using JMS is a true breeze and has saved me hundreds if not thousands of hours of time.
   
3. EJBs. These are a sometimes overhyped application development model. The real core of most application servers is an EJB container and deployment environment. EJBs provide declarative transaction management (i.e. set up transaction boundaries for method invocations that auto-commit database manipulations and auto-rollback in the case of failure). EJBs also CAN provide easier interfacing of the object/data layer of your application to a persistent database, but this depends greatly on how often and when you need access to that data. The EJB model makes it easy to make dumb mistakes in how you model your data, and to destroy application performance with slow DB access. At least it did early on when people took the EJB model as something to be used whole hog. These days most decent apps that use EJBs use entity beans sparingly for read-mostly application data, and use custom session beans for high throughput data-writing.
   
4. Theoretically simple load balancing and scalability. The EJB model and EJB-compliant app servers are supposed to make enterprise apps scalable by EJB clustering. This can sometimes work well. In other cases it does not. Unfortunately, my biggest criticism of the EJB model is that it was in NO WAY designed for distributed computing, and makes no attempt at the specification level to address how clustering of these resources should work, and how various kinds of work can be partitioned effectively in the EJB model. If you have real computationally intense or IO intense work to do, think very carefully about how it will be modelled before you get too caught up with EJBs.
   

I can't think of much else off the top of my head, and if none of this sounds useful to you, then you've probably never worked in the awful realm of enterprise software development, and you probably have no need for an application server.

Re:WebLogic re-evaluated

[codepunk]

Let me add one more,since weblogic is notoriously buggy

5. Stability

Re:zope

[codepunk]

I tried zope and I really wish I could bring myself to use it. It does however have one very FATAL FLAW (DTML). I just do not have time to dork around learning yet another tag language. Zope would be one of the biggest app servers around if it was not for the DTML bullshit.

Why app servers are such a pain

[samwhite_y]

Nobody seems to be addressing some of the real painful spots in the current app server architectures. Jboss seems to do a better job of addressing these issues then other app servers, but I do not have the luxury of that choice.

First, how are you supposed to do development in an environment where it takes almost a minute to restart the application and find out if your latest change is working properly? That type of coding harks back to the dark ages of coding when you had to wait minutes before the compile and run was finished. There are kludges for creating "simulated" app server environments that give you faster development times, but that can only take you so far.

Secondly, it is practically impossible to create a distributable self-installing application that installs with no fuss into an app server environment. I am amazed that people are willing to put up with the configuration headaches for delivering app server solutions that they would never accept for their desktop applications.

Thirdly, there is a constant confusion surrounding issues like "session" and "non-session" beans, maintaining "transaction compliance", and whole hosts of finagle issues. Many of these issues have a drastic impact on performance depending on your choice, and usually the choices that give sufficient flexibility and acceptable performance are only available with completely proprietary vendor specific solutions.

As far as I can tell, the original vision of having easily developed, easily deployable, and high performing server-side application solutions has been lost and has been replaced by an environment in which it is difficult to create code, painful to deploy solutions, and a real headache to tune for speed.

This is such an unfortunate fate for EJBs. In the original vision, EJBs were to be the server side equivalent of Microsoft's ActiveX controls for the desktop. There are still some good ideas buried in the EJB specs, but the heavy weight app servers have buried these little nuggets inside massive overachieving bloat ware.

Nice wording there

[Earlybird]

• If you have been using WebLogic off and on since before EJB (Enterprise JavaBeans) existed [...]

Oh yes, I remember those golden days of yore when EJB actually existed. Those were the days, eh?

Re:Nice wording there

[Earlybird]

The point is, as I'm sure you yourself admit somewhere in your loopily informal writing, I don't think many people used EJB before it existed. Last I checked, causality still applied, even to Sun Microsystems. Anyway, I hope you'll forgive my innocent little bit of linguistic mockery.

Re:Nice wording there

[Earlybird]

If I didn't take you literally, there wouldn't be a joke, would there? :) So I definitely get the gist of your story submission.

I'm down with a fever and had nothing better to do than deconstruct your sentence, sorry. Wish somebody had modded me up as funny, though. ;)

dedicated team of people

[KyleCordes]

If you take the amount of money that it costs to set up WAS or WL on a cluster, counting the support contracts etc., divide it by two, then wave it at the JBoss people, you are likely to get extremely intensive hands-on help from the people who wrote the code you are having trouble with.

Re:dedicated team of people

[SuperKendall]

Pretty much exactly what I told management (as with any WL company, our WL support contracts are extensive)!! But still, no luck.

If I ever get my own company off the ground, I know which solution I'm sticking with...

---> Kendall

$1000 a day

[KyleCordes]

Maybe you probably weren't paying enough. A top-notch BEA Weblogic consultant able to make the thing really sing, could cost well over that figure.

You switch to JBoss

[KyleCordes]

Lots of people are doing it, especially for development.

It's really a rather good way to go. Jboss for development will keep your cycle fast and keep your code very close to the specs (as it should be); then if you want to deploy to something else, it will be relatively painless.