Narrow method in CORBA?

what is the function of narrow method? and when do i need to use it?

It is the CORBA way to downcast an object.

Similar Messages

PortableRemoteObject.narrow() method

Hi,
I usually use this method in case of looking for some remote home interface. But recently I found some EJB examples, where an author ommited the PortableRemoteObject.narrow method. Actually the source code was generated by Lomboz.
This unusual procedure made me to prepare some tests. I made some EJB bean and its interfaces, after that I made a little change inside on one cpy of home interface, that this one was out of date. In the end I generated appropriate client in two ways:
- using PortableRemoteObject.narrow method
- unusing PortableRemoteObject.narrow method
The results, when I used PortableRemoteObject.narrow method and when I unused it is similar, both resposed by java.lang.ClassCastException
The small difference was, in order to use PortableRemoteObject.narrow method I got:
at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(Unknown Source)
at javax.rmi.PortableRemoteObject.narrow(Unknown Source)
Ommiting this method I got only;
java.lang.ClassCastException: $Proxy0
Well, in both ways I observed the same final exception:
java.lang.ClassCastException, which good explains what happend wrong. What really is better to use PortableRemoteObject.narrow method based on my above experiences?
Thank for some suggestions
Krzysztof

You need to do the .narrow() method on anything that comes across RMI. The reason is that you have no guarantee that the thing coming across RMI is a Java object. It's possible to send something other than a Java object.
If your client is using a local interface instead of a remote interface, the narrow() is not required.

What is returned by narrow method?

Hi,
Following java code is part of the idlj-generated HelloHelper class. What is returned, When we called narrow() method in the client application code? It is stub or HelloApp.Hello object?
************** HelloHelper class *************************
public static HelloApp.Hello narrow (org.omg.CORBA.Object obj){
if (obj == null)
return null;
else if (obj instanceof HelloApp.Hello)
return (HelloApp.Hello)obj;
else if (!obj._is_a (id ()))
throw new org.omg.CORBA.BAD_PARAM ();
else{
org.omg.CORBA.portable.Delegate delegate = ((org.omg.CORBA.portable.ObjectImpl)obj)._get_delegate ();
HelloApp._HelloStub stub = new HelloApp._HelloStub ();
stub._set_delegate(delegate);
return stub;
*********in the server application code****************
HelloImpl helloImpl = new HelloImpl();
org.omg.CORBA.Object ref = rootpoa.servant_to_reference(helloImpl);Hello href = HelloHelper.narrow(ref);
String name = "Hello";NameComponent[] path = ncRef.to_name(name);ncRef.rebind(path, href);
*********in the client application code****************
static Hello hello;
hello = HelloHelper.narrow(ncRef.resolve_str(name));
Sincerely...

Both. If the object is already a stub it returns it, otherwise it forms a stub from the object (presumably an IOR or the remote object itself) and returns it. In either case the stub is an instance of HelloApp.Hello which I would guess is a remote interface.

Confusion in PortableRemoteObject.narrow() method

In EJB 1.0 reference of home object is obtained through external casting as HelloHome home = (HelloHome)ctx.lookup("HelloHome")
My question is that since IIOP has not been designed for Java, but for generic languages, and this means that there are some limitations. Some languages, in fact, do not have the concept of casting.
Still why we have to cast the Object if we use PortableRemoteObject.narrow method for obtaining the home interface reference in EJB2.0.
HelloHome home = (HelloHome)javax.rmi.PortableRemoteObject.narrow(object, HelloHome.class)

If the client is built using Java, you can not explicitly cast from the Naming.lookup() function. Instead, you must use lookup() to return a generic java.lang.Object, and then cast to the specific object type with the PortableRemoteObject.Narrow(objectReference, interfaceName) method.

Difference between narrow() method usage and simple class cast for EJB

Hi,
I have a very simple question:
what is the difference between PortableRemoteObject.narrow(fromObj,
toClass) method usage and simple class cast for EJB.
For example,
1)
EJBObject ejbObj;
// somewhere in the code the home.create() called for bean ...
ABean a = (ABean)PortableRemoteObject.narrow(ejbObj,ABean.class);
OR
2)
EJBObject bean;
// somewhere in the code the home.create() called for bean ...
ABean a = (ABean)ejbObj;
Which one is better?
P.S. I'm working with WL 6.1 sp2
Any help would be appreciated.
Thanks in advance,
Orly

