Slashdot Mirror
Sun 'Calls JBoss bluff' on J2EE compliance
joshmccormack writes "According to c|net's news.com Sun has finally responded to JBoss Group's request for J2EE compliance testing.
Simon Phipps, Sun's chief technology evangelist stated in the article he thinks JBoss Group is bluffing, that their code won't pass the tests, and that some of the code is just copied from Sun."
The J2EE standard doesn't cover everything you'd ever need to do to get an application off the ground.
eg, most enterprise applications allow you to connect to a database. J2EE defines a way of naming the database connection ("DataSource") with a logical name. Say "MyBigDB". This is a name bound into a JNDI tree - basically a directory. Give the directory "MyBigDB" and you get back an instance of DataSource that can connect to your database.
At some point these convenient names "MyBigDB" must be mapped to actual parameters (hostname, username, password, port number) of the database.
J2EE doesn't really specify this. Each vendor has their own config file syntax for doing this mapping.
So this is the sort of thing they mean when they say it takes "hours" to port. You find out where JBoss keeps its config files, what the syntax is, and how to map MyBigDB to the hostname etc.
Hopefully none of your code changes, its just a matter of defining mappings in config files. The more complex your application, the more points of contact with "the real world" or "the bare metal" it probably has. J2EE hides a lot, but it can't hide everything.
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
Even beyond discussing non-standard extensions, there are facets of application development/deployment that are not covered by the J2EE spec. Therefore, in order to provide the environment the application expects, there is application-server specific configuration that must go on.
Specifically, this is often the case in setting up the JNDI tree for the application and for the individual components (java:/comp/env/) as well as configuring features like EJB 2.0 CMP where you must map database fields to Entity EJB fields, and configuring the specific JMS queues and topics that you want to connect your Message Driven Beans to.
JBoss uses a jboss.xml config file, BEA WebLogic uses a different configuration file, and other application servers use their own file formats and tools. JBoss offers a tool that helps migrate WebLogic configuration files to their XML format. This doesn't cover non-standard extensions, but it does cover converting many of the application-server configuration options.
I used all 3 most popular containers (JBoss, WebLogic, Websphere) and seems that JBoss is the best choice. Websphere was always late with standards and Weblogis was always ahead (Websphere was EJB1.0 + some 1.1 compliant when Weblogic had almost all EJB2.0 features), but Weblogic had many errors in it's bleeding edge versions. JBoss was developed fast and with latest specs in mind but I didn't encountered any real problems.
-- mg