We Keep Coding

JavaWebStart- multiple jars in same jnlp?

I'm trying to convert my java software jar into a Java WebStart application. I've managed to successfully deploy it as a WebStart with a jnlp file that provides details about the software's jar.
However, my software requires certain details to be stored locally in a file on user's machine. These details can be set & the file can be generated by having the user run another java software (a very small java utility software) coded by me. I wonder if it's possible to package in this smaller software's jar as well along with the main software using the tag. As far as I know, we can use the tag to specify additional jars/ libraries that our software jar uses.
Can we package in another java jar created by us in the jnlp and would it then get downloaded alongside the main software jar and other libraries (jars) when the user launches the jnlp ?
Kindly let me know. Thanks.
P.S: I know that all jars downloaded by a WebStart application end up in the deployment cache. Is there no way to specify where they should get downloaded to ? In my case, I would prefer it if the 2nd software's jar gets downloaded in an easier-to-find location.

Yes, it would be downloaded - but it would end up in the deployment-cache with no easy way to find it (names get all mixed up) or start it.
There's no way around webstart keeping the files in the deployment-cache: if you could specify the download-location different versions of jar-files with the same names and different codebase could end up in the same location causing no end of trouble.
I see two ways to get the wanted functionality:
Add the ability to change the local configuration as an additional function in the main application. You probably can use most of the existing code but use a method-call instead of starting it as a separate application
Create a second jnlp-file to start the configuration-program. From what you write it should be pretty small and not too much effort to create.

Internationalization - listing and adding languages

I'm making an application in Java. This application can be internationalized using ResourceBundles. I want to allow user to choose the language that he want to the application have. And there's a question: how to list available languages for the program? I don't want to use Locale.getAvailableLocales(), because I don't know if the app's got a .properties file for the chosen language. There's also the second question: can I add an ability to add additional language files outside the .jar file? And the last question: is there any better internationalization solution?
Regards

You could just store a fixed list of supported locales in some constant of your application. If you need to make this dynamic, I see two solutions:
use a properties file listing the supported locales, and load them from this properties file at startup.
iterate through the available locales (or languages), try to load a corresponding bundle properties file (using Class.getResourceAsStream()), and consider that the locale is supported if you get an InputStream, and not supported if you get null.
You could let the user add a bundle by putting some directory in the classpath, in addition to your jar. Drop the properties file in this directory (respecting the package hierarchy), et voilà.

Getting resources from jars in an Applet's cache

I'm shoehorning an existing application into an Applet so we can say we support Web 2.0. Don't ask.
File system accesses are sprinkled all over our baseline so I'm in the process of converting them all to classpath based resource loading which is going swimmingly, except for the dozens of cases where we're traversing the directory system compiling lists of things. One simple example is looking inside a particular directory for .obj files and presenting that list to the user.
So I wrote an abstraction layer over files and directories in jars vs the file system, and it works just fine. My problem is that when I get the resource URL from class.getResource it contains the address for the jar on the server, but I know that the Applet has already accessed that jar for various classes.
I'm hoping there's a way to avoid getting the jar file from the server; e.g. the file is already cached somewhere and there's an easy way of obtaining it.

What you are seeing is deceptive. It is no business of applet and JWS apps. to know the location of cached resources. For that reason even if the resources is cached locally, the plug-in will claim the path is to the server.

Where/how to store persistent data with tomcat?

Where should I store persistent files in a Tomcat web app ?
javax.servlet.context.tempdir is not feasible, it's erased when the app is redeployed/removed
Don't want to use an absolute path in e.g. servlet init parameters
Storing the files in a database is not an option

Our team does this a lot. A general rule we follow is outside the web app and outside Tomcat.
Our sysadmin set up a directory on our server that the tomcat user has rw permissions to (e.g. /var/tomcat/persist). We have a built a directory structure under this that tomcat uses to store files, read app-specific init files, etc.
If you don't want to use an absolute path in your init-params for your servlet, consider setting a system property when tomcat is started up. The good thing about that is every application running under tomcat will have access to it. The bad thing about that is every application running under tomcat will have access to it. You could set a property named base.persist.dir and build subdirectories for each application underneath it. We set system properties in the setenv.sh script in the bin/ directory under the CATALINA_OPTS environment variable.

Answering the title of the question, what about using a database, a DataSource and JDNI? Even in a web only context, writing to files using java.io is not really recommended because of concurrency, threading, security, clustering, portability issues. Some of these problems can be "workarounded" but still, this is not really a best practice. The standard approach is to use a database and I'd suggest to reconsider this option, throwing "file-based" lightweight database like HSQLBD or JavaDB into the mix.
(EDIT: For an unknown reason, database is not an option. Using JNDI or context parameters or init parameters to pass an absolute path - which are the less worse options IMHO - is excluded too. For a relative path, maybe look at user.home or user.dir then - or any other system property that you could pass on the command line. I don't like it, I wouldn't do it, and this doesn't solve the issues previously mentioned, but it's your choice after all.)

Storing the files in a webapp directory under the home directory of the user running Tomcat is a good and convenient option. It is outside of Tomcat, which means it will survive redeployment, and it is usually a writable directory (because it is created under the users' home dir).
But it is always a good idea to allow overriding the location of such directory via system property.

Generally, this would go to the database. But since the OP insists on not using a database, I'd try a different approach:
Filesystem path which is known: ${user.home}/.myapp. Applications sometimes use this for e.g. search indices which can be recalculated based on data in the database. Might be okay for your use case to use the user's home.
Store the configurable filesystem path in a configuration repository such as the database or perhaps Java Preferences (if you don't like to use servlet init params). Commercial applications such as Atlassian JIRA use a configurable (but absolute) filesystem path where they store issue attachments. If they don't know a better way, i don't know who does :)

I generally would suggest to use a database to store persistent data and expose it via a DataSource.
If you don't want to do that, I guess you could consider using the "user.home" system property (I have seen this used in a few circumstances). But... there are no guarantees that your servlet will be run with permission to write access unless you configure that yourself.

Using the ClassLoader method to retrieve all resources under classes as Input Streams

My problem is one that you would think is quite common, but I haven't so far managed to find a solution.
Building a Java web app under Tomcat 5.5 (although a requirement is that it can be deployed anywhere, like under a WebLogic environment, hence the loading resources as streams requirement). Good practice dictates that resource files are placed under WEB-INF/classes and loaded using the ClassLoader's getResourceAsStream() method. All well and good when you know the name of the resource you want to load.
My problem is that I need to load everything (including recursively in non-empty sub-directories) that lives in a subdirectory of classes.
So, for example, if I have the following under WEB-INF/classes:
folderX/folderY
folderX/folderY/fileA.properties
folderX/fileB.properties
I need the fileA.properties and fileB.properties classes to be loaded, without actually knowing their names before the application is started (ie I need the ability to arbitrarily load resources from any directory under WEB-INF/classes).
What is the most elegant way to do this? What object could I interrogate to find the information I need (the resource paths to each of the required resources)? A non-servlet specific solution would be best (keeping it all within the class loading framework if possible).
Thanks in advance!

As far as I am aware, there is no such ability, since the classloader only attempts to load things it is asked for. It doesn't pre-fetch all items on the classpath, or treat them as a directory structure.
The way I would solve the problem is create a directory listing in a text file of all relevant resources at build time and include that in the war, and then walk it through that way.

You can do that with some tricks :)
Get the resource as URL, extract the protocol :
file protocol - get the URL path and you have a folder, scan for files.
jar/zip protocol - extract the jar/zip path and use JarFile to browse the files and extract everything under your path/package.