[email protected] (Orly) writes:
Hi,
I have a very simple question:
what is the difference between PortableRemoteObject.narrow(fromObj,
toClass) method usage and simple class cast for EJB.
For example,
1)
EJBObject ejbObj;
// somewhere in the code the home.create() called for bean ...
ABean a = (ABean)PortableRemoteObject.narrow(ejbObj,ABean.class);
OR
2)
EJBObject bean;
// somewhere in the code the home.create() called for bean ...
ABean a = (ABean)ejbObj;
Which one is better?(1) is mandated by the spec. It is required because CORBA systems may
not have sufficient type information available to do a simple case.
P.S. I'm working with WL 6.1 sp2 You should always use PRO.narrow()
andy

EJB P.R.O.narrow method returns a null reference though object is valid

All,
I'm trying to deploy a simple stateless session bean to SUN server. The client code keeps failing because PortableRemoteObject.narrow returns null, even though the reference is located in JNDI tree.
I read somewhere that turning on RMI stub generation might help, but it didn't do it in my case.
This is a local server (SUN App Server, as downloaded from java.sun site).
JNDI tree contains the following entries:
UserTransaction
test.Dummy
jdbc
ejb
test.Server
Neither test.Dummy nor test.Server (the beans I deployed) want to load.
Any help would be appreciated.
Thanks!
Mark

Never mind. For some reason changing initial context creation from:
Properties p=new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY,"whatever factory");
p.put(Context.PROVIDER_URL,"whatever url");
InitialContext context=new InitialContext(p);
to:
InitialContext context=new InitialContext();
fixed the problem. Which is strange, since JNDI tree was listing both objects, and they both could be resolved when using the first code snippet. Only the actual object creation was failing.
If anyone knows why this is so, please explain.
Cheers,
Mark

ClassCastException at narrow (Servlet/EJB)

Hi
I am new to this EJB concept.
I try to use an EJB in a servlet but I have a ClassCastException thrown by the narrow method.
I've already looked through the forums , but I haven't seen a solution for me.
I use JBOSS-3.0.8 and TOMCAT-4.0.1.
I include the client jar file generated by the deploytool in my client classpath.
Here is the part of the servlet calling the EJB:
Properties props= new Properties();
props.put(Context.PROVIDER_URL, "jnp://localhost:1099");
props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
try {
Context jndiContext = new InitialContext(props);
System.out.println("Lookup");
Object object = jndiContext.lookup("ejb/eltUtil");
System.out.println("Object =>" + object.getClass()+"<=");
System.out.println("Object =>" + object.toString()+"<=");
System.out.println("PortableRemoteObject");
UtilHome lUtilHome = (UtilHome)PortableRemoteObject.narrow(object,UtilHome.class);
Here is the result in the jsp page:
java.lang.ClassCastException
     at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:296)
     at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
     at fr.gouv.defense.cimd.authentification.servlet.ServletListeUtil.doGet(ServletListeUtil.java:87)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1011)
     at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106)
     at java.lang.Thread.run(Thread.java:484)
And the log message in Tomcat:
Lookup
Object =>class org.jnp.interfaces.MarshalledValuePair<=
Object =>org.jnp.interfaces.MarshalledValuePair@53cdaa<=
PortableRemoteObject
When I run the code in a Client interface in Eclipse, that works and the log is :
Lookup
Objet =>class $Proxy0
Objet =>ejb/eltUtilHome
PortableRemoteObject
I don't know what to do.
Does anybody got the answer?
Thanks.

even if isAssignableFrom returns false, still it can work.....
here is how
Object notificationServiceObject = initialContext.lookup(NotificationServiceHome.JNDI_NAME);
//Key Step
Object notificationServiceRawObject = ((org.jnp.interfaces.MarshalledValuePair)
notificationServiceObject).get();
NotificationServiceHome notificationServiceHome =
          (NotificationServiceHome)javax.rmi.PortableRemoteObject.narrow
