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):
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.
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.
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.
FYI, JMX is not a JBoss technology, but rather a Sun JSR Specification. Perhaps the most telling point is that JBoss's name doesn't appear anywhere in the working group for the JSR. Claiming or attributing responsibility for such technology is a bit disingenuous. Especially since several other app servers (e.g. WebSphere and Sun J2EE) use the same technology.
Also, am I the only one who's annoyed at the use of the word "microkernel"? While I'm sure that some similarities exist, a J2EE server is not an operating system. It's a shared environment high above the sysetm management level, and as such cannot be classified in the same manner. Using Operating System terms at that level only serves to confuse potential customers about the purpose of the technology.
My pet peeve in this area is the 1060 NetKernel. They get so wrapped up in the "kernel" language, that they forget to tell everyone exactly what their product does. I mean, look at this stuff:
I'm sure I'm not alone when I say, HUH?
Javascript + Nintendo DSi = DSiCade
It also depends on what you mean by "commercial". If you mean for commercial use, then yes. But if you mean that it is for sale... yes and no. You can use JBoss free (or could) and buy support. So really, the author is correct.
Proprietary is incorrect, though. It is not an applicable term to a J2EE app server. Or if it is correct, it applies to all of the other big app servers: Weblogic, Websphere, and Oracle. I can run these on many OSs and I can use different databases, different JVMs, etc, etc.
As to the review, anyone who has used one of the big name app servers for any length of time, would not find a single book to be a sufficient resource. It is good to see the reviewer point this out. Oddly enough, having had to use Oracles app server for a few years (and being dumbfounded at their horrid/incorrect/blatant lies documentation) I have found one of the best general resources to actually be BEA's dev2dev site. It contains good articles and detailed documentation on some of the steps others abstract away (especially concerning deployment descriptors for ejbs and jms).
Of course, Weblogic and Websphere still have the lion's share of the market... but I would love to see more JBoss (and less Oracle... ick).
Now a days JBoss uses a modified version of Tomcat to provide Servlet and JSP support. The way you delpoy is different and your configuration changes, so in a sense you could say that everything changes. Bugs and performance wise they are going to be the same. Usually the main reason to go with JBoss AS over Tomcat is when you need EJB support.
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
I completely agree.
Having dabbled with WebSphere at work some, I'd say IBM's documentation isn't any better. Trial and error is still the #1 troubleshooting method.
In Soviet Russia, I ruled you
"How the hell to upgrade my EJB+JSP+MBean+JMS from one version to another when every configuration file i've had to modify to get my app to work right has changed formats on me."
Seriously, JBoss 321 -> 327 has had major changes outside of the obvious tomcat 4 to 5 one (the reason we had to do this in the first place), and 327 to 402 is even worse. the JMS subsystem is the worst moving target, as its configuration is significantly different in all three releases we're now arguing with.
JBoss guys, i really do have better things to do with my time than read through and compare 1000 lines of XML between two releases to figure this crap out. A simple "upgrade instructions" document would have been nice.
the reality is that the *vast* majority of those files are currently undocumented and anything anybody does with them is pure guesswork.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
I've used both (as well as many other servlet containers, j2ee containers).
If you just need servlets/jsp, I'd recommend using Tomcat by itself; JBoss adds the rest of the J2EE stack on top of Tomcat, so if you're not using that you're kind of wasting effort.
On the other hand, if you *need* the full stack, JBoss is not a bad container. I would recommend having a look a Tomcat + Spring + Hibernate as an alternative however, as most apps (aside from a couple of banking apps) I've seen really don't need the added complexity, and Spring makes a very good alternative.
If you do use JBoss, keep in mind that they have had a tendency to do things their own way, which may have a tendency to bite you if you're assuming compliance to spec. (as an example, google: jboss unified classloader )
rob.
The review mentions XDoclet, which afaict is more or less deprecated by the annotation feature found in Java 1.5 / JBoss4.
If this book doesn't cover the EJB3.0 stuff, I wouldn't consider picking it up..
Is JBoss, the only 'real' J2EE App Server out there ? I don't think so.
:)
There are alternatives opensource projects like JOnAS(http://jonas.objectweb.org/ or Geronimo(not production ready) available.
JOnAS is J2EE 1.4 certified too, completely free.
The development team is very reactive on the mailing lists.
And the most important : a lot of projects are already in production