Why is the <env-entry> defined in DD properly accessed only through business method?

[Piotr Nowicki]

Howdy Ranchers!

I've defined a environment resource with default value using annotations:

@Stateless
public class NewSessionBean {
     @Resource(name="test") int myValue = -1;

     public int doSmth() {
        return myValue;
    }
}

in DD I've defined it's value in the following way:
... <session> <ejb-name>NewSessionBean</ejb-name> <env-entry> <env-entry-name>test</env-entry-name> <env-entry-value>100</env-entry-value> </env-entry> </session> ...In another EJB I'm accessing the NewSessionBean as follows:

...
   @EJB
   NewSessionBean nsb;  
   
   @PostConstruct
   private void init() {
      System.out.println(nsb.myValue);   // results in -1
      System.out.println(nsb.doSmth());  // results in 100
      System.out.println(nsb.myValue);   // results in -1
   }
...

As you can see, I'm accessing the env-entry as a package-private field, and then I'm using a business method.

The point is that direct field access returns the default value (-1).
The business method returns properly overridden value (100). To be sure that no 'initialization' takes place, the third line still results in -1.

Well, I guess it's because of the proxy object. Using business method, the container can intercept the method invocation and access the proper value. While accessing the field directly it cannot proxy such call and that's why it results in the default value. Is this correct?

This brings me to observation that the container doesn't simply override the environmental variable (in this case: field myValue) during it's initialization. It just fetches the overriden value 'on-the-fly'. On the other hand, if you access the 'myValue' within the NewSessionBean, like so:

public int doSmth() {
    System.out.println(myValue);
    return myValue;  // results in 100
}

it works fine and returns proper answer: 100...

Can anyone explain why it's so? I wonder if this is the default and expected behaviour, or it might be only Glassfish 3.1 specific?

Thanks in advance,
Cheers!

[Jaikiran Pai]

A no-interface view bean exposes only the public methods. The spec doesn't say anything about the fields. From the spec point of view, the example you showed is along expected lines.

Well, I guess it's because of the proxy object. Using business method, the container can intercept the method invocation and access the proper value. While accessing the field directly it cannot proxy such call and that's why it results in the default value. Is this correct?

Yes, it's related to the proxy and the interceptor chain (the internal details). When you invoke on the proxy, that's when the server decides which bean instance to pick or whether to create a new instance and inject the values and invoke the @PostConstruct and such. Unless that process takes place, the field value will not be set to the value that you have specified in your DD.

[Piotr Nowicki]

Thanks Jaikiran!

Ok, so when I use @EJB annotation, the container doesn't provide me by default with proxied object. It do that just upon business method invocation, right?

Well, ok it makes sense. The client EJB is not bound to any particular proxied-instance of NewSessionBean, but the invoked EJB (NewSessionBean) can be different with each business method call.

Right now I'm curious to what EJB am I getting while executing the field-access. I guess it must be some uninitialized EJB instance?

[Jaikiran Pai]

Pedro Kowalski wrote:
Right now I'm curious to what EJB am I getting while executing the field-access. I guess it must be some uninitialized EJB instance?

It's not yet an "EJB". You are getting a proxy (a subclass of the no-interface bean impl in this case) which is type safe to the bean impl class. It doesn't have any EJB semantics yet.

[Piotr Nowicki]

You're right, I used the inapropriate wording; by 'unitiniaialized EJB' I meant a class which hasn't yet been given an EJB nature.

Thanks for clarifying this out!