I am launching a desktop application via webstart. One of the features of the application is dynamically creating menu items by searching for a my-plug-in.xml file and grabbing the plugin parameters. Basically the idea is so developers can create their own applications, package them in jars with my-plug-in.xml, and my application will find the plug in file and add their application to the desktop environment.
problem is, i can't find any feature to search through the resources in a webstart launch. the resource loader works fine provided you know the full classpath com/mydomain/app/my-plug-in.xml. if multiple my-plug-in.xml files are packaged without classpath identification, then the loader will just pick the first one.
any solutions? i want a list = getResources("*/my-plug-in.xml") method!
One should search through the application jars, list the contents of the jars and find the resources which match the needed pattern. After that the retrieval could be made with getResourceAsStream, or something like that. Busy now...;0), if problems with any of the steps let us know.
Joined: Dec 08, 2004
thanks for the reply. thats what i was doing initially running the application from my desktop, unfortunately it doesn't scale to a webstart launch quite so easily. running from the desktop it's easy to get the current folder or classpath and loop through its contents and grab stuff directly from the jar files. with webstart, the jars are going to be renamed and cached locally in some obscure directory like C:\Documents and Settings\user\Application Data\Sun\Java\Deployment\cache\javaws\http\Ddomain.com\P80\DMwebstart\DMapplication, and the classpath will point to something like C:\Program Files\Java\jre1.5.0_02\lib\deploy.jar
i have yet to figure out a method of grabbing a list of all the jar files in the application. i could probably live with grabbing the list of resources from the jnlp file (is there a method for this?), but this doesnt seem like an ideal solution.
I actually did something similar to that. I merged all the various plug-ins into a single xml file and placed it on the server.
The downside is adds a global file to maintain rather than letting each plug-in manage its own plug-in.xml file. Works fine as an internal applications, but wouldn't fit into a plug-in model such as eclipse.