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.

Re:Does it cover known "features"?

[nigord]

Or that sometimes EJB wont deploy for any reasons??? I had a case where 1/10 times, weblogic would complain that it cannot find an EJB. The only solution I found is to go to the console, redeploy that EJB... restart... Just restarting wont do the trick :( But I am buying the book anyway, been waiting for something like this for some times....

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

[Anonymous Coward]

is it java:comp/env or just /env? Blah...

It is java:comp/env. Everything else is just plain wrong, you should avoid using any app server that allows a lookup using any other format.

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

[JSR $FDED]

WebLogic offers a tool similar to XDoclet, except that it is specialized in WebLogic and covers the latest (WLS7) extensions:

http://beust.com/cedric/ejbgen

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

[Anonymous Coward]

No, you don't buy '4 1-year contracts of support' if you have a 4-CPU machine. Weblogic (and Tuxedo, for that matter) licensing is based on a tier system. A 4-CPU machine falls into a certain tier, and you pay a set amount based on the hardware and the number of seperate Weblogic domains on that machine: it's one support contract, one license, not four.

Re:Vendor lock-in

[RickHigh]

There are books that do exactly what you are saying.
Java Tools for Extreme Programming (Covers Ant, JUnit, J2EE development issues AND was number one under Software Development on Amazon for three months this year).
and
Java Development with Ant (Cover XDoclet)
come to mind....

If your interested in XDoclet (as you stated) check out this FREE multipart tutorial series that covers XDoclet, Ant doing EJB Development. EJB with XDoclet Step by Step based on earlier tutorial that has WebLogic and JBoss examples with XDoclet http://www.rickhightower.com/ejbcmpcmrtut.html. Also, I wrote two chapters in the upcoming book that covers Struts, XDoclet and Ant on Tomcat
Mastering Tomcat Development from Wiley . I wrote the chapter on Struts and the chapter on Ant/XDoclet for the Tomcat book. The Struts chapter rewrites a model 1 JSP based application to be a model 2 based Struts application (it uses XDoclet). The Ant/XDoclet Chapter has examples of using XDoclet for Custom Tags, Struts, Servlets, EJBs and more.

The books you are asking for already exist.... These are but a few examples. I don't think having books on these topics excludes having a book on weblogic. The world is big enough for both.

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...

Re:Vendor lock-in

[RickHigh]

I have always heard good stories about WebLogic support. Maybe you just got the wrong person.

Re:Vendor lock-in

[myawn]

J2EE does allow you to write code in a way that avoids vendor lock in. I would say it's much easier to do in J2EE than in almost any other environment, but it still does require some forethought.

Case in point: I developed some code that was originally deployed in Tomcat. When I moved the code to BEA, it failed to run (or even compile). It turns out that I used a data type (String[], an array of strings) in a JavaServer page that was not one of the data types that JSP containers are required to support. But, the spec doesn't say that you must reject any other data types -- so Tomcat is perfectly right in allowing this construct, and BEA is perfectly right in rejecting it. So there is a grey area that programmers must be aware of if they want to maximize portability.

Sun has created an Application Verification Kit (AVK) that should help identify these types of issues -- think of it as lint for J2EE objects.

Also, if you're looking for a book covering developing for J2EE using open source tools (Ant, Tomcat, Struts, etc.), I highly recommend J2EE and JAX: Developing Web Applications and Web Services. It is, without qualification, the best book I've ever written on this subject :-). More info is also available at http://www.theYawns.com

Re:Vendor lock-in

[RickHigh]

"It is, without qualification, the best book I've ever written on this subject :-)." I admire your shameless plug... LOL

Re:Vendor lock-in

[Anonymous Coward]

I worked at BEA for two years (I quit about a year ago) as a developer on the EJB container.

I dealt with the Tier 4 support (aka "CCE": Customer Centric Engineering, the highest level (technically) of support); whenever they'd file bugs against our code.

I've never seen stupider, more useless bug reports. "EJB don't work" was my personal favorite bug report title (the description field was equally useful).

I shudder to think what the people who triage MS Windows bug reports must see everyday.

Online tutorials and such?

