Webstart Reource Problem

Hello, i have two Problems ;)
I?m trying the first time Java Webstart and it works fine. My Problems are :
Images :
Images i placed in Menu or Toolbar doesn?t appear on my Application. I used them like
... new ImageIcon (./images/blabla.jpg);
I think this relative Path doesn?t work because the Application is in a Jar File. Please let me know how to declare Image Resources in Jar Files.
The Second Problem is the Connection to the Database. The JDBC Library is in the Jar File but i doesn?t know where i have to declare it.
My Jnlp File :
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="http://localhost:80" href="TroubleTicket.jnlp">
<information>
<title>BlaBla</title>
<vendor>Bla</vendor>
<homepage href="Bla"/>
<description>Trouble Ticket System</description>
<offline-allowed/>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se href="http://java.sun.com/products/autodl/j2se" version="1.4+"/>
<jar href="TroubleTicket.jar"/>
</resources>
<resources os="Windows">
<j2se href="http://java.sun.com/products/autodl/j2se" version="1.4+"/>
</resources>
<application-desc/>
</jnlp>
Please let me know how to solve this Problems. Thanks in advance.

For a resource in a jar file, you have to load the image using the ClassLoaders getResource method:
     java.net.URL imgUrl = getClass().getClassLoader().getResource("test.gif");
imageIcon icon = new ImageIcon(imfUrl);
/Dietz

