CODEWITHSUNDEEP
javatestingjakarta-eeweld-junit4
Jürgen
Jürgen

Reputation: 176

Handling of TimerService in Weld-Junit

I'm trying to setup a Weld-JUnit4 Test for a JavaEE Bean which uses a TimerService. The Application runs in a Wildfly Application Server an So the TimerService is injected into the bean via @ResourceAnnotation.

In Weld-JUnit I have to bind Resources via:
WeldInitiator.from(<Some class).bindResource(nameOfRessource, <TimerServiceMock>)

But this doesn't work. The mock will not be injected. So I tried @Resouce(name = "myTimer")in the JEE Bean. This doesn't work too. So I tried @Resouce(lookup = "myTimer")in the JEE Bean. This works in my Testcase. But in ProductionCode this will change the lookupbehaviour. So it is no valid solution.

How it is possible to Mock the TimerService in a WeldJunitTest? Is there any kind of default lookup for the java.ejb.TimerService?

Thank you for your help.

Upvotes: 1

Views: 282

Answers (1)

Johannes Hahn
Johannes Hahn

Reputation: 410

EJB Spec states

16.14 TimerService References

The container must make the TimerService interface available either through injection using the Resource annotation or in JNDI under the name java:comp/TimerService, in addition to through the EJBContext interface. The authenticationType and shareable elements of the Resource annotation must not be specified.

So it should work if you use that name with the lookup attribute.

Alternatively:

16.2.2 Annotations for Environment Entries

[...]

  • A field of the bean class may be the target of injection. The field must not be final. By default, the name of the field is combined with the name of the class in which the annotation is used and is used directly as the name in the bean’s naming context. For example, a field named myDatabase in the class MySessionBean in the package com.acme.example would correspond to the JNDI name java:comp/env/com.acme.example.MySessionBean/myDatabase. The annotation also allows the JNDI name to be specified explicitly.

So you can also bind the JNDI-name that corresponds to the name of the field. It would allow you to get away with even less overhead in the EJB itself, but at the cost of breaking the test whenever you rename the field.

Upvotes: 0

Related Questions