>I am sorry I misread your question. I guess that analogy would be:
>why don't all Java classes have the same constructor?
>
I don't really see the analogy. I think it make sense at times for the
return type to be a superclass of the object you are returning esp when java
doesn't let you override a method with a different return type even when the
return type is a subclass. I do see all the advantages of a typed language
(verses smalltalk) but at times it forces developers to use reflection and
at time that makes the programmer take the easy non OO route.
Anyway I think you know better and this probably isn't the place for this
discussion.
>I hope that this will not stop you from using EJB to build your
application.
>
Not at all. We are committed to using EJBs.
>Regards,
>
>Vlada
>
>-----Original Message-----
>From: Sachin Aggarwal <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Date: Friday, March 26, 1999 8:29 PM
>Subject: Re: having same return type for ejbCreate and find( was RE:
findByPrimaryKey )
>
>
>>> 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".
>>
>>
>
>===========================================================================
>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".