[fluor2]

I'm currently looking into PHP and MySQL, since the Microsoft ASP servers are so expensive to put on the net. But even if this book is very cool and such, I miss some plain old tutorials that explains simpler Java examples. I know JBuilder comes with weblogic (or was it another EJB-compatible server?), anyways, configuring tomcat and all that still makes the platform a little hard for starters like me. I miss compiled html files format help guides (the PHP manual already exist in .chm). Anybody know anything here?

Re:Online tutorials and such?

[hoover]

Have you looked into Zope? It's well documented (the "Zope book" is freely available on the net), open source and has a great developer community to help you along in your first steps.

Ummm FYI, tim

[Anonymous Coward]

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.

It should be noted that WebLogic is a J2EE app server, so if you are hosting Java/J2EE applications, you should read on.

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 ?

[Anonymous Coward]

Its as much of a niche as Java is.
Yeah, I wouldn't exactly call it a "small" niche, but it IS a niche.

Re:Small niche ?

[Nadir]

>Niche my arse

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

Re:Small niche ?

[Hooya]

Niche my arse

Well i certainly do hope your arse is a 'small 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

Re:Small niche ?

[Anonymous Coward]

I believe BEA quotes the figure of a 13,000 customers. Now, multiply that number by 3, and we're talking 39,000 installs on the corporate side.

Then, you have your 2% or so of home users (hobby, open-source development, etc.) and we're only to 45,000-ish. That's still quite small to say, Oracle or SQL Server -- but now we're comparing apples to oranges.

Nevertheless, the quality of an application server (or for that matter, any software) should not be measured by installed base numbers -- rather by the reliability, performance, and ease of integration within existing environments.

Re:Small niche ?

[liloldme]

If we are allowed to make some generalizations and assume that the original author was your stereotypical overweight geek then we may say it is not a small niche though.

Re:Small niche ?

[liloldme]

OTOH, Weblogic isn't the only J2EE server around, they have maybe 40% of the market. Plus, JBoss reports about 100,000 downloads per month on average.

what gives?

[ideonode]

A few times the examples were WebLogic centric when they could have been written them in a cross platform manner

The name of the book is BEA WebLogic Server Bible, and the reviewer is complaining that it's too specific to BEA? Eh?

Re:what gives?

[dancornell]

I believe the "cross platform" comment would be better interpreted as "between development and deployment platforms" Hard coding things like JNDI properties is guaranteed to cause troubles when you move your app from one developer's machine to another or from a test environment to deployment.

The point is that code examples should employ best practices so that people who are learning new technolgies learn to use the correctly from the outset.

Re:what gives?

[RickHigh]

Huh???? I was not complaining. I gave this book a 5 star rating, and said if you are doing weblogic get this book..... I was stating a fact. I can disagree with an approach and still like a book.

Re:what gives?

[RickHigh]

The point is that code examples should employ best practices so that people who are learning new technolgies learn to use the correctly from the outset. BINGO.... wait 20 seconds before post... Hmmmmmmmmmmmm.... that is exactly what I meant.

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)

Re:weblogic... so much potential

[old-lady-whispering-]

the word of the day is dumbass. Can you say dumbass. You probably never installed Weblogic. I have used it for 3 years and am currently upgrading to 6.1(am pleased with the functionality). You should be able to alleviate your ingnorance by reading up on jvm's java servlets, ejb's and yes read the bea bible. Then you won't sound like such a dumbass. God why do people post such ingnorant crap

Re:weblogic... so much potential

[RickHigh]

Your post is mean and evil.... but.....

I read your post, and I laughed so hard my eyes teared.

People have opinions whether there informed or not. Thank you... you made my day.

Re:weblogic... so much potential

[Anonymous Coward]

I have never been hit by a buss crossing a road, so it is logical to assume that I nor anyone else ever will.

Perhaps I should have been more explicit. We worked _with_ the engineers and designers of WebLogic and it was they who told us that we could not use the system with a proxy solution (a small one at that, consisting of some servlets and perhaps one of the various proxy mods for Apache). Again, this was early on in the design phase and we were still very open to change and modification. However, every way it was approached they told us that we would need a duplicate machine for a very small purpose (performance and badwidth wise).

