2012-03-08 22 views
8

HERES THE ANSWER: E appare (attraverso i nostri test) che Java 7 Web Start richiede di ospitare le risorse su un server utilizzando un certificato SSL. Il tuo certificato NON deve essere firmato, ma i certificati non firmati invieranno al client un messaggio di fiducia che potranno ignorare. Vedere la risposta seguente per ulteriori dettagliJava Web Start interrotto da JDK 1.7

Abbiamo un'applicazione interna che utilizziamo da molti anni. Per semplificare la manutenzione di questa applicazione non abbiamo fornito ai nostri dipendenti una versione installabile dell'applicazione, semplicemente assegniamo loro un collegamento a .jnlp e usiamo JWS per avviarlo sulla loro scatola. Finora questo ha funzionato in modo fantastico, ma non appena i nostri dipendenti si aggiornano a Java 7, il sistema JWS smette di funzionare sul proprio computer. Abbiamo controllato, ricontrollato e persino validato il nostro schema JNLP ed è corretto, il che ci porta a pensare che ci sia un problema con lo stesso Web Start.

Quando l'utente fa clic sul file jnlp, avvia la schermata iniziale di Java 7, che quindi inizia a scaricare le risorse necessarie. Da lì semplicemente si blocca e la barra di avanzamento sull'app di lancio JWS rimane allo zero percento.

Qualche idea? È causato dal fatto che eseguono l'aggiornamento a Java 7. Nel frattempo, abbiamo avvisato che tutti i dipendenti devono rimanere su Java 6 fino a nuovo avviso. Tutto il nostro codice è firmato correttamente.

Ecco una copia della nostra JNLP:

<?xml version="1.0" encoding="utf-8"?> 
<jnlp 
    spec="1.5+" 
    codebase="http://peiportal/updater"> 
    <information> 
    <title>PEI Portal Application</title> 
    <vendor>Petz Enterprises, Inc.</vendor> 
    <offline-allowed/> 
    </information> 
    <security> 
     <all-permissions/> 
    </security> 
    <resources> 
    <jar href="PEIPortalLauncher.jar"/> 
    </resources> 
    <application-desc/> 
</jnlp> 
+0

Hai provato a qualificare completamente il nome host (peiportal) nella codebase? Probabilmente non è così semplice, ma solo un pensiero. –

+0

Congratulazioni per la bella esperienza finora. Non tutti ricordano positivamente il webstart. Si prega di postare l'eccezione dalla finestra di webstart. Hai provato 'spec =" 6.0+ "'? Dovresti aggiungere un attributo 'href =" http: // peiportal/updater/percorso al file jnlp "' all'elemento jnlp. – Stephan

+0

Anche gli elementi 'j2se' e' application-desc' sono mancanti. Penso che la specifica 1.5 sia andata deprecata. – Stephan

risposta

12

Abbiamo recentemente imbattuto in questo problema quando la gente ha iniziato l'installazione di Java 7 sulle loro macchine Windows. Abbiamo istanze di file jar su tre diversi server Linux e abbiamo scoperto che è possibile scaricare l'applicazione da due di essi, uno remoto e uno locale, ma non il terzo, anche locale, server.

La chiave era nella specifica codebase nel file jnlp. Affinché il file jar venga scaricato correttamente in una finestra di Windows con Java 7, il codebase deve specificare "https: ..." anziché "http: ...".

Il server remoto citato sopra è configurato come server sicuro, e quindi è stato appositamente configurato con https. Nessuno dei server locali è configurato in modo sicuro, ma quello che ha funzionato ha semplicemente utilizzato "https:" nella specifica codebase. Cambiare il jnlp sull'altro server ha funzionato bene. (Il nostro jnlp è basato su modelli e modificato per ogni installazione al di fuori del controllo sorgente, quindi il potenziale di differenze.)

Potrebbe essere necessario eliminare tutte le applicazioni non funzionanti elencate nel pannello di controllo Java per sincronizzarsi con il nuovo jnlp in il tuo server: vai nella scheda Generale del pannello di controllo Java (disponibile dal pannello di controllo di Windows), premi il pulsante "Visualizza ..." in "File temporanei Internet" ed elimina tutte le applicazioni non funzionanti.

