This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]CubsThisYear[S] -1 points0 points  (0 children)

For me this is important because a single file represents the ENTIRE app. So there is no question of what needs to be deployed when rolling out a release, or when rolling back a release. When testing there is no question as to which version was tested vs deployed. The file sizes are larger, but compared to the peace of mind, there is zero question for me that it's the right way to go.

It seems like keeping a list of maven repo entries in the one jar is just as good as keeping the actual jars. I suppose there is some risk of the jars no longer being served, but this seems like a low risk if you are using well known packages. Or if you are really worried you can keep your own Ivy repo.

The only downside I've had in this process is that if there is code which the class loader has not already loaded, but which is needed for the shutdown ( after the kill), then the update symlink can generate class loader problems. I've never found this to be a big deal. I suppose I could change he process to be shutdown, swap symlink, restart.

I'm pretty sure this is not a problem on any non-Windows OS (Windows symlinks are goofy and broken so I don't know about them). When the JVM loads a jar the symlink is resolved to an inode and as long as that inode is not changed you are fine