I am glad you find it useful. Some people find Windows NT very useful and secure. Considering we told them what we needed and what the parts were and their only solution was a very static system that we could not interchange various parts of the basic functionality much less add to with what we needed, then it is either their system that was the problem or them. If you post here sometime that you worked with MS and were told you could not use any HTML on MS systems then who's fault is it then?

Your obviously angry, so I will not post much more. Perhaps someone just needs a hug? You sound like you are defending something that either does not need defending (like a mindless animal or zealot would do) or perhaps... who knows? I am reminded of how monkeys in sports bars will literally get pissed and try to fight if someone says they actually are a fan of another team. I suggest a rabies test.

This is a karma whore/troll

[Anonymous Coward]

I'm currently looking into PHP and MySQL, since the Microsoft ASP servers are so expensive to put on the net. But even if this book is very cool and such, I miss some plain old tutorials that explains simpler Java examples

PHP and MySQL has nothing to do with Java. Using open source buzzwords to get karma

I know JBuilder comes with weblogic (or was it another EJB-compatible server?),

Comes with Borlands home-built app server.

anyways, configuring tomcat and all that still makes the platform a little hard for starters like me.

Tomcat isn't a full-fledged J2EE server (tomcat only handles servlets and jsps. NOT EJBs).

I miss compiled html files format help guides

Most app servers (Weblogic included) comes with these.

BET WebLogic Server Bible

[McFly69]

When I first read it, I thought it said "BET WebLogic Server Bible." First thought came to my head was.. wow Black Entertainment TV has its own Bible now.

Yes I knwo it is off topic but wanted to share my thoughts.

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...

[Anonymous Coward]

Jrun 4.0 is EOL.

JBoss is the only safe choice.

I find it interesting that open source vendors are the only ones that remain and everyone else is dissapearing in the app server business.

Re:I love Java...

[glwtta]

Not every "enterprise class web application" needs EJBs

a-fucking-men!

Re:I love Java...

[mrmcfad]

You're blaming WebLogic for using Entity Beans? It's a known best practice to use Session Beans as a facade to a data layer rather than use Entity Beans. I've had a positive experience using WebLogic 6.1.

Re:I love Java...

[Black Perl]

Jrun 4.0 is EOL.

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

Re:I love Java...

[Anonymous Coward]

Frankly, with JBoss 3.0

I'll use JBoss when I can get a decent set of documentation on how to run the damn thing. You know how to set up things like database connection pooling. The Administration and Developement docs are jus JBoss internals. Point me at the correct set of docs and I'll give it a shot. Untill then bugger off.

And don't give me this subscribe to the mailing list either, I'm on so many mailing lists right now I have to set up filters and subdirectories just to keep crap sorted.

Re:I love Java...

[Anonymous Coward]

Were you at the meeting when we made the Weblogic sales rep cry?

That was funny

Re:I love Java...

[Anonymous Coward]

You know how to set up things like database connection pooling.

Why, you having problems doing a simple copy & paste of the several example XML snippets provided with the distro? Are you stupid?

And don't give me this subscribe to the mailing list either, I'm on so many mailing lists right now I have to set up filters and subdirectories just to keep crap sorted.

boo hoo hoo, cry me a river.

Re:I love Java...

[Anonymous Coward]

I'm with you, man.

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.

[Anonymous Coward]

They are not DOS boxes.

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.

[Anonymous Coward]

Ughh...why not:

% tail -f weblogic.log
...or...
% tail -f wl-domain.log

Works for me!

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!)

Re:Should be a good read.

[clockwise_music]

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).

I'd recommend going to Log4J for all of your output. Makes it quite easy to dump everything to a nice log file, zip it each night and take it off the production server. If the only reason you're moving to linux is so you can use better logging capabilities, it sounds like you're wasting your time. Having said that, I used linux (and hpux) and weblogic, and ended up starting/stopping it from the command line. Very useful for examining startup/shutdown error messages real-time.

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.

Borders plug?!

[Danborg]

