Possible BUG in Mixed Code Security Warning?

Discussion in 'Java' started by FutureScalper, Jul 2, 2010.

  1. I conclude after much working with this issue that the Security
    Warning is somehow erroneously triggered, even though it is explicitly
    disabled.

    I believe this is a BUG but someone can enlighten me, please? Note
    easily reproducible because things work for perhaps several hours
    before problems occur. This app needs to run unattended 24 x 7.

    If I can't get rid of this, I'll have to back down to Java 6 Update 17
    and stay there until it's resolved.

    I can run for hours, and then suddenly I get the Security Warning for
    mixed code. Everything is signed, and the system is configured as
    follows, with Web Start as the deployer.

    The app does not contain any custom classloaders, nor do anything
    except just run standalone.

    In Windows/Sun/Java/Deployment (which is definitely being used)

    deploiyment.config contains:
    deployment.system.config=file:/C:/windows/Sun/Java/Deployment/
    deployment.properties
    deployment.system.config.mandatory=true

    deployment.properties contains:
    deployment.security.mixcode=DISABLE

    C:\Windows\SysWOW64>java -server -version
    java version "1.6.0_20"
    Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
    Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)

    The following exception is false. Signer information is the same in
    all packages, as far as I know. (I signed everything and control the
    deployment.)

    Exception in thread "AWT-EventQueue-0" java.lang.SecurityException:
    class "com.twc.trader.SupportResistanceDialog$1"'s signer information
    does not match signer information of other classes in the same package
    at java.lang.ClassLoader.checkCerts(Unknown Source)
    at java.lang.ClassLoader.preDefineClass(Unknown Source)
    at java.lang.ClassLoader.defineClassCond(Unknown Source)
    at java.lang.ClassLoader.defineClass(Unknown Source)
    at java.security.SecureClassLoader.defineClass(Unknown Source)
    at java.net.URLClassLoader.defineClass(Unknown Source)
    at java.net.URLClassLoader.access$000(Unknown Source)
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(Unknown Source)
    at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at com.twc.trader.SupportResistanceDialog.<init>(Unknown Source)
    at com.twc.trader.Core.getSupportResistanceDialog(Unknown Source)
    at com.twc.trader.TickAnalyzer.update(Unknown Source)
    at com.twc.trader.PriceMicroDetailWindow.notifyObservers(Unknown
    Source)
    at com.twc.trader.PriceMicroDetailWindow$1.chartMouseClicked(Unknown
    Source)
    at org.jfree.chart.ChartPanel.mouseClicked(Unknown Source)
    at java.awt.Component.processMouseEvent(Unknown Source)
    at javax.swing.JComponent.processMouseEvent(Unknown Source)
    at java.awt.Component.processEvent(Unknown Source)
    at java.awt.Container.processEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
    at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
    at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Window.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
    Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
    Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)
     
    FutureScalper, Jul 2, 2010
    #1
    1. Advertising

  2. On Jul 2, 3:05 pm, FutureScalper <> wrote:
    > I conclude after much working with this issue that the Security
    > Warning is somehow erroneously triggered, even though it is explicitly
    > disabled.
    >
    > I believe this is a BUG but someone can enlighten me, please?  Note
    > easily reproducible because things work for perhaps several hours
    > before problems occur.  This app needs to run unattended 24 x 7.
    >
    > If I can't get rid of this, I'll have to back down to Java 6 Update 17
    > and stay there until it's resolved.
    >
    > I can run for hours, and then suddenly I get the Security Warning for
    > mixed code.  Everything is signed, and the system is configured as
    > follows, with Web Start as the deployer.
    >
    > The app does not contain any custom classloaders, nor do anything
    > except just run standalone.
    >
    > In Windows/Sun/Java/Deployment (which is definitely being used)
    >
    > deploiyment.config contains:
    > deployment.system.config=file:/C:/windows/Sun/Java/Deployment/
    > deployment.properties
    > deployment.system.config.mandatory=true
    >
    > deployment.properties contains:
    > deployment.security.mixcode=DISABLE
    >
    > C:\Windows\SysWOW64>java -server -version
    > java version "1.6.0_20"
    > Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
    > Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)
    >
    > The following exception is false.  Signer information is the same in
    > all packages, as far as I know.  (I signed everything and control the
    > deployment.)
    >
    > Exception in thread "AWT-EventQueue-0" java.lang.SecurityException:
    > class "com.twc.trader.SupportResistanceDialog$1"'s signer information
    > does not match signer information of other classes in the same package
    >         at java.lang.ClassLoader.checkCerts(Unknown Source)
    >         at java.lang.ClassLoader.preDefineClass(Unknown Source)
    >         at java.lang.ClassLoader.defineClassCond(Unknown Source)
    >         at java.lang.ClassLoader.defineClass(Unknown Source)
    >         at java.security.SecureClassLoader.defineClass(Unknown Source)
    >         at java.net.URLClassLoader.defineClass(Unknown Source)
    >         at java.net.URLClassLoader.access$000(Unknown Source)
    >         at java.net.URLClassLoader$1.run(Unknown Source)
    >         at java.security.AccessController.doPrivileged(Native Method)
    >         at java.net.URLClassLoader.findClass(Unknown Source)
    >         at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
    >         at java.lang.ClassLoader.loadClass(Unknown Source)
    >         at java.lang.ClassLoader.loadClass(Unknown Source)
    >         at com.twc.trader.SupportResistanceDialog.<init>(Unknown Source)
    >         at com.twc.trader.Core.getSupportResistanceDialog(Unknown Source)
    >         at com.twc.trader.TickAnalyzer.update(Unknown Source)
    >         at com.twc.trader.PriceMicroDetailWindow.notifyObservers(Unknown
    > Source)
    >         at com.twc.trader.PriceMicroDetailWindow$1.chartMouseClicked(Unknown
    > Source)
    >         at org.jfree.chart.ChartPanel.mouseClicked(Unknown Source)
    >         at java.awt.Component.processMouseEvent(Unknown Source)
    >         at javax.swing.JComponent.processMouseEvent(Unknown Source)
    >         at java.awt.Component.processEvent(Unknown Source)
    >         at java.awt.Container.processEvent(Unknown Source)
    >         at java.awt.Component.dispatchEventImpl(Unknown Source)
    >         at java.awt.Container.dispatchEventImpl(Unknown Source)
    >         at java.awt.Component.dispatchEvent(Unknown Source)
    >         at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
    >         at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
    >         at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
    >         at java.awt.Container.dispatchEventImpl(Unknown Source)
    >         at java.awt.Window.dispatchEventImpl(Unknown Source)
    >         at java.awt.Component.dispatchEvent(Unknown Source)
    >         at java.awt.EventQueue.dispatchEvent(Unknown Source)
    >         at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
    > Source)
    >         at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    >         at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
    > Source)
    >         at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    >         at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    >         at java.awt.EventDispatchThread.run(Unknown Source)


    OK, I see a couple of typos in my post, but I can assure you that
    deployment.config is correct, is being used, and deployment.properties
    is mandatory, and my understanding is that the property will DISABLE
    Security Warning checking.

    But, several instances of my app fail at different random points,
    after many hours of running, and there appears to be no pattern except
    that the Security Warning behavior reappears for no apparent reason
    when the GUI tries some action. Apparently random.
     
    FutureScalper, Jul 2, 2010
    #2
    1. Advertising

  3. FutureScalper

    Eric Sosman Guest

    On 7/2/2010 3:05 PM, FutureScalper wrote:
    >[...]
    > I believe this is a BUG but someone can enlighten me, please? Note
    > easily reproducible because things work for perhaps several hours
    > before problems occur. This app needs to run unattended 24 x 7.
    >[...]
    > I can run for hours, and then suddenly I get the Security Warning for
    > mixed code. Everything is signed, and the system is configured as
    > follows, with Web Start as the deployer.
    >
    > The app does not contain any custom classloaders, nor do anything
    > except just run standalone.


    This seems odd. You say it runs "standalone" and "unattended,"
    yet the exception occurs on thread AWT-EventQueue-0, which suggests
    that there's a GUI somewhere. The stack trace seems to show that a
    mouse click is being processed by Swing components -- if the app is
    standalone and unattended, who's clicking mouse buttons?

    Also, the app doesn't merely "run for hours" and suddenly hit
    trouble while doing the same things it's been doing all along. The
    JVM is trying to load the com.twc.trader.SupportResistanceDialog$1
    class, which it wouldn't be doing if it had been using that class
    "for hours" and had thus loaded it earlier; this is the first time
    com.twc.trader.SupportResistanceDialog$1 has been called for. (It's
    possible for a class to be loaded, discarded, and re-loaded, but
    since you say you're doing no ClassLoader trickery that seems fairly
    unlikely.) I think you should focus your attention on the signing of
    this seldom-used nested class, and see if that turns up anything of
    interest. At the very least, knowing the particular class that's
    involved may help you reproduce the problem with less waiting around.

    I don't know whether it makes a difference, but the troublesome
    class is being loaded from the network, not from a local source. Maybe
    you've got a mismatched mixture of old, cached classes with fresh
    somewhere-over-the-network classes? It might be helpful to turn on the
    JVM's trace of class-loading activity, and see if anything's weird.

    Good luck!

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jul 2, 2010
    #3
  4. On Jul 2, 3:42 pm, Eric Sosman <> wrote:
    > On 7/2/2010 3:05 PM, FutureScalper wrote:
    >
    > >[...]
    > > I believe this is a BUG but someone can enlighten me, please?  Note
    > > easily reproducible because things work for perhaps several hours
    > > before problems occur.  This app needs to run unattended 24 x 7.
    > >[...]
    > > I can run for hours, and then suddenly I get the Security Warning for
    > > mixed code.  Everything is signed, and the system is configured as
    > > follows, with Web Start as the deployer.

    >
    > > The app does not contain any custom classloaders, nor do anything
    > > except just run standalone.

    >
    >      This seems odd.  You say it runs "standalone" and "unattended,"
    > yet the exception occurs on thread AWT-EventQueue-0, which suggests
    > that there's a GUI somewhere.  The stack trace seems to show that a
    > mouse click is being processed by Swing components -- if the app is
    > standalone and unattended, who's clicking mouse buttons?
    >
    >      Also, the app doesn't merely "run for hours" and suddenly hit
    > trouble while doing the same things it's been doing all along.  The
    > JVM is trying to load the com.twc.trader.SupportResistanceDialog$1
    > class, which it wouldn't be doing if it had been using that class
    > "for hours" and had thus loaded it earlier; this is the first time
    > com.twc.trader.SupportResistanceDialog$1 has been called for.  (It's
    > possible for a class to be loaded, discarded, and re-loaded, but
    > since you say you're doing no ClassLoader trickery that seems fairly
    > unlikely.)  I think you should focus your attention on the signing of
    > this seldom-used nested class, and see if that turns up anything of
    > interest.  At the very least, knowing the particular class that's
    > involved may help you reproduce the problem with less waiting around.
    >
    >      I don't know whether it makes a difference, but the troublesome
    > class is being loaded from the network, not from a local source.  Maybe
    > you've got a mismatched mixture of old, cached classes with fresh
    > somewhere-over-the-network classes?  It might be helpful to turn on the
    > JVM's trace of class-loading activity, and see if anything's weird.
    >
    >      Good luck!
    >
    > --
    > Eric Sosman
    >


    Okay, thanks for your response. Take it easy, yes it's a GUI driven
    application but it does run unattended usually overnight, and runs
    24x7 whether operator is present or not. Now, I admit I've only seen
    the problem when clicking a button, or when an action listener wants
    to do something, like put up that dialog. That's true.

    Perhaps I don't understand the concept of "signing". I sign the jars,
    and is that not sufficient? There are plenty of times the app pulls
    up this particular dialog just fine. And other times it does not.
    This inconsistency is the issue here. Also, I've seen the Security
    Warning on other action listeners as well. Since the problem is
    intermittent and difficult to reproduce, I can't say whether the
    particular function was used in the past or not.

    I am not aware of any network-loaded classes, and that's a great
    suggestion. The application does do RMI amongst copies of itself but
    I don't believe that's the problem. The intent is that it can run
    standalone, without an internet connection, on an isolated machine as
    well as during live online trading, of course.

    I will see whether for some weird reason attempts are being made to
    load classes over the network. I'll investigate how you came to this
    conclusion and maybe there is something weird going on here...

    Here's the jnlp used to run the thing, which resides on a webserver,
    and it uses 5 locally cached jars, plus the installed JRE of course,
    which is not the Client VM, but the Sun Java Server VM for high
    performance.

    Is there something in this jnlp which would trigger class loading over
    the network? That's a subtlety I hadn't thought of....

    <?xml version="1.0" encoding="UTF-8" ?>
    <jnlp spec="1.0+" codebase="http://FutureScalper.com/[location
    removed]/serverbeta_ta" href="FutureScalperServerBeta_ta.jnlp">

    <information>
    <title>FutureScalper Server TA BETA</title>
    <vendor>FutureScalper.com</vendor>
    <description>FutureScalper Server TA BETA</description>
    <homepage href="http://FutureScalper.com/[location removed]/
    serverbeta_ta" />
    <offline-allowed />
    </information>

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

    <resources>
    <j2se version="1.6.0+" java-vm-args=" -server -
    -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1TimeSliceMS=40 -
    -XX:+G1ParallelRSetUpdatingEnabled -XX:+G1ParallelRSetScanningEnabled
    -
    -XX:GCPauseIntervalMillis=250 -
    -XX:ThreadStackSize=128 -XX:CompileThreshold=20 -
    -XX:CICompilerCount=4 -XX:+UseBiasedLocking -
    -XX:+AggressiveHeap -XX:+ForceTimeHighResolution -
    -XX:+RelaxAccessControlCheck -XX:-TieredCompilation -
    -XX:MaxInlineSize=256000 -Xverify:none -XX:FreqInlineSize=256000 -XX:-
    DontCompileHugeMethods -
    -XX:+UseFastAccessorMethods -Xss128k -Xms370m -Xmx370m -Xbatch -
    Xnoclassgc -
    -Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel
    --Dswing.metalTheme=steel -
    -Ddeployment.security.mixcode=DISABLE -
    -Duser.timezone=America/New_York -Duser.language=en -Duser.region=US /
    >


    <property name="sun.java2d.noddraw" value="true" />
    <property name="sun.java2d.d3d" value="false" />
    <property name="java.rmi.server.hostname" value="127.0.0.1" />
    <property name="deployment.security.mixcode" value="DISABLE" />

    <jar href="sFutureScalper.jar" download="eager" main="true" />
    <jar href="sFutureScalperChart.jar" download="eager" main="false" /
    >

    <jar href="sFutureScalperSounds.jar" download="eager" main="false" /
    >

    <jar href="sFutureScalperContracts.jar" download="eager"
    main="false" />
    <jar href="sFutureScalperAuth.jar" download="eager" main="false" /
    >

    </resources>

    <application-desc main-class="com.twc.trader.FutureScalper">
    <argument>command-line-argument</argument>
    </application-desc>

    </jnlp>
     
    FutureScalper, Jul 3, 2010
    #4
  5. On Jul 3, 4:33 pm, Eric Sosman <> wrote:
    > On 7/3/2010 10:54 AM, FutureScalper wrote:
    >
    >
    >
    >
    >
    > > On Jul 2, 3:42 pm, Eric Sosman<>  wrote:
    > >> [...]
    > >>       Also, the app doesn't merely "run for hours" and suddenly hit
    > >> trouble while doing the same things it's been doing all along.  The
    > >> JVM is trying to load the com.twc.trader.SupportResistanceDialog$1
    > >> class, which it wouldn't be doing if it had been using that class
    > >> "for hours" and had thus loaded it earlier; this is the first time
    > >> com.twc.trader.SupportResistanceDialog$1 has been called for.  (It's
    > >> possible for a class to be loaded, discarded, and re-loaded, but
    > >> since you say you're doing no ClassLoader trickery that seems fairly
    > >> unlikely.)  I think you should focus your attention on the signing of
    > >> this seldom-used nested class, and see if that turns up anything of
    > >> interest.  At the very least, knowing the particular class that's
    > >> involved may help you reproduce the problem with less waiting around.

    > > [...] There are plenty of times the app pulls
    > > up this particular dialog just fine.  And other times it does not.
    > > This inconsistency is the issue here.  Also, I've seen the Security
    > > Warning on other action listeners as well.  Since the problem is
    > > intermittent and difficult to reproduce, I can't say whether the
    > > particular function was used in the past or not.

    >
    >      Function, schmunction: The stack trace you provided shows that
    > the trouble is in loading com.twc.trader.SupportResistanceDialog$1.
    > The JVM wouldn't be loading the class if it had already been loaded
    > previously (unless you're doing something odd with ClassLoaders, which
    > you say you're not), so this is the first time the class has been used.
    > Find out what the class is (from its name, it looks like a nested class
    > within com.twc.trader.SupportResistanceDialog), find out what action
    > causes it to be loaded, and you'll be well on the way to understanding
    > the chain of events that leads to the failure.  That's not a solution
    > in and of itself, but you'll at least have a way to provoke failures
    > "more reliably."
    >
    > >>       I don't know whether it makes a difference, but the troublesome
    > >> class is being loaded from the network, not from a local source.  Maybe
    > >> you've got a mismatched mixture of old, cached classes with fresh
    > >> somewhere-over-the-network classes?  It might be helpful to turn on the
    > >> JVM's trace of class-loading activity, and see if anything's weird.

    >
    > > I am not aware of any network-loaded classes, [...]

    >
    > > I will see whether for some weird reason attempts are being made to
    > > load classes over the network.  I'll investigate how you came to this
    > > conclusion and maybe there is something weird going on here...

    >
    >      See those java.net.URLClassLoader methods in the stack trace?
    >
    >      Let me narrow it down a little more for you: The class gets loaded
    > while you're in com.twc.trader.SupportResistanceDialog.<init>, that is,
    > while you're constructing an instance of SupportResistanceDialog.  I
    > can't tell how many constructors this class has nor which of them is
    > running, but at least one of them uses the nested class and somebody
    > tries to load the nested class from the network.
    >
    > --
    > Eric Sosman
    >


    Eric, there is NOTHING which should provoke classes being loaded "from
    the network".

    All JARs are local, all loads in this case are "ordinary"
    instantiations.

    Just because "...URL..." is in the name of the method doesn't mean the
    "network" is involved.

    ANYWAY, what part of "deployment.security.mixcode=DISABLE" does the
    Java runtime NOT understand ????

    To me, it doesn't go any further than that. If deployment.config is
    correctly set, and mandates deployment.properties, and it contains
    "deployment.security.mixcode=DISABLE" then it should be GAME OVER for
    mixed code Security Warnings.

    What more is there to this issue? I should NOT be receiving the mixed
    code Security Warning.

    Under what circumstances should this ever happen, given the
    specifications for the property "deployment.security.mixcode=DISABLE".

    Please explain it to me; and in the meantime, I have to freeze at Sun
    Java 6 Update 17 until what I strongly suspect is a bug, is resolved.

    The class in question is loaded 99.9% of the time without issue. I
    believe the VM "reverts" erroneously to mixed code checking at
    runtime, as I've had issues with other classes being loaded, also as a
    result of a GUI activity. Again, I'm just asking why the
    inconsistency? If it's NOT entitled to be loaded, then it should
    NEVER load, or am I being naive here?

    I am very appreciative of your replies.
     
    FutureScalper, Jul 4, 2010
    #5
  6. FutureScalper

    Eric Sosman Guest

    On 7/4/2010 8:54 AM, FutureScalper wrote:
    > [...]
    > Just because "...URL..." is in the name of the method doesn't mean the
    > "network" is involved.


    Sorry; my mistake. I keep forgetting that "URL" encompasses
    a lot more things than network protocols.

    > The class in question is loaded 99.9% of the time without issue.


    Why do you believe so? Why do you believe this class, unlike
    practically all other classes, is loaded more than once? Have you
    traced the JVM's loading of classes? Have you even traced the
    loading of this one particular class, perhaps by putting a logging
    call in its static initialization code? Have you even determined
    what the class *is* -- yes, we know its synthetic name, but have
    you figured out which bit of source code it corresponds to?

    You keep rending your garments and tearing your hair about the
    injustice of a SecurityException, but I've seen nothing to indicate
    you're doing anything but the tearing and rending -- except, maybe,
    the "99.9%" figure, but I suspect you just plucked that one from the
    air. How did you measure it? What experiments have you tried?

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jul 4, 2010
    #6
  7. On Jul 4, 11:04 am, Eric Sosman <> wrote:
    > On 7/4/2010 8:54 AM, FutureScalper wrote:
    >
    > > [...]
    > > Just because "...URL..." is in the name of the method doesn't mean the
    > > "network" is involved.

    >
    >      Sorry; my mistake.  I keep forgetting that "URL" encompasses
    > a lot more things than network protocols.
    >
    > > The class in question is loaded 99.9% of the time without issue.

    >
    >      Why do you believe so?  Why do you believe this class, unlike
    > practically all other classes, is loaded more than once?  Have you
    > traced the JVM's loading of classes?  Have you even traced the
    > loading of this one particular class, perhaps by putting a logging
    > call in its static initialization code?  Have you even determined
    > what the class *is* -- yes, we know its synthetic name, but have
    > you figured out which bit of source code it corresponds to?
    >
    >      You keep rending your garments and tearing your hair about the
    > injustice of a SecurityException, but I've seen nothing to indicate
    > you're doing anything but the tearing and rending -- except, maybe,
    > the "99.9%" figure, but I suspect you just plucked that one from the
    > air.  How did you measure it?  What experiments have you tried?
    >
    > --
    > Eric Sosman
    >


    You've really got an attitude. Look, the class is MY code, it's an
    ordinary JDialog and it's loaded only once. It loads fine, and I
    repeat 99.9% of the time. I don't care of that initial load is first
    in the session or a couple of hours later.

    The only point here is that it should NEVER load if it's in violation
    of the mixed code restriction, not sometimes.

    And the mixed code restriction is switched off. Why doesn't that
    impress you?

    Never mind whether I've traced class loading... The point is that the
    Security Warning intermittent issue is probably a BUG and I submitted
    a bug report to Sun/Oracle on this.
     
    FutureScalper, Jul 4, 2010
    #7
  8. FutureScalper

    Eric Sosman Guest

    On 7/4/2010 3:05 PM, FutureScalper wrote:
    >
    > You've really got an attitude.


    Yes, I've got an attitude. My attitude is that your shirty
    back-sass justifies me in tripling my fees for trying to help.

    > Look, the class is MY code, it's an
    > ordinary JDialog and it's loaded only once. It loads fine, and I
    > repeat 99.9% of the time.


    So you've actually recorded at least a thousand successful
    class loadings with no more than one failure? R-i-i-g-h-t.

    > Never mind whether I've traced class loading...


    I think you have not, and that you're just sulking and making
    excuses (and making up numbers). Listen, O Victim, it may in fact
    be true that you have encountered a bug. But if you want justice
    you need to do more than lie around complaining about it: You've
    got to make a case, gather some evidence, investigate, do something
    other than sit there in a tear-soaked passive wretchedness. And
    you certainly need to stop abusing the passers-by who offer alms.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jul 4, 2010
    #8
  9. FutureScalper

    Lew Guest

    FutureScalper wrote:
    >> --
    >> Eric Sosman
    >>


    Don't quote sigs.

    > You've really got an attitude. Look, the class is MY code, it's an


    He's got the attitude called "telling the truth".

    The evidence strongly supports what Eric told you. The person disregarding
    that evidence and resorting to ad hominem remarks is the one with the attitude.

    > ordinary JDialog and it's loaded only once. It loads fine, and I
    > repeat 99.9% of the time. I don't care of that initial load is first
    > in the session or a couple of hours later.


    But the stack trace shows that the error occurs during the load of the nested
    class to which Eric pointed you, all your shouting notwithstanding.

    > The only point here is that it should NEVER load if it's in violation
    > of the mixed code restriction, not sometimes.
    >
    > And the mixed code restriction is switched off. Why doesn't that
    > impress you?


    Probably because the evidence favors what he said, not what you said.

    > Never mind whether I've traced class loading... The point is that the


    Never mind tracking down the real reason for the problem ...

    > Security Warning intermittent issue is probably a BUG and I submitted
    > a bug report to Sun/Oracle on this.


    Oh, it's a "BUG" all right, just not in Sun's code.

    --
    Lew
     
    Lew, Jul 4, 2010
    #9
  10. FutureScalper

    Guest

    On Jul 2, 8:05 pm, FutureScalper <> wrote:

    > Exception in thread "AWT-EventQueue-0" java.lang.SecurityException:
    > class "com.twc.trader.SupportResistanceDialog$1"'s signer information
    > does not match signer information of other classes in the same package
    >         at java.lang.ClassLoader.checkCerts(Unknown Source)


    This security check dates back over a decade. This exception may now
    show up now because of the mixed code fix or some other change in
    6u18/6u19/6u20. It's even possible that it's just a race condition
    that has been disturbed.

    Tom Hawtin
     
    , Jul 6, 2010
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pete Becker
    Replies:
    0
    Views:
    1,382
    Pete Becker
    Feb 10, 2005
  2. Des Norton

    Newbie - Mixed Mode Security

    Des Norton, Sep 29, 2004, in forum: ASP .Net Security
    Replies:
    2
    Views:
    112
    Des Norton
    Sep 30, 2004
  3. MR
    Replies:
    2
    Views:
    170
  4. nugget
    Replies:
    7
    Views:
    212
    nugget
    May 16, 2006
  5. Joel VanderWerf

    1.9 warning for 'private' and possible bug

    Joel VanderWerf, Jun 5, 2010, in forum: Ruby
    Replies:
    5
    Views:
    128
    Joel VanderWerf
    Jun 6, 2010
Loading...

Share This Page