(notificationServiceRawObject,NotificationServiceHome.class);
NotificationService notificationService = notificationServiceHome.create();

Unnecessary narrowing

Hello,
I [more than once] stumbled accross code such as:
Object homeRef = namingcontext.lookup("some.jndi.path.for.XxxHome");
XxxHome xHome = (XxxHome)javax.rmi.PortableRemoteObject.narrow(homeRef, XxxHome.class);
Xxx remoteRef = (Xxx)javax.rmi.PortableRemoteObject.narrow(xHome.create(), Xxx.class);The second cast and narrowing seem unnecessary to me. I think it's an overlooking from the developper's part which switched from Java to J2EE recently.
But as I am recent myself to J2EE, I have still a doubt : is there any reason why one would want to do this?

jduprez,
Both casting and narrowing are necessary... coz of the following points,
1. When u narrow a home object it is enabling the object to function under the Distributed environment.. not acutally down casting the object... the down casting happens by the standard java casting code that we usally write.
In fact i have noticed in Weblogic 8.1 that u can downcast the home object and start using it with out running the object through the narrow method. What weblogic does does in this case is i GUESS is it switches off the distributed functionality of the object.
This Concept is clearly explained in the book Mastering Enterprise Java Beans Edit II by Ed Roman. In the Corba Appendix chapter u may want to read it to totally understand why one has to run the home object through narrow method and as well as down cast.
Hope i could clear you curiousity.
Cheers,
Max

Java Corba Problem

Hi,
I have a strange Java Client Server application with a corba interface between the two.
There are three Session Classes that describe this interface.
The base session is SessionA. Extending that (i.e. :: in IDL) is SessionB and extending that is SessionC.
The client is broken up into two parts which run in the same JVM. The first part has a dependency to SessionC and the second part has a dependency SessionB. It has to be this way.
Upon start up the client creates a SessionC everything okay. The client then launches part of the application which only has a dependency to SessionB. To launch this part of the client application a SessionB object must be past. To do this I use the SessionBHelper class and the narrow method.
Everything works fine no exceptions are thrown.
Now here is the part that is killing me - when I invoke a method then from the Client to SessionB it throws a Marshalling exception
org.omg.CORBA.MARSHAL: minor code: 0 completed: No. I check the spec. and there is minor code 0 has a default meaning - i.e. nothing. I have n't a clue what is wrong.
My only thoughts are that narrow can only be used in down casting. But I could be wrong here.
I would really appreciate any help or thoughts. Thanks in Advance.

When ever I come across the most lovely Marshalling exceptions... its usually because my skel/stub classes out of synch with each other (on the client/server)
When I update the everyone... I usually have everything working and playing nicely.
This occurs with some frequency using Websphere EJB (using IIOP)... if your client JAR's are not in synch with your server JAR's... then the objects can't be marshalled... its a pain
./dave

PortableRemoteObject.narrow

Why is it necessary to use and cast the result of this method call, which appears to return the same object as was passed as the first argument? In other words, why do this:
Object myObj = ctx.lookup(MYHOME);
MyHome myHome = (MyHome)
PortableRemoteObject.narrow(myObj, MyHome.class);
MyEjb myEjb = myHome.create();
-in code that must know each EJB, when you can do this:
//In a generic HomeFactory class
Object myObj = ctx.lookup(MYHOME);
Class beanHome = Class.forName(MYHOME);
PortableRemoteObject.narrow(myObj, beanHome);
return myObj
//In some other class
MyHome myHome = (MyHome) HomeFactory.getHome(MYHOME);
MyEjb = myHome.create();
I left out the try-catch blocks and all of that for compactness. The reason I ask is because a generic Home Factory can store EJBHome objects in a collection, testing them first and returning them without creating the actual remote reference, so it does not need to know the specific EJB, allowing the specific client code to cast the generic Object to the specific EJBHome object.
A Sun-certified instructor once told me that it was absolutely necessary to use the Object returned from the narrow method because it performed some essential RMI activity on the object, but I have never had a problem using it the second way I describe above in the HomeFactory. Also, I have never been able to find any documentation to substantiate his claim. Any thoughts as to the necessity of using the object returned from the narrow method? It appears to be the exact same object that is passed in to the method, and likely un-changed at that.

