Develop Reference

Is it possible to provide security for war file?

I have developed a web application which I am going to sell, but I face some security issues because I am going to provide a .war file to client machines and I found .war files can be easily extracted.
How can one provide security for war files to avoid being copied or extracted?
While searching I found Excelsior jet which converts web apps to native code but it's a trial version and I cannot afford its price so I want to know other alternatives.

A web app container cannot deploy an exe anyway. You can obfuscate your classes and maybe write a licensing module. If you prevent users from extracting your war you'll also prevent the container from deployment.
For example, you might use a Java Bytecode Obfuscater such as
yGuard
ProGuard
JODE
As for a licensing module, you may be able to use
this or this question.

The possible way is to
Use code obfuscator
Code in init() or somewhere check for license/access only one host.
Another option is to code your own classloader and implement it in modified web container

Packaging up a project for deployment - Java

I have a Java application (a quite large one with many external .jar dependencies as well as dependencies on images) and I need to package it up so that someone can double click to run, for example. Or something easy like that.
It uses Java Persistence, so it requires a sql connection which is specified in the Persistence.xml file in the Java Project.
How can I package this up? I was thinking:
the installation process should validate that the user has MySQL installed and if not, direct them to install it
the installation process could ask the user to enter credentials for any database and then I could update the Persistence.xml at run time
These were two ideas I had...but I wasn't sure if there was a known solution to this problem. Any help would be much appreciated!

I think you should take a look at embedded database solutions, like H2. Also, you can package your application using maven's shadowing or jar plugin, having the jar-with-dependencies profile activated.
This will nicely rid you of checking for database servers running on the client machine, and also will give you the proper means of bundling the application in one nice JAR, albeit a little large.
Maven is a build ecosystem and toolset especially designed for building Java applications and executing the code -- and generally doing whatever else you can imagine that's possible to do with and to your code.
It has a rich API for developing plugins and many developers have exploited this feature. There are numerous plugins for building -- and launching -- and packaging your application as well as helping you manage your applications dependencies.
Maven's shadowing comes in the form of maven-shade-plugin, available here. What it does is that it helps you create a single JAR file from all your dependencies. Also, there is the maven-jar-plugin which offers a profile jar-with-dependencies. It is also accessible from here.
H2, on the other hand is a full-fledged RDBMS. This is the website: http://www.h2database.com/html/main.html, and here is a tutorial.
You can find information on embedding the database here:
How to embed H2 database into jar file delivered to the client?
Embedding the Java h2 database programmatically
h2 (embedded mode ) database files problem
I would also suggest you use a combination of H2/Hibernate/Spring which is a very easy setup and provides you with really rich features and an easy-to-use API.
I hope this helps you :)

Building a sophisticated installer that checks lots of dependencies, and runs on lots of different platforms (which I assume you want) is complicated.
I suggest that you look at an installer generator; see What is the best installation tool for java?
Another alternative that I've seen in a few products is to write a (non-GUI) installer or configurer in a scripting language like Perl.

I wrote an installer using ANT, but has no GUI. Also, I used Iz Pack (good option), so I think that depends on how smart do you want it to be, if you are supposed to use it, or a non-technical person, etc.

How to maintain a group of apps with shared libraries that change often?

I have a lot of small-ish Java command-line apps that have to use a vendor set of jars to make their connection to the servers, and while writing these apps has been pretty easy, maintaining them is turning out not to be.
I built them using Maven and some templates that gave me a pretty quick turnaround on development time, but these are all standalone command-line apps so far.
The pain comes from the updates to the vendor servers. Whenever it happens, it forces me to recompile all of these applications with the new jars in play, otherwise I'd get SerialVersionUID Exceptions and borked apps.
What I'm considering
I was thinking that it would be possible to use Maven to generate the app and then throw it in an app server with the server providing a set of shared vendor .jars in whatever /shared classpath it provides. That way I could just update the .jars, restart the server, and everything will likely continue without error.
However, I'm not sure what is required to get that working. They aren't .war's, and most of these apps use other .jars besides my code that isn't usually shared.
Questions
What kinds of deployments work like this?
Are there other ways to do this that I'm missing?
Any tutorials, frameworks, etc., that would make this simpler?

I could just share from my experience. We have 3 ways of overcoming this at the moment. The first way, was our old way, which we still use.
Create a base project which we link to with all our external JARs. The user project when compiled/deployed checks for a newer tag of the base project than it is currently using, and if there's a newer tag, it will fail and force the user to check for the updates and recompile. The benefit of this is that at compile time you can check for new jars, and we get a list of what changed, and reload the jars. In our IDE we can quickly see if anything changed from the API - it has been known to happen, then we can fix and recompile. Also because we're aware of the changes, we can read the changelogs and see if any of the changes affect us, and we then retest parts of the application that depend on these libraries.
We use Maven, but instead of the public repositories, we maintain our own repository, where we only move a library into our local repo after it has been tested - so no surprises for us.
This method is unique to a Tomcat deployment, but we also load libraries via the Context using a classloader. It's not my favorite way to load external jars, but this one works without a deploy. Of course since the compiler isn't there to help you, the new jar can not be 100% compatible with your code, and you can end up with some runtime NoSuchMethodError or ClassNotFoundException expections.

I might be misunderstanding your situation, but if the interface you use in the vendor libraries does not change between versions, couldn't you just keep the jar-files in the classpath of your command-line applications and thereby just overwrite the vendor files when necessary? In that way you would only need to recompile when the interfaces change in a way to break your code?

Proprietary non-OSGi packages needed in OSGi application - can't redistribute

