We have an app that we use as an applet in our website. Since the latest Java updates, we can't use it because a third party component uses it's own applet loader, and that is being blocked by the runtime. So, we've moved to Webstart, which is working ok, but when a user downloads the JNLP then leaves our site they can access the app by loading the JNLP. So we miss out on the website traffic.
So my question is: is there any way to make a jnlp "use-once" to force a user to come back to the website? Tying it to a session variable? An entry in the database to say when they were last online maybe? Has anyone else done something similar?
Thanks in advance.
Java Web Start is a deployment technology, not a marketing strategy, but some possibilities suggest themselves:
Exploit the features of the <shortcut/> element.
Dynamically load and display site content in your application.
Make it easy to visit your site using the browse() method provided by java.awt.Desktop.
Related
I'm using IntelliJ IDEA, I have coded a frame which I want to put into an HTML file so I can run it in my browser, how do I do this now that I cannot use JApplet? I have found this documentation: http://docs.oracle.com/javase/tutorial/deployment/webstart/deploying.html and this http://docs.oracle.com/javase/tutorial/deployment/webstart/deploying.html but I am new to programming and find this difficult to follow. I don't know for instance how I would go about putting my class files and the image that I used in a separate directory nor do I know how I go about signing my application so that it will run in a browser.
I want to put into an HTML file so I can run it in my browser,
You can use the Desktop class. This class allows you to access default applications from your desktop.
Read the section from the Swing tutorial o How to Integrate With the Desktop class for more information and working examples.
See Java Plugin support deprecated and Moving to a Plugin-Free Web.
Note that is one of my 'copy/paste comments' that does not explicitly mention JFrame based apps., however the links are still relevant in that Oracle & browser makers would not be phasing out support for applets if they wanted programmers to keep trying to shove rich client apps (e.g. Swing GUIs) into thin client web pages.
OTOH you can offer a JFrame (or a JApplet) to be launched from a link in a web page to end up free floating on the desktop of the user by using Java Web Start.
Even then, it is not a simple matter for the programmer or the end user. The programmer needs to ensure the app is digitally signed using a code signing certificate issued by a CA (usually they are expensive). The end user used to just be able to click the link, 'OK' the prompts produced by the Java virtual machine, and see the app appear on-screen. But now most browsers will download the launch file to the local file system rather than directly hand it to the JVM to be launched. So the user faces an extra step in explicitly finding the downloaded launch file and double clicking it.
This is all due to security concerns related to bugs in the plug-ins that run things in web pages. So if you were to find a way around all these hoops, please let us know. It is a security bug that requires urgent fixing.
I have created a simple java game and received a .jar file. I want to publish this game online on game websites (flash game websites such as kongregate, miniclip, etc.) but am unaware as how i would go about doing this. I have read that you create an applet to post the game online; but can I do that for a website that i am unable to edit?
TLDR: How to post .jar file on website, & if you do so via applet, can someone who cannot edit the site create an applet for the website?
If it is the latter can someone guide me towards a guide for creating an applet?
How to post .jar file on website, & if you do so via applet, can someone who cannot edit the site create an applet for the website?
Short answer, no. Long answer, nope.
In fact, it surprises me that you would think that you can launch an applet from a site when you cannot edit it! If that were possible, I could insert spam ads in a site that is supposedly under your control!
As to deploying the application:
The best way to deploy a Java desktop application is using Java Web Start. A JWS app. can be launched from a link on a web site.
It is a lot easier to deploy a JWS app. than it is to deploy applets (which, BTW, soon won't be supported in Chrome or IE at all, and are by default blocked in Safari and FF).
You will still need 'edit permission' on the site to launch a JWS app. As well as the ability to add new files to the site (e.g. the Jars(s) & the JNLP file used to launch the app.).
Lastly, either applets or JWS will need to be digitally signed by a valid certificate before there is a good chance of the JRE allowing them to launch.
I have created a simple java..
Not looking so simple now, is it? ;)
Deployment is typically a lot harder than people expect, and in the case of 'simple apps.' harder than they were to code and debug..
In my web application I need to launch a Windows application installed on client machine when a button in the page is clicked.
I know there are security policies in browsers that avoid this by default, but I also know application that do this. An example could be online meeting, web conferencing applications like WebEx or GoToMeeting.
How they do that?
I'm working with Java, so I'm wondering if Java Applets are an option to achieve this.
Is there some other well known way to solve this issue?
NOTE application execution MUST be allowed by user
The best way to deploy a Java desktop application is using Java Web Start.
And forget applets. Soon Chrome won't be able to load them (along with a number of other plug-ins) at all.
you can achieve it with applet. but user must allow to run it. it is hard to run some extern application from button or link because this is potentially danger behaviour. Remember the applet can not get access to the files on user computer and other servers (unless it is digitally signed)
I have a Google App Engine Application, and as part of that Application I have my standard HTML pages, Home, ContactUs, Testimonials, Pricing ETC ETC, when users click on "login" or go to a specific URL eg (www.diarybooker.com/demo) it loads the actual application.
All these standard HTML files are fairly static files though, with analytics and SEO etc in them, however in order to update these currently I need to release a new version of my application every time.
Can anyone offer any advice as to how I can JUST update the HTML without having to release a new version of my application (especially if I am in the middle of a development cycle and don't want to branch just to update a contact number or fix an SEO issue etc)
It is entirely possible that I am actually using the system incorrectly and that I should be re-wiring things better/differently, but I cant find any information about how this SHOULD be setup, and Im not even sure what to search for either, so if anyone can at least point me in the direction of some information on this, I would be very greatful!!
By way of an alternative example, I have a friend who is running www.wineathome.org.uk and if you click on "attend a tasting" it moves off into http://wineathomeuk.appspot.com. Clearly this is not very clean and is also not the way to make it work, I could embed the application in an iframe, but is that really the way to go?!
You have your application code in source control, right? I'd suggest that you create a deployment directory and clone into it the version of the application that you want to have running on AppEngine. Then, copy into the deployment directory the versions of the HTML files that you want updated. Deploy away.
That is the only strategy that's going to work for you. The GAE deployment tool only deals with your application as a whole.
Looks like you have a couple of issues going on.
On the first issue as #AdamCrossland states you can use source control. I use git and create branches for my application at different versions. If you do that you can merge your updated HTML back into an older branch then update your application from that branch. That way your only changing the HTML files and leaving the application in it's current state. App Engine deploy is intelligent and will only upload the modified files. Doing this from Eclipse is a bit more difficult than from the CLI IMO, but YMMV.
The other issue of a friend clicking on attend a tasting routing the url to appspot is a bit harder to deal with unless some code is provided. I would think it is because the code is doing a redirect to a hard coded URL. I have several application mapped to a domains and none of them route to appspot unless I forced it to in order to use some functionality like HTTPS which only works on appspot.com. I personally try to avoid iframes it opens up an avenue for exploits.
I have a simple java applet that retrieves an image from a server and prints it out. The only problem is that I get the following java security warning:
Researching on this site and all over the web, some people suggest that I sign the applet (I tried that to no avail) and others suggest that I Modify a local java security setting but that isn't feasible for my clients.
Not only do I get this warning at the start of my applet, but seemingly any time the code attempts to interact with the printer, the dialog re-appears. Also, note that there is no checkbox next to 'Always allow this applet to access the printer'. These symptoms show on any browser.
How do I get java to respect the users choice to allow it to send jobs to the printer?
You might use the JNLP API services in a sand-boxed applet in a plug-in 2 JRE. They will still prompt the user each first time they go to print, but should also put an 'always allow' check-box on the dialog (though it really only applies for that run). See a demo. of the PrintService.
See also the applet info. page that includes a link on the Next Generation in Applet Java Plug-in Technology which "..brings new abilities to applets: such as .. allowing embedded applets to gain full access to the services of Java Web Start."