• Post Reply Bookmark Topic Watch Topic
  • New Topic

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

 
Piotr Nowicki
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy Ranchers!

I've defined a environment resource with default value using annotations:
in DD I've defined it's value in the following way:
In another EJB I'm accessing the NewSessionBean as follows:

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:
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
Sheriff
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!