The file that was uploaded for this game is named "drts-4k.jar.pack.gz". How does the applet know how to retrieve that file? Does it automagically read the cache_archive value, append ".pack.gz", and look that up from the webserver, ungzip it, and unpack it, and vola it has its jar!?

From this link, as I understand it :- the client will allways ask for the "*.jar"- it is up to the server to give the "*.jar.pack.gz" if the client support it (Accept-Encoding in the HTTP request). Other wise, it have to send the ".jar"- the client know if it got "*.jar" or "*.jar.pack.gz" from the CE (Content-Encoding I think)

So I think it is OK to use a php page to send back the "*.jar" or "*.jar.pack.gz"

And isn't it just ".pack.gz", not ".jar.pack.gz"? I mean, there's no jar in there.

I just copy what is in the link

Quote

I think you can make the applet tag point directly at a .pack.gz as well

If the apple tag point directly on the .pack.gz, you have to be sure that all explorer that will be use can understant it... I have no idea whish ones are compatible with it. You should make a try and ask us to do the test.

Damnit, sun.When I tried a local .html file that pointed at a "M.pack.gz", a pack200 gz file, it worked. When I uploaded both to my webserver, it no longer worked, despite the file being there.

I can kind of understand why they'd want to enforce backwards compatibility on the server side so it'll still provide jars for older jvms.. but this is really, REALLY overly complicated. And it's not like code written for 1.5 will run on 1.4 jvms anyway if you use new classes or functions.

I've written a new obfustificate / pack / zip chain which is getting the same sort of file size that Riven presented earlier. However I can't get the browser (using file open on the html file) to get the pack.gz in preference to the .jar using the jre1.6 only parameter tag. (I am using 1.6). If I remove the jar and just leave the pack.gz I get a nice class not found stacktrace. Can this be tested without recourse to a webserver?

My web hosting has .htaccess and php but no servlets. I need to check whether they're using Apache, as I've seen some examples on how to get the right files served up using that. Alternatively I'll need to hack out some PHP. Anyone got a non-servlet solution working yet?

I am boggled at -Djnlp.packEnabled=true causing it to interpret the <applet>'s code attribute as a fully qualified name rather than the name of a class file. Replacing it with code="a" doesn't help: it looks for a file /tmp/pack200/a.class and ignores /tmp/pack200/grav4k_1v3.pack.gz

That's pretty much what I'm getting. If I leave the jar in the same directory, then the browser goes and gets that Ok. On the positive note, my hosting provider is using Apache, so hopefully I can fix up a server solution using .htaccess. However I think that's a project for the weekend.

I have thought, but not investigated, about directly using game.pack.gz as instead of the game.jar in the applet tag, but append appropriate html response (with pack 200 mime type) message to the front of game.pack.gz to try and trick the JVM in to thinking it recieved a pack 200 archive from a server.

I have thought, but not investigated, about directly using game.pack.gz as instead of the game.jar in the applet tag, but append appropriate html response (with pack 200 mime type) message to the front of game.pack.gz to try and trick the JVM in to thinking it recieved a pack 200 archive from a server.

Perhaps it requires a server sending a "Content-Encoding: pack200-gzip" header.

Grr.. .I've been trying to accomplish this same thing, run an pack200 applet using the appletviewer, locally, but no luck. Why oh why does Sun need to make technologies such a pain to use client-side?

I won't claim it's pretty, but I don't think there are enough security flaws in this for anyone to do anything nasty to your machine. Tested and it allowed me to play the .pack.gz of Gravitational Fourks; the logging output is good enough to check that it is getting the file you think it is. I haven't played around with caching pragmas, because I want to get on with actually developing a game for this year, but I suspect they would be helpful.

I got pack200 working under Tomcat61. Install Tomcat2. If using Vista and Tomcat installed under Program Files, change permissions to allow modify & write3. Edit startup.bat in /bin to include "set JRE_HOME=C:\Program Files\Java\jre6" or whereever you have a JRE installed4. Check tomcat works when you run startup.bat, and stops with shutdown.bat5. Add directory 'java' under directory 'webapps'.6. Create subdirectory 'WEB-INF' and copy in 'web.xml' from 'webapps/ROOT/WEB-INF'7. Edit web.xml to include:

Quote

<!-- The JNLP servlet, installed to support Pack200 for use in Java4K --> <servlet> <servlet-name>JnlpDownloadServlet</servlet-name> <servlet-class>jnlp.sample.servlet.JnlpDownloadServlet</servlet-class> </servlet>

8. Create directory 'lib' under 'WEB-INF'9. Copy in 'jnlp-servlet.jar', which you will find in the sample/jnlp/servlet direvtory in the java sdk10. Add your .html and pack.gz files in the java directory. Note you also need the jar as the server looks for it - but it can be an empty file11. Point your browser at http://localhost:8080/java/yourhtmlfile.html

Sorry, just confirming, it is not possible to test a pack200 file locally? We have to do it via the tomcat method? Are people actually doing that, or just hoping it works ok as a pack200 file and uploading to the Java4K site blindly?

Sorry, just confirming, it is not possible to test a pack200 file locally? We have to do it via the tomcat method? Are people actually doing that, or just hoping it works ok as a pack200 file and uploading to the Java4K site blindly?

Look two posts before yours and you'll find a small self-contained web server which supports pack200.

(I had posted it before, but I didn't look in this thread. Oh well, never mind).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org