jetty and redeployment

[pascalpt]

Hi,
I'm normally using jboss-tomcat for development and I'm currently giving jetty a try. Is there any way to have jetty not trash all the http sessions and compiled jsps on a redeploy like it's possible to do with tomcat? It's a major slowdown when doing a lot of redeployments to have to wait for every single jsp to recompile when only one or two have changed. Same goes for having to relogin to the webapp but that's not nearly as annoying.

Thanks

Pascal

[pascalpt]

Is it the only way it works right now? Can it be configured?

Thanks

Pascal

[jules]

You are asking for 2 things -

1 preservation of JSP classes between JBoss instances - this would be tricky since on being taken down, JBoss will undeploy your webapp and Jetty will remove associated directories - I will check. Can JBoss/Tomcat preserve these ?

2. Persistent HTTP Sessions - I have put a lot of work into JBoss3.0.1 to support distributable sessions. See docs/examples/jbossweb/FAQ and jetty-web.xml. If you use e.g. a CMP based store for your sessions, you should be able to retain them between different instances of your JBoss.

Does that help ?


Jules

[jules]

You are asking for 2 things -

1 preservation of JSP classes between JBoss instances - this would be tricky since on being taken down, JBoss will undeploy your webapp and Jetty will remove associated directories - I will check. Can JBoss/Tomcat preserve these ?

2. Persistent HTTP Sessions - I have put a lot of work into JBoss3.0.1 to support distributable sessions. See docs/examples/jbossweb/FAQ and jetty-web.xml. If you use e.g. a CMP based store for your sessions, you should be able to retain them between different instances of your JBoss.

Does that help ?


Jules

[pascalpt]

Thanks for the reply Jules

1.
Yes it does, it's an extra parameter in the configuration of the web container service that was introduced in 3.0.1. It used to just do it by default before 2.4.7 and didn't do it at all for 2.4.7 (I didn't check 2.4.8) and 3.0. I didn't look into the code but my guess is that it preserves the generated class and source files in the work directory and then just compares the timestamps. Again I don't know exactly how it is implemented but the result is that if the flag is set the webapp is not completely undeployed so only the modified jsps get recompiled on redeploy.

2.
I will look into the FAQ and try to understand the problem a little more. I think Tomcat does some persisting of the sessions so that if I redeploy or restart jboss-tomcat (with the same parameter I set for #1) it keeps the persisted sessions around. Now, I am now only running this for development and I haven't done any stress testing so I don't know yet what the perfomance implications are and what it implies for clustering but this is the behavior I get. Thanks for the pointers, I'll do more reading.

As I mentionned before, #2 is only remotely annoying, #1 definitely is though so if there were a way to do this, I (and I'm sure a lot of other people) would find it extremely helpful.

Thanks again

Pascal

[jules]

Pascal,

I'll put (1) on my TODO list.

As far as (2) goes, it might be useful to have a flat-file backend to distributed sessions, to do what you are asking for simply.

Now a question from me :-)

Why are you bouncing JBoss so much ?

You are aware that you can deploy your webapp as an unpacked war and then edit JSPs in situ (this should prevent all your JSPs being continually thrown away) - aren't you....


Jules

[pascalpt]

Hi Jules,
The answer is simple, source-code control. There others like the fact that I use model 2 and a lot of java classes keep changing as I go, but the main thing is that I can repackage everything in 5-6 secs and redeploy it in 10 so it's much better to work on the jsps in a directory that I can synchronize with the repository.

Now I could probably point jboss to that directory but that would force me to make sure all the classes and jars fit a certain hierarchy and that they are broken into the ones that go in the exploded war file and in the ejb-jar, etc. I'd welcome suggestions if there's a better way to handle this but this quick redeployment is the best way I 've found so far.

Pascal

[jules]

I started off jarring a load of bits together and deploying the result, but this takes time, even on a fast box.

The next app I wrote, I organised everything so that it builds straight into the correct structure and touches it's WEB-INF/web.xml.

Over hundreds of development iterations this pays for itself many times over.

If you are on Unix - symbolic links can work wonders too.

All those 5-6 secs add up over a week.... :-)


Jules

[pascalpt]

Hi Jules,
I just switched to copying all the files to an exploded structure and touching the application.xml. You're right, it does cut down a lot on deployment time. And I can make sure I only touch the descriptor if a java class has changed (as oppose to only jsps) thus preventing the redeployment which also speeds up things a lot.

When I change any java class, the 2 initial problems still remain though...

Thanks for the tip

Pascal