I can't believe timothy mentions Borders in this article... I thought all Slashdot automatons were required to plug Think Geek at all times?

Re:Borders plug?!

[RickHigh]

No Margin.... No Mission (Wait 2 minutes) Money runs the world http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF -8&q=%22no+margin%22++%22no+mission%22

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

[Anonymous Coward]

Care to publish your methods and results?

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

[FigWig]

In your calculation you should also factor in hardware maintenance. If you had to run more servers for equal load with JBoss, it would cost more initially to purchase the hardware, but your monthly hosting/maintenance/support costs would be higher also.

You are likely correct about JBoss being a much cheaper solution, just make sure you factor in all the costs.

Re:Weblogic & JBoss

[mrmcfad]

In my experience it isn't developers you have to convince but management. They consider it CYA to have a big name vendor to call upon in times of trouble. I've used Tomcat and WebLogic at times. Both worked great and support from each was terrific. The Tomcat effort had to be somewhat "under the radar" whereas the WebLogic could be banner headlines. Go figure....

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.

WebLogic re-evaluated

[Anonymous Coward]

We are seriously considering and are currently evaluating JBoss, after less than two years with WebLogic. Motives?

We are not satisfied with:
1. Licence costs
2. Performance
3. Support costs
4. Easy of use

Preliminary data looks good for JBoss.

Re:WebLogic re-evaluated

[codepunk]

Let me add one more,since weblogic is notoriously buggy

5. Stability

Can someone please explain...

[bayankaran]

Why do we need an application server and in what circumstances an application server is worth?

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.

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

Re:WebSphere 5 shipped?

[Anonymous Coward]

Get with the program MSBob. WebSphere 5 has not shipped. It will not ship until November. If you would carefully read either the label of your CD or any of the IBM website you would find out that it has not shipped...

Re:Get some PRIORITIES!

[pmz]

More people probably died from cancer or auto accidents in the last five minutes than died on Sept. 11. Where are your priorities, Anonymous Coward?

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

[KenSeymour]

Did you try the documentation they charge money for?

I am curious myself because I am considering using JBoss.

Re:The issue is not hardware or software costs

[Anonymous Coward]

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

whine whine whine

well SOAP isn't part of the J2EE spec yet, moron. As for compliance, even BEA admits that JBoss is one of the best servers out there if you're looking for standards compliance.

Re:The issue is not hardware or software costs

[beanball75]

You might want to look it up on Amazon (the dead-tree book) and read the reviews. It's not exactly a "how-to" document.

I've had to rely heavily on trial-and-error and the forums to get everything working.

Re:The issue is not hardware or software costs

[Solaristrum]