The narrow method is there to allow an implementation to do some extra work or return a different object if it needs to. It appears that your implementation does not need to do these things so it just returns the object that was passed. If you take your shortcut, you will limit yourself to running only on your current implementation. If you try to switch implementations or even upgrade to a later version it might break. If you follow the correct method the your code will be portable.

How to determine IP address of client request in CORBA

Hello
does anyone know of a way to determine which peer is making the invocation of a method in CORBA?
I need to find a way to determine the IP address of the calling peer, but at the server-side and NOT by passing the IP address as an argument with a method invocation like the following method:
void foo(in string ipAddress);
The above method declaration is in the .idl file.
Thank you in advance

There's no portable way to do this and I don't know if / how it's possible with the Sun ORB (the one available in the J2SE).
It is possible with the latest versions of JacORB (www.jacorb.org) - a free LGPL Java ORB. The feature is undocumented (as yet) but if you can decompose unit test code you can see how it works in the code in this directory:
http://www.jacorb.org/cgi-bin/cvsweb/JacORB/test/regression/src/org/jacorb/test/transport/

Why use PortableRemoteObject.narrow() ?

hi!
I am new to RMI-IIOP. Can somebody explain why we need to use the narrow method to type cast object refs in RMI-IIOP while in RMI, we just need to use a casting operator?
TIA,
Mani

See http://info.borland.com/devsupport/appserver/faq/45/ejb/portable_remote_object.html
--Mark Johnson

Why PortableRemoteObject.narrow()

Hello,
Can any one please suggest me the difference in looking Up of the components in 2 ways..??
1) HelloHome home = (HelloHome)ctx.lookup("HelloHome")
2) Object ref = getInitialContext().lookup(eb/HelloBean);
HelloHome home = (HelloHome)javax.rmi.PortableRemoteObject.narrow(ref, HelloHome.class)
Why we need option 2 when we get a home object when we make a look up as in 1.
why PortableRemoteObject.narrow()
Please make ur suggestions.
Thanks.

Hi,
From an article at http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/ejb-tier/ejb-tier9.html
Type narrowing is needed because many application servers use RMI-IIOP as the communication protocol to access remote beans. However, some application servers do not use RMI-IIOP and hence allow the use of Java language typecasts as well. For portability you cannot rely on an application server allowing Java language typecasts; you should always use the PortableRemoteObject.narrow method. The overhead on this method call is usually quite small
-Amol

Exception: Cannot narrow remote object to ...

Hi,
          in certain circumstances I get an Exception "Cannot narrow remote
          object to <some EJB-Home-Class>".
          My enviroment: weblogic 7.0, solaris, Java 1.3.1, J2EE-application
          (EJBs, Servlets, Database)
          In the init method of an start-up servlet I spawn some threads for a
          scheduler of the application. There are a scheduler core and some
          worker classes.
          The start-up servlet, all the other servlets and the schedulers
          classes are in an web-archive (war-file) in an ear-archiv. Furthermore
          there a some 3rd party archives in the ear-archive, a jndi.properties
          file etc. The manifest file of the war-archive contains a class-path,
          points to the 3rd party archives in the ear-archive.
          The schedulers workers code is simple:
          InitialContext jndiContext = ...getInitialContext();
          Object obj = jndiContext.lookup(<some EJB>);
          - EJBs home interface (for example):
          SyncOrderQueueHome home = (SyncOrderQueueHome)
          javax.rmi.PortableRemoteObject.narrow(obj,
          SyncOrderQueueHome.class);
          - EJBs remote interface:SyncOrderQueue sync = home.create();
          - call some business method
          sync.createOrderQueue();
          In the enviroment described above I get an " Exception: Cannot narrow
          remote object to <package>.SyncOrderQueueHome".
          On the other hand the scheduler and all the workers work fine as a
          standalone application (not in an app-server context) and in Oracles
          app-server (OC4J, v.9.0.3).
          I tried to understand, what for an object I get as the result of the
          JNDI lookup bevore the narrow method fails:
          - in the app-servers context:
          <package>.SyncOrderQueueEJB_4o6qkf_HomeImpl
          - outside the app-server:
          <package>.SyncOrderQueueEJB_4o6qkf_HomeImpl_WLStub
          What happened here? The common servlets use the same functionality and
          work fine. Why I get different objects? Where is the bug?
          Any ideas?
          Thomas


