Detecting if next generation plug-in is activated

Hi,
I am wondering if there is a way to programatically detect if the next generation plug-in check box is selected for the JRE/Control Panel (1.6_11).
We are having trouble with our software when this is enabled (the default) and want to notify the user to turn it off. I am assuming that this value is stored in the registry or some properties file but I can't seem to find it.
Thanks!
-Rob

The Deployment Toolkit portion of this document
file:///C:/Program%20Files/Java/docs/technotes/guides/jweb/deployment_advice.html#deplToolkit
has a link to deployJava.js which contains a function that will tell you if the new plugin is active.

Similar Messages

  • Next-generation plug-in 1.6 : ClassNotFoundException and not caching JARs

    Hi,
    Since the introduction of the next-generation plug-in in Java 1.6.0_10, the applet I have used and developed for many years don't load anymore.
    The situation is this : the Jars of this applet are embedded in a Lotus Notes database as Java resources, in order to be used in a particular form in my application. Note that this application is accessed via a Web browser through a Domino server and that this application requires a user authentication. If I try to open the form containing the applet while using a plug-in 1.6.0_10 or newer, with default parameters (cache and next-generation plug-in activated), here is the exceptions I get (here with plug-in 1.6.0_20) :
    load : class mycompany/tools/Planner not found.
    java.lang.ClassNotFoundException: mycompany.tools.Planner
         at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
         at java.lang.ClassLoader.loadClass(Unknown Source)
         at java.lang.ClassLoader.loadClass(Unknown Source)
         at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
         at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
         at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
         at java.lang.Thread.run(Unknown Source)
    Caused by: java.io.IOException: open HTTP connection failed:http://www.mycompany.com:80/test/database.nsf/46277DA0EF2790B0C12574040052D714/$FILE/mycompany/tools/Planner.class
         at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
         at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
         at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
         at java.security.AccessController.doPrivileged(Native Method)
         ... 7 more
    Exception : java.lang.ClassNotFoundException: mycompany.tools.PlannerBy reading a lot forums I found that a lot (really a lot) of people were experiencing the exact same issue, regardless of the type of server they used to host their applet. And unfortunately, only few answers were relevant to help me understand why I got this error...
    By looking deeper in the documentation, I have found this [Applet Developer's guide|http://download.oracle.com/javase/6/docs/technotes/guides/jweb/applet/applet_dev_guide.html]. Here, it is written that one of the enhancement of the next-generation plug-in is that : "+... The JVM running the applet is isolated from the web browser at the operating system level. If something should go wrong while running the applet, or if an uncooperative applet refuses to shut down, the new Java Plug-in detects and handles the error condition gracefully; the Web browser is unaffected+".
    I am not quite sure of what it really means, but I have started to think that my problem could be that, by running in a separate process than the one of the Web browser, loading the Jars will require an authentication on my server. To verify this hypothesis, I have changed the codebase of my applet, so the Jars are downloaded from another server where no user authentication is required. The good news is that my applet can now find the Jars and run as expected. The bad news is that none of the Jars are placed in the cache, which means that the Jars have to be downloaded each time I start a new session to work with my applet.
    I have also tried to disable the "Use the next-generation plug-in" option in the Java control panel. In this case, everything is fine, too, and even the Jars are stored in the cache. The interesting thing is that afterwards, by enabling the "Use the next-generation plug-in" option again, the applet will load and run like a charm... because the Jars are in the cache and the class loader can find them! (I suspect that this case has been experienced by several people, answering on forum posts that they cannot reproduce the issue.)
    Anyway, even if there is some workarounds to ensure it is possible to work with the latest versions of the plug-in, having to change the default options is not always easy or possible, depending of the environment. This applet that I am talking about is used by a lot of our customers and all have their internal policies and requirements regarding the Java configuration. If for some of them it will be possible to use a workaround, for others it will not. And this is a major problem to me.
    As I said, a lot of people have experienced this issue. I hope that someone having a better understanding on how this next-generation plug-in works, will have a solution, or at least, will be able to explain what is wrong in this approach and if my suggestion regarding an authentication issue for the class loader make sense.
    Any help will be greatly appreciated.
    Philippe

    Hi,
    I was wrong in my approach.
    My applet was implemented using the "<object>" tag and it seems that it was not the best way to address compatibility issues across all versions of the plug-in and all browsers.
    So, I have finally found what I was looking for in this "[Java Rich Internet Applications Development and Deployment|http://download.oracle.com/javase/6/docs/technotes/guides/jweb/index.html]" guide. In this guide, it is recommended to use the "[Deployment Toolkit|http://download.oracle.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html#deplToolkit]", based on a Javascript library containing everything needed to deploy your application as an applet or a Java Web Start application.
    My application, deployed as an applet, now works like a charm.
    I hope pointing on this Deployment Toolkit will also help others...
    Philippe

  • Ssvagent.exe does not always disable next-generation Plug-In

    Around half the time running the "ssvagent.exe -high -jpisetup -old" in a vbs after the jre-6u22-windows-i586.exe process stops running
    the next generation Plug-In option is not disabled.
    I have verified that it does not run until after the Java installtion is complete.
    Running "ssvagent.exe -high -jpisetup -old" manually right after installing Java will always disable next generation Plug-In.
    Any ideas why it won't always run properly from a script?
    Edited by: EthanD on Sep 20, 2012 10:21 AM

    Hi,
    I was wrong in my approach.
    My applet was implemented using the "<object>" tag and it seems that it was not the best way to address compatibility issues across all versions of the plug-in and all browsers.
    So, I have finally found what I was looking for in this "[Java Rich Internet Applications Development and Deployment|http://download.oracle.com/javase/6/docs/technotes/guides/jweb/index.html]" guide. In this guide, it is recommended to use the "[Deployment Toolkit|http://download.oracle.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html#deplToolkit]", based on a Javascript library containing everything needed to deploy your application as an applet or a Java Web Start application.
    My application, deployed as an applet, now works like a charm.
    I hope pointing on this Deployment Toolkit will also help others...
    Philippe

  • Next-Generation Plug-In settings in the Enterprise

    I work in a company of 1000+ desktops and various user groups running various core systems. For background, we've been standardized on IE 6 for years, and we're trying to move to IE 8.
    I'm looking into an issue with one of our core systems. It's a 3rd party solution that relies on an applet that fails when the latest JRE is downloaded and the "Enable the next-generation Java Plug-in" is checked (which it is by default).
    I've been searching the web, and I know most of the work-arounds, including how to run ssvagent.exe -high -jpisetup -old from the JRE install folder. I'm almost ready to pass this information on to our desktop admins, but I have a few questions I know they are going to ask. I would deeply appreciate any help in answering these questions:
    What is the possible impact of disabling the next-generation Java Plug-in on other applets from other 3rd party vendors? Are we likely to run into some applets/plug-ins that fail when this option is disabled?
    The vendor of the app that's failing isn't being very helpful. Is there any info we can give them on how to recompile the applet so that it works under the default setting?
    What are other large enterprises doing to manage this?
    Thanks in advance for any answers. Until we have this resolved, we're unable to upgrade users to the current JRE.

    I tried the java_version param. It prompted me with a warning informing me that the app would run an earlier version of Java. I clicked run, and continued having the same issue. I captured this from the console:
    Java Plug-in 1.6.0_20
    Using JRE version 1.5.0_15-b04 Java HotSpot(TM) Client VM
    User home directory = C:\Documents and Settings\kswans1.AMERICREDIT
    c: clear console window
    f: finalize objects on finalization queue
    g: garbage collect
    h: display this help message
    l: dump classloader list
    m: print memory usage
    o: trigger logging
    q: hide console
    r: reload policy configuration
    s: dump system and deployment properties
    t: dump thread list
    v: dump thread stack
    x: clear classloader cache
    0-5: set trace level to <n>
    java.lang.NoClassDefFoundError: sun/awt/DesktopBrowse
         at sun.plugin2.applet.Applet2Environment.initialize(Unknown Source)
         at sun.plugin2.main.client.PluginMain.handleMessageSetJVMID(Unknown Source)
         at sun.plugin2.main.client.PluginMain.mainLoop(Unknown Source)
         at sun.plugin2.main.client.PluginMain.run(Unknown Source)
         at sun.plugin2.main.client.PluginMain.main(Unknown Source)
    security: property package.access value sun.
    security: property package.access new value sun.,com.sun.javaws
    security: property package.access value sun.,com.sun.javaws
    security: property package.access new value sun.,com.sun.javaws,com.sun.deploy
    security: property package.access value sun.,com.sun.javaws,com.sun.deploy
    security: property package.access new value sun.,com.sun.javaws,com.sun.deploy,com.sun.jnlp
    security: property package.definition value null
    security: property package.definition new value com.sun.javaws
    security: property package.definition value com.sun.javaws
    security: property package.definition new value com.sun.javaws,com.sun.deploy
    security: property package.definition value com.sun.javaws,com.sun.deploy
    security: property package.definition new value com.sun.javaws,com.sun.deploy,com.sun.jnlp
    security: property package.access value sun.,com.sun.javaws,com.sun.deploy,com.sun.jnlp
    security: property package.access new value sun.,com.sun.javaws,com.sun.deploy,com.sun.jnlp,org.mozilla.jss
    security: property package.definition value com.sun.javaws,com.sun.deploy,com.sun.jnlp
    security: property package.definition new value com.sun.javaws,com.sun.deploy,com.sun.jnlp,org.mozilla.jss
    basic: setDeployURLClassPathCallbacks: no enhanced access
    basic: Added progress listener: sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@153f67e
    network: Cache entry found [url: http://drvmwebbnt02.americredit.com:9081/MyProvenir/MyProvenirZip.class, version: null] prevalidated=false/0
    network: Connecting http://drvmwebbnt02.americredit.com:9081/MyProvenir/MyProvenirZip.class with proxy=DIRECT
    network: Connecting http://drvmwebbnt02.americredit.com:9081/MyProvenir/MyProvenirZip.class with cookie "JSESSIONID=84C38F94C7BABF9B3318856D87B9736D; __utma=1.1067525869.1271360926.1278605523.1278684887.12; __utmz=1.1271360926.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)"
    network: ResponseCode for http://drvmwebbnt02.americredit.com:9081/MyProvenir/MyProvenirZip.class : 304
    network: Encoding for http://drvmwebbnt02.americredit.com:9081/MyProvenir/MyProvenirZip.class : null
    network: Disconnect connection to http://drvmwebbnt02.americredit.com:9081/MyProvenir/MyProvenirZip.class
    network: Cache entry not found [url: http://drvmwebbnt02.americredit.com:9081/MyProvenir/, version: null]
    basic: Applet loaded.
    basic: Applet resized and added to parent container
    basic: PERF: AppletExecutionRunnable - applet.init() BEGIN ; jvmLaunch dt 374612 us, pluginInit dt 666096 us, TotalTime: 1040708 us
    basic: Applet initialized
    basic: Removed progress listener: sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@153f67e
    basic: Applet made visible
    basic: Starting applet
    basic: completed perf rollup
    basic: Applet started
    basic: Told clients applet is started

  • Applet doesn´t load in java 7 with next-generation plug-in marked

    I have developed an applet with netbeans 7.1.2 which worked fine until I updated from jvm6 to jvm7. The applet does not load properly unless I uncheck from the configuration of the jvm the checbox plug-in next-generation.
    Anyone know why in java 6 working properly with the plug-in next generation and in java 7 do not?
    I can do something to work properly in Java 7 without having to uncheck the checkbox?
    Thanks.

    1 - Java installed -> 1.7.0_05-b06. In Firefox works fine. The problem is in IE8.
    2 - I can run other applets.
    3-
    security: property package.access value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.imageio.,com.sun.org.apache.xerces.internal.utils.,com.sun.org.apache.xalan.internal.utils.
    security: property package.access new value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.imageio.,com.sun.org.apache.xerces.internal.utils.,com.sun.org.apache.xalan.internal.utils.,com.sun.javaws
    security: property package.access value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.imageio.,com.sun.org.apache.xerces.internal.utils.,com.sun.org.apache.xalan.internal.utils.,com.sun.javaws
    security: property package.access new value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.imageio.,com.sun.org.apache.xerces.internal.utils.,com.sun.org.apache.xalan.internal.utils.,com.sun.javaws,com.sun.deploy
    security: property package.access value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.imageio.,com.sun.org.apache.xerces.internal.utils.,com.sun.org.apache.xalan.internal.utils.,com.sun.javaws,com.sun.deploy
    security: property package.access new value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.imageio.,com.sun.org.apache.xerces.internal.utils.,com.sun.org.apache.xalan.internal.utils.,com.sun.javaws,com.sun.deploy,com.sun.jnlp
    security: property package.definition value null
    security: property package.definition new value com.sun.javaws
    security: property package.definition value com.sun.javaws
    security: property package.definition new value com.sun.javaws,com.sun.deploy
    security: property package.definition value com.sun.javaws,com.sun.deploy
    security: property package.definition new value com.sun.javaws,com.sun.deploy,com.sun.jnlp
    security: property package.access value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.imageio.,com.sun.org.apache.xerces.internal.utils.,com.sun.org.apache.xalan.internal.utils.,com.sun.javaws,com.sun.deploy,com.sun.jnlp
    security: property package.access new value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.imageio.,com.sun.org.apache.xerces.internal.utils.,com.sun.org.apache.xalan.internal.utils.,com.sun.javaws,com.sun.deploy,com.sun.jnlp,org.mozilla.jss
    security: property package.definition value com.sun.javaws,com.sun.deploy,com.sun.jnlp
    security: property package.definition new value com.sun.javaws,com.sun.deploy,com.sun.jnlp,org.mozilla.jss
    basic: Listener de progreso agregado: sun.plugin.util.ProgressMonitorAdapter@bbe282
    basic: Plugin2ClassLoader.addURL parent called for .../appletFirma/lib/bcmail-jdk13-145.zip
    basic: Plugin2ClassLoader.addURL parent called for.../appletFirma/lib/jce-ext-jdk13-145.zip
    basic: Plugin2ClassLoader.addURL parent called for .../appletFirma/lib/AbsoluteLayout.jar
    basic: Plugin2ClassLoader.addURL parent called for .../appletFirma/lib/plugin.jar
    basic: Plugin2ClassLoader.addURL parent called for .../appletFirma/AppletAplication.jar
    security: Se ha activado la comprobación de revocación de la lista negra
    security: Está activada la comprobación de lista de bibliotecas de confianza
    network: Se ha encontrado la entrada de caché [URL: .../appletFirma/lib/bcmail-jdk13-145.zip, versión: null] prevalidated=false/0
    cache: Resource .../appletFirma/lib/bcmail-jdk13-145.zip has expired.
    network: Conectando.../appletFirma/lib/bcmail-jdk13-145.zip con proxy=DIRECT
    network: Conectando.../ con proxy=DIRECT
    network: Conectando .../appletFirma/lib/bcmail-jdk13-145.zip con cookie "__utma=153011745.179473224.1324411077.1324563223.1326992570.4; DomAuthSessId=07A8675D20F4CBAA6E2D638B5330E7A0"
    network: ResponseCode de.../appletFirma/lib/bcmail-jdk13-145.zip: 304
    network: Codificación de .../appletFirma/lib/bcmail-jdk13-145.zip: null
    network: Desconectar conexión con .../appletFirma/lib/bcmail-jdk13-145.zip
    cache: Reading Signers from 2157 .../appletFirma/lib/bcmail-jdk13-145.zip | C:\Documents and Settings\Francisco Alvarez\Configuración local\Datos de programa\Sun\Java\Deployment\cache\6.0\1\282adb01-384a1e15.idx
    cache: Done readSigners(.../appletFirma/lib/bcmail-jdk13-145.zip)
    cache: Read manifest for .../appletFirma/lib/bcmail-jdk13-145.zip: read=201 full=5808
    security: Cargando certificados de despliegue desde C:\Documents and Settings\Francisco Alvarez\Datos de programa\Sun\Java\Deployment\security\trusted.certs
    security: Se han cargado certificados de despliegue desde C:\Documents and Settings\Francisco Alvarez\Datos de programa\Sun\Java\Deployment\security\trusted.certs
    security: Cargando certificados del almacén de certificados de la sesión de despliegue
    security: Certificados cargados del almacén de certificados de la sesión de despliegue
    security: Cargando certificados del almacén de certificados TrustedPublisher de Internet Explorer
    security: Certificados cargados desde el almacén de certificados TrustedPublisher de Internet Explorer
    security: Validar la cadena de certificados utilizando la API CertPath
    security: Cargando certificados del almacén de certificados ROOT de Internet Explorer
    security: Certificados cargados desde el almacén de certificados ROOT de Internet Explorer
    security: Cargando certificados de CA raíz desde C:\Documents and Settings\Francisco Alvarez\Datos de programa\Sun\Java\Deployment\security\trusted.cacerts
    security: Certificados de CA raíz cargados desde C:\Documents and Settings\Francisco Alvarez\Datos de programa\Sun\Java\Deployment\security\trusted.cacerts
    security: Cargando certificados de CA raíz desde C:\Archivos de programa\Java\jre7\lib\security\cacerts
    security: Certificados de CA raíz cargados desde C:\Archivos de programa\Java\jre7\lib\security\cacerts
    security: Obtener recopilación de certificados del almacén de certificados de CA raíz
    security: Obtener recopilación de certificados del almacén de certificados de CA raíz
    security: Obtener recopilación de certificados del almacén de certificados de CA raíz
    security: Obtener recopilación de certificados del almacén de certificados de CA raíz
    security: El certificado no ha caducado. No es preciso comprobar la información sobre el registro de hora
    security: Se ha encontrado el archivo de lista de jurisdicciones
    security: No se necesita comprobar la extensión de confianza de este certificado
    security: El soporte de CRL está desactivado
    security: El soporte de OCSP está desactivado
    security: Esta validación de entidad final de OCSP está desactivada
    security: Comprobando si el certificado está en el almacén de certificados denegados de despliegue
    security: Comprobando si el certificado está en el almacén permanente de certificados de despliegue
    security: Comprobando si el certificado está en el almacén de certificados de la sesión de despliegue
    security: Comprobando si el certificado está en el almacén de certificados TrustedPublisher de Internet Explorer
    basic: Dialog type is not candidate for embedding
    security: El usuario ha otorgado privilegios de código sólo para esta sesión
    security: Agregando certificado en el almacén de certificados de la sesión de despliegue
    security: Certificados agregados en el almacén de certificados de la sesión de despliegue
    security: Guardando certificados en el almacén de certificados de la sesión de despliegue
    security: Certificados guardados en el almacén de certificados de la sesión de despliegue
    network: Se ha encontrado la entrada de caché [URL:.../appletFirma/lib/jce-ext-jdk13-145.zip, versión: null] prevalidated=false/0
    cache: Resource http://desarrollo.isaltda.com.uy/appletFirma/lib/jce-ext-jdk13-145.zip has expired.
    network: Conectando .../appletFirma/lib/jce-ext-jdk13-145.zip con proxy=DIRECT
    network: Conectando .../appletFirma/lib/jce-ext-jdk13-145.zip con cookie "__utma=153011745.179473224.1324411077.1324563223.1326992570.4; DomAuthSessId=07A8675D20F4CBAA6E2D638B5330E7A0"
    network: ResponseCode de .../appletFirma/lib/jce-ext-jdk13-145.zip: 304
    network: Codificación de .../appletFirma/lib/jce-ext-jdk13-145.zip: null
    network: Desconectar conexión con .../appletFirma/lib/jce-ext-jdk13-145.zip
    cache: Reading Signers from 2157 .../appletFirma/lib/jce-ext-jdk13-145.zip | C:\Documents and Settings\Francisco Alvarez\Configuración local\Datos de programa\Sun\Java\Deployment\cache\6.0\37\590df8a5-7d87e233.idx
    cache: Done readSigners(.../appletFirma/lib/jce-ext-jdk13-145.zip)
    cache: Read manifest for .../appletFirma/lib/jce-ext-jdk13-145.zip: read=202 full=47488
    security: Validar la cadena de certificados utilizando la API CertPath
    security: El certificado no ha caducado. No es preciso comprobar la información sobre el registro de hora
    security: Se ha encontrado el archivo de lista de jurisdicciones
    security: No se necesita comprobar la extensión de confianza de este certificado
    security: El soporte de CRL está desactivado
    security: El soporte de OCSP está desactivado
    security: Esta validación de entidad final de OCSP está desactivada
    security: Comprobando si el certificado está en el almacén de certificados denegados de despliegue
    security: Comprobando si el certificado está en el almacén permanente de certificados de despliegue
    security: Comprobando si el certificado está en el almacén de certificados de la sesión de despliegue
    network: Se ha encontrado la entrada de caché [URL: .../appletFirma/lib/AbsoluteLayout.jar, versión: null] prevalidated=false/0
    cache: Resource .../appletFirma/lib/AbsoluteLayout.jar has expired.
    network: Conectando.../appletFirma/lib/AbsoluteLayout.jar con proxy=DIRECT
    network: Conectando .../appletFirma/lib/AbsoluteLayout.jar con cookie "__utma=153011745.179473224.1324411077.1324563223.1326992570.4; DomAuthSessId=07A8675D20F4CBAA6E2D638B5330E7A0"
    network: ResponseCode de.../appletFirma/lib/AbsoluteLayout.jar: 304
    network: Codificación de.../appletFirma/lib/AbsoluteLayout.jar: null
    network: Desconectar conexión con .../appletFirma/lib/AbsoluteLayout.jar
    cache: Reading Signers from 1055 .../appletFirma/lib/AbsoluteLayout.jar | C:\Documents and Settings\Francisco Alvarez\Configuración local\Datos de programa\Sun\Java\Deployment\cache\6.0\17\56fa4991-262eae08.idx
    cache: Done readSigners(.../appletFirma/lib/AbsoluteLayout.jar)
    cache: Read manifest for.../appletFirma/lib/AbsoluteLayout.jar: read=283 full=283
    security: Validar la cadena de certificados utilizando la API CertPath
    security: El certificado no ha caducado. No es preciso comprobar la información sobre el registro de hora
    security: Se ha encontrado el archivo de lista de jurisdicciones
    security: No se necesita comprobar la extensión de confianza de este certificado
    security: El soporte de CRL está desactivado
    security: El soporte de OCSP está desactivado
    security: Esta validación de entidad final de OCSP está desactivada
    security: Comprobando si el certificado está en el almacén de certificados denegados de despliegue
    security: Comprobando si el certificado está en el almacén permanente de certificados de despliegue
    security: Comprobando si el certificado está en el almacén de certificados de la sesión de despliegue
    security: Comprobando si el certificado está en el almacén de certificados TrustedPublisher de Internet Explorer
    basic: Dialog type is not candidate for embedding
    security: El usuario ha otorgado privilegios de código sólo para esta sesión
    security: Agregando certificado en el almacén de certificados de la sesión de despliegue
    security: Certificados agregados en el almacén de certificados de la sesión de despliegue
    security: Guardando certificados en el almacén de certificados de la sesión de despliegue
    security: Certificados guardados en el almacén de certificados de la sesión de despliegue
    network: Se ha encontrado la entrada de caché [URL:.../appletFirma/lib/plugin.jar, versión: null] prevalidated=false/0
    cache: Resource .../appletFirma/lib/plugin.jar has expired.
    network: Conectando .../appletFirma/lib/plugin.jar con proxy=DIRECT
    network: Conectando.../appletFirma/lib/plugin.jar con cookie "__utma=153011745.179473224.1324411077.1324563223.1326992570.4; DomAuthSessId=07A8675D20F4CBAA6E2D638B5330E7A0"
    network: ResponseCode de.../appletFirma/lib/plugin.jar: 304
    network: Codificación de .../appletFirma/lib/plugin.jar: null
    network: Desconectar conexión con .../appletFirma/lib/plugin.jar
    cache: Reading Signers from 5 .../appletFirma/lib/plugin.jar | C:\Documents and Settings\Francisco Alvarez\Configuración local\Datos de programa\Sun\Java\Deployment\cache\6.0\15\c16d34f-2740f800.idx
    network: No hay información de certificado para el archivo JAR sin firma: .../appletFirma/lib/plugin.jar
    cache: Done readSigners(.../appletFirma/lib/plugin.jar)
    cache: Read manifest for .../appletFirma/lib/plugin.jar: read=89 full=89
    network: Se ha encontrado la entrada de caché [URL: .../appletFirma/AppletAplication.jar, versión: null] prevalidated=false/0
    cache: Resource .../appletFirma/AppletAplication.jar has expired.
    network: Conectando .../appletFirma/AppletAplication.jar con proxy=DIRECT
    network: Conectando .../appletFirma/AppletAplication.jar con cookie "__utma=153011745.179473224.1324411077.1324563223.1326992570.4; DomAuthSessId=07A8675D20F4CBAA6E2D638B5330E7A0"
    network: ResponseCode de .../appletFirma/AppletAplication.jar: 304
    network: Codificación de .../appletFirma/AppletAplication.jar: null
    network: Desconectar conexión con .../appletFirma/AppletAplication.jar
    cache: Reading Signers from 1055 .../appletFirma/AppletAplication.jar | C:\Documents and Settings\Francisco Alvarez\Configuración local\Datos de programa\Sun\Java\Deployment\cache\6.0\51\609786b3-797751c9.idx
    cache: Done readSigners(.../appletFirma/AppletAplication.jar)
    cache: Read manifest for .../appletFirma/AppletAplication.jar: read=242 full=1552
    security: Validar la cadena de certificados utilizando la API CertPath
    security: El certificado no ha caducado. No es preciso comprobar la información sobre el registro de hora
    security: Se ha encontrado el archivo de lista de jurisdicciones
    security: No se necesita comprobar la extensión de confianza de este certificado
    security: El soporte de CRL está desactivado
    security: El soporte de OCSP está desactivado
    security: Esta validación de entidad final de OCSP está desactivada
    security: Comprobando si el certificado está en el almacén de certificados denegados de despliegue
    security: Comprobando si el certificado está en el almacén permanente de certificados de despliegue
    security: Comprobando si el certificado está en el almacén de certificados de la sesión de despliegue
    security: Validar la cadena de certificados utilizando la API CertPath
    security: El certificado no ha caducado. No es preciso comprobar la información sobre el registro de hora
    security: Se ha encontrado el archivo de lista de jurisdicciones
    security: No se necesita comprobar la extensión de confianza de este certificado
    security: El soporte de CRL está desactivado
    security: El soporte de OCSP está desactivado
    security: Esta validación de entidad final de OCSP está desactivada
    security: Comprobando si el certificado está en el almacén de certificados denegados de despliegue
    security: Comprobando si el certificado está en el almacén permanente de certificados de despliegue
    security: Comprobando si el certificado está en el almacén de certificados de la sesión de despliegue
    basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
    security: Validar la cadena de certificados utilizando la API CertPath
    security: El certificado no ha caducado. No es preciso comprobar la información sobre el registro de hora
    security: Se ha encontrado el archivo de lista de jurisdicciones
    security: No se necesita comprobar la extensión de confianza de este certificado
    security: El soporte de CRL está desactivado
    security: El soporte de OCSP está desactivado
    security: Esta validación de entidad final de OCSP está desactivada
    security: Comprobando si el certificado está en el almacén de certificados denegados de despliegue
    security: Comprobando si el certificado está en el almacén permanente de certificados de despliegue
    security: Comprobando si el certificado está en el almacén de certificados de la sesión de despliegue
    basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
    security: Validar la cadena de certificados utilizando la API CertPath
    security: El certificado no ha caducado. No es preciso comprobar la información sobre el registro de hora
    security: Se ha encontrado el archivo de lista de jurisdicciones
    security: No se necesita comprobar la extensión de confianza de este certificado
    security: El soporte de CRL está desactivado
    security: El soporte de OCSP está desactivado
    security: Esta validación de entidad final de OCSP está desactivada
    security: Comprobando si el certificado está en el almacén de certificados denegados de despliegue
    security: Comprobando si el certificado está en el almacén permanente de certificados de despliegue
    security: Comprobando si el certificado está en el almacén de certificados de la sesión de despliegue
    basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
    security: Validar la cadena de certificados utilizando la API CertPath
    security: El certificado no ha caducado. No es preciso comprobar la información sobre el registro de hora
    security: Se ha encontrado el archivo de lista de jurisdicciones
    security: No se necesita comprobar la extensión de confianza de este certificado
    security: El soporte de CRL está desactivado
    security: El soporte de OCSP está desactivado
    security: Esta validación de entidad final de OCSP está desactivada
    security: Comprobando si el certificado está en el almacén de certificados denegados de despliegue
    security: Comprobando si el certificado está en el almacén permanente de certificados de despliegue
    security: Comprobando si el certificado está en el almacén de certificados de la sesión de despliegue
    basic: Applet cargado.
    basic: Applet resized and added to parent container
    basic: PERF: AppletExecutionRunnable - applet.init() BEGIN ; jvmLaunch dt 305312 us, pluginInit dt 6347309 us, TotalTime: 6652621 us
    security: Validar la cadena de certificados utilizando la API CertPath
    security: El certificado no ha caducado. No es preciso comprobar la información sobre el registro de hora
    security: Se ha encontrado el archivo de lista de jurisdicciones
    security: No se necesita comprobar la extensión de confianza de este certificado
    security: El soporte de CRL está desactivado
    security: El soporte de OCSP está desactivado
    security: Esta validación de entidad final de OCSP está desactivada
    security: Comprobando si el certificado está en el almacén de certificados denegados de despliegue
    security: Comprobando si el certificado está en el almacén permanente de certificados de despliegue
    security: Comprobando si el certificado está en el almacén de certificados de la sesión de despliegue
    basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
    basic: Applet initialized
    basic: Starting applet
    basic: completed perf rollup
    basic: Applet made visible
    basic: Applet started
    basic: Told clients applet is started
    basic: Starting applet teardown
    basic: Finished applet teardown
    basic: Listener de progreso eliminado: sun.plugin.util.ProgressMonitorAdapter@bbe282
    plugin2manager.parentwindowDispose

  • Need to disable next-generation Java plug-in for sccm deployment

    hey all,
    hope I have the right forum for this question.
    I'm deploying Java 7 update 55 to users in our company and have discovered that we need to disable the next generation plug-in.
    is there a way to deploy Java with the plug-in disabled?  preferably a command that I can add to a batch file.
    I've read about a registry hack (doesn't work based on feedback), but I'd prefer not to deploy a mass registry change company-wide.
    any help would be greatly appreciated.
    thanks for your time!

    I'm deploying Java 7 update 55 to users in our company and have discovered that we need to disable the next generation plug-in.
    is there a way to deploy Java with the plug-in disabled?  preferably a command that I can add to a batch file.
    I've read about a registry hack (doesn't work based on feedback), but I'd prefer not to deploy a mass registry change company-wide.
    any help would be greatly appreciated.
    Have you created the required deployment rule set?
    https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+orana+(OraNA)
    This Symantec blog has several posts by JRE team members (they have 'Oracle' in their user id) about the issue and the above link is referenced from it:
    http://www.symantec.com/connect/forums/how-everyone-addressing-forced-java-dialog-java-update-needed-your-java-version-insecure
    This Symantec link discusses 'Updating Java through Managed Sjoftware Delivery Policy
    http://www.symantec.com/connect/articles/updating-java-through-managed-software-delivery-policy

  • Next Generation Java Plug-in

    Hi -
    Our desktop application was built using older versions of core java and now runs on 1.6.0_19. When the next generation java plug-in came into play (enabled by default) we started having some GUI issues with various dialog boxes (freezing, not functioning properly, etc). These could probably have been written better whenever they were. We can individually go back and fix all of these but don't have the time to do it now. So we decided to uncheck the plug-in for now. When I do this locally on my pc, everything works fine. However, our application is available on citrix servers and when I disabled the plug-in there, I'm getting "Java Heap Space" exceptions. I definitely know there is sufficient memory on the box and the JRE settings are fine as well. Any idea why disabling the plug-in would cause java to run out of memory? I have been really confused by this and any insight would be greatly appreciated.

    anyone?

  • The next-generation Java Plug-in

    I really need to disable the next-generation Java Plug-in on the Advanced tab of the Java control Panel, but it is grayed out.  I have admin rights. I tried to uninstall/install Java, but that did not work.  Any suggestions?  Thank you

    Hello jpalan!
    Last case, you can make a PKGBUILD for on older version on your local pc, according to a working PKGBUILD.

  • How to disable Next Generation Java Plug-in for GPO software deployments?

    Is there a way to disable the Next Generation Java Plug-in using a script or batch file for GPO software deployments?
    Our group needs to deploy JRE 6 Update 20 to a large number of Oracle Financials users. As part of this deployment, we need to disable the Next Generation Java Plug-in as part of the installation for each desktop. Our plan is to extract the MSI installer package from Sun and create a GPO for software deployment.
    It seems you cannot disable the Next Generation Java Plug-in using a simple registry hack or customized MST transform file. Is there another method for disabling Next Generation Java Plug-in?

    btenney,
    Thanks very much for your suggestion. Can you explain what the parameters are on the ssvagent.exe that you noted -high -jpisetup -old? I can't seem to find any information on the parameters. Also, will this set the configuration just for the user logged on (current user) OR for all users existing and future?
    We are having trouble getting next-gen java shut off for all possible users that may logon to a machine in future .. thus looking at putting in bootup login script, but hoping there is a better way to have it take affect at the machine level. Or to at least automate at the user level (existing and future windows users/profiles)

  • How to reload proxy configuration with Next Generation Java Plug-in

    When using the Next Generation Java Plug-in, I no longer see an option in the console to reload the proxy from the browser by pressing p. If the proxy information is changed in the browser after the Java console loads, is there a way to reload the proxy from the browser? If not, why was it removed?
    It's been useful to us because of the way we test with LoadRunner, which uses a proxy. Our other options are to either disable the Next Generation Java Plug-in so the option comes back, or set the proxy in the Java settings instead of trying to read from the browser, but I'm trying to find out it's one of those will be necessary.
    We're using Java 1.6.0_17. Thanks!

    btenney,
    Thanks very much for your suggestion. Can you explain what the parameters are on the ssvagent.exe that you noted -high -jpisetup -old? I can't seem to find any information on the parameters. Also, will this set the configuration just for the user logged on (current user) OR for all users existing and future?
    We are having trouble getting next-gen java shut off for all possible users that may logon to a machine in future .. thus looking at putting in bootup login script, but hoping there is a better way to have it take affect at the machine level. Or to at least automate at the user level (existing and future windows users/profiles)

  • Java 8, next-generation java plug-in?

    hey all,
    i'm looking for the "enable the next-generation java plug-in" option in java 8 update 40, but can't find it in the advanced tab of the java control panel.
    has it been removed?
    thanks!

    anyone?

  • Java options: "Enable the next-generation Java Plug-in"

    On windows, this option is sometimes "grayed out" and you cannot disable it.
    This option is available since java 6 u 10, and is accessible via windows control panel, or alternatively via javacpl.exe.
    Which are the cases where the option is grayed out?
    I've made the assumption that it is grayed out on windows 7, or on windows 7 64, but there are cases of windows 7 64 where the option isn't grayed out.
    It seem neither connected with Internet Explorer version, since it works or not with either IE 8 or IE 9.
    Edited by: Agostino on 18-gen-2012 2.58

    Current Firefox versions (3.6 and later) can only run Java applets via the Next Generation plugin.
    *http://java.com/en/download/help/new_plugin.xml

  • Disable next-generation Java Plug-in-Is Applets load on same JVM guranteed?

    Dear all,
    I am working on a banking application that uses WinXP and JRE1.5, where the banking application is browser based and with a lot of applets. For inter-applet communcation, we use singleton, a Object called CommonFunctionUtility, which is a single instance so that all applets can share information.
    Recently, there is a direction to upgrade the JRE to 1.7. However, after upgrade, we find that applets are loaded to different JVMs so that they're not referring to the same instance of this CommonFunctionUtility, so applet hangs as they cannot retrieve correct information.
    As an interim solution to meet internal requirement to complete JRE1.7 rollout, it is suggested to disable the next-generation java plugin first, and amend the application later using other way to share data later. In view to this, may anyone have any idea that Oracle ever confirm that after disabling next-generation java plugin, it is guranteed that all applets in same browser will be loaded on same JVM?
    Regards,
    Francis

    By disabling the next generation plugin it should "work as before". That's about as much guarantee as you'll get, the business of providing guarantees lies on your shoulders (without an Oracle service agreement) through system integration tests.

  • Next Generation in Monitor or PDA screens...

    OK, so I'm sitting here on my iMac, and reading this, and reading that, we do a lot more reading then we used too, and we read more on electronic screens, then plain old school paper and print.  SO the financial pundents hammer apple constantly for not bringing the truly next great WOW FACTOR, to the masses.  I tend to think, Apple itself is having identifying the next wow factor in itself, there in case, the problem.   Heck, I have been struggling with, "What would be really great, next" kind of thought, ???????  but sitting here at my MAC it slapped me square in the face.   I know the technical developers have been into this kind of technology for quite some time over the past years, and, considering the vacuum in the NEXT GREAT THING category, and not just Trumped up progressions of ALREADY GREAT THINGS, Apple needs to WOW the world once again.  And here is what Apple has to do......
    We are going to be reading on our screens for generations into the future, The Print can not appear "under the glass"  The print must appear "on the surface"  Presently, Static on the screens attacks dust, which causes the eye to focus shift, dust to text, dust to text, text to dust.  When the eye goes finite and precise, it can detect these minute differences and shift.  When you choose just to focus on the text, you still know the dust is still there.   (Yeah, just clean your screen is not going to cut it anymore, and the foolish company will loose if they do not seize this need the consumers will demand.)  So, the NEXT great thing is Print, Text, and Color, on the surface of the screen, and one other thing will need to be coupled with this, actually two, sorry.   Back lighting this new screen will have to be thought of as the way it was, Backlighting will only be needed in low light and night conditions, Daylight operation will have its light source external, from the sun, from interior lighting.   Again, if backlighting is not thrown out with the bath water, then we will have back lighting available to us in low light conditions.
    Apple started from Steve Jobs love of the finite and beautiful, Calligraphy.
    Those who perfect the next generation screens on their products right now, will carry the day and alligence of the most consumers.
    S.M.  ~you need me~  

    Hi,
    I was wrong in my approach.
    My applet was implemented using the "<object>" tag and it seems that it was not the best way to address compatibility issues across all versions of the plug-in and all browsers.
    So, I have finally found what I was looking for in this "[Java Rich Internet Applications Development and Deployment|http://download.oracle.com/javase/6/docs/technotes/guides/jweb/index.html]" guide. In this guide, it is recommended to use the "[Deployment Toolkit|http://download.oracle.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html#deplToolkit]", based on a Javascript library containing everything needed to deploy your application as an applet or a Java Web Start application.
    My application, deployed as an applet, now works like a charm.
    I hope pointing on this Deployment Toolkit will also help others...
    Philippe

  • Next-Generation Java 7 Plugin Performance on Windows 7 and IE 8

    Applet performance has historically been a black eye, to say the least, for Java Applets. Slow load times over today's networks are simply not tolerated by today's network standards. I'm currently supporting an Applet that is forced to move to the Java 7 Platform. As such, we are particularly sensitive to anything new that may further hinder applet performance. To that end, I've been doing quite a bit of benchmarking lately of Applet load times using various configurations with the Java 7 Plugin on Windows 7 using IE 8.
    To capture Java Applet load times, I've simply been marking the start time in Javascript from the HTML onLoad() event, and then calling out to a similar Javascript function to mark the end time from the bottom of the init() method in the Java Applet. I subtract the two times to get a general idea of how long it takes to load the applet.
    The best load times, so far, (when loading the JARs from the web server) occur when caching is employed (e.g., cache_option, cache_archive, cache_version). What I've noticed though, is that when everything else is the same, the performance is degraded by at least half when I check the 'Enable the next-generation Java Plug-in' in the Plugin Control Panel. Applet load times slow down by at least half when this option is enabled. When loading JAR files from the web server, with caching in effect, the applet load time performance is comparable to loading JAR files from the file system only when the next-generation plugin is not enabled. I assume this is because of the associated overhead of spinning-up this external JVM process, but I'm not certain.
    Does anyone know if this is a correct assumption? And if I'm correct, are there ways to speed up the loading of an applet when caching is used with the next-generation plugin? Is this another cold-start vs. warm-start issue for the JVM?
    My goal is to have applet load times for JARs loaded from the web server, using the next-generation plugin, as fast as when the JARs could be loaded from the local file system (which apparently is no longer possible using the next-generation plugin, sadly).
    Thanks!

    Thanks Igor.
    Web Browser: IE 8.0.76
    Java Plugin: 7u3 (1.7.0_03-b05)
    OS: Windows 7 Enterprise (32-bit)
    Server: Websphere 7
    Java Applet is in O&M phase and been around a while. Rich Internet Application with file system access requirements. Currently compiled with JDK 1.5. 10 JAR files total, 6 of which are third-party JARs. 4 JARs are custom and are signed.
    JAR1.jar -> 11077 bytes
    JAR2.jar -> 14207 bytes
    JAR3.jar -> 5093 bytes
    JAR4.jar -> 22233 bytes
    JAR5.jar -> 18722 bytes
    JAR6.jar -> 17578 bytes
    JAR7.jar -> 722237 bytes
    JAR8.jar -> 90688 bytes
    JAR9.jar -> 17521 bytes
    JAR10.jar -> 50686 bytes
    JSP Page is used to render the following HTML tags for loading the applet:
    <object classid="clsid:${UID}" name="preview" width="100%" height="300" id="poc">
    <PARAM name="java_code" value="com.loadfast.Applet.class"/>
    <param name="codebase" value="/www/applet"/>
    <PARAM name="cache_option" value="Plugin"/>
    <PARAM NAME="cache_archive" VALUE="
    JAR1.jar,
                        JAR2.jar,
                        JAR3.jar,
                        JAR4.jar,
                        JAR5.jar,
                        JAR6.jar,
                        JAR7.jar,
                        JAR8.jar,
                        JAR9.jar,
                        JAR10.jar
    "/>
    <PARAM NAME="cache_version" VALUE="
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11"/>
    <PARAM name="type" value="application/x-java-applet"/>
    </object>
    Here's a brief synopsis of my test methodology:
    Assuming caching is the fastest performance I'm going to get by putting JARs on web server, goal was to determine if browser plugin and next-gen plugin will offer the same performance in terms of time to load the Applet.
    To test, I unchecked the 'Enable Next-Gen' plugin option in the Java Plugin. I updated the cache_version values for all JARs. I 'touched' all JAR files in the WAR (I use cygwin) and redeployed the WAR. I have a cli script that launches IE and points it at my applet. When the applet loads, a Javascript Alert box displays showing the number of milliseconds it took to load the applet. I document the time, quit the browser, and re-execute my script. I do this 10 times for each test scenario and take the average.
    The two basic test scenarios are using the Browser Plugin (not next-gen) and using the Next-Gen Plugin. That is the only variable I change between test scenarios. Here is the raw data I collected for each test scenario:
    Not Using Next-Gen Plugin (milliseconds):
    run1 run2 run3 run4 run5 run6 run7 run8 run9 run10
    1761 474 535 495 500 505 502 267 693 513
    Avg: 625ms
    Using Next-Generation Plugin (milliseconds):
    run1 run2 run3 run4 run5 run6 run7 run8 run9 run10
    5382 1529 983 1545 1622 1575 1544 1544 1545 1529
    Avg: 1880ms
    The time it takes to load for each first run indicates caching is happening as subsequent runs are faster. I verified that the JVM is not making http requests for cached JAR files by proxying these requests with Tcpmon just to confirm this was the case.
    I'm basically just looking for a logical explanation to account for the significant time difference that occurs from this Plugin configuration change. It seems to make logical sense to me that this can be explained by JVM Process start up time, but I'm looking for corroboration on that or another explanation.
    Thanks for any advice, help, etc. I'll start looking into JNLP and JAR index as well.

Maybe you are looking for