>1. The specification makes a distinction between component inheritance,
>implementation inheritance, and interface inheritance. None of these
>three terms is well defined in the specification. Nevertheless, the
>specification permits the latter two (see page 290). What kind of
>inheritance is the kind you list above, and is your interpretation in
>keeping with the specification?
The spec is at best vague on inheritance IMO. It claims it can
be done but doesn't give you a clue how to.
The way I see it (probably wrongly but I have empirical proof!),
you can do all three except when dealing with Home interfaces:
1)You can do Remote interface inheritance (Interface inheritance)
2)You can do bean inheritance (Implementation inheritance)
3)1 + 2 together give you Component inheritance
Once you create your client EJBObject proxy (using unique Home
interfaces for each bean), normal Java inheritance rules begin.
On the container side, implementation inheritance ensures your
method invocations are forwarded to correct bean instance.
>2. Suppose I am able to solve the problem you state above (out of band,
>i.e. with my own classes). Is that the only issue with respect to
>various kinds of inheritance in EJB? I personally cannot think of any
>others (other than implementation-type issues, such as lazy- versus
>eager-loading of complex object graphs).
I'll have to pass on this one. Come to think of it though,
why not have a factory object that creates client proxies
given a JNDI name and class.
>I *know* this has been beaten to death in the archives
Apparently not.
Hamid
===========================================================================
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".
