Reload recompiled servlet

[eelgueta]

Hi All,

I'm developing a servlet and I have to restart JBoss everytime I recompile de servlet class. The alternative is to let the session expire.

Is there any configuration or procedure I can apply to reload the servlet class?

Thank you.

Ed.

[jonlee]

Assuming that you are working with an exploded WAR (as it appears), just "touch" or otherwise modify the date on the WEB-INF/web.xml for the WAR. If you are using Ant, use the touch task for this purpose.

[eelgueta]

Thank you very much.

[carfield]

I can't config JBoss to reload servlet class automatically, just like what jsp does?

[jonlee]

I can't think of a way off-hand that Jetty or Tomcat would normally deal with this other than a redeploy of the context - which is what we are doing. Servlets are built for stable production services, precompiled, preloaded and no wait time - they have an advantage over JSPs in this respect. The disadvantage is that to reload them, you need to reload the whole context - this is the effect of touching web.xml. This is less of a JBoss issue and more of a servlet container architecture issue I think.

[lauerc]

According to the documentation, Tomcat does support reloading of web classes (see: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/loader.html)
Is there no way to configure the embedded Tomcat service to behave like described in that doc?

Best regards,
Christian

[jonlee]

This requires the catalina class loader and the catalina class loading scheme. The JBoss architecture uses its own class loading system.

Also, Tomcat employs its own scanner that monitors every file for change when this option is used - as they note, this is quite intensive in terms of processor overhead. JBoss and Jetty employ a less intensive approach and also simplifies their redeployment strategy.

You could write your own MBean for both scanning and redeployment but as JBoss already deals with a quite complex situation (much more so than Tomcat), this could have side effects with overall JBoss performance and perhaps reference resolution. You would also probably have to make use of the loader-repository attrbutes to separate these loaded classes from the standard unified class space.

However, I do stand corrected - Tomcat does have an individual class redeployment strategy (although not designed for production).

[lauerc]

I'm working in a team of four JAVA Developers, we're using BEA WebLogic Server for about 2.5 years. This year I have brought in JBoss and I'm very happy with it except of the inability to reload servlets classes and some current JMS problems (but that is no issue for this topic). The problem is that expecially this feature works very well on WebLogic Server, and it's very hard to find arguments for my team collegues to move to JBoss when they have always to redeploy their whole application for any single bugfix during development time. This tends to happen very frequently and it's not very produtive if you every time have to reploy your web application, because on that the sessions are killed. To test your changes, you then have to relogin into the application and to bring your session into the specific state, which really sucks.

On BEA WebLogic Server this specific developement step takes about 5 seconds, at JBoss it takes more than half a minute - just because of the inability to reload servlet classes.

You have mentioned that it's possible to write an MBean to reach that desired behaviour, do you have any hints for me to do that? are there any examples?

I really would love to use JBoss more and more (maybe even to kick out BEA), but this requires at least this disadvantage to be solved.

Best regards,
Christian

[jonlee]

As always, there are plenty of examples with open source. The JBoss deployment service is built from MBeans. Look at the end of conf/jboss-service.xml to see the expected operation of the deployers used. If you then look at the System branch of the CVS, you will find the deployment source files. Since you are working within this scheme, you probably want to tag off these systems.

You'll want to specify what areas you want to watch for WARs and their content, and this will probably have to fit within a new attribute for the URLDeployer, if you are using that. It will need to be passed to something in the custom WAR deployer. The cleanest code to look at is the SAR deployer and JAR deployer to understand the basics. You will need to set the watcher to monitor the required files - I guess you should define in the new attribute not only the WAR but the servlets in the WAR to watch. Also pay attention to the Repository code as I suspect you will want to make use of it, rather than pile your development classes into the unified class space.

These are just suggestions as I have done little more than glance at the code in the past to determine if it was creating some memory problems (which it wasn't).