Tony,
Generally the PRO.narrow is used when casting to verify that the object
recieved is actually able to be casted to the type needed. One of the
rationals as I understand is that the PRO.narrow() can do typecasting of the
object whether it is marshalled as serialized Java class or a IDL type.
For instance take the following object
public final class Customer implements java.io.Serializable
{
public String _fname;
public String _lname;
}
Now this could be marshalled in one of two ways.
1) As a serialized Java class over an RMI type. This is likely how mosy
containers would marshall this like BEA. Basically my guess is this is why
PRO.narrow() is a no-op for BEA is that they always serialize so there is no
need for type casting
2) As an IDL type marshalled over IIOP. Since the object has no methods and
is final is can be mapped to an IDL struct type. This means when marshalled
there is MUCH less overhead as you do not need to serialize the instance
which is expensive.
One PRO.narrow()'s job is to handle these scenarios. This is why you may
see performance gains in those EJB containers with CORBA roots by avoiding
alot of unnecesary Java serialization.
Im not an RMI-IIOP expert but thats one reason this approach is consistant
with the goal of portability.
Dave Wolf
Internet Applications Division
Sybase
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Abbott
> Sent: Wednesday, September 06, 2000 5:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Entity Bean Parent/Child Relationships?
>
>
> Hi Jonathan,
>
> Hmm.. I'd never thought of using PRO.narrow there. Never seen
> anyone else do
> it either. Decided to do a little digging and it seems like the
> spec (1.1 at
> least) is not entirely clear on this matter. The examples in
> sections 8.3.1
> (calling create on home interface) and 8.3.2 (calling
> findByPrimaryKey) imply
> that it is not required, since it is explicitly used in the
> example of 8.2.1
> (acquiring the home interface) but not in the other two. The examples they
> use are:
>
> 8.2.1
> Context initialContext = new InitialContext();
> AccountHome accountHome = (AccountHome)
> javax.rmi.PortableRemoteObject.narrow(
> initialContext.lookup( java:comp/env/ejb/accounts ),
> AccountHome.class);
>
> 8.3.1
> AccountHome accountHome = ...;
> Account account = accountHome.create( John , Smith , 500.00);
>
> 8.3.2
> AccountHome = ...;
> Account account = accountHome.findByPrimaryKey( 100-3450-3333 );
>
> So to me, these examples seem to make the case against using
> PRO.narrow on the
> results of create/findBy*. In my mind this is quite logical,
> since these are
> references provided specifically by the container as EJB remote
> interfaces,
> whereas the result of lookup() is generic and thus required to be
> narrow()ed.
> Surely the container should obviate the need for using PRO.narrow on
> references that are specifically returned as EJB remote interfaces?
>
> BUT then in section 8.9 they go and say
>
> "A client program that is intended to be interoperable with all
> compliant EJB
> Container implementations must use the
> javax.rmi.PortableRemoteObject.narrow(...) method to perform
> type-narrowing of
> the client-side representations of the home and remote interface."
>
> contradicting their examples above.
>
> Anyone else have any insight into this? If I'm missing something
> obvious here
> please let me know!
>
> -t
>
>
>
>
>
>
> On Wed, Sep 06, 2000 at 01:51:48PM -0700, Jonathan K. Weedon wrote:
> > Tony Abbott wrote:
> > >
> > > findBy methods on the home interface should return either the
> remote interface
> > > or a Collection of remote interfaces. So just make
> findByParent return a
> > > collection of categories. So your code would look something like...
> > >
> > > InitialContext context = new InitialContext();
> > > Object obj = context.lookup("java:comp/env/ejb/Category");
> > > CategoryHome ch =
> (CategoryHome)PortableRemoteObject.narrow(obj, CategoryHome.class);
> > >
> > > Collection col = ch.findByParent("Furniture");
> > > Iterator i = col.iterator();
> > > while (i.hasNext())
> > > {
> > > Category cat = (Category)i.next();
> > > ... do stuff ...
> > > }
> > >
> > > -t
> >
> > Tony,
> >
> > In the above code, you neglected to use PRO.narrow for the narrowing of
> > the contents of the Iterator. It should be:
> >
> > Collection col = ch.findByParent("Furniture");
> > Iterator i = col.iterator();
> > while (i.hasNext()) {
> > Category cat = (Category) PortableRemoteObject.narrow
> > (i.next(), Category.class);
> >
> > }
> >
> > This is one of those insidious cases that I mentioned in a previous
> > thread, whereby your version of the code would work in some AppServers,
> > and not in others, even though (given your use of PRO.narrow for the
> > JNDI lookup) you probably thought you were writing portable code.
> >
> > -jkw
> >
> >
> ==================================================================
> =========
> > To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
> --
>
> Tony Abbott [EMAIL PROTECTED]
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
