Bill,
Thanks for taking the time to run the tests, and congrats on the
perfect results.
Re: the lack of a method-permissions, we don't provide access
control without installing our security product (which requires
RSA, which requires money, etc.) Thus, by default, the default
version of our product runs without ACLs. Another posting
recently questioned whether it was compliant to have a
server in a configuration that did not support security checks
and identity propagation, and I must admit I had not thought
about it.
In our product, security checks are enabled if you are running
with security; without security, the server is wide open, and
thus does not require ACLs.
This could be a non-compliance that we should address for the
next release. It's trivial to fix (and in fact, its how our
Alpha version worked, and then we thought it was easier to let
people deploy non-ACLed beans into a non-secured server).
Thoughts?
(And how about some of those other products. Anyone able to
run the tests? Lurking vendors?)
-jkw
Bill Claypool wrote:
>
> "Jonathan K. Weedon" wrote:
>
> > I have developed a fairly straight-forward RMI API compliance checker.
> > This test provides a simple stateless session bean, which is to be
> > deployed into the AppServer under test. Then, a client is run against
> > the AppServer which tests various aspects of the RMI API. (Note that
> > this test is for the RMI APIs, not for RMI protocol, which might be
> > RMI-over-JRMP, RMI-over-IIOP, or RMI over any other protocol. Any
> > proper implementation of the RMI APIs should pass all tests.)
> [...]
> > Please, post your results for these and other products.
>
> Results for Unify eWave Engine 1.1b:
>
> Support for int PASSED
> Support for int[] PASSED
> Support for String PASSED
> Support for String[] PASSED
> Support for EJBObject PASSED
> Support for EJBHome PASSED
> Support for Vector(1) PASSED
> Support for Vector(2) PASSED
>
> Ran 156/156 tests: 100.0%
> Skipped 0/156 tests: 0.0%
> Passed 156/156 tests: 100.0%
> Failed 0/156 tests: 0.0%
>
> Note that I had to add a <method-permission> entry to ejb-jar.xml
> before I was able to actually call the bean. I am surprised that
> you would be able to run this in any EJB 1.1 server without some
> similar entry.
>
> diff -c ejb-jar.xml.orig ejb-jar.xml
> *** ejb-jar.xml.orig Wed Apr 12 11:17:22 2000
> --- ejb-jar.xml Wed Apr 12 11:23:25 2000
> ***************
> *** 24,29 ****
> --- 24,40 ----
> </session>
> </enterprise-beans>
> <assembly-descriptor>
> + <security-role>
> + <role-name>Public</role-name>
> + </security-role>
> + <method-permission>
> + <role-name>Public</role-name>
> + <method>
> + <ejb-name>rmiTest</ejb-name>
> + <method-name>*</method-name>
> + <method-params />
> + </method>
> + </method-permission>
> <container-transaction>
> <description></description>
> <method>
>
> --
> Bill Claypool | Seeing is believing in the things you see.
> [EMAIL PROTECTED] | Loving is believing in the ones you love.
> 1 916 928 6259 | RKBA! -Margie Adam
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
