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.java
>: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]
