Tony Abbott wrote:
>
> Hi Jonathan, Dave
>
> I understand that PRO.narrow is required when casting a (potentially) remote
> object reference to cater for using IIOP as the underlying protocol. What I'm
> struggling with right now is the requirement of using it on the result of a
> multi-object find.
Actually it isn't necessarily required even when using IIOP, if
your JNDI provider has a bit of intelligence. The fact of the matter
is that the EJB spec requires its use, so some vendors also require
its use (for implementation convenience or to force the client
developer to write spec-compliant code), thereby if you don't use it
your code won't be portable.
> The java typecast used in this case is required purely because a Collection
> is not typed. The type of the returned objects is fixed (by contract) to be
> an entity object reference of a specific type, that of the bean who's home
> interface you are calling findXXX on. I fail to see the difference between
> that and the reference returned by a single-object finder. If the returned
> Collection was typed (say java supported templates ala C++) there would be
> no need for the java cast. Would PRO.narrow be required then and if so, why?
Obviously in that case it would not be necessary, but since Java has no
parameterized types it is of hypothetical value only.
> -t
>
> On Wed, Sep 06, 2000 at 04:47:26PM -0700, Jonathan K. Weedon wrote:
> > Tony,
> >
> > The basic rule of thumb is that a PRO.narrow is needed wherever
> > a Java cast is needed. Elsewhere, it is not needed.
> >
> > Specifically, a PRO.narrow IS NOT needed for:
> >
> > * create methods
> > * single object finders (including findByPrimaryKey)
> >
> > (and you will note a Java cast is also not required).
> >
> > However, a PRO.narrow is needed for:
> >
> > * JNDI lookups,
> > * multi-object finders (including your findByParent)
> >
> > (and you will note that a Java cast is required).
> >
> > The spec is completly consistent on this matter.
> >
> > -jkw
> >
> > Tony Abbott wrote:
> > >
> > > 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".
> >
>
> --
>
> 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".
--
________________________________________________________________________________
Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===========================================================================
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".
