0
votes

I have a JAX-RS webservice with a resource for generating testdata. During tests I found out, that the injected EJB is not reinitialized and still contains data from the last request.

I have a jar file server.jar containing my business logic with EJBs. To show my problem I have created a stateless bean:

@Stateless
public class TestService
{
    @EJB
    SubsequentTestService state2Service;

    private String value;

    public void testIt()
    {
        System.out.println("####### VALUE: " + value);
        value = "TestValue";

        state2Service.testIt();
    }
}

I am using the subsequent call to SubsequentTestService to show the odd behaviour also exists for call of another stateless EJB:

@Stateless
public class SubsequentTestService
{
    private String value;

    public void testIt()
    {
        System.out.println("####### VALUE2: " + value);
        value = "TestValue2";
    }
}

Changing the annotation form @EJB to @Inject does not change anything.

In my web.war I have simple JAX-RS beans. The one which is called to show the strange behaviour is defined as follows:

@Path("/test")
public class TestResource
{
    @Inject
    TestService testService;

    @GET
    @Path("/state")
    public void testState()
    {
        testService.testIt();
    }
}

The JAX-RS application configuration looks as follows:

@ApplicationPath("/api")
public class JaxRsConfiguration extends Application
{
}

The war file contains the beans.xml, but no other configuration file. Everything is packaged into an ear file and is deployed in wildfly 10.0.0.Final. If I call the webservice as GET request via http://localhost:8080/api/test/state I get the expected output:

INFO [stdout] (default task-7) ####### VALUE: null
INFO [stdout] (default task-7) ####### VALUE2: null

But on the second request I get following unexpected output:

INFO [stdout] (default task-8) ####### VALUE: TestValue
INFO [stdout] (default task-8) ####### VALUE2: TestValue2

What is my problem here? Might be anything misconfigured in the wildfly? But I have only changed the logging and the datasource definition.

1

1 Answers

2
votes

You have the meaning of @Stateless backwards.

This does not mean like so:

Hey container, here's an arbitrary class, please make it a stateless bean.

This actually means like so:

Hey container, here's a stateless class, you can safely use it as a stateless bean.

You have a stateful class. You should mark it as a @Stateful bean. Otherwise, get rid of all the state (unmanaged instance variables) so you can safely use it as a @Stateless bean.

See also: