Slashdot Mirror


JBoss - A Developer's Notebook

Pankaj Kumar writes "Controversies aside, JBoss has emerged as a credible alternative to commercial J2EE App Servers for developing and deploying Java based server applications. Besides the usual advantages of open source and GPL licensing, what sets it apart is its JMX based microkernel, a light-weight framework to run independently developed Java programs within a single JVM. Together, these make it possible for one to pick and choose components and assemble a custom server anywhere between the two extremes (and beyond!) of a simple Servlet Container and a full-fledged J2EE Server. JBoss - A Developer's Notebook by Norman Richards, a JBoss developer at JBoss, Inc., and Sam Griffith, Jr., a software consultant and trainer, is a no-fluff How-To guide on doing stuff with JBoss in O'Reilly's new Developer Notebook format." Read on for Kumar's review of the book. JBoss - A Developer's Notebook author Norman Richards & Sam Griffith, Jr. pages 150 publisher O' Reilly rating 7 reviewer Pankaj Kumar ISBN 0596100078 summary A How To Guide on Working With JBoss

True to the format, this book doesn't waste pages on paeans to architectural elegance, internal design or conceptual deliberations, and limits itself to the basic needs of most professionals -- how do I do this or that with JBoss, where to start, what steps to carry out or what code to write, and what happens behind the curtains.

Books dealing with J2EE products tend to be fat and bulky, but this (note)book doesn't fall in that category. By covering only JBoss specific aspects and avoiding general J2EE topics, this rather thin book has managed to include a good deal of difficult-to-find information about JBoss. In fact, while going through its pages, I got a feeling that the authors have taken care to be different and complementary to the online documentation available in the JBoss Application Server Guide and JBoss Wiki.

In support of the above claim, let me compare the coverage of how to deploy applications under JBoss, an important activity with any J2EE container, in the JBoss Guide, JBoss Wiki, and the book under review. The JBoss Guide covers application deployment as part of the JMX based microkernel architecture and design, describing, in excruciating detail, the internal components responsible for the deployment and and how they interact. The JBoss Wiki takes a more externally focused approach, talking about hot deployment capability, relevant directories and configuration files in an installed system, and steps in a typical deployment process. In contrast, Developer's Notebook goes through the whole process of creating the deployable WAR file for a web application, deploying that to JBoss by copying the created file to JBoss's deploy directory, and verifying successful deployment or looking for errors. It even talks about how to modify a deployed application. Needless to say, the last one is most useful to someone who just wants to deploy his or her application.

True to its lab notebook style, the book makes important, though not integral, observations about specific topics in the page margins. For example, a note in the margin of deployment steps tells you that you can include a deployment package within another deployment package, up to an arbitrary level of nesting, a la Russian doll packaging. I found this informal way of communicating relevant stuff quite effective.

Another noteworthy aspect of this book is that it makes generous use of appropriate tools, such as Ant and XDoclet, to get things done. This can be either good or bad, depending upon your familiarity with these tools. For me, it turned out to be a mixed bag. I know Ant and am happy writing Ant scripts for packaging and deployment. It is different with XDoclet, which I haven't had a chance to use so far. But perhaps the authors know better and one should just get familiar with it before working on any project involving JBoss and Enterprise Java Beans.

It is difficult, if not impossible, to cover each and every aspect of software as feature rich and complex as JBoss in any single book. This leaves the somewhat unpleasant task of choosing topics to the the authors and editors, for the selection may or may not match the needs of a particular reader. At the same time, it increases the responsibility of a reviewer like me who must help a prospective buyer decide for or against making a purchase, based on her needs.

Let me attempt to do that by making two lists: first, what is included and then, what is not.

What is included (paraphrased Table of Contents):
  • How to install, start, examine (through JMX Console) and shutdown JBoss Server.
  • How to package, deploy, observe and undeploy an application.
  • How to create a web application with database access and user authentication.
  • How to use MySQL as database for a JBoss application.
  • How to setup user database, login modules and enable SSL.
  • How to configure logging for various components of JBoss.
  • How to map schema, objects and relations to database tables.
  • How to monitor and manage a JBoss application with MBeans.
  • How to create a custom JBoss with modules that your application needs.


A similar, comprehensive, list of what is not included is simply not possible. Still, I have gone ahead and created the following based on my experience with JBoss. Keep in mind that these reflect the kind of applications I have worked on and may not be representative of your needs.
  • How to use JBoss as a J2SE container.
  • How to develop Web services with JBoss.
  • How to create, package and deploy an application consisting of JBoss services, web applications and web services.
  • How to troubleshoot class loading problems.
  • How to isolate applications within a single JBoss server instance.
  • How to profile for performance bottlenecks.
  • How to run multiple instances of JBoss Server on a single machine.


