aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Patching an EAR and the like Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Patching an EAR and the like" Watch "Patching an EAR and the like" New topic
Author

Patching an EAR and the like

Richard Grey
Greenhorn

Joined: Nov 21, 2001
Posts: 25
How can you patch an EAR ?

Scenario:

We have a client.ear deployed to our application server (although I don't think it matters which, it's Borland Enterprise Server v6.5) that is live in production.

For a critical fix, we would ideally like to modify the offending class(es) and include these in a new Patch001.jar.

But of course, we can't. The classes in the EAR file take precedence via the app server class loading mechanism.

What patching strategies do other people use in situations like this ? Or do they rebuild and redeploy the whole EAR again with the modified classes ? Why can't I just "tack on" a Patch001.jar (or EAR for that matter) - lots of other software solutions release fixes like this ?

Cheers.
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Richard,


What patching strategies do other people use in situations like this ? Or do they rebuild and redeploy the whole EAR again with the modified classes ? Why can't I just "tack on" a Patch001.jar (or EAR for that matter) - lots of other software solutions release fixes like this ?

I�m not sure about other containers, but with weblogic one cannot do any patching the way you described it. One solution that will always work is to add the patch to the system classpath and restart the server. Then what is the benefit over redeploying another version of the ear? This is actually much better since it deploys without restarting the server and is not that messy (imagine adding more and more patches to the system classpath). Your "patching" issue is actually resolved through versioning, when multiple version of the same app could be available at the same time. It also could easily be solved redeploying the same application. Most containers provide very nice features or command line tools for doing that.
Regards.


I think, therefore I exist -- Rene Descartes
Richard Grey
Greenhorn

Joined: Nov 21, 2001
Posts: 25
Thanks Valentin.

I agree. The benefits are in hot deploying a new version of the EAR.

I think the main issue I need to address is making sure that only the classes that have changed are recompiled.

The problem arises from the fact that if I rebuild all the classes, something "potentially" could have changed, despite the fact that the source hasn't changed apart from the sources being patched.

Besides, the ear is always going to change as new stubs etc will have to be generated for potentially changed classes.

I think we ideally wanted to have a clean, tested EAR file that remains untouched - which therefore doesn't require retesting - hence the requirement to be able to add a separate patch.jar. A fair enough request methinks, but perhaps slightly off track for J2EE development ?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Patching an EAR and the like
 
Similar Threads
Problem in invoking ejb from different .ear
Packaging ear for JBoss
jboss hot deployment issue / smart solution needed
How to specify library need by EJB in same EAR file
In Eclipse, how to add log4j.properties to classpath ?