tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <quin...@skywalk.co.za>
Subject Re: Problem with Testing OpenEJB Security - Examples
Date Fri, 18 Sep 2009 16:24:34 GMT
That's actually a good idea, ie. JUnit runner with annotations.

Here are some ideas. The names were just chosen to make their points
more clear. Better names can be used with actually implemented.

To run a specified test as 3 different roles. The first 2 should
succeed, the 3rd should fail with a security exception.
@RunTestAs({
  @Allow("admin"),
  @Allow("human-resources"),
  @Disallow("employee")
})

Allowing @EJB annotations to inject, just like in the container.
@EJB
private MyBeanLocal myBean;

Basic configuration of OpenEJB. This basically just specified how the
InitialContext need be created:
@OpenEJBContext({
  properties=@Properties({
    @Property("javax.naming.factory.initial", "..LocalInitialContextFactory"),
    @Property("..realmName", "MyRealm")
  }),
  resources=@Resources({
    @DatabasePool(
      name="myPool",
      driver="org.postgresql.Driver",
      databaseName="my_dedicated_test_database"
      ...
    })
  })
})

And along with this you can specify something like the following to
have a given file load for your context. This would then instead load
a testing deployment descriptor instead of the original, in places
where it is found. So it basically follows rules like: if
(testConfigFound) { loadTestConfig(); } else { loadStandardConfig(); }
@OpenEJBContext({
  config="/META-INF/testing-openejb-jar.xml"
})

You can perhaps do the same for persistence.xml and other common
descriptor files. This is a big problem with JUnit tests, that the
descriptor files used in production don't always work well in the
JUnit tests. Take for example my persistence.xml. I have to specify a
propery like:
  <property name="hibernate.transaction.manager_lookup_class"
value="class-of-tx-manager-lookup"/>
And in tests:
  <property name="hibernate.transaction.manager_lookup_class"
value="class-of-another-tx-manager-lookup"/>

And since I can't specify different persistence.xml files, I create my
own TransactionManagerLookup, which is a wrapper of both types, and at
runtime dynamically selects the correct one. This is extra effort,
which is found in many different forms, such an annotation can make
much easier to solve.

There are just some ideas. Got any others? If we can perhaps spec
something like this, I will see if I can put it together. I would
enjoy writing something like this. I'm low on time at the moment, but
from next weekend I should be free again, and was planning on doing
some open source work in any case. So if we can spec this in the
meantime I will make it when I get  some time.

The basic idea around it, would be:
1. You use the OpenEJB JUnit runner. It checks the JUnit test class's
annotations. Parses them and initializes an InitialContext plus
specifies some options to OpenEJB. OpenEJB loads taking into account
these options. Then each of your tests are executed taking into
account method level annotations as well. Annotations which specify
multiple types of "runs", like running in different security contexts
to test authorization, will be run once for each of the roles.

Quintin Beukes



On Thu, Sep 17, 2009 at 1:05 AM, David Blevins <david.blevins@visi.com> wrote:
>
> On Sep 12, 2009, at 3:35 AM, Quintin Beukes wrote:
>
>> Is it possible to dynamic construct EJBs in the embedded container? If
>> this is possible one could even go as far as making an
>> openejb-junit.jar, which takes the form of:
>> OpenEjbTest.runAs("admin", new Callable() {
>> ...
>> });
>>
>> Then the static method would have an EJB which it dynamically modifies
>> to run as a given role.
>
> No way to dynamically define ejbs at the moment.  For the use case above the
> InitialContext login approach might work better as it allows you to set the
> user/pass as a string.
>
> On another note, I've also been kicking around the idea of creating a JUnit
> test runner which would open up some interesting possibilities such as
> annotating test methods with transaction and security annotations.
>
> -David
>
>
a

Mime
View raw message