java.security.AccessControlException doing "Hellow World" RMI invocation

HCL Domino Domino Forum
1

  • I’m trying to use R6 to invoke RMI to run code in a Java 5 VM. I’ve done this without RMI, by using RunTime.exec() and console scraping, and that works fine. But this system requires quite a bit more complexity than console scraping can readily accept.- I have the server running in Java 5, the objects bound to the RMI Registry, and it all works from Eclipse using a test client.

  • I had to past the object interface and implementation code directly into Script Libraries in Domino because (naturally) the 1.3.1 JVM can’t understand 1.5.x JARs. This may cause versioning issues, but I don’t get far enough to know.

  • Instead it says java.security.AccessControlException: access denied (java.io.FilePermisison /- read). This is baffling to me, because it shouldn’t be hitting that directory. The code is all local to the Domino application.

  • By “RMI classes directory”, I mean the directory that Eclipse uses when it compiles the code that registers the remote object with the RMI Registry. In this instance it’s /classes. The build.xml file packages this entire directory into a JAR that it instantiates classes from to register the object, and to run the stand-alone test client.

  • None-the-less, I’ve done the following:

  1. Set the Agent security to “3” to allow all operations with admin rights.

  2. Updated Domino’s java.policy file to grant the Domino directory and all it’s subdirectories full permissions:

grant codeBase “file://-” {

permission java.security.AllPermission;

};

  1. Updated both Domino’s and Java 5’s java.policy files to allow read access to the RMI classes directory:

    permission java.io.FilePermission “<fully qualified path to eclipse project classes directory/-”, “read”;

  • Step one gets around a different access violation. The other two steps have no effect, even after restarting the server between policy file updates. I’ve done all sorts of variations on the above, like changing slashes and using “*” instead of “-”. Nothing makes the slightest bit of difference, at least nothing I’ve done.

  • SO I have two questions:

  1. What am I missing to get past this permission issue?

  2. Am I wasting my time? I’m using Java 5 as the RMI server to overcome many, many limitations in R6’s 1.3.1 JVM. If R6 can’t accept an object from a Java 5 RMI server, then this is a wash, anyway, and I’m back to console scraping.

  • Thanks for your time…
2

Subject: “SOLVED”: I am wasting my time…

  • As is typical, after spending the entire day looking for an answer, and finally breaking down and posting a query, I find what I’m looking for! (wry grin)- The “solution” is that java.io.FilePermission requires a Winbloze path, so it must use double backslashes in the java.policy file instead of the more normal single forward slashes. Do that, and I get an UnsupportedClassVersionError from the RMI invocation, which is what I feared all along. Don’t know how to get around that … I must have capabilities that are simply not present in Domino’s JVM.

  • Hope this helps someone else…

3

Subject: RE: “SOLVED”: I am wasting my time…

Interesting.

Have you tried using the library from the file system via JavaUserClasses?

If you do that, Domino uses the machine jvm classloader and not it’s own (if I understand correctly) you may find a way through there.

I’m hazy about this but i believe that Domino classloader hunts for classes in the following order:

  1. javauserclasses using system classloader

  2. domino jvm??

  3. lib\ext

  4. Java libraries

I always found that this area of Domino is very poorly documented by IBM. There seems to be no centre of wisdom provided.

Simon

4

Subject: RE: “SOLVED”: I am wasting my time…

  • I appreciate your response, Simon, but I can load the code just fine after correcting the path in java.policy. I even figured out how to compile the RMI server code using 1.3 compatibility so I can load the JAR directly from the hard drive for the objects, which gets around the UnsupportedClassVersionError.- Now I have to figure out how to build and compile RMI stubs by hand, because JVM 1.3 doesn’t use the same mechanism as JVM 1.5, so the Domino end can’t unmarshall the return object.

  • Nothing like backwards compatibility, eh?

  • Thanks again, and hope this helps someone…