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.
First, In reading the actual org post at no point doe sit give the impression that JBos sinvented JMX.. Second, a microkernel refers to a designb in which the J2ee server is microkerneled meaning there is a bsse setup of MBeans that form the JBOss core and additional MBeans that add configurable stuff oin to the server core.. ..If Geronimo can use micokernel def so can JBoss and in fact they did long bfore other IOC containers started using the term..
In contrast Most complex systems do in fact approach kernel achitecture layouts ..fopr example..
Apache web server, CIsco routers..and etc all use the term kernel..
Fred Grott(aka shareme) http://mobilebytes.wordpress.com
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.
This entire story is crap because it WAS NOT POSTED BY ZONK! What's up with Slashdot anyway? Don't they realize it's Zonk's blog?
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 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.
R(k)
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 and they are doing a great job (however they're commercial ;-)
Anyway, fact is that JBoss is based on JMX and that modular design is simply superior. Another fact is that JBoss has matured to a level where it frankly can do anything any commercial J2EE container can do. Unless you've already standardized on Websphere or Weblogic, I just don't see a reason not to take a very serious look at JBoss - it runs fast, it's stable, and there is plenty of support (and great books, obviously).
Just my 2 cents for all it's worth.
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 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
Expert Java EE Consulting
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.
My personal experience, FWIW, is that taking advantage of the JBoss-specific architecture has its downsides:
-you lock yourself into jboss (not a horrible thing, really, how often do you want to change the appserver of a running application, but annoying)
-some of the implementations appear to be version dependant, e.g. your jboss-specific components might break when you upgrade
-there's are undocumented hurdles-e.g. I spent hours trying to figure out why my mbeans were refusing to load, eventually googled a mail message to learn that it relies on an (undocumented, as far as I can tell) naming convention.
In the end we just did POJO with MBean access to some basic parameters. But there's definately an (unfriendly) learning curve.
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
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.
What is your beef with Java? Java is excellent for server-side applications. Not so much for client-side, I agree, however there are some impressive java applications out there. (Limewire, Open Office, etc). JBoss and J2EE application servers are very good. I prefer a simple Tomcat server over JBoss myself. Not everyone should program in Java. Just web developers ;)
Why? Object Orientated Programming language. Very well documented. Code runs on multiple platforms. Interpreted language. (Running applications on a virtual machine gives you an extra layer of security between the application and OS).
There's no place like ~/
Save yourself FOUR BUCKS by buying the book here: JBoss - A Developer's Notebook
My beef with Java? Unpleasant to use.
I love Azureus... in fact, I cannot stand to use any other linux bittorrent client... but I really dislike using it. Conflicted? Why, yes I am!
It is slow to start, slow to react while already running, takes up far more processing power than reasonable, takes up far far more memory than reasonable, and the memory usage/processing power requirements grow over time. My computer can keep going for weeks at a time, but I have to restart Azureus every couple of days or else it becomes GUI-unresponsive. (I don't know if it actually stops working... can't tell; the gui is just no longer refreshed.)
And these annoyances are pretty typical of my other Java (admittedly client-side) experiences.
I'll take your word of its strengths on the server side (and liking Python, I cannot disagree with your argument). But I really must say client-side Java is probably as much a curse as it is a blessing to more serious and useful Java technologies.
Akarsz Magyar Gentoo fórumot? Akkor
"if(!(new File(name+".lck")delete())) log.debug("couldn't delete: "+name+".lck file.");" Well, I'm currently working on developing a swing-based desktop app. Originally it was to be developed in VB thank god that got changed. What other option is there for doing a full blown desktop application?(sort of rhetorical, but I'm interested.. how many languages have real support for creating gui's? is there a way to do a gui in lisp? seems so improbable to me). I guess we could have gone with C or C++. I would like to do some C, C++ since I haven't really touched it since college, but I wonder what the difference in development time would be (minus the fact I'm more up to speed with java than C). The J2SE library is huge and so easy to use. In my spare time I took a look at the MFC library and some tutorial code for it and wanted to vommit. Still I guess I'm not entirely ready to give up on c, c++ coding for windows, if someone could recommend a free ide/compiler (I loathe what visual studio did to my computer when I installed it some 4 or 5 years ago) for use on windows I'd appreciate it.
- 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 cases a bit of manual work is needed, but not too often. There is a lot of information on this in the official JBoss for-buy documentation. If you do not want to buy the official documentation, please have a look at the DTDs for the XML files, as they generally are well commented. As a last resort you can also look at the source, but personally I only had to do that once (in 5-6 upgrades).if someone could recommend a free ide/compiler
x
Too bad if you don't like MS, but they still make the best development tools. These are still BETA and will do nasty things to your box, so you might want to wait until the 2005 release is released.
http://lab.msdn.microsoft.com/express/default.asp
I prefer a simple Tomcat server over JBoss myself
HMMM. Tomcat is the web container in JBOSS so what you're saying is: I'm not really familiar with JBOSS but I don't want to pass up this opportunity to look smart. Bravo.
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/
wow ok I should actually preview my posts... damn cut and paste... was supposed to start with this quote: "Not everyone should program in Java. Just web developers ;) " //I have no idear how that code got in there I swear I'm not at work.
Thanks, but no thanks... I've had issues with Visual studio fubarring my box, definitely don't want to play with beta software development tools. Why should software dev tools mess with the OS? Unless they are just as entangled with the kernel as IE? Anyone else has suggestions for C/C++ gui application development on a windows box?
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.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
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?
Constitutionally Correct
Alright, another kaleidojewel affiliate link. Had to use redirects this time, huh?
Fuck you kaleidojewel.
The only contender in the long run I see currently is Ruby, with their excellent rails framework.
I would hardly call a framework where the object model has to be defined as database tables, and you then end up locked into a particular database product for the lifetime of your application 'excellent'. Compared to other systems, like Hibernate, where data can be defined as true objects, this is a huge step backwards.
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)
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..
Here is a link to get a hard copy of the JBoss Administration and Development manual (150 pages = $8.50) from PrintFu
Spoken like someone who has never used (or priced) JBoss support. On the other hand, people who actually are JBoss support customers
have a different opinion. (note, that is from people who have used JBoss support AND support from other vendors)
(disclaimer: JBoss employee and author of the book being reviewed)
Surprisingly many. GTK+ website lists, unless I coffeedly counted wrong, 29 supported languages. Can't seem to find the list of languages supported by Tk, but I presume mindboggling number of languages have Tk bindings (not as slick as GTK+, but more cross-platform, for sure). And, a lot of languages have way to mess with C/C++ functions, so you probably could write a wrapper you need yourself...
Sure there is! Pick any of the dozens of ways! Most are for X11 but some cross-platform ones are there too, like Tk and GTK+ and Qt =)
Right on, I could not believe the parent response was modded up, but I don't have anymore mod points...
People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf.
Gee, it really sounds fantastic. Did you notice an increase in the girth of your penis as well, thanks to JBoss ?
Hmm...
;)
Isn't it nice, though, that you can be a server-side Java programmer during the day at work, and use the same skill set at home to hack together your client-side hobby projects?
Isn't it nice to be able to focus on a single language and really master it, instead of trying to keep several balls in the air at once?
Isn't it nice that if you ever wanted to, you could write an applet for your website instead of having to pay five hundred bucks for Flash authoring tools?
After all, with Java, the difference between web development and client-side development is just the libraries you choose... Isn't it "one stop shopping"?
Right?
Farewell! It's been a fine buncha years!
If you think Python apps are slower or worse, that Python is NOT an improvement over Java "language wise", it pretty safe to assume that you have absolutely no clue about Python.
Since you are clueless, let me explain why...
Python bytecode may execute slower than Java's but much of performace sensitive code in Python is typically executed through native modules usually written in C. The result is Python apps run faster than Java, take less memory and start faster because Python programmers are not silly about making everything in PURE Python.
As for as the language, what did you do with Python? Write some "if statements" and decided that it's no different than Java? Python is a dynamically strongly typed language and that is a VAST improvement in productivity, assuming you know how to take advantage of dynamism than just thinking that it is just something so that you don't have to worry about specifing types. If you think classes are cool, you need to look at Python's metaclasses. You can completly change the way classes behave (No! That is not same as inheritance. With metaclasses you reconfigure the very behaviour of the class construct, not just the code in it). And that's just the begining.
http://www.objectstyle.org/cayenne/index.html
http://jakarta.apache.org/tomcat/index.html
http://jakarta.apache.org/tapestry/
http://www.eclipse.org/
http://ant.apache.org/
Choose any database you want. Tapestry is simply AMAZING!!! Everything is a component. It is like have all of the coolest legos and building sites in not time. Also, if you don't like the block, it is EASY to make custom components. Howard Lewis Ship is a genius.
Okay, the Java world needs to really wake up and start buying into Cayenne. Get off the Hibernate kick!!! All I see is ways to improve Hibernate and Cayenne already has it all in place. Plus Cayenne and Tapestry were made for each other.
J2EE was a nice try, but way, WAY too complicated. Both Cayenne and Tapestry are straight-forward and easy to use, IMHO!!!
You are right. Very well said.
There's no place like ~/
Why should I use your companies product instead of suns app server?
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.
-Stu