aspose file tools*
The moose likes JBoss/WildFly and the fly likes Why JBoss? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » JBoss/WildFly
Bookmark "Why JBoss?" Watch "Why JBoss?" New topic
Author

Why JBoss?

Saeed Amer
Ranch Hand

Joined: Jan 20, 2004
Posts: 140
Hello aothors,

The fact that JBoss is industry standard, open source and free App Server does not necessarily mean it is the best option available. Does your book cover any comparison of JBoss with other leading App Servers available on the market, like WebLogic, WebSphere, etc.

What is it that would help make JBoss a choice over the others (excluding the 'price' factor)?

What was it that made you write a book on JBoss and not on any other App Server?

TIA,
Saeed
Tom Marrs
Author
Ranch Hand

Joined: Sep 20, 2000
Posts: 67
We wrote the book on JBoss rather than on other application servers becasue we felt that there were already enough good books on WebLogic and WebSphere. We also felt that the JBoss community was under-served - there just wasn't enough good documentation for developers. Everything else was about JBoss' architecture and internals. As long as an application server is J2EE certified and runs well, we don't need to know all the details of the server's architecture/internals. Since J2EE is a specification, we just wanted to show how to develop and deploy applictions on JBoss.

Our book doesn't do any comparison between JBoss and other application servers. It's for developers who want to use JBoss.

OK, other than the "price" factor. That's a tough one. I still like JBoss because it works well. Right now, they're the ones that are pushing the J2EE standards committees to simplify the J2EE and make it easier. I also like the fact that JBoss (unlike some commercial vendors) still has the same core architecture/code base in place. Granted, they've made upgrades over the years, but they've never had to scrap everything and start over.
So, for me, it's also stability, J2EE compliance, thought leadership, and quality of product.
Saeed Amer
Ranch Hand

Joined: Jan 20, 2004
Posts: 140
Thank you Tom, for taking time to reply.

Reason for my rather naive questions was many fold:

I am NOT a J2EE developer (as of now) but I am quite a bit into it. I have worked with Core Java/JDBC for quite sometime. I have spent time learning Servlet/JSPs (scjp+scwcd certified - big deal!!) and now I am investing time mastering the EJBs. So, for learning and practicing EJBs, I am using JBoss 4.0. I plan to write the scbcd exam soon.

Most of the job postings that see on job-boards/forums usually require people to have experience with WebLogic, WebSphere, etc and I see very few (if not none) looking for people with JBoss experience. This concerns a bit - though I know JBoss seems to be as popular as these expensive App Servers.

I don't know much about tuning and customizing App Servers in general and JBoss in particular but I hope your book covers this topic in substance.

I haven't used any other App Server (other than JBoss) and I am not sure how do they differ when it comes to deploying code (deployment descriptors, relationship declaration, EJB-QL, etc). Would I be able to deploy my code/descriptors to any other App Server without changing my "XML (descriptors, datasource, etc)" files? I fear there is more to it than just deployment descriptors. If you happen to have some idea (I am sure you do), I'd appreciate if you could kindly shed some light on it (though this is not the topic of discussion).

I haven't seen the book yet but all I hope is that it would be a good read. I appreciate your time inadvance!!

Best regards,
Saeed
Tom Marrs
Author
Ranch Hand

Joined: Sep 20, 2000
Posts: 67
First, we don't go into tuning/customizing JBoss. Again, the JBoss Wiki and reference books already do a good job of that. Our focus is on development and deployment.

Second, J2EE portability. Your code shouldn't have to change when you port between application servers. Your J2EE-standard descriptors (application.xml, web.xml, and ejb-jar.xml) won't change. But if you use JBoss-specific descriptors (joss-web.xml, jboss.xml) in addition to the J2EE standard descriptors, then you have a little bit of work to port the application. Since I use XDoclet to generate everything, I just change the XDoclet tags in my Servlet(s) and EJB(s) and I'm done. In 2004, I ported from JBoss to Oracle 91AS (the client wanted me to) in about a day. It was pretty easy, but you have to know your way around the J2EE specs and deployment descriptors.

There are no standards for DataSource deployment. It's different between application servers right now.

I hope this helps.

Tom
Saeed Amer
Ranch Hand

Joined: Jan 20, 2004
Posts: 140
Thank you again, Tom!! I think I am definitely going to enjoy reading your book!

Best regards,
Saeed
Will Fleming
Greenhorn

Joined: Sep 28, 2005
Posts: 20
Originally posted by Tom Marrs:
We also felt that the JBoss community was under-served - there just wasn't enough good documentation for developers.



I have to agree--I am definately a newbie with jboss, but it has been a lot of work trying to find good documentation.

FWIW, your book was my second choice. I went with the developers notebook because I saw a few good reviews and it looks quick and dirty. I just want to get up and running right now in a test environment so that is all I need. If/when I decide to actually depoly the application in the real world, I will come back for a more complete guide.


SCJP 1.5
Tom Marrs
Author
Ranch Hand

Joined: Sep 20, 2000
Posts: 67
Will,
The developers notebook is a good place to start, too. I wish you the best with it.

Tom
Eiji Seki
Ranch Hand

Joined: Feb 15, 2006
Posts: 88
If you want to avoid compatibility problems, just stick to the J2EE standards no matter what. Also, avoid anything that just doesn't look right (for example, strange JSP tags like <html:text value="<%= xxx %>" /> . If you do so, you will have no or few problems.

Deployment and configuration is a whole different issue. Since they are container dependent, each one has different aproaches. But even so, all you need is to learn how it is done in each container.

For example, I also use XDoclet tags in order to generate JBoss deployment and configuration, because JBoss works with the jboss-web.xml and jboss.xml files Tom was talking about. Notice that I don't use JBoss-only non-standard extensions, I just use those files for deployment and configuration purposes.

WebSphere, on other hand, is not XDoclet configurable (at least I wasn't able to do so, but since I haven't really needed it... hehe). Look's like it's recommended to use IBM's free packaging application, since it does most of the work you would need to do at deployment time otherwise.

What we do is to include most deployment info as possible. For example, since JBoss files are easily created with XDoclet, they are included in every package, even if it is going to be deployed on other application server. After all, the files being there do not hurt anyone, just make the file JBoss compatible.

I would like every application server to support default ear-contained configuration files so deployment configuration is much easier. This way, we should be able to include default configurations for all appservers and then change them case by case.


SCJD URLyBird (WIP)<br />SCJP 1.5
 
wood burning stoves
 
subject: Why JBoss?