I ran into the exact same error today while installing NB 6.8 beta. To resolve it we need to install two plugins:
- Java Web Applications (as mentioned by Ali above) and
- Sun Java System Web Server 7.0
Note that these two are part of the Category called "Java Web and EE" hence the confusion that we need to install Glassfish App Server. But we need these two plugins because they are required for debugging using breakpoints in emulator. Netbeans runs a web server when we do breakpoint based debugging.
Also note that the Java Web applications needs SOAP Web Services and JavaScript Debugger plugins to run and so these plugins are also installed when you try to install it.
I've seen some suggestions like having the image directory being a symbolic link pointing to a directory outside the web container, but will this approach work both on Windows and *nix environments?
If you adhere the *nix filesystem path rules (i.e. you use exclusively forward slashes as in /path/to/files), then it will work on Windows as well without the need to fiddle around with ugly File.separator string-concatenations. It would however only be scanned on the same working disk as from where this command is been invoked. So if Tomcat is for example installed on C: then the /path/to/files would actually point to C:\path\to\files.
If the files are all located outside the webapp, and you want to have Tomcat's DefaultServlet to handle them, then all you basically need to do in Tomcat is to add the following Context element to /conf/server.xml inside <Host> tag:
<Context docBase="/path/to/files" path="/files" />
This way they'll be accessible through http://example.com/files/.... For Tomcat-based servers such as JBoss EAP 6.x or older, the approach is basically the same, see also here. GlassFish/Payara configuration example can be found here and WildFly configuration example can be found here.
If you want to have control over reading/writing files yourself, then you need to create a Servlet for this which basically just gets an InputStream of the file in flavor of for example FileInputStream and writes it to the OutputStream of the HttpServletResponse.
On the response, you should set the Content-Type header so that the client knows which application to associate with the provided file. And, you should set the Content-Length header so that the client can calculate the download progress, otherwise it will be unknown. And, you should set the Content-Disposition header to attachment if you want a Save As dialog, otherwise the client will attempt to display it inline. Finally just write the file content to the response output stream.
Here's a basic example of such a servlet:
@WebServlet("/files/*")
public class FileServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
String filename = URLDecoder.decode(request.getPathInfo().substring(1), "UTF-8");
File file = new File("/path/to/files", filename);
response.setHeader("Content-Type", getServletContext().getMimeType(filename));
response.setHeader("Content-Length", String.valueOf(file.length()));
response.setHeader("Content-Disposition", "inline; filename=\"" + file.getName() + "\"");
Files.copy(file.toPath(), response.getOutputStream());
}
}
When mapped on an url-pattern of for example /files/*, then you can call it by http://example.com/files/image.png. This way you can have more control over the requests than the DefaultServlet does, such as providing a default image (i.e. if (!file.exists()) file = new File("/path/to/files", "404.gif") or so). Also using the request.getPathInfo() is preferred above request.getParameter() because it is more SEO friendly and otherwise IE won't pick the correct filename during Save As.
You can reuse the same logic for serving files from database. Simply replace new FileInputStream() by ResultSet#getInputStream().
Hope this helps.
See also:
Best Answer
Assuming you want to stick with Java, I would implement your server side as a simple Servlet. If all you want to do is send an XML file to the client I think using a proper web services stack is probably overkill and will over complicate things.
Using this approach your mobile app simply makes an HTTP connection to your Servlet, which responds with your XML file.
In fact, if it's a static XML file you don't need any kind of server side code, any web server would suffice.