I am thinking of trying JBoss to keep my J2EE skills up. I am currently working on a Java project that is neither web related nor J2EE.
From looking at the website, http://www.jboss.org/, it looks as though JBoss is Free for both development and production. I guess they make their living from support and selling detailed documentation.
Anyway, I was wondering if anyone out there had used it.
I'm in the process of figuring out J2EE as well, and i found JBoss to be really confusing for a simple newbie like me. If you're just looking to get to grips with the basics, then why not give openejb a try?? It is free (GPL i think) and works on a simple command line interface. Their docs are good as well, i found working with this far easier than jboss. Here it is:
Oh, and the JBoss people make their money from consulting and selling training and docs. You'll be hard pushed to find some decent, free, up-to-date docs for jboss cos they want your cash!!! (can't blame them really....)
The primary focus on my career path is getting productive in J2EE, and I know J2SE well. I find that Sun's Appserver is more involved than JBoss, so I'm starting with JBoss.
In contrast, JBoss uses a similar means of configuration to Apache Tomcat. I know Tomcat servlets well enough to get and keep things up and running cleanly, and that paradigm suits me. Searching and tweaking XML config files, plus making things right for the Apache HTTP server front end stuff is what I prefer to popping up layers of GUI frames, tabs etc. and the app setups the "other guys" use.
JBoss has it's own XML config files like the J2EE standard with the same directory layout and similar file names, just with different elements for the JBoss specific parts.
There is also a Web interface for some things, which Sun Appserver also has. Sun's Web interface is visually nice, even looks somewhat fancy, but JBoss' is all about information, no fluffiness. Both trash comments if you save the info, but they are nice for listing all options and their default values.
The approach I'm using is the standard method of learning a new middleware platform: install, read the tutorial and follow the tutorial demos. Then tweak on the demo to see what entry points there are which would be useful next in a pilot project. Finally, bring forward an existing Tomcat servlet to run under JBoss as the middleware management layer.
I had JBoss 3.2.4 running on my production server using the 2.4 kernel, but the 100MB overhead was too much, and I had to remove it. Then I started with JBoss 4.0.0 on my development server running Fedora 2, but I had the wrong tutorial version which is an incompatiblity. Otherwise, it ran smoothly. I'm currently using JBoss 3.2.6 on the Fedora 2 box with no problems running the correct Sun tutorial example.
The JBoss tutorial recommends reading Sun's "The J2EE Tutorial" first. Makes sense, since Sun's is the reference implementation, but it's 500+ pages. I've only briefly read a few parts relevant to my questions.
The JBoss tutorial is called "Getting Started with JBoss", and it's only about 67 pages, a much smaller bite than Sun's. I'm on page 36, Container Managed Persistence, which is what I expect to use for doing something useful. I've already done the previous chapters.
I suppose that you "other guys" interested in doing some .NET would find Chapter 7 "Web Services with JBoss.Net" an interesting topic.
I went over the 4.0.0 tutorial. The .NET implementation is more matured on that version, so I would suggest to people going to use JBoss with .NET to start with JBoss 4.x.
About IDEs: The JBoss people clearly think Eclipse is the best one to use for JBoss, unless you have money to burn, etc. I used JBuilder for two years, but I'm using Sun's netBeans IDE 4 beta now.
The JBoss group is a proponent of using Aspect Oriented Programming (AOP) with their product. I would like to know what people's general experience, impressions and suggestions are in the AOP space. I only understand that it's a security-focused paradigm.
Aside: I've converted my Tomcat servlet to J2SE 1.5 aka Java 5. Converting the Java source to Generics took some refactoring. Also, the Struts error message constant moved, so some JSP pages had minor package path changes. I felt lucky that it was a minor task.