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.
Your quotation doesn't imply that JBoss has any responsibility for JMX. It simply says their "microkernel" is based on JMX.
"A man talking sense to himself is no madder than a man talking nonsense not to himself."
JBoss is not an alternative to commercial J2EE App Servers, because it is a commercial J2EE App Server. It's an alternative to proprietary J2EE App Servers.
Some people might think I'm being pedantic, but I think that the distinction is important.
And JBoss is not non-commercial, either, it's non-proprietary. Given the JBoss Group's penchant for astroturfing, I wouldn't be surprised if this is a cleverly-disguised slashvertisement.
a bloated medley of JCP technologies that very few people actually need. It doesn't matter if it is commercial or non-commercial, JBOSS or something else. The volumes that have been written on J2EE, how to use it, best practises, performance tuning, design patterns is a good sign that people are having difficulties using J2EE to rapidly create fast and easily maintainable applications using J2EE at a reasonable cost and time. OK, the servlets and JSPs are very basic and useful but all the EJBs, MDBs, CMPs, Value Objects, etc.. are seldom useful. I have seen many projects go out of control where unsuspecting developers have spent months on this stuff to produce a bulky unusable system. Lightweight technologies like Hibernate and spring are much better. J2EE is going the CORBA way.
Explore your creative side
I've used JBoss for 4 years since it was version 2. It's performed really well but it's not perfect. It has memory leaks when compiling and redeploying web apps which cause the server to have "out of memory errors" while i'm developing numerous times every day. I've upgraded the JDK to the lastest version a number of times so i don't think that's causing it.
But, for me, the biggest issue has been the lack of quality documentation. That problem has been resolving itself over the years as it gains popularity. I don't what WebSphere and WebLogic, for example, have in terms of documentation, but I wish Jboss has better docs.
nevertheless, it's solid and free. i recommend it.
I can not find any hint in this direction in the poster's text.
It is relevant. The term Microkernel is in no way reduced the the usage in an OS kernel. That you have only heard it in this context is just your problem. Words have only a meaning in context. And regarding this it is quite clear, that the general pattern is meant, not its special application to OS kernels.
No, it is quite irrelevant.
The term Microkernel is in no way reduced the the usage in an OS kernel.
"Kernel" in CompSci refers specifically to the low level, hardware/resource control layer of an Operating System. The definition is very clear and distinct. Using the term in places other than OS design is obviously an attempt to liken the new design to a kernel's design. Yet that doesn't make sense, since the two concepts are very different.
The result is that the term gets overloaded and the definition starts to become fuzzy. Which then means that a greater context is required to fully explain the subject.
For example, if I say "Having extensively used DiVX, I must say that I dislike it intensely," it is unclear if I'm referring to DiVX the codec, or DiVX the DVD alternative. And having this statement made in the context of a Video Encoding forum does not necessarily help. Discussing the relative merits of the DVD format vs. the DiVX format is well within the bounds of normal discussion for such a forum. Which means that people often must state, ""Having extensively used DiVX (the disc format, I love the codec), I must say that I dislike it intensely."
This breaks up the flow of the idea, and makes communication more difficult. Why would we want to *intentionally* muck up our communications like that? Especially when the term "Framework" fits perfectly well, and is intended for this precise situation.
As I said, the overloading of the term is confusing, highly annoying, and destructive to communication.
Javascript + Nintendo DSi = DSiCade
Uh, no, your analagy doesn't really fit. The two are not equivalent, did you read any other replies? Tomcat is a servlet container, and JBoss is a full-blown application server, which uses a modified version of Tomcat as it's servlet container. JBoss does a whole lot more than Tomcat, but can be terribly unwieldy to someone that has no experience in it, and especially someone that has no experience, and isn't positive why they're using it. I'd be very, very surprised if Tomcat wasn't suitable to your needs, especially since you mentioned that it's going to be hosted on one machine.
--- What