The article you point to at OnJava is over 18 months old - that is ancient history in the enterprise computing world. BEA has consistently been one of the earliest adopters of new J2EE technologies providing EJB2.0 implementation before the spec was even final! You are right that SOAP is not a J2EE spec (and it won't be) but Java APIs for using SOAP already exist (JAX-RPC being the main one) and will be incorporated into J2EE 1.4. WebLogic server 7.0 provided JAX-RPC support before that specification went final and has been supporting SOAP and web services since WebLogic 6.1. If you want to be on the cutting edge of new technologies use WebLogic, if you are willing to sit around and wait for an app server to be built after the specs have been finalized (6-9 months for JBoss, 8-18 months for WebSphere) then use something else.

Re:The issue is not hardware or software costs

[Anonymous Coward]

In case you haven't noticed, Weblogic is not the only one pushing the J2EE specs.

The point being that the original poster claimed Weblogic is an option if you need standards compliance which is completely untrue.

And for your information, JBoss has had SOAP invoker since forever, even before JAX-RPC was specced.

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:The issue is not hardware or software costs

[Anonymous Coward]

Yeah, if you want to read about the internals. As opposed to, Under what circumstances do I have to restart the server?

Re:The issue is not hardware or software costs

[Anonymous Coward]

you restart the server when your shit doesn't work

how difficult is that to understand? You need a documentation for it? Let me help you:

you restart the server when your shit doesn't work

feel better now?

Re:The issue is not hardware or software costs

[Anonymous Coward]

And for your information, JBoss has had SOAP invoker since forever, even before JAX-RPC was specced.

Just undocumented, ?

Re:The issue is not hardware or software costs

[Anonymous Coward]

go to www.jboss.org, click on the documentation link on the left

it's not that difficult

zope

[zoftie]

its like OT, but blatant promotion of the book and products it describes here without even mentioning competition, mad me spin on my own chair. Zope another alternative to commercial servers written in clean language python that does not treat programmer as malignant influence(as Java does), yet takes best from many languages, including Java and Perl. Zope can be load balanced and attached to many databases(easily!), and it even comes with its own database(plugged in), that is optimized for reading.I suggest you do your shopping first on the web, before buying into megamonster contracts with those companies, check out free alternatives.

JBoss others have mentioned is available if you are really stuck on Java language.

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.

Alternatives to WebLogic...

[Anonymous Coward]

and even WebSphere...

JBoss, also orion (http://www.orionserver.com/)

Anyone else using Orion?? Comments?

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.

Re:Why app servers are such a pain

[liloldme]

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?

You switch to JBoss, that's how :) (yes I noticed you said it's not an option for you, and you have my sympathies)

Re:Why app servers are such a pain

[clockwise_music]

Great comments samwhite. .NET promises to fix a lot of these problems.. but I am vey cautious about it's performance capabilties and how it will end up working in the real world. Plus who the hell wants IIS as their production server in a high-load environment? After code-red + nimbda, no-one if they can help it.

Sorry, I didn't want to get into a j2ee vs .net argument.

Re:Why app servers are such a pain

[axxackall]

JBoss 3: 2 minutes before any first log message from my application (CPU: PIII-500MHz, RAM: 256MB)

Compare it to 5 seconds for Apache/CGI, 10 seconds for Zope, and 45 seconds for stand-alone Tomcat :)

So, the general rule for Java development (and EJB especially) - don't do mistakes if you don't have time to debug :))

Weblogic centric--Really?

[Fujisawa Sensei]

A few times the examples were WebLogic centric

No kidding. I mean this is a book on Weblogic after all.

Re:Weblogic centric--Really?

[RickHigh]

What I meant (and I think you can glean this from the review) is that at times the examples used a weblogic centric approach when I know a more J2EE generic approach existed and would work just as well. I did not mean that the book should not cover weblogic centric features. In fact, I went on for a while about how I liked the weblogic centric features that it did cover. Clear???? If not email me, and I will clarify it further. It is a good book and if you are doing weblogic, I suggest that you get it.

Re:Weblogic centric--Really?

[Fujisawa Sensei]

I have it.

My point is, you said two different things. First impression is where you didn't like the face they use WLS features, see the above. The second was that you did like the WLS specific features.

There a a few very good J2EE books. As far as I know this is the only good WLS specific book.

Re:Weblogic centric--Really?

[RickHigh]

Nope... that is not it.... I am saying use WebLogic specific features when it makes sense, i.e., it provides value above and beyond J2EE. Otherwise show the more portable way of doing things, e.g., don't hardcode JNDI props in the client. Use the proper JNDI names and client ENC. Some people who read this book won't be J2EE experts, they may be J2EE functional but not experts. Show them the right way. They may have to port their component to another platform or may need their components to run on two platforms.

I consider this a nit and not a major flaw. Since they are mostly compliant with all of their examples.

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

[RickHigh]

I guess this is indicative of my English skill being bad. You are making fun of something I said, and I still think it looks right. Hmmmmmmmmmmmmmm..... If you have been using WebLogic off and on since before EJB (Enterprise JavaBeans) existed. Hmmmm..... Is it because I have both since and before?..... I think it is.... Write it the correct way and let me see... I believe the original read like this.... 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. I aint no English major that is for sure.... but it not be stopping me none from exspressing my opinions none. Ha Ha.... An editor once asked me if English was my first language. When I am in a hurry, my writing skills get worse. I figured this was a pretty informal setting.

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

[RickHigh]

If you have been using WebLogic off and on since before EJB (Enterprise JavaBeans) existed, you will still learn a bunch of new tricks.