I believe the problem is the threads you are starting are not using the
          context classloader of the current thread.
          -- Rob
          [email protected] wrote:
          > Hi,
          >
          > in certain circumstances I get an Exception "Cannot narrow remote
          > object to <some EJB-Home-Class>".
          >
          > My enviroment: weblogic 7.0, solaris, Java 1.3.1, J2EE-application
          > (EJBs, Servlets, Database)
          >
          > In the init method of an start-up servlet I spawn some threads for a
          > scheduler of the application. There are a scheduler core and some
          > worker classes.
          > The start-up servlet, all the other servlets and the schedulers
          > classes are in an web-archive (war-file) in an ear-archiv. Furthermore
          > there a some 3rd party archives in the ear-archive, a jndi.properties
          > file etc. The manifest file of the war-archive contains a class-path,
          > points to the 3rd party archives in the ear-archive.
          >
          > The schedulers workers code is simple:
          >
          > InitialContext jndiContext = ...getInitialContext();
          > Object obj = jndiContext.lookup(<some EJB>);
          >
          > - EJBs home interface (for example):
          > SyncOrderQueueHome home = (SyncOrderQueueHome)
          > javax.rmi.PortableRemoteObject.narrow(obj,
          > SyncOrderQueueHome.class);
          >
          > - EJBs remote interface:SyncOrderQueue sync = home.create();
          >
          > - call some business method
          > sync.createOrderQueue();
          > In the enviroment described above I get an " Exception: Cannot narrow
          > remote object to <package>.SyncOrderQueueHome".
          >
          > On the other hand the scheduler and all the workers work fine as a
          > standalone application (not in an app-server context) and in Oracles
          > app-server (OC4J, v.9.0.3).
          >
          > I tried to understand, what for an object I get as the result of the
          > JNDI lookup bevore the narrow method fails:
          > - in the app-servers context:
          > <package>.SyncOrderQueueEJB_4o6qkf_HomeImpl
          > - outside the app-server:
          > <package>.SyncOrderQueueEJB_4o6qkf_HomeImpl_WLStub
          >
          > What happened here? The common servlets use the same functionality and
          > work fine. Why I get different objects? Where is the bug?
          >
          > Any ideas?
          > Thomas

Array Type in CORBA

Hi,
I'm trying to use a method in CORBA Idl which uses
an array as in parameter. When I'm trying to call this
method by passing a properly initialized array from my
java program, I'm getting a nullPointerException in Java. The following is the scenario...
dbCorbaInterface.idl
=====================
module dbCorbaInterface{
struct Product{
string id;
string name;
typedef sequence<Product, 20> ProductList;
interface DBInterface{
boolean insertOrder(in ProductList prList);
DBInterfaceImpl.java
=====================
public class DBInterfaceImpl extends _DBInterfaceImplBase{
boolean insertOrder(Product [] prList){
Client.java
============
Product [] prList = new Product[20];
for(int i = 0; i <20; i++){
prList = new Product();
//Initialize the elements of the product array
prList.id = i;
prList.name = "";
//Assume there is an obj of DBInterface named DBI
DBI.InsertOrder(prList); // => Gives nullPointerException.
Can anyone help to solve this issue?
Rgds,
Jai

Hi,
I'd look on DBI interface initialization. You're getting nullPointerException because it's REALLY null.

Narrow method in CORBA?

Similar Messages

Maybe you are looking for