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?
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!
Hmm long question, I'll be very impressed if you got this far and
even more impressed if you have an answer !!!
Looking forward to your reply!
Dave Elliot
[EMAIL PROTECTED]
