Do you mean for the client to call A.ejbCreate() to return the B, or do you
mean to create an A and then call some other method, like A.createNewB()
which happens to return a B.  That might be more reasonable, though I am
still afraid this stuff is highly dependent on the app server implementation
of the client side stubs.

Another possibility would be to make use of something like the strategy
pattern where you always create the same type of EJB, but it delegates
processing of certain methods to an embedded object which is created based
upon a parameter in the create method.  This gets you out of any odd stuff
with the interfaces and casting.  It probably requires the bean to be a BMP
bean since the strategy object is sort of a dependent object, but a BMP bean
might be easier to understand.

Cheers
Jay Walters
NetNumina Solutions

-----Original Message-----
From: Sacha Labourey [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 10, 2001 7:06 PM
To: [EMAIL PROTECTED]
Subject: Re: Multiple implementations of the same remote interface


Hello Cedric,

> > If I well understand your point :
> >         - specify in Bill.create(...) the paiement process type as a
> > parameter (an enum class for example)
> >         - in my BillBean.ejbCreate, also create a BillPaiementProcess
> > EJB object of the right class (determined thanks to the parameter)
>
> Yes.
>
> >         - from my client code get my BillPaiementProcess EJB object
> > from the newly created Bill
> >         - adjust properties and call method, from the client, on the
> > BillPaiementProcess EJB created by and from the Bill EJB.
>
> I'm not sure what you're saying here.  You are receiving an
> object that implements
> a specific interface (your bean) which has been declared in your
> Home interface.
> If you intend to cast the returned object to a different
> interface, then I would
> argue that something is wrong with your design.

It is not what I wanted to express. The Bill EJB (A) has created the
BillPaiementProcess EJB (B). But I do not receive object B from its home
interface (BHome). I receive from A instead :
"A.giveMeTheBEJBObjectYouJustCreated ()" which is of the kind B.

But I know which subclass of B it will be (as I gave the parameter to
a.ejbCreate(parameter)) so I can safely "ejb-cast" it. B Homes interface are
only used by A ejbCreate method, not by the client side code.

...

But I think I know understand what you tell me :
        - either I use multiple implementations on the server side, selected
by
whatever mean by server-aware code (and a parameter passed to a constructor
by example), but I only use a generic and identical interface from the
client side for all implementations
        - either I want to be able to act differently on these
implementations from
my client and I need to create completely different EJB objects (not only
EJB implementation). In spite of that, I can still use inheritence to
organize my EJB classes and remote interfaces to facilitate my client code.


In a previous post, you said that component inheritance was not possible
with EJB (with current spec only or will never be possible by design?).
Nevertheless, I guess it is still possible to have a session bean (for
example) query different types of entity beans each belonging to a same root
interface and having this session method return a collection of remote
interface, each possibly identifying a different target EJB. Right?

Thank you Cedric. Cheers,



                                        Sacha

===========================================================================
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".

Reply via email to