Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Dynamic casting of Home interface  RSS feed

 
Kanu Dialani
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Suppose if I have 10 session Beans. From my client application there are different modules that access these beans. I want to write a connection class which has a generic method that will return the Home interface. Now i want this method to return me the Home interface according to the parameters at runtime.

Suppose ....

com.MySessionHome intf = (com.MySessionHome) PortableRemoteObject
.narrow(o, com.MySessionHome.class);


Now can i have a Super Interface that extends the EJBObject and have my 10 different Home interfaces extend this Super Interface ....

so that the above line of code may look somewhat like this


SUPERINTERFACE intf = (SUPERINTERFACE) PortableRemoteObject
.narrow(o, com.MySessionHome.class);

IS something of this kind possible ? If yes please guide me

Thanx in advance
 
Ådne Brunborg
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you do the "lookup, narrow and cast" you get the Home interface of the bean, distinct to THAT bean. And you cannot cast that Home to the home of a different Bean.

But you CAN make logic for that bean to lookup another bean, based on the incoming request, something like this:

- each different thing the client wants to do, has it's own request object, all rq-objects extends RequestObject
- you make a Facade-bean, with one business method, doStuff(RequestObject rq), exposed Remote
- the Facade then looks up other EJBs as needed, these have only Locally exposed methods:


would that solve your problem?
[ March 21, 2006: Message edited by: �dne Brunborg ]
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kanu Dialani:

SUPERINTERFACE intf = (SUPERINTERFACE) PortableRemoteObject
.narrow(o, com.MySessionHome.class);


Hi,

a slightly different version might might strip off one formal handicap:

but as far as I remember a Home interface is not allowed to inherit any interface like your business interface SUPERINTERFACE, so I would suspect it not to work.

Thomas
 
Ådne Brunborg
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Thomas Taeger:

but as far as I remember a Home interface is not allowed to inherit any interface like your business interface SUPERINTERFACE, so I would suspect it not to work.

Thomas


The spec says the Home "must extend EJBHome". So if you have "SUPERINTERFACE extends javax.ejb.EJBHome", you can have "MySessionHome extends SUPERINTERFACE" and keep with the contract. But, if you instanciate your beans as SUPERINTERFACE, you can only access SUPERINTERFACE methods. Which means, all beans would appear identical to the client. But the client would still have to lookup and narrow each bean type, so I fail to see any reason why you'd want to do this.

Or, if you have "MySessionHome extends javax.ejb.EJBHome, SUPERINTERFACE" you would not be able to use the instanciated object for anything EJB-related at all. You would get an object which refers to the Home of your bean (since you do a lookup), cast it to somehting not EJB-related, and are stuck with an unspecified object which implements your SUPERINTERFACE but cannot be used for anything different. And you'd STILL have to do lookup on a specific bean...
 
Kanu Dialani
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanx a lot Thomas, for your interest. Your code was helpful. Actually when i posted this msg on the forum i had not tried coding the interfaces. But after reading ur reply i ve tried with having a superInterface for both the Home as well as the Remote interfaces and it worked. I ve just tried it with 1 session bean. But i think it should not create any problems with multiple beans. This is not any requirement but just my curiosity. But i think when developing an application which involves many beans , this type of a design can be helpful.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!