Domanda

Usiamo Java Web Start per distribuire un'applicazione Java sulla nostra Intranet. L'applicazione riceve aggiornamenti frequenti. Una volta in un po 'di un utente lancerà l'applicazione dal proprio desktop dopo aver aggiornato i JAR / WAR sul server web (timestamp è cambiato) e Java Web Start lancerà la vecchia versione invece di scaricare uno nuovo.

Ecco una pasta della nostra JNLP, come si può vedere offline-permesso è acceso, ma l'aggiornamento di controllo sempre e la politica sempre. Inoltre, scaricare bandiera è ansioso. Dalla mia comprensione queste opzioni dovrebbero sempre comportare un controllo di cache di contro timestamp sul server e il download del file JAR.

sto iniziando a ottenere frustrati con Webstart! Qualcuno ha visto problemi la classica? Eventuali soluzioni? Sto ammalarsi di persone a piedi attraverso la compensazione la cache webstart manualmente ogni terzo o quinto aggiornamento.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE jnlp PUBLIC "-//Sun Microsystems, Inc//DTD JNLP Descriptor 6.0//EN" "http://java.sun.com/dtd/JNLP-6.0.dtd">
<jnlp spec="1.0+" codebase="$$codebase" href="$$name">
  <information>
    <title>TITLE</title>

    <vendor>VENDOR</vendor>

    <description>Our Utility Application</description>

    <description kind="short">Our Utility Application PRD</description>
    <icon href="images/util_icon.png" height="64" width="64"/>
    <offline-allowed/>
    <shortcut online="true">
      <desktop />
      <menu submenu="Utility Apps"/>
    </shortcut>
  </information>

  <security>
     <all-permissions />
  </security>

  <update check="always" policy="always" />

  <resources>
    <!-- requires 1.6+ -->
    <j2se version="1.6+" href="http://java.sun.com/products/autodl/j2se" java-vm-args="-ea" initial-heap-size="128m" max-heap-size="512m" />

    <!-- application code, download jar before we start. -->
    <jar href="OurUpdatedJarName.jar" main="true" download="eager" />

    <property name="configfile" value="updatedJarName.config" />
  </resources>

  <application-desc main-class="main.Client">
    <argument>-D</argument> 
  </application-desc>
</jnlp>
È stato utile?

Soluzione

Si potrebbe avere risolto il problema - Ma jnlp spec = "1.0+" - L'elemento è supportato solo dopo jnlp spec 6.0+. Probabilmente thats che è uno dei motivi per i vostri aggiornamenti fallimento.

Altri suggerimenti

Supponendo che i JRE client vengono aggiornati, si potrebbe provare <update check="timeout" policy="always"/> come suggerito in questo infilare e descritti nella JNLP documentazione di sintassi .

Ho avuto gli stessi problemi come la vostra e risolto nel modo seguente:

  1. Cambia

    <jar href="OurUpdatedJarName.jar" ...

    a

    <jar href="OurUpdatedJarName-$VERSION.jar" ...

  2. Mettere $ VERSION nella <a href="foo-$VERSION.jnlp">Run</a>

Aggiorniamo automaticamente $ VERSION per ogni distribuzione.

Lo so che è una soluzione brutta, ma è uno che lavora per noi ogni volta.

questo problema è causato da tag offline-allowed.

Per JNLP spec

Se non viene specificato in linea-permesso, Java Web Start sarà anche controllare per vedere se è disponibile un aggiornamento. Tuttavia, se l'applicazione è già scaricato il controllo verrà timeout dopo pochi secondi, nel qual caso l'applicazione nella cache sarà lanciato invece. Data una connessione server ragionevolmente veloce, l'ultima versione dell'applicazione sarà solitamente essere eseguito, ma non è garantito . L'applicazione, tuttavia, può essere eseguito offline.

abbiamo distribuito le applicazioni Java Web Start oltre una dozzina di paesi e quando abbiamo scoperto che l'applicazione non è stata correttamente l'aggiornamento è stato per un miss-configurazione della rete della contea, o nelle impostazioni di rete del computer dell'utente, per lo più la proxy. Nei nostri officines centrali in Spagna Java Web Start allways lavoro ok.

Ho usato il clone Java Web Start nextx.jar. Ho rintracciato il mio problema JAR non aggiornare per l'utilizzo del metodo URLConnection.getLastUpdated (). Dal momento che utilizza il metodo HEAD per ottenere il lastUpdated del nome del file, questo è il motivo per cui a volte non scaricare a causa di caching del getLastUpdated (). Abbiamo deciso di utilizzare il nostro proprio metodo di rinfrescare la nostra applicazione come webstart è viziata.

ho avuto questo problema solo perché non ho lasciato l'applicazione aperta abbastanza tempo per completare l'aggiornamento.

Se si dispone di questa opzione: controllo di aggiornamento = "background" nella vostra JNLP, attendere qualche tempo prima di chiudere l'applicazione in modo da consentire l'aggiornamento (che è in esecuzione su sfondo) Fine

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top