Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Minimizing EAR Redeployment  RSS feed

 
JC Bustamante
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have an EAR file containing a generic module which acts as a generic MDB as well as a number of JARs representing our services which is invoked by the MDB. The problem that is occurring is that whenever we change a module, we have to redeploy the whole application. I was wondering if there is a way to separate our JARs from the EAR file so that we can plug it into the server's deploy directory whenever a change is made. Can anyone help me out here?

Thanks in advance,

Juan
 
Scott Selikoff
author
Bartender
Posts: 4093
21
Eclipse IDE Flex Google Web Toolkit
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the world of J2EE/EJB development.

Redeploying an EAR is often a *huge* pain and can take 20-30 mins for some systems. There are some tools for different server environments (RAD on WebSphere for example) that will do faster hot-sync deployments, but these are often far from perfect. Most servers support immediately redeployment of JSPs if you drop a new JSP file in, but this setting often has to be enabled.

You could export EAR contents into JARs and drop them in the server's lib directory, although this seems counter-intuitive for a number of reasons. For starters, it will require you restart the server which could take just as long as deploying a new EAR. Second, you shouldn't place application JARs on the server level as a common practice, it should be only for server-related tools like Axis, log4j, etc. If you use singletons (static objects) especially in your application, moving the JARs around could create complex class loaders that span the whole server and break proper functionality. Lastly, if the JARs really aren't changing much then you shouldn't be redeploying at all, so the whole notion seems backwards.

In my experience, the only consistent solution is to use a faster computer. This is why J2EE applications are considered heavy weight, if the developer's machine is too slow, it can seriously affect developer productivity.
[ May 05, 2008: Message edited by: Scott Selikoff ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!