tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <>
Subject Re: Problem with Testing OpenEJB Security - Examples
Date Fri, 18 Sep 2009 16:29:04 GMT
Even as a current feature, a property name like
"org.apache.openejb.config-prefix=testing-", would load
testing-persistence.xml and testing-ejb-jar.xml instead of
persistence.xml and ejb-jar.xml, where this is the case. Where it
isn't it would load the original file, as it does currently.

Like I said, I have found way around needing this, but they require
making extra classes, managing extra dependencies, etc. So it could
definitely help if it's there.

Quintin Beukes

On Fri, Sep 18, 2009 at 6:24 PM, Quintin Beukes <> wrote:
> 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 <> 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

View raw message