Way to keep minimal application-server dependency?

views:

answers:

+4 Q:

Way to keep minimal application-server dependency?

What is the best (easiest, most seamless) way to build a Java app while relying as little as possible on the actual application-server used in deployment?

For example, say I want to deploy on Apache Geronimo, and later want to use GlassFish, how difficult would the transition be? What is the best way to abstract the use of each app server?

Excuse my ignorance, I'm relatively new to Java development. I want to start a new project, but am unsure on whether to use separate APIs for the functionality I need or develop on top of a chosen app-server from the start.

Thanks for your help,

Ivan

+1 A:

From my experience with Jboss and Sun AS, you should just forget about AS-independency.

In sql, for example, you can do quite a lot without employing vendor-specific features. Well, it's not like that in JEE. For Jboss and SAS even 'hello world' applications will require different configuration. And more application grows, more vendor-specific features you have to use.

In particular, if you look at official Sun JEE tutorial, you'll find that it employs SAS-specific configuration files (sun-web.xml, sun-ejb-jar.xml, etc) from the very beginning.

But all above applies only if you use full range of JEE features (like EJB, JMS, mbeans). I've found that if you just have servlets/jsps packaged in one war-archive, such application can still be very portable.

Nikita Rybak 2010-08-24 04:42:33

You can write portable code, just don't use app server specific features (and app server specific deployment descriptors are another story).

Pascal Thivent 2010-08-24 04:56:12

@Pascal Knowing that your code is portable doesn't help you to rewrite lots of configuration files. And even though configuration descriptors aren't usually huge, getting them right is often tricky. Each AS has its own weird 'features' not evident to beginners.

Nikita Rybak 2010-08-24 05:00:12

With Java EE, you CAN do a lot without employing vendor-specific feature, I simply do not agree with you at all (and I've been involved in enough big Java EE applications to know that this is true).

Pascal Thivent 2010-08-24 05:34:21

@Nikita, IMHO - I think it depends on the AS. I first started JEE development on Weblogic which is really easy to build/deploy/configure/monitor for EJBs and was able to port it to Websphere with difficulty on config (looking up for equivalent tags and server conf files) - but not much changes to the code itself.

JoseK 2010-08-24 05:51:20

@Pascal Can you do 'hello world' ejb without vendor-specific configuration? In what server?

Nikita Rybak 2010-08-24 05:52:18

@Pascal Sorry, I deleted my comment because you changed the comment I was replying to. In general, I just don't see why anybody would want to get the same configuration headache twice. Much easier to choose the server you want first. Never worked with Websphere or Weblogic, though.

Nikita Rybak 2010-08-24 05:57:42

@Nikita You can do a "hello world" EJB (and even real world apps) without vendor-specific deployment descriptor. This is exactly my point.

Pascal Thivent 2010-08-24 06:16:56

@Nikita I've done several projects (with Stateless Session Beans and MDBs) where JBoss was used as "development" server (easier and faster to use for development at that time) while WebLogic was used for production. It just works, without headache. I would do it again. And I'm currently using GlassFish 3 intensively and I've still not used anything app server specific.

Pascal Thivent 2010-08-24 06:24:16

@Pascal Then how come official Sun's JEE tutorial (not SAS tutorial) doesn't show that? They use SAS-specific descriptors in almost every section and in the most basic examples. http://download.oracle.com/javaee/5/tutorial/doc/

Nikita Rybak 2010-08-24 06:26:33

@Pascal You mean, in Jboss you can inject one ejb as dependency into another without jboss-specific configuration? Sorry, but I find that hard to believe. (And that's even not so rare task)

Nikita Rybak 2010-08-24 06:33:10

@Nikita Absolutely, you can. But I'm done now, I made my point, I do not agree with your answer.

Pascal Thivent 2010-08-24 06:46:06

+3 A:

Without getting into too much details, even though you can write bare-bones JEE code, the configuration around it is not very simple. Each application server has its own set of configuration files and naming conventions (for example, the format for specifying the location of the AS is different in IBM WAS and in JBOSS). Though these are not very important for application development, once you get to the deployment phase, these will become important. As far as the libraries and your code is concerned as long as you stick to EJB standards you will be able to run your application on majority of the application servers (I know of WAS and JBoss - the code that I wrote didn't have to change for these servers; the configuration though, well that was a different beast !).

Gangadhar 2010-08-24 04:50:33

Agree. The basic code eg: Struts or MVC framework, Spring, EJBs , servlets, POJOs can be used across app servers. If you've hardcoded JNDI lookups to Datasources etc in the code then those will change. Other config stuff like no of threads, JMS config etc all will change on each AS.

JoseK 2010-08-24 05:45:54

No, the format to specify the location of a JNDI server is not different. The values are though.

Pascal Thivent 2010-08-24 06:13:07

Thanks for your help guys. As Shengyuan also mentioned in his answer, sticking to the JEE specs as much as possible will minimize refactoring and the inescapable configuration pain at deployment. I have lots of reading to do... :-/

imiric 2010-08-24 23:27:02

+2 A:

Follow JEE specification as much as possible, while follow server specification least as possible.

If we try to find out what are in common among there JEE application servers(JBoss, WAS...), answer is JEE specification which server vendors must follow. If you have 2 solutions on a JEE problem, you could check which solution comply with JEE specification better rather than server specification.

卢声远 Shengyuan Lu 2010-08-24 04:58:41

If only it was so easy in real word. On one side, vendors often interpret specification differently. On another - JEE provides rather minimal set of tools and it's often tempting to use server to its full potential.

Nikita Rybak 2010-08-24 05:04:21

@Nikita Please, give concrete examples of Java EE "interpretations". Please give concrete examples of things that you can't achieve with the huge standard Java EE platform because of the minimal set of tools. This does not reflect my experience.

Pascal Thivent 2010-08-24 05:36:04

@Pascal With _each_ new feature I had to add something to jboss.xml, jboss-app.xml or other jboss-specific configuration files. Usually they're as big as generic JEE configuration files (ejb-jar.xml, etc) To me, it does make JEE specification to sound kinda incomplete.

Nikita Rybak 2010-08-24 05:47:20

If you have the resources then consider developing and testing for several application servers instead of just your initial target one. This will allow you to - from the start - pinpoint things that need to be configurable and code accordingly.

Personally I would consider Glassfish 3.0.1 in such a situation as it is the reference implementation, so things should at least work there without any special efforts.

Thorbjørn Ravn Andersen 2010-08-24 06:23:51

ansaurus

tags:

views:

answers:

Way to keep minimal application-server dependency?

related questions