> First of all, a generic return type of create/find could not be
> EntityBean.
> If a generic type were used, it would have to be EJBObject.
>
> We decided to use the application-specific signature for 2 reasons:
>
> - The application does not have to use the ugly
> PortableRemoteObject.narrow
> type conversion; the code looks simple without the type conversion.
>
> - The PortableRemoteObject.narrow conversion may yield a round-trip
> to the server on some implementations of RMI/IIOP.
>
> What don't you use code generation in your product? Most commercial
> products do.
I'm a bean developer and not a EJB server vendor. But looks like there were
some technical reasons beyond my comprehension and I'll take your reasons as
good reasons though it makes the sever side java developer's job a little
difficult. :-)
>
> Vlada
>
> -----Original Message-----
> From: Sachin Aggarwal <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Friday, March 26, 1999 6:50 PM
> Subject: having same return type for ejbCreate and find( was RE:
> findByPrimaryKey )
>
>
> >This is a good time for me to ask why do the spec authors
> require the return
> >type to be the bean class.
> >
> >I ran into this problem with create method on home. I needed an
> adapter on
> >the client , wanted to use polymorphism to provide a method
> >createEntity(String entityname) and I was *forced* to use reflection to
> >execute the createMethod().
> >
> >Why don't we have the return type as EntityBean . I know that would mean
> >more casting but I would think that as better than using reflection when
> >implementing polymorphism or end up discouraging polymorphism.
> >
> >Same applies for the finder method .
> >
> >I think I'm missing something but can't figure it out.
> >
> >
> >p.s Actually I would have the same question for java experts -
> why not have
> >a overridding method have a different return type as long as
> it's subclass
> >of the return type of the overridden method.
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: A mailing list for Enterprise JavaBeans development
> >> [mailto:[EMAIL PROTECTED]]On Behalf Of Vlada Matena
> >> Sent: Friday, March 26, 1999 8:00 AM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: findByPrimaryKey
> >>
> >>
> >> We want the signature of the findByPrimaryKey to have the exact types
> >> for the input argument and the return value. This makes it
> impossible to
> >> include the method in the home interface because each enterprise bean
> >> needs a different signature.
> >>
> >> Vlada
> >>
> >> -----Original Message-----
> >> From: Saurabh Sahai <[EMAIL PROTECTED]>
> >> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> >> Date: Thursday, March 25, 1999 10:03 PM
> >> Subject: Re: findByPrimaryKey
> >>
> >>
> >> >Thanks Vlada.
> >> >
> >> >>Yes, the home interface of every entity bean must have the
> >> >>findByPrimaryKey method, and every entity class with bean
> >> >>managed persistence must define the ejbFindByPrimaryKey
> >> >>method.
> >> >>
> >> >>The implementation of the ejbFindByPrimaryKey should verify
> >> >>that the entity with the given primary key exists.
> >> >>
> >> >
> >> >
> >> >That is precisely what my point is. If every BMP entity bean has
> >> to have an
> >> >ejbFindByPrimaryKey method, should'nt this be a method on the
> EntityBean
> >> >interface. (Maybe we need a BMPEntityBean class).
> >> >
> >> >I am saying this because from a container's point, even though
> >> the container
> >> >knows that it is dealing with a BMP entity bean, it cannot do
> >> something like
> >> >:
> >> >
> >> > EntityBean bean;
> >> > .........
> >> > bean.ejbFindByPrimaryKey(...)
> >> >
> >> >It will need to use reflection to get the find method and invoke it.
> >> >
> >> >Thanks.
> >> >
> >> >-Saurabh
> >> >
> >> >=================================================================
> >> ==========
> >> >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".
> >>
> >>
> >
> >=================================================================
> ==========
> >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".
>
>
===========================================================================
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".