Similar Messages

  • Java Webstart application problem with TLS certificate revocation checks (Java 1.7.0_76)

    We have a problem with our Java Web Start Application regarding the TLS certificate revocation check:
    The application is running on a server within a wide area network which is separated from the internet.
    The application users have access to the WAN, and also access to the internet over some corporate proxy/firewall.
    The user has to enter, for example "https://my-site.de/myapp/ma.jnlp" within a webbrowser or could also call  "javaws https://my-site.de/myapp/ma.jnlp" to start the application client.
    The webserver has a certificate from a trusted certificate authority. This certificate seems to be ok, the browser is even configured to perform OCSP status check.
    The application files are signed with a certificate from another trusted certificate authority. This certificate seems also to be ok. Regarding this certificate there
    are no problems with certificate revocation checks.
    The problem is, while starting the application client there is a message box which tell us something like "the connection to this website ist not trustworthy",
    "Website: https://my-site.de:80", and something about an invalid certificate, meaning the webserver certificate.
    Obviously the jvm runtime, which is executed on the users workstation, tries to perform a revocation check for the webservers certificate, but this fails because
    it cannot fetch the certificate under https://my-site.de:80.
    The application will execute without further problems after that message but the users are very concerned about the "invalid" certificate, so here are my questions:
    - Why is the application trying to get the webserver certificate over Port 80. Our application developers told me, there is no corresponding statement. Calling this address
      has to fail while "https://my-site.de:443" or "https://my-site.de" would not have a problem.
    - Is there a way to make the application go on without performing a tls revocation check? I mean, by adjusting the application sourcecode and not by configuring the users Java Control Panel.
      While disabling the TLS Certificate Revocation check in the Java Control Panel, the Webstart Application executes without a warning message, but this is not a workable solution for
      our users.
    It would be great if someone can help me with a hint so i can send our developers into the right direction;-)
    Many thanks!
    This is a part from a java console output after calling "javaws -verbose https://my-site.de/myapp/"
    (sorry for this is in german... and also my english above)
    network: Verbindung von http://ocsp.serverpass.telesec.de/ocspr mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
    network: Verbindung von http://ocsp.serverpass.telesec.de/ocspr mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
    security: OCSP Response: GOOD
    network: Verbindung von http://ocsp.serverpass.telesec.de/ocspr mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
    security: UNAUTHORIZED
    security: Failing over to CRLs: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED
    network: Cacheeintrag gefunden [URL: http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl, Version: null] prevalidated=false/0
    cache: Adding MemoryCache entry: http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl
    cache: Resource http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl has expired.
    network: Verbindung von http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
    network: Verbindung von http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
    network: ResponseCode für http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl: 200
    network: Codierung für http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl: null
    network: Verbindung mit http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl trennen
    CacheEntry[http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl]: updateAvailable=true,lastModified=Tue Mar 24 10:50:01 CET 2015,length=53241
    network: Verbindung von http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl mit Proxy=HTTP @ internet-proxy.***:80 wird
    network: Verbindung von socket://ldap.serverpass.telesec.de:389 mit Proxy=DIRECT wird hergestellt
    security: Revocation Status Unknown
    com.sun.deploy.security.RevocationChecker$StatusUnknownException: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED
        at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source)
        at com.sun.deploy.security.RevocationChecker.check(Unknown Source)
        at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)
        at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)
        at com.sun.deploy.security.RevocationCheckHelper.checkRevocationStatus(Unknown Source)
        at com.sun.deploy.security.X509TrustManagerDelegate.checkTrusted(Unknown Source)
        at com.sun.deploy.security.X509Extended7DeployTrustManagerDelegate.checkServerTrusted(Unknown Source)
        at com.sun.deploy.security.X509Extended7DeployTrustManager.checkServerTrusted(Unknown Source)
        at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
        at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
        at sun.security.ssl.Handshaker.processLoop(Unknown Source)
        at sun.security.ssl.Handshaker.process_record(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
        at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
        at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
        at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
        at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source)
        at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source)
        at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
        at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
        at com.sun.deploy.model.ResourceProvider.getResource(Unknown Source)
        at com.sun.javaws.jnl.LaunchDescFactory._buildDescriptor(Unknown Source)
        at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
        at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
        at com.sun.javaws.Main.launchApp(Unknown Source)
        at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
        at com.sun.javaws.Main.access$000(Unknown Source)
        at com.sun.javaws.Main$1.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
        Suppressed: com.sun.deploy.security.RevocationChecker$StatusUnknownException
            at com.sun.deploy.security.RevocationChecker.checkCRLs(Unknown Source)
            ... 35 more
    Caused by: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED
        at sun.security.provider.certpath.OCSP.check(Unknown Source)
        at sun.security.provider.certpath.OCSP.check(Unknown Source)
        at sun.security.provider.certpath.OCSP.check(Unknown Source)
        ... 36 more
    security: Ungültiges Zertifikat vom HTTPS-Server
    network: Cacheeintrag nicht gefunden [URL: https://my-site.de:80, Version: null]

    Add the JSF Jars to the WEB-INF/lib directory of the application. If still getting error add to the CLASSPATH variable in the startWebLogic script in the domain/bin directory.

  • WebStart Proxy Problem

    Hey guys,
    i´ve got the following problem and it would be sooo great if you could help me:
    i´ve got 2 apps which are launched over webstart. in webstart the network connection is set to a proxy. this setting is correct for app A. the other app B should ignore these setting and should go over a direct connection to the network.
    now my question: how can i ignore the webstart settings for the proxy connection in my java app B, so that i can establish a direct connection?
    many thanks for your help!!
    greetz, iTob

    Yep, the problem was with the location for the applications folder, for some reason it was different to the users profile folder.
    I went into the web start application manager, then under preferences and advanced i checked that the applications folder location was correct and pointed to a valid folder.
    Hope this helps
    Alistair

  • Upgrade JDK and WebStart - big problems

    I have been developing (compiling and running) a J2EE application using JDK 1.3.1_02. Now I am trying to upgrade it to Java 1.4.2_03. This process has been very frustrating and left me with a bunch of questions.
    The application uses several external JAR libraries (JavaDatePicker, rpValidation) and some J2EE libraries (ejb.jar, jta.jar, oc4jclient.jar, etc...). For the most part, when I examine the manifest of these jars, they say that they were created by java 1.3.
         eg: jta.jar
              "Manifest-Version: 1.0
              Created-By: 1.3.1_02 (Sun Microsystems Inc.)"
    QUESTION #1) Do these jar files need to be upgraded to a v1.4? In other words, can I run an application using Java 1.4 if it references a library that was created with Java v1.3?
    POTENTIAL ANSWER) I don't think that they need to be upgraded b/c if so then the newer JDev (which ships with jdk 1.4) would contain newer versions.
    The application works when I run it from my development environment (JDeveloper 9.0.3.3 with a newly installed JDK 1.4.2_03). However, it does not work when I run it from Java Web Start. The problem comes when it's time to do an RMI lookup on an EJB. At that point the program throws the following exception:
         javax.naming.NamingException: Lookup error: java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionContext; nested exception is:
              java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionContext
    This error has never happened before. It only occurs when I changed the descriptor in the jnlp file from <j2se version="1.3"/> to <j2se version="1.4"/>. I know that the class is deployed because I include the jar in the jnlp file.
    local.jnlp:
         <resources>
         <j2se version="1.4"/>
         <jar href="client.jar" />
         <jar href="mymt.zip" />
         <!-- Javadatepicker libraries -->
         <jar href="javadatepicker.jar" />
         <jar href="metouia.jar" />
         <jar href="kunststoff.jar" />
         <!-- RM lookup library -->
         <jar href="RMInterfaces.jar" />
         <!-- J2EE libraries -->
         <jar href="ejb.jar" />
         <jar href="oc4jclient.jar" />
         <jar href="jta.jar" />
         <jar href="jaas.jar" />
         <jar href="jms.jar" />
              <jar href="jmxgrinder.jar" />
              <jar href="jmxri.jar" />
              <jar href="jmxtools.jar" />
         <!-- Field Validation Library -->
         <jar href="rpValidation.jar" />
         <extension name="common" href= "localmt.jnlp" />
         </resources>
    To further complicate things, I did a search and found that HttpSessionContext is: "Deprecated. As of Java(tm) Servlet API 2.1 for security reasons, with no replacement. This interface will be removed in a future version of this API."
    But my code never even calls this class. So I'm guessing that something in one of the libraries calls it. And these libraries must be from the old JDev and thus call old classes. So I upgraded all the j2ee libraries that I bundle in the deployed application with the ones that ship with JDev 9044. However, I still get the same error.
    What I don't understand is why it runs in JDev but not after being deployed with JWS ?! What's wrong with my RMI lookup?

    After upgrade, previous admin account will not work. You will need to add GUI admin account through the console access. So before starting with upgrade process please make sure you have console access available for the appliance. Command would be :
    add-guiadmin [admin] [password]
    Syntax Description
    admin User name for the GUI account.
    password Password for the GUI account.
    Usage Guidelines
    If you do not set up a GUI account using the add-guiadmin command, then there is no way to access the ACS SE other than through the CLI administrator account and a serial connection. After initial installation of the ACS SE, add a web GUI account using this command.

  • Invalid Argument Error

    I am getting above error on load of the JNLP file. When I access the URL for the JNLP, the JNLP file downloads (I can see the content using Ethereal) and WebStart does launch. So, I assume MIME type is OK and the download servlet is working, at least enough to serve up the JNLP.
    What makes this more curious is that it is a working configuration in Jetty. I can take the exact same application - drop it in Jetty, it works; drop the SAME file in Tomcat 4.1.27, it doesn't work.
    Anyone seen this?
    WS 1.2
    J2SDK 1.4.1_01 on both ends.
    Tomcat 4.1.27
    The error and log information is as follows.
    Error dialog/General Tab:
    An error occurred while launching/running the application.
    Category: Invalid Argument error
    Could not load file/URL specified: C:\Documents and Settings\mjf860\Local Settings\Temporary Internet Files\Content.IE5\2DQR21KT\cwms[1].jnlp
    The JNLP file does in fact NOT exist (the directory does, no JNLP files are in in it), despite the fact that I saw it go over the network to my box.
    The JNLPServetLog stuff:
    JnlpDownloadServlet(3): Request: /cwms/app/cwms.jnlp
    JnlpDownloadServlet(3): User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; H010818)
    JnlpDownloadServlet(4): DownloadRequest[path=/app/cwms.jnlp isPlatformRequest=false]
    JnlpDownloadServlet(4): Basic Protocol lookup
    JnlpDownloadServlet(4): JnlpResource: JnlpResource[WAR Path: /app/cwms.jnlp lastModified=Tue Sep 09 17:14:51 EDT 2003]]
    JnlpDownloadServlet(3): Resource returned: /app/cwms.jnlp
    JnlpDownloadServlet(4): lastModified: 1063142091684 Tue Sep 09 17:14:51 EDT 2003
    TIA,
    Mike

    I just found out by searching tomcat list that in your
    dynamic jnlp file you can set the cache-control to
    public using
    response.setHeader("Cache-Control", "public")
    This will allow Internet Explorer to cache the jnlp
    file and you won't get the exception.
    This way you can keep your jnlp file under a security
    constraint.I wasn't sure what was meant by "dynamic JNLP" or how to follow the above procedure, so I created a servlet (a JSP, actually) to implement the above workaround. It will serve JNLP files from a password-protected directory in a way that works for the Tomcat-to-Internet Explorer combination. It's posted below in case it can help anyone else.
    There are still a few things to watch out for: (1) the protection (the <auth-method> tag in your web.xml file) for the JNLP file must be BASIC--FORM will not work. (2) you will have to enter the password twice--once for the browse and again for Web Start.
    The servlet itself is enclosed below. If you have questions about it, please post them to this forum.
    Bob Pollack
    Gestalt, LLC
    <%@ page import="java.io.*" %>
    <%
    // This is a fetch program to retrieve a JNLP file from a
    // password-protected directory. Java Webstart has problems
    // doing this directly, so this program must be used instead.
    // That is, instead of a link that points to "xxx.jnlp", make
    // a link that points to "fetchJNLP.jsp?name=xxx.jnlp".
    // Even with this program, the only kind of authentication
    // that Webstart understands is basic authentication.
    // You cannot use form-based authentication and Webstart together.
    String jnlpName = request.getParameter ("name");
    String myPath = request.getServletPath ();
    String myURL = request.getRequestURL ().toString ();
    String dirPath = null;
    String dirURL = null;
    String jnlpPath = null;
    String jnlpRealPath = null;
    boolean abort = false;
    // Screen the name parameter to make sure that hackers
    // cannot use this program to fetch any old thing
    // The current criteria are that the name must be a JNLP file
    // in this directory
    if (jnlpName == null)
    abort = true;
    else if (! jnlpName.endsWith (".jnlp"))
    abort = true;
    else if (jnlpName.indexOf ("/") >= 0)
    abort = true;
    if (abort)
    response.sendError (response.SC_FORBIDDEN);
    return;
    int pos = myPath.lastIndexOf ("/");
    if (pos < 0)
    pos = myPath.length ();
    dirPath = myPath.substring (0, pos);
    pos = myURL.lastIndexOf ("/");
    if (pos < 0)
    pos = myURL.length ();
    dirURL = myURL.substring (0, pos);
    if (jnlpName.startsWith ("/"))
    jnlpPath = jnlpName;
    else
    jnlpPath = dirPath + "/" + jnlpName;
    out.clear ();
    response.setContentType ("application/x-java-jnlp-file");
    // The following line is the reason this servlet exists.
    // If a JNLP file is in a protected directory, Tomcat will
    // send it out with a Cache-Control header of "no-cache",
    // which keeps the client end of JNLP from working.
    // See Java Developer Forum,
    // "Java Web Start & JNLP: Invalid Argument Error",
    // at http://forum.java.sun.com/spider.jsp?f=38&t=442995
    // for a rambling discussion of this issue.
    response.setHeader ("Cache-Control", "public");
    jnlpRealPath = application.getRealPath (jnlpPath);
    File jnlpFile = new File (jnlpRealPath);
    FileReader fr = new FileReader (jnlpFile);
    BufferedReader br = new BufferedReader (fr);
    while (true)
    String line = br.readLine ();
    if (line == null)
    break;
    // As long as we're doing this anyway, we'll add a service
    // that substitutes the full URL for this directory into
    // the codebase of the outgoing JNLP file. This will make it
    // possible for the files to be moved from machine to machine
    // without changes.
    // For example, instead of saying
    // codebase="http://myhost:8080/home/protected"
    // the JNLP file can say
    // codebase="$BASE"
    String base = "$BASE";
    pos = line.indexOf (base);
    if (pos < 0)
    out.println (line);
    else
    out.print (line.substring (0, pos));
    out.print (dirURL);
    out.print (line.substring (pos + base.length ()));
    out.println ();
    out.flush ();
    out.close ();
    %>

  • Signed JNLP restrictions

    Hi all,
    I have a java application distributed as a signed JNLP.
    Inside this application I can read/write stuff to the filesystem, read system properties, etc... but I'm getting one issue that I believe it wasn't happening with jdk 1.5.
    I'm trying to enable the ARD from the JNLP, so I invoke osacript with administrator privileges to run kickstart.
    This is what I'm getting:
    stdErr [0:175: execution error: Security API failed with error -2129264641. (1)]
    I have also tried using 'sudo' and the result is:
    stdErr [/bin/sh: /usr/bin/sudo: Operation not permitted]
    Is there any restriction somewhere for signed JNLP apps?
    Many thanks for your inputs!
    Luis

    >
    I have an application that has been distributed via WebStart without problem for a while. Recently (since 1.6.0_11) we started getting warnings because our JNLP file sets restricted properties, so we had to sign the JNLP.>'Sign the JNLP'? Do you mean 'requested extra permissions in the JNLP, and signed the Jar files'? The second I am quite familiar with, the first I have never heard of. The rest of your post sounds similarly bass-ackwards.

  • Has anyone ever used web start in large scale ?

    Dear friends,
    have you ever used some web start application in large scale ?
    i.e., have you distributed some real application with web-start?
    I�m doing such experience here and I�m a bit afraid about several problems in the final user machine - such as java version, browser incompatibility and mainly with the ugly WebStart cache problems.

    can you give a bit more detail on what exactly you're afraid of? is this a www application? internal business app? etc.
    for example you can force your java version in java web-start,etc...

  • Advantages of Web Start

    Me and the company I work for are about the make the final decision what to choose, Java Web Start or just plain JavaServer Pages. I intend to choose the Web Start but still I would like to know some more;
    Who has used for quite some time and what is your experience? What are the common problems?
    Thanx
    EJS

    I suggest you search across the sun site and using google. There many articles about this topic.
    For example
    http://java.sun.com/products/javawebstart/developers.html
    http://java.sun.com/products/javawebstart/index.jsp
    http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/faq.html
    http://www.vamphq.com/talk/jug-jan-2002/slides.html#jws-16
    http://www.javaworld.com/javaworld/jw-07-2001/jw-0706-webstart.html
    file:///D:/Documents%20and%20Settings/Administrator/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/U1CR6TAL/256,1,Slide 1
    http://servlet.java.sun.com/javaone/javaone2000/pdfs/TS-1473.pdf
    I use it for a few reasons.
    1) The initial installiation of the my software on a clients machine is very easy (After the Sun VM is installed from the sun site). Simply a link on a web page.
    2) I only need to update my software on the server and it is automatically updated on the users machines. Maintenance is easy and it is transparent to the user.
    3) After the initial setup it is only necessary to involve the system techs very rarely. (If a JNLP change is required)
    4) It offers a secure environment.
    I have been very pleased with Webstart.
    Problems I have encountered.
    1) It is necessary to do some testing under Webstart after development modification and testing. There are some cases where the program may run as a standalone or jar and fail under Webstart. There seem to be few of these and I have been able to address any I have encountered.
    2) The security constraints have sometimes taken some time to overcome. For example getting third party or additional jars signed, to distribute, and work can be a pain.
    The user forums have been a great help.
    rykk

  • Jar files download problems in Java Webstart with JRE 1.6

    We have encountered a few problems in Java Webstart with JRE 1.6
    In JRE 1.5, the jar files are getting downloaded onto the client
    machine with it's original names.
    Example :
    Server File Name : acm.jar
    Client File Name : RMacm.jar
    But in JRE 1.6, the jar files are getting downloaded with improper file names.
    Example :
    Server File Name : acm.jar
    Client File Name : 4fb074cc-66fc7407
    Moreover the path itself seems to be invalid.
    Example Path :
    JRE 1.5 path:
    C:\Documents and Settings\Administrator\Application
    Data\Sun\Java\Deployment\cache\javaws\https\D17.16.23.11\P443\DMtest\DMwebStart
    JRE 1.6 path:
    C:\Documents and Settings\Administrator\Application
    Data\Sun\Java\Deployment\cache\6.0\12
    Due to this, we are facing Classpath problems.
    What changes do we have to make to the code, for Java
    Webstart to work ?
    We are using JBoss 4.0.4 and JDK 1.5 in the Server
    On the client machine, we have IE 6 and JRE 1.6.01
    Help would be appreciated.

    Ask your Java Web Start question at:
    http://forum.java.sun.com/forum.jspa?forumID=38

  • Problem in launching webstart application when using version atribute

    Hello Experts,
    I am trying out my first example of JNLP. This is my JNLP file.
    <?xml version="1.0" encoding="UTF-8"?>
    <jnlp spec="1.0+" codebase="http://localhost:8092/webApplForWebStart" href="launch.jnlp">
        <information>
            <title>ForWebStart2</title>
            <vendor>NAgrawal</vendor>
            <description>ForWebStart2</description>
            <description kind="short">ForWebStart2</description>
            <homepage href=""/>
            <offline-allowed/>
            <shortcut online="true">
              <!-- create desktop shortcut -->
              <desktop/>
              <menu submenu="WebStart Trial"/>
         </shortcut>
        </information>
        <security>
            <all-permissions/>
        </security>
        <resources>
            <j2se version="1.5+"/>
            <jar href="JNLPTime.jar" version="1.0" main="true" download="eager"/>
        </resources>
        <application-desc main-class="TheTime">
        </application-desc>
    </jnlp>My Problem is if I remove version="1.0" from <jar > tag application is launching properly. But if I am using version attribute , it is giving me this error while launching the application.
    "Unable to load resource :( http://localhost:8092/webApplForWebStart/JNLPTime.jar , 1.0)
    java.io.IOException : missing version response from server."
    I can't afford to remove the version attribute as it is required for auto-update. Has anyone ever tried faced such problem.? Please help me. Any help is highly appreciated.Thanks in advance.

    It's just as told.
    If you're using explicit versions, the server response MUST provide an header to tell which version is returned (you could be using 'wildcards' like 1+).
    How are you serving requests? Are you using JnlpDownloadServlet? If so, check docs: extra work is required in order to use version features.
    If using your own service google for header (and parameter) name, use exact versions and copy to the response the value you're retrieving from the request.
    Bye.

  • Problem in webstart with show() statement

    hi
    I'm trying to use webstart for my application but i'm dealing with some problems. Most of them are solved, but one error is still bugging me.
    When I use the statement show() for a JFrame, the application doesn't respond anymore, however it is still doing something according to the windows task manager.
    Anyone who could help me?
    Thx

    What version Java Web Start are you using ?
    There is a Known problem in 1.0.1 (1.2 too) where if no windows are showing, awt ends the EventQueue thread, then later when you show something it starts a new one without the right ContextClassLoader set.
    this was fixed in 1.4.2

  • Problems with Webstart installer

    In our Windows 2000 workstation configuration normal users are not allowed to install programs, which modify the registry. Thus, administrator priviledges are required to install Java Webstart.
    The problem is that when the normal user logs into the machine the webstart icon does not show up on the user's desktop (because the admin has installed it).
    Therefore, I assume that the desktop icon is written to the installing user's desktop folder (the admin). I assume that the icon should be stored in the All Users desktop folder to avoid the problem.
    Of course, it is not difficult to create the shortcut for other users, however, if you have to do a lot of webstart installations, it is better if this is already accomplished by the installer.
    I would appreciate, if the JWS Team could address this issue soon.
    Kind regards
    Thomas G�lden
    [email protected]

    In our Windows 2000 workstation configuration normal
    users are not allowed to install programs, which
    modify the registry.Sounds typical. I hope such issues will be solved, because many people will try to use Web Start for deployment in medium to larger companies. These have full time admins, who will enforce stricter security permissions than the usual user is admin mess. :)
    It would be interesting to check the available Web Start sources regarding to what registry entries are set/modified by Web Start installation.
    The ones I am aware of have to do with the MIME registration of Web Start, thus that mechanism that will
    activate the Web Start client, when a link to a .jnlp URL is hit from the web browser.
    Thus I wonder what will happen if you try two Web Start installations:
    1. admin installation that will do the mime registrations
    2. user installation that will perhaps notice that the mime registration has already been done and just set up the user specific stuff, like user cache and user desktop icons
    Regards,
    Marc

  • Problem using Java Webstart to kick off CORBA Client

    Dear all,
    I am currently having a problem in using the Java Webstart to kick off
    the CORBA Client, I set up the JNLP file jvm properties as following:
    <resources>
    <j2se version="1.4*" java-vm-args="-Xms64m -Xmx256m -verbose -esa
    -Xnoclassgc -client -Dswing.useSystemFontSettings=false ">
         <resources>
         <property name="vbroker.orb.initRef"
    value="NameService=corbaloc::10.35.55.82:20005/NameService"/>
    </resources>
    </j2se>
    </resources>
    The problem I have is that when the webstart starting the client, the
    client just simply dies during the startup and I find the log message
    following:
    org.omg.CORBA.ORBPackage.InvalidName
         at com.inprise.vbroker.orb.ORB.resolve_initial_references(ORB.java:943)
    So it is showing that there is problem with the vbroker.orb.initRef
    setting, know that if I don't use the webstart to start the client and
    simply use the windows batch file, using the jvm properties as:
    java -Dvbroker.orb.initRef=NameService=corbaloc::10.31.51.80:20001/NameService
    It would work perfectly.
    Could you tell if I miss anything when configuing the webstart jnlp
    file on this regard? Currently, I think that the only way I can set
    the JVM properties in the JNLP file is to use its properties tag to
    set the system properties for the application.
    Thanks heaps in advance for any help you can give here !!!
    Victor

    Hi, Andre,
    No, I have tried both of your suggestion and there was no joy. I still have the following error and the client jvm just crashes during starting up:
    org.omg.CORBA.ORBPackage.InvalidName
         at com.inprise.vbroker.orb.ORB.resolve_initial_references(ORB.java:943)
    I believe it is still related to the jvm properties:
    <property name="vbroker.orb.initRef" value="NameService=corbaloc::10.35.55.82:20005/NameService"/>
    And know that when I used "-Dvbroker.orb.initRef=NameService=corbaloc::10.35.55.82:20005/NameService" in the windows batch file, the client runs ok.
    Is this indicating that there is the limitation of using the webstart to invoke CORBA client?
    Any further help would be very appreciated!
    Victor

  • Webstart, file loding problem

    Hello all.
    ok my problem is:
    I am using webstart to transfer the client app to the client PC
    a part of the files that i am transfering is the plugins for the client.
    these will need to be loaded in later when the client runs.
    ok now to the problem, what do i need to write for the client app to be able to find the plugins, without knowing which plugins there are and what there names are.
    the only way i know what there names are is when i load in the xml files that were also downloaded and also need to be loaded in the same way.
    each xml file contains the info for a plugin.
    pls people help me here i have no idea what to do.
    Ask any questions if you dont understand what i am saying.

    Master_Zog wrote:
    so which of the 2 strategies will wwork best and how can i make them work.
    // The plug-in Jar(s) should be on the application's run-time classpath if added to
    // the resources section of the JNLP file, because of that, it is not necessary to
    // establish a new ClassLoader (URL or otherwise) to access them.  The context
    // classloader should locate the URL just fine.
    //  UrlClassLoader loader = new UrlClassLoader(new URL{pluginFile.toURI().toURL()});
    ClassLoader loader = Thread.currentThread().getContextClassLoader();
    Class<ServerPlugin> plugin = loader.loadClass("Plugin").asSubclass(ServerPlugin.class);BTW - since the loadClass method requires the fully qualified name of the plug-in, and it would make sense to have many plugins, that reference to "Plugin" as opposed to something much more specific, like "com.their.RtfPlugin", or "org.our.XmlPlugin", is a bit worrying. One single plug-in name, in the default package, would completely stuff the approach mentioned above for multiple plug-ins.
    But then, I suspect having one single plug-in name would be problematic in other ways..
    The plug-in (fully qualified) names are unique. Yes or no?

  • Problem with WebStart & applicaton parameters or properties..

    Ok. I have a WebStart application which is supposed to be launched from a website only (not offline-allowed - even though you seem to be able to launch it offline! grr) and the application needs to take TWO parameters from the website. I am currently using Properties to accomplish this. The website (using Enhydra) dynamically generates a .jnlp file that specifies the correct properties. I can confirm this by DOWNLOADING the .jnlp file and viewing it in notepad. However, when WebStart actually runs this, it's caching the very first JNLP my app was ever launched with, and using THOSE parameters. My question is.... WHY AND HOW DO I MAKE IT STOP. ^_^ This is just another twist in my way-too-complicated-and-painful quest to simply pass some parameters to my application. (another other suggestions on how to simply pass two strings are also appreciated.)
    Thanks,
    -xanatos

    Hi,
    the short answer is leave jnlp.href empty and Web Start won't reload/cache you startup file.
    For more details check out the Unofficial JNLP/Web Start FAQ at http://www.geocities.com/vamp201/jwsfaq.html
    - Gerald

Maybe you are looking for