Hi Elliot, i posted nearly the same question some days before. It seems,
that sun's spec says, findXXX and create functions must return the beans
remote interface, which would be the subclass, not any superclass. But in
fact, the spec isn't very explicit in this point, and what's more: the j2ee
reference implementation does allow you to do exactly what you want...
Furthermore i have (had?) another problem, concerning derivation of the
bean's remote interface and implementation class. To illustrate it, i
include a Mail i sent to the j2ee interest mailing list:
-----------------------------------
I want to define my own "inheritence" of beans using bean managed entity
beans. Therefore i must be able to derive a beans remote interface from
another beans remote interface - and the bean class itself, too (the home
interface cannot be derived for the sake of the return type of finders and
create fn - it must be the beans remote interface and cannot be some common
base class, at least as stated in the spec... nevertheless the j2ee
reference implementation in fact allows common base classes as finder/create
return types... orion for example does not... but back to my problem...).
In particular i defined an interface
public interface NMejbObject extends javax.ejb.EJBObject
{
public long getId() throws RemoteException;
}
and a bean class
public class NMejbEntity implements javax.ejb.EntityBean
{
public long m_Id;
public long getId()
{return m_Id;}
}
Then i used these classes as base classes to define an entity bean, such
that the getId() fn will be like any normal remote function of the EJBs
remote interface. This bean works fine within the j2ee reference
implementation.
Then i introduced another derivation step:
public interface NMejbBeanTypeA extends NMejbObject
{
public long someFn() throws RemoteException;
}
and
public class NMejbEntityTypeA extends NMejbEntity
{
public long someFn()
{ // do something }
}
If you construct a bean using these classes as base classes, hence
public interface MyActualBeanRemote extends NMejbBeanTypeA
public interface MyActualBeanImpl extends NMejbEntityTypeA,
the j2ee server encounters a compilation error on deployment, when trying to
compile the generated implementation wrapper (the *_EJBObjectImpl.java,
which implements the remote interface of the bean), saying that the function
getId() of the class NMejbObject is not implemented - which in fact is true
and can be seen in the generated code. There is generated code for the
someFn() but not for getId(). That means, functions which perfectly fit all
EJB specifications won't be treated correctly by the code generation, if
defined in a super-super-interface. But the j2ee deploytool itself
recognizes the function getId() and offers it for example in the transaction
screen.
I wanted to know, if this is a bug of the j2ee reference implementation or
part of the spec (could not find it).
All this inheriting seems to be useless, but i want to build my own
"inheritance" for beans with bean managed persistence, which won't work if
the above thing does not work...
-----------------------------------
Well, since the weekend is beginning and it's my work writing ejbs, not fun,
i could not test everything, but it seems, that orion is able to deploy such
a 3-step inherited bean, at least there are no error messages on deploying
it... me lacks the time to write a client today to check, if the functions
are really in there, but if it's able to compile it, the chances are at
least good ;-) - you'll here it on monday!
Best regards
Jens Stutte
-----Urspr�ngliche Nachricht-----
Von: Elliot, David (NOW) [mailto:[EMAIL PROTECTED]]
Gesendet am: Donnerstag, 17. Februar 2000 20:13
An: Orion-Interest
Betreff: Can you deploy a subclassed EJB with Orion (or J2EE for that
matt er) ?
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]
