Hi,
Please note that the JBoss proxies implement the
remote interface if the bean so that you can
ask "if (myRef instanceof MyRemoteInterface) ...".
However, that is not portable.
But IsA functionality is present implicit in
javax.rmi.PortableRemoteObject.narrow():
If A is not null then
If (A IsA B) then
narrow(A, B) returns != null, castable to B
If not (A IsA B) then
narrow(A, B) throws ClassCastException
While EJB does not support component inheritance,
language class inheritance (and in particular
superinterfaces of remote interfaces) is allowed.
Best Regards,
Ole Husgaard.
Sacha Labourey wrote:
>
> Hello all IsA friends,
>
> I agree with you Edward, this feature should be directly integrated in the
> EJB behaviour to be of real help.
>
> Nevertheless, in the meantime, some of us may accept to pay the price of
> additional problems by using workarounds in order to get an IsA approaching
> feature. Peter has suggested one.
>
> If we look at the change between EJB 1.0 and 1.1, narrowing must be
> ecplicitly done thanks to the javax.rmi.PortableRemoteObject.narrow() call.
> This change "pervert" the usual Java usage through the use of a kind of
> "helper class" or more accuratly "helper method" to accomodate from the
> CORBA/IIOP world.
>
> We may also have a kind of javax.rmi.PortableRemoteObject.isA() helper call
> which may be implemented this way (would be in another package!):
>
> {
> //.. two parameters : theEjbObject (EJBObject) and classToCompareTo
> (Class)
> //
> EJBHome theEjbHome = theEjbOject.getEJBHome();
> EJBMetaData metaData = theEjbHome.getEJBMetaData();
> Class theEjbRemoteClass = metaData.getRemoteInterfaceClass();
>
> return theEjbRemoteClass.isAssignableFrom (classToCompareTo);
> }
>
> This solution has the advantage to accept in input any EJBObject and Class
> object. It has the disadvantage to cost network round trips. The ideal
> solution would have this information directly incorporated in the proxy.
>
> As I said before, I agree that some standard/usable mechanism would be
> greatly appreciated. In the meantime we may be interested in finding
> interesting workarounds at some cost.
>
> Cheers,
>
> Sacha
>
> > -----Message d'origine-----
> > De : [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]De la part de Kenworthy, Edward
> > Envoyé : mardi, 6 février 2001 08:54
> > À : 'jBoss'
> > Objet : RE: [jBoss-User] IsA behaviour when inheriting beans
> >
> >
> >
> > You're still missing my point !
> >
> > The reason for choosing an OO programming language is that it
> > *supports* the
> > various OO constructs - inheritance, classes, polymorphism and all the
> > behavour that is implied (eg inheritance without resulting isA behaviour
> > isn't true inheritance.)
> >
> > You would be mad to try and programme in a fully OO way using an 8 bit
> > assembler language, because you would have to hand code all of the support
> > for OO that an OO language has built into it. This would lead to a
> > maintenance nightmare. What happens if someone else modifies your code and
> > fails to follow your hand-crafted implementation of some OO
> > feature ? It's a
> > real pain in the arse.
> >
> > Enterprise Java Beans are implemented using Java. However the EJB
> > spec does
> > not allow for inheritance between EJBs (the major issue being with entity
> > beans.) It doesn't support it. Can you hand craft support for isA
> > inheritance ? Sure, but that's rather missing the point, as I explained
> > above.
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
