Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

BEA WebLogic Server Bible 132

Posted by timothy from the thinking-about-it dept.
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:

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.
This discussion has been archived. No new comments can be posted.

BEA WebLogic Server Bible More

BEA WebLogic Server Bible

Comments Filter:

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

    by FortKnox ( 169099 ) on Wednesday September 25, 2002 @11:08AM (#4327467) Homepage Journal
    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.
    • 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 (Score:5, Insightful)

    by MSBob ( 307239 ) on Wednesday September 25, 2002 @11:09AM (#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...

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

        by MSBob ( 307239 )
        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 (Score:4, Informative)

      by Kerg ( 71582 ) on Wednesday September 25, 2002 @11:24AM (#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 (Score:4, Interesting)

      by cpfeifer ( 20941 ) on Wednesday September 25, 2002 @11:29AM (#4327617) Homepage
      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 (Score:4, Interesting)

        by pbur ( 88030 ) on Wednesday September 25, 2002 @11:34AM (#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.
        • 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 (Score:1, Informative)

          by 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.
        • Have you ever called BEA weblogic support? You practically have to tell them how to solve the problem.

          No, eDocs [bea.com] has answered all my questions. :-)

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

        • I have always heard good stories about WebLogic support. Maybe you just got the wrong person.
      • 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.

      • 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.
        • 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. =^)
    • 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.).
    • 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

    • 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.
    • There are books that do exactly what you are saying.
      Java Tools for Extreme Programming [rickhightower.com] (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 [amazon.com] (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 [eblox.com] 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 [amazon.com]. 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.
    • 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 [amazon.com]. It is, without qualification, the best book I've ever written on this subject :-). More info is also available at http://www.theYawns.com

  • 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 (Score:1, Insightful)

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

  • Ummm FYI, tim (Score:1, Informative)

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

    by MosesJones ( 55544 ) on Wednesday September 25, 2002 @11:11AM (#4327491) Homepage

    $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
    • >Niche my arse

      Well, I guess your arse may be a niche :)
      • 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 ? (Score:1, Offtopic)

      by Hooya ( 518216 )
      Niche my arse

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

    • Re:Small niche ? (Score:2, Interesting)

      by silversurf ( 34707 )
      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

  • what gives? (Score:1, Funny)

    by ideonode ( 163753 )
    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?

    • 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.
      • 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.
    • 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 (Score:2, Insightful)

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

    • 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

  • I love Java... (Score:5, Informative)

    by Fnkmaster ( 89084 ) on Wednesday September 25, 2002 @11:15AM (#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? (Score:5, Insightful)

      by MSBob ( 307239 ) on Wednesday September 25, 2002 @11:19AM (#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.

    • Re:I love Java... (Score:5, Informative)

      by pbur ( 88030 ) on Wednesday September 25, 2002 @11:28AM (#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.
    • 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... (Score:1, Redundant)

      by glwtta ( 532858 )
      Not every "enterprise class web application" needs EJBs

      a-fucking-men!

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

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

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

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

  • Thoughts on Weblogic (Score:2, Insightful)

    by pbur ( 88030 )
    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? (Score:2)

    by oops ( 41598 )
    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.
  • I can't believe timothy mentions Borders in this article... I thought all Slashdot automatons were required to plug Think Geek at all times?
    • 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 (Score:5, Interesting)

    by signe ( 64498 ) on Wednesday September 25, 2002 @11:49AM (#4327738) Homepage

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

      by glwtta ( 532858 )
      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.
    • 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.
    • 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.

    • 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....
      • 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.
    • 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.
    • 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.
      • Did you try the documentation they charge money for?

        I am curious myself because I am considering using JBoss.
      • 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!

  • zope (Score:1)

    by zoftie ( 195518 )
    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.

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

    by samwhite_y ( 557562 ) <icrewps@yaho[ ]om ['o.c' in gap]> on Wednesday September 25, 2002 @03:50PM (#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.

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

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

    • 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.
  • A few times the examples were WebLogic centric

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

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

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

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

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

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close