I forgive your mockery. But you misunderstand. Application servers existed before EJB. WebLogic server existed before EJB. The original before I edited to make it suitable for SlashDot (which can still be found on Amazon) reads: 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.

Weblogic and other application servers predate EJB. Back when EJB came out, NetDynamnics was THE Application server before it got bought by Sun and merged with Netscape then became IPlanet and then Sun ONE.

Therefore, as loopy as it is, I stand by the technical merit of my first statement.

Even today WebLogic is much more than just an EJB server, and the book covers much more than EJB.

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. ;)

Re:I love Java... but not EJB's

[clockwise_music]

I work for one of the top 5 IT companies, and we also had _huge_ troubles with EJB's and Weblogic 5.1. We ended up pulling in a BEA consultant for $1000 a day and still couldn't get the problem fixed. A nightware. I ended up re-writing the website using servlets, JSP's, Corba and straight JavaBeans, doing my best to avoid EJB's. The connection pooling worked fine (after a while) so it wasn't much of an issue. I still got some mighty strange errors sometimes. (ever got pkzip out-of-memory exceptions when deploying?)

The number one rule was, if something doesn't work, re-start weblogic. It become our biggest in-joke. You have no idea how many times somebody goes "there's a problem with.." and someone shouted back "./stopWebLogic.sh; ./startWeblogic.sh"!!!

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.

Instant Application Resin EE

[RickHigh]

Dont' forget Resin EE.... Check out article on Resin: The Instant Application Server by Daniel Solin 09/18/2002 "Imagine a Java Web application server that runs on Unix, delivers incredible performance, is really easy to set up, and inexpensive to boot. Even crazier, imagine that this little app server offers all of the features you expect from a modern Java server, including JSP/servlets, XML/XSL, and EJB/CMP. "

Re:Instant Application Resin EE

[Anonymous Coward]

well, resin is not a j2ee app server like websphere weblogic jboss and orion are... so yes do forget it if you're doing j2ee applications

Re:unnecessary

[RickHigh]

It sounds like you need a copy. I know I did. Ha Ha!

Reviewer is a Python Fan.... Re:zope

[RickHigh]

BTW I love Python. I just wish they would have made it a standard scripting language for JSP (Java Server Pages).

My Java Python Book

Re:WebLogic and WebSphere? OAS!

[axxackall]

Try OAS:

Bad compliance both to CORBA and to EJB. Slow. Buggy. Expensive. Bad support.

I hate Java

[axxackall]

I hate the speed of interpreter combined with convinience of extra compilation step - too bad price for cross-patfom-ness.

I hate to get tough-coupled "spagetti" application from other developers and apply GoF patterns hoping it help and understanding it doesn't. By the way, using GoF from the beginnig doesn't help either - the language is neither lazy evaluated, nor dynamically typed. It's even not enough strong typed.

