This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Query related to No Interface View Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Query related to No Interface View" Watch "Query related to No Interface View" New topic
Author

Query related to No Interface View

Sagar Shroff
Ranch Hand

Joined: Jun 07, 2011
Posts: 208

Hello Ranchers ,
I was reading this snippet in spec

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.

I dint understood "..any interceptor methods are invoked as needed.".Can someone explain me why would i require an interceptor and an example of a scenario will be very helpful.

The Spec has also mentioned very similar quote

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

Please help me on both of this quotes in context to interceptors.


Also can some one explain why can i call only public methods through a no interface view otherwise EJBException.Why so the spec have made this as compulsion there must be some logic or reason behind which i am not aware ???


Regards,
Shroff.


OCJP-90%,OCPWCD-95%
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1662
    
  25

Hi Sagar,

Interceptors are explained later (Chapter 12 and its own spec: Interceptors 1.1). Just browse through my notes and you will find an example in chapter 4.

Why so the spec have made this as compulsion there must be some logic or reason behind which i am not aware ???

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.

Regards,
Frits
Sagar Shroff
Ranch Hand

Joined: Jun 07, 2011
Posts: 208

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.

Ok so even in a no interface view the container does generate an interface for us ! Now frits there are 2 questions bobbling in my mind .
I am definitely not knowing some concepts here.Please clarify if possible.
According to my understanding we use interface here to just give a coarse grained view to the client who uses our bean.
like for eg i create an EJB(with a remote view) bean which has a business method which says " HELLO " . Now in order for the client to know how to invoke our business function
or to get info about our business methods we give them a remote interface,so that they can use it an accordingly invoke it.This is what i have an understanding of why we require remote business interface.
(Please correct me if i have got wrong somewhere).

Now in scenario with local bean my understanding of why we require a no-interface view is that mostly my local bean is invoked by some other bean in my app or by some other web component in my application
so since here there is no client involved as such, there is no compulsion for the programmer to provide an interface.(Is my understanding correct ???)
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 ???

Regards Shroff.
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1662
    
  25

Hi Sagar,

Good questions!

1)So now my question is then why does the container provides one and for what reason ?

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.
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.

Regards,
Frits
Sagar Shroff
Ranch Hand

Joined: Jun 07, 2011
Posts: 208

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.

Yes that may be one of the reasons !
Thanks

Regards,
Sagar
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10067
    
163

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.


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.

[My Blog] [JavaRanch Journal]
Sagar Shroff
Ranch Hand

Joined: Jun 07, 2011
Posts: 208

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.


Whoa had no idea about it !
Regards Shroff.
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1662
    
  25

Thanks for explaining: it all makes sense and sound logical!

Regards,
Frits
Sagar Shroff
Ranch Hand

Joined: Jun 07, 2011
Posts: 208

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.


I have one doubt on what Jaikiran said.So if we say that the generated proxy is a subclass of the target class then , so when i lookup i get a proxy object which is extending the target class ...ohkie now
Lets Assume the target class name is LocalBeanClass

So when we do lookup , we can do this :
1) LocalBeanClass ref= // lookup code ;

we can even do this (assume LocalBeanParentClass is a parent class of LocalBeanClass)
2) LocalBeanParentClass ref = // lookup code ;

but we cannot do this (assume LocalBeanSubClass is a sub class of LocalBeanClass)
3) LocalBeanSubClass ref = (LocalBeanSubClass) //lookup code ;
we cannot downcast because when we do lookup we get proxy and that proxy cannot be casted to a class which has no relation with it.

So dont you think so that proxy being a Subclass of the target class , will never allows me to use the concept of polymorphism ,

Regards,
Shroff
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1662
    
  25

Hi Sagar,

With EJB's there are some restrictions anyway:

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.

Regards,
Frits
Sagar Shroff
Ranch Hand

Joined: Jun 07, 2011
Posts: 208

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.


I got your point that even though B is a Foo , we still cannot access it through Foo because the Foo that we use is a Container created interface a proxy . Please correct me if i have got wrong .

Regards,
Shroff
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Query related to No Interface View