I can only hope that the authors will take this as a reader feedback and include some of the above in a future edition.

So, what else is there not to like about this book? One thing that caught my attention was the relative absence of insight into why things worked the way they worked: What are the underlying patterns and how can the awareness about these patterns be applied to other similar situations? These are the things I look for in a new product or technology, and have found them to be much more helpful than just a compilation of step-by-step descriptions of doing things. Perhaps the Developer's Notebook format doesn't allow for such digressions, still I think inclusion of such insights would have improved the book.

Overall, I would say that JBoss - A Developer's Notebook is a good introductory book for those who are thinking of getting started or are just getting started with JBoss. If you have already worked on JBoss and are looking for more advanced or esoteric stuff, then this book is perhaps not for you.

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

3 of 116 comments (clear)

  1. Re:Anyone else gets nauseated... by MemoryDragon · · Score: 4, Interesting

    Simple... php inferior language
    C much longer development time for server side stuff, with not too much performance gain in that area, and to few portable libraries which are really portable (thank Microsoft and the ISO consortium for that)
    Python... much slower, and not really an improvement over java language wise
    Lisp... not as common, you cannot find enough people
    The ideal language for that kind of development probably would be smalltalk, but the Smalltalk vendors killed themselves in the Digital Parcplace fiasko and their inability to extend the common base to something java could deliver out of the box.
    The only contender in the long run I see currently is Ruby, with their excellent rails framework.

  2. Re:Anyone else gets nauseated... by Elrac · · Score: 4, Interesting
    I like to think of myself as a "the right tools for the job" kind of person. I prefer to do Windows GUI apps in Delphi, I do online game and communications apps in C, and simple CGIs and scripts in Perl. Until recently, I earned a living coding in FORTRAN, on a machine where its performance is unsurpassed by other languages.

    As such, I don't see anything seriously wrong with Java. Thanks to its clean and simple syntax and its rich library, I feel it lets me solve problems faster than many other languages. At least on the server, it runs at compiled speeds, and the base of free code to build on is enormous.

    There are certainly "better" languages, for various flavors of "better". Lisp and Smalltalk come to mind. Look at Structure and Interpretation of Computer Programs for a glimpse at the awesome power of Lisp. Smalltalk programmers never cease to rave about what a joy it is to work with. These two languages suffer from lack of acceptance by the masses, something like why Microsoft and not {*nix|*BSD|BeOS|VMS} is the dominant operating system. I posit that it takes hardly more intellectual prowess to program in Java than in BASIC, but Lisp and Smalltalk are better suited for hardcore geeks.

    The other languages you mentioned each have some glaring flaws:
    • PHP is a haphazardly thrown-together toy language, lacking structure, standards and consistency. It makes some things, mostly Web-related, very easy but doesn't help you not get tangled up in more complicated projects.
    • ASP is not a language, the underlying language is (Visual) BASIC. It runs only on Windows!
    • Python is not a bad language, and from what I hear, Ruby is even better. But it's still (mostly) interpreted and hence too slow for many Enterprise applications. Also, it doesn't have Java's breadth of support. Libraries, utilities, documentation, hype -- Guido/Matz just don't have as deep pockets as Sun.
    • C is a good systems-level language. Because a programmer must micro-manage memory, it and C++ suck as application development languages. The sheer mass of existing C/C++ coding doesn't disprove this; it dates back to a time when programmer productivity wasn't valued as much.


    J2EE is horribly complicated. But because it was backed by Sun, and still much more manageable than CORBA, it was happily accepted by the industry. The standard is improving, the code base is growing -- Java has momentum, and for better or worse it isn't going away anytime soon.
    --
    When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
  3. JBoss + Hibernate + Spring by cbarcus · · Score: 4, Interesting

    While I didn't find J2EE really compelling for a project I was working on back in 2003, JBoss in combination with both Hibernate and Spring was quite awesome. For those who don't know, Hibernate is a persistence framework for SQL databases; I found it to work very well with PostgreSQL. Spring is an MVC framework meant to make it easier to organize server-side application logic.

    Some nice tools for building Java-based web-applications:

    http://www.hibernate.org/
    http://www.springframework.org/
    http://www.jboss.com/
    http://www.postgresql.org/
    http://ant.apache.org/
    http://www.eclipse.org/