3.4.4Session Bean’s No-Interface View
The container provides an implementation of a reference to a no-interface view such that when the client invokes a method on the reference, the business method on the session bean instance and any interceptor methods are invoked as needed.
3.4.3Session Bean’s Business Interface
The container provides an implementation of a session bean’s business interface such that when the client invokes a method on the instance of the business interface, the business method on the session bean instance and any interceptor methods are invoked as needed
OCJP-90%,OCPWCD-95%
Why so the spec have made this as compulsion there must be some logic or reason behind which i am not aware ???
Frits Walraven wrote:Hi Sagar,
When you don't specify an interface, the EJB container will generate the specific business interface for you. No interface view is just a convenience way (less coding for the developer) of working with EJB's, but in the end it will just be the same as an EJB with a Business interface.
OCJP-90%,OCPWCD-95%
1)So now my question is then why does the container provides one and for what reason ?
2)And if it does provide one then when i do lookup the reference of the class that i get , i assume that type must be implementing the interface which is internally created by the container ???
Frits Walraven wrote:Hi Sagar,
Well there is no requirement stating that the container should create an interface (and I guess you are right, strictly you don't need one), but it seems logical to me as the proxy-object (the one with the added features like transactions etc.) has to implement the same methods. An interface decouples things. I guess that is also why only the public methods are exposed.
OCJP-90%,OCPWCD-95%
Frits Walraven wrote:
2)And if it does provide one then when i do lookup the reference of the class that i get , i assume that type must be implementing the interface which is internally created by the container ???
Yes, the proxy object (the one being referenced) will then implement the generated interface. But then again I am not a EJB container developer so I am not sure however it seems logical to me.
Jaikiran Pai wrote:
The spec requires that the generated proxy for the no interface view be type compatible with the bean implementation class which is marked for the no interface view. Proxy generating frameworks allow generating proxies as sub classes of the target class. So in case of no interface view, the proxy that is generated is typically a sub class of the bean implementation class.
OCJP-90%,OCPWCD-95%
Jaikiran Pai wrote:
The spec requires that the generated proxy for the no interface view be type compatible with the bean implementation class which is marked for the no interface view. Proxy generating frameworks allow generating proxies as sub classes of the target class. So in case of no interface view, the proxy that is generated is typically a sub class of the bean implementation class.
OCJP-90%,OCPWCD-95%
4.9.2.1 Session Bean Superclasses
As an example, the client views exposed by a particular session bean are not inherited by a subclass that also happens to define a session bean.
@Stateless
public class A implements Foo { ... }
@Stateless
public class B extends A implements Bar { ... }
Assuming Foo and Bar are local business interfaces and there is no associated deployment descriptor, session bean A exposes local business interface Foo and session bean B exposes local business interface Bar, but not Foo.
Frits Walraven wrote:
Assuming Foo and Bar are local business interfaces and there is no associated deployment descriptor, session bean A exposes local business interface Foo and session bean B exposes local business interface Bar, but not Foo.
OCJP-90%,OCPWCD-95%
Consider Paul's rocket mass heater. |