I hate to know that "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp." (Greenspun's Tenth Rule of Programming) and that it's perfectly applied to Java.

I hate to feel myself like a sheep blindy following Sun Microsystems.

And I hate the job market stupidly demanding mostly only Java programmers.

I probably came too early and I should wait another 10 years when the computer market will recognize that GOTO was only a part of the problem. ANY distructive coding is not a programming.

Re:I hate Java

[Anonymous Coward]

he he

dude,

you suck

your theory

[Anonymous Coward]

You need someone on the hook when things go wrong. You need guarantees.

I agree fully in theory. If only for a devil's advocacy remark it should be noted that many a time there have been companies that used a part (the integrators) or the end usage company that have been left with a crappy, broken, insecure and unrealiable system that no 'guarantee' as you put it would help. Guarantee should be backed up. Guarantee indeed. If many more of these companies find that they are loosing productivity, money and time (guess what time equals) then they are going to continue to grow impatient with these software companies.

Now I am not saying that BEA is like that, maybe they actually support their product. However, put it to another industry. What if UPS could not depend on Ford (who knows what they use, work with me here) because the vehicles constantly died, required 5 times the gas, ran slow, ground the gears under normal operations, spontaneously burned (including the cargo), etc. Yet all through this UPS is charged huge fees not to actually FIX the problem, but simply apply more bandaids. Will they get their money lost back? Will they be given the ability to restore the faith of the customers that were let down? No and no, however they will most likely choose another vendor for their trucks.

In a perfect world (well one that still allowed imperfect software) then what you say would be great. However, since competition is what makes products cheaper yet better, and makes service dependable yet unnecessary... I think that the solution now is to go open source. Hell, even Ballmer admitted the very simple fundamental fact that their prices (MS's) must be justified, as they will not be giving away their software.

Side track now... given that last part, I don't understand why people think Open Source or Free Software is socialist. It is very much Free Market, the price is simply on service not on the product now. Isn't the US more of a service oriented society today?

as opposed to...

[Anonymous Coward]

ok, I am feeding a troll... or perhaps this person really is truthful and feels this way. I suppose it is the old argument given by a bureacrat against a doctor for laughing about an evisceration in their latest sleezy joke they picked up.

That was not arbitrary, as one time I heard this hospital admin berate a doctor for making a joke like this. It was a generic joke (not aimed at any patient or real case) and was not in anywhere the patients ever go. One of the doc's calmly asked the suit what his job was, and the idiot took the bait and rattled on about saving lives and such with his PR rhetoric. When the doc asked how many times he had literally himself saved a life, whether on duty or just passing on the road randomly upon an accident the suit finally realized the trap. Another doc reminded the suit about how a previous years policy would have cost lives and livelihood to which many doctors paid many expenses out of their own pockets so that the 'poor little executives' could continue to make their millions while claiming they lost money. The suit left without comment.

Damn that was gratifying. Anyway, what this leads to is that I really hope that the poster is not one of these that confuses ACTING like he cares with the ACTION of caring and doing things to help. If I had a dime for every pathetic, brainless, morons in uniform or government/contractor suits that caused vital systems to be fucked up by their obvious lack of real caring, or the direct compromise of mission critical data, or the direct compromise of lives because they were too busy ACTING like they cared... I could fund my own military and fill it with the few remaining folk that are dedicated to preservation of freedom and life. Don't come here and patronize anyone about talking about nerf toy guns, when it is shitholes like you that end up giving the military (and by this I mean the real fighting men, not these bureacrats in tailored suits with name-tags) the broken and useless shit (policies and equipment both) that cause them to not be as effective. You sit back in your comfy fucking chair and play 'hearts' while some 19 year old kid is getting shot at or a brand new widow and her 3 kids are mourning the loss of their father. Cry me a fucking river, asshole.

You wanna help? Then make Bush enact a policy to remove all the self serving fuckwads in the military and actually fucking open up "The Art of War" instead of spending another day making a powerpoint slide.

you are just proving the earlier posters's point

[Anonymous Coward]

if EJB makes it all the way to you, then there is a situation of a big problem, half of which you could fix (you meaning WebLogic). The other half is the problem of the licensced company for obviously not having any sort of QA or coordinated development administration. (in other words, they have a bunch of poop throwing monkeys in suits instead of competent management)

As for your half, if problems like this happen alot then it might be a sign that your company has not done an adequate job of educating the customer or assisting in initial setup. There shouldn't be any guess work for software that is as expensive as WebLogic.

Now don't get me wrong, I have worked with vendors before to where we ended up helping them refine their product and setup process. Unfortunately this meant we did not have time to actually implement our system with their product so they lost the actual sale. Even Ballmer has admitted that non-free software (and especially OpenSource) must justify its cost. I see little justification for using any product that expensive where I have to feel around in the dark to setup the environment properly.

As an (sort of) aside... I recall hearing once from an exasperated tech support person to a very large vendor recenly that "Often we get complaints and questions about this [issue], however the solution is not that hard and definitely not as hard as people are making it out to be." When I first asked if that was documented, she responded that "No, that is exactly what I am saying... it is not a big issue." Then I asked her for a synonym for "often" until she realized I meant "Frequent" as in Frequently Asked Question (not to mention common sense dicating that if it is such a common problem then obviously it is not a trivial matter if only from a numerical perspective).

From my experience, many tech support departments of software houses seem to forget the very fundamentals of tech support.