Hi,
Thanks for your response. I didn't get much sleep last night, so maybe I'm
being slow...
> [snip] with JNDI meaning Java Naming and Directory Interface, this store
> must reside on the file system
Why? (I'm genuinely curious and I seek understanding.) Is this your
hypothesis based on observation, or are you saying that this is the only
(convenient) way to implement it?
I assumed that the applet would connect to the JNDI server over the network.
Then the JNDI server, which does not suffer from the security constraints of
an applet, can access the file system or use whatever implementation
approach is most appropriate. In this scenario, the applet need never access
the file system.
The JNDI server need not execute with the same security restrictions as the
client applet? (Or is my mind going...?)
It seems that I've made some fundamentally incorrect assumption somewhere;
and I still haven't understood my error.
Still, thanks for trying to explain it to me! Perhaps if I go back over the
JNDI source again, more carefully, I'll have an epiphany.
-Brian
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kris Kristensen
Sent: Friday, January 05, 2001 8:36 PM
To: jBoss
Subject: Sv: [jBoss-User] Applet + JNDI Lookup => AccessControlException
?
Hi Brian
I've had the exact same problem when running applets that accesses ejb's,
but only when these applets were deployed to my webserver (that is not
inside my IDE JB4). My webserver is Jrun
As far as I can see, this exception is fully acceptable because the applet
is running "out of it's sandbox". Applets are, as you probably know,
restricted from access to the client's file system. I haven't tried it out
but I guess if you deployed your applet to the embedded tomcat web server
everything would work fine, because then it would use the JBoss/Tomcat
security manager, instead of the default.
I found out (by removing the JBoss-client package from my jar) that my 1.3
plugin complained about "cannot find class:
org.jnp.interfaces.NamingContextFactory" which lead me to the clue that
JBoss does access the file system when doing a JNDI-lookup. Hmmm, with JNDI
meaning Java Naming and Directory Interface, this store must reside on the
file system, and the fact that it is the applet that's looking up the JNDI,
then the applet is trying to access the file system, and therefore get
caught by the security manager.
<<java.lang.SecurityManager.checkPermission(SecurityManager.java:545)>>
sounds reasonable ?
A work around is to sign your applet using keytool/jarsigner see sun´s
homepage for details. It worked for me.
Cheers
Kris Kristensen
[EMAIL PROTECTED]
-----Oprindelig meddelelse-----
Fra: Brian Calves <[EMAIL PROTECTED]>
Til: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Dato: 5. januar 2001 21:14
Emne: [jBoss-User] Applet + JNDI Lookup => AccessControlException ?
>
>Hi,
>
>I'm out of ideas, hopefully someone here can give me a clue...
>
>Until now, my EJB clients have been java applications and other EJBs. This
>worked great! Now I'm writing an applet as an EJB client. Unfortunately,
>when the applet attempts a JNDI lookup, I get an AccessControlException.
>It seems something is trying to access a config file in the file system?
>
>I think I read that jBoss has primarily been tested with applets that have
>been granted extra security privileges. Even if I eventually go that route,
>I still want to understand why/where file system access results from the
>JNDI lookup.
>
>How is my code interacting with the system to produce this exception?
>Looking at the stack trace, it's not obvious to me where the access
>violation is really coming from. I tried looking through the source,
>but I couldn't identify the point of the file system access.
>
>Help? Thanks!
>Brian
>
>
>java.security.AccessControlException: access denied (java.io.FilePermission
>/usr/local/jboss_tomcat/jboss-2.0-FINAL/conf/default/- read)
> at
>java.security.AccessControlContext.checkPermission(AccessControlContext.jav
a
>:272)
> at
>java.security.AccessController.checkPermission(AccessController.java:399)
> at
>java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
> at
>sun.rmi.server.LoaderHandler$Loader.checkPermissions(LoaderHandler.java:759
)
> at
>sun.rmi.server.LoaderHandler$Loader.access$000(LoaderHandler.java:713)
> at
>sun.rmi.server.LoaderHandler.getClassLoader(LoaderHandler.java:265)
> at
>sun.rmi.server.MarshalInputStream.resolveProxyClass(MarshalInputStream.java
:
>172)
> at
>java.io.ObjectInputStream.inputProxyClassDescriptor(ObjectInputStream.java:
9
>82)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
> at
>java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
> at java.rmi.MarshalledObject.get(MarshalledObject.java:138)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:304)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:282)
> at javax.naming.InitialContext.lookup(InitialContext.java:350)
> at Foo.initEJB(Foo.java:45)
> at Foo.init(Foo.java:71)
> at sun.applet.AppletPanel.run(AppletPanel.java:344)
> at java.lang.Thread.run(Thread.java:484)
>
>
>private void initEJB()
> // throws CreateException, NamingException, RemoteException
> {
> try
> {
> // Hmmm... isn't there a simpler way to accomplish this?
> Hashtable env = new Hashtable();
> env.put(NAMING_FACTORY_INITIAL,
>getParameter(NAMING_FACTORY_INITIAL));
> env.put(NAMING_PROVIDER_URL,
>getParameter(NAMING_PROVIDER_URL));
> env.put(NAMING_FACTORY_URL_PACKAGE,
>getParameter(NAMING_FACTORY_URL_PACKAGE));
> env.put(JNP_PORT, getParameter(JNP_PORT));
> env.put(JNP_LOG, getParameter(JNP_LOG));
> InitialContext jndiContext = new InitialContext(env);
>
> Object ref = jndiContext.lookup("app/StandardEditor"); // <--
*BOOM*
> StandardEditorHome home = (StandardEditorHome)
>PortableRemoteObject.narrow(ref, StandardEditorHome.class);
>
> this.app = home.create();
> }
> catch(Exception e)
> {
> e.printStackTrace(System.err);
> }
> }
>
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>List Help?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
