Hi,
I'm thinking out loud here. These are my latest, uninformed theories and
observations:
Unmarshaling the object during the JNDI lookup results in invocations on a
class loader. This is evident from the stack trace. The class loader access
es a CLASSPATH. The $(JBOSS)/conf/default directory (from stack trace) is
the first entry in this CLASSPATH.
So the *client* CLASSPATH points at the local file system. This results in
the AccessControlException, because applets aren't normally allowed to
access the file system.
So this leads me to the following questions:
1) Where is the client's CLASSPATH coming from?
2) How can I override this CLASSPATH in the client?
3) Why is the *client* looking for JBOSS in the local file system, anyway?
Ostensibly, 99% of clients won't be executing on a system with JBOSS
installed. So why is the *client* CLASSPATH pointing at these JBOSS-specific
file system locations? It seems to me that I have a configuration problem. I
don't know if this is just a personal problem or a common problem based on
the way JBOSS is implemented/shipped.
I'll keep looking. Hopefully someone with a clue will jump in and enlighten
us.
Best Regards,
Brian
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kris Kristensen
Sent: Monday, January 08, 2001 1:08 PM
To: jBoss
Subject: Sv: [jBoss-User] Applet + JNDI Lookup => AccessControlException
?
Hi Brian
You are absolutely right, it should make its lookup over the network and not
on the local box. Sorry for this very poor answer.
To make it up you again, I've posted the question to JDC (Java Developer
Community) at http://java.sun.com, and to this list again.
So...Let's hear what the list have to say.
Cheers
Kris Kristensen
[EMAIL PROTECTED]
Ps. When/if I get an answer from JDC, I'll post it to the list.
-----Oprindelig meddelelse-----
Fra: Brian Calves <[EMAIL PROTECTED]>
Til: 'jBoss' <[EMAIL PROTECTED]>
Dato: 8. januar 2001 14:01
Emne: RE: [jBoss-User] Applet + JNDI Lookup => AccessControlException ?
>
>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.ja
v
>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:75
9
>)
>> 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.jav
a
>:
>>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]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
