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
Oh, and besides their Market Speak(TM) being confusing and redundant, their Market Speak(TM) is confusing and redundant.
Javascript + Nintendo DSi = DSiCade
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.
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
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 have no clue what I'm doing, but I'm considering getting some apples. One of my buddies actually likes apples. I've never tried them but I like oranges. Are there any benefits of apples over oranges?
___
If you think big enough, you'll never have to do it.
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.
"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.
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:
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
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/