What are the main issues to consider when this company (which I have contracted with) wants to develop under JBoss (during R&D) with the intention of eventually transitioning to their established production WebSphere environment?
This is dangerous because you have different deployment descriptors and setup between different application servers. You really need to be developing/testing to the same type of environment you'll see in production. Your tests could pass in a JBoss environment, but they could break in your WebSphere production environment. You have to be concerned with not only your code, but deploymnent descriptors and your application server setup.
If you're going to use WebSphere in production, then use it for R&D as well. Then, when you're tests pass, you're confident that production will go smoothly, too.
If you continue with JBoss for R&D, and WebSphere in production, then you need to also concern yourself with deployment descriptors. Make sure that you're using Ant/Maven plus XDoclet to generate your descriptors - you should be OK if you do this. But after you're done testing against JBoss in your R&D environment, I would deploy on WebSphere and run all your tests to make sure things will work in production. But, I still think this is a bad idea because it makes your developers' Unit tests meaningless.
Joined: Jan 23, 2006
Thanks. I kinda thought so. I wish the dangerously product-specific deployment descriptors were identified somewhere.
Despite the title, the book takes great pains to be a vendor-neutral J2EE book. We point out each JBoss-specific issue in a sidebar. The code tends to be container-neutral, but the deployment descriptors are container-specific.
XDoclet and Hibernate go a long way towards mitigating container-specific brain damage.