+2

che è ESATTAMENTE qual è il problema. Abbiamo cercato ovunque questa soluzione e non è stato segnalato dove hanno cambiato il web start per richiedere SSL quando si scaricano le risorse in Java 7. Speriamo che gli altri vedano questo e ottengano la soluzione ora, grazie. –

2

Mentre la risposta di grw è sicuramente corretto, ho lavorato intorno a questo problema forzando 1,6 nel mio file JNLP:

<resources> 
- <j2se version="1.6+" java-vm-args="-Xmx256M"/> 
+ <j2se version="1.6" java-vm-args="-Xmx256M"/> 

utilizzare la seconda riga nella patch sopra, senza il plus. Ciò dovrebbe costringere Java 7 a scaricare i file usando un JRE Java 6, che funzionerà quindi.

+0

Ho appena provato questo e sembra funzionare, tuttavia voglio sottolineare l'avvertenza che sarà necessario avere un JVM 1.6 installato per poterlo effettivamente eseguire (ovviamente). Grazie per l'heads-up, però, non avevamo incluso la linea di cui sopra e come tale non avevamo nemmeno esplorato questa rotta. –

+1

Credo che Java 7 vm installerà la versione corretta se la chiedi con la riga sopra. Non ne sono sicuro, ma piuttosto sicuro. –

+0

dal modo in cui capisco lo schema che verrà eseguito se si aggiunge il seguente attributo href: href = "http://java.sun.com/products/autodl/j2se" Ecco dove ho trovato le informazioni più preziose: http://mindprod.com/jgloss/jnlp.html –

1

Quando l'utente fa clic sul file jnlp, avvia la schermata iniziale di Java 7, che quindi inizia a scaricare le risorse necessarie. Da lì semplicemente si blocca e la barra di avanzamento sull'app di lancio JWS rimane allo zero percento.

FWIW, questo può anche essere causato da un deadlock in Webstart risolto solo in 7u10 (come ancora in beta). Vedi http://javafx-jira.kenai.com/browse/RT-25023. Il deadlock sembra essere compreso tra il thread GUI (ad es. Per la console Java) e un thread di download jar.

+0

suona come potrebbe essere il problema. Siamo passati a SSL e l'abbiamo risolto, ma questa potrebbe essere la radice del perché non funziona ancora con connessioni non protette. Avrò l'uptote, ma non ho tempo per testarlo adesso ... comunque buone informazioni da avere qui per chiunque abbia un problema con le versioni precedenti di Java 7, quindi grazie! –

4

Per chi non ha avuto accesso al link fornito da kenai.com deepc: Il bug citato è

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191454

Un altro bug che ho trovato nel bug DB Java che potrebbe corrispondere per descrizione potrebbe essere

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040

Speriamo Java Web Start funziona su HTTP di nuovo con U10 ...


Aggiornamento: Nel nostro caso si è scoperto che AVG antivirus è stata la causa. Nelle impostazioni di AVG, disabilitare sia "Online Shield" che "Surf Shield" e la combinazione di Java 7, Windows 7 e HTTP semplice ha funzionato. Oppure esegui l'aggiornamento alla versione più recente di AVG 2012. Cf. http://forums.avg.com/in-en/avg-forums?sec=thread&act=show&id=216448.

0

Abbiamo avuto un problema simile dopo 1,7 aggiornamento, ma sono stati in grado di risolvere da sfuggire i caratteri nel file .jnlp per href, vale a dire, cambiando punto interrogativo e commerciale nel valore href con & # 63 e # 38 & rispettivamente.

href = "appname.jnlp? Protocollo = http & host = xx.xx.xx.xx & port = xx"

Questo approccio sarà po 'più sicuro, se la 1.6 viene eliminato dopo 1,7 aggiornamento, e mantenendo il valore della specifica su "1.6+".

2

Abbiamo riscontrato questo problema, ma abbiamo risolto il problema che il ServerName e AliasName nel nostro file di configurazione Apache includevano il numero di porta. cioè domain.com:443. Quando Java 7 confronta il ServerName non corrisponde e il problema si verifica. Rimuovendo il: 443 dal nome tutto va bene.

Problemi correlati