views:

122

answers:

2

I have a java app that works with an EJB, however if:

  1. The EJB gets updated, the app is broken.
  2. The app server is updated, the app is broken.

Without human involvement, is there a preferred method to update the client jars for the app server and bean?

If there preferred method depends on the app server, then assume jboss.

A: 

That's one of the reasons people are migrating to web services :) Or use JMS, too.

Really, if your app server is upgraded or vendor is changed, there is no way your old/foreign stubs will work with new code on server side. :-(

Remember EJB declared there should be an application deployer role? It's up to him to prepare client.jar for client applications and distribute it (or may be it's the application packager? doesn't matter; the point is: it's not an automatic operation).

Some tricks may be possible (like demanding placing client.jar onto specific place on the server to download it by client first, then use class loader to use), but those are more hacks than established practice.

As for JBoss specifics, I have no any information.

Vladimir Dyuzhev
A: 

You're basic problem is that if the interface contract between one component changes it breaks the other component. This is not a problem limited to Apps and EJBs, it just isnt compiler safe.

The only automated approach that I know of is to setup your projects in such a way as to make the App project dependent on the EJB project (within the IDE and build files), giving you the compiler checking. And deploying them together as an EAR.

If that's not an option, and they must be deployed separately, than your EJB developer needs to be on his game about keeping backward compatible interfaces intact.

For interfaces we have two. One that uses our serialized objects and limited one that uses only java objects.
TJ