Re: A strange problem – a strange solution
Posted by Sven Gothel on Oct 04, 2013; 9:07am
URL: https://forum.jogamp.org/A-strange-problem-a-strange-solution-tp4030149p4030151.html
On 10/03/2013 08:32 PM, Alexei A. Morozov [via jogamp] wrote:
> Dear colleagues,
>
> Here is information on a strange problem with Java3D that I have found after
> the publication of JDK7u25.
7u40 is the current release now, below you mention it .. also affected.
> I have found that some examples on my demo site
> cannot work and crash with stack trail like this:
>
> Exception in thread "J3D-MasterControl-1" java.lang.NullPointerException
> at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
> at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
..
> at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at javax.media.j3d.Renderer.<init>(Renderer.java:85)
> at javax.media.j3d.MasterControl$8.run(MasterControl.java:976)
> at java.security.AccessController.doPrivileged(Native Method)
..
Pls try to issue a GLProfile.initSingleton() upfront to ensure all
GlueGen/JOGL related classes (and native JAR files) are loaded.
This should not be necessary .. but thats the only test I could make here ..
>
>
> Well, I cannot understand what a fundamental reason of this situation is, but
> I have found a workaround and want to share it. It has appeared that the crash
> occurs in the course of 3D drawing if the vecmath.jar library is not loaded
> still. So, I use the following workaround now:
>
> a dummy command
>
> Color3f color3d= new Color3f(0,0,0);
>
> is to be inserted in the program before the 3D scene creation. This issue
> changes the behavior of the program.Surely some weird class-loading issue, maybe even JAR order in applet/jnlp.
> Well, I don’t understand what is wrong with JDK7u25-40, but now we have a
> workaround at least.
ah .. 7u40 is affected as well.
>
> P.S. The second issue linked with JDK7u25 is that Java checks the Codebase tag
> in the MANIFEST files now. All gluegen and jogl archives use the
>
> Codebase: *.jogamp.org
>
> value now and this is very uncomfortable for me, because one must change all
> values to the * string to provide work in local net (without access to
> external sites like *.jogamp.org). So, I wonder if this is a policy of the
> jogamp.org or just an unforeseeable consequence of JDK change. Could it be
> fixed in the future releases please?The reason is explained here:
https://jogamp.org/bugzilla/show_bug.cgi?id=758
" 'Codebase: *.jogamp.org' will prevent copying the signed jar files
and survive a vulnerability deletion,
i.e. if we delete our copy from the server it .. it's of no use anymore.
Users would need to signed the jars to be used on their servers.
Yes, this is more like snake oil .. not real security...."
You cannot simply 'open' and change the MANIFEST of our _signed_ JAR files.
If this is possible, Oracle just won another price for a non-working security method.
We set the 'Codebase' tag of the produced JAR files while building
using the environment variable 'JOGAMP_JAR_CODEBASE'
Unix'ish:
export JOGAMP_JAR_CODEBASE="Codebase: *.goethel.localnet"
Windows:
set JOGAMP_JAR_CODEBASE=Codebase: *.goethel.localnet
.. which sets the ant property 'jogamp.jar.codebase',
which you also could set directly when invoking ant.
After build, you will need to sign your builds and publish them ..
Of course, you could also download our unsigned builds
and edit the 'Codebase' tag.
You may use a unix tool like 'sed' for such task, it's simple.
The latter would also allow you to relocate all other codebase related entries,
have a look at jogamp-scripting repo.
Cheers, Sven
>
> Thank you,
>
> Alexei
>
> My fixed demo site: http://www.alexei-morozov-2012.narod.ru/
URL: https://forum.jogamp.org/A-strange-problem-a-strange-solution-tp4030149p4030151.html
On 10/03/2013 08:32 PM, Alexei A. Morozov [via jogamp] wrote:
> Dear colleagues,
>
> Here is information on a strange problem with Java3D that I have found after
> the publication of JDK7u25.
7u40 is the current release now, below you mention it .. also affected.
> I have found that some examples on my demo site
> cannot work and crash with stack trail like this:
>
> Exception in thread "J3D-MasterControl-1" java.lang.NullPointerException
> at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
> at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
..
> at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at javax.media.j3d.Renderer.<init>(Renderer.java:85)
> at javax.media.j3d.MasterControl$8.run(MasterControl.java:976)
> at java.security.AccessController.doPrivileged(Native Method)
..
Pls try to issue a GLProfile.initSingleton() upfront to ensure all
GlueGen/JOGL related classes (and native JAR files) are loaded.
This should not be necessary .. but thats the only test I could make here ..
>
>
> Well, I cannot understand what a fundamental reason of this situation is, but
> I have found a workaround and want to share it. It has appeared that the crash
> occurs in the course of 3D drawing if the vecmath.jar library is not loaded
> still. So, I use the following workaround now:
>
> a dummy command
>
> Color3f color3d= new Color3f(0,0,0);
>
> is to be inserted in the program before the 3D scene creation. This issue
> changes the behavior of the program.
> Well, I don’t understand what is wrong with JDK7u25-40, but now we have a
> workaround at least.
ah .. 7u40 is affected as well.
>
> P.S. The second issue linked with JDK7u25 is that Java checks the Codebase tag
> in the MANIFEST files now. All gluegen and jogl archives use the
>
> Codebase: *.jogamp.org
>
> value now and this is very uncomfortable for me, because one must change all
> values to the * string to provide work in local net (without access to
> external sites like *.jogamp.org). So, I wonder if this is a policy of the
> jogamp.org or just an unforeseeable consequence of JDK change. Could it be
> fixed in the future releases please?
https://jogamp.org/bugzilla/show_bug.cgi?id=758
" 'Codebase: *.jogamp.org' will prevent copying the signed jar files
and survive a vulnerability deletion,
i.e. if we delete our copy from the server it .. it's of no use anymore.
Users would need to signed the jars to be used on their servers.
Yes, this is more like snake oil .. not real security...."
You cannot simply 'open' and change the MANIFEST of our _signed_ JAR files.
If this is possible, Oracle just won another price for a non-working security method.
We set the 'Codebase' tag of the produced JAR files while building
using the environment variable 'JOGAMP_JAR_CODEBASE'
Unix'ish:
export JOGAMP_JAR_CODEBASE="Codebase: *.goethel.localnet"
Windows:
set JOGAMP_JAR_CODEBASE=Codebase: *.goethel.localnet
.. which sets the ant property 'jogamp.jar.codebase',
which you also could set directly when invoking ant.
After build, you will need to sign your builds and publish them ..
Of course, you could also download our unsigned builds
and edit the 'Codebase' tag.
You may use a unix tool like 'sed' for such task, it's simple.
The latter would also allow you to relocate all other codebase related entries,
have a look at jogamp-scripting repo.
Cheers, Sven
>
> Thank you,
>
> Alexei
>
> My fixed demo site: http://www.alexei-morozov-2012.narod.ru/
signature.asc (911 bytes) | Free forum by Nabble | Edit this page |