Hello,
thanks a lot for your comments. Just giving me a reference to the
documentation helped me a lot.
Dave refers to the spec that says:
" * An enterprise bean must not attempt to listen on a socket, accept
connections on a socket, or use a socket for multicast.
The EJB architecture allows an enterprise bean instance to be a network
socket client, but it does not allow it to be a network server. Allowing
the instance to become a network server would conflict with the basic
function of the enterprise bean-- to serve the EJB clients."
This implicitly says: The EJB may attempt to connect to a socket, i.e.
at some low level issue (maybe implicitly) the "connect" call of the
socket interface.
In 18.2.1.1 the spec defines that the EJB Container must be able to
grant to the enterprise bean instances at runtime...
...java.net.SocketPermission - grant "connect", "*" [Note A], deny all
other
Note [A] says: "This permission is necessary, for example, to allow
enterprise beans to use the client functionality of the Java IDL API and
RMI-IIOP packages that are part of Java 2 platform."
That is to say: The EJB is MEANT to possibly be a RMI client.
Indeed, a small standalone RMI client test application runs fine with
only the following policy granted:
grant {
// allows anyone to listen on un-privileged ports
permission java.net.SocketPermission "*:1024-65535",
"connect,resolve";
};
or, stated in other words, connect-permission is enough to be RMI
client.
OK, this to the spec. It should be possible then. But how?
Daves reference gave me the hint. Some lines below the cited text above
the spec says:
"The enterprise bean must not attempt to ... set security manager ..."
This evil forbidden thing a did in my code line
System.setSecurityManager(new RMISecurityManager());
I commented it out and - miracle - I could connect to my tiny RMI server
and everthing worked as had dreamed of it.
Problem solved.
But, referring to point 2 of my original mail: What the heck is the
<server> tag in rmi.xml meant to do? And why doesn't orion start up when
I set it?
Again, thanks for your valuable hints.
Friedrich Dodt
Ted Neward wrote:
>
> Where do you see that? I don't read any particular restriction on making RMI
> calls; you're not allowed to explicitly listen for any incoming socket
> calls, but that's not the same.
>
> When I stop to think about it, in fact, a reference to another EJB itself
> may be a remote reference, so the EJB spec CAN'T, in my interpretation,
> forbid RMI calls, because then a Bean could never refer to another bean in
> any way.
I completely agree to this argument.
> Is there some text I missed in that section? (I freely admit, I
> just skimmed it just now--not a real deep read--but didn't see anything
> along those lines.)
>
> Ted Neward
> Java Instructor, DevelopMentor (http://www.develop.com)
> http://www.javageeks.com/~tneward
>
> ----- Original Message -----
> From: "Dave Smith" <[EMAIL PROTECTED]>
> To: "Orion-Interest" <[EMAIL PROTECTED]>
> Sent: Thursday, August 31, 2000 9:10 AM
> Subject: Re: RMI from EJB, permissions in EJB
>
> > I'm not sure you can. I think this kind of behaviour (i.e. opening sockets
> > to remote registries) is explicitly forbidden in section 18.1.2 of the EJB
> > 1.1 spec.
> >
> > Friedrich Dodt wrote:
> >
> > > How do I get my Session Bean to issue an RMI call successfully?
> > >
> > > I am trying to contact a simple RMI method that runs on an RMI server
> > > (rmiregistry) from code in my Session Bean. Up to now without success.
> > >
> > > 1. With the naive approach
> > >
> > > System.setSecurityManager(new RMISecurityManager());
> > > RemoteObject remo = (RemoteObject) Naming.lookup(toLookup);
> > >
> > > I get a (java.net.SocketPermission xxx.xxx.xxx.xxx:xxxx
> > > connect,resolve)
> > >
> > > To overcome this, I have changed
> > > - {java.home}/lib/security/java.policy
> > > - and I have tried it the with the command line arguments
> > > -Djava.security.manager -Djava.security.policy==my.policy
> > > when I start orion.jar.
> > >
> > > This policy file contained just
> > >
> > > grant {
> > > // Allow everything for now
> > > permission java.security.AllPermission;
> > > permission com.evermind.server.AdministrationPermission;
> > > permission java.net.SocketPermission "*:1024-65535",
> > > "listen,accept,connect,resolve";
> > > };
> > >
> > > However, this didn't change Orions behaviour.
> > >
> > > The approach with
> > > // create and fill a Hashtable "environment", then call
> > > InitialContext context = new InitialContext (environment);
> > > didn't work either.
> > >
> > > 2. Suspecting that the Orion server interferes with the normal policy
> > > concept, I tried to change the rmi.xml file.
> > >
> > > The mere adding of a line like
> > >
> > > <server host="localhost" username="admin" password="admin" />
> > >
> > > to rmi.xml leads to the server not starting up. It does not say "Orion
> > > 1.0.3 initialized" and it does not react (in the case rmiregistry runs;
> > > if not an Exception is thrown indicating the connection is refused).
> > >
> > > This is clearly a bug: If the server can't cope with a situation it
> > > should at least leave a message and not just be stuck silently. This is
> > > true if you start Orion just as it ships with just the rmi.xml changed.
> > >
> > > So the question is: How can I contact an RMI server from within an EJB?
> > >
> > > If you don't know that, perhaps you can answer this one: How can I
> > > permit SocketPermission (and other permissions?) to the code in my EJB?
> > >
> > > Thanks in advance
> >
