Updating the kernel tests to make security policy configurab

[starksm64]

The existing hardcoded security policy is not adequate for testing the profile service so I need to make this configurable on a per test basis. It seems like the best place to introduce this is the AbstractTestSetup?

It would be nice if we could just annotate the test class and methods with such configuration information.

[starksm64]

Actually it looks like a test specific AbstractTestDelegate is what is needed.

[adrian.brock]

Or if you want to avoid Java5isms a simple property file like:

test-security.properties
org.jboss.some.test=blah
default=other

Of course you could support both.

[starksm64]

We have the same problem with the setup/delegate notion as we do with the deployers currently. Security is really an aspect that should be layered into any AbstractTestDelegate as all of the existing JavaBeanTestDelegate, JBossXBTestDelegate, MicrocontainerTestDelegate and XMLTestDelegate can have a need to customize the setUpSecurity behavior. What I want to do is augment the AbstractTestDelegate.setUpSecurity to look to the unit test clazz for annotations and/or properties.

Do we have a "slurp all annotations of type x" utility method in aop/javassist for retrieving the annotations in a type hierarchy?

[adrian.brock]

What do you mean by type heirarchy?

Annotations are not inherited unless you specifically say so.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/annotation/Inherited.html

AFAIK, the compiler then adds them to the class that is inheriting it
and it doesn't work very well if you do incremental compiles.

[starksm64]

Meaning a testcase class hiearchy where annotations could be on different classes/test methods. The behavior described by the Inherited meta-annotation does not seem to be consistent with all java ee 5 annotations uses. Probably due to inconsistent usage in the different specs.

So attempting to employ different visitor patterns to slurp annotations from interfaces/superclasses/superinterfaces is contrary to the java language default behavior.

[starksm64]

I was thinking these classes were specific to the mc test codebase, but they are coming from the shared test module. So the question is do we expand this layer with javassist/annotation support, look at TestNG, move to Junit4 (which has been released, http://prdownloads.sourceforge.net/junit/junit4.0.zip?download), ...?

For now I'll augment the org.jboss.test.security.TestsPolicyPlugin with a type hierarchy visitor abstraction that allows for some customization of the policy based on the test being run.

[starksm64]

I updated the PolicyPlugin to access the testcase class so it can perform class related configuration and updated the TestsPolicyPlugin to scan for class related properties files that define testcase specific permission via properties of the form "test.Permission.N=perm_class, name [ ,action ]". For the profileservice testcase I'm working on I create a
kernel\src\tests\org\jboss\test\profileservice\test\SimplePSTestCase.properties with:

test.Permission.0=java.util.PropertyPermission, jbosstest.deploy.dir, read

to allow read access to the jbosstest.deploy.dir system property.