The solution needs to be generic and work with any type of web application server and environment.
If you can update a WAR that is deployed on an application server incrementally depends on whether your particular app server supports that.
So, I don't think it's a technical issue you're trying to solve, but a process issue.
As an old timer, I would highly recommend against giving the customer the "deltas" and then letting them update the WAR. That is fraught with peril.
20MB over FTP takes a couple minutes. I think you're *much* better off building the WAR yourself (making sure you have a copy that *exactly* matches
what your customer has for adding the new stuff).
The OSGi technology provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed.
The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring restarts.
Or am I reading too much into this? It also sounds a bit like the dependency injection feature of Spring (which I am currently using).
Also, I know that my war file is smallish at the moment (20 mb), but I'm planning on adding lots of new features over the next year or two. Assuming my war file gets to 100+ mb, do I really have to send the whole war file every time? How to the major companies handle this problem with their large applications?
If there are resources that they have to be able to change themselves, then you could store them somewhere else, not inside the WAR file. Then they'd just have to put the right files in a directory somewhere and your webapp will pick them up from there.
What exactly are the replaceable parts of your application? Just data files (HTML pages, images, ...) or runnable code?
Jesper de Jong wrote:Do you really want to let your customers update the WAR file themselves? I don't know if that is a good idea... (assuming they are not Java developers). What if they do something wrong so that your software doesn't work anymore?
I agree with you on this point. I don't like the idea of forcing the customer to manually repackage the war file. I am wondering what common strategies are used by others when dealing with this problem (multiple war/jar files, optional packages, etc). So far I haven't found a solution that works other than repackaging/redistributing the entire war.
Jesper de Jong wrote:What exactly are the replaceable parts of your application? Just data files (HTML pages, images, ...) or runnable code?
I would need to replace both static files(xml,xsl,js,etc) as well as updates to class files.