Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

BEA WebLogic Server Bible

timothy posted about 12 years ago | from the thinking-about-it dept.

Java 132

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.

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:


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.

cancel ×

132 comments

Sorry! There are no comments related to the filter you selected.

frost piss (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4327428)

oh yes

Re:frost piss (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4327440)

lol you got moderated really fast, sucks for you dickcheese

Early Post (damned 2 minute wait) (-1, Offtopic)

SexyKellyOsbourne (606860) | about 12 years ago | (#4327438)

Lucifer

Our father who art in Hell
Hallowed be thy name
Thy kingdom is come
Thy will is done
On earth as it is in Hell

We take this night our rightful due
And trespass not on the path of He
Lead us unto temptation
And deliver us from false deity

For thine is the Kingdom
And the Power
And the Glory
Forever

Shemhamphoresh!

-King Diamond

Does it cover known "features"? (3, Informative)

FortKnox (169099) | about 12 years ago | (#4327467)

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"? (1)

nigord (573821) | about 12 years ago | (#4328053)

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 (5, Insightful)

MSBob (307239) | about 12 years ago | (#4327472)

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 (2)

Fnkmaster (89084) | about 12 years ago | (#4327557)

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 (3, Insightful)

MSBob (307239) | about 12 years ago | (#4327597)

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 (0)

Anonymous Coward | about 12 years ago | (#4327623)

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 (4, Informative)

Kerg (71582) | about 12 years ago | (#4327584)

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 [jboss.org] , both for free and for pay docs.

Re:Vendor lock-in (4, Interesting)

cpfeifer (20941) | about 12 years ago | (#4327617)

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 (4, Interesting)

pbur (88030) | about 12 years ago | (#4327650)

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 (2)

cpfeifer (20941) | about 12 years ago | (#4327809)

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 (1, Informative)

Anonymous Coward | about 12 years ago | (#4331187)

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 (2)

MSBob (307239) | about 12 years ago | (#4327750)

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 (2)

SimonK (7722) | about 12 years ago | (#4330374)

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 (2)

cpfeifer (20941) | about 12 years ago | (#4330485)

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 (2)

j3110 (193209) | about 12 years ago | (#4329230)

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 (1)

JSR $FDED (410612) | about 12 years ago | (#4330118)

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 (2)

gorilla (36491) | about 12 years ago | (#4330188)

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.

Online tutorials and such? (1)

fluor2 (242824) | about 12 years ago | (#4327480)

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?

This is a karma whore/troll (1, Insightful)

Anonymous Coward | about 12 years ago | (#4327505)

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.

Re:Online tutorials and such? (0)

hoover (3292) | about 12 years ago | (#4329418)

Have you looked into Zope [zope.org] ? 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 (1, Informative)

Anonymous Coward | about 12 years ago | (#4327482)

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 ? (4, Insightful)

MosesJones (55544) | about 12 years ago | (#4327491)


$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 ? (0)

Anonymous Coward | about 12 years ago | (#4327518)

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 ? (-1, Flamebait)

Anonymous Coward | about 12 years ago | (#4327651)

Yes, timothy is a fucking idiot with little real life experience. So what else is news?

Re:Small niche ? (2)

Nadir (805) | about 12 years ago | (#4327735)

>Niche my arse

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

Re:Small niche ? (1)

liloldme (593606) | about 12 years ago | (#4328539)

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 ? (1, Offtopic)

Hooya (518216) | about 12 years ago | (#4327753)

Niche my arse

Well i certainly do hope your arse is a 'small Niche'.

Re:Small niche ? (2, Interesting)

silversurf (34707) | about 12 years ago | (#4327922)

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 ? (0)

Anonymous Coward | about 12 years ago | (#4328170)

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 ? (1)

liloldme (593606) | about 12 years ago | (#4328769)

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 [sourceforge.net] on average.

what gives? (1, Funny)

ideonode (163753) | about 12 years ago | (#4327496)

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? (1)

dancornell (95530) | about 12 years ago | (#4328119)

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? (1)

RickHigh (576831) | about 12 years ago | (#4332667)

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.

weblogic... so much potential (2, Insightful)

Anonymous Coward | about 12 years ago | (#4327502)

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 (1)

old-lady-whispering- (602967) | about 12 years ago | (#4327616)

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

BET WebLogic Server Bible (0, Offtopic)

McFly69 (603543) | about 12 years ago | (#4327509)

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... (5, Informative)

Fnkmaster (89084) | about 12 years ago | (#4327516)

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.

So you think WebLogic's bad, huh? (5, Insightful)

MSBob (307239) | about 12 years ago | (#4327543)

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.

WebSphere 5 shipped? (2)

Software (179033) | about 12 years ago | (#4328268)

According to this page [ibm.com] , 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? (2)

MSBob (307239) | about 12 years ago | (#4329687)

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? (0)

Anonymous Coward | about 12 years ago | (#4332293)

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:I love Java... (5, Informative)

pbur (88030) | about 12 years ago | (#4327612)

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

Anonymous Coward | about 12 years ago | (#4327708)

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

Black Perl (12686) | about 12 years ago | (#4328980)

Jrun 4.0 is EOL.

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

Re:I love Java... (1)

mrmcfad (412038) | about 12 years ago | (#4328174)

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

borzwazie (101172) | about 12 years ago | (#4327666)

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... (1, Redundant)

glwtta (532858) | about 12 years ago | (#4327821)

Not every "enterprise class web application" needs EJBs

a-fucking-men!

Can someone please explain... (0)

bayankaran (446245) | about 12 years ago | (#4328179)

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

Re:Can someone please explain... (2)

Fnkmaster (89084) | about 12 years ago | (#4328616)

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.

Weblogic 6.1 better than iPlanet at least... (2)

SuperKendall (25149) | about 12 years ago | (#4328471)

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

dedicated team of people (2)

KyleCordes (10679) | about 12 years ago | (#4333187)

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:I love Java... (0)

Anonymous Coward | about 12 years ago | (#4330018)

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

Anonymous Coward | about 12 years ago | (#4330578)

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

Anonymous Coward | about 12 years ago | (#4330462)

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

That was funny

Re:I love Java... but not EJB's (1)

clockwise_music (594832) | about 12 years ago | (#4332802)

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

$1000 a day (2)

KyleCordes (10679) | about 12 years ago | (#4333203)

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.

unnecessary (-1, Troll)

boxless (35756) | about 12 years ago | (#4327522)

this shit is golfcourse-ware.

any company with an IT staff that has IQs above 120 doesn't need it. Of course, that rules out 80% of companies.

Should be a good read. (2)

bdowne01 (30824) | about 12 years ago | (#4327533)

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

Anonymous Coward | about 12 years ago | (#4327591)

They are not DOS boxes.

Re:Should be a good read. (2)

bdowne01 (30824) | about 12 years ago | (#4327603)

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

Anonymous Coward | about 12 years ago | (#4330737)

Ughh...why not:

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

Works for me!

Re:Should be a good read. (2)

bdowne01 (30824) | about 12 years ago | (#4332851)

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

clockwise_music (594832) | about 12 years ago | (#4332866)

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.

hubba (-1)

macksav (602217) | about 12 years ago | (#4327537)

bububba. y'know, the more and more i come here, the dirtier i feel. with all the creeps and dildo suckers posting here, not to mention the moaning ketboard fuckers and tweezer-wielding masturbators along with the fecal-facial crowd and the ass-reaming piss-drinkers, i need a good solid dose of hardcore beastiality pron to feel clean again. since i've pretty much used up my stash of hardcore aniaml fucking, anybody got some links?

Thoughts on Weblogic (2, Insightful)

pbur (88030) | about 12 years ago | (#4327553)

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

Get some PRIORITIES! (-1, Flamebait)

Anonymous Coward | about 12 years ago | (#4327676)

The worst terrorist attack in recorded history occurred over a year ago, followed by a Holy War against Islam, and now Israel and the Palestinians as well as India and Pakistan are teetering on the brink of their own war, Argentina is in the midst of a financial crisis, America is considering launching attacks against Somalia and Iraq, and you people have the gall to be discussing BEA WebLogic???? My *god*, people, GET SOME PRIORITIES!

The bodies of the thousands of innocent civilians who died (and will die) in these unprecedented events could give a good god damn about BEA WebLogic, your childish Lego models, your nerf toy guns and whining about the lack of a "fun" workplace, your Everquest/Diablo/D&D fixation, the latest Cowboy Bebop rerun, or any of the other ways you are "getting on with your life" (here's a hint: watching Cowboy Bebop in your jammies and eating a bowl of Shreddies is *not* "getting on with your life"). The souls of the victims are watching in horror as you people squander your finite, precious time on this earth playing video games!

Re:Get some PRIORITIES! (1, Insightful)

pmz (462998) | about 12 years ago | (#4328323)

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?

Niche? (2)

oops (41598) | about 12 years ago | (#4327720)

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?! (1)

Danborg (62420) | about 12 years ago | (#4327723)

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

Weblogic & JBoss (5, Interesting)

signe (64498) | about 12 years ago | (#4327738)


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 (3, Interesting)

glwtta (532858) | about 12 years ago | (#4327781)

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 (0)

Anonymous Coward | about 12 years ago | (#4327817)

Care to publish your methods and results?

Re:Weblogic & JBoss (2)

puppetman (131489) | about 12 years ago | (#4327979)

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 (1)

FigWig (10981) | about 12 years ago | (#4328093)

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 (1)

mrmcfad (412038) | about 12 years ago | (#4328246)

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 (2)

mgkimsal2 (200677) | about 12 years ago | (#4328848)

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.

Re:Weblogic & JBoss (2)

iabervon (1971) | about 12 years ago | (#4328259)

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.

The issue is not hardware or software costs (2)

mikael (484) | about 12 years ago | (#4328520)

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 (1)

KenSeymour (81018) | about 12 years ago | (#4328568)

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 (1)

beanball75 (126064) | about 12 years ago | (#4329598)

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 (0)

Anonymous Coward | about 12 years ago | (#4328943)

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 [onjava.com] 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 (1)

Solaristrum (198730) | about 12 years ago | (#4329953)

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 (0)

Anonymous Coward | about 12 years ago | (#4330440)

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 (2)

fishbowl (7759) | about 12 years ago | (#4330517)

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 (0)

Anonymous Coward | about 12 years ago | (#4334041)

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

WebLogic re-evaluated (0)

Anonymous Coward | about 12 years ago | (#4328116)

We are seriously considering and are currently evaluating JBoss [jboss.org] , 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 (2)

codepunk (167897) | about 12 years ago | (#4329376)

Let me add one more,since weblogic is notoriously buggy

5. Stability

zope (1)

zoftie (195518) | about 12 years ago | (#4328908)

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 (2)

codepunk (167897) | about 12 years ago | (#4329492)

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

Anonymous Coward | about 12 years ago | (#4330110)

and even WebSphere...

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

Anyone else using Orion?? Comments?

Why app servers are such a pain (4, Interesting)

samwhite_y (557562) | about 12 years ago | (#4330264)

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 (1)

liloldme (593606) | about 12 years ago | (#4330473)

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)

You switch to JBoss (2)

KyleCordes (10679) | about 12 years ago | (#4333227)

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.

Re:Why app servers are such a pain (1)

clockwise_music (594832) | about 12 years ago | (#4332898)

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.

Weblogic centric--Really? (1)

Fujisawa Sensei (207127) | about 12 years ago | (#4330676)

A few times the examples were WebLogic centric

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

Re:Weblogic centric--Really? (1)

RickHigh (576831) | about 12 years ago | (#4332701)

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.

Nice wording there (2)

Earlybird (56426) | about 12 years ago | (#4331419)

  • 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?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?