Yes, for exactly the reasons u mentioned i was compelled to ask
end-user download vrml97.jar and put it into ext dir, so it becomes an
installed extension. As to solution, JRE1.3 is to support automatic
extensions downloading (u write a couple of lines in manifest file and
Plug-in would download necessary extension and put it into ext dir).
BTW, RC3, which has recently been released, already claims to support
this feature. Haven't tried it yet with RC3 (two previous RCs didn't
support it), but i definitely will soon enough.
vladimir
-=V=-
>-------<=============>-------<
Join Java community now!
http://JavaCafe.VirtualAve.net/
>-------<=============>-------<
In your previous letter u wrote:
--------------------------------
JP> hi,
JP> i'm trying to create a J3D VRML web browser viewer with the vrml97 loader. i have
it set up so that the vrml97.jar is enclosed in my VRMLViewer.jar on "server" system.
the "server" system also
JP> holds the vrml data file (test.wrl). my "client" system (which the browser will
be running under) will have just Java3D installed (not the vrml97 loader). "client"
will load up the
JP> VRMLViewer.html which will invoke the VRMLViewer.class object in the
VRMLViewer.jar archive and load the test.wrl file up using the vrml97 loader that's
also in the VRMLViewer.jar archive given
JP> to the "client" from the "server".
JP> when i do this, i get an AccessControlException where i'm violating a
RuntimePermission to createClassLoader. looking further into the vrml loader source
code, i realize that the VrmlLoader
JP> object creates a URLClassLoader object based on the URL location on the Url of
where my "server" holds the test.wrl file is - the URLClassLoader is triggering the
AccessControlException. so i
JP> have a couple of questions from that:
JP> 1) i understand that a class loader allows classes to be loaded from elsewhere (ie
another network domain). from the code, it looks like vrml97 loader is setting up an
URLClassLoader for the
JP> test.wrl file. why does it need to do that? isn't a file stream just be opened
across the network to read in the test.wrl file for the loader or am i just not
understanding the code? or is it
JP> using the URLClassLoader to load certain vrml97 class files from across the
network from my "server" and that violates Java security? if that's the case, why do
we need to a URLClassLoader since
JP> i've bundled the vrml97.jar archive in with the VRMLViewer.jar archive which is
downloaded to the "client" anyway. couldn't the "client" just use the JRE's default
class loader to load the
JP> vrml97 loader classes from it's own local space? again, am i just not
understanding how the JVM works?
JP> 2) if the URLClassLoader is absolutely necessary to read in my test.wrl from the
"server", can anything be done with the loading code to allow the "client" to allow
class loading. basically i'm
JP> looking for solutions which require work on the "server" (ie code modifications,
server system settings, etc), but assume that the "client" is dumb and that nothing
can be done with the "client.
JP> thanks for any input. i'm new with Java and Java3D... still learning as much as
possible.
JP> jack
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