I want to use proprietary, non-OSGi jars in an OSGi environment. For development, we just repackage/export it with the Maven bundle plugin [1]. Problem is, for legal reasons we won't be able to redistribute these packages to our customer, which kills both embedding and repackaging, which are (AFAIK) the only options (see [2]).
Before using OSGi, we had a section in our manual describing how to put these files in a library folder after acquiring them on ones own. Given OSGi rules for resolving classes, this obviously won't work anymore.
Am I correct to assume that the only way to solve this is a legal one, i.e. getting a redistribution license from the packages' vendor (which may be a beurocratic nightmare and impede timely delivery), or am I missing a technical solution?
[1] How can I share non-OSGi libraries between bundles in an OSGi container?
[2] Non-osgi library usage in an osgi application

I would simply add this JAR to the main Java application classpath, using its existing location in a library folder as you have already established. Then you can export the packages you need into OSGi using the org.osgi.framework.system.packages.extra property.

I have seen this requirement too in a commercial project. We ended up adding a special bundle, which on start-up downloaded the needed jars from the relevant sites and added them to our re-export bundles.
So
we have a 3rd-party non-OSGi jar J.jar which we want to use
we add an (almost) empty OSGi bundle with two files
a META-INF/MANIFEST.MF that re-exports all the relevant packages of J.jar
a simple text file - META-INF/DOWNLOADS - that specifies from where we can download J.jar
we have a simple generic OSGi bundle (with a early start-up level) that goes through all installed bundles and checks if META-INF/DOWNLOADS exists. If it does, it downloads the specified jars if not already present.
When the re-export bundle is later started, it will look like we distributed the offending jar... and everybody are happy.
When we needed a new version of the jar, we just released a new version of our jar as we would normally do.. The main problems were how to handle any problems in the down-load process.

Perhaps OSGi Remote Services (distributed OSGi) could be an answer. You would host the OSGi environment that exposes the proprietary lib, and install the rest on the client's machine.

This is quite philosophical. Just what exactly constitutes a distribution of digital content?
(1) We all agree that if the jar in question is included in your installation download, it's a redistribution.
(2) What if the installation program is a thin shell, when it runs, it downloads more stuff from internet. If it downloads the jar from your server, I think most people would agree that this is essentially the same as (1), and it is a redistribution.
(3) What if the installation shell downloads the jar from the owner's server? Suppose it is automated without end user knowledge.
Could anybody really argue that (3) is very different from (2), and it is not a redistribution?
I think it is, for all intents and purposes. We are effectively distributing the jar with our program, how that is done under the hood is not relevant with regard to the spirit of the redistribution license. Whoever gets the program gets the jar along with it, that is a fact.
At least we should contact the author to verify he is ok with it. We must pay due respect to free softwares, do not use them in a way that's against the wills of the authors.

What's the best way to add a self-update feature to a Java Swing application?

I'm trying to figure out a way to add a self-update feature to a Java/Swing application I'm working on.
Basically I've got a bunch of jar files with extra functionality to be re-deployed to the installed users when they change. Nothing complicated, just check if a new version has been released, download them over HTTP, and then optionally offer to restart the app to the user.
I had a look at webstart, and it could work. But this particular app does some funky stuff with classloading and GC memory settings that don't look like they are supported via webstart, or will at least complicate matters. (It's a tweaked build of JMeter)
I also went down the road of adding in this plugin handler http://swing-fx.blogspot.com/2008/06/add-auto-update-and-plugins-to-your.html, but it is very alpha, and tries to do too much with the usual bugs you get with alpha stuff.

I did the exact same thing. But that was long back so there are probably better tools today.
What I found out I needed was a loader. The loader main program did not have the app jars in classpath. It first downloaded an update if required and then created a custom classloader with the app jars in class path and invoked the main method of the application main class. It is not very complicated. IIRC I needed to do this because the jars could not be overwritten in windows if they were already in classpath.
Hope this helps.

we had a swing app 6 years ago that had self-update. like you suggested,
1)it downloaded the latest jars over http,
2) copied them to a folder.
3) since the swing app is launched using a .BAT file, after user said YES, we would shut down the swing app and look for any files in the update folder. if yes, launch another .BAT file to copy the NEW JARs to the required directory.
4) then re launch the swing app.

Updates, plugins, separation of concern etc. are exactly what OSGi is about - you might want to take a look at this. It won't come free (read: with a steep initial learning curve, especially when you are currently using classloading tricks) at least there are good open source implementations (felix - see felix.apache.org, equinox - see www.eclipse.org and others)
For these implementations autoupdaters are available - if you write your modules correctly it's possible to update at runtime without restarting.

I believe you should look again at Java WebStart, or at least detail the "funky classloading" which you think is going to cause problems (as it might also cause problems with any solution proposed here).
IIRC, you can set command line parameters using Java WebStart ( http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources ).

I would definitely first try out Webstart. We've had lots of success launching even the early Eclipse RCP apps using Webstart, and you can probably not get more funky classloading issues than with the OSGI framework (Eclipse Equinox).
Could you perhaps give some more detail in your question about you classloading approach?
Regarding the GC and other VM settings: these are easy to specify in your JNLP (Java Network Launching Protocol) files used by Webstart for launching apps.

The Java Web Start is good choice. The GC stuff is not important. Classloading could be problem. But when you got trusted by user you can grant AllPermisions and you will be able to do custom classloading. Maybe it will be good to reconsider funky stuff with classloading. It is really necessary? Or look at NetBeans. There should be found inspiration for auto-update.