Tim Pedone wrote:
>
> Evan,
>
> thanks, I'm glad it was a straight forward solution. The second variation seems
>like it would be more portable so what's the advantage of the
>javax.rmi.PortableRemoteObject.narrow solution?
Well the EJB spec says:
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.
Note: Programs that use the cast operator to narrow the remote and home interfaces
are likely to fail if the Container implementation uses RMI-IIOP as the underlying
communication transport.
Now to my mind a component that uses EJBContext.getEJBObject() is acting
as a client to itself, and thereby must use narrowing as stated above. However,
I can't for the life of me understand why the spec writers have left us with these
wishy-washy requirements. I would suggest either replacing the above with:
A client program must use the javax.rmi.PortableRemoteObject.narrow(...)
method to perform type-narrowing of the client-side representations of the home
and remote interface.
Or, even better, remove this requirement altogether! It's not that hard
for the vendors to allow direct casting, even when we implement over IIOP.
All that is required is a little intelligence in the NamingContext objects
(much the same kind of intelligence that is required in the implementation
of PortableRemoteObject.narrow).
>
> Tim Pedone
>
> >>> Evan Ireland <[EMAIL PROTECTED]> - 8/9/99 4:44 PM >>>
> Tim Pedone wrote:
> >
> > Hello,
> >
> > We've started creating an object model that we are going to implement using EJB.
>I've come across a fundamental design issue that I'm not sure how to solve. We have
>two beans: ControlParamBean and ActivityBean (along with their associated interfaces
>ControlParam and Activity). ControlParam has a method called setActivty() that takes
>an Activity as an argument. This method will be called from the client. Activity
>has a method called addControlParam() that takes a ControlParam argument. The body
>of ActivityBean.addControlParam() looks like this:
> >
> > aControlParam.setActivity(this);
> >
> > Of course the problem is that setActivity() takes an Activity and "this" is an
>ActivityBean. I can't cast it because ActivityBean does not truly implement
>Activity. Since the client knows nothing of the ActivityBean class, I can't change
>setActivity() to take an ActivityBean either. How should this be handled?
>
> What about:
>
> Acvitity self =
>(Activity)javax.rmi.PortableRemoteObject.narrow(_context.getEJBObject());
> aControlParam.setActivity(self);
>
> or:
>
> Acvitity self = (Activity)_context.getEJBObject();
> aControlParam.setActivity(self);
>
> if your server doesn't support the standard narrowing mechanism.
> ________________________________________________________________________________
>
> Evan Ireland Sybase EA Server 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".
>
> ===========================================================================
> 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 EA Server 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".
