The Web Start Developers Guide states
All application resources must be retrieved from the JAR files specified
in the resources section of the JNLP file, or retrieved explicitly
using an HTTP request to the Web server.
Storing resources in JAR files is recommended, since they will be cached
on the local machine by Java Web Start.
Now, I have some resources I want to dynamically load after my application has been started (for example OSGi bundles). I can do this using plain HTTP, but I would like to make use of Web Start's support for local caching and versioned/architecture-specific resources.
Is there a way to download additional jar files from the original code base (as specified in the application's jnlp file) using the Web Start infrastructure?
Or alternatively: is there already an established way to integrate OSGi and Web Start that would relieve me of the task to install bundles from the Web Start server?
If you make your application in itself an Equinox-based OSGI application, you can web-start it with all the addition bundles you need.
This article "WebStarting Equinox OSGi Apps" can give you a good introduction on the required settings.
All bundles have to be deployed as signed JAR files
You need a feature that contains all the necessary bundles
When exporting the feature, make sure that PDE creates a JNLP (Java Network Lauching Protocol) file (a checkbox in the export wizard) for this feature
Provide a root JNLP file for you application
Deploy your application to a web server and make sure that the web server is aware of the application/x-java-jnlp-file mime type
He also has an OSGI demo.
I haven't tried it but look at the javax.jnlp.DownloadService API
Related
Oracle recommends using the JnlpDownloadServlet to launch JNLP from Java web applications - https://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/downloadservletguide.html
However, I need to launch a JNLP application with a dynamically generated JNLP file from a dotnet application.
What would I need to do to enable this?
set content type as application/x-java-jnlp-file
output the JNLP file as a download.
Is there anything else?
The JNLP file is just an XML file that happens to be an executable file as long as you have Java Web Start installed on your machine. This is usually installed on a machine.
From a .NET Web Application point of view, you'd need to ensure the following:
Correct content-type (application/x-java-jnlp). You might need to add configuration to your .NET server to enable this mime type.
The file needs to be accessible via a URL (kind of obvious, but worth mentioning for completeness)
The file needs to be downloadable. Conceptually it is the same as returning any other file.
For seamlessness, the browser needs to be setup to automatically execute jnlp files. Sometimes company/default browser settings do not do this and you'd end up needing an extra click. Not a big deal, but just something to be aware of
In terms of "configuring"/implementing the actual serving of the JNLP file from a .NET Application:
Your end goal is that whatever JNLP file you return is executable with Java Web Start. This gives you a nice repeatable test while you're working on this.
You need to ensure that your .NET Application is able to serve the jar files needed by the JNLP application. Typically the codebase attribute and the resources element needs to reference your .NET application. The JNLP File Structure Page should help with this.
If you look at the JNLP servlet source code you will see that all it does is use the .jnlp file as a template and substitute place holders for specific values. There is nothing special about it that couldn't be duplicated in a .Net MVC or API controller.
I've created a dynamic web application and i'd like to deploy it with glassfish. I've successed build my sources to MyProject.jar. But when i deployed it, the following error displayed:
remote failure: Archive type of /home/davenlin/MyProject/build/MyProject.jar was not recognized
My project is just a normal Restful application, not ejb application, so i don't know if i must generate a MyProject.war instead of MyProject.jar.
Please help me. Thanks !
Okay, because my comment was rather unexplanatory:
Web applications are handled by application servers or servlet containers.
Both do quiet a lot of work for you and web applications are not comparable to
desktop or standalone java applications. While your standalone applications are deployed as jar - files and then executed by the JVM, web applications are
executed by the container (application server / servlet container).
So this does require your application to provide additional configuration and affords the archive itself to have a different structure.
So even if you are just exposing some web services to build a restful application, your application server will do things for you such as
forwarding requests to the right classes, translate query and post parameters into java - objects accessable by your own classes respectivly your own objects and returning your response to the clients.
The interesting thing about it is:
The additional files in the web - archive are usually xml - files and web - related files such as html, css, js.
So this does not distinguish war's from jar's as you can also package additional resources within a jar.
The basic but now obsolete requirement on a war - file is that it contains
a deployment descriptor (which is again is an xml - file)
to configure your application , its context and the relative url (more concrete : url - patterns) it uses , but as this requirement is obsolete someone may still think that this distinguishing is obsolete, too.
I have made an app using Tomcat as my server. It uses JSP pages and java servlets.
If I copy my webapp (the folder) to some other server, will it run? What are the requirements for it to work/not work?
EDIT: Thanks for the answers. One more thing, what if some of my code uses filepath, that originates from the bin folder of Tomcat. For eg: "../webapps/MyApp/WEB-INF/sample.txt"
Is the directory structure the same in all servers?
Java servlets and JSP are intended to be portable technologies. There is a servlet standard and a JSP standard. Any servlet container (such as Tomcat) that implements the version of the standard that your code uses should be able to run your code.
You should move your web application around by copying its web application archive (WAR) file, rather thsn the directory (the extracted content of the WAR).
Ofcourse it will run , there are many servers out there that support jsp/servlet . Most of them are free for development and some are paid for deployment. See this link for more info
For most of the containers (i am not sure for all but most of them) like Tomcat, Jetty, Resin etc, you don't need to modify the project. You can place your project war file in the webapps directory and the project will get deployed on starting the server.
My company has developed a web application (J2EE environment/Tomcat server) and wants to sell it as a product. Customers can avail this product as basic edition or premium edition. In the premium edition the customers have some extra functionalities (may be some extra links). This distinction is made based on the serial key.
I was just a listener when the above thing was discussed.
Is doing the above problem possible? How do we convert a war file into an exe file and embed logic to distinguish premium or basic version.
How do we convert a war file into an exe file and embed logic to distinguish premium or basic version.
These are 2 distinct requirements which have nothing to do with each other.
If you have a web application you can either enter the serial key using a web page (like Jira does for instance), or you could perhaps let the key (or the filename of the keyfile) be written in Context.xml, and let a servlet read that context parameter. Based on the key the application could then allow or not allow some functionality.
As for converting to an executable, there are multiple interpretations to the word executable. I for one think "war" file is executable enough - dump it in a tomcat and it runs.
If you want it standalone you could provide a tomcat distribution with your app predeployed (again, like Jira does), or use a Jetty embedded container. Although that may not be appropriate for heavy workloads.
You could even try to convert jetty + your web app to a native exe using gjc (Gnu Java Compiler) though I doubt it will work as well as the normally deployed version.
I'd advise you to either inject the key via context parameters, or create an admin page n which you can enter the key.
A WAR is a web application archive. It's supposed to be executed on a webserver with a servlet container. An executabele JAR requires a class with a main() method, but a web application normally doesn't have any since that's the responsibility of the servlet container, not the web application. Normally, a WAR is to be distributed as-is, it's the serveradmin's responsibility to deploy it to a servlet container. You can if necessary include some documentation which describes how to do it for various containers.
If you really intend to sell a web application as a desktop application for some unobvious reason, then your best bet is really to include an embeddable servlet container like Jetty and ship a class with a main() method along it which creates an instance of the embedded servlet container, deploys the WAR file to it and runs the servlet container. This can in turn be wrapped in an executabele JAR.
Alternatively, you can also host it somewhere on the internet and provide a specific login.
What are the steps required for enabling a Java web application (Developed using Spring + Wicket) to accept client file uploads to a specific directory on the server.
While Googling for answers to this question I see suggestions that /WEB-INF/some-directory should be used as the upload location?
Is the reason for this best practice?
Is this location writable by the web application?
What happens to this location when a new version of the web application is deployed?
Can/Should any other directory be used?
Thanks
Two possible reasons for the use of a subdirectory of WEB-INF:
it is not visible through HTTP
your application typically has write access to it
I would rather recommend using a configurable, external directory (e.g configured in a context parameter or en application config file); this way you have fine grained control over the permissions of the directory.
AFAIK, file upload in Wicket is provided by the FileUploadField component, which gives you a FileUpload object that you can writeTo a file on your server.
You might also want to configure/check the maximum size for the files you want to accept. In Tomcat, this is done through the maxPostSize attribute of a Connector (see The HTTP Connector)