I was in vacation when that thread started, so I am catching up a little on
that and would like to add my two cents.
I have been struggling with inheritance too and it feels good to share the
frustration with others.
In fact, classes that should be beans are the concrete ones, and they might
not all be leaves.
I also want to add that the EJB hierarchy can hardly be built on top of an
existing class hierarchy. The bean implementation classes must be aware that
they are EJB classes. They must be aware of small details like :
They should not implement the interface to which they correspond
(see some discussion about that on the list).
When returning a reference to self they should return the EJBObject
related to the bean (context.getEJBObject()) instead of 'this'.
Persistent attributes must be made public for CMP fields in entity beans,
even if this is usually not considered as a good practice in plain java.
For association and relationships you should use Handle or collections of Handle.
However since I am new to EJB I don't know how handle are mapped in relational DB.
For sure the
Handle implementation is vendor specific.
The polymorphic finder is not that trivial. In EJB spec 1.1, the finder
implementation must return a collection of keys. It is then to the container
to load/activate the appropriate bean instance. The container will always
provide EJBObjects that refer to instances of the bean corresponding to the
home interface, not to a derived class.
CompanyHome.findPublicShareCompanies() will return a collection of ICompany
not of IPublicShareCompany and the container will invoke business methods
of CompanyImpl, not of PublicShareCompanyImpl. I don't see any easy
workaround (maybe I missed something) to insure that the finder method
will return a IPublicShareCompany or to invoke PublicShareCompanyImpl
methods from CompanyImpl keeping the security and transaction context.
Do you have any hint on how to implement these polymorphic finders?
The only way I see is to have a specialized SessionBean that does the
find on the base class bean, check some fields in the returned entity
bean and then replace the object in the collection by the derived class
when it found an object that should be from a derived class.
Collection c = BaseClassHome.findBySomeCriteria( xxx );
Collection replacement = new SomeConcreteCollection();
for (Iterator i = c.iterator(); i.hasMore();)
{
BaseClass base = (BaseClass) i.next();
if ( DerivedClass.SPECIFIC_VALUE.equals(base.getTheProperty()))
{
i.remove();
replacement.add( DerivedClass.findByPrimaryKey(base.getPrimaryKey()));
}
}
c.addAll(replacement);
return c;
The problem with that solution is that you have to change the find methods
everytime you add a new class in the hierarchy. You also must put some field
in the base class to keep track of the actual class of the object.
Do you have cleaner suggestions?
Benoit Tremblay (Clea informatique)
at Ericsson Research Canada
===========================================================================
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".
