-----Original Message-----
From: Elliot, David (NOW) <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Date: Thursday, February 17, 2000 10:33 AM
Subject: Can you deploy a subclassed EJB with Orion (or J2EE for that
matter) ?
>Hi all,
>
>I have a question regarding Orion 0.9.1 and I guess J2EE in general.
>I hope I can phrase this problem correctly as it's causing us a little
>grief...
>
>Basically, should you be able to build an entity EJB's remote&home
>interfaces and the implementation class as superclasses forming a
>"superclass" entity EJB? And then sub-class this EJB to create
>a series of subclass EJBs ?
>
>We need to do this but find that Orion does not want to compile an
>EJB that is built as a sub-class of an existing EJB. This is because
>the return type of findByPrimaryKey() (the method is defined in the
>superclass) is not being considered valid by Orion in the subclass that
>inherits it.
>
>ie: findByPrimaryKey() is defined in the SuperClassHome as:
>
> SuperClass findByPrimaryKey(Integer)
>
>Which is also implicitly a method that gets inherited by SubClassHome.
>
>However Orion is not happy with that method signature when
>it compiles SubClassHome, as it expects the return type to
>be SubClass, ie:
>
> SubClass findByPrimaryKey(Integer).
>
>As SuperClass is a superclass of SubClass, shouldn't it be ok
>to have a superclass for the return type of findByPrimaryKey (as
>it encompasses SubClass) via the nature of polymorphism?
The reverse would be true; but SuperClass is not an instanceof SubClass.
The object returned by findByPrimaryKey is literally what you get from the
EJB find, in this case expecting an instance of SubClass. If your design
were implemented, and you called a method specific to SubClass on the result
of this EJB find, you would get a NoSuchMethodException.
>
>
>Just a quick note to explain the why:
>We have a requirement for a session EJB which will be used by
>clients to access a variety of entity EJBs. We need the session
>EJB to be able to lookup the entity EJB's dynamically (ie it won't
>know which EJB it is looking up at compile time). So we want
>to pass it the String identifying the EJB it is to lookup, which
>it will lookup and narrow to the generic superclass of all the EJBs. It
>could then call some standard methods on this EJB knowing that the
>subclass EJB it actually has a handle on has implemented these
>methods. This doesn't work if you can't deploy a subclass EJB tho...
>hence the question!
We're doing something similar, and our solution has been to create only one
entity bean, for SuperClass. The bean instantiates the requested SubClass
by string (Class.forName()) and returns it as an instanceof SuperClass.
Orion will let you do this. The consequences are that the key is heavy,
because it carries a long stringy classname, and that the SuperClass data
members tend to end up in a weakly type-checked configuration.
>
>
>Hmm long question, I'll be very impressed if you got this far and
>even more impressed if you have an answer !!!
Just the diversion I was looking for.
>
>Looking forward to your reply!
>
>Dave Elliot
>[EMAIL PROTECTED]
>
>
>
