Anyonme got version-based download working ? — oracle-tech

    Forum Stats

  • 3,681,447 Users
  • 2,238,013 Discussions
  • 7,831,224 Comments

Discussions

Anyonme got version-based download working ?

843802843802 Posts: 39,816
edited June 2002 in Java Web Start & JNLP
I've scanned all the messages here as well as on vamp, but nowhere do I see an anwser on how to get versioning working.

My test app is a straight forward one.
Below are the jnlp and version.xml.

As long as the attribute [version="1.1"] is included I get the;

Missing version field in response from server when accessing resource: (http://localhost/Webstart/app/uitrij.jar, 1.1)

error. When I strip only that attribute the app loads just fine.
The excpetion that results in the above mentioned error is also listed below.

Anyone got any ideas ?

Anne.

--
launch.jnlp:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="http://localhost/Webstart/app/" href="launch.jnlp">
<information>
<title>VSP Uitrij Example 1</title>
<vendor>Finalist IT</vendor>
<description>Example of Webstart uitrij app in war</description>
</information>
<resources>
<j2se version="1.2+"/>
<jar href="uitrij.jar" version="1.1"/>
</resources>
<application-desc/>
</jnlp>

version.xml:
<jnlp-versions>
<resource>
<pattern>
<name>uitrij.jar</name>
<version-id>1.1</version-id>
</pattern>
<file>uitrij.jar</file>
</resource>
</jnlp-versions>

Java Webstart Download Error -Exception tab:
JNLPException[category: Download Error : Exception: null : LaunchDesc: null ]
at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
at com.sun.javaws.cache.DownloadProtocol.getDownloadSize(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)
at com.sun.javaws.Launcher.downloadResources(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Thread.java:479)

Comments

  • 843802843802 Posts: 39,816
    As long as the attribute [version="1.1"] is included
    I get the;

    Missing version field in response from server when
    accessing resource:
    (http://localhost/Webstart/app/uitrij.jar, 1.1)
    You should have a look at the jnlp specification, it explains the three or so different download mechanisms that are available.

    1. basic download
    For this scheme to work it suffices to have a plain web server at the other end of the connection, looking for new versions and subsequent updates are implemented by asking the web server for a time stamp and comparing that with the stuff in the JWS cache. Works but is error prone once the timing gets meddled.

    2. versioned download
    This is what you tried. It again communicates via HTTP to the web server, however this time some extra information is encoded in the URL of the GET request. To make use of this information you have to plug a piece of code into the web server, either some Perl/Python/C++/whatever CGI script or a Java Servlet. The task of this piece of code is to decode what the requesting JWS client wants and to pump back that content via the web server.

    3. versioned download, sending delta/difference jars
    Again needs some CGI script or Servlet on the web server, this time it should able just to package the contents into the result jar, that changed between the present and requested versions.

    I recall this from memory, so my description might be imprecise concerning naming, but it should give a proper approximation of the processes.
    Just read it up in the jnlp spec, if you want exact information. :)

    Again, your problem is you don't provide the necessary helper on the web server. It has to answer in a certain way, and because there isn't any, that answer misses and Web Start recognizes that giving the error message you posted.

    Regards,
    Marc
  • 843802843802 Posts: 39,816
    Hi Marc,
    You should have a look at the jnlp specification,
    I already had :)
    1. basic download
    2. versioned download
    This is what you tried. It again communicates via HTTP
    to the web server, however this time some extra
    information is encoded in the URL of the GET request.
    To make use of this information you have to plug a
    piece of code into the web server, either some
    Perl/Python/C++/whatever CGI script or a Java Servlet.
    My impression was that the JnlpDownloadServlet was used for that and that I thus didn't have to provide any other helper.
    The task of this piece of code is to decode what the
    requesting JWS client wants and to pump back that
    content via the web server.
    3. versioned download, sending delta/difference jars
    Again, my impression was that the JnlpDownloadServlet would also ake care of that.

    What I thought happens is;
    because of the application/x-java-jnlp-file mime type if a href of a jnlp file is clicked Webstart Client is started. This tries to parse the jnlp and use the info stored in it.

    It then would construct the correct url to retrieve the jar(s) needed to run the app, store them locally and run it. In case of versions it would copnstruct a url with the ?version= parameter in it.

    On the server side the request(s) are mapped to the JnlpDownloadServlet which takes care of providing whatever is needed.

    IOW; I didn't think I needed to create url's with parameters in them, other than a link to a jnlp file on a server somewhere...

    Anyway, I can live with Basic download for the time being.
    I'm currently trying to get a WAR working, but it looks like the current version can't handle WAR's...

    Thanks for your comments; it did help me find the bit on constructing url's with ?version= parameters etc.

    Anne.
  • 843802843802 Posts: 39,816
    Anne, What does your web.xml look like for the JnlpDownloadServlet ?? Is the mapping to *.jnlp ?

    I had a problem (can't remember if it was the missing version field error or not...) that I had to change the mapping for the servlet from *.jnlp to /app/* (note, all of my jars, the jnlp, and version.xml file are all located in a /app subdirectory.

    dave
  • 843802843802 Posts: 39,816
    My impression was that the JnlpDownloadServlet was
    used for that and that I thus didn't have to provide
    any other helper.
    Oh sorry. I did not recognize that you already used the download servlet.

    As far as I understand, you switch from basic to version-based
    download by adding the version="x.y" attribute to the jar element.
    What happens next, complete download of the new version or
    the download of a difference jar is up to the jnlp client (here Sun's
    Java Web Start) and if it has an older version in its cache.

    My guess is that you did not setup the servlet properly or that
    it doesn't work for some other reason.
    The only way to find out is to have a look at the HTTP communication
    between jnlp client and servlet that happens during your test.

    Do you know how to do that?

    Regards,
    Marc
  • 843802843802 Posts: 39,816
    Hi Marc,
    My impression was that the JnlpDownloadServlet was
    Oh sorry. I did not recognize that you already used
    the download servlet.
    Well, you were partially right I think :)
    Problem is that I've been combining two test at the same time.
    In one test I have all the files in a directory(-structure) on a (local) webserver.
    This allows me to do the simple tests.

    And then I create a .war and deploy that to a (local) application server (HP's Bluestone 7.3 in this case).

    The versioning would only work when doing the app server test, as the 'standalone' test has no back-end to interpret the request for a version-specific file (jar), as you pointed out.

    As the deployment using a .war file (still) doesn't seem to work because of the .getRealPath() problem (see http://developer.java.sun.com/developer/bugParade/bugs/4474021.html) I don't even get to versioning in that test.

    So if I want versioning I have a couple of options I guess;
    - Try the jar as provided by BEA as mentioned in
    http://forum.java.sun.com/thread.jsp?forum=38&thread=176243
    If this indeed works (haven't tried it yet), my guess is they 'fixed' the getRealPath() problem(s) themselves. (It doesn't seem like it's fixed in the current jnlpDownloadServlet )
    - Set up the app server as a straight-forward servlet-runner to run the jnlpDownloadServlet without using the std deployment.

    I'd prefer the 1st option to work, as I'd like to be able to deploy using a .WAR.
    The latter would basically come down to what you called 'installing a helper'.
    As far as I understand, you switch from basic to
    version-based
    download by adding the version="x.y" attribute to the
    jar element.
    And add the version.xml which links the versions to actual files (jars), IIRC.
    What happens next, complete download of the new
    version or the download of a difference jar is up to the jnlp
    I'm not quite clear on when the diff is done and when a complete file/jar is downloaded, but that at the moment is a moot point for me :)
    My guess is that you did not setup the servlet
    properly or that it doesn't work for some other reason.
    Several reasons, as mentioned above :)
    The only way to find out is to have a look at the HTTP
    communication between jnlp client and servlet that happens during
    your test.
    Do you know how to do that?
    Well, one thing I've been trying to get to work is the logging of the jnlpDownloadServlet.
    But even in DEBUG mode it doesn't really give me much information.
    I've also got Webstart's logging on, but again the information in it's logfile is not really informative.

    I've also used Sam Spade to see what responses I get from specific requests.

    Hmm, just thought of something; I haven't looked at the logfile of the web-server yet.
    Not that I think it'll help me much, but might be of interest to look at it all the same.

    <aside>
    Interestingly enough SamSpade gave me two different results when requesting the .jnlp file from the .WAR.
    Using a HTTP 1.0 it gave me a 404
    Using HTTP 1.1 it gave me the jnlp file.
    </aside>

    FWIW; I'm currently leaning towards phasing the implementation of Webstart.
    1st as webserver based solution with only Basic versioning. (This works, that I know for sure :)
    Later on as versioned-download using .WAR deployment.

    Dave,
    I don't have my web.xml here, but yes both .jnlp as /app/ are mapped to the jnlpDownloadServlet. That part of it works. (When doing the app server test that is; no servlet is used in the standalone test).

    Anyway, thanks again for your comments.
    If nothing else they at least made me get my thoughts a bit more straight :)

    Anne.
  • 843802843802 Posts: 39,816
    able to deploy using a .WAR.
    Have you tried out tomcat?

    And add the version.xml which links the versions to
    actual files (jars), IIRC.
    That is used by the download servlet.
    The protocol choice is done in the jnlp, on side of the
    initiating jnlp client.

    What happens next, complete download of the new
    version or the download of a difference jar is up to
    the jnlp

    I'm not quite clear on when the diff is done and when
    a complete file/jar is downloaded, but that at the
    moment is a moot point for me :)
    It is a matter of the implementation of the jnlp client,
    but I assume Sun managed to build in that feature.
    Once you get so far, I would first beam over a 1.1
    to fill the JWS cache, then provide a 1.2 on the
    server and wait what happens.

    I've also used Sam Spade to see what responses I get
    from specific requests.
    What is Sam Spade?

    Hmm, just thought of something; I haven't looked at
    the logfile of the web-server yet.
    That should give you the incoming requests from the jnlp
    client to the web server.
    You won't see the outgoing responses however.

    I mostly use brute force eavesdropping.
    On a Unix box I might run a tcpdump and pipe the raw network traffic
    to a strings filter.

    Or I use the "netcat" tool, the swiss army knife of
    networking :), it will act as webserver and I forward the intercepted
    request to the real webserver and for the back road I am able to see the response from the web server.

    Regards,
    Marc
  • 843802843802 Posts: 39,816
    Have you tried out tomcat?
    Not yet.
    The work I do is payed for by a customer who uses BS 7.3, so if it works on Tomcat, at the moment, is also a bit moot. I will try this once I'm done though, just to see if it works.
    I seem to recall reading that a specific version of Tomcat works and another doesn't ?
    And add the version.xml which links the versions to
    actual files (jars), IIRC.
    That is used by the download servlet.
    Ah, ok. So the client looks at the attribute and requests that file, the servlet reads the version.xml and thus is able to find the requested version of that file ?
    I'm not quite clear on when the diff is done and
    It is a matter of the implementation of the jnlp
    client, but I assume Sun managed to build in that feature.
    I guess that if the mime-type application/x-java-archive-diff is recognised the client knows that what's coming is the diff between the cached and the requested version.
    I've also used Sam Spade to see what responses I
    get from specific requests.
    What is Sam Spade?
    From http://samspade.org:
    "Sam Spade is a hard-boiled Film-Noir detective, famously played by Humphrey Bogart in The Maltese Falcon" :)
    Seriously, Sam Spade is a site with online networking tools, as well as a freeware network query tool for Windows.
    Hmm, just thought of something; I haven't looked at
    the logfile of the web-server yet.
    That should give you the incoming requests from the
    jnlp client to the web server.
    Eggsactly.
    You won't see the outgoing responses however.
    Unless I go 'lowlevel' as you suggested, I don't think there is a way to see those.
    Although as mentioned; Sam Spade does show the responses, just not what the client does with that. The combination of the two should get me a good idea on what's going on.
    (I'm running a Win-box as you probably noticed by now :)
    Or I use the "netcat" tool, the swiss army knife of
    networking :), it will act as webserver and I forward
    the intercepted request to the real webserver and for the back road I
    am able to see the response from the web server.
    Hmm, I should have a couple of servlet lying around somewhere (other project) that sort of do that :)

    Anne.
  • 843802843802 Posts: 39,816
    I guess that if the mime-type
    application/x-java-archive-diff is recognised the
    client knows that what's coming is the diff between
    the cached and the requested version.
    No, the client looks in its cache and if there is an older version already, it might decide to ask for a incremental update by providing the current-version-id. The server side is then free to decide if it sends back a full jar or a differential jar. The client finally recognizes the result via the mime type.

    Hmm, I should have a couple of servlet lying around
    somewhere (other project) that sort of do that :)
    Wasted spit to explain the beauty of the Unix component model unified by the mighty pipe and the there existing similarity of files and sockets to a Windows/Servlet developer. :)

    Regards,
    Marc
  • 843802843802 Posts: 39,816
    Wasted spit to explain the beauty of the Unix
    component model unified by the mighty pipe and the
    there existing similarity of files and sockets to a
    Windows/Servlet developer. :)
    Does it help if I say that I own a (new) Zaurus ? :)

    Anne.
  • 843802843802 Posts: 39,816
    Does it help if I say that I own a (new) Zaurus ? :)
    A collegue of mine went to Java One and bought one as well. A cute device and it is cool to have a bash command shell on that tiny PDA.

    But honestly, I don't know what he uses it for, I guess it went in his cool gimmicks box. :)

    Regards,
    Marc

  • 843802843802 Posts: 39,816
    A recap.

    Webstart works when distributing to a webserver, using the Basic method.
    In combination with a Bluestone server the other two versioning methods will not work, as the jnlpServlet is not able to translate the virtual path to a real path.
    As per spec the ServletContext.getRealPath() method returns null, which results in a failure.
    The version of jnlpServlet as provided by BEA does also not work under Bluestone.

    As a result it's not possible to deploy Webstart resources under Bluestone using a .war.
    Since the BAM/SAM does allow .war's to be deployed to Webservers, this can be used to deploy resources for the Basic method, although the codebase in the .jnlp file(s) may need altering after deployment, as they have to point to the webserver the resources were deployed to (no translation of $$codebase is done in this case).

    FWIW; under Tomcat (as well 3.2 as 4 I'm told) deployment of a .war does seem to work, although the example of the web.xml has to be extended with the <?xml ...> header, otherwise Tomcat will complain about it.

    So as long as this issue remains (I'm not sure if it's a Webstart issue or a Bluestone issue, I'd guess of the 1st as the ServletContext.getRealPath() specifically states that the method may return null in case a .war is used), it seems it will not be possible to use anything but the Basic Method in combination with a Bluestone server.

    HTH,

    Anne.

    PS The Zaurus is still in my gool gadgets box too :)
  • freddylegenfreddylegen Posts: 1 Newbie
    edited October 10

    The most varied genres, the most extensive listings. All you can ask in a rental service is what you will find with this option of online based company and believe me, you won't regret being part of it one bit.

    Final Tip: By researching and comparing the Best Online Movie Rentals 123 movies available in the market you will get the best deal possible, hundreds even thousands of movie downloads at the cheapest price. Nonetheless, you are welcome to take advantage of the resources already listed in our website, we have done all the hard work for you.

This discussion has been closed.