Become a fan of Slashdot on Facebook

 


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

JBoss - A Developer's Notebook 116

Posted by timothy from the hello-boss-coffee dept.
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.
This discussion has been archived. No new comments can be posted.

JBoss - A Developer's Notebook More

JBoss - A Developer's Notebook

Comments Filter:

  • JMX Microkernel (Score:4, Informative)

    by AKAImBatman ( 238306 ) * <akaimbatman AT gmail DOT com> on Monday August 29, 2005 @12:36PM (#13428306) Homepage Journal
    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.

    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 [jcp.org] 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. [1060.org] 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:

    NetKernelTM Microkernel is a REST microkernel. It provides a clean, robust and scalable foundation for the development and delivery of robust, scalable and adaptable systems.


    I'm sure I'm not alone when I say, HUH?

    • 1060 Market Speak (Score:5, Funny)

      by AKAImBatman ( 238306 ) * <akaimbatman AT gmail DOT com> on Monday August 29, 2005 @12:39PM (#13428330) Homepage Journal
      Oh, and besides their Market Speak(TM) being confusing and redundant, their Market Speak(TM) is confusing and redundant.
    • Your quotation doesn't imply that JBoss has any responsibility for JMX. It simply says their "microkernel" is based on JMX.
      • My quotation states that "JMX sets JBoss apart". How can JBoss be set apart by a technology used by many (if not all) the major vendors? Perhaps the author meant "JMX sets JBoss apart from the other low cost/free/open source J2EE servers?"
        • Whether or not JBoss is set apart by it's use of JMX is irrelevant to whether or not the author "attributes responsibility" to JBoss for JMX.
          • My reading of the post is that the poster is implying either responsibility for or a current monopoly on the technology. Nothing could be further from the truth.

            However, I am willing to concede that others (such as yourself) have not read it this way. Which only leaves the point about being "set apart" based on this technology. I find it hard to accept that JBoss is "set apart" by a technology that is in many competing J2EE servers. In which case, I can only assume that the poster either did not understand
            • My understanding is that while lots (most? alll?) of J2EE application servers use JMX or provide services based on JMX in some way, the core of JBoss's architecture is JMX, to the extent that if you're running a minimal JBoss configuration, what you've got is an MBeanServer and a few MBeans. Every other service is loaded via the services provided by that JMX 'spine.'

              I want to emphasize that I know SFA about (e.g.) WebLogic and its architecture, so what I said above may well not be a unique feature of JB

        • Re:JMX Microkernel (Score:3, Informative)

          by br0k_sams0n ( 848842 )
          You're sinking fast. Others have already addressed the "JBoss isn't claiming to invent JMX argument" so I won't go there. Most FOSS application servers as well as commercial servers do expose JMX objects so this isn't something that sets them apart. What does set them apart is that they base their architecture on JMX where as others simply expose JMX objects, usually for mundane tasks simply to get the checkbox on feature set. JBoss on the other hand, uses JMX to bootstrap the entier application server, al
          • You're sinking fast.

            Sinking, nothing. I'm pointing out an oddity in the review, which *seems* to claim that JBoss is somehow superior for its use of JMX. Since JBoss has nothing to do with the development of the technology, nor does it have a monopoly on the use of the technology, I find that statement odd at best, disingenuous at worst. However, I think you answered the argument after this:

            What does set them apart is that they base their architecture on JMX where as others simply expose JMX objects, usual

        • My quotation states that "JMX sets JBoss apart". How can JBoss be set apart by a technology used by many (if not all) the major vendors? Perhaps the author meant "JMX sets JBoss apart from the other low cost/free/open source J2EE servers?"

          Nope, that's not what you quoted in your original response. Here it is for everyone who is too lazy to look it up again (including the OP):

          "what sets it apart is its JMX based microkernel,"

          To me, that simply means they've made an implementation of the JMX standard. It does
    • JBoss doesn't claim to have invented JMX. They merely utilize it in their implementation.

      "Microkernel" refers to the architectural pattern around which JBoss was designed. You can read up on it in the POSA book [amazon.com] by Buschmann et. al.
      • JBoss doesn't claim to have invented JMX. They merely utilize it in their implementation.

        The poster implies that JMX is a JBoss technology, or at least that JBoss has a current monopoly on JMX.

        Still, I'm willing to concede the point since no one else seems to be bothered by this. The rest of my point still stands from an informative perspective. JMX is a standard technology used by a variety of J2EE servers.

        "Microkernel" refers to the architectural pattern around which JBoss was designed.

        Irrelevant. My po

        • Re:JMX Microkernel (Score:2, Insightful)

          by rca66 ( 818002 )

          The poster implies that JMX is a JBoss technology, or at least that JBoss has a current monopoly on JMX.

          I can not find any hint in this direction in the poster's text.

          "Microkernel" refers to the architectural pattern around which JBoss was designed.

          Irrelevant. My point was that the use of the term "Microkernel" is confusing,

          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

          • 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

            • Using the term in places other than OS design is obviously an attempt to liken the new design to a kernel's design.

              Absolutely right, the pattern has been derived from the OS design.

              Yet that doesn't make sense, since the two concepts are very different.

              It's an abstraction, it looks at what is the essence behind the principle of the OS microkernel and transfers it to other areas. That's what patterns are about. And to make it clear: using this term in that general way is in no way an invention by th

              • Absolutely right, the pattern has been derived from the OS design.

                Which is, again, completely screwed up. JBoss, NetKernel, Geronimo, etc., all have zip to do with microkernels. They don't manage anything other than loading shared, executable code. Something which, if I may point out, is precisely what a Microkernel *doesn't* do. That's what the servers are for!

                Not to mention that the concept *still* fails to commmunicate what precisely the software *does*. When we talk about OS Microkernels, we know that w

                • They don't manage anything other than loading shared, executable code. Something which, if I may point out, is precisely what a Microkernel *doesn't* do. That's what the servers are for!

                  Well actually, servers are part of the Microkernel pattern. To make things worse, there is also a participant called "microkernel" in the Microkernel pattern... If it was not clear up to now: JBoss at all is not a microkernel, its architecture is based on the Microkernel pattern. JBoss also contains e.g. the servers whic

    • Especially when the "kernel" is responsible for handling a "virtual machine", it is fully correct to refer to it as one. One good example would be UML (user-mode linux, not to be confused with..whatever that bizarre prototyping / flowcharting 'language' is). Most here would agree that Linux is a kernel, even when it is abstracted to the level of an application. Another example, based on UML is CoLinux, which allows Linux to run as a privileged application on an NT-based windows system. (It may run on 9x
    • 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 [jcp.org] 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.

      I don't see how the statement you quoted implies that JBoss was involved in creation of JMX. Being based on JMX implies only one thing: it

    • Re:JMX Microkernel (Score:2, Informative)

      by Doc Ruby ( 173196 )
      JBoss obviously didn't invent the GPL or OSS, either, but they're other aspects of JBoss, apart from JMX, that the post claims sets JBoss apart from its competition. Your straw man is your own invention, your own inference, that is not stated in the post you're arguing with. It's your own agenda, neither that of JBoss or the poster to whom you replied.
      • Right on, I could not believe the parent response was modded up, but I don't have anymore mod points...
      • Moderation -1
            100% Overrated

        I point out the clear error a post, but that doesn't rate. More tracks of the sleazy SlashStalker Trollmods. Ew, they're covered in slime!

    • While I'm sure that some similarities exist, a J2EE server is not an operating system.

      Ummmmm I'm not so sure about this portion of your comment. When you think of an operating system there are (at least) 2 distinct functions. 1) Abstract hardware resources so that they are easily accessable via an API for developers. Java does this via it virtual machine and the J2EE API. 2) Provide a set of tools to allow an operator to execute applications, monitor performance, diagnose faults, etc, etc. Java prov

  • Commercial != Proprietary (Score:5, Insightful)

    by Bistronaut ( 267467 ) on Monday August 29, 2005 @12:41PM (#13428348) Homepage Journal
    "Controversies aside, JBoss has emerged as a credible alternative to commercial J2EE App Servers..."

    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.

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

      A

    • The author obviously meant commercial in the "pay big bucks for" sense. It's not the standard definition of commercial but a google search turned up this definition: "Software developed for and sold to the general public. Generally there are licensing fees associated with the use of such software.".

      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.

      Hate to break this to you but EVERY J2EE app serve

  • Not GPL, LGPL (Score:1, Insightful)

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

    • Re:Not GPL, LGPL (Score:2, Interesting)

      by $RANDOMLUSER ( 804576 )
      Either way, given that WebLogic and WebSphere cost a fortune, JBoss is the only "real" app-server that can be had for no dollars. It's good to have a cookbook out there, so the do-it-yourselfers can learn how to write for an app-server on their own. Plus, the low-budget crowd can put up a real app-server. If JBoss won't scale to the traffic and you have to buy one of the big boys, well, that's a good problem to have.

      • Re:Not GPL, LGPL (Score:2, Interesting)

        by Anonymous Coward
        Either way, given that WebLogic and WebSphere cost a fortune, JBoss is the only "real" app-server that can be had for no dollars.

        No, Sun has had a Real Appserver(tm) available for no cost for some time now (at least two years). They've even gone to the trouble of benchmarking it (both backed by Oracle and by MySQL) against the SPEC Java benchmark AND publishing the results so you can compare it.

        Their next version is even Open Sourced and being developed under GlassFish at java.net.

      • Re:Not GPL, LGPL (Score:1, Informative)

        by Anonymous Coward
        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/ [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 :)

  • J2EE is.. (Score:5, Insightful)

    by SilentReallySilentUs ( 908879 ) on Monday August 29, 2005 @01:20PM (#13428614) Homepage
    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.

    • Re:J2EE is.. (Score:3, Insightful)

      by helix_r ( 134185 )
      ...I have seen many projects go out of control where unsuspecting developers have spent months on this stuff to produce a bulky unusable system...

      Ahem.... that would describe where I work.

      But anyways, its all water under the bridge. In a few years, those of us that are still employed will laugh at the comically baroque complexity of the bullshit tools we have to work with today.

    • J2EE is a specification to which various parties provide some or all of the services. Last I checked, some of these vendors provide different pricing on what you want allowing you to roll-your-own container.

      As for being a bloated medly of seldom used/needed technologies, I strongly disagree with this statement. Like Corba, it defines a set of services vendors provide to build enterprise applications. Last I checked, distributed transactional services, orbs, mail, security, and messaging were all really i

    • Re:J2EE is.. (Score:2, Interesting)

      by ezweave ( 584517 )

      I have heard this opinion off and on, but I have also heard this from people who either did not fully grasp the entire framework that is J2EE or from people who did and thought it was a waste of time for various reasons.

      No matter how you build your framework, good OO design dictates that you seperate business logic from the presentation, control layers (commonly called MVC [wikipedia.org] and idea as old as Smalltalk 80). If you stick with Servlets and JSPs you should at least have some type of BusinessObject that does t

    • Re:J2EE is.. (Score:3, Interesting)

      by _marshall ( 71584 )
      disclaimer: I work for JBoss, but have been a J2EE programmer for as long as I can remember =)

      Most of the enterprise Java community actually agrees with you, hence why the EJB3 specification is highly derived and influenced from Hibernate. Value Objects, Home interfaces, and redundant configurations are just some of the things that have been all but completely removed from the new spec. But "removal of annoying features" isn't the only thing that EJB3 is focusing on. There is also a sharp focus on the Keep
    • J2EE consists of Servlets, JSP, JNDI, the new Deployment API, JMS, JCA, JTA, the JAX api's, and EJB. All of the new frameworks like Spring use these core API's to some degree.

      You seem to only be complaining about EJB, and how it's going the CORBA way, which I find tremendously funny because EJB was originally (and still is) a standard runtime model for CORBA objects written in Java, with a difficult object/relational mapping spec bolted on.

  • I am working a couple of other people on a startup, and we were thinking of going the JBoss route. One of them prefers JBboss, I've never used it, but have used Tomcat. We'll likely be running on multi proc AMD servers.

    Has anyone used both? What are the benefits of one over the other? Do you like the way one does something better? Caveats? Pitfalls? Problems in deployment?

    Thanx in advance.

    • JBoss includes Tomcat AFAIK, so I think you may be comparing apples to oranges. What are you trying to do with the tech?


    • Re:Question for developers: JBoss vs Tomcat (Score:4, Informative)

      by ChaseTec ( 447725 ) <chase@osdev.org> on Monday August 29, 2005 @01:32PM (#13428709) Homepage
      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.

    • EJBs: JBoss
      No EJBs: Either will do
    • It depends on what your product is doing. If you simply need a web application, then there isn't much need to introduce all of JBoss into the mix unless you need to cluster it and manage a large number of nodes in a centralized manner. However, it is quite possible to slim JBoss down by stripping out many parts of the app server to make it lightweight and suitable as simply a web application container. I've actually used JBoss as a framework for a product before and it absolutely shined. We didn't need EJB
    • Tomcat

      Don't add complexity you don't need. Only use JBoss when Tomcat doesn't support what you're doing and you understand why.

    • Translation (Score:5, Funny)

      by RelliK ( 4466 ) on Monday August 29, 2005 @01:44PM (#13428791)
      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?
      • Actually it goes more like this:

        I'm thinking about using apple boxes to package some goods. A buddy likes apple boxes, but I've only used orange crates. What are the benefits of apple boxes over orange crates?

        Clearly there are differences, and yet they have the same purpose: to hold fruit. Apple boxes may be better for a number of reasons, orange crates may be better for a number of reasons and all I'm asking is what those are.

        So, thanks anyway.

        • Re:Translation (Score:3, Insightful)

          by Marc2k ( 221814 )
          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,
        • Closer:

          You are dealing with apples. So do you need just an apple crate, or a rig which carries apple crates across the country?

          If you don't need the long distance shipping, then the simple crate alone will do the job.

          • Yeah, that's probably it. I can start with a crate and add stuff to it as I need (wheels, handle, linkage for more crates), but maybe the rig is better in the long run if I think I will need things like an engine, cab and bigger load capacity.

            Analogy aside, some have said that JBoss is the way to go if we need EJBs. If we didn't need that right away, we could use Tomcat now and later add in OpenEJB. On the surface at least that means that either would be acceptable. I guess what I wanted to know was if som

    • Re:Question for developers: JBoss vs Tomcat (Score:5, Informative)

      by rhedin ( 91503 ) on Monday August 29, 2005 @01:49PM (#13428842)
      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.

      • Thanks. On the EJB point though, when does it (?) make more sense to use JBoss than Tomcat and OpenEJB?

        I'll take a look at the Tomcat, Spring Hibernate combination. Hibernate is used in JBoss app server as well.

        • when does it (?) make more sense to use JBoss than Tomcat and OpenEJB?

          This is generally a matter of preference-- using JBoss (or Jonas, or Geronimo, or WebShere...) gets you the advantage of a single application server providing access to servlets, EJB, MDB, JNDI, blah, blah, blah, blah. There is nothing preventing you from breaking this up into discrete components and using just what you need, where you need it: Tomcat, OpenEJB, ActiveMQ, whatever. While every project should be evaluated on its own merits,

    • It's a common question. Since I work for JBoss, I suppose I'll sound biased here, but I would always opt for running Tomcat under JBoss. If you don't need the full range of features that JBoss ships with, you can run a stripped down version. Even one with just Tomcat. The new JBoss installer let's you easily set up such a configuration.

      Why would you want to do that? First off, you can use the JBoss deployment model. Just drop the WAR file /directory into the deploy directory and you are good to go.

  • I miss JBoss!! (Score:2, Interesting)

    by teutonic_leech ( 596265 )
    Just started a new gig and am forced to use WebSphere (WAS 5.x/6.x) and RAD. What can I say - it's a huge piece of turd and I miss using Tomcat/JBoss for real. There are great advantages to using commercial application servers - for instance WAS (and Weblogic) allows you to hotdeploy and debug your code while running it in your container right out of the box. Of course you can do that with JBoss as well, just takes a big longer to setup and configure. Some plug-ins like SolarEclipse attempt to address this

    • Re:I miss JBoss!! (Score:2, Interesting)

      by AKAImBatman ( 238306 ) *
      You should try Orion [orionserver.com] sometime. Everytime I'm forced to work with JBoss, I can't help but wish I was using Orion. ;-)

      Why is Orion cool? Because it combines simplicity in design with all the features you've come to expect in high end commercial app servers. For example, Orion was the first server that I'm aware of that had *working* hot-deploy for EARs, WARs, and EJB JARs. (JBoss supposedly had hot-deploy for EJB in earlier versions, but it never seemed to work *quite* right.)

      No other app server has managed t

  • Jboss Documentation (Score:1, Insightful)

    by Anonymous Coward
    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 popular
    • 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.
  • I wrote a JBoss tutorial a while back. It is for an older version of JBoss, but most of the content is still relevant today.

    http://ensode.net/jboss_intro.html [ensode.net]

  • JBoss-specific code (Score:2, Interesting)

    by sbenj ( 843008 )
    I've just finished a (small) project, part of which involved some services deployed on jBoss. Part of the development involved figuring out whether to use the built-in jboss MBean and Interceptor architecture. Initially I wanted to use as much of the built-in stuff as possibly, partly because it's silly to write things twice and partly becuase I wanted to learn more about JBoss.

    My personal experience, FWIW, is that taking advantage of the JBoss-specific architecture has its downsides:
    -you lock yourself in

  • "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.
    • Don't worry, you can buy support for that.
    • I'm dealing with the very same problem right now. You might be tempted to use JBoss "Support". Don't bother, you'll get better feedback from a newsgroup.
      JBoss support is the worst in the business.
      And some of the most expensive.
    • I know this problem, and maybe this can help you and others.

      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.

      We have over a dozen JBoss configuration files that are tweaked. When we upgrade we:

      • Diff between the original and tweaked version of of old release.
      • Apply diff to original of new release to get new tweaked file.

      In some cas

      • that's exactly the process i'm doing, and its tedious as hell and while we're at it, not entirely successful.

        in particular is the hassles that occur when one particular mbean declaration gets moved (or becomes "optional" when before it was required). there are a lot of those to deal with in upgrades that skip release generations.
      • Just say you know, there is no longer "for-buy" documentation. We released all of our documentation for free over a year ago. You can buy a print version of the app server docs, but that is the only form of "pay" documentation we've had for quite some time.

        (disclaimer: JBoss employee and author of the book being reviewed)

  • JBoss + Hibernate + Spring (Score:4, Interesting)

    by cbarcus ( 600114 ) on Monday August 29, 2005 @03:15PM (#13429691)
    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/

  • How many people out there use JOnAS as an alternative to JBoss? I've heard that JBoss now uses Tomcat as a base for the JSP/servlet stuff, just like JOnAS, so it's pretty much an apples-to-apples comparison now.

    How many people are using either of these as compared to more commercialized offerings such as Websphere, WebLogic, JRun, etc?

  • JBoss4? (Score:1, Informative)

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

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close