• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Query related to No Interface View

 
Ranch Hand
Posts: 211
Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Creator of Enthuware JWS+ V6
Posts: 3411
320
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 211
Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3411
320
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 211
Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Sagar Shroff
Ranch Hand
Posts: 211
Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3411
320
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for explaining: it all makes sense and sound logical!

Regards,
Frits
 
Sagar Shroff
Ranch Hand
Posts: 211
Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3411
320
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 211
Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic