IronJacamar Embedded

[Jesper Pedersen]

Hi all,

I have merged initial support for the embedded profile to the master branch.

The basic setup is the same as the IronJacamar 1.x series, just a package name change, so not a lot of news in that area.

However, I have added a JUnit4 testing extension which supports all stages of our bootstrap:

https://github.com/ironjacamar/ironjacamar/blob/master/testsuite/src/test/java/org/ironjacamar/embeddded/junit4/JUnit4TestCase.java

Step 1: @Configuration

The org.ironjacamar.embedded.Configuration annotation is read (if present), and the embedded environment is setup based on the specified settings.

Currently it supports 'full' attribute which specifies if a full profile of the IronJacamar container with all its dependencies should be activated. A value of 'false' will just give the kernel environment.

We can add more settings in future versions which interacts with the deployed beans.

Step 2: Static @Deployment

Static org.ironjacamar.embedded.Deployment annotations are read, and the deployments are processed in the order defined.

The deployment method can take parameters, which can be initialized with the javax.inject.Inject and javax.inject.Named annotations. If no @Named annotation exists the simple class name is used as a name lookup in the kernel.

Step 3: Static @Inject

Static javax.inject.Inject annotations are processed, and the values are injected. A javax.inject.Named annotation can be used to specify the bean name, otherwise the simple class name will be used as a name lookup in the kernel.

Step 4: Static @Resource

Static javax.annotation.Resource annotations are processed, and the values are injected based on JNDI lookups through the 'mappedName' attribute.

Step 5: @BeforeClass

JUnit4's @BeforeClass annotation(s) is executed.

Here we can do pre-condition checks on the environment.

Step 6: Non-static @Deployment

Non-static org.ironjacamar.embedded.Deployment annotations are read, and the deployments are processed in the order defined.

The deployment method can take parameters, which can be initialized with the javax.inject.Inject and javax.inject.Named annotations. If no @Named annotation exists the simple class name is used as a name lookup in the kernel.

Step 7: Non-static @Inject

Non-static javax.inject.Inject annotations are processed, and the values are injected. A javax.inject.Named annotation can be used to specify the bean name, otherwise the simple class name will be used as a name lookup in the kernel.

Step 8: Non-static @Resource

Non-static javax.annotation.Resource annotations are processed, and the values are injected based on JNDI lookups through the 'mappedName' attribute.

Step 9: @Before

JUnit4's @Before annotation(s) is executed.

Step 10: @Test

The JUnit4 test method executes.

Step 11: @After

JUnit4's @After annotation(s) is executed.

Step 12: Non-static cleanup

Fields related to step 8 and 7 are cleared. Deployments defined in step 6 are undeployed.

Step 6 through 12 are repeated for each test.

Step 13: @AfterClass

JUnit4's @AfterClass is executed, and post-conditions on the environment can be performed.

Step 14: Static cleanup

Fields related to step 4 and 3 are cleared, and deployments defined in step 2 are undeployed.


So, this gives a very fine grained lifecycle, and give us options to verify the environment and deployments at various levels. It goes without saying (right?) that this setup should be used for all test cases that aren't strictly POJO based.

The API will improve over time based on requirements, and ease of use. F.ex. the API for the XSDs is missing atm, but will show up in a later commit.

Hope this gives an idea of where future resource adapter testing is heading :)

[Jianfeng Zhang]

That's great! Thanks Jesper.

A question: If I don't need transactionManager, can I ignore it? (don't inject tm)

--
You received this message because you are subscribed to the Google Groups "IronJacamar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ironjacamar-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[thje...@redhat.com]

Great progress! The Narayana team will take a look at this for our quickstarts that use IronJacamar Embedded.

[Jesper Pedersen]

On Tuesday, April 28, 2015 at 8:09:41 PM UTC-4, Jeff Zhang wrote:

That's great! Thanks Jesper.

A question: If I don't need transactionManager, can I ignore it? (don't inject tm)

The Embedded injection is a special "bean", the rest is whatever is defined, or deployed.

The beans for the full profile configuration can be found in embedded/src/main/resources - except for noop-transaction.xml

[Jesper Pedersen]

The initial IronJacamar 2.0 XSDs are in, so that should provide the XSD-based API for embedded.

I don't think that it makes sense to expose the 1.x XSDs, as they "belong" in the "org.jboss.jca" namespace, so no need for the ShrinkWrap/Descriptor metadata-parser to deal with them. Feedback is of course welcome.

[Jesper Pedersen]

I have merged support for the @PreCondition and @PostCondition annotations, which can be used to verify the state of the environment.

The AllChecks implementation will verify that the state of the container is the same upon startup as it is upon shutdown, and hence no deployments nor parts of those are still active in some form.

Together with the rest of the JUnit4 setup we should now have the testing blocks that we need for all basic test cases. I'll look at integrating 3rd party extensions, like Byteman, at a later time - feel free to speak up if you would be interested in helping with that.

[Jesper Pedersen]

I have merged initial Byteman integration into the repository.

There is a special JUnit4 runner called IronJacamarWithByteman which allows classes to be annotated with @BMRules and @BMRule that defines the Byteman rules that should be used during the test cases. I didn't add support for method level rules, as I don't think it is necessary. Of course I could be proven wrong, but we can always add it later.

The rules are activated in a new "Step 0", which means that we can test all classes in our environment, and they are uninstalled in a new "Step 15".

The @BMRule annotation has support for the following Byteman keywords

• RULE
• INTERFACE / CLASS
• METHOD
• AT
• BIND
• HELPER
• IF

which should cover most of our use-cases.

Currently the test suite is always with the Byteman agent installed. Contribution on splitting based on test class name (*BMTestCase) is welcome.

[Jesper Pedersen]

I have submitted https://github.com/ironjacamar/ironjacamar/pull/445 which adds support for an @Initializer() and a @Finalizer annotation.

The @Initializer takes an org.ironjacamar.embedded.junit4.Beans class, and executes it after the @Configuration is run -- e.g. a Step 1a). This can be used to change the configuration of the container beans before any deployments are done.

Likewise, @Finalizer takes an org.ironjacamar.embedded.junit4.Beans class, and executes it before the container is shutdown, in order to handle any cleanup. Should only be necessary in order to guard against container asserts.

[Stefano Maestri]

Hi,

yup they sounds useful in some situation